Esse é o segundo artigo que escrevemos sobre as disfunções do papel de Product Owner. No primeiro, resumimos o papel do PO e explicamos por que preferimos chamar de disfunção ao invés de erros.
Naquela edição falamos mais sobre as disfunções que as organizações causam quando não compreendem o que o Product Owner (PO) deveria fazer. Neste artigo, o nosso foco será nas disfunções que a personalidade e características das pessoas causam enquanto desempenham essa função.
Ouça este conteúdo:
Disfunções quanto à entrega de produto/serviço
A primeira categoria de disfunção está relacionada à entrega de produtos e serviços para o cliente final. O time trabalha, com muito suor, sangue e lágrimas, mas na hora de concretizar o resultado, marcar o gol, algo acontece e aquele lindo incremento não vê a luz do dia.
PO Freio de Mão Puxado
A vida é dura e esse PO já teve experiências ruins. Provavelmente já foi punido por disponibilizar alguma coisa que não deu muito certo, talvez tenha até sido demitido. Isso pode ter criado nele um medo, quiçá pânico, de disponibilizar produtos para os clientes.
Ele quer ter certeza de que nada vai dar errado e para isso deseja que todos do time garantam que tudo irá funcionar. Se possível, o PO espera que o chefe autorize e que o chefe do chefe esteja ciente. Normalmente, esse é um comportamento criado por um problema interno e deve ser tratado aos poucos.
Na verdade, o PO não visualiza que quanto mais a entrega demorar, maiores os custos e as expectativas. E, em caso de falha, a dor será tremenda. O PO tem que ter paixão por entregar.
Se for possível entregar incrementos do produto todos os dias, ele o faz. Porque o que importa é receber feedback o quanto antes, coletar métricas de uso e de eficácia e já criar itens para melhor resolver o problema dos clientes.
PO Mestre dos Magos
Você assistiu à Caverna do Dragão nos anos 80-90? Lembra do Mestre dos Magos? Ele era um sábio que aparecia no início do desenho, falava algumas frases bonitas que nenhum dos outros personagens entendia e desaparecia.
Os meninos e meninas que compunham o time que buscava voltar para a casa, passavam o restante do episódio lutando contra hordas de bárbaros, demônios, o Vingador e até Tiamat, a dragoa de 5 cabeças. No final, após vencerem as épicas batalhas, o Mestre dos Magos retornava e dava uma lição de moral vinculando o ocorrido com a frase que ele havia dito no início do episódio.
O PO Mestre dos Magos é parecido. Ele aparece no Planejamento da Sprint (Sprint Planning) para dar os pitacos dele e some durante toda a Sprint. Não sabe o que está acontecendo no time, não vê os desafios que as pessoas estão enfrentando, não está disponível para resolver dúvidas e ninguém consegue encontrá-lo.
No dia da Revisão da Sprint (Sprint Review) ele aparece todo pomposo com frases do tipo: “Não foi isso que eu pedi”, “Por que não falaram comigo? Estava na minha sala (que fica do outro lado da cidade) o tempo todo.”.
O PO faz parte do Time Scrum e precisa jogar junto. Ele deve estar junto do time durante a Sprint tirando dúvidas e vendo o resultado do trabalho no dia a dia enquanto prepara os próximos itens do Backlog.
PO César
O mito do Poder de César tornou-se comum com os filmes de Hollywood que retratam batalhas entre gladiadores no Coliseu de Roma. Você pode até imaginar a cena: um gladiador perde e está caído no chão. O vencedor olha para o imperador que fará um sinal de “joinha”. Se o dedo ficar para cima 👍 o perdedor vive. Agora, se o dedo ficar para baixo 👎, o vencedor tem que matar o perdedor.
O PO César é parecido com o Mestre dos Magos, a diferença é que ele entra na Reunião de Review e tem um comportamento imperial. Ele ou ela olha cada parte do que foi entregue e faz uma avaliação. Como César, aprova as que irão para o cliente 👍 e reprova 👎 as que não gostou.
Você já sabe, mas não custa lembrar: A Sprint Review não é uma reunião de avaliação. Por isso que o PO se senta junto com os Desenvolvedores, para acompanhar o desenvolvimento dos itens e, ao menor sinal de problema, comunicar o que está acontecendo.
O objetivo primário da Sprint Review é coletar feedback de clientes e stakeholders para criar itens de valor e alimentar o Backlog do Produto. Inspeção é constante, diária e colaborativa.
Disfunções relacionadas à escolha do Product Owner
O Product Owner é um papel interessante. Toda experiência prévia que você teve na sua vida pode te auxiliar a desempenhar bem as responsabilidades dele. Entretanto, se não analisarmos adequadamente o perfil da pessoa, podemos acabar com algumas disfunções.
PO Técnico
Ter um passado na área técnica de desenvolvimento de produtos não é um requisito, mas não precisa ser um problema. Infelizmente é difícil se desvencilhar de velhos hábitos.
Digamos que a pessoa tenha sido uma desenvolvedora de software a vida toda. Ela sabe fazer e o faz muito bem. Quando ela ouve um cliente falando sobre um problema, ela já imagina como construiria o software para solucionar o problema. Daí podem vir algumas disfunções.
Sem problemas, apenas soluções
Os itens de valor ao invés de serem escritos com o ponto de vista do cliente, acabam sendo escritos do ponto de vista técnico. O cliente não entende o que será feito e os desenvolvedores ficam amarrados à solução que já foi dada.
Vamos dar um exemplo: Digamos que o cliente deseja ser avisado toda vez que seu próximo voo sofra alguma alteração. O PO Técnico escreve então a seguinte História de Usuário (User Story): Eu, enquanto Maria Passageira, desejo receber um alerta pop up no meu computador para que eu seja avisada das alterações do meu voo.
O primeiro desafio será explicar o que é um alerta pop up para o cliente e porque ele deve aparecer. Segundo, o time fica ancorado à solução que já foi dada pelo PO Técnico. Agora, eles vão criar um alerta pop up, pois foi exatamente isso que foi pedido.
Muito melhor seria: Eu, enquanto Maria Passageira, desejo ser alertada de alterações no meu voo, pois não quero perdê-lo. O problema está claro: Ela não quer perder o voo. O cliente compreende com mais facilidade. O mais importante, a solução não está amarrada à visão de uma pessoa. Os desenvolvedores podem pensar juntos qual a melhor solução: pop up, SMS, WhatsApp, mensagem no aplicativo, e-mail etc.
Apegado ao passado
Outro problema que acontece quando o PO não consegue separar sua antiga carreira técnica da atual, mais focada nos negócios, é fazer o FDP do PO de forma disfuncional:
- Fatiar olhando as camadas técnicas ao invés de utilizar uma visão de negócios;
- Priorizar itens de acordo com a complexidade técnica ao invés do valor que os itens entregam para o cliente;
- Descartar itens difíceis de construir, mas que são vitais para a sobrevivência do negócio.
Deixe-me dar uma mãozinha
Nada está tão ruim que não possa piorar. Se o PO Técnico resolver meter a mão na massa e partir para a construção, teremos um problemão.
Quem está capitaneando o barco se o capitão está no convés? Quem está olhando as métricas? Fatiando as próximas histórias? Conversando com os stakeholders? Tratamos este problema na primeira parte deste artigo: PO Chapeleiro Maluco.
PO Cliente
Conflito de Interesses
Nos primórdios do Scrum, muitos acreditavam que o PO deveria ser o cliente (representante da empresa contratante ou unidade usuária). O grande problema é que nem sempre havia o interesse dessa pessoa em se tornar PO e a coisa se tornava um caos.
Há um conflito de interesses que não era tão claro em uma primeira olhada. Se o PO é o cliente, ele forçará o time a fazer todas as vontades dele, sejam elas importantes ou não. Esse representante tentará fazer que o contrato seja extremamente vantajoso para a empresa dele.
Funções distintas na empresa e no projeto
Outra coisa que normalmente acontecia era que essa pessoa era eleita e tinha que desempenhar duas funções. Na empresa ou unidade usuária ela era o Gerente de Vendas, por exemplo. Para o projeto ela era PO.
Fazendo um rápido exercício de empatia, se você estivesse no lugar dela, você daria preferência a ser Gerente de Vendas (que paga o salário dela) ou ter um papel que você nem sabe o que é, como faz, onde vive e de que se alimenta? O Raphael Sabbagh escreveu o artigo Polêmica: o melhor Product Owner NÃO é o cliente em 2014 para tratar exatamente desse assunto.
PO representando todos os clientes
O risco do PO ser um representante específico do cliente é que ele tentará impor sua visão do produto. O Time pode criar um produto que sirva apenas a ele e ignore o resto dos clientes.
O autor que vos escreve já passou por isso. A sensação de derrota é horrível. Na sala fica uma pessoa feliz (representante que foi o “PO”) e todo resto bicudo — incluindo seu time, que vai “apanhar” de todos os outros clientes. Em parte, porque o papel do PO é conversar com todos os outros clientes.
PO Garçom / PO Proxy
Logo quando se percebeu o problema de que o cliente não era o melhor PO, criou-se uma figura que ainda existe em muitas empresas que é o PO Proxy, também conhecido como PO Garçom. Ele vai até o cliente, o cliente fala o que deseja, ele escreve o pedido do cliente exatamente como foi feito e passa para o Time (cozinha).
Não faz nenhum tipo de avaliação, não olhas as métricas, não verifica se o que foi pedido poderá resolver o problema ou piorá-lo, não vê o que a concorrência está fazendo, nem olha para as expectativas dos outros stakeholders. É um leva e traz. O cliente pede, ele repassa para os desenvolvedores. Os desenvolvedores perguntam, ele repassa a pergunta e assim vai.
O trabalho de PO é um trabalho sério e requer muita capacidade de análise de necessidade e síntese de soluções. Fique com a famosa frase atribuída a Henry Ford: “Se eu tivesse perguntado às pessoas o que elas queriam, elas teriam dito cavalos mais rápidos”. Atenção. Isso não quer dizer que o PO não deve ouvir clientes e demais stakeholders. Ele deve conversar com eles sempre, só que a habilidade de analisar o contexto e propor soluções cabe a ele e não ao cliente.
Disfunções de Personalidade do Product Owner
A nossa personalidade tem uma grande influência naquilo que fazemos. Um bom PO tem que ser comunicativo, saber analisar contextos, validar hipóteses, fatiar problemas, compreender métricas, priorizar itens de valor, manter o Product Backlog e muito mais. Nem sempre encontramos pessoas compatíveis com essas responsabilidades. Vamos a algumas disfunções quanto à personalidade do PO.
PO Smeagol
Lembra quando você jogava bola na rua ou em algum campo de várzea e o time do dono da bola estava perdendo ou quando colocavam ele em alguma posição que ele não gostava, que ele pegava a bola e ia embora encerrando a partida?
Pois bem, há POs que têm o mesmo comportamento. O Backlog é dele, ninguém dá pitaco. Toda sugestão já tem um não como resposta ou quando muito aquele: “vamos ver” que nunca chega.
Precisamos deixar claro que somos um time e time joga junto. Temos que confiar uns nos outros e ter consciência que nenhuma pessoa sozinha é mais inteligente do que o coletivo.
O PO é o responsável pelo Backlog, mas seu trabalho será muito mais proveitoso se ele contar com a inteligência do time todo. Aliás, o bom PO conta sempre com a ajuda de todo time para o bom desempenho da sua função.
PO Tudo é Prioridade
PO que não sabe priorizar os itens de valor. Na K21 temos um lema que estampa um dos nossos principais adesivos:
Não existem dois itens com a mesma prioridade. Se o Backlog do Produto tem 10 itens, então cada um deles tem uma prioridade. Algumas fontes do Tudo é Prioridade podem ser:
Backlog Gigante Guerreiro Daileon / Megazord
Você chega em um time e pede o backlog deles. É aberta uma planilha ou um software de gestão de backlog com centenas ou milhares de itens. Dá preguiça só de olhar, quanto mais ler cada um dos itens.
Mantenha um backlog enxuto. Recomendo métricas como Aging para descartar itens antigos e evitar backlogs monstruosos.
PO sob pressão
Como diz o meme: “É raro, mas acontece muito“, o PO é pressionado pela gerência, cliente e até mesmo pelo próprio time. Se ceder, tudo vira prioridade e então passa a valer a máxima: “Se tudo é prioridade, nada é prioridade”.
É um trabalho que exige certo sangue frio e muita gestão de expectativas para evitar ao máximo essa disfunção.
PO Hardy Har Har
O jogo nem começou e ele já vê a derrota. Zero empolgação com o produto, fica de cabeça baixa quando conversa com os stakeholders. Quando vai falar com o time é a cara do Livro das Lamentações. Ele chega no trabalho, olha para o time e exclama:
Por que saí do ventre materno? Só para ver dificuldades e tristezas, e terminar os meus dias na maior decepção?
Jeremias 20.18 (NVI)
O PO tem que ser uma pessoa empolgada e apaixonada por resolver o problema do cliente. Se a moral dele for baixa, o time também terá uma moral baixa e tudo ficará mais difícil. Vai precisar de um baita Scrum Master para levantar essa moral e uma mega batalha pelo coração do time.
PO Imortal
Não é que ele tenha desejado ser poderoso, mas aconteceu. Ele é o herói que mata no peito e resolve os problemas. Infelizmente, com isso, o Time se acostumou: “deixa que o PO resolve”.
Como crianças que precisam de acompanhamento constante, o PO se torna a mãe ou pai do time. Se tira férias, o telefone toca toda hora. Se fica doente, recebe aquelas mensagens: “olha, eu sei que você está doente, mas…”. Se morre, o time faz uma sessão espírita para invocar o PO. Afinal, ele ou ela tornou-se insubstituível.
A princípio é bacana ser reconhecido como herói, mas, depois, o peso do heroísmo vai dragar todas as energias desse PO que irá para o esgotamento físico e mental. As causas do heroísmo podem ser muitas, mas a mais comum é quando o PO acaba agindo como a pessoa do meio.
Ele fala com as pessoas de negócio, “traduz” para os desenvolvedores e vice-versa. Isso infantiliza os desenvolvedores que nunca terão contato com o negócio e não se apropriarão do contexto em que estão atuando. Enquanto PO, parte do seu trabalho é fazer com que o time entenda o contexto em que está inserido, saiba quais resultados eles estão gerando e consigam administrar o Backlog na sua ausência. Voltemos ao Guia do Scrum:
“O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o Product Owner ainda é o responsável.” (Guia do Scrum, p. 7).
Ou seja, você é o responsável, mas pode delegar as suas atribuições para outras pessoas quando necessário. Se o time for imaturo com relação ao negócio e a comunicação com o cliente, a delegação será muito difícil.
PO Fofoqueiro
Detona os stakeholders para o Time Scrum. Fala mal deles, os culpa por tudo que dá errado, faz piadinha. Com isso, o Time passa a ver esses stakeholders não mais como pessoas que devem ter seus problemas resolvidos, mas como inimigos que devem ser combatidos.
Quando está com os stakeholders, o comportamento é o oposto — tudo é culpa dos outros membros do Time. Esse é o tipo mais difícil de personalidade para desempenhar o papel de PO. Ele é o responsável por criar muito atrito, quebrar a confiança entre as partes e construir ambientes internos competitivos. Muitas vezes não é apenas um desvio na função e sim um desvio de caráter. Será que vale a pena tê-lo no time?
Disfunções com relação à escrita dos itens de valor
Uma grande parte do trabalho do PO é escrever os itens que ficarão no Backlog do Produto. Todavia, não existe um padrão. Muitos optam pelo formato de História de Usuário (User Stories), enquanto alguns adicionam informações como os Critérios de Aceitação (sobre este tema veja os artigos Como é a User Story? e Garantia da qualidade com TDD).
Entretanto, sempre fica uma dúvida: Quanto o PO deve detalhar os itens do Backlog? A resposta não é exata e na prática dependerá muito dos desenvolvedores e stakeholders. Há duas disfunções com relação a esse tema (veja a seguir).
PO Escritor
Existem as Histórias de Usuário, mas esse PO escreve Epopeias de Usuário. Cada item no backlog tem 10 volumes e, se impressos, dariam inveja a Marcel Proust (escritor de Em Busca do Tempo Perdido, o maior livro do mundo).
Cada item tem tanto detalhe, mas tanto detalhe, que ninguém lê. Muita escrita (pelo PO), acarreta em pouca leitura (pelos desenvolvedores).
Normalmente também é um PO que não quer fazer modificações no item, porque com tantos detalhes, a mudança irá afetar diversos pontos da epopeia e dará muito trabalho.
Esse padrão é comum em POs que vieram de modelos antigos, que tentavam detalhar todas as necessidades e passar os requisitos por debaixo da porta para os desenvolvedores, sem a necessidade de interagir com eles. Também acontece em times que sofreram alguma falha no passado e a solução proposta (e jamais avaliada) foi: “temos que detalhar mais os itens do backlog”.
Outro possível motivo é o PO que deseja fazer a Documentação Cover My Ass.
O formato de História de Usuário é sucinto justamente para que o PO TENHA que conversar com os desenvolvedores. A função do PO é analisar o contexto, sintetizar propostas de solução, participar da construção respondendo dúvidas e coletar resultados.
PO Mistério
“Nem tanto ao mar e nem tanto a terra”. Uma vez estivemos em uma empresa que os itens do backlog eram demasiadamente sucintos: “Incluir Item”, “Listar tudo”, “Consultar itens pelo nome”, “Relatório para o Cliente”. É claro que uma semana após o time discutir esse “backlog” ninguém lembrava de nada. Você precisa ser um Sherlock Holmes ou uma Miss Marple para descobrir o que deverá ser feito.
Quanto eu devo detalhar?
É difícil definir quanto detalhe deve ter um item de backlog, pois depende muito do time, do cliente e do contexto. Vou contar uma particularidade que gosto de fazer com meus times, todavia, entenda isso mais como uma ideia do que como recomendação.
Eu gosto de colocar 4 informações que ficam disponíveis: a) desde o surgimento do item; b) sem que a pessoa tenha que abrir o detalhamento do item. Se o backlog é apresentado em um formato de planilha, cada informação será apresentada em uma célula.
- Identificador para facilitar referenciamento. Exemplo: US 001, US 002…
- Item escrito sempre no formato de História de Usuário.
- A prioridade é dada pela posição do item no backlog. Quanto mais acima, mais prioritário.
- Métricas Impactadas para acompanhamento do resultado.
Há um quinto item que pode ser acrescentado para projetos enormes: Separar os itens por tema da funcionalidade ou persona impactada.
Quando chegamos mais próximo à construção da história, junto com os desenvolvedores, adicionamos novas informações: 1) Critérios de Aceitação; 2) e um grande espaço para os desenvolvedores escreverem tudo o que acharem necessário: detalhes de implementação, imagens, diagramas, recomendações etc. Nós não utilizamos mais estimativas, mas se seu time utiliza, seria legal acrescentar essas informações também.
Repito mais uma vez, isso é como meu time prefere e pode te dar algumas ideias, mas não quer dizer que funcionará no seu. Teste e avalie o resultado.
Conclusão
As disfunções acontecem meio que de forma natural. Elas são o fruto de experiências passadas e soluções que não foram avaliadas. O melhor que podemos fazer é ficar atentos a elas e, no momento certo, nos adaptarmos às necessidades.
Quer saber mais sobre esse tema? Veja os artigos que indicamos no texto e faça o nosso treinamento de Certified Scrum Product Owner® (CSPO).
