Uma questão bastante abordada e discutida quando pensamos em projetos que utilizam do SCRUM como ferramenta de processo, é a ausência (indisponibilidade) do Product Owner. Se levarmos em consideração que PO é o "cara" que melhor conhece o produto, que tem clara a prioridade do que deve ser feito, é a pessoa que demanda as necessidades do negócio, considero natural que esta "entidade" não seja tão acessível quanto pregamos no SCRUM.
Como resolver esta questão?
Abaixo uma matéria escrita por Paulo Rebelo no site INFOQ explana um pouco mais sobre o assunto.
Como lidar com a ausência de um Product Owner efetivo
O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner.
Papel e responsabilidades
Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:
- Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
- Priorizar as histórias de mais alto valor;
- Estar disponível para a equipe, ajudando-a a entender os requisitos;
- Aprovar as histórias realizadas pela equipe;
- Definir as necessidades dos usuários;
- Garantir o retorno de investimento para cada funcionalidade entregue;
- Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.
A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.
É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega).
Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.
No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto.
Alternativas
Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.
É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?
Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.
Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).
Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.
O Problema da indisponibilidade
A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a.
Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum?
A Implantação do Scrum nas Empresas
Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida.
Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.
Conclusões
O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.
Alaor e Antônio, em primeiro lugar, parabéns pelo texto!
ResponderExcluirComo em toda metodologia e frameworks, tem-se lá as definições de papéis a serem desempenhados e suas respectivas responsabilidades. O Scrum, por ter como proposta a gestão de projetos ágeis, o papel de cada um torna-se ainda mais fundamental e a ausência, ou indisponibilidade, implica, em minha opinião, já listá-lo na lista de riscos. Permanecendo essa situação, eu não teria dúvidas: lista de issues. A importância do seu papel na participação do projeto, implica diretamente na qualidade, prazo e, consequentemente, no custo. Mesmo quando amenizado por elementos como os analista de negócios.
Como é gratificante receber um comentário de uma pessoa que admiro e me espelho. Acrescento a suas palavras uma crença.
ResponderExcluirIndependente do modelo de gestão de projetos (ágies ou tradicionais) o mais importante é que os profissionais envolvidos tenham maturidade e comprometimento, a indisponibilidade realmente é um risco, mas tenho o sentimento que enquanto não se elevar o nível profissional dos analistas envolvidos o custo sempre será o maior vilão do projeto.