Antonio Carlos Silveira, um dos mais novos gerentes do
Yahoo! Brasil, apresentou uma palestra com o tema
O Product Owner e o Product Backlog. Pra variar, ele também é um dos caras que já trabalhou na
Globo.com, e que ajudou a empresa a utilizar Scrum, tornando-se o maior case de utilização no Brasil. Minha impressão:
a melhor palestra do evento Tudo começa com uma brincadeira muito boa. No dia anterior, o Guilherme Chapiewski apresentou um pouco da atuação dos líderes Ágeis na Globo.com e é claro, mantendo a imagem de uma empresa massa pra caramba!(Foi muito massa a palestra, logo escrevo um pouco sobre ela).
Mas, mantendo seu compromisso principal com a verdade, o Antonio Carlos mostrou como é realmente o trabalho na Globo.com: A competitividade é acirrada!!
A intenção da apresentação era realmente esclarecer o conceito de Product Owner, e o artefato Product Backlog do Scrum. O nome em si não importa, mas os princípios por trás dos papéis e dos artefatos.
Alegoria interessante:
Uma equipe Scrum é formada por:
Tradicionalismo x Agilidade - De onde viemos e Para onde vamos
Tradicionalmente, principal missão de um Product Manager era se antever e prever futuro. Mas Por quê? A fórmula é simples:
- Se antecipar aos acontecimentos de um projeto pode reduzir incertezas
- Reduzindo incertezas provavelmente diminuirá a quantidade de Change Requests
- Como Change Requests são caras, reduzir sua ocorrência certamente diminuirá o custo do projeto
Surge a figura de um Product Manager carrasco, que não se importa com a saúde das equipes que trabalham para ele, e está mais preocupado a cumprir um cronograma custa o que custar.
Não existe, neste ambiente, uma preocupação em adaptar-se à mudança, mas em restringir a mudança. Antecipar-se é o principal foco deste modelo, mesmo que o nosso mundo esteja seguindo na direção contrária. AC atribuí a isso uma espiral negativa dentro das empresas: setores de tecnologia querendo restringir mudanças devido aos custos elevados, e os setores de marketing buscando adaptar os produtos aos mercados.
Este é o principal motivador para o crescimento de métodos Ágeis. Assim, o que queremos é a agir rapidamente a qualquer Request de mudança. Ao invés de criar procedimentos para restringir mudanças, precisamos abraçar as mudanças adaptando-se o mais rápido possível.
O Product Owner
O papel do PO primeiro de tudo é: Ele precisa entender o Cliente 
Ele precisa responder às seguintes perguntas:
- Qual o seu Target ?
- Quem é o seu público alvo?
- Quais são as personas? (dica do Danilo Bardusco)
- Quem se quer atingir?
- Por que um cliente gastaria dinheiro com o seu produto?
Além disso também, o cliente é uma Ponte entre os Clientes e o Time, inclusive na hora de buscar mais informações quando seu conhecimento do domínio do problema não é completamente compreendida. Assim, ele facilita o contato entre o Business e o Desenvolvimento.
Existe sempre uma tenção entre este PO e a equipe. Em métodos Ágeis, TUDO é baseado em confiança. E qual o paradoxo desta realidade: estamos num mundo em que confiamos muito poucos uns nos outros, e desenvolvimento Ágil para funcionar precisa muito de confiança.
Espiral negativa da vez:
- PO não confia no time, porque normalmente não recebe o que solicita. Assim, o que ele faz? Atola a equipe de solicitações, na esperança de ganhar alguma coisa "do balaio"
- A equipe sabe que o PO vai pedir mais do que eles conseguem produzir. Como sair dessa? Estimar cada vez mais tempo para completar as tarefas...
É isso que precisa ser mudado para que um ambiente ágil seja produtivo. Transparência é a palavra de um projeto Ágil. Inclusive, para que se entenda melhor essa alegoria. Imagine um projeto scrum como um barco: Se ele afundar, vai todo mundo pro buraco.
- O PO pode ser técnico? Não necessariamente. Primeiramente, o PO precisa entender a equipe: sua capacidade de produção. Precisa entender que não é apenas empurrando trabalho para a equipe que mais software vai ser entregue. O Danilo Bardusco já escreveu sobre isso.
É necessário criar um ciclo virtuoso em que:
- O PO entender as necessidades de esclarescimento da equipe.
- Estimula a equipe no limite, para que ela consiga se comprometer e produzir o melhor produto. Tendo orgulho do que faz.
- Sabe que um número, que a preocupação apenas com produtividade não trará o resultado esperado.
- Trás um ponto de vista para a equipe que agregue valor para a equipe
PO: Cria a Visão
O PO precisa pintar uma imagem bonita, para onde todos da equipe queiram seguir. Dois exemplos foram citados:
Disney e
Mirosoft. A primeira empresa cria uma Visão única, que guia todos da empresa, e é um dos motivadores de seu sucesso:
We create happiness by providing the finest in entrertainment for people of all ages, everywhere Na criação desta Visão, o Product Owner deve estar preocupado em conquistar a equipe como um todo. E para isso a visão deve ser:
- Compartilhada e compreendida por todos
- Deve criar o desejo na equipe em fazer parte desta conquista
- Deve ser clara e concreta
- Deve ser difícil de ser alcançada, mas não impossível
Você é o product owner de um projeto? Qual a visão do seu software? e a equipe, entende essa visão?
PO: Entende o domínio do Problema e da Solução
Deve ser a referência sobre o Domínio do problema. Ele deve ser o ponto focal para a equipe, quando ela estiver em dúvida. E pra isso ele deve ter poder de decisão.
Receita para o fracasso:
Um product Owner que nunca decidiu nada. Criando a "Síndrome para o PO Mensageiro": Se para tomar qualquer decisão o PO precisa se comunicar com alguém para pedir a opinião, o problema está formado. Quais as consequências disso?
- Equipe vai desconsiderar o papel do PO, indo diretamente à pessoa que decide.
- O Time passa a tomar decisões. Se sentindo no direito de tomar as próprias decisões sobre o produto.
É necessário que o PO imponha respeito à equipe. Tudo que está sendo dito aqui é sobre pessoas, e a interação entre elas. Esqueça ferramentas! O que importa é a relação entre esse as pessoas, a maneira como você interage com elas. Comunicação Oral é o principal! Lembre-se disso: ferramentas não vão substituir o sucesso da interação pessoal entre as pessoas. (Repetitivo? náá)
Além disso, é obrigação do PO aceitar o que for produzido pela equipe. Para isso:
- Deve estar presente para esclarecer dúvidas (deve estar próximo)
- Deve avaliar o que for produzido
Aqui, o AC indica um estudo bastante interessante: A universidade de Michigan descobriu (há quase 10 anos), que equipes multiciplinares juntas produzem mais que o dobro do que equipes separadas por salas, predios, etc. 
Leia a notícia
Nota importante: é o PO que organiza o Release Plan para o produto. Ele que encontrará o melhor momento para lançar uma versão nova do produto.
PO: Responsável pelo ROI
Sim!!! Retorno sobre investimento!
É o foco do PO! Normalmente relacionado a dinheiro. Mas não necessariamente o dinheiro em si. Acima de tudo, ROI deve estar ligado a um objetivo mensurável:
- Dinheiro
- Audiência
- Satisfação do Cliente
- Fidelidade
PO: Responsável pelo Product Backlog
Resumindo o que apresentamos acima: O Product Owner tem como função?
- Entender o Cliente
- É o elo de comunicação entre os Clientes e a Equipe
- Entender do domínio do problema e principalmente possui o poder de decisão sobre o projeto
- Aprova/Rejeita o resultado do Sprint
- Responsável pelo Release Plan
- Responsável pelo ROI
- Responsável pelo Product Backlog
Lembrando que: Product Backlog é uma lista priorizada (em qualquer mídia) e ordenada com coisas que trarão algum benefício para o usuário.
Como descrever itens do backlog? User Stories!
AC ainda explicou sobre a profundidade na elaboração do Product Backlog, já explicado na apresentação: 10 ways to screw up with Scrum and XP. (Numa imagem muito bonita: 3D, tons pastéis, Estrelinha e um "r" no logo!)
O que define um bom Product Backlog?
- Está Planejado adequadamente para os próximos 3 Sprints, ajudando o time a ter uma visão maior sobre para onde estão indo.
- Sempre priorizado. Para que a equipe consiga escolher sempre o item mais prioritário
- Sempre visível: Isso trás transparência
- Deve ser mantido pelo Produtc Owner (não é função da equipe priorizar o Backlog)
Priorização
Foram citados os modelos de priorização:
Principal Bibliografia Ágil sobre o assunto: Agile Estimating and Planning por Mike Cohn
No Modelo de Kano, deve-se categorizar o product backlog através do valor percebido pelo cliente. Em três categorias:
- Must-have: Obrigatórios (Um hotel deve ter cama)
- Linear: Quanto mais melhor (Cerveja grátis no quarto do hotel - ótimo )
- Exciters: Necessidades não conhecidas (TV de LCD 42'' no Quarto - ótimo, mas não faz tanta diferença)
Para cada item do Backlog, faça duas perguntas:
- Funcional: O que vc acha de ter uma Latinha de cerveja de graça no quarto de hotel, quando vc chegar?
- Disfuncional: Se você chegar num hotel e não tiver uma latinha de cerveja de graça no quarto, o que vc acha?
No método de Benefício Relativo é necessário, primeiramente, que as estórias estejam estimadas. Após isso, preencha a seguinte tabela:
| Benefício em ter | Penalidades em não ter | SUM(BV) | Estimativa | BV/Est |
|---|
| Funcionalidade 1 | 1 | 9 | 10 | 2 | 5 |
| Funcionalidade 2 |
|
|
|
|
|
| Funcionalidade 3 |
|
|
|
|
|
| Funcionalidade 4 |
|
|
|
|
|
A Ordenação se dá pela coluna BV/EST
Mesmo sendo um método bastante interessante, em sua experiência, Antonio acredita que no final é o chutão que conta. A Utilização de personas pode ajudar bastante.
É isso... Esses relatórios estão ficando bastante extensos... mas espero ter passado a idéia da apresentação... aos que não assistiram...
Antonio: Parabéns pela apresentação!
(
Acompanhe as impressões dele sobre o evento, além inúmeras referências)
Tomei a liberdade de adicionar neste blog os slides da apresentação (sem autorização,
desculpe!). Aproveite:
