Este artigo está dividido em três partes, com muitas verdades inconvenientes sobre código versus produto, “PO imaginário” x “PO real” e documentação versus conhecimento. Clique aqui e leia a primeira parte.

“PO imaginário” x “PO real”

Todas as metodologias ágeis se sustentam, em maior ou menor grau, no princípio de que os desenvolvedores não devem sofrer interferência. Uma missão é passada e será entregue. E quem passa a missão?

O Product Owner (P.O.).

Em um artigo da InfoQ/BR é citado como funções do P.O.:

• 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.

O artigo segue falando: “A efetiva contribuiç?o do ProductOwner (PO), como se vê, é um fator chave para o sucesso do projeto.”

O P.O. seria o contato da equipe com o mundo. Ele seria responsável por saber o que deve ser construído, saber particionar esse todo em partes menores e estar disponível para acompanhar o desenvolvimento para tirar as dúvidas dos desenvolvedores.

Resumindo: é alguém que conhece o todo do problema antes do início do projeto e que a partir dali mesmo segue até o fim acompanhando o time de desenvolvimento. Esse é o que eu chamo de “PO imaginário”.

“PO imaginário” é como um amigo imaginário. Como o Haroldo, que anda com o Calvin nos quadrinhos. Alguém que seria ótimo se existisse mas que, infelizmente, não existe. Digo, ótimo no ponto de vista da “terra prometida” que citei anteriormente.

Com um P.O. desse tipo, os desenvolvedores não precisariam conversar com mais ninguém, não precisariam prestar contas para mais ninguém, nunca teriam dúvidas (pois existiria alguém em tempo integral para saná-las) e que seria o culpado caso o projeto desse errado. Afinal, era dele a responsabilidade de determinar o que deveria ser feito.

Qualquer um que já trabalhou em um projeto que lidasse com um domínio de negócio minimamente complexo sabe que da mesma forma que o trabalho de desenvolvimento é gradual, o trabalho de compreensão do que deve ser construído também é gradual.

Um projeto que atenda duas pessoas terá duas visões do que é correto, do que é mais produtivo, do que é realmente o negócio. Aumente o número de pessoas, aumentam o número de visões. Aumente o número de áreas de negócio que o sistema irá atender, aumenta o nível de complexidade.

Por exemplo: um sistema financeiro de uma empresa atende um grande número de tipos de necessidades, desde entrada de dados até a visões dos mesmos. Cada parte da área financeira tem sua visão particular do negócio. E mesmo os gestores, que teoricamente têm a visão do todo, muitas vezes não têm o conhecimento aprofundado de cada parte.

Unir esse conhecimento em uma proposta que atenda a todos é praticamente compor um tratado de paz entre nações onde cada povo quer sair com necessidades atendidas e cedendo o mínimo possível.

Se o sistema tiver que atender o financeiro e o setor de pessoal, a complexidade aumenta exponencialmente. A visão de um departamento do que seria um “funcionário” é totalmente diferente da visão do outro setor. Porém as duas terão que conviver de forma harmoniosa dentro do domínio, permitindo que a informação flua da maneira mais natural possível.

Obviamente a resposta fácil para isso é “só dividir o problema em problemas menores”. A questão é que para dividir é necessário compreender. E essa compreensão leva tempo, demanda esforço e, principalmente, muita interação e negociação.

Esse trabalho começa (ou deveria começar) muito antes de qualquer codificação. Normalmente dura até após a entrega, pois é a manutenção desse “tratado de paz” que irá garantir que todos os envolvidos estão sendo atendidos corretamente. Isto é, à medida que o negocio muda, alterações ocorrerão. E elas deverão atender a todos os interessados.

Esses são chamados de stakeholders, que são todos aqueles que serão atingidos direta ou indiretamente pelos mesmos. Os usuários de cada funcionalidade, os gestores que receberão visões dos dados, os setores governamentais que serão atendidos pelas informações fornecidas pelo sistema, todos eles são stakeholders.

Acreditar que um P.O. é simplesmente um perito que pode ser pinçado diretamente da área de negócio para um projeto de desenvolvimento é uma falácia porque, como citei anteriormente, o mesmo terá uma visão particular do todo. Essa visão não necessariamente será a mais correta, ou melhor dizendo, a que melhor atenderá as necessidades dos stakeholders.

Várias áreas, comitês de P.O.s?

Talvez seja a solução, mas mesmo assim será necessário fazer acordos, alinhar jargões, criar artefatos que permitam que as pessoas não só percebam a visão do negócio que está sendo construída bem como aprovem a mesma.

E que viabilize perceber os pontos de mudança (e seus impactos) quando o negócio se alterar. Um estudo recente da Harvard Business Review mostrou que entre os mais de 1.400 projetos pesquisados, uma média de 27% extrapolaram o orçamento. Muitos poderão dar diversos motivos para isso (você encontra vários deles no link do estudo).

Defendo o seguinte motivo: superestimamos a tecnologia. Subestimamos a complexidade do negócio. Se não sabemos o que deve ser feito, nunca faremos corretamente, nunca atenderemos as necessidades, nunca chegaremos aos objetivos.

Aí chegamos a mais três verdades inconvenientes:

• Muitos falarão que através de interações e refatorações chegaremos a uma visão que atenda a todos. Isso seria muito bonito se o custo não fosse problema. Muitos pregam que o desenvolvimento não seja orientado a projeto, e sim uma ação permanente que só acaba no infinito. Porém isso está longe de acontecer. Ainda trabalhamos e trabalharemos por um longo tempo orientados a projetos que têm custo e prazo. Diante disso, quanto mais conhecermos do nosso alvo, mais fácil será de estimá-lo.
• Refatorações de domínios complexos têm custo muito mais alto do que se advoga por aí. Não devemos abrir mão das mesmas. Se escorar na possibilidade de resolver todas as divergências por tentativa e erro é praticamente garantia de fracasso. Digo isso porque entregas desse tipo seriam uma espécie de tentativa e erro sem previsão de fim, o que levaria ao cancelamento do projeto muito antes de chegarmos a uma versão do software que atenda a todos.
• Domínios que sofrem muitas alterações são diferentes de domínios que não são bem compreendidos. Me expressando melhor, é muito fácil dizer que um usuário não sabe o que quer quando não gastamos um mínimo de tempo tentando entender as necessidades dele. E nos casos de vários usuários ou várias áreas de negócio, quando não gastamos um mínimo de tempo tentando compreender o todo.

Um P.O. real deve ser construído, ou melhor, deve se construir, pois além de absorver o negócio precisará muitas vezes negociar uma nova visão do mesmo com os stakeholders e após esse momento transmitir esse conhecimento para a equipe.

Essa transmissão – Stakeholders > P.O. > Equipe – é complexa, e infelizmente muitos clientes não terão uma relação pessoal com todas essas habilidades, nem a disponibilidade para assumir o papel de um “P.O. real” efetivo.

Espero que estejam gostando.

Aguardem a continuação do artigo e até o próximo!