Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.
Projetos e produtos
Primeiro algumas definições básicas:
A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.
Fonte: http://en.wikipedia.org/wiki/Project
The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.
Fonte: http://en.wikipedia.org/wiki/Product_(business)
Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.
Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).
Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.
Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:
Just like every product needs a product manager, every project needs a project manager. Just because product managers think they can manage their own projects does not mean they should. The skills, talents, and traits involved in project management are very different from those involved in product management. Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role. Project management is not a stepping stone to product management, nor vice versa. Good project managers are just as valuable as good product managers. Finding a good project manager to manage your projects will help you be an even better product manager. The less time product managers spend on project management, the more time they will be able to spend on product management. To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.
Já Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:
For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.
As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):
[Scrum] Roles: Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Team: A cross-functional group of people responsible for managing itself to develop the product. Scrum Team: Product Owner, ScrumMaster and Team
[Scrum] Roles:
Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Team: A cross-functional group of people responsible for managing itself to develop the product. Scrum Team: Product Owner, ScrumMaster and Team
Fonte: http://en.wikipedia.org/wiki/Scrum_(development)
Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.
Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia… O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…
O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
fonte: http://pt.wikipedia.org/wiki/Croquis
Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.
Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.
O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.
Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.
A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.
Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…
Burnup feito à mão
Outro exemplo de burnup feito à mão
Burn down feito à mão que aparece na busca por imagens de burnup
Mais um exemplo de burnup feito à mão
Na gestão de projetos tradicional existe o famoso Gantt Chart que permite saber com precisão quanto tempo um projeto vai levar, quanto tempo demorará cada tarefa do projeto, que tarefa depende de qual tarefa e se alguma atrasar, o que acontece com o projeto.
Gantt chart
O Gantt Chart não se aplica a contento para projetos de software que usam metodologias ágeis pois ele pressupõe o conhecimento completo de todas as tarefas e fases do projeto antes de seu início, enquanto que nas metodologias ágeis “responder às mudanças tem mais valor que seguir um plano”, ou seja, as metodologias ágeis entendem que mudanças sempre vão acontecer e que o melhor a fazer é estar preparado para as aceitá-las.
O cone da incerteza
Já que mudanças sempre vão acontecer, como podemos acompanhar um projeto ágil, saber qual é o prazo de entrega desse projeto e, ao longo do projeto, saber se ele está dentro do prazo? Mesmo antes das metodologias ágeis já existia o conceito do cone da incerteza que diz que a precisão das estimativas de prazo de um projeto é muito pequena no início do projeto e aumenta ao longo do tempo. Aliás, não só a precisão das estimativas de prazo, como também de custos e de escopo que, juntos com o prazo, são os três limitadores de todo projeto.
Cone da incerteza
O cone da incerteza se aplica a qualquer projeto, quer ele use metologias ágeis ou metodologias de gestão de projetos mais tradicionais. Ou seja, mesmo tendo um Gantt Chart, no início do projeto não teremos precisão sobre seu prazo. O Gantt Chart passa uma falsa impressão de que está tudo sob controle, mesmo com todas as incertezas que existem no início de qualquer projeto.
Mas eu tenho que ter um prazo…
Contudo, mesmo levando em conta o cone da incerteza, é possível ter uma estimativa de prazos, nem que seja algo como “esse projeto vai ficar pronto em setembro” o que significa que ele pode ficar pronto em qualquer um dos 30 dias de setembro, ou “esse projeto será entregue no terceiro trimestre de 2011″ o que dá 45 dias para mais ou para menos de margem de erro!
Prazos têm que existir e te que ser respeitados.
E não raro há casos em que prazo é fixado por quem pediu o projeto (“o site dessa promoção tem que ser publicada até 15 de julho pois nesse dia teremos uma campanha direcionando para esse site”). Nesses casos nos sobram escopo e recursos para mexer sendo que às vezes adicionar mais recursos não faz o projeto andar mais rápido.
De qualquer forma, tanto tendo um prazo fixo (“15 de julho”) quanto podendo dar estimativas um pouco mais abertas (“em setembro”, “terceiro trimestre de 2011″), é preciso saber se estamos dentro do prazo para podermos tomar decisões (trazer mais gente? reduzir escopo? negociar mais prazo?).
Como fazer acompanhamento de projetos ágeis?
Projetos ágeis podem fazer uso de gráficos burnup para podermos ter melhor visibilidade de seu andamento. Não estou falando dos gráficos burnup de cada iteração, que interessam apenas à equipe que está tocando o projeto, mas sim um burnup do projeto inteiro que trará informações úteis para todas as pessoas interessadas nesse projeto.
Veja o exemplo do gráfico abaixo:
Burnup
Nesse exemplo temos uma definição inicial do esforço necessário para terminar um determinado projeto que teria começado em 7/1/2008. O esforço necessário para concluir esse projeto é de quase 100 “xpto”, que está marcado na linha verde. Esse “xpto” pode ser pontos ou horas ou features ou o que quer que usemos para medir progresso de desenvolvimento.
Note no exemplo que nos dias 4/2, 18/2 e 31/3 houve aumentos do esforço necessário. Se não fossem esses aumentos o projeto estaria concluído até 24/3. Com os aumentos passou para 21/4, quase um mês de atraso.
A linha vermelha mostra a velocidade do time. A inclinação dessa linha é o indicativo da velocidade: quanto menor a inclinação, mais devagar o time e, consequentemente, o projeto está andando.
Por que um gráfico burnup como esse é importante?
Ele vai ajudar o time e todos os interessados no projeto a entender seu andamento. Esse gráfico deve andar junto com uma espécie de log para entendermos porque aumentou o esforço necessário, ou porque o projeto está andando mais devagar.
Não é necessário nenhum software especial para fazer esses gráficos. Uma planilha pode dar conta do recado, ou mesmo o bom e velho papel e lápis!
Normalmente o esforço necessário para entregar um projeto pode aumentar porque aumentou o número de funcionalidades a ser entregue (aumento de escopo) ou apareceram dificuldades técnicas não previstas. Esse esforço pode diminuir quando há diminuição do escopo do projeto.
Razões comuns para diminuição de velocidade do projeto são o surgimento de dificuldades técnicas não previstas ou a entrada de um projeto extra que está divergindo esforços da equipe ou ainda a saída de um ou mais membros da equipe antes do término do projeto.
Enfim, a idéia é conseguir ter maior visibilidade e, consequentemente, mais informações para que se possa intervir quando necessário para garantir a entrega dos projetos dentro do prazo estimado.
Acabou de ser publicado hoje, na InfoQ, um whitepaper que escrevi sobre Gestão Ágil de Produtos:
http://www.infoq.com/vendorcontent/show.action?vcr=581
Posted originally in Portuguese at Locaweb’s AgilBlog
I recently read about agile culture and how some teams use only the processes embedded into the agile methodologies without absorbing the agile culture:
Doing some research on Wikipedia, I found:
which means that while process is “how things get done”, culture explains “why things should be done that way”.
What matters the most is the culture, since without knowing “why” something should be done in some way it is very difficult to follow and maintain that way – the “how” to do those things.
We can have an agile culture without any methodologies. If we present the Agile Manifesto and its principles to someone who never heard of agile methodologies, is very likely that she end up creating some processes which enable the agile culture.
On the other side, given an agile methodology like Scrum or XP, it is not easy to understand why this process should be followed. We can even see some benefits in the daily routine of software development but without knowing why we should follow this process, the probability that the process continues to be followed or, even more important, that the process evolves, are minimum.
That’s why it is so important to understand the agile culture before implementing any agile methodology
But culture change is a long term task, slow and difficult to measure. And any long term, slow and difficult to measure task is of little attractiveness. People look for the culture change benefits but are not willing to spend what is necessary to get to the results. That’s why we see the recipes.
Implementing methodologies and process changes are short term tasks, with great impact and easy to measure (graphs, points, etc.). That’s why we naturally prefer methodologies, the recipes.
It is very important to coordinate the methodology implementation and the process change in order to be sure they are not performed mechanically and that they are gradually inserted as a new organizational culture.
Coordinating the methodology implementation and the process change is not about knowing a lot about the topic and answering questions like “what should I do with the story points of this unfinished story?” or “should we estimate stories in points or hours?” or “should we use kanbam, lean, XP, scrum, …?” or …
This coordination must be in the direction of “agile thinking”. Agile methodologies are supposed to helps us think agile but many times it makes us stop thinking. :-/
Culture can only be changed through thinking, arguing, listening, experimenting.
Following recipes without thinking, arguing, listening and experimenting is a sure recipe for a mechanical implementation of the methodologies and a good chance of failure.
As mentioned in Outliers and in a very interesting Scientific American article, in order to be a specialist in anything we must practice in a thoughtful way and understanding what we are practicing and never execute the “blind practice”.
So in your next revision and planning meeting, or even during your daily stand up meeting, remember that prior to the methodologies comes the agile culture. Re-read with your team the agile manifesto and its principles and discuss the following topics:
Agile is culture, agile methodologies are the processes that help create this culture.
Would you like to read more about this topic? Please check other posts on agile and agile methodologies.
Publicado originalmente no AgilBlog da Locaweb
Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:
Pesquisando na Wikipedia, encontrei as definições abaixo:
Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.
Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.
As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.
A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.
Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.
Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.
Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.
Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.
É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.
E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …
A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/
Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.
Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.
Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.
Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:
Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.
Quer ler mais sobre o tema? Então veja outros posts sobre agilidade e métodos ágeis.
Há quase um ano atrás eu comentei sobre a mudança do papel do gerente em um time que resolveu adotar metodologias ágeis. Na London QCon 2009 foi apresentada a palestra Managers in Scrum de Roman Pichler, um consultor inglês especializado em gestão ágil de produtos.
A apresentação completa pode ser vista em:
http://www.infoq.com/presentations/managers-in-scrum
Quem quiser ver só os slides, pode baixá-los aqui.
Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:
Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:
Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:
E, por último, um resumo:
Vale conferir essa apresentação.
Texto muito interessante da infoQ sobre como ter times super produtivos:
http://www.infoq.com/news/2009/03/hyper-productive-team
Aliás, esse texto é um resumo de 4 artigos sobre Group Coherence de Joanna Zweig e Cesar Idrovo publicados Agile Journal baseados em uma pesquisa feita por eles:
Ao contrário do que reza a lenda, não basta só ter certeza que a máquina de café esteja funcionado…
Vou fazer como a infoQ e vou colocar abaixo um resumo do resumo!
Primeiro a motivação:
“Group characteristics and group dynamics are invisible to most of us. We are not trained to detect them, let alone manage them. Our work is influenced by much more than what we see. This can make project success (and failure) sometimes appear to be random.”
Em seguida, uma definição:
“Group Coherence is the shared state reached by a group of people that allows them to perform one or more tasks in perfect rhythm and harmony with great energy to overcome obstacles. This simplistic interpretation is a starting point for discussion and we acknowledge that it doesn’t begin to do justice to all the interdisciplinary components of Group Coherence that include behavioral, psychological, spiritual and sociological.”
E depois vêm as constatações (os destaques são meus):
“In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group’s ability to execute on the project vision or enterprise strategy.”
“The hyper-productive teams we have observed apply high rates of practical collaboration. We believe that fostering Collaborative Interaction leads to increases in productivity, yet performance is recognized at the individual rather than team level. In environments where collaboration is required, managers should avoid assigning project work and accountability to individuals.”
“Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production. Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.”
“Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production.
Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.”
Abaixo estão os 4 atenuadores:
E os 5 amplificadores:
E a conclusão:
“In hyper-productive teams there are high levels of group creativity despite functional specialization. These are groups that are willing and allowed to experiment. Group Coherence can help understand the ingredients that can be observed when this happens. In the research these include Trust and Respect, Bonding, Loosening Boundaries, Shared Leadership, Agreement on a Shared Goal and Tolerance for Chaos. These formed the basis for this post. They cannot guarantee an earlier or more dynamic occurrence of group creativity, but their absence can prevent or delay its emergence. They are also all available to Agile teams.”
“In hyper-productive teams there are high levels of group creativity despite functional specialization. These are groups that are willing and allowed to experiment. Group Coherence can help understand the ingredients that can be observed when this happens. In the research these include Trust and Respect, Bonding, Loosening Boundaries, Shared Leadership, Agreement on a Shared Goal and Tolerance for Chaos. These formed the basis for this post. They cannot guarantee an earlier or more dynamic occurrence of group creativity, but their absence can prevent or delay its emergence.
They are also all available to Agile teams.”
O termo maçã podre, apesar de bastante forte, serve para descrever uma situação bastante delicada na formação e gerenciamento de times. Chamamos de maçã podre (rotten apple) a pessoa que destoa negativamente do resto do time e que, com seu comportamento, poderá estragar a equipe.
A InfoQ falou bastante sobre esse tema da maçã podre do ponto de vista técnico, o under-performer, aquele que é ou está tecnicamente abaixo do resto da equipe. Esse post da InfoQ é um resumo de um thread na lista Scrum Development no Yahoo! Groups que gerou mais de 100 mensagens sobre o tema.
Agora, o que fazer quando nos deparamos com uma maçã podre do ponto de vista comportamental? Alguém que é tecnicamente bom, mas que tem problemas de comportamento? Tecnicamente essa pessoa pode ter bastante para contribuir para o time mas seu comportamento faz com que o time não consiga ter um bom relacionamento com essa pessoa.
Nesses casos há dois caminhos a seguir. O mais simples é tirar essa pessoa do time. Essa é uma solução fácil tanto para o time quanto para o seu líder. A tendência numa situação dessas é o time isolar a pessoa difícil até que ela, por vontade própria ou por decisão do chefe, saia do time.
O caminho mais difícil, mas que certamente trará mais benefícios para a equipe, é ajudar essa pessoa difícil a se integrar ao time ao ponto de essa pessoa deixar de ser uma maçã podre.
É fácil receber no time pessoas fáceis de lidar. O desafio é receber uma pessoa difícil e ajudá-la a se integrar ao time. Os valores do time devem ser mais fortes que os valores da pessoa difícil ao ponto de os valores do time serem absorvidos e assumidos pela pessoa difícil.
Conversas francas com todo o time e com a pessoa difícil é um bom caminho. A transparência é essencial. Se houver boa vontade e disposição tanto do time quanto da maçã podre, há boas chances de a situação ser revertida.
Vale lembrar que, na maioria das vezes, uma maçã podre não quer ser maçã podre. Ela pode não se dar conta de que seu comportamento é prejudicial para o time. Ela pode ter tido experiências anteriores onde seu comportamento seria considerado normal. Por isso vale investir em ajudar o time e a pessoa difícil a se entenderem. Contudo, não dá para tentar indefinidamente fazer com que as coisas se ajeitem. É importante definir um prazo para reavaliar a situação e, caso ela não tenha se resolvido, talvez não haja outra opção a não ser tomar uma decisão mais difícil: dispensar uma ou mais pessoas do time.
Consegui achar mais um tema que une a natação com gestão de produtos, métodos ágeis e desenvolvimento de sistemas, a questão de como se tornar muito bom em alguma coisa. Afinal, nascemos com um dom, ou com prática poderemos ser muito bom em algo?
Há uns 4 meses atrás li um artigo sobre natação em:
http://www.totalimmersion.net/2007articles/january/expert.html
Que me levou ao artigo “The Expert Mind” da Scientific American. O mote das duas é que dá para se transformar em um especialista do assunto desde que:
Recentemente esse tema voltou à tona com o novo livro do Malcom Gladwell, autor de “The Tipping Point: How Little Things Can Make a Big Difference” e “Blink: The Power of Thinking Without Thinking“, chamado “Outliers: The Story of Success“.
Curiosamente a receita de sucesso é mais ou menos a mesma: para se transformar em um especialista em algum assunto (natação, programação, gestão, aplicação em bolsa, etc.) deve-se:
