MINI GUIA DE SOBREVIVÊNCIA DO(A) PRODUCT OWNER

“Uau! Agora vou ser Project Owner, ou melhor, Product Master… Não, não, é Product Owner, e ouvi alguém chamar isto de piou.”

Nos processos de difusão dos métodos ágeis, um fato bastante comum consiste em pessoas das áreas de negócio “caírem” no papel de Product Owner. Estes felizardos representantes dos usuários classificam-se geralmente em dois tipos: aqueles que já escreveram algum tipo de especificação funcional para TI e os que nunca o fizeram.

Inicialmente, vamos focar no primeiro tipo.

Acredito que você, Product Owner neófito, passou ou passará em breve por algum treinamento provido por sua organização, pelo menos fornecendo uma visão geral do Scrum e, por consequência, do que se espera do Product Owner. Apenas revisando, ou resumindo, as principais atribuições deste papel são:

• Atuar como representantes do negócio, identificando e listando requisitos de produtos que tragam valor à organização
• Priorizar tais requisitos, constantemente
• Detalhar os requisitos, na forma de user stories
• Participar de cerimônias (reuniões) do Scrum, interagindo com a equipe implementadora dentro e eventualmente fora delas
• Validar as entregas, aprovando, rejeitando ou propondo alterações nos itens implementados, em nome do máximo benefício ao negócio
• Manter os olhos no retorno do investimento das entregas, mexendo na ordem e no teor do conjunto de requisitos, decidindo o ponto em que o projeto deve terminar (quando o conjunto for totalmente atendido ou quando o ganho marginal da próxima entrega priorizada não compensar o investimento)

Antes de mais nada, você deve entender muito bem a lista acima. Se ficar alguma dúvida, por menor que seja, você deve procurar o(s) agente(s) de mudança que esteja(m) difundindo o ágil na sua organização para esclarecimentos conceituais e operacionais.

Após este primeiro e importante passo, seguem dez recomendações baseadas na prática:

1 – Tenha muito clara a visão do projeto

Quais são os benefícios esperados do projeto? Ele tem real chance de trazer valor efetivo para a empresa? Há algum fator crítico de sucesso ou uma condição crucial que se não for cumprida / atendida invalida o esforço do projeto ou impede o lançamento? Se você consegue responder bem a estas perguntas, estamos bem. Senão, reveja os pontos.

2 – Descubra um nível adequado de pulverização das user stories

A user story é o artefato onde o Product Owner explica o requisito. Uma boa user story é pequena (implementável em até três dias, para sprints de duas semanas) e tem uma entrega clara, validável. Atenção para a questão da entrega validável! Um problema recorrente é a equipe construir um item relativo a uma user story que não constitui uma entrega que o usuário possa usar e averiguar se está OK. Para ser mais claro, uma entrega é uma tela de cadastro, um cálculo verificável, um relatório, uma consulta, algo operacional. Um webservice, por exemplo, não é por si só validável pelo usuário com facilidade (se você não sabe o que é um webservice, ótimo, talvez seja até melhor não saber). Se a entrega não for algo que você possa abrir no seu computador e fazer funcionar, mexendo como usuário, então não é adequada para a sua validação.

3 – Planeje um espaço no seu dia a dia para focar na composição das user stories

Sua empresa adota o home office em alguns dias da semana? Você está nesta? Que bom, pois um ótimo lugar para escrever uma user story é longe das interrupções e distrações do nefasto escritório. Recolha as informações necessárias e no conforto de seu lar produza lindas stories.

Caso não seja possível o home office, isole-se em algum recanto do escritório mesmo e dê foco.

4 – Use o mais possível diagramas e desenhos nas suas user stories

“Uma imagem vale mais que mil palavras”. Se você puder fazer um fluxograma ou um desenho que explique o requisito, isto poupará muitas linhas escritas e dores de cabeça. Nem vou falar da necessidade de prototipar as saídas (desenhar a tela, o layout do relatório). Isto precisa ser feito. Se não conseguir fazer em meio eletrônico, faça em um papel de pão, mas faça. Ajuda se houver um padrão visual estabelecido, mas não fuja de esboçar da melhor maneira possível como é a saída que você quer.

5 – Use linguagem estruturada nas suas user stories

Admitamos: o analfabetismo funcional impera. Tenho visto pessoas nas empresas com nível universitário, que até conhecem bem o negócio, mas que na hora de escrever um simples parágrafo, têm muita dificuldade.

Alguns, é claro, nascem com o dom da escrita e/ou tiveram uma boa formação em língua portuguesa. Conseguem elaborar textos que fazem sentido, com lógica, sem ambiguidades, com clareza, completeza, concisão, começo, meio e fim. Conseguem expressar causa e efeito. Conseguem, enfim, escrever algo compreensível.

Mesmo para estas pessoas bem formadas, vale fazer uso de uma estrutura de texto “itemizada”, com frases curtas. Expresse uma necessidade por parágrafo, cada um com no máximo três linhas. Transforme o mais possível sua story em uma lista. Identifique claramente os agentes (quem), as ações (o quê), o encadeamento das coisas (quando) e dê um toque final, comedido, com pitadas de porquê.

6 – Participe com carinho ou faça acontecer groomings com a equipe implementadora

O chamado grooming é uma reunião onde os requisitos (e as user stories) são previamente discutidos e refinados com a equipe de implementação (antes de serem apresentados em um sprint planning).

Esta ação de engenharia simultânea (para usar um termo do Lean) é muito recomendada e facilitará a vida de todos. A equipe de construção pode ajudar a lembrar de detalhes relevantes e a discussão prévia contribuirá com uma melhor compreensão da story.

O grooming ajuda também na pulverização (quebra de stories grandes) e na adoção do nível de detalhe bom para a equipe (nem acima, nem abaixo).

A grande questão aqui é como arrumar tempo para fazer esta atividade! Aí está um ótimo desafio para a equipe autogerenciada (como bem preconiza o ágil) arrumar um jeito.

7 – Evite validações superficiais, preparando-se para elas

Validar uma entrega não é testar. O item (pelo menos em tese!) já foi muito bem testado e está pronto para a apreciação do Product Owner. O pronto, na conceituação do ágil, é uma condição tal que a entrega esteja validável (construída, testada, integrada e colocada no ambiente combinado).

Então, na review, você deverá validar se o item foi construído de acordo com a story. Pode ser que, neste momento, você perceba que até foi, mas que faltou algo na story. Não se penalize muito – isto é parte natural da dinâmica do ágil e o que você deve fazer é abrir um item de mudança para ser feito em sprint futuro (pode ser no imediatamente seguinte – você define a prioridade, lembra?).

Para fazer uma boa validação, pense em cenários. Mexa no item entregue fazendo um cenário de uso “caminho feliz” (o uso direto e reto, sem exceções) e também executando cenários com situações especiais, menos comuns, exóticas, porém possíveis de acontecer um dia – tudo à luz do negócio. Aí sim haverá uma boa validação, gerando as mudanças que se mostrarem necessárias, se for o caso.

Assim sendo, traga os cenários para a review e nada de pressa em encerrar esta reunião.

O mais possível, lembre-se das situações de exceção já na confecção das stories. Afinal, a equipe de implementação não consegue adivinhar regras de negócio e a forma, óbvia, de ter todas as situações possíveis implementadas no produto é dizer à equipe quais são elas.

8 – Alinhe os requisitos com todos os stakeholders de negócios

O Product Owner é o representante do negócio no projeto, portanto ele deve trazer a posição consensual dos usuários para as stories.

Sabe aquele usuário chave, com alto poder de influência, que estava de férias e que quando voltou viu um item implementado e o modificou integralmente porque não foi consultado antes? Então, fuja deste tipo de situação. Busque o consenso com todas as partes antes de fechar as regras de negócio e passar para a equipe de construção.

9 – Procure adquirir sensibilidade de estimativas de esforços

Confiança é um valor do ágil. E confiança se conquista com visibilidade, transparência. Muitos elementos do ágil estimulam isto. No sprint planning, por exemplo, a equipe dá uma estimativa para cada story na frente do Product Owner. Desta forma, este último presencia a carga do sprint, reduzindo sua insegurança quanto àquela velha questão do “será que estão colocando pouca coisa para ficarem folgados”?

Com o tempo, você deve começar a entender o tamanho relativo de cada story. Deve começar a “sacar” o que é uma story de tamanho X ou Y. E poderá até esclarecer dúvidas com a equipe na hora da carga.

10 – Cultive um mindset de trabalho cooperativo

O ágil visa desmantelar silos e neutralizar fronteiras, fazendo desenvolvedores e usuários trabalharem juntos. Então, qualquer ímpeto de “nós contra eles” deve ser evitado. Todos estão no mesmo barco! Para ilustrar como é feia a não colaboração, listo abaixo exemplos de frases reais, saídas das bocas de Product Owners, que recomendo que você prometa que nunca vai repetir:

• “Isto é um problema para TI resolver”
•  “Eu não vou perder tempo escrevendo uma story de TI” (frase típica em ambientes onde quem escrevia as especificações no passado eram pessoas de TI, não de negócio)
• “Mas isto está subentendido! Por que não implementou?”

Finalmente, se você “caiu” no papel de Product Owner e nunca escreveu nenhum tipo de especificação, então acrescente às recomendações acima mais uma: peça exemplos ou modelos de user stories consideradas boas e as estude bem. Observe a estrutura e a linguagem, tentando fazer algo ainda melhor, cada vez mais afinado com as boas práticas de análise de negócio.

Que esta pequena contribuição possa ajudar no exercício deste papel tão fundamental que é o de Product Owner, o administrador de valor para o negócio!

Roberto Pina Rizzo
MSc, PMP, PMI-ACP, SAFe Agilist
Lean Agile Change Agent / Gestor Senior de TI