O Scrum continua insistindo que uma só pessoa faz o papel de Product Owner em um projeto de desenvolvimento. Uma pessoa estabelece a direção e as prioridades da equipe, define o que o sistema fará, gerencia as demandas do backlog e decide quando o trabalho está pronto. Mas, como em muitas outras organizações, descobrimos que isso não funciona.

Existem muitos detalhes funcionais, operacionais e técnicos para uma pessoa entender e administrar, muitas decisões importantes para uma pessoa para tomar, muitos problemas para resolver, muitas perguntas e arestas soltas para acompanhar, e não há tempo suficiente. Isso requer muitas perspectivas diferentes: necessidades e riscos do negócio, dependências e riscos técnicos, experiência do usuário, capacidade de suporte, compliance e restrições de segurança, fatores de custo. E existem muitas partes interessadas que precisam ser consultadas e gerenciadas, especialmente em grandes sistemas críticos de negócios.

Um único Product Owner não consegue escalonar

Roman Pichler diz que um Product Owner pode suportar uma ou no máximo duas equipes de recursos. O que você faz em grandes projetos, produtos complexos com dezenas ou centenas de pessoas envolvidas? Você precisará montar uma equipe de product ownership, com uma hierarquia de Product Owners reportando a um gerente de produto ou gerente de programa. Ou encontre outra maneira de difundir as responsabilidades do Product Owner para mais de uma pessoa, dividindo um pouco do trabalho entre um gerente de produto e um/ou mais analistas de negócios para cuidar do trabalho detalhado. Você pode, também, tentar usar Customer Pairing ou algum outro tipo de padrão de desenvolvimento baseado na experiência de uso do cliente.

Um princípio do desenvolvimento Agile é que você obtém os melhores resultados de pessoas que trabalham juntas: melhor compreensão, melhores projetos, melhor código. Então, por que pedir uma pessoa para tomar todas as decisões importantes sobre o que precisa ser construído

Quem é o seu Product Owner?

Na nossa loja, cada sistema tem um patrocinador: um executivo de negócios com as responsabilidades operacionais do dia-a-dia e autoridade para tomar decisões estratégicas de negócios e produtos. O patrocinador define a direção e as metas para o sistema como um todo, e consegue lida com qualquer política, arbitrando demandas conflitantes e prioridades das diferentes partes interessadas: clientes, parceiros, vendas, ops, compliance, desenvolvimento. O patrocinador toma as decisões de ir ou não para as principais iniciativas e equilibra as decisões sobre risco e custo, quando as apostas são altos.

As outras responsabilidades estão espalhadas entre as líderes de desenvolvimento, desenvolvedores, testadores, atendimento ao cliente e outras pessoas na organização.

Os líderes de desenvolvimento cuidam da maior parte do trabalho de gestão do backlog e do planejamento detalhado, priorização de recursos e correções, trabalhando com os patrocinadores, desenvolvedores, QA (Quality Assurance ou Garantia da Qualidade), ops e com outras partes interessadas para definir cronogramas de desenvolvimento. Isso dá à equipe de desenvolvimento mais controle sobre como gerenciar as dependências e os riscos técnicos para decidir como o trabalho será feito e que tipo pode ser feito em conjunto.

Os líderes de desenvolvimento e os desenvolvedores preenchem os requerimentos, escrevendo e revisando as especificações, construindo protótipos, realizando workshops, discutindo e argumentando alternativas e esclarecendo detalhes, realizando experimentos e melhorando o design. Sabem quando procurar o patrocinador ou outras partes interessadas quando eles precisam de esclarecimentos ou outro tipo de ajuda. Eles podem cuidar disso porque todos na equipe vêm trabalhando nessa área de negócio por cinco, 10 ou mais anos, e têm a visão e a experiência necessárias.

Dan Norte explica em Accelerating Agile: Hyper-performing without the Hype que a chave para equipes Agile hiperprodutivas é ter pessoas que realmente entendam o domínio, para que todos possam contribuir, preencher os detalhes, fazer sugestões, questionar suposições, avaliar riscos e tomar decisões quando for preciso. Monte sua equipe com pessoas que já trabalharam com os mesmos tipos de sistemas antes, treine todos ou faça experiências práticas, se possível.

Decidindo quando o trabalho está pronto

Decidir quando o trabalho está pronto – o que para nós significa que o código está pronto para ser lançado – também é compartilhado entre a equipe.

Os desenvolvedores escrevem seus próprios testes unitários e testam suas próprias alterações. Todos o código deve passar pelo pacote de ferramentas de regressão automatizada de versão e pela verificação de análise estática em Integração Contínua.

Os líderes de desenvolvimento revisam todos os check-ins de código para terem a certeza de que o código está correto, seguro e de fácil manutenção – isso é feito de forma adequada.

Os engenheiros de QA testam, alteram ou corrigem cada recurso, incluindo testes de integração e testes exploratórios para verificar se o recurso ou a correção faz o que é para fazer. Eles também fazem a revisão da usabilidade, trazendo outras partes interessadas, como o serviço ao cliente ou ops, de acordo com a necessidade deles.

Antes que as mudanças sejam liberadas, nosso gerente de lançamentos (que também é o chefe da nossa equipe de QA) verifica se todos os comentários e demos estão prontos e se todos os testes foram bem sucedidos, avalia o risco, decide qual código está pronto para lançamento e, em seguida, convoca a reunião de lançamento com patrocinador, desenvolvimento, ops e outros interessados. A partir daí, o patrocinador analisa todas as etapas e verificações que foram feitas, revisa as principais mudanças (especialmente alterações que tenham impacto regulamentar ou carregam risco operacional) e dá o ok para que a liberação possa prosseguir.

É assim que Product Ownership deveria funcionar

Ter muitas pessoas dividindo responsabilidades de Product Ownership nos permite fazer mais coisa. Nós também fazemos um trabalho melhor: mais pontos de vista, mais conhecimento e mais oportunidades para perceber e arrumar os erros. Isso cria mais oportunidades de participação e contribuição para o negócio para todos na equipe. E tudo se torna um auto-reforço. Quanto mais as pessoas se envolvem com o Product Owner, mais elas aprendem. Quanto mais elas aprendem, melhor elas fazem o trabalho e podem contribuir mais. A organização fica melhor, o produto fica melhor. Por que você não iria quer isso?

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/05/how-product-ownership-works-in-real.html