Livro The Professional Po Ingles

Machine Translated by Google
O Guia do Proprietário do Produto Profissional para

Maximizando valor com Scrum
“Este livro apresenta um método de comunicar nossos desejos, de forma
convincente, coerente e com o mínimo de confusão e incômodo.”
—Ken Schwaber, presidente e fundador, Scrum.org
O papel do Product Owner é mais crucial do que nunca. Mas é muito

mais do que mecânica: trata-se de assumir a responsabilidade e
reorientar o valor como o objetivo principal de tudo o que você faz. Em The
Professional Product Owner, dois dos principais especialistas em propriedade
de produtos Scrum bem-sucedidos, Don McGreal e Ralph Jocham, mostram
exatamente como fazer isso. Você aprenderá como identificar onde o valor
pode ser encontrado, medi-lo e maximizá-lo durante todo o ciclo de vida do
produto.
McGreal e Jocham orientam você em todas as facetas da concepção,

surgimento e amadurecimento de um produto usando a estrutura Scrum. Eles
discutem estratégias, estabelecem as melhores práticas para gerenciar a
complexidade e entregar valor continuamente e definem as práticas e
PEDIR E SALVAR ferramentas concretas que você pode usar para gerenciar Product Backlogs e
planos de lançamento, tudo com o objetivo de torná-lo um Product Owner mais
Economize 35% ao fazer o pedido bem-sucedido. Ao longo, os autores compartilham experiências pessoais
reveladoras que iluminam os obstáculos ao sucesso e mostram como eles
de informit.com/TPPO e digite o código
podem ser superados.
SCRUMORG durante a finalização da compra
• Definir o sucesso de “de fora para dentro”, usando medições externas

FRETE GRÁTIS para os EUA em livros impressos voltadas para o cliente para orientar o desenvolvimento e maximizar o valor
Principais formatos de e-book

• Trazer empoderamento e empreendedorismo para o
Somente o InformIT oferece PDF, EPUB e
A função do proprietário do produto e alinhar todos por trás de um
MOBI juntos por um preço modelo de negócios compartilhado • Use o gerenciamento baseado
em evidências (EBMgt) para investir nos lugares certos, tomar decisões mais
inteligentes e reduzir riscos
OUTRAS DISPONIBILIDADES
• Aplicar efetivamente a função de Product Owner do Scrum, artefatos,

Através da O'Reilly Safari serviço de e eventos
assinatura
• Preencher e gerenciar Product Backlogs e usar especificações just-in-time •
Livreiros e varejistas online, Planejar e gerenciar lançamentos, melhorar a transparência e
incluindo loja Amazon/Kindle e Barnes
& Noble | bn.com reduza a dívida técnica •
Escale seu produto, não seu Scrum • Use Scrum
para injetar autonomia, domínio e propósito no trabalho de sua equipe de
produto
O profissional
Proprietário do produto
Aproveitando o Scrum como um
Vantagem competitiva
Don McGreal
Ralph Jocham
Boston • Columbus • Indianápolis • Nova York • São Francisco • Amsterdã • Cidade do Cabo
Dubai • Londres • Madri • Milão • Munique • Paris • Montreal • Toronto • Delhi • Cidade do México
São Paulo • Sydney • Hong Kong • Seul • Cingapura • Taipei • Tóquio
9780134686479_web.indbiii 05/02/18 15h40

Muitas das designações usadas por fabricantes e vendedores para distinguir seus produtos são reivindicadas como marcas registradas.
Onde essas designações aparecem neste livro e o editor estava ciente de uma reivindicação de marca registrada, as designações foram
impressas com letras iniciais maiúsculas ou todas em maiúsculas.
Os autores e a editora tomaram cuidado na preparação deste livro, mas não oferecem nenhuma garantia expressa ou implícita de
qualquer tipo e não assumem nenhuma responsabilidade por erros ou omissões. Nenhuma responsabilidade é assumida por danos acidentais
ou consequenciais relacionados ou decorrentes do uso das informações ou programas aqui contidos.
Para obter informações sobre como comprar este título em grandes quantidades ou para oportunidades especiais de vendas (que podem
incluir versões eletrônicas, designs de capa personalizados e conteúdo específico para o seu negócio, objetivos de treinamento, foco de marketing
ou interesses de marca), entre em contato com nosso departamento de vendas corporativas em corpsales@pearsoned.com ou (800) 382-3419.
Para consultas sobre vendas governamentais, entre em contato com cities@pearsoned.com.
Para perguntas sobre vendas fora dos EUA, entre em contato com intlcs@pearson.com.
Visite-nos na Web: informit.com/aw
Número de controle da Biblioteca do Congresso: 2018934196
Copyright © 2018 Scrum.org
A Microsoft e/ou seus respectivos fornecedores não fazem representações sobre a adequação das informações contidas nos documentos e
gráficos relacionados publicados como parte dos serviços para qualquer finalidade. Todos esses documentos e gráficos relacionados são
fornecidos "como estão" sem qualquer tipo de garantia. A Microsoft e/ou seus respectivos fornecedores se isentam de todas as garantias e
condições com relação a estas informações, incluindo todas as garantias e condições de comercialização, expressas, implícitas ou estatutárias,
adequação a uma finalidade, título e não violação específicos.
Em nenhum caso a Microsoft e/ou seus respectivos fornecedores serão responsáveis por quaisquer danos especiais, indiretos ou consequentes
ou quaisquer danos resultantes da perda de uso, dados ou lucros, seja em uma ação de contrato, negligência ou outra ação ilícita, decorrente de
ou em conexão com o uso ou desempenho de informações disponíveis no
Serviços.
Os documentos e gráficos relacionados aqui contidos podem incluir imprecisões técnicas ou erros tipográficos.
Alterações são adicionadas periodicamente às informações aqui contidas. A Microsoft e/ou seus respectivos fornecedores podem fazer
melhorias e/ou alterações no(s) produto(s) e/ou programa(s) aqui descritos a qualquer momento. Capturas de tela parciais podem ser visualizadas
na íntegra na versão de software especificada.
Microsoft® e Windows® são marcas registradas da Microsoft Corporation nos EUA e em outros países.
Capturas de tela e ícones reimpressos com permissão da Microsoft Corporation. Este livro não é patrocinado, endossado ou afiliado à
Microsoft Corporation.
Todos os direitos reservados. Esta publicação é protegida por direitos autorais e a permissão deve ser obtida do editor antes de qualquer
reprodução proibida, armazenamento em um sistema de recuperação ou transmissão de qualquer forma ou por qualquer meio, eletrônico,
mecânico, fotocópia, gravação ou similar. Para obter informações sobre permissões, formulários de solicitação e os contatos apropriados no
Departamento de Permissões e Direitos Globais da Pearson Education, visite www.pearsoned.com/permissions/.
ISBN-13: 978-0-13-468647-9
ISBN-10: 0-13-468647-0
1 18
9780134686479_web.indb iv 05/02/18 15h40

À minha incrivelmente paciente, solidária e incrível esposa Marita; também aos meus
pequenos M&M's, Meagan e Molly, por serem fontes constantes de risadas, amor e
inspiração.
-Vestir
À minha família — obrigado por sua compreensão e apoio duradouro. Tudo isso, as
viagens, as longas horas, não seriam possíveis sem vocês.
Natacha, você é a melhor e eu te amo. Noémie e Anaïs, obrigada por me
manterem com os pés no chão. Vocês são as melhores filhas que eu poderia desejar.
—Ralph
9780134686479_web.indb v 05/02/18 15h40

Conteúdo
Prefácio xiii
Introdução xv
Agradecimentos xxi
sobre os autores xxiii
PARTE I Estratégia 1
Capítulo 1 Questionário sobre gerenciamento ágil de 3
produtos Mentalidade de produto versus 3

mentalidade de projeto O que é gerenciamento de 4
produtos? 7
O vácuo de gerenciamento de produtos e os três Vs 9

Visão 11
Valor 13
Validação 14
Gestão de Produtos e Scrum 15

O Dono do Produto 18
Definindo um produto 22
Revisão do questionário 31
vii
9780134686479_web.indb vii 05/02/18 15h40

Conteúdo
Capítulo 2 Visão 33
Questionário
33
Modelagem de Negócios 35
Business Model Canvas 35
Visão do produto 40
Focado 41
Prático versus Emocional 46

Difundido 49
Visão com Scrum 50
Estratégia Técnica 51
Capítulo 3 Valor 55
Questionário
55
Valor definido 56
Entregando valor 57
Métricas de valor 60
Gestão Baseada em Evidências 65

Valor atual 68
Hora de Mercado 73
Capacidade de inovar 78
Métricas de Rastreamento 83
Para onde vai o seu dinheiro 85
Valor Negativo 86
Visível 87
Invisível 87
neutralidade de valor 89
Perversão de Métricas 89
Capítulo 4 Validação 93
Questionário
93
Feedback das partes interessadas 95
Feedback do mercado 97
Produto com minima viabilidade 97
Produto Mínimo Viável através de Kano 98
viii
9780134686479_web.indb viii 05/02/18 15h40

Conteúdo
Padrões MVP 102

MVP promocional 102
Mineração MVP 103
MVP da página de destino 103

Mágico de Oz MVP 103
MVP de recurso único 104

Girar ou Perseverar 104
PARTE II Scrum 109
capítulo 5 Empirismo 111

Questionário
111
É um problema complexo 111
Questionário de Certeza 115
Visualizando Complexidade 116
Cynefin 118
Óbvio 119
Complicado 120
Complexo 121
Caos 123
Juntando tudo 123
Tipos de Complexidade 126
Gestão de risco 126
Capítulo 6 Scrum Quiz Por 135

que um 135
Framework? 136
Os Pilares do Scrum 139
Transparência 140
Inspeção 140
Adaptação 141
Funções do Scrum 141
Proprietário do produto 142
Equipe de desenvolvimento 145
ix
9780134686479_web.indb ix 05/02/18 15h40

Conteúdo
Scrum Master 149

Outros 151
Artefatos do Scrum 154
Lista de pendências do produto 155
Sprint Backlog 157

Incremento 158
Outros 159
Eventos Scrum 164
Corrida 164
Planejamento do Sprint 167
Reunião Diária 173
Revisão do Sprint 176
Retrospectiva da Sprint 179

Outro 180
Iterativo e Incremental 184
Manifesto Ágil para Desenvolvimento de Software 186
PARTE III táticas 189
Capítulo 7 Gerenciamento do Backlog do Produto 191

191
Questionário O que é um requisito? 192
Histórias de usuários do 193

Backlog do produto 195
Requisitos não Funcionais 199
épicos 202
Critérios de Aceitação 205
Espigões 208
Pedidos do Backlog do Produto 209
Medindo valor, risco e tamanho 213

"Feito" 215
Definição de "Concluído" 215
Definição de exemplo de "Concluído" 220
9780134686479_web.indb x 05/02/18 15h40

Conteúdo
“Pronto” é uma mentalidade 224
Preparando-se 227
Gerenciamento de requisitos enxutos 230
Mapeamento da história 232
Etapas para criar um mapa histórico 233
Explorar o mapa da história 234
Mapas de histórias e backlogs de produtos 235
O Passado e o Futuro 236
Mapeamento de Impacto 236
Critérios de sucesso 239
Especificação por Exemplo 241
Capítulo 8 Gerenciamento de liberação 249
Questionário
249
Razões para Liberar 250
Estratégia de Lançamento 251
Principais lançamentos 252
Lançamentos menores 256
Versões Funcionais 256
Estimativa e Velocidade 259
Gerenciando várias equipes 264
Produtos de escala 267
Um produto, uma equipe de desenvolvimento 268
Vários produtos, uma equipe de desenvolvimento 268
Vários produtos, várias equipes de desenvolvimento 270
Um produto, várias equipes de desenvolvimento 271
A estrutura Nexus 272
Comunicando 273
Noções básicas de previsão 274
Previsão em vários produtos 278
Porcentagem de conclusão 280
Simulação de Monte Carlo 282
Qual é a cor da sua velocidade? 287
XI
9780134686479_web.indb xi 05/02/18 15h40

Conteúdo
Orçamento 289
Governança e Conformidade 294
Começo 300
Qualidade 304
Definições 304
Tipos de Qualidade 306
Mantendo a qualidade 307
Capítulo 9 O Proprietário do Produto Profissional 315

Entendendo o sucesso do Product Owner 316
O proprietário do produto receptor 316
O proprietário do produto iniciante 317
Você 317
Habilidades e Traços 318
Medindo o sucesso 321
Índice 323
xii
9780134686479_web.indb xii 05/02/18 15h40

Prefácio
Comunicação, Intencionalidade e Realização

Você pode ter algo que deseja fazer. Você pode ter uma visão que deseja realizar
(uma nova maneira de as pessoas viajarem entre dois lugares); um produto que você
deseja criar (um toboágua em um lago ou um computador quântico); uma melhoria que
você deseja fazer em algo (o atendimento ao cliente é mais rápido, mais eficaz, mais
amigável). Independentemente disso, você é uma pessoa que tem autoridade e recursos
para tentar conseguir o que deseja. Mas você acha isso muito, muito difícil.
Sua habilidade é visualizar o que você quer. Sua habilidade não é necessariamente
construir o que você deseja (mesmo que pudesse, não teria tempo para isso).
Você só precisa dizer a alguém o que deseja, financiar e provisionar

adequadamente, e o resultado será ótimo (ou pelo menos satisfatório).
Assumimos quando nos comunicamos com outras pessoas que elas entendem o que
queremos dizer. Não necessariamente. Você pode ser inarticulado ou incompreensível.
As pessoas com quem você se comunica podem ser idiotas.
xiii
9780134686479_web.indb xiii 05/02/18 15h40

Prefácio
Ainda mais angustiante, presumimos que sabemos o que queremos dizer, mesmo que
não tenhamos pensado nisso com precisão ou completamente. Nossa tentativa de
comunicação pode ser prematura. Mas, quem tem tempo para esperar?!
Este livro apresenta um método de comunicar nossos desejos de forma convincente,

coerente e com o mínimo de confusão e incômodo. Caso contrário, podemos alienar
nossos aliados, desperdiçar nosso capital e causar danos irreparáveis. Eu sei.
Uma grande força do Scrum é sua capacidade de verificar frequentemente a clareza

do que está sendo comunicado, bem como o quão bem os outros percebem o que você
está comunicando.
A inspeção frequente da clareza das comunicações e das consequências é importante.

É particularmente importante no início de um empreendimento, quando estamos apenas
aprendendo a comunicar quais podem ser os resultados. À medida que melhoramos a
comunicação, as comunicações se tornam mais precisas. Com menos esforço,
aprendemos a determinar o desconhecido e transformá-lo em clareza, e obtemos os
resultados que desejamos.
Como a pessoa que quer algo, quando você usa o Scrum para melhorar a comunicação
e os resultados, seu papel é chamado de Dono do Produto. Don McGreal e Ralph
Jocham escreveram este livro para ajudá-lo a usar o Scrum para fazer isso. Eles devem
saber porque eles fizeram isso.
—Ken Schwaber
xiv
9780134686479_web.indb xiv 05/02/18 15h40

Introdução
Este livro descreve como gerenciar efetivamente produtos feitos pelo homem, principalmente
produtos de software. Mas com a mesma facilidade poderia abordar outros produtos feitos
pelo homem, como redes elétricas, usinas nucleares, pomares de maçã, nano robôs e até
sistemas de drenagem de tempestades. Qualquer coisa imaginada, criada, sustentada e
eventualmente aposentada ou substituída por pessoas está dentro de nosso alcance.
Abordamos especificamente produtos complexos, onde mais se sabe sobre seu contexto
do que se sabe. O criador do produto – seu Dono do Produto – percebe um espaço de
ideias e concebe algo que outros podem achar valioso ou útil.
Tomemos como exemplo a primeira versão do iOS desenvolvida para o iPhone. Enquanto
este produto estava sendo concebido e criado, mais era desconhecido do que conhecido, e
um certo grau de sucesso e fracasso estava envolvido. O Product Owner trouxe a visão para
um pequeno grupo de pessoas que tinham experiência na tecnologia, mercado e produtos
necessários. Esse grupo empregou o empirismo e pequenas equipes auto-organizadas para
gerenciar a criação e o desenvolvimento do iOS, controlar o risco e criar valor.
xv
9780134686479_web.indb xv 05/02/18 15h40

Introdução
Às vezes, uma ideia não está pronta para o horário nobre. A tecnologia pode não ser
adequada para a visão, ou as pessoas podem não ser adequadamente qualificadas.
No entanto, o risco é controlado por meio de curtos ciclos de experimentação.
Esse processo é chamado Scrum,1 uma estrutura para criar e desenvolver produtos
complexos. O Scrum identifica o Dono do Produto como a pessoa que dá vida ao
produto, desde a visão até a criação, e que permanece responsável pela viabilidade do
produto conforme ele se desenvolve e continua em seu ciclo de vida. Um Product Owner
é a pessoa que é responsável por um produto em qualquer ponto no tempo.
Um produto faz coisas, executa funções ou causa mudanças ou resultados.

O ciclo de vida de um produto inclui os seguintes componentes:
• Criação—Um produto é idealizado e partes dele ganham vida, então ele tem algumas
das capacidades e pode executar algumas das funções que foram concebidas para ele.
• Surgimento — Conforme o produto é usado e o tempo passa, novos recursos e funções

aparecem. Estes podem ser criados para ele ou podem ser anexados a ele por interfaces
para outros produtos.
• Maturidade — O produto atinge a maturidade quando totalmente capaz, conforme previsto

e emergido, conforme moldado pelas forças do mercado, novas tecnologias e as
capacidades de seus proprietários de produto.
• Senescência - Ao longo da colina, o produto ainda é usado, mas foi eclipsado por produtos
mais novos, mais fáceis e mais atraentes, com mais ou menos recursos, a preços maiores
ou menores, mas são preferidos pelo mercado e são mais valiosos.
Um produto pode ser um computador, software que o computador está operando,

um sistema de segurança, uma câmera, um carro, um sistema de fluxo de trabalho, um
software de inventário just-in-time, um foguete ou uma função comercial que usa um ou
mais dos acima e executa uma função para uma organização.
1. “Scrum Guides,” Scrum.org, acessado em 4 de março de 2018, http://scrumguides.org.
XVI
9780134686479_web.indb xvi 05/02/18 15h40

Introdução
Exemplos de produtos notáveis e proprietários de produtos incluem o seguinte:
• Foguetes de pouso automático — Elon Musk

• Carros elétricos — Elon Musk
• iPhones—Steve Jobs
• Câmera Polaroid—Edwin Land
• Carro Modelo T —Henry Ford •
Scrum—Ken Schwaber e Jeff Sutherland
Esses Product Owners eram visionários, pessoas que imaginavam métodos diferentes de fazer as
coisas, imaginavam produtos para realizar essas coisas e, então, faziam com que esses produtos
surgissem. Para que esses produtos fossem lembrados, seus Product Owners tiveram que guiá-los
até a maturidade no mercado, onde se mostraram úteis para pessoas ou organizações.
O Scrum ajuda os Product Owners durante a fase visionária, simplificando as demandas

sobre eles. Os Product Owners que podem estimular, imaginar e fazer o produto surgir às vezes
são menos habilidosos em gerenciar e administrar o produto à medida que ele amadurece. Isso
requer uma pessoa treinada em habilidades mais tradicionais, como manufatura, estoque, marketing,
vendas, suporte, serviço e faturamento. Um Product Owner que possui ambos os conjuntos de
habilidades é o Product Owner profissional.
A maioria de nós conhece os Product Owners que supervisionam os produtos na fase madura
de seus ciclos de vida. Na medida em que trabalham em estreita colaboração com as partes
interessadas e estão imbuídos da visão, são bem-sucedidos.
Os Product Owners que também dirigem o negócio, respondem às forças do mercado e ajudam
o produto a se transformar à medida que novas tecnologias e ideias surgem, ajudando-o a se
tornar mais útil.
A senescência é uma parte difícil do ciclo de vida do produto. Todos nós já vimos produtos da IBM,
CDC, Xerox, Kodak, Motorola, Nokia, Blackberry, Wang, DEC e outras organizações que atingem
esse ponto em seus ciclos de vida. Na medida em que esses produtos são levados graciosamente
para seus túmulos, eles sustentam as organizações que os abrigaram até a maturidade. Agora eles
estão na vida
xvii
9780134686479_web.indb xvii 05/02/18 15h40

Introdução
Apoio, suporte. Se tiverem alcançado a maturidade com sucesso, podem ter proporcionado uma
oportunidade para novos visionários criarem novos produtos que possam sustentar a organização.
Normalmente não.
Este livro descreve como uma pessoa atuando no papel de Dono do Produto pode usar o Scrum
para visualizar, criar e amadurecer um produto. Ao longo do ciclo de vida, o produto é passado de
pessoa para pessoa. Em nossa opinião, deve ser passado de um indivíduo responsável para o
próximo indivíduo responsável.
Essa única pessoa, o Dono do Produto, é responsável por tudo o que acontece em relação ao
produto, seu valor para a organização anfitriã e para aqueles que o utilizam.
O Product Owner faz com que o produto viva e cresça de muitas maneiras diferentes, como
desenvolvimento, parcerias e interfaces. No entanto, esse indivíduo é a pessoa “o dinheiro pára
aqui”; ele ou ela sozinho, não um comitê ou grupo, cumpre esta função.
Temos um grande exemplo disso nos Estados Unidos com o Affordable Care Act (ACA) e o site
healthcare.gov. Quando chegou a hora da ACA ganhar vida, isso não aconteceu. Não respondia na
internet, não permitia o cadastro das pessoas, confabulava dados. E quem foi o responsável por este
desastre, este embaraço? Ninguém tinha certeza.
Uma criança bem-sucedida tem muitos pais. Uma falha não tem nenhum.
—baseado em Tácito, Agrícola, ca. 98 DC
Eventualmente, o Secretário de Saúde, Educação e Bem-Estar disse que ela era a responsável, mas
quis dizer apenas que estava no lugar errado na hora errada – não o Dono do Produto.
Se você tem um produto em algum ponto de seu ciclo de vida e deseja usar o Scrum para
criar mais valor para seus usuários, você será o Dono do Produto.
Este livro pretende dizer-lhe como fazê-lo.
Este livro faz parte de uma série de livros da Scrum.org conhecida como a série profissional.
Esta série foi fundada em um conjunto uniforme de valores que unem o
xviii
9780134686479_web.indb xviii 05/02/18 15h40

Introdução
pessoas envolvidas no trabalho, para que possam confiar umas nas outras, minimizar o desperdício
e ter sucesso.2
Como ler este livro

Este livro foi elaborado de forma a assumir que você possui algum conhecimento de Scrum.
Se você é novo no Scrum, sugerimos que dê uma olhada primeiro na Parte II.
Fazemos referência ao Guia oficial do Scrum de Ken Schwaber e Jeff Sutherland (criadores do
Scrum) ao longo do livro e fizemos todos os esforços para permanecermos consistentes com sua
linguagem. Por exemplo, usamos letras maiúsculas nos termos oficiais do Scrum para funções,
artefatos e eventos da mesma forma que o Guia do Scrum .
Cada capítulo é relativamente independente. Os capítulos são agrupados em três partes:
• Parte I: Estratégia—Esta parte tem muito pouco a ver com o próprio Scrum. Em vez de
nosso foco é o gerenciamento ágil adequado de produtos e a maximização do ROI de um produto.
Apresentamos os três Vs (visão, valor, validação) como forma de alcançar isso.
• Parte II: Scrum—Esta parte começa definindo o controle de processo empírico e como o Scrum
é uma ferramenta para gerenciar a complexidade e a entrega contínua de valor. Com a ajuda do
Guia do Scrum, definimos cada papel, artefato e evento com atenção especial ao papel do Dono
do Produto.
• Parte III: Táticas—A Parte III apresenta práticas e ferramentas mais concretas para
gerenciando Product Backlogs e planos de lançamento, e conclui examinando o que significa ser
um Product Owner profissional.
Cada capítulo começa com um pequeno questionário. A intenção é preparar o terreno para o
capítulo, convidando você a pensar de forma independente sobre os tópicos principais. Revisamos
o teste no final do capítulo para determinar se o seu pensamento mudou de alguma forma - considere
isso Leitura Orientada a Testes.
2. Outras publicações podem ser encontradas ou referenciadas em http://scrum.org.
xix
9780134686479_web.indb xix 05/02/18 15h40

Introdução
Ao longo do caminho, compartilhamos anedotas pessoais de

experiências relevantes. Essas sinopses têm um ou ambos
os nossos rostos ao lado deles. Assim como este.
Colocamos muito pensamento e prática no curso Scrum.org Professional Scrum Product

Owner que ensinamos e mantemos. Achamos que este livro é um companheiro perfeito
para esse curso, pois contém as mesmas informações e muito mais.
Esperamos sinceramente que você goste de lê-lo tanto quanto gostamos de ensinar,
discutir, treinar e escrever sobre esses tópicos.
—Don e Ralf
Registre sua cópia de The Professional Product Owner no site da InformIT para
acesso conveniente a atualizações e/ou correções assim que estiverem disponíveis.
Para iniciar o processo de registro, acesse informit.com/register e faça login ou crie
uma conta. Digite o ISBN do produto (9780134686479) e clique em Enviar. Procure na
guia Produtos registrados um link de conteúdo de bônus de acesso próximo a este
produto e siga esse link para acessar qualquer material de bônus disponível. Se você
gostaria de ser notificado sobre ofertas exclusivas em novas edições e atualizações,
marque a caixa para receber nosso e-mail.
xx
9780134686479_web.indb xx 05/02/18 15h40

sobre os autores
Don McGreal, em sua função como VP de Learning Solutions na Improving

(improving.com), é um consultor e instrutor ágil prático. Ele é especialista em
coaching ágil nos níveis corporativos e de gerenciamento de produtos em
organizações maiores.
Don é um Scrum.org Professional Scrum Trainer que escreveu e ministrou aulas para
milhares de profissionais de software em todo o mundo. Ele também é cofundador da
TastyCupcakes.org, uma coleção abrangente de jogos e exercícios para acelerar a adoção
de princípios ágeis.
Don é um canadense francófono irlandês que vive no Texas.
Ralph Jocham é um cidadão alemão que passou os últimos 20 anos coletando

software profissional e experiência em desenvolvimento de produtos na França,
Reino Unido, Estados Unidos e agora na Suíça. Ele se tornou um evangelista ágil em 2000
e aperfeiçoou sua abordagem na ThoughtWorks.
Ralph também é o primeiro treinador da Europa com Scrum.org e ensinou milhares de

profissionais em todo o mundo. Quando não está ocupado administrando sua empresa,
xxiii
9780134686479_web.indb xxiii 05/02/18 15h40

sobre os autores
eficaz ágil (eficazagile.com), ou ajudando todos os tipos de empresas na

Europa, ele gosta de ensinar em universidades.
Ralph, no entanto, encontra tempo para passar bons momentos com sua
família regularmente, oferecendo-lhes uma culinária internacional caseira e fazendo
longas caminhadas com o cachorro da família.
Don e Ralph são administradores do curso Scrum.org Professional Scrum

Product Owner ministrado em todo o mundo.
xxiv
9780134686479_web.indb xxiv 05/02/18 15h40

1Gestão
produto ágil
Não fizemos nada de errado, mas de alguma forma, perdemos.

—CEO da Nokia, Stephen Elop
Questionário
Para preparar o terreno para este capítulo, tente responder a cada uma das seguintes
afirmações com Concordo ou Discordo. As respostas aparecem no final do capítulo.
Declaração Aceita Discordo
Cronograma, orçamento e escopo são as melhores formas de medir o desempenho do projeto

sucesso.
O gerenciamento de produtos é uma prática essencial para os Product Owners.
Um Product Owner deve atuar como um proxy entre o negócio e a tecnologia.
Um Product Owner estabelece uma visão para um produto.
O Scrum fornece todas as ferramentas necessárias para o sucesso do produto

gestão.
Todo esforço de desenvolvimento tem um produto.
9780134686479_web.indb 3 05/02/18 15h40

Capítulo 1 Gerenciamento Ágil de Produtos
Mentalidade de produto versus mentalidade de projeto

Um projeto começa com uma ideia. Se a ideia parecer promissora, um projeto pode ser
iniciado para torná-la realidade.
Projetos importantes exigem organização e responsabilidade. É aqui que entra um gerente

de projeto . Um gerente de projeto é alguém qualificado em gerenciar tarefas e pessoas, mas
não necessariamente conhecedor ou apaixonado pelo domínio.
Este gerente de projeto reúne informações suficientes para criar um plano. O plano delineará
em detalhes o escopo da iniciativa em vários marcos do projeto e estimará quanto tempo e
dinheiro serão necessários para concluir tudo.
Esse gerente então pede recursos (incluindo pessoas), forma uma equipe em torno do projeto
e mantém cada membro da equipe na tarefa para garantir um resultado bem-sucedido. O
sucesso é medido, em última análise, pelo quanto o gerente de projeto se apega ao plano
inicial - escopo, tempo, orçamento.
Isso parece perfeitamente razoável - a princípio.
Mas e os projetos que permanecem no prazo, dentro do orçamento e dentro do escopo,

mas ainda assim não são bem-sucedidos? Durante anos, a Nokia liderou o mercado na
produção de telefones celulares. Ele entregou telefone após telefone em horários apertados.
Ele sabia como executar um projeto, e cada projeto individual provavelmente foi bem-
sucedido. Mas e os telefones da empresa? A Nokia ainda existe? Sim, como um
departamento da Microsoft. O interessante é que a Microsoft pagou mais pelo Skype (US$
8,6 bilhões), uma empresa de serviços para algumas centenas de pessoas, do que pela
Nokia (US$ 7,2 bilhões), uma empresa que em determinado momento tinha uma vasta
infraestrutura, milhões em ativos de hardware e 100.000 funcionários. .
Se você ou sua empresa pensar em projetos e menos em produtos e valores, a maré da

sorte pode virar rapidamente.
9780134686479_web.indb 4 05/02/18 15h40

Mentalidade de produto versus mentalidade de projeto
Curiosamente, a palavra “projeto” costumava significar

fazer algo antes de (pro-) agir (-jetar). Na década de
1950, o gerenciamento de projetos tornou-se mais
popular com a introdução de várias técnicas nas
indústrias de engenharia e defesa. Isso expandiu a
definição de “projeto” para incluir planejamento e
execução e, desde então, expandiu-se para centenas de técnicas em muitos
outros setores.
Não se preocupe, este não é um livro de gerenciamento de projetos. No entanto, uma compreensão
do estado atual do gerenciamento de projetos deve fornecer algum contexto para o motivo pelo qual
o escrevemos.
Essa mentalidade de projeto (veja a Figura 1-1) define o sucesso de “dentro para
fora”, usando medições internas que são mais sobre gerenciamento de tarefas e
sobre a precisão com que o plano inicial foi seguido.
Mentalidade de projeto
Alcance
Sucesso inicial definido de dentro
para fora: • Escopo • Tempo • Orçamento
Leva a menos envolvimento nos
negócios e mais gerenciamento de Tempo

Orçamento
tarefas.
Figura 1-1 Representação visual de uma mentalidade de projeto
Qual é a alternativa?
O que seus clientes valorizam? Projetos ou produtos? O objetivo não é entregar

projetos, mas agregar valor por meio de produtos - produtos que, em última
análise, levam a maiores receitas e custos mais baixos para sua organização. Produtos
9780134686479_web.indb 5 05/02/18 15h40

que são tão bons que sua base de clientes crescerá e os clientes existentes permanecerão
por perto.
Portanto, esqueça os projetos. Aborde sua ideia e seu caso de negócios como um
produto. Dê sua ideia de produto a uma equipe capacitada e apresente-a a metas de
negócios significativas, como adoção de usuários, vendas e satisfação das partes
interessadas. Impressione a equipe de que a única maneira de influenciar alvos como
esses é liberar algo de valor o mais rápido possível e validar sua suposição de negócios.
Agora que a equipe tem a mentalidade adequada, a próxima pergunta deve ser: “O
que podemos lançar primeiro que terá o maior impacto em nossas metas?”
De repente, a entrega e os negócios começam a se alinhar e preencher a lacuna de

comunicação.
Essa mentalidade de produto (veja a Figura 1-2) é uma abordagem “de fora para dentro”
que usa medições externas para orientar ativamente o desenvolvimento do produto para
maximizar o valor.
Mentalidade de projeto j Mentalidade de Produto
Sucesso inicial definido de dentro Sucesso continuamente

Alcance
para fora: • Escopo • Tempo • Orçamento impulsionado por métricas de
negócios externas em: • Adoção/
retenção de usuários • Receita •

Economia de custos por recurso
Leva a menos envolvimento nos Leva a menos desperdício,

negócios e mais gerenciamento de Tempo mais criatividade e mais
Orçamento
tarefas. lançamentos.
Figura 1-2 Mentalidade de produto versus projeto
9780134686479_web.indb 6 05/02/18 15h40

O que é gerenciamento de produtos?
Uma mentalidade de produto:
•
incentiva lançamentos mais frequentes, o que resulta em feedback antecipado do
mercado; • comunica objetivos em vez de tarefas; as equipes ficam mais criativas com
suas soluções e assumem mais controle sobre seus planos; e • elimina o desperdício
dependendo menos da atribuição de tarefas, relatórios e
decisões de gestão.
Compare isso com a mentalidade do projeto, que leva a:
• menor envolvimento comercial;
• mais transferências; • mais
gerenciamento de tarefas; e • mais
gestão de pessoas.
Mas e se não houver um produto?
Leia. Mais adiante neste capítulo, defendemos que o desenvolvimento de software sempre
envolve um produto.
O que é gerenciamento de produtos?
A Figura 1-3 mostra as diferentes camadas de planejamento dentro de uma organização

que desenvolve produtos de qualquer tipo. No centro de qualquer abordagem baseada em
Scrum está um plano diário dentro de um plano Sprint. (Sprints e Sprint Planning são
descritos nos Capítulos 5 e 6.) Ambos os planos pertencem à Equipe de Desenvolvimento
que está fazendo o trabalho. Eles têm autonomia para desenvolver um plano sobre a melhor
forma de atender a meta do Sprint e inspecionar e adaptar esse plano todos os dias.
9780134686479_web.indb 7 05/02/18 15h40

Visão da empresa
Estratégia de negócio
Visão do produto
Estratégia de produto
Plano de Lançamento
Plano de Sprint
Plano Diário
Figura 1-3 As diferentes camadas de planejamento
As duas camadas externas de planejamento são a visão geral da empresa e a estratégia de

negócios. Ambos são normalmente de propriedade de uma equipe executiva ou CEO, que
estabelece e comunica uma visão de toda a empresa e promove uma estratégia geral sob essa
visão.
Entre os objetivos organizacionais maiores e o trabalho que as equipes de desenvolvimento

realizam no dia a dia, há uma lacuna (consulte a Figura 1-4).
9780134686479_web.indb 8 05/02/18 15h40

O vácuo de gerenciamento de produtos e os três Vs
Visão da Empresa
produtos
Gestão
Vácuo
Plano de Sprint
Plano Diário
Figura 1-4 O Vácuo de Gerenciamento de Produto
Chamamos isso de Vácuo de Gerenciamento de Produto, e é

uma grande motivação para escrever este livro.
O Vácuo de Gerenciamento de Produto e o

três contras
O problema de qualquer vácuo é que ele tem uma necessidade inata de ser preenchido.
Se você não for cuidadoso, o Vácuo de gerenciamento de produtos será preenchido com
trabalho ocupado sem sentido e gerenciamento extenso de tarefas, geralmente guiado por
9780134686479_web.indb 9 05/02/18 15h40

métricas do projeto conforme descrito anteriormente. Todas as camadas de

orçamento, termo de abertura do projeto, entrega e divisão de tarefas mascaram a
verdadeira intenção da iniciativa. Você corre o risco de estar ocupado sem uma direção clara.
Quanto maior o vácuo:
• quanto mais desconectados os grupos de tecnologia estão dos negócios; • menos
engajadas as pessoas no terreno se tornam; • mais confiança há no gerenciamento
de projetos e tarefas; • mais hierarquias e transferências surgem; • mais complexidade
é introduzida; • mais difícil é mudar de direção quando o clima de negócios muda; •
mais “trabalho ocupado” é criado; • mais desperdício e retrabalho ocorrem; e
• menos valor é entregue aos clientes.
O verdadeiro gerenciamento de produtos consiste em incorporar agilidade em toda a

organização, de cima a baixo, preenchendo assim o vácuo do gerenciamento de produtos.
Feito corretamente, isso cria uma verdadeira vantagem competitiva.
Para preencher o vácuo da maneira certa, use os três Vs mostrados na Figura 1-5.
A Figura 1-6 representa como os três Vs preenchem o vácuo.
Valor
Visão Validação
Figura 1-5 Os três Vs
10
9780134686479_web.indb 10 05/02/18 15h40

Visão da empresa
Visão
Visão do produto
produtos
Gestão
Valor Estratégia de produto
Vácuo
Validação Plano de Lançamento
Plano de Sprint
Plano Diário
Liberar
Figura 1-6 Como Visão, Valor e Validação preenchem o vácuo de gerenciamento de produto
Vamos dar uma breve olhada em cada um dos Vs.
Visão
Visão cria Transparência.
O Product Owner bem-sucedido estabelece uma visão clara do produto para sua equipe, assim
como um comandante militar estabelece uma intenção clara para seus subordinados.
Isso permite que os subordinados ajam sem ordens diretas, se necessário, para realizar a
intenção do comandante.
11
9780134686479_web.indb 11 05/02/18 15h40

Do livro Auftragstaktik: The Basis for Modern Military Command? pelo Major Michael J.
Gunther:
O uso de táticas de missão [Auftragstaktik] permite [s] comandantes subordinados. . . interpretar

a melhor forma de atingir a intenção do comandante com base em sua compreensão da
situação tática. . . . O sucesso da doutrina depende de o destinatário das ordens entender a
intenção do emissor e agir para atingir o objetivo, mesmo que suas ações violem outras
orientações ou ordens recebidas. 1
A auto-organização não acontece simplesmente. Assim como nas forças armadas, os

dois principais ingredientes são visão compartilhada e limites claros.
No contexto do desenvolvimento do produto, os limites são fornecidos pelo Scrum e a visão

é fornecida por meio da forte liderança e comunicação do Dono do Produto.
A visão do produto ancora tudo no processo. Essa visão cria transparência porque
forma a base para todas as conversas seguintes, levando a um entendimento comum
de por que você está construindo o produto e quais são as necessidades de seus
clientes. De acordo com Richard Hackman, 30% do sucesso de uma equipe depende
de como ela foi lançada.2 Uma visão excelente e bem comunicada é fundamental para
um lançamento bem-sucedido.
Você precisa comunicar a visão do produto repetidas vezes para manter todos a bordo e
honestos. Nunca esqueça que esta visão representa a voz do cliente. Se você parar de
ouvir seus clientes, o produto resultante será de menor valor ou até os alienará.
1. Michael J. Gunther, Auftragstaktik: a base para o comando militar moderno? (Fort Leavenworth, KS:
Escola de Estudos Militares Avançados, Escola de Comando e Estado-Maior do Exército dos EUA,
2012), 3 (ênfase adicionada).
2. J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances (Boston, MA: Harvard
University Press, 2002).
12
9780134686479_web.indb 12 05/02/18 15h40

Muitas vezes vejo o termo “recursos” usado para seres humanos. Esses
recursos recebem um catálogo de requisitos a serem implementados e
raramente têm ideia do motivo. Eles carecem do contexto da visão e,
portanto, são privados da consciência situacional. Eles cumprem
exatamente o que foi especificado, mas muitas vezes ainda erram o objetivo.
Fazer a conexão com a visão do produto (ou mesmo da organização) ajuda os membros
da equipe a assumir compromissos orientados por metas e a sentir que fazem parte de
algo maior do que eles mesmos. Então, como você cria uma visão clara? As técnicas são
exploradas no Capítulo 2, “Visão”.
Valor
Definir valor fornece a você algo para inspecionar.
Imagine a visão como um longo fio. O valor são as pérolas individuais que você anexa à
medida que progride. A visão fornece um alicerce e uma direção, mas sem as pérolas
ligadas a ela, não há valor. O trabalho de um Time Scrum é identificar e então anexar pérolas
(valor) ao fio (visão).
A primeira pérola pode ser uma grande iniciativa de negócios ou uma pequena característica
distinta. Apontar para o item mais valioso primeiro e prendê-lo completamente antes de
passar para o próximo. Em outras palavras, esteja sempre em posição de entregar valor.
“Se você pudesse ter apenas uma coisa, o que seria?” geralmente é uma boa pergunta de
abertura ao identificar o mais valioso.
Se tudo é importante, então nada é.

—Patrick Lencioni3
3. Silos, política e guerras territoriais: uma fábula de liderança sobre como destruir as barreiras que transformam colegas
em Concorrentes (San Francisco: Jossey-Bass, 2002).
13
9780134686479_web.indb 13 05/02/18 15h40

Depois de obter essa resposta, geralmente após uma pesquisa persistente, tente realmente entender
a visão da outra pessoa; tente entender o porquê subjacente. Você pode até questionar a utilidade
do produto. Eventualmente, quando você o tiver reduzido e estiver convencido, vá em frente e defina
como o valor se manifestará. Um processo levaria menos cliques? Quantos? O comportamento de um
usuário mudará? Como? Uma transação será mais rápida? Quão rápido? Você precisa fornecer mais
liderança do que simplesmente dizer “vamos fazer isso!” Se você não for capaz de quantificar o sucesso
ou provar a realização do valor, as chances de estar no caminho errado são bastante altas. Não se
esqueça que a única prova real, porém, é através do cliente. Tudo antes não passa de uma hipótese.
Gosto da ideia de que, por meio da funcionalidade que desenvolvemos, realmente

melhoramos o mundo. Pode não ser a paz mundial que alcançamos, mas causamos
um impacto positivo na vida de alguém - mesmo que seja apenas um clique a
menos em um processo.
Então, como você mede o valor? As técnicas são exploradas no Capítulo 3, “Valor”.
Validação
Validação causa Adaptação.
A maioria das suposições de negócios está claramente errada.4 Elas parecem boas no papel, mas não
se sustentam no mundo real. Cada ideia valiosa deve ser validada o mais rápido possível. Um lugar onde
isso é feito no Scrum é a Revisão do Sprint. A Sprint Review é a chance para todos os stakeholders
revisarem o estado atual do produto e obter uma visão sobre as próximas etapas. Quanto mais próximos
os revisores estiverem dos clientes reais e quanto mais próximo o Incremento estiver de ser lançado,
mais realista será o feedback e as adaptações subsequentes.
4. Ronny Kohavi et al., “Online Experimentation at Microsoft” (artigo ThinkWeek, Microsoft Corp.,
Seattle, WA, 2009).
14
9780134686479_web.indb 14 05/02/18 15h40

Gestão de Produtos e Scrum
Mesmo que as avaliações da Sprint corram bem e todos pareçam felizes, você ainda não
terá uma validação verdadeira até que o produto ou recurso esteja em produção e seja
usado. No Scrum, “Concluído” significa que o incremento é potencialmente liberável. No
entanto, para obter a validação final e reduzir o risco geral do produto, você precisa
estabelecer um ciclo de feedback com o mercado. Para isso, você precisa liberar com a
frequência que a empresa puder suportar.
Os dois principais ciclos de feedback no Scrum estão no lado do processo e no

lado do produto:
• A validação do processo é sobre inspecionar e adaptar como o Time Scrum está

trabalhando.
• A validação do produto é sobre inspecionar e adaptar o que o Time Scrum

está construindo.
A validação no contexto do gerenciamento de produtos e os três Vs são sobre o último:

validação do produto.
O Capítulo 4, “Validação”, descreve isso com mais detalhes.

Construir produtos requer que você considere uma série de atividades estratégicas.
Considere a seguinte lista:
• Analisar a indústria e a concorrência

• Maximizando o ROI
• Prevendo e avaliando a viabilidade •
Desenvolvendo a estratégia do produto •
Planejando lançamentos • Identificando os
clientes e suas necessidades • Mapeando o
produto • Resultados da auditoria • Criando
mensagens de saída
15
9780134686479_web.indb 15 05/02/18 15h40

• Sustentar o produto •
Executar o lançamento •
Criar o caso de negócios •
Identificar os requisitos do produto •
Lançar o produto • Desenvolver a
estratégia de retenção do cliente • Definir
recursos e iniciativas do produto • Retirar o
produto • Marketing e branding
Quantos deles se encaixam perfeitamente no reino do Scrum? Talvez três ou quatro,

mas não muitos.
O mundo do gerenciamento de produtos é muito maior do que o Scrum, conforme

sugerido na Figura 1-7, o que possivelmente explica por que existe um vácuo tão grande
de gerenciamento de produtos na indústria de software.
O negócio produtos produtos Contínuo

Modelagem Visão Entrega
Gestão
apenas em
Mercado Queime/ Custo de
Relativo Tempo Ágil
Pesquisar Gráficos Burndown Atraso
Estimativa Planejamento
Definição Scrum Lista de pendências
A/B de Feito refinamento Valor

teste Métricas
Compre um
empirismo e Do utilizador
3 Funções 3 Artefatos
Característica Auto-organização Histórias
Do utilizador Corrida Previsão Medindo/

Meta 5 Eventos
pesquisas reduzindo
Velocidade Liberar Técnico
Planejamento Especificação História Dívida
Planejamento
pôquer por Exemplo Mapeamento
Programa Mínimo Impacto

Roteiro
Gestão Produto Viável Mapeamento
… e muitos, muitos mais.
Figura 1-7 O Scrum é incrementado por muitas, muitas práticas. (Figura © 1993-2016 Scrum.org.
Todos os direitos reservados.)
16
9780134686479_web.indb 16 05/02/18 15h40

É aqui que entra o Dono do Produto. Um Dono do Produto é uma das três funções do Scrum.
Embora a maioria das atividades de gerenciamento de produtos não faça parte da estrutura
Scrum, conforme mostrado na Figura 1-8, um bom Dono do Produto as assumirá para preencher
o vácuo do gerenciamento de produtos.
Gestão de produtos
produtos
Scrum
Proprietário
Figura 1-8 A propriedade do produto é o gerenciamento ágil de produtos que utiliza o Scrum.
Em outras palavras, um bom Product Owner é um Product Manager ágil.
Quando trabalho com uma organização para identificar os candidatos ideais

para a função de Product Owner, primeiro pergunto sobre as atividades
estratégicas acima e quem as realiza. Se a organização já possui um Product
Manager que realiza muitas dessas atividades, considero-o um candidato
ideal para Product Owner. Se ninguém está fazendo essas atividades ou
essa pessoa não está disposta ou capaz de se comprometer com uma
função de Product Owner, então insisto em capacitar nosso Product Owner para assumir
essas atividades como uma forma de elevar a função além da tática para a estratégica.
Um Product Owner empoderado e empreendedor preenche o vácuo de gerenciamento

de produto, conforme mostrado na Figura 1-9.
17
9780134686479_web.indb 17 05/02/18 15h40

Visão da Empresa
Visão Modelo de negócios

Visão do produto
Declaração de visão
Medições de valor
produtos
Gestão
Valor Estratégia de produto
Vácuo
Validação Plano de Lançamento

Roteiro
Lista de pendências do produto
Plano de Sprint
Plano Diário
Liberar
Figura 1-9 O Dono do Produto e o Vácuo de Gerenciamento do Produto
O Dono do Produto
Quem deve desempenhar o papel de Product Owner?
Mais adiante neste livro, mais tempo é gasto nas tarefas e responsabilidades específicas
de um Product Owner. Este capítulo fica em um nível mais estratégico.
No Scrum, você precisa de um Product Owner. Mas obviamente é preciso mais do que
apenas preencher o papel. A eficácia dessa função e da implementação geral do Scrum
depende muito do tipo de pessoa nessa função (consulte a Figura 1-10).
18
9780134686479_web.indb 18 05/02/18 15h40

O Dono do Produto
Esperado
Benefícios EU
nitiat g
dentro
ng
eu
ce4
Re
Escriba Proxy O negócio Patrocinador Empreendedor produtos

Representante Papel do Proprietário
Figura 1-10 Tipos de função do Product Owner por benefícios esperados
Um escriba provavelmente é alguém do lado da tecnologia encarregado de capturar

requisitos para a equipe de desenvolvimento. Essa pessoa costuma ser vista como a
secretária da equipe e é solicitada a anotar tudo durante as reuniões com a empresa. Ele tem
pouca ou nenhuma capacidade de tomada de decisão, o que afeta gravemente sua eficácia
como Product Owner e causa atrasos.
Ainda é provável que um proxy venha do lado da tecnologia, mas é visto como um
representante do negócio, talvez até mesmo de um gerente de produto específico do lado do
negócio. Ela geralmente tem um título de analista de negócios ou analista de sistemas.
O problema é que um proxy cria uma indireção desnecessária entre o Time de
Desenvolvimento e os verdadeiros influenciadores.
Qual é a resposta provável do proxy sempre que a equipe tem uma pergunta para ela?
“Deixe-me ir perguntar”, resultando em mais atrasos.
A procuradora poderia proteger sua função e interromper qualquer comunicação direta entre
a equipe e a empresa? Muito provavelmente. Você certamente vê isso o tempo todo.
Tanto o escriba quanto o proxy estão no lado receptor do que entra no produto. Eles são
informados sobre o que fazer. Na melhor das hipóteses, eles elaboram os detalhes.
19
9780134686479_web.indb 19 05/02/18 15h40

Um representante comercial é alguém do lado comercial e não do lado tecnológico.

Essa função é uma clara melhoria em relação à função de proxy, pois demonstra um
compromisso da empresa com o produto. Em contraste com o Proprietário do Produto
proxy, essa função fornece acesso mais direto ao conhecimento do domínio e às
expectativas das partes interessadas. No entanto, ainda pode haver atrasos na tomada
de decisões, pois o representante comercial geralmente tem autonomia limitada sobre
o gerenciamento de produtos.
Um patrocinador de negócios é uma grande melhoria na função de Product Owner. Um

patrocinador é alguém que liderou o caso de negócios inicial e adquiriu o orçamento.
Consequentemente, ele tem a confiança e o mandato para tomar decisões financeiras
e de produtos no local. Isso cria menos soluços, menos troca de contexto e fluxo
amplamente aprimorado. A equipe de desenvolvimento pode então se concentrar mais
e fazer mais coisas mais cedo.
O Dono do Produto final é um empreendedor. É alguém que está gastando seu

próprio dinheiro para financiar o desenvolvimento do produto. Isso dá a ela total
responsabilidade sobre todas as decisões de gerenciamento de produtos para negócios
e estratégia de TI. Agora, embora isso possa não ser uma situação realista para muitas
organizações, uma mentalidade empreendedora ainda é algo que os Product Owners
devem assumir. Eles devem esperar ver um retorno sobre o investimento (ROI) como
se seu próprio dinheiro estivesse em jogo.
O representante comercial, o patrocinador e o empresário estão mais no lado

inicial do produto. Por causa de sua compreensão mais profunda do negócio e de sua
comunicação bidirecional, eles desenvolvem uma empatia mais forte com o cliente. Essa
empatia lhes permite iniciar em vez de simplesmente receber os requisitos certos.
Lembre-se de que quanto mais próximo um Dono do Produto estiver de um

patrocinador, mais ele poderá se desligar da Equipe de Desenvolvimento. Encontrar
maneiras de manter esse senso de conexão com a visão do produto torna-se ainda
mais importante e é o que se espera de um Product Owner empreendedor.
20
9780134686479_web.indb 20 05/02/18 15h40

O Dono do Produto
A Figura 1-11 fornece um resumo desta discussão sobre as funções do Dono do Produto
tipos.
Escriba Proxy O negócio Patrocinador Empreendedor

Representante
Visão Nenhum Baixo Médio Alto Alto
Tomando uma decisão

Nenhum Baixo Médio Alto Alto
Baixo Baixo Alto Alto Alto
Conhecimento de Domínio
Nenhum Nenhum Baixo Alto Alto

Orçamento
Desenvolvimento Alto Alto Médio Baixo Alto

Envolvimento da equipe
Envolvimento Comercial Baixo Med Alto Alto Alto
Responsabilidade
Nenhum Baixo Médio Alto Alto
Proprietário do produto Domínio do proprietário do produto Domínio da equipe de desenvolvimento
Figura 1-11 Resumo dos tipos de função do Product Owner
Costumo me pegar anotando esses cinco tipos de função do Product Owner

quando falo com as organizações. Eu gosto de perguntar a eles onde eles
veem seus Product Owners. Não surpreendentemente, eles estão
frequentemente mais próximos das funções de escriba e proxy. Isso então
se transforma em uma discussão de ações mais práticas que um Product
Owner poderia fazer para subir na lista. Poderia um escriba passar a ser
mais representativo dos empresários? Um proxy poderia começar a aprender mais sobre
o lado comercial? Um representante comercial poderia pedir para se envolver mais com o
orçamento e a direção estratégica? Se a resposta for não para qualquer uma dessas
perguntas, devemos nos perguntar se temos a pessoa certa na função de Product Owner.
21
9780134686479_web.indb 21 05/02/18 15h40

Definindo um produto
O que é um produto? Superficialmente, essa questão parece simples. Mas isso não.
Um produto é qualquer coisa que pode ser oferecida a um mercado que possa satisfazer um desejo ou
necessidade.5
As empresas vendem muitos produtos - varejo, produtos financeiros, assentos em

aviões, carros.
No mundo do desenvolvimento de software, você também fabrica produtos:
• Alguns são commodities simples - processadores de texto, jogos,

sistemas.
• Outros são canais para outros produtos - varejo online, reservas de viagens
sites, aplicativos bancários móveis, mecanismos de pesquisa.
Quando este livro se refere a produtos, geralmente significa produtos de software.

No entanto, muitos dos conceitos discutidos se aplicam muito além do domínio
do software.
Para começar, aqui estão algumas afirmações:
1. Sempre existe um produto. Pode não ser sempre óbvio, mas está lá
e precisa ser identificado.
E
2. Todo produto tem um cliente que é: a.

Consumidor: Qualquer pessoa que obtém valor do seu produto, pagando
ou não por ele
b. Comprador: Qualquer pessoa que pague pelo seu produto, independentemente de usá-lo ou não
c. Ambos
5. Philip Kotler, Linden Brown, Stewart Adam, Suzan Burton e Gary Armstrong, Marketing, 7ª ed.
(Frenchs Forest, Nova Gales do Sul: Pearson Education Austrália/Prentice Hall, 2007).
22
9780134686479_web.indb 22 05/02/18 15h40

3. Todo produto tem um produtor que recebe um benefício básico por meio de:
uma. aumento de receita
b. Redução ou prevenção de custos
c. Benefício social
O que acontece com muita frequência é que áreas menores de funcionalidade ou mesmo
componentes técnicos menores são considerados produtos, sem cliente claro ou proposta de valor.
Tive em um dos meus treinamentos de Product Owner um participante que se

apresentou como “Meu nome é . . . e eu sou o Product Owner para testes.”
Normalmente sou conhecido por ser rápido com minhas palavras, mas neste
caso fiquei sem palavras.
Outro padrão comum é a Lei de Conway:
Organizações que projetam sistemas. . . são obrigados a produzir designs que são cópias das
estruturas de comunicação dessas organizações.6
O resultado da Lei de Conway é uma série de “sistemas” interconectados construídos por

diferentes departamentos (ou hierarquias) dentro de uma organização com pouco foco no produto
real ou mesmo em quem é o cliente.
Esta é a razão pela qual o Scrum nomeia a função de Proprietário do Produto e não
Proprietário do Sistema, Recurso ou Componente.
A melhor abordagem é pensar no produto da perspectiva do cliente. Quais necessidades do

cliente você está atendendo? O que os clientes esperam?
Quais melhorias de produto facilitarão a vida dos clientes?
6. Melvin E. Conway, “Como os comitês inventam?” Datamation 14, no. 5 (1968): 28–31.
23
9780134686479_web.indb 23 05/02/18 15h40

Quando trabalhamos com empresas para definir seus produtos, enfatizamos

que, em última análise, essa é uma decisão de negócios. Vamos alinhar
nossos grupos de tecnologia com base nos produtos que nossa empresa
deseja que os clientes finais vejam.
Por exemplo, a Empresa A pode ter uma direção estratégica de apresentar a

seus clientes uma série de produtos para atender às suas necessidades,
enquanto a Empresa B decide que prefere apresentar a seus clientes um
produto maior. Ambas são opções válidas e nenhuma delas deve ser limitada
pela estrutura técnica de entrega de software. Isso precisa continuar sendo
uma escolha estratégica de negócios, e a tecnologia deve ser capaz de
para se adaptar o mais perfeitamente possível.
Isso preenche o abismo entre negócios e tecnologia.
Quando você pensa em um carro, qual é o produto? O motor, o sistema de entretenimento, a

direção, o ar condicionado, o próprio carro? Qual é exatamente o produto?
Como dito acima, comece com o cliente. Quem é o consumidor e quem é o comprador?
Se você está comprando o carro para si mesmo, então você é o comprador e o cliente. Se
você é um pai que compra um carro para seu filho, você é o comprador, mas a criança é o
consumidor.
As montadoras devem projetar produtos com ambos em mente. Os carros devem incluir airbags
e classificações de segurança para os pais e cores divertidas e sistemas multimídia para os
adolescentes.
Mas você pode olhar para isso de um ângulo diferente: a montadora é a compradora e também a
consumidora dos componentes do carro. Os produtos são os motores, sistemas de entretenimento,
airbags e assim por diante, produzidos por fornecedores ou mesmo por grupos internos.
Portanto, para conhecer seu produto, você precisa conhecer o consumidor e o comprador — os
clientes de seu produto.
24
9780134686479_web.indb 24 05/02/18 15h40

Voltando ao software, a Tabela 1-1 apresenta alguns exemplos realistas. Veja se

essas afirmações ainda são verdadeiras.
Tabela 1-1 Exemplos de produtos
Produtor Descrição Comprador Consumidor Produtor

Beneficiar
Microsoft Software de Empreendimento Empregado receita

escritório profissional ––––––– ––––––– (licenciamento)
para trabalho de usuário individual usuário individual

escritório diário ou
ocasional
Tecnologia Substitua o sistema Tecnologia Individual Redução de

Departamento de back-end herdado Departamento programadores custos (menores
dentro de um por uma API de serviço custos de manutenção)
organização da Web atualizada
Wikipédia Enciclopédia Doadores Buscadores de Benefício social
sem fins lucrativos informações

(informação
com colaboradores
gratuita)
voluntários
Central de Atendimento Um sistema para Central de Atendimento Cliente Redução de custos

cliente Agentes de (tempos de chamada
agentes de serviço para atendimento em Call Centermais curtos)
registrar chamadas
controle de qualidade Criação de testes controle de qualidade

interno Redução de
Departamento automatizados para Departamento Desenvolvimento custos (melhor qualidade)
desenvolvimento Equipes
times
O negócio Criação de O negócio ISTO Receita
Grupo de analistas documentos para Departamento Desenvolvimento (salário)

entregar ao TI para Departamento
implementação
Amazon.com site de varejo indivíduos indivíduos Receita (vendas)
Facebook Mídia social Anunciantes indivíduos Receita
(vendas de
publicidade)
Depois de identificar seu produto, a próxima pergunta é: “É um produto viável?”
25
9780134686479_web.indb 25 05/02/18 15h40

Um produto viável é aquele em que o benefício declarado do produtor se concretiza.

Isso significa que você deve ter maneiras de medir o benefício ao longo do caminho. O
Capítulo 3, “Valor”, explica mais sobre como fazer isso.
Por enquanto, considere isso uma grande responsabilidade de um Product Owner
para maximizar o ROI.
Os exemplos anteriores dos grupos separados de teste automatizado e análise de

negócios raramente produzem um ROI viável.
Reconhecidamente, você verá exemplos de iniciativas que falharam, uma e outra vez. O
grupo de testes automatizados está desenvolvendo um produto? Claro.
Mas o benefício declarado de melhor qualidade é viável? As outras equipes de
desenvolvimento adotarão ambientes de teste que não foram desenvolvidos por eles?
Quem manterá esse sistema de teste após sua implementação? O ROI raramente existe,
a menos que esses esforços residam nas próprias equipes de desenvolvimento.
Independentemente disso, é importante entender o custo e o benefício percebido e configurar
um mecanismo de feedback para garantir que o produto ainda seja viável.
Uma lição importante ao definir seu produto é ir o mais alto possível sem perder de vista
seus objetivos principais. Você precisa encontrar a área de valor certa do ponto de vista do
cliente. O que o cliente precisa e pelo que ele está disposto a pagar? O que fornece valor?
Voltando ao exemplo do carro, você compraria um volante ou um assento?

Você provavelmente deseja um produto utilizável, um carro completo neste caso. Este
produto oferece um benefício para você como consumidor.
Se você estruturar suas equipes abaixo das áreas de valor, verá muitos Product
Owners, com toda a sobrecarga de coordenação resultante. Imagine ter um Product Owner
separado para cada componente do carro sem uma visão realmente centralizada para o carro
inteiro como um produto (veja a Figura 1-12).
26
9780134686479_web.indb 26 05/02/18 15h40

ISTO
PMO Direção
Governança
Componente Componente Componente Componente Componente Componente Componente Componente Componente Componente Componente
UMA B C D E F G H EU J k
Figura 1-12 Um Dono do Produto para cada componente do carro
Agora, quando você adiciona um novo recurso ou uma grande iniciativa para uma área de
valor, ele precisa ser dividido em unidades de trabalho para cada um dos componentes afetados.
Isso cria uma sobrecarga enorme, com muitas dependências a serem gerenciadas e resultando
em escassez de habilidades, problemas de tempo, qualidade e integração. Para lidar com todas
essas dependências, você provavelmente precisará encontrar um proprietário de “recurso” para
cuidar de toda a coordenação e ser responsável pelo recurso. Alguns chamam essa função de
gerente de projeto (veja a Figura 1-13).
Gerente de Projetos também

característica característica característica
conhecido como
Proprietário do recurso
ISTO
PMO Direção
Governança
Componente Componente Componente Componente Componente Componente Componente Componente Componente Componente Componente
UMA B C D E F G H EU J k
Figura 1-13 Os gerentes de projeto são proprietários de recursos.
Os problemas mencionados acima podem levar ao seguinte:7
1. Ciclo de vida sequencial
As dependências dos vários componentes precisam estar alinhadas, o que requer um

plano que leve em consideração as transferências. Uma vez concluído o Componente B,
ele é entregue ao Componente F e assim por diante.
7. Cesário Ramos, “Scale Your Product NOT Your Scrum,” Scrum.org (fevereiro de 2016).
27
9780134686479_web.indb 27 05/02/18 15h40

2. Gerenciamento, coordenação e sobrecarga de dependências desnecessárias

complexidade do
gerenciamento Em uma abordagem orientada a planos, toda a coordenação das

dependências é deixada para os gerentes, muitos dos quais não são técnicos. Ao fornecer um
objetivo claro e deixar os detalhes de implementação para as equipes de recursos, você obtém
comprometimento e funcionalidade de trabalho mais rapidamente para revisão.
3. Trabalhando em recursos de baixo valor
O recurso é composto por funcionalidades de vários graus de valor, de muito baixo a muito
alto. Como todo o recurso está sendo decomposto e gerenciado e coordenado de cima para
baixo nos componentes, não há feedback para identificar funcionalidade de alto ou baixo valor.
4. Handoffs, dispersão de informações e alto estoque As
atividades de recursos individuais precisam ser concluídas antes que a próxima atividade
possa começar. A comunicação e a transferência de conhecimento nessas transferências
são feitas por documentos e especificações. Todas essas atividades intermediárias levam a
um alto estoque, informações espalhadas e muitas transferências.
5. Perda de foco no cliente e no produto como um todo
Quando o trabalho é organizado por atividades a serem realizadas por todas as equipes
componentes, naturalmente o cliente torna-se secundário. Existem dependências, desafios e
outros obstáculos suficientes para gerenciar que um cliente, especialmente um cliente que
fornece feedback, pode rapidamente se tornar um incômodo.
6. Medida opaca de progresso
A abordagem sequencial significa que você perde o feedback, o que significa que você está
preso medindo o progresso em direção ao seu plano, em vez de em relação às suas metas de
valor.
7. Trabalho inventivo
O que você faz quando sua equipe de componentes fica sem trabalho? Você precisa justificar
sua existência. Então você vem com “coisas importantes” que precisam ser feitas para que
você possa justificar a folha de pagamento de sua equipe.
28
9780134686479_web.indb 28 05/02/18 15h40

8. Má qualidade
Como você se concentra na qualidade de cada componente, perde de vista a
qualidade geral do recurso final. Essas otimizações locais são conhecidas por causar
problemas para o objetivo real. Além disso, problemas técnicos entre esses
componentes muitas vezes não são resolvidos corretamente por falta de tempo.
Lembra do plano a ser seguido? Isso leva a problemas de qualidade técnica a longo prazo.
Em vez de pensar em componentes, você precisa pensar em termos de um produto
(maior). Isso pode ir longe. Um Product Owner deve ser capaz de lidar com um grande
número de equipes de desenvolvimento para um único produto.
Lembre-se, o Dono do Produto ideal é um empreendedor – uma voz única para a visão do
produto, independentemente de seu tamanho. Uma empresa tem apenas um CEO, quer
tenha 100 ou 100.000 funcionários.
Isso é conhecido como a regra do Papai Noel. Não importa o quão ocupado o Papai Noel
esteja, ele não traz outros Papais Noéis. Como ele lida? Elfos.
À medida que os produtos crescem, os Product Owners devem se envolver menos com
as táticas do dia-a-dia de desenvolvimento de produtos e mais envolvidos com a estratégia
e a direção. Eles podem obter ajuda (elfos) de equipes, partes interessadas, assistentes
e assim por diante para o trabalho mais tático. Como Papai Noel, você pode delegar
responsabilidades, mas continua responsável pelo sucesso do Natal.
Se isso não for suficiente, divida o produto em domínios de valor no nível correto de
abstração (consulte a Figura 1-14). Isso também requer que você configure equipes de
recursos multifuncionais sob seu produto de acordo. A intercomunicação resultante é
essencialmente o comitê gestor, o Project Management Office (PMO) e a governança em
um único órgão. Isso resolve os problemas mencionados anteriormente.
29
9780134686479_web.indb 29 05/02/18 15h40

produtos
negócios e
TI trabalhando em conjunto
É aqui que os
ajudantes entram em jogo
Valor Valor
Domínio Domínio
Valor
Domínio
serviço compartilhado
Figura 1-14 Domínios de valor independentes com foco no cliente, compartilhando serviços comuns
Tive um cliente que tinha vários Product Owners para um grande produto.
A solução do cliente foi permitir que cada um selecionasse algo de sua
lista para o próximo Sprint, estilo round-robin. Embora isso possa parecer
justo a princípio, é a solução estratégica certa para a organização?
As equipes de desenvolvimento estão realmente trabalhando nos recursos
mais valiosos? Quem decide quais são os melhores recursos, considera
menos de quantas vozes existem? Essa pessoa é o verdadeiro Product Owner.
Os serviços compartilhados entre os domínios de valor representam gerenciamento

de dependência e integração em nível técnico. Com a integração contínua de hoje,
infraestrutura como código e automação de teste, essa área é bem compreendida. A
coordenação em nível técnico é muito mais previsível. Ou você tem um produto
funcionando ou não.
30
9780134686479_web.indb 30 05/02/18 15h40

Revisão do questionário
Revisão do questionário
Compare suas respostas do início do capítulo com as abaixo.

Agora que você leu o capítulo, você mudaria alguma de suas respostas?
Você concorda com as respostas abaixo?
Declaração Aceita Discordo
Cronograma, orçamento e escopo são as melhores formas de medir o desempenho do projeto ÿ

sucesso.
O gerenciamento de produtos é uma prática essencial para os Product Owners. ÿ
Um Product Owner deve atuar como um proxy entre o negócio e ÿ

a tecnologia.
Um Product Owner estabelece uma visão para um produto. ÿ
O Scrum fornece todas as ferramentas necessárias para o sucesso do produto ÿ

gestão.
Todo esforço de desenvolvimento tem um produto. ÿ
31
9780134686479_web.indb 31 05/02/18 15h40

O Guia do Proprietário do Produto Profissional para

Maximizando valor com Scrum
“Este livro apresenta um método de comunicar nossos desejos, de forma
convincente, coerente e com o mínimo de confusão e incômodo.”
—Ken Schwaber, presidente e fundador, Scrum.org
O papel do Product Owner é mais crucial do que nunca. Mas é muito

mais do que mecânica: trata-se de assumir a responsabilidade e
reorientar o valor como o objetivo principal de tudo o que você faz. Em The
Professional Product Owner, dois dos principais especialistas em propriedade
de produtos Scrum bem-sucedidos, Don McGreal e Ralph Jocham, mostram
exatamente como fazer isso. Você aprenderá como identificar onde o valor
pode ser encontrado, medi-lo e maximizá-lo durante todo o ciclo de vida do
produto.
McGreal e Jocham orientam você em todas as facetas da concepção,

surgimento e amadurecimento de um produto usando a estrutura Scrum. Eles
discutem estratégias, estabelecem as melhores práticas para gerenciar a
complexidade e entregar valor continuamente e definem as práticas e
PEDIR E SALVAR ferramentas concretas que você pode usar para gerenciar Product Backlogs e
planos de lançamento, tudo com o objetivo de torná-lo um Product Owner mais
Economize 35% ao fazer o pedido bem-sucedido. Ao longo, os autores compartilham experiências pessoais
reveladoras que iluminam os obstáculos ao sucesso e mostram como eles
de informit.com/TPPO e digite o código
podem ser superados.
SCRUMORG durante a finalização da compra
• Definir o sucesso de “de fora para dentro”, usando medições externas

FRETE GRÁTIS para os EUA em livros impressos voltadas para o cliente para orientar o desenvolvimento e maximizar o valor
Principais formatos de e-book

• Trazer empoderamento e empreendedorismo para o
Somente o InformIT oferece PDF, EPUB e
A função do proprietário do produto e alinhar todos por trás de um
MOBI juntos por um preço modelo de negócios compartilhado • Use o gerenciamento baseado
em evidências (EBMgt) para investir nos lugares certos, tomar decisões mais
inteligentes e reduzir riscos
OUTRAS DISPONIBILIDADES
• Aplicar efetivamente a função de Product Owner do Scrum, artefatos,

Através da O'Reilly Safari serviço de e eventos
assinatura
• Preencher e gerenciar Product Backlogs e usar especificações just-in-time •
Livreiros e varejistas online, Planejar e gerenciar lançamentos, melhorar a transparência e
incluindo loja Amazon/Kindle e Barnes
& Noble | bn.com reduza a dívida técnica •
Escale seu produto, não seu Scrum • Use Scrum
para injetar autonomia, domínio e propósito no trabalho de sua equipe de
produto

Livro The Professional Po Ingles

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro The Professional Po Ingles

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

O Guia do Proprietário do Produto Profissional para

—Ken Schwaber, presidente e fundador, Scrum.org

O papel do Product Owner é mais crucial do que nunca. Mas é muito

McGreal e Jocham orientam você em todas as facetas da concepção,

• Definir o sucesso de “de fora para dentro”, usando medições externas

Principais formatos de e-book

• Aplicar efetivamente a função de Product Owner do Scrum, artefatos,

9780134686479_web.indbiii 05/02/18 15h40

Para consultas sobre vendas governamentais, entre em contato com cities@pearsoned.com.

Visite-nos na Web: informit.com/aw

Número de controle da Biblioteca do Congresso: 2018934196

Copyright © 2018 Scrum.org

9780134686479_web.indb iv 05/02/18 15h40

9780134686479_web.indb v 05/02/18 15h40

Capítulo 1 Questionário sobre gerenciamento ágil de 3

produtos Mentalidade de produto versus 3

O vácuo de gerenciamento de produtos e os três Vs 9

Gestão de Produtos e Scrum 15

9780134686479_web.indb vii 05/02/18 15h40

Prático versus Emocional 46

Visão com Scrum 50

Gestão Baseada em Evidências 65

Para onde vai o seu dinheiro 85

Produto Mínimo Viável através de Kano 98

9780134686479_web.indb viii 05/02/18 15h40

Padrões MVP 102

Mineração MVP 103

MVP da página de destino 103

MVP de recurso único 104

Revisão do questionário 108

PARTE II Scrum 109

capítulo 5 Empirismo 111

É um problema complexo 111

Questionário de Certeza 115

Visualizando Complexidade 116

Juntando tudo 123

Tipos de Complexidade 126

Gestão de risco 126

Revisão do questionário 133

Capítulo 6 Scrum Quiz Por 135

Equipe de desenvolvimento 145

9780134686479_web.indb ix 05/02/18 15h40

Scrum Master 149

Lista de pendências do produto 155

Sprint Backlog 157

Planejamento do Sprint 167

Reunião Diária 173

Revisão do Sprint 176

Retrospectiva da Sprint 179

Manifesto Ágil para Desenvolvimento de Software 186

Revisão do questionário 188

PARTE III táticas 189

Capítulo 7 Gerenciamento do Backlog do Produto 191

Questionário O que é um requisito? 192

Histórias de usuários do 193

Requisitos não Funcionais 199

Critérios de Aceitação 205

Pedidos do Backlog do Produto 209

Medindo valor, risco e tamanho 213

Definição de exemplo de "Concluído" 220

9780134686479_web.indb x 05/02/18 15h40

“Pronto” é uma mentalidade 224