Papéis no desenvolvimento de software significa uma ocupação, uma responsabilidade, assim como em um teatro, um ator faz um “papel” em uma peça. No desenvolvimento, é mais ou menos a mesma coisa, em um projeto de software, cada um assume um papel no projeto, aonde terá um conjunto de responsabilidades.
Papel é um pouco diferente de cargo, por exemplo, o cargo de uma pessoa na empresa pode ser Assistente Administrativo, mas no projeto ele assume o papel de usuário chave (key user) do módulo financeiro. Então, antes de mais nada, separe a ideia de papel de cargos na empresa,
O framework Scrum contém apenas 3 papéis para composição do Time Scrum: O Dono do Produto (Product Owner), Scrum Master e Time de Desenvolvimento (Development Team).
O Dono do Produto (Product Owner).
O nome já diz tudo, esse papel é responsável pelo produto (software), ele é o dono do produto, ele é quem diz o que vai ter e o que não vai ter no produto, o que deve ser feito primeiro, ou seja, define as prioridades. Além disso, é responsável pelo ROI (Return On Investiment ou retorno sobre o investimento) e deve conhecer muito bem as necessidades do produto.
As necessidades do produto certamente não virão da cabeça do Dono do Produto, mas sim dos usuários, dos gerentes do negócio, do dono da empresa, enfim, dos stakeholders (interessados no projeto), mas é o Dono do Produto quem recebe as necessidades e as prioriza conforme os interesses destes stakeholders, pois ele é o representante oficial dos mesmos.
Para ser um dono do produto, ele precisará:
- Conhecer o negócio do cliente / empresa e suas necessidades.
- Precisará maximizar o valor do produto, avaliando o maior retorno possível sobre o dinheiro investido.
- Deve ter facilidade de acesso aos interessados no projeto.
- Deve ter facilidade de comunicação com diversos níveis hierárquicos da empresa ou cliente.
- Cuidar do Backlog do Produto (lista dos itens e funcionalidades que o produto terá, veremos isso em detalhes em outro artigo).
- Definir o período das liberações (releases) do software.
- Ser uma única pessoa, não um comitê (ainda que influenciado por um conjunto de pessoas).
- Detalhar os itens do backlog do produto, criando as estórias de usuário ou especificações dos requisitos, no nível de detalhe suficiente para o Time de Desenvolvimento.
- Estar sempre disponível para o Time de Desenvolvimento, quando este requerer informações para realizar o desenvolvimento do produto.
- Fornecer feedback constante para o time de desenvolvimento.
- Garantir que o Backlog do Produto seja visível para o time scrum e todos os interessados no projeto.
O Dono do Produto, e somente ele, é quem determina o que deve ser desenvolvido pelo time de desenvolvimento, podendo incluir ou tirar itens do Backlog do produto, ele só não pode retirar itens de uma Sprint em andamento, mas caso necessário, ele poderá cancelar uma Sprint (o que é muito raro devido a sua curta duração e uma prática, apesar de possível, não recomendável). Obviamente ele atua sobre a influência de outras pessoas interessadas no projeto, mas é ele quem define se algo deve ser feito e quando (prioridade), pois ele é quem responde sobre o ROI do projeto.
O Dono do Produto, idealmente, não deve ser pressionado por decisões unilaterais, por exemplo, de um diretor, que utiliza seu “poder” para solicitar alguma demanda. Por exemplo, o diretor solicita que no pedido de venda, seja emitido um aviso sobre produtos em promoção e ao mesmo tempo, o gerente financeiro solicita que no pedido de venda seja emitido um alerta ao vendedor se o cliente selecionado estiver com alguma fatura em atraso e não deixe seguir com o pedido de venda. Neste ponto, qual o item mais importante? O que o diretor da empresa pediu ou o que o gerente pediu? A resposta é “depende”. A solicitação do diretor pode não ser mais importante em um momento em que as vendas estão indo bem, então faz sentido não vender para inadimplentes para não prejudicar mais ainda o caixa da empresa, mas pode ser muito importante em um momento que é necessário aumentar as vendas e os produtos em promoção são estoque antigos que estão parados.
Por isso a importância do Dono do Produto ter certa imparcialidade nas decisões em termos de “quem solicitou” e assim poder analisar o que é melhor para o negócio e definir o que irá trazer maior valor ao negócio primeiramente.
Outro ponto importante, é que é recomendável que se tenha apenas um Dono do Produto, para cada Backlog do Produto, para evitar conflitos de interesses e é extremamente recomendável que o Dono do Produto não seja o gerente ou chefe dos desenvolvedores.
Comparando com os modelos tradicionais de desenvolvimento de software, o Dono do Produto estaria juntando parte de 3 funções: Gerente do Projeto e Analista de Requisitos e Consultor de Negócios.
O Dono do Produto, se assemelha a um Gerente de Projeto pois é dele a responsabilidade de definir as prioridades, o escopo do produto (backlog do produto), define quando serão efetuadas as liberações em produção (releases do produto) e acompanha os prazos da entrega das releases. Porém, as semelhanças param por ai, pois ele realiza o “macro” gerenciamento, pois não cabe a ele definir o tempo de entrega de cada item do backlog, não determina as tarefas a serem realizadas muito menos o tempo das mesmas e não controla os prazos dentro de uma Sprint.
O Dono do Produto, se assemelha a um analista de requisitos, pois ele é quem realiza esse levantamento, coleta as necessidades e busca detalhar a nível de negócio as necessidades, mas ele não irá definir como será construída a solução para resolver o problema do negócio, como faria um analista de sistemas. Ele fica no nível mais acima, na camada do negócio, pois é o Time de Desenvolvimento quem irá definir qual a solução para resolver ou atender a necessidade do negócio.
E o Dono do Produto se assemelha a um consultor de negócios, pois ele deverá conhecer o negócio do cliente e analisar as demandas no nível de quanto cada solução irá trazer de retorno ao negócio, mas a responsabilidade para ai, pois encontrar melhores soluções para o negócio, já não faz parte deste papel.
Por fim, o que não se espera de um Dono de Produto:
- Falta de conhecimento sobre o produto sendo desenvolvido ou do negócio.
- Falta de tempo para atender o time de desenvolvimento.
- Falta de habilidade de comunicação e relacionamento interpessoal.
- O micro gerenciamento, tipo comando e controle, típico de gerentes tradicionais.
- Dificuldade de tomada de decisão.
- Falta de autoridade sobre o produto sendo construído.
- Falta de conhecimento do Scrum.
No próximo post, irei abordar o Time de Desenvolvimento. Até a próxima.