O Dono do Produto

Tão ou mais complicado do que criar o produto – em meu caso, um treinamento – será o trabalho de ‘criar’ uma freguesia para ele. Sei que o FDP¹(Formação de Donos de Produtos) atrairá gente letrada e com experiência em projetos de software. Ok. Entendo que a maioria delas não vai desempenhar o papel e sim apoiar e orientar os profissionais que o farão. O treinamento deve contemplar esta modalidade de uso e o faz². Mas eu também sei que o evento não será legal se não contar com “não-letrados”, gente que não seja de TI e sim do negócio. Este treinamento foi desenhado principalmente para eles, nossos (frequentemente) mal compreendidos e (invariavelmente) mal tratados usuários. Ok, sei que não vou atrai-los com demagogia barata. Antes de mais nada, é preciso explicar melhor quem é esse tal de Dono do Produto (ou Product Owner), o que ele faz, como, porque etc. É o que tento com este artigo.

.:.

O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

Um DP por Projeto – Um Projeto por DP

Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

Colocado e Falante

De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

O Passo Esquecido

Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

Os Passos Executados

Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

Aos Donos com Carinho

Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

.:.

Observações:

1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

Faltou dizer:

Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!