Estratégia Lean

Prévia do material em texto

Estratégia Lean
o caminho mais rápido e seguro para
inovação e transformação digital
Paulo Caroli e Joaquim Torres
(Joca)
Estratégia Lean
o caminho mais rápido e seguro para
inovação e transformação digital
Paulo Caroli e Joaquim Torres (Joca)
Esse livro está à venda em http://leanpub.com/leanpmo
Essa versão foi publicada em 2020-01-23
Esse é um livro Leanpub. A Leanpub dá poderes aos autores e
editores a partir do processo de Publicação Lean. Publicação Lean
é a ação de publicar um ebook em desenvolvimento com
ferramentas leves e muitas iterações para conseguir feedbacks dos
leitores, pivotar até que você tenha o livro ideal e então conseguir
tração.
© 2015 - 2020 Paulo Caroli e Joaquim Torres (Joca)
http://leanpub.com/leanpmo
http://leanpub.com/
http://leanpub.com/manifesto
Outras Obras Desses Autores
Livros De Paulo Caroli
Fun Retrospectives
Optimizing The Flow
Direto ao ponto
Retrospectivas Divertidas
Fun Retrospectives
DevOps para entrega de produtos enxutos
Lean Inception
7 passos para definir a estratégia do seu time
Enxugando a Máquina
Whisky, Sushi, Systems & Flow
The Lean Product Guide
O Modelo 4 E
MyStartUp
Produktmanagement
Consciência Digital
Transformação digital
Lean Inception
Diagrama de Fluxo Cumulativo
Cumulative Flow Diagram
Management 3.0
Lean Software Engineering
A verdadeira história de um time em formação após a Lean
Inception
http://leanpub.com/u/paulocaroli
http://leanpub.com/funretrospectives
http://leanpub.com/optimizingtheflow
http://leanpub.com/diretoaoponto
http://leanpub.com/retrospectivas
http://leanpub.com/lasretrospectivas
http://leanpub.com/devopsmvp
http://leanpub.com/directoalpunto
http://leanpub.com/estrategiadotime
http://leanpub.com/enxugando-a-maquina
http://leanpub.com/whiskysushisystemsflow
http://leanpub.com/leanproduct
http://leanpub.com/omodelo4e
http://leanpub.com/mystartup
http://leanpub.com/produktmanagement
http://leanpub.com/conscienciadigital
http://leanpub.com/transformacao
http://leanpub.com/leaninception
http://leanpub.com/diagramadefluxocumulativo
http://leanpub.com/cfd
http://leanpub.com/management30
http://leanpub.com/leanengineering
http://leanpub.com/apos-lean-inception
http://leanpub.com/apos-lean-inception
Lean Product Development: Guiando a Construção do MVP com
Scrum e Kanban
Livros De Joaquim Torres (Joca)
Product Management
Produktmanagement
Transformação digital
http://leanpub.com/lean-delivery
http://leanpub.com/lean-delivery
http://leanpub.com/u/joca
http://leanpub.com/productmanagementsuccess
http://leanpub.com/produktmanagement
http://leanpub.com/transformacao
aos amigos do Sicredi, corporação exemplar na busca de mais
agilidade, enquanto mantém o equilíbrio com a estrutura
organizacional.
Conteúdo
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . ii
Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . iii
Sobre este livro . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Sobre o Lean PMO . . . . . . . . . . . . . . . . . . . . . . iv
Simples é diferente de simplório . . . . . . . . . . . . . . . 1
Unidade de Negócio - UN . . . . . . . . . . . . . . . . . . 1
Estratégia, UN, OKR e MVP . . . . . . . . . . . . . . . . . 2
Os três horizones - 3Hs . . . . . . . . . . . . . . . . . . . . . 4
Horizonte 1 – estável . . . . . . . . . . . . . . . . . . . . . 5
Horizonte 2 – emergente . . . . . . . . . . . . . . . . . . 6
Horizonte 3 – experimento . . . . . . . . . . . . . . . . . 7
De H3 para H2 . . . . . . . . . . . . . . . . . . . . . . . . 7
De H2 para H1 . . . . . . . . . . . . . . . . . . . . . . . . 7
Experimento, resultado, receita . . . . . . . . . . . . . . . 9
Os 3Hs e este livro . . . . . . . . . . . . . . . . . . . . . . 9
O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 11
Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
CONTEÚDO
Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Priorização relativa por VALOR e ESFORÇO . . . . . . . . 15
Definindo VALOR . . . . . . . . . . . . . . . . . . . . . . 16
Compreendendo ESFORÇO . . . . . . . . . . . . . . . . . 18
NOTA da iniciativa . . . . . . . . . . . . . . . . . . . . . . 19
Cálculo de NOTAs, um exemplo . . . . . . . . . . . . . . 19
Várias iniciativas . . . . . . . . . . . . . . . . . . . . . . . 21
Iniciativa NOTA 10 . . . . . . . . . . . . . . . . . . . . . . 23
Sessão colaborativa de preenchimento da tabela de pri-
orização . . . . . . . . . . . . . . . . . . . . . . . . 23
Moedas da organização . . . . . . . . . . . . . . . . . . . 28
Risco ou realidade . . . . . . . . . . . . . . . . . . . . . . 28
Outros modelos para priorização . . . . . . . . . . . . . . . 30
Priorização absoluta . . . . . . . . . . . . . . . . . . . . . 30
Priorização do Hipopótamo . . . . . . . . . . . . . . . . . 30
Priorização por decibéis . . . . . . . . . . . . . . . . . . . 31
Priorização The Flash . . . . . . . . . . . . . . . . . . . . 31
Priorização rapa do tacho . . . . . . . . . . . . . . . . . . 32
Funding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Objetivos de negócio e funding . . . . . . . . . . . . . . . 34
Funding e os 3 Hs . . . . . . . . . . . . . . . . . . . . . . . 35
Funding e capacidade de Negócio . . . . . . . . . . . . . 35
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
MVP – Produto Mínimo Viável . . . . . . . . . . . . . . . . 37
MVP e o Fluxo de trabalho . . . . . . . . . . . . . . . . . 37
Lean Inception . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 39
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CONTEÚDO
O MVP nas cerimônias do scrum . . . . . . . . . . . . . . 43
Construindo MVP com Kanban . . . . . . . . . . . . . . . . 45
Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
O MVP no Kanban . . . . . . . . . . . . . . . . . . . . . . 48
Arquitetura Mínima Viável (MVA) . . . . . . . . . . . . . . 60
Micro-serviços de Domínio . . . . . . . . . . . . . . . . . 62
Acompanhamento Lean . . . . . . . . . . . . . . . . . . . . . 63
O entendimento da iniciativa via MVP . . . . . . . . . . 63
O planejamento do produto e seus MVPs . . . . . . . . . 64
O acompanhamento da criação do produto via MVP . . 66
Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 69
Os eixos do burn up . . . . . . . . . . . . . . . . . . . . . 71
O ritmo da construção do MVP . . . . . . . . . . . . . . . 71
Verificando o progresso . . . . . . . . . . . . . . . . . . . 73
A linha de escopo do MVP . . . . . . . . . . . . . . . . . 75
Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 77
Nome do time e ID do MVP . . . . . . . . . . . . . . . . . 78
Nome do MVP . . . . . . . . . . . . . . . . . . . . . . . . 78
Estado atual (verde / amarelo / vermelho) . . . . . . . . . 78
Data atual e data prevista . . . . . . . . . . . . . . . . . . 78
Lista de features do MVP . . . . . . . . . . . . . . . . . . 79
Nível de incerteza da funcionalidade(verde / amarelo /
vermelho) . . . . . . . . . . . . . . . . . . . . . . . 79
Estado e % de completude da funcionalidade . . . . . . . 79
Detalhamento e texto descritivo . . . . . . . . . . . . . . 80
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Analysis paralysis . . . . . . . . . . . . . . . . . . . . . . 91
CONTEÚDO
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Objetivos e Resultados Chaves - OKR . . . . . . . . . . . . 94
Planejamento Contínuo . . . . . . . . . . . . . . . . . . . . . 103
Aposta e quantidade de fichas . . . . . . . . . . . . . . . 103Do OKR ao MVP, estamos alinhados! . . . . . . . . . . . . 105
OKRit - OKR, iniciativas e tarefas . . . . . . . . . . . . . . 107
Sobre Pivotar . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Um caso prático . . . . . . . . . . . . . . . . . . . . . . . . 111
Disclaimer
Eu escrevendo sobre Lean, mas sem colocar limite no WIP, e
escrevendo vários E-Books ao mesmo tempo…
Pois bem, então vou tratar os E-Books como MVPs. Se já tem algo
minimamente viável para passar a ideia, o conceito, então vou
liberar.
Por isso neste E-Book você vai encontrar erros de ortografia,
imagens em versões iniciais, e texto por escrever.
Mas como um bom MVP, estou muito interessado no seu feedback.
Abraços,
Caroli
paulocaroli@gmail.com
Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Agi-
leBrazil, Paulo Caroli possui mais de vinte anos de experiência
em gestão e desenvolvimento de software, com passagem em
varias corporações no Brasil, Índia e EUA . Em 2000, conheceu o
Extreme Programming e, desde então, tem mantido seu foco em
processos e práticas de gestão e desenvolvimento ágil. Ingressou
na ThoughtWorks em 2006 e ocupou os cargas de agile coach,
treinador, e Gerente de Projetos. Possui os títulos de Bacharel em
Ciência da Computação e MS em Engenharia de Software, ambos
da PUC -Rio. Autor dos Livros ” Direto Ao Ponto; Criando Produtos
de forma enxuta” , e “Fun Retrospectives; activities and ideas for
making agile retrospectives more engaging”.
Paulo Caroli
Acompanhe Paulo Caroli no seu site e nas redes sociais:
Sobre a Editora Caroli
A Editora Caroli nasceu em 2017, quando Paulo Caroli decidiu
realizar todos os passos desde escrever um livro a impressão e venda
do mesmo. Este livro é O Mistério do Colégio Alipus.
Paulo Caroli seguemuito do seu aprendizado no Vale do Silício para
a criação de conteúdo e publicação de livros. Com um estilo Lean
StartUp (construir fazendo) nasceu a Editora Caroli.
Caroli constituiu uma editora para publicar seus livros e para ajudar
a publicar livros de amigos.
WIP (Writing In Progress)
A Editora Caroli apresenta uma nova proposta de trabalho, apro-
ximando autores dos seus leitores desde o início da geração do
conteúdo. Porque esperar o autor terminar de escrever para ver se o
conteúdo é bom? Nomundo atual isso não faz mais sentido. Então a
Editora Caroli promove o compartilhamento (gratuito sempre que
possível) do WIP (Writing In Progress) através dos formatos eBook
(pdf, mobi e epub). Desta forma, leitores tem acesso rápido as novas
ideias, e podem fazer parte da evolução da obra. Para os autores,
esse é uma forma efetiva de feedback e motivação para a geração
de conteúdo.
Este e outros eBooks estarão disponíveis no site http:
//caroli.org
http://caroli.org
http://caroli.org
Sobre este livro
Este livro vem evoluindo desde 2014, ano em que liderei uma
transformação digital de uma excelente corporação.
Naquela época eu ajudei a diminuir a distância existente entre
dois mundos: metodologias ágeis e o PMO, abreviação para Project
Management Office, em Inglês. Eu percebi que não estava somente
levando algumas práticas ágeis para os projetos e para o PMO, mas
sim estava usando práticas Lean para aproximar esses dois mundos.
Por esse motivo esse trabalho foi nomeado Lean PMO, onde eu
indicava que o P de PMO deveria ser para Produtos, ao invés de
Projetos.
Mas o conteúdo do livro e o feedback recebido pelo mesmo evolui.
E este foi utilizado por diferentes organizações, independente da
estrutura de PMO. Por tal motivo o nome foi alterado de Lean PMO
para Lean Strategy.
Sobre o Lean PMO
PMO (abreviação de Project Management Office em Inglês ou
Escritório de Gestão de Projetos em Português) é uma unidade
organizacional que conduz e dá suporte aos grupos de Gestão de
Projetos.
Desde 2000, os métodos ágeis vem evoluindo e sendo aplicados nas
organizações. Atualmente todas organizações usam alguma coisa
de métodos ágeis. E o PMO já vem se adaptando em relação a isso.
Vide a evolução do PMBOK nos últimos anos, incluindo ágil no seu
vocabulário.
Sobre este livro v
Mas a maior mudança vem da transformação digital que coloca
o cliente no centro do universo. Produtos digitais são criados e
evoluem baseado no feedback real dos seus usuários. E isso que vem
gerando uma reorganização nas empresas, atuando sobre produtos
mais que projetos.
Como conduzir e dar suporte a essas novas empresas? O PMO
tradicional não funciona. Um pouco de agilidade no processo ajuda,
mas ainda não resolve. O novo foco é em Produtos!
Simples, trocamos o P de PMO de Project para Product. Mantemos
a sigla, mantemos a unidade organizacional. Mas ajustamos o
objetivo: conduzir e dar suporte a estratégia e gestão de Produtos.
Eu tenho utilizado muitos conceitos e práticas Lean nesta área. Por
isso criei este eBook com o nome de Lean Strategy, que compartilho
aqui.
Seja parte da criação e evolução deste eBook!
Os conceitos aqui apresentados estão sendo colocados a prova em
várias corporações. Em 2017 os resultados se mostram valiosos. A
partir deles, estou descrevendo o que está funcionando.
Simples é diferente de
simplório
Este livro apresenta um modelo simples para te ajudar com uma
estratégia mais enxuta e efetiva. Mas não confunda simples com
simplório. Para alcançar este modelo simples, alguns anos se passa-
ram na busca e confecção do mesmo. Somente depois de cinco anos
de tentativas e maturidade do mesmo, compartilho este modelo
simples.
Unidade de Negócio - UN
Os conceitos compartilhados neste livro foram aplicados em várias
organizações, desde pequenas StartUps a grandes empresas com
variadas estruturas organizacionais. Por esse motivo decidi descre-
ver neste livro algo prático para ser utilizado por uma unidade de
negócio (UN para abreviação), onde UN rerpesenta uma unidade
de negócio independente com resultados, estratégia, processos,
gestores e equipes distintas.
Simples é diferente de simplório 2
Unidades de Negocio - UN
No caso de uma pequena startUp, a própria compõe a UN. Grandes
corporações são formadas por várias UNs.
Os conceitos apresentados neste livro se aplicam a UNs mais ágeis,
que buscam uma estratégia e processo mais enxuto (Lean) para
suceder com produtos digitais. Considero este livro mais útil para
UNs com maior foco em H2 (do que H1 ou H3, conforme descrito
no capítulo os Três Horizontes).
Estratégia, UN, OKR e MVP
Os OKRs (mais detalhes no capítulo OKR) ajudam a definir o
direcionamento estratégico da UN. Mas precisamos transformar
estratégia em ação. Precisamos priorizar as iniciativas, criá-las e
medir seus resultados.
Para tanto, utilizamos os MVPs (mais detalhes no capítulo MVP).
Iniciativas priorizadas passam por um workshop de Lean Inception
(mais detalhes no capítulo Lean Inception), onde são compreen-
didas e planejadas via MVP, o produto mínimo viável, ou seja,
o mínimo necessário para verificar o direcionamento inicial da
iniciativa.
Dessa forma, o MVP funciona como a ponte entre o estratégico
e o tático, conectando as expectativas estratégicas da UN com a
Simples é diferente de simplório 3
realidade da evolução e inovação dos seus produtos, segundo as
métricas (mais detalhes no capítulo Métricas) de uso dos mesmos.
<imagem MVP como ponte, de um lado a estratégia, do outro o
operacional, quem cria o MVP>
Desta forma o MVP serve como mediador da conversa entre as
pessoas mais estratégicas –correlacionando MVPs com OKRs e
outras iniciativas da UN– e as mais operacionais, que detalham as
funcionalidades e tarefas necessários para a sua criação. Entretanto,
todos comparam o resultado esperado com o resultado atual do
MVP, demonstrado por suas métricas de uso.
A estratégia do negócio passa a ser assunto e responsabilidade de
todos. Todos compreendem osMVPs, bem como esses se relacionam
e auxiliam com os OKRs da UN.
Os três horizones - 3Hs
A estrutura de três horizontes da McKinsey ¹fornece uma nomen-
clatura para: o momento atual (horizonte 1), um futuro próximo
(horizonte 2) e um futuro maisdistante (horizonte 3). Empresas
inovadoras distribuem seu portfólio de investimento de acordo com
esses três horizontes.
os 3 Horizontes de crescimento
¹A Alquimia do Crescimento - os Segredos das 30 Empresa que Mais Crescem no Mundo,
por Baghai, Mehrdad; Editora Record 1999
Os três horizones - 3Hs 5
os 3 Horizontes de crescimento
< qual imagem está melhor? >
A McKinsey realizou estudos e pesquisas sobre como as empresas
sustentam o crescimento. Com base nessas pesquisas, criou-se a
estrutura de três horizontes, uma abordagem que ilustra como ge-
renciar para o desempenho atual, entretanto maximizando futuras
oportunidades de crescimento.
Desde o lançamento do meu livro ²sobre a criação de produtos
de forma enxuta, baseado no conceito de MVP –produto mínimo
viável, ou Minimum Viable Product, em inglês– tenho buscado
um melhor esclarecimento sobre experimentos, MVP e produtos
estabelecidos. Encontrei na estrutura dos três horizontes uma boa
forma de expressar o meu entendimento e sugestão sobre a gestão
de portfólio e investimento em produtos e inovação.
Horizonte 1 – estável
No horizonte 1 estão as vacas leiteiras, aqueles produtos já cresci-
dos, estáveis e que estão gerando o sustento da empresa atualmente.
²Direto ao ponto: criando produtos de forma enxuta, Paulo Caroli, Casa do codigo, 2016
Os três horizones - 3Hs 6
Talvez esses já não tenham muito investimento em novo desen-
volvimento. A maior parte do investimento está em operação, em
mantê-lo funcionando e atendendo as necessidades atuais do seu
cliente.
Horizonte 2 – emergente
O horizonte 2 mostra o que está por vir num futuro próximo (em
alguns meses ou anos, dependendo do nicho de mercado). São
os produtos ou features emergentes. Aqueles que requerem mais
investimento em desenvolvimento e criação do que em operação (a
base de usuários e/ou a exposição do produto ainda é pequena).
Invista nas bezerras
O investimento em H2 é o gasto com suas bezerras, aquelas que são
candidatas a futuras vacas leiteiras. Lembre-se que as atuais vacas
leiteiras vão ficar velhas e vão secar. Logo, você precisa investir
nessas bezerras!
Mas nem toda bezerra vai virar uma boa vaca leiteira. Isso faz parte
do negócio. Aprendi isso com meu avô que criava gado leiteiro: ou
segue apostando na bezerra (pois começou a dar leite), ou pivota seu
uso (deixa para reproduzir, talvez gerando alguma vaca leiteira), ou
desiste (pare de gastar com essa bezerra pois ela não vai virar uma
vaca leiteira; bom, nesse caso a pobrezinha ia para o abate).
Prosseguir, pivotar, ou cancelar. Esse é o mantra para os
produtos e as features emergentes.
Os três horizones - 3Hs 7
Horizonte 3 – experimento
O horizonte 3 é um futuro bem distante, anos ou décadas, depen-
dendo do seu nicho de mercado.
E a metáfora da vaca acaba aqui. No horizonte 3 você nem sabe o
que vai estar dando o sustento da fazenda. Simples assim. Pode ser
uma criação de ovelhas de raça, búfalos leiteiros, plantação de soja,
minério, aeroporto para marcianos, etc.
É experimento. Ideias e mais ideias. Algo bem distante. Talvez até
inimaginável com o seu conhecimento atual.
São experimentos, coisas para te fazerem pensar, para te ajudarem
a entender ummundo novo que ainda nem se formou. Talvez até te
tirando da zona de conforto (por exemplo um engenheiro da Kodak
com seus experimentos sobre fotografia digital em 1974).
De H3 para H2
Mas assim como a vaca atual está secando, a bezerra também vai
secar, e lá na frente, você vai precisar de alguma ideia nova. Algo
que brote e possa emergir.
Agora sim, posso ressaltar que o investimento em H2 ou é para
algo próximo ao seu produto atual (uma bezerra que também vai
dar leite) ou é algum experimento que já se mostrou interessante,
ou seja, algo que veio de H3 para H2.
De H2 para H1
O movimento de H2 (emergir) para H1 (estável) é comum nas
empresas. E isso era o suficiente no século passado, para muitos
nichos de mercado.
Os três horizones - 3Hs 8
Mas o mundo mudou. Com o advento da internet, da mobilidade,
das redes sociais, e a computação nas nuvens, tudo ficou acelerado.
O H3 era muito distante, e provavelmente não iria derrubar um
CEO. Ele se aposentaria antes disso.
Agora é diferente. O H3 chega mais rápido. E com ele, a inovação
disruptiva, aquela que altera o seu negócio pela raiz. Que vai
derrubar um CEO após o outro, e tirar a empresa do mercado.
A mensagem é clara: quem não investir em experimentos não vai
sobreviver. É questão de tempo. Quem não se reinventar vai ficar
de fora.
E não é investimento realizado em H1 e H2. Aqueles onde existe
ROI e/ou NPL. São investimentos em experimentos. Sem resultados
esperados. É investimento em H3.
Mas cuidado. No momento que se coloca expectativa de resultado
no experimento, ele deixa de ser um experimento. Em contrapartida
um MVP tem uma expectativa de resultado. Um MVP deve colocar
uma hipótese a prova: será que essa bezerra vai dar leite?
Cuidado, você pode estar se iludindo e chamando H2 de H3. Não
confunda um H3 que entrou para H2 com algo que começa com
H2. MVP é H2. É algo com resultado esperado e com expectativa de
emergir.
H3 são experimentos. Criatividade, liberdade, observação. É pes-
quisa, é experimento, é aprendizado. H3 busca ideia e conheci-
mento. Não busca resultado. Mais que validar uma hipótese, H3
ajuda a formular as hipóteses.
H3 deve gerar muitos dados. Talvez até dados divergentes para
serem analisado de vários ângulos diferentes, para gerar novas
perspectivas. Até que saia dali uma ideia mais evoluída. Algo que
ajude a formar uma hipótese. Algo para o qual possamos elaborar
um MVP, e colocar a hipótese a prova.
Perceba a diferença: em H2 temos um resultado esperado. Podemos
Os três horizones - 3Hs 9
descrevê-lo, colocá-lo num canvas ³, criar, e verificar se estamos
alcançando o resultado esperado. Poderemos decidir entre pivotar,
cancelar ou prosseguir.
Mas em H3 não. Não temos resultado, mas sim um processo para
experimentação: criatividade, liberdade, observação. E depois, se
alguém der sentido de algo que apareça dentre os vários experi-
mentos, formulamos uma hipótese.
Experimento, resultado, receita
Em H1 o foco é na receita. Quando a vaca leiteira começar a secar,
planejamos a sua descontinuação.
Em H2 o foco é no resultado. Melhores resultados indicarão as
melhores vacas leiteiras, onde deveremos dar mais atenção, afinal
de contas, esse será o nosso sustento. Na busca de resultados,
decidimos frequentemente: prosseguir, pivotar, ou cancelar.
Em H3 o foco é no processo de experimentação; Seja de forma mais
defensiva, onde a empresa reconhece a aceleração do seu nicho
de mercado e decide o quanto vai dedicar a experimentos. Seja de
forma mais agressiva, onde a empresa experimenta para atacar (ser
disruptiva) em novos mercados.
Os 3Hs e este livro
Este assunto de 3Hs deve ter despertado seu interesse para repensar
o portfolio de investimento da sua emrpesa.
Como está portfólio de investimento da sua empresa? Está alinhado
com a velocidade deste novo mundo?
³O Canvas MVP para definir a estratégia do Produto Mínimo Viável, por Paulo Caroli;
disponível em www.caroli.org/o-canvas-mvp . Acesso em agosto de 2018.
Os três horizones - 3Hs 10
Espero que você consiga alocar budget para cada um dos 3Hs.
Mas te digo que cada um desses horizontes requer uma forma de
trabalhar distinta. Considero omodelo apresentado neste livromais
adequado para iniciativas e UNs com maior foco em H2.
O ciclo PDCA do Lean
Strategy
O PDCA do Lean Strategy
Esse é o ciclo do PDCA: Tudo começa a partir de um workshop
de OKR (em Inglês, Objectives and Key Results) para a Unidade de
Negócio (UN).
Workshops de ideação, workshops de discovery, fases de entendi-
mento, pesquisa de mercado, resultado de pesquisa ou trabalho de
agência, lista de desejos, planilha da diretoria; seja lá o estilo da sua
empresa, a lista de iniciativas é compilada. O que não aponta para
um norte identificado pelos OKRs já pode ser descartado.
Então várias iniciativas (candidatas) da UN sãoconsideradas em
um workshop de priorização relativa, onde essas são avaliadas
quantitativamente, considerando o valor e o esforço de cada uma
(PLAN).
O próximo squad disponível puxa a iniciativa priorizada (sistema
O ciclo PDCA do Lean Strategy 12
puxado) para um workshop de Lean Inception, onde todos juntos
(negócio, tecnologia e UX) compreendem e criam o plano para a
criação do MVP. Seguindo as práticas Scrum, Kanban e DevOps, o
squad constrói o MVP (DO).
Assim que o MVP está pronto, este é liberado para os seus usuários
finais. Os dados de uso são coletados e compilados como métricas
a serem analisadas (CHECK).
Comparando o resultado obtido com o resultado esperado do MVP,
decidimos como prosseguir com a iniciativa: pivotar, prosseguir,
ou cancelar. Esta decisão é realizada perante os resultados apre-
sentados por todas as iniciativas em andamento, seus MVPs, a
capacidade, o budget, os investimentos, e o alinhamento com os
OKRs da UN (ACT). Com base nesses parâmetros, decidimos,
estrategicamente, quais iniciativas começar, quais continuar, quais
pivotar, e quais cancelar.
O PDCA do Lean Strategy completa um ciclo no workshop de
Lean Strategy, onde verificar investimentos, OKRs, iniciativas em
andamento, MVPs e novas iniciativas. E depois voltamos para o
início do ciclo com um novo workshop de OKR, seguido pela
listagem das iniciativas, workshop de priorização… até o próximo
workshop de Lean Strategy. Reuniões bissemanais são utilizadas
para acompanhar os OKRs da UN.
O modelo Lean Strategy traz disciplina para priorizar, construir,
medir, e coordenar esforços para alcançar os objetivos estratégicos
do negócio.
Plan
Vamos planejar as ações estratégicas organizacionais para alcançar
nossos objetivos. Para tanto, vamos usar um portfolio dinâmico, que
nos permita compreender e agrupar as iniciativas, permitindo tanto
O ciclo PDCA do Lean Strategy 13
(1) uma priorização, inicial, quanto (2) o redirecionamento baseado
no feedback de cada iniciativa.
Do
Dado uma iniciativa priorizada, vamos compreendê-la, e executá-la
de forma enxuta, ágil e centrada no feedback dos nossos usuários.
Para tanto faremos entregas rápidas e frequentes.
Check
Medimos o uso de cada entrega. Essas métricas são essenciais para
validação de hipóteses e ajustes na evolução de nossas iniciativas,
baseado no feedback de uso.
Act
Decidimos como proceder com cada iniciativa: pivotar, prossegir,
ou cancelar. Vamos rever as hipóteses iniciais (PLAN) e os dodos
de uso dos MVPs (CHECK). Iremos também comparar as diversas
iniciativas perante o orçamento da Unidade de Negócio (UN).
Plan
Priorização relativa por
VALOR e ESFORÇO
“Esta iniciativa é importante?”
Sempre obtive a mesma resposta quando fiz tal pergunta em uma
reunião sobre portfolio. Por isso, não a faço mais. A pergunta mais
relevante para te ajudar a priorizar as iniciativas é:
“Qual dessas duas é mais prioritária?”
Desta forma as iniciativas são priorizadas relativamente umas
às outras. Essa pergunta é muito útil e deve ser utilizada, mas
precisa de uma forma imparcial de responder a pergunta, ou pelo
menos, uma forma objetiva, que auxilie a um grupo de pessoas a
compreender as escolhas.
A forma mais objetiva que conheço é dinheiro. Essa é simples. E
desde que somos bem pequenos sabemos a diferença entre uma nota
de 2 reais e uma de 50 reais.
Por esse motivo eu aconselho uma forma de priorizar baseada
em algo vinculado a valor financeiro. Aliás aconselho uma forma
de trabalhar descrita pelo magnífico Dan Reinertsen no seu livro
Principles of Product Development Flow⁴: Cost of delay e CD3.
Cost of Delay (abreviado como COD) é o valor associado ao custo
de atraso de uma iniciativa; ou seja, qual valor acreditamos estar
deixando de ganhar por tal iniciativa ainda não estar pronta.
Por exemplo, iniciativa A tem um COD de 1000 dólares por mês,
enquanto iniciativa B tem um COD de 2000 dólares por mês.
⁴Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean
Product Development. Celeritas Publishing, 2009.
Priorização relativa por VALOR e ESFORÇO 16
Mas antes que você pense e diga que devamos priorizar iniciativa
B, tem de considerar qual esforço associado para criar tal iniciativa.
Por exemplo, iniciativa A requer um mês de trabalho, enquanto
iniciativa B requer quatro meses de trabalho.
1000 dólares por mês depois de ummês de trabalho vale mais a pena
do que 2000 mil dólares por mês com quatro meses de trabalho.
Logo é melhor fazer primeiro a iniciativa A, depois a iniciativa
B. Essa conta de COD / duração também tem um nome e uma
abreviação: Custo de Atraso por Duração, CD3.
Definindo VALOR
A cálculo do valor de Cost of Delay é complicado. Afinal de contas,
como decidir e afirmar: eu acredito que a iniciativa A vá nos trazer
100.000 dólares por mês; e acredito que a iniciativa B traria 200.000
dólares por mês.
Minha primeira recomendação é não usar valoresmonetários (como
dólares ou reais), mas somente valores. Assim sendo, definimos a
escala de valores entre 0 e 10. Logo todas iniciativas devem ter um
valor entre 0 e 10. Por exemplo: iniciativa A tem o valor 3 enquanto
iniciativa B tem o valor 6.
Minha segunda recomendação é que esses valores estejam atrelados
a dois tipos de expectativas: (1) expectativa de uso vinculado a tal
iniciativa, e (2) expectativa do negócio vinculado a tal iniciativa.
Para (1), eu gosto dos parâmetros utilizados pelo método RICE⁵,
segundo por SeanMcbride, gerente de produtos da Intercom. RICE é
um acrônimo para as iniciais de Reach, Impact, Confidence e Effort
(assunto da próxima sessão).
⁵post descrevendo o método RICE, segundo por SEAN MCBRIDE ,PRODUCT MANA-
GER, DA INTERCOM; disponível em https://blog.intercom.com/rice-simple-prioritization-for-
product-managers/ . Acesso em Agosto de 2018
Priorização relativa por VALOR e ESFORÇO 17
• Reach: quantas pessoas serão impactadas por essa iniciativa?
(Considere para um mesmo período)
• Impact: quanto isso irá impactar cada uma dessas pessoas?
• Confidence: o quáo confiante você está em relação a esses
números?
Para (2), eu gosto dos parâmetros descritos por WSJF (Weighted
Shortest Job First), também vinculada a Dan Reinertsen, e recomen-
dada pelo framework SAFe⁶.
• Business Value: Qual a penalidade potencial ou impacto nega-
tivo se atrasar ou demorar? Quanto está deixando de ganhar
com esa iniciativa?
• Time Criticality: O quão rápido o valor do negócio diminui
ao longo do tempo? Os usuários irão esperar por nós ou
encontrarão uma outra opção?
• Risk Reduction: Qual o risco de postergar esta iniciativa
para o nosso negócio? Esta iniciativa vai abrir/facilitar novas
oportunidades de negócio?
É importante ressaltar que tanto RICE, quanto WSJF recomendam
o mesmo denominador: Effort, assunto da próxima sessão.
Segue a equação recomendada para cálculo de VALOR, baseado em
RICE e WSJD:
VALOR =X + Y, onde X representa valores referentes aos usuários, e
Y valores referentes ao negócio. O cálculo de X é influenciado por
RICE, e o cálculo de Y por WSJD. Tanto X, quanto Y são valores
entre 0 e 5, logo, a resultante de VALOR é algum valor entre 0 e 10.
VALOR = [valores referentes aos usuários] + [valores referentes ao
business]
⁶Scaled Agile Framework – SAFe for Lean Enterprises
http://www.scaledagileframework.com/
Priorização relativa por VALOR e ESFORÇO 18
VALOR = [Reach x Impact x Confidence] + [ (Business Value +
Time Criticality + Risk Reduction) /3]
Seguem o intervalos de possíveis medidas para os parâmetros:
• Reach (de 0 a 5; 5 significa maior alcance)
• Impact (de 0 a 1; 1 significa maior impacto)
• Confidence (de 0 a 1; 1 significa 100% confiante)
• Business value (de 0 a 5; 5 significa maior valor)
• Time Criticality (de 0 a 5; 5 significa extremamente crítico)
• Risk Reduction (de 0 a 5; 5 significa extremamente necessário
para reduzir risco)
Compreendendo ESFORÇO
No momento de PLAN, temos muitas hipóteses, mas mesmo assim
precisamos transformar tais hipóteses em valores para nos auxilia-
rem a tomar decisões.ESFORÇO é uma medida da expectativa de trabalho da equipe em
tal iniciativa. Dado que temos uma dada equipe, quanto de esforço
requer a iniciativa A? E a iniciativa B? E as outras? Pronto. Dê um
palpite de esforço, ou seja, uma noção da expectativa do trabalho
necessário para cada uma das iniciativas. Assim você conseguirá
comparar o custo / benefício das iniciativas.
Mas não tente ser perfeito com estimativas, especialmente neste
momento. Estimativa é um assunto muito difícil. E provavelmente
você irá errar, mesmo quando compreender melhor as iniciativas e
detalhar o trabalho para construí-las.
Mas nesse momento, de esclarecimento sobre o portfolio de inici-
ativas, ainda não temos os detalhes das iniciativas. Portanto não
tente ser preciso. Faça a pergunta de forma comparativa:
Priorização relativa por VALOR e ESFORÇO 19
Para a mesma equipe (assumindo dedicação exclusiva
por iniciativa); qual dessas iniciativas requer mais es-
forço? A, B, C, D…? Qual requer menos esforço?
Esta comparação de esforço não é uma estimativa ou comprome-
timento com datas. É uma comparação entre o trabalho esperado
para as iniciativas, de forma a compará-las, e possivelmente, dar
unidades a cada uma delas; por exemplo: 1, 3 e 8; respectivamente
para a iniciativas A, B e C, indicando que a iniciativa B requer
três vezes mais trabalho que a iniciativa A, enquanto a iniciativa
C requer oito vezes mais. Desta forma o ESFORÇO das iniciativas
é determinado de forma comparativa, sem vínculo com período de
tempo.
Uma UN deve manter a gestão de iniciativas similares em tamanho.
Se uma iniciativa de uma UN for mais de dez vezes maior do que a
menor iniciativa da UN, recomendo que esta seja dividida em duas
iniciativas menores.
Desta forma, o ESFORÇO de cada iniciativa deve variar entre 1E e
10E.
NOTA da iniciativa
Após determinar comparativamente o VALOR e o ESFORÇO de
cada iniciativa, devemos calcular suas NOTAs. Esta conta é rea-
lizada com base na seguinte fórmula para o cálculo da nota da
iniciativa:
NOTA = VALOR / ESFORÇO
Cálculo de NOTAs, um exemplo
Segue um exemplo de cálculo das NOTAs de duas iniciativas.
Priorização relativa por VALOR e ESFORÇO 20
Iniciativa A: metade dos nossos usuários serão afetados por esta
iniciativa. Reach = 2.5
Iniciativa B: todos nossos usuários serão afetados por esta iniciativa.
Reach = 5
Iniciativa A: o impacto vai ser enorme para cada usuário que
perceber esta iniciativa. Impact = 1
Iniciativa B: o impacto vai ser pequeno para cada usuário que
perceber esta iniciativa. Impact = 0.2
Iniciativa A: temos dados quantitativos que demostram que isso vai
acontecer. Confidence: 0.9
Iniciativa B: não temos dados quantitativos, nem pesquisa com
usuários, mas acreditamos fortemente que isso vá acontecer. Con-
fidence: 0.5
Iniciativa A: vamos receber uma multa altíssima caso não façamos
isso. Business value: 5
Iniciativa B: estamos deixando de expandir mercado por não ter
essa iniciativa funcionando. Business value: 3
Iniciativa A: Se perdemos o time-to-market, nossos usuários irão
migrar para nossos competidores. Time criticality: 5
Iniciativa B: essa iniciativa é importante, mas parece que não iremos
perder essa oportunidade (ainda). Time criticality: 1
Iniciativa A: Essa iniciativa traz um produto bonito, mas não
resolve os problemas de arquitetura que seguimos postergando.
Risk Reduction: 1
Iniciativa B: Essa iniciativa vai dar o start para a nova arquiterura
de todos nossos produtos. Isso vai evitar muitos problemas futuros
. Risk Reduction: 4
Iniciativa A: A equipe considera que precisa de 3 vezes mais esforço
para essa iniciativa, quando comparado com a iniciativa B: 3E
Priorização relativa por VALOR e ESFORÇO 21
Iniciativa B: A equipe considera que precisa de 3 vezes menos
esforço para essa iniciativa, quando comparado com a iniciativa
A: E
Segue abaixo os cálculos para as NOTAs das iniciativas A e B.
Cálculo da NOTA da iniciativa A:
VALOR A = [2.5 x 1 x 0.9 ] + [ (5 + 5 + 1) / 3]
VALOR A = 2.25 + 3.67 = 5.9
ESFORÇO A = 3
NOTA A = VALOR A / ESFORÇO A
NOTA A = 5.9 / 3 = 1.97
Cálculo da NOTA da iniciativa B:
VALOR B = [5 x 0.2 x 0.5 ] + [ (3 + 1 + 4) / 3]
VALOR B = 0.5 + 2.67 = 3.17
ESFORÇO B = 1
NOTA B = VALOR B / ESFORÇO B
NOTA B = 3.17 / 1E = 3.17
Iniciativa VALOR ESFORÇO NOTA
A 5.9 3 1.97
B 3.17 1 3.17
Várias iniciativas
O exemplo ilustrativo da sessão anterior demonstra iniciativa A e B.
Mas as unidades de negócio, especialmente em grandes corporações
possuem portfolios com muito mais que duas iniciativas. Devemos
colocá-las em uma tabela para demonstrar os númenos.
Segue um exemplo de tabela de priorização com as iniciativas de
Priorização relativa por VALOR e ESFORÇO 22
uma UN:
Iniciativa VALOR ESFORÇO NOTA
A 5.9 3 1.97
B 3.17 1 3.17
C 8 4 2
D 7.6 5 1.52
E 4.3 3 1.43
F 2.1 2 1.05
Desta forma podemos selecionar as iniciativas mais prioritárias
dado a capacidade daUN. Note que o orçamento daUNdeve refletir
a quantidade e tamanho das equipes de produto.
Mais uma vez ressalto que neste momento de planejamento e
priorização do portfólio não estamos interessados em ser precisos
em relação a datas e tamanho absoluto das iniciativas.
O mais importante é compreender o esforço relativo dentre as
iniciativas em uma unidade de negócio. Por exemplo, a iniciativa B
requer cinco vezes mais esforço que a iniciativa A. Para a atividade
de priorização essa informação é mais útil do que dizer que a inici-
ativa A requer um esforço de aproximadamente dois meses e meio
enquanto a iniciativa B requer um esforço de aproximadamente um
ano.
Inevitavelmente, quando utilizamos medidas temporais, como se-
manas ou meses, geramos expectativas sobre o tempo necessário
para realizar uma iniciativa.
Alem disso antecipamos uma conversa sobre a equipe que vai
trabalhar na iniciativa. Qual o perfil da equipe para essa iniciativa?
Precisamos de mais conhecimento em alguma área ou tecnologia
específica? Mas este não é o momento de definir ou escolher a
equipe mais adequada à esta iniciativa. Isso acontece quando está
iniciativa for priorizada, ao entrar na etapa DO.
Depois do planejamento e da priorização das iniciativas, entramos
na fase de DO. Nesta fase começaremos com uma Lean Inception,
Priorização relativa por VALOR e ESFORÇO 23
onde o time de produto responsável pela iniciativa irá compreender
a iniciativa e criar um plano baseado no conceito de MVP.
Iniciativa NOTA 10
Não sei quanto a você, mas no meu tempo de colégio, 10 era a nota
máxima. Por vezes a nota final era calculada somando e dividindo
alguns números. E o resultado era algun valor entre 0 e 10.
E todos alunos buscavam a nota 10.
Pois bem, o cálculo de NOTA proposto nesse livro gera algum valor
entre 0 e 10, sendo 10 a melhor nota possível.
Nesse contexto, uma iniciativa NOTA 10 seria uma iniciativa que,
comparativamente com as outras iniciativas, gera o máximo de
valor para o negócio (5), o máximo de valor para os usuários (5),
com o menor esforço (1):
NOTA = VALOR / ESFORÇO,
NOTA = (5 + 5) /1
NOTA = 10
Iniciativa NOTA 10!
Sessão colaborativa de
preenchimento da tabela de
priorização
Recomendamos o preenchimento da tabela de priorização de uma
única vez, em uma sessão colaborativa com os representantes das
varias iniciativas. Reserve uma boa sala (local ou virtual, para
reuniões remotas) para o tempo que considerar adequado (isso
Priorização relativa por VALOR e ESFORÇO 24
depende do número de iniciativas, de participantes, e do nível de
discussão e detalhes para cada iniciativa).
Todos os parâmetros desta tabela consideram valores relativos entre
as iniciativas, por este motivo recomendamos fortemente que os
principais sponsors estejam juntos nesta sessão. Trabalhos prévios
para melhor esclarecimento de cada iniciativa são bem-vindos.
Entretanto alertamos para o possível desperdício de gastar muito
tempo e esforço detalhando uma Iniciativa, para depois descobrir
que esta alcança uma nota baixa e não será priorizada.
Segue um exemplo de tabela de priorização, criada compost-its
em um quadro durante uma sessão colaborativa em uma reunião
trimestral de priorização de iniciativas de uma UN.
preparando a tabela - iniciativas vs quesitos
Priorização relativa por VALOR e ESFORÇO 25
resultado da tabela de priorização
Segue o passo a passo para facilitar a sessão colaborativa de
preenchimento da tabela de priorização:
1. Listar todas as iniciativas
Lista todas as iniciativas a serem comparadas e priorizadas nesta
sessão. As sessões e o agrupamento das iniciativas devem refletir a
estrutura financeira. Por exemplo: sessão da UN XPTO, sessão das
iniciativas H2 grupo Alpha, sessão iniciativas Mega Blaster - fase 3.
Liste as iniciativas como títulos de linhas em uma tabela (seja em
formato digital, como Excel, ou com post-it em um quadro branco)
1. Faça o pitch de cada iniciativa
Este varia muito de organização a organização, desde pitches muito
curtos (de um a cinco minutos) a pitches mais longos com decks e
apresentações sobre a importância e a relevância de cada iniciativa.
1. Explique e escreva cada quesito
Priorização relativa por VALOR e ESFORÇO 26
Explique e de um exemplo de cada quesito. Se necessário, imprima
ou projete as perguntas de cada quesito para que fiquem visíveis a
todos.
Escreva cada quesito como títulos de colunas em uma tabela
(exemplo: uma planilha Excel ou post-it em um quadro branco)
1. Compare cada quesito, iniciativa a iniciativa
Selecione um quesito e compare-o iniciativa a iniciativa, de forma
a buscar valores relativos.
Por exemplo:
esforço; olhando para essas iniciativas, qual requer
menos esforço? Chamamos então de 1. Se esta inicia-
tiva tem esforço 1, quanto esforço seria esta outra? E
aquela?
Outro exemplo:
reach; lembrando que reach máximo é 5 e mínimo e
0. Qual o reach da iniciativa A? Se a iniciativa A tem
este reach, quanto seria o reach para a iniciativa B;
maior, menor, o mesmo? E para a iniciativa C?
1. Faça os cálculos
Se está usando um Excel, certifique-se da fórmula:
NOTA = VALOR / ESFORÇO, onde VALOR=[Reach x Impact x
Confidence]+[(BusinessValue + Time Criticality + Risk Reduction)
/3 ]
Se possível escreva a fórmula e deixe-a visível a todos.
Faça o cálculo e demonstre os resultados, indicando as notas de cada
iniciativa.
Priorização relativa por VALOR e ESFORÇO 27
1. Conversa sobre o resultado
Promova uma conversa sobre o resultado apresentado. Neste mo-
mento a sessão se torna um pouco matemática e gera uma nota
para casa iniciativa, destacando as prioridades relativas. Agora é o
momento de refletir sobre os números e usá-los como base de uma
boa conversa.
Inevitavelmente algumas iniciativas tem notas mais baixas que
outras. Converse sobre o resultado e os passos seguintes antes de
terminar a sessão.
Cuidado com os Outliers
Outlier é uma iniciativa que de alguma forma se destaca
do grupo, e deve ser retirada desta sessão (considere
marcar outra sessão para tratar do outlier).
Outliers acontecem quando estamos comparando coisas muito
distintas. Por exemplo, maçã, laranja, uva, banana e um elefante.
Outro exemplo: um skate, uma bicicleta, uma moto e um transa-
tlântico.
Outliers devem ser identificados antes da sessão de comparação
das Iniciativas, mas caso esses estejam na lista de Iniciativas, tente
identifica-los e separa-los para outra sessão. Isso evita (1) discussões
muito difusas e (2) gerar valores relativos irrelevantes; por exemplo:
• esforço skate = 1
• esforço bicicleta = 1
• esforço moto = 1
• esforço transatlântico = 10;
ao invés disso, recomendamos retirar transatlântico da lista —
outlier— e alcançar algo como:
Priorização relativa por VALOR e ESFORÇO 28
• esforço skate = 1
• esforço bicicleta = 4
• esforço moto = 10
Moedas da organização
Em uma grande organização que prestei consultoria sobre trans-
formação digital, ao invés de utilizarmos os números gerados pela
tabela de NOTAs de cada UN, criamos o conceito de moedas da
organização.
Por exemplo, considere a organização fictícia: organização JFC.
Para o exemplo anterior NOTA A de 0.98 e o NOTA B de 1.59,
dizíamos que a iniciativa A valia 98 moedas JFC enquanto a
iniciativa B valia 159 moedas JFC.
Ou seja, multiplicávamos o valor NOTA por 100 e utilizávamos a
unidade moeda JFC.
Risco ou realidade
O risco em investir em algo que não vai gerar o resultado es-
perado não deveria nem ser chamado de risco, mas sim de uma
realidade. Formas menos enxutas de trabalhar exigem muito mais
planejamento e controle na tentativa de mitigar tal risco. E, para
piorar, muitas vezes mascaram iniciativas que deram errado por
trás daquela que deu certo.
Aceitar a incerteza da iniciativa reduz a carga emocional e as
inúmeras horas e esforço gastos com planejamento e controles
da iniciativa. Se tal iniciativa recebeu uma nota alta, então não
devemos economizar esforços com ela.
Priorização relativa por VALOR e ESFORÇO 29
Errado! Mesmo recebendo notas altas, ainda estamos no mundo das
hipóteses. E, somente com dados reais poderemos comprovar que
aquela iniciativa promissora gerou resultados promissores.
O MVP é para isso. Para algo que ainda não está definido. Para
ajudar a converter a hipótese em realidade. Para gerar dados
reais de uso. Para dar direcionamento ao negócio. Para colocar a
iniciativa a prova.
E antes de pensar em qual MVP testar, decidimos qual iniciativa
tem melhores chances (a tabela de priorização das iniciativas). Ou
seja, qual das incertezas são menos incertas? Qual hipótese parece
mais plausível? Onde devemos investir nossos esforços?
Outros modelos para
priorização
O modelo proposto apresenta uma forma efetiva de priorização
relativa, onde consideramos VALOR e ESFORÇO de cada iniciativa,
relativamente entre elas.
Mas existem outras formas de priorização. Segue abaixo algumas
outras formas de priorização que eu já em uso em algumas organi-
zações.
Priorização absoluta
Priorização absoluta é quando uma iniciativa é priorizada isolada-
mente, Independente das outras iniciativas. Isso acontece quando
a decisão sobre priorizar a iniciativa acontece baseado somente em
valores e parâmetros relacionados a própria iniciativa.
Por exemplo um business case detalhado (e muito bem analisado)
da iniciativa que demonstra ROI ou VPL para a iniciativa: “Segundo
os números do business case apresentado gastaremos ummilhão em
um ano, para aumentarmos os lucros em 12% em dois anos, geando
um ROI de X”.
Priorização do Hipopótamo
Hipopótamo (Hippo em Inglês, ou do acrônimoHighest Paid People
Opinion) é aquela pessoa com maior salário.
Outros modelos para priorização 31
Brincadeira a parte, geralmente o maior salário reflete anos de
experiência, e tipicamente representa alguma posição de alto poder
na organização. Geralmente o HIPPO influencia a todos, e a sua
iniciativa é priorizada. Entretanto esta forma de priorização inibe a
conversa sobre outros aspectos, outras iniciativas, e outros profis-
sionais que não são HIPPO.
Priorização por decibéis
Reuniões de priorização podem ser longas, cansativas e estressan-
tes. Pior ainda, essas podem acontecer em ambientes de trabalho
nocivos, onde quem fala mais alto acaba decidindo. Esta é a
priorização por decibéis, onde a prioridade é definida por aquele
que fala (ou grita) mais alto.
Priorização The Flash
The Flash, aquele super-herói que corre mais rápido que os outros.
Por vezes organizações tem budget disponível, e aquele que chega
mais rápido terá sua iniciativa priorizada. Nesse caso o Flash acaba
ganhando a iniciativa, independente de como essa se compara com
as outras que não correram tão rápido para serem priorizadas.
Isso me remete aqueles programas de auditório que responde quem
bate em um botão mais rápido. Por vezes o candidato mais rápido
nem sabe a resposta, mas clicou primeiro e vai falar primeiro.
Infelizmente isso acontece em algumas organizações que dão início
a iniciativas por motivo similar: alguém foi mais rápido em apertar
um botão (ou responder um e-mail, enviar alguma planilha ou
plano). E somente algum tempo depois a organização irá percebero resultado dessa resposta rápida.
Outros modelos para priorização 32
Priorização rapa do tacho
Rapa do tacho, ou aquela sobra que fica no fundo do recipiente.
Isso acontece quando, próximo da virada do ano financeiro, alguém
percebe que ainda há dinheiro aprovado para ser usado.
Essa é a rapa do tacho. Vão levar o tacho, então é melhor rapá-
lo, pois aquela verba já estava aprovada. Geralmente isso está
relacionado a budgets previamente aprovados. E a organização
decide priorizar algo, não necessariamente por sua priorização
neste momento específico; mas por que a verba já está aprovada
e podemos gastá-la.
Funding
<texto em construção>
Evite o funding de iniciativa
Se possível não faça funding da iniciativa. Ao invés, faça funding
da equipe, do squad, da tribo, ou da UN; ou seja, faça o funding do
grupo responsável por uma (ou várias) iniciativas.
Projetos são aprovados, logo recebem funding. É assim que muitas
organizações trabalham. Mas este livro propõe uma mudança de
paradigma: de projetos para produtos.
Algumas organizações já entenderam esta mudança e estão dando
passos mais largos nessa direção. Outras organizações ainda estão
entendendo essas mudanças, e testando pequenos passos nessa
direção.
Mas, independentemente do apetite que a sua organização tem
para mudança, evite tratar a iniciativa como um projeto. Ao menos
na questão de funding. Pois a forma de tratar o funding pode
ser um grande impulsionador, ou bloqueador para a mudança de
paradigma.
Segue uma proposta para alocar e gerenciar o funding:.
Comesse com uma simples pergunta:
Olhando para indicadores do passado e do futuro
(lagging e leading indicators, em Inglês), o quanto sua
organização deve investir em cada UN?
Funding 34
Por exemplo, considere uma organização, com quatro UNs: UN A,
UN B, UN C e UN D, que tem R$100.000,00 a ser disponibilizado
como funding do próximo período (tipicamente anual ou trimestral,
dependendo da maturidade de Estratégia Lean da organização).
Dado os indicadores do passado e do futuro, decidimos distribuir
os fUndings desta forma:
• R$60.000,00 para a UN C
• R$20.000,00 para a UN B
• R$10.000,00 pata a UN A
• R$10.000,00 para a UN D
Com o funding de R$20.000,00, a UN B mantém três squads, logo as
três iniciativas com maiores notas serão encaminhadas para cada
um desses squads.
Este é um exemplo simplificado, mas que demonstra o relaciona-
mento entre funding, UN, squads e iniciativas.
Objetivos de negócio e funding
Segue uma forma de fazer o funding dos objetivos de negócio: des-
crevemos os objetivos de negócio, verificamos o quanto o business
case de um projeto está alinhado com nossos objetivos, e decidimos
o funding dos projetos, que são encaminhado para suas respectivas
UN.
Agora descrevo outra forma de fazer o funding dos objetivos de
negócio. Descrevemos os objetivos de negócio, decidimos os fun-
dings das UNs, verificamos a priorização relativa das iniciativas por
UN, e decidimos as iniciativas a começar, que são encaminhadas as
respectivas squads das UNs.
São similares, mas com uma diferença essencial: projetos versus
produtos.
Funding 35
Objetivos -> projetos -> aprovação -> funding
Ou
Objetivos -> iniciativas -> priorização relativa -> fun-
ding
Funding e os 3 Hs
O Funding deve refletir o horizonte de atuação da UN. Por exemplo
a UN A recebe um funding de 50000.
Isso significa que a UN ou gera mais de 50000, por isso tem este
funding logo sendo lucrativa, ou a UN gera menos que 50000 e está
recebendo investimento.
Uma UN que tipicamente opera em H2 e H3 recebe investimentos
para tanto. Já uma UN que opera em H1 não deveria receber mais
funding do que gera de receita.
Funding e capacidade de Negócio
<writing in progress>
Do
MVP – Produto Mínimo
Viável
< ainda vou adicionar texto e imagens neste capítulo >
O MVP fatia uma iniciativa em pedaços bem pequenos. Isso ajuda
de duas formas: (1) reduz o risco de insistir em uma iniciativa que
não se provou, ou seja, parecia uma boa iniciativa, mas que não
gerou bons resultados, e (2) maximiza o fluxo de trabalho.
MVP e o Fluxo de trabalho
Para te convencer que trabalhar com MVP, ou seja pequenos
pedaços de trabalho é melhor não somente pelo conceito de MVP,
mas também por ser tratar de pequenos batch sizes, eu vou te contar
a história do meu bar de uísque.
… <ainda estou decidindo se conto aqui a história sobre meu bar de
uísque. Esse história já está no capítulo do CFD, o qual estou em
dúvida de retiro deste livro >
Lean Inception
< capнtulo resumindo a lean inception. Importante ser breve pois
isso jб estб detalhado no livro direto ao ponto.Mas precisa sermuito
claro que o time de produto precisa compreender a iniciativa e criar
i plano para criaзгo do MVP. >
Construindo MVP com
Scrum
Dado que muitas equipes utilizam Scrum, vamos compartilhar
como temos combinado Scrum com a criação de MVPs. Para tanto,
vamos realizar uma introdução básico sobre o Scrum, e, em seguida
demostrar como encaixar Scum com MVP, features e histórias.
Scrum
Scrum é um framework ágil para a conclusão de projetos comple-
xos. Scrum foi inicialmente formalizado para projetos de desenvol-
vimento de software, mas tem sido aplicado para qualquer âmbito
de projetos complexos, e trabalhos inovadores.
O Scrum é especialmente adequado para projetos com requisitos
que mudam rapidamente ou são altamente emergentes.
A Equipe Scrum
Scrum fomenta uma equipe multi-funcional e auto-organizada.
A eficiência do time depende da capacidade dos membros traba-
lharem em conjunto, e fazer o melhor uso das habilidades dos
indivíduos. O time Scrum é auto-organizado pois não deve existir
um líder de equipe que decide quem vai fazer qual tarefa e como.
Tarefas e problemas são levantados por todos, e essas são questões
decididas pela equipe como um todo. Os times Scrum são apoiados
por dois papéis específicos: o Scrum Master e o Produt Owner (PO).
Construindo MVP com Scrum 40
Scrum Master
Scrum Master é alguém experiente com o framework Scrum que
pode ajudar o time a usar o processo para alcançar seus objetivos
de alto nível. Os melhores Scrum Masters são aquelas pessoas que
sentem mais satisfação de facilitar o sucesso dos outros do que
seus próprios. O Scrum Master deve se sentir confortável e seguro
com o framework a ponto de dar todo controle em relação ao
produto para o Product Owner (PO), e todo controle em relação
ao desenvolvimento a sua equipe.
Product Owner
OProduct Owner (PO) representa o negócio, os clientes ou usuários,
e orienta a equipe para a construção do produto certo. O PO deve
liderar o esforço de desenvolvimento, através de esclarecimentos e
priorizações sobre o trabalho.
Tipicamente, o PO trabalha com o Product Backlog, a lista mestre
dos requisitos do produto a ser criado. É sua função priorizar o
backlog com base no valor do negócio, e no alinhamento entre as
partes interessadas, tanto internas quanto externas a equipe Scrum.
Como tal, o PO deve estar disponível para a equipe para responder
a perguntas e direcionar o time a cada momento ou indagação.
Esta combinação de autoridade e disponibilidade para a equipe de
desenvolvimento faz com que o PO seja peça chave do framework.
Scrum valoriza a auto-organização e autonomia do time; portanto,
o PO deve respeitar o direcionamento e a capacidade da equipe para
criar o seu próprio plano de ação.
A Sprint
Sprint é uma iteração, um ciclo de trabalho repetitivo no qual o time
Scrum passa por todas as cerimônias do Scrum: planning, review e
retrospectiva. O tamanho da Sprint é fixo e definido pelo time (ou
Construindo MVP com Scrum 41
pela organização) ao começar a implantar Scrum. Duas semanas é
o tamanho de Sprint mais adotado por times de desenvolvimento
de Software.
Cerimônias da Sprint
A equipe Scrum – o Scrum Master, o PO e todos membros do
time (com suas variadas formações) – participam ativamente de
todas reuniões com um alto nível de autonomia, transparência e
comprometimento.
Cerimônias da Sprint
Na Sprint planning, a equipe decide o Sprint backlog,o qual é
acompanhado diariamente (Daily Scrum) e reavaliado na Sprint
review. Através da busca de melhoria continua (salientado nas
retrospectivas), tipicamente o time Scrum performa em níveis ele-
vados de rendimento. Muito disso é alcançado pelo entrosamento
do time, do alinhamento cadenciado via Sprints, e da clareza de
cada papel e reunião.
Daily Sprint
Reunião diária do Scrum, onde basicamente todos os membros
do time ficam de pé (para que a reunião não demore demais) e
Construindo MVP com Scrum 42
respondem a três perguntas, as quais auxiliam o time a se auto-
organizar, buscando o alinhamento diário em relação ao trabalho
da Sprint. As três perguntas são: o que fiz ontem, o que vou fazer
hoje e o que está impedindo o progresso do meu trabalho.
Sprint Planning
Sprint Planning, ou reunião de planejamento do Scrum é uma
reunião de planejamento que acontece no início de cada Sprint. A
reunião de planejamento do Sprint é descrita em termos de metas
e resultado desejado. O resultado desejado é um compromisso com
um conjunto de funcionalidades a serem desenvolvidas no próximo
Sprint. Buscando assim o equilíbrio entre autonomia, flexibilidade
e comprometimento do time. Tal compromisso é revisitado ao final
da Sprint, na reunião de review.
Sprint Review
Reunião realizada ao final da Sprint com o objetivo de apresentar
o estado da arte do produto sendo criado, rever o progresso do
trabalho do time, e comparar com o planejamento apresentado na
Sprint planning.
Retrospectiva
A reunião de retrospectiva Scrum é um momento para a equipe re-
fletir sobre como estão trabalhando, e buscar maneiras de melhorar.
Tipicamente, o time Scrum realiza uma retrospectiva por Sprint.
Construindo MVP com Scrum 43
OMVP nas cerimônias do scrum
Antes da reunião de planejamento, as próximas funcionalidades
devem ter sido analisadas em detalhe e detalhadas em histórias do
usuário.
O planejamento da Sprint
Durante a Sprint
Na reunião de revisão do sprint, a equipe scrum irá rever o trabalho
realizado durante o sprint. Neste momento, a equipe deve revisar
e atualizar tanto as histórias do sprint backlog, quanto as suas
respectivas funcionalidades no canvas MVP.
Construindo MVP com Scrum 44
Revisão da Sprint
Com o canvas MVP atualizado, a equipe pode (e deve) verificar
quanto falta para terminar o MVP . E, se necessário, a equipe de
agir (ACT) para ou (1) alcançar, ou (2) realinhar as expectativas
de entrega do MVP. Tipicamente, as reuniões de retrospectiva
geram action items para o próximo Sprint. Assim que todas as
funcionalidades do MVP estiverem completas, o mesmo deve ser
disponibilizado para os usuários finais.
Construindo MVP com
Kanban
Dado que muitas equipes utilizam Kanban, vamos compartilhar
como temos combinado Kanban com a criação de MVPs. Para
tanto vamos realizar uma introdução básico sobre o Kanban, e, em
seguida demonstrar como encaixar Kanban com MVP, features e
histórias.
Kanban
Kanban é um método formulada por David J. Anderson⁷ para
gestão do fluxo de trabalho de um processo incremental e evolutivo.
Influenciado pelo modelo Toyota Just-In-Iime⁸, o método se baseia
em visualizar o fluxo de trabalho e, a partir disso, atuar no processo
para não sobrecarregar os membros da equipe.
Através de uma abordagem de gestão visual perante a cadeia de
valor, o processo, desde sua etapa inicial até a entrega do trabalho,
é exposto aos membros da equipe. Tipicamente a cadeia de valor é
representada em quadros brancos com post-it ou ferramentas on-
line. Processo, itens de trabalho, bem como os trabalhadores estão
visualmente representados nesses quadros, comumente chamados
de kanban boards, ou kanban (isso mesmo, o método e o nome do
quadro se confundem). A partir do kanban, fica mais fácil para a
equipe decidir o que, por quem, quando, e quanto produzir.
⁷Kanban: Successful Evolutionary Change for Your Technology Business by David Ander-
son, Blue Hole Press Inc (2013)
⁸Ohno, Taiichi. (1988) Toyota Production System. Productivity Press
Construindo MVP com Kanban 46
No desenvolvimento de software, normalmente uma pequena ta-
refa leva de horas à dias para ser concluída. Além disso, você
não consegue visualizar quantos requisitos estão atualmente em
análise; ou quantos requisitos estão atualmente sendo codificados
ou testados. O fato é que não conseguimos “ver” o item de trabalho
relacionado ao software, e como este se move ao longo das etapas
de do processo, até que esteja pronto. Aqui é onde tudo começa:
kanban torna tais itens em construções visíveis!
Visualize o workflow
A ideia principal do kanban é colocar o fluxo de trabalho na frente
de todos. Por exemplo em um quadro branco, ou na própria parede.
Abaixo está uma foto tirada de um kanban de uma equipe de
desenvolvimento de software.
Exemplo de kanban – o workflow visível
Cartões na parede. Simples assim. Cartões (ou post-it) na parede
mostrando o processo e o trabalho da equipe. Uma descrição rápida
do processo e trabalho deste time seria: um item de trabalho está
em etapa In Analysis, cinco itens estão na etapa de Ready For
Dev, três itens estão na etapa In Dev, um outro item está na etapa
Ready for BA, três itens estão na etapa Ready for QA, cinco itens
estão na etapa In QA, e oito itens estão em etapa de Ready for
Construindo MVP com Kanban 47
SAT. Também parece que a equipe usa fotos para representar as
pessoas trabalhando nos itens. Os cartões têm um código de cores
(há três cores diferentes nos cartões na foto). Os cartões também
têm anotações escritas neles, um identificador numérico, e post-it
menores coloridos colados sobre eles.
Como a parede é uma superfície bidimensional, o kanban é apresen-
tado em um formato tabular, onde as etapas de trabalho são títulos
de colunas, e os items de trabalho, as fotos das pessoas, e outras
marcas relacionadas ao trabalho preenchem o espaço na parede.
Estes cartões podem ser organizados em uma linha horizontal ou
não. Tudo depende da equipe e como elas representam e organizam
o seu trabalho na parede.
Limite o WIP
Limitar o trabalho em andamento, ou WIP de work in progress
em Inglês, implica que o kanban segue um sistema puxado. O
trabalho em cada etapa do processo é limitado de forma que
um novo trabalho somente seja “puxado “ para a próxima etapa
quando há capacidade disponível dentro do limiteWIP de tal etapa.
As restrições de WIP identificam gargalos e áreas problemáticas
no processo, auxiliando o time a tomar decisões para resolvê-
los. Limitar WIP é o grande diferencial do método Kanban. Tal
artimanha é o divisor de aguas entre task boards, ou quadros visuais
– como eram conhecidos antes da influencia de David Anderson
com a divulgação do método Kanban—e o quadros kanban.
Construindo MVP com Kanban 48
ilustração de kanban com limites
Siga melhorando o fluxo de trabalho
Segundo David Anderson, o ponto principal de implantar um
kanban é criar uma mudança positiva. Antes de criar essa mudança
o time tem que saber o que mudar. O time precisa descobrir isso
olhando como itens de trabalho estão fluindo através do processo,
e analisando as áreas problemáticas em que o trabalho engargala.
Daí sim, realizar nomudanças no processo de trabalho para resolver
tais problemas.
E assim sucessivamente; identificando problemas, e agindo para
resolvê-los. Tudo isso baseado na visualização e limites WIP do
kanban. Melhorando o trabalho e o processo, na busca contínua
de maior eficiência.
OMVP no Kanban
Segue abaixo um sequenciador de features, exemplo de resultado
de uma inception DiretoAoPonto.
Construindo MVP com Kanban 49
Sequenciador de Features
Note no sequenciador apresentado que o MVP 1 é composto pelas
features F1, F2, F3, F4, F5 e F6.
O fluxo de trabalho do MVP é simples. Para cada MVP, temos
as features a serem trabalhadas, as features em construção e as
features prontas. Isso representa o seguinte fluxo, no nível de funci-
onalidade: funcionalidade na fila -> funcionalidade em construção
-> funcionalidade pronta.
Uma vez que uma funcionalidade entra na etapade funcionalidade
em construção, primeiro precisamos quebrar esta funcionalidade
em pedaços menores (histórias ou tarefas, dependendo do estilo da
equipe). Desta forma teremos um conjunto de itens de trabalho a
ser realizado para cada funcionalidade, e cada um desses itens passa
pelo seguinte fluxo: a fazer -> fazendo -> feito.
Visualizando o fluxo para MVP, features e
itens de trabalho
O fluxo de trabalho do MVP com suas features, e das features com
seus itens de trabalho é representado no kanban abaixo.
Construindo MVP com Kanban 50
Kanban de Features do MVP
Note neste Kanban os dois níveis de trabalho: (1) features do MVP,
e (2) histórias (ou tarefas) de uma funcionalidade. Este kanban
demonstra o workflow de MVP e features, e o progresso de cada
funcionalidade perante o andamento das suas histórias (ou tarefas,
representados pela letra W na figura).
Sugiro manter o sequenciador de funcionalidade próximo ao kan-
ban de features do MVP. Desta forma, todos podem verificar onde
está cada MVP e cada funcionalidade. Se já estão em construção,
prontos, ou ainda esperam na fila.
O Sequenciador de Features, agora sem os cartões das features que foram para
o kanban
Segue uma sequência de imagens, demonstrando o Sequenciador
Construindo MVP com Kanban 51
de features e o kanban, dia após dia.
Kanban no dia 1 – passo 1
Kanban no dia 1 – passo 2
Construindo MVP com Kanban 52
Kanban no dia 2
Kanban no dia 3
Construindo MVP com Kanban 53
Kanban no dia 4
Kanban no dia 5 – passo 1
Construindo MVP com Kanban 54
Kanban no dia 5 – passo 2
Kanban no dia 5 – passo 3
Kanban no dia 5 – passo 4
Construindo MVP com Kanban 55
Kanban no dia 5 – passo 5
Kanban no dia 6
Construindo MVP com Kanban 56
Kanban no dia 7 – passo 1
Kanban no dia 7 – passo 2
Construindo MVP com Kanban 57
Kanban no dia 7 – passo 3
Kanban no dia 7 – passo 4
Kanban no dia 8
Construindo MVP com Kanban 58
Kanban no dia 9
Kanban no dia 10 – passo 1
Kanban no dia 10 – passo 2
Construindo MVP com Kanban 59
Kanban no dia 10 – passo 3
funcionalidade WIP
O Kanban apresentado tem um limite de três features no WIP.
Isso está explicitado pela quantidade de linhas neste kanban. Estas
imagens representam um kanban utilizado por um time cross-fun-
cional, com 8 pessoas com perfis e capacitações de desenvolvedor,
testados, ops e UX (User eXperience).
Não é intuito deste livro discutir como decidir o limite WIP de um
kanban, mas somente ilustrar como implementas um kanban para
o MVP e suas features.
Arquitetura Mínima
Viável (MVA)
O MVP permite que a equipe de possa entregar um produto nas
mãos de usuários rapidamente, à um baixo custo. Quanto mais cedo
o produto for utilizado, mais se pode aprender com os usuários
para melhorá-lo. A melhor maneira de aprender e evoluir é ouvir
de usuários que utilizam o software, não de pessoas olhando para
uma folha de papel em branco tentando visualizar como um sistema
deve funcionar.
Um dos desafios que a abordagem MVP apresenta é de que ela
pode levar à falta de uma arquitetura. Quando construindo um
produto do zero, a pressa para entregá-lo pode vir ao custo de uma
arquitetura sustentável. Deve haver balanço entre velocidade de
entrega e qualidade. É necessária uma arquitetura mínima viável⁹.
Então, como definimos qual o MVA? Recomendamos realizar per-
guntas como estas:
• Quantos usuários utilizarão o sistema no lançamento inicial?
Nos primeiros 6 meses? Dentro de um ano?
• Os usuários iniciais serão internos, externos, ou ambos?
• Quantas transações por segundo esperamos no lançamento?
Nos primeiros 6 meses? Dentro de um ano?
• Como os usuários começarão a utilizar o sistema?
• Qual o nível de segurança e auditabilidade exigido no lança-
mento? Dentro de 6 meses? Dentro de um ano?
Há diversas outras perguntas para guiar a discussão. Estas pergun-
tas ajudam a equipe a definir os requisitos básicos para lançar no
⁹Arquitetura Minima Viável (MVA) blog post por Paulo Caroli; Disponível em
http://www.caroli.org/arquitetura-minima-viavel-mva/ ; Acesso em Agosto de 2018
Arquitetura Mínima Viável (MVA) 61
mercado. Embora não entre no mérito de definir uma arquitetura
completa e perfeita para o produto final, isto é diferente de ignorar
a definição de uma boa arquitetura. O foco é no quanto de inves-
timento é necessário para lançar e, em seguida, definir um plano
para evoluir a arquitetura conforme o número de usuários aumenta
e requisitos são adicionados.
Tentar construir o produto perfeito raramente é a abordagem
correta. Vamos dizer que a resposta do dono do produto para estas
perguntas sejam as seguintes:
• Haverá apenas cinco usuários internos nos primeiros três
meses. Seis meses a partir de agora os nossos dois primeiros
clientes externos estarão usando os sistemas em modo piloto.
Um ano a partir de agora lançaremos o sistema para todos os
clientes.
• No lançamento haverá uma quantidade trivial de transações.
Daqui a seis meses o tráfego será moderado. No próximo ano,
o tráfego será extremo.
• Inicialmente, adicionaremos usuários ao sistema através de
uma interface. No futuro, os clientes terão gestão de ID self-
service. Espero que isto aconteça em um ano a partir de agora.
• Nós só precisamos de segurança mínima para a primeira ver-
são. Para o piloto, precisamos de segurança e audit completos.
Com base nessas respostas, muita discussão e definição pode ser
adiada para após o lançamento da primeira versão. Por que gastar
tempo na estratégia de cache agora, quando não vemos a necessi-
dade no horizonte de um ano? Nós podemos colocar fora diversas
tarefas de gerenciamento de ID para mais tarde também. Deve-se
evitar discussões imediatas sobre requisitos que só virão no futuro,
de forma que seja implementado apenas o estritamente necessário
da melhor forma possível. É por isso que o MVA é tão importante.
Esta abordagem depende da disciplina e confiança entre o dono
do produto e da equipe de desenvolvimento, para garantir que
Arquitetura Mínima Viável (MVA) 62
ambas obtenham os resultados desejados: o produto é entregue
rapidamente com um sistema bem arquitetado e com pouca dívida
técnica.
Micro-serviços de Domínio
A abordagem de micro-serviços é um estilo de desenvolvimento no
qual uma aplicação é composta de uma série de pequenos serviços,
cada um rodando em seu próprio processo e se comunicando
através de mecanismos leves (geralmente uma API HTTP). Estes
serviços são construídos em torno de requisitos de negócio, e
devem ser capazes de ir à produção independentemente e de forma
automatizada.
Uma abordagem para definir o escopo de um micro-serviço é
analisar qual a funcionalidade de negócio que ele se propõe a dispo-
nibilizar, e como este serviço se relaciona com outros. Mapeamento
de contexto é uma ferramenta em Domain Driven Design que
auxilia na identificação de diferentes contextos e seus limites. Um
contexto encapsula os detalhes daquele domínio, como o modelo e
os dados, e define os pontos de integração com outros contextos.
Desta forma, há uma relação direta em DDD e mapeamento de
contexto com a definição de micro-serviços, que devem possuir
interfaces bem definidas e se limitarem à uma certa quantidade de
funcionalidades de negócio.
Embora micro-serviços adicionem complexidade operacional para
serem mantidos, eles provêm uma arquitetura forte e flexível, na
qual diferentes contextos têm limites bem definidos e podem ser
implementados da maneira como for mais adequado (com quais
tecnologias e estratégias forem apropriadas).
Acompanhamento Lean
Nesta fase, devemos acompanhar a criação e a evolução das inicia-
tivas segundo o plano de entrega dos MVPs.
MVP, ouMinimumViable Product em Inglês, é a linguagem comum
entre as quatro etapas do Lean Strategy (PLAN / DO/ CHECK /
ACT). O conceito de MVP é baseado no livro The Lean Startup:
How Today’s Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses do Eric Ries ¹⁰.
O entendimento da iniciativa via
MVP
O workshop Lean Inception¹¹ gerou o sequenciadorde features, no
qual está mapeado o que o time estará construindo para a entrega
dos incrementos do produto enxuto, baseado nos MVPs.
¹⁰Ries, Eric. (2011) The Lean Startup: How Today’s Entrepreneurs Use Continuous Innova-
tion to Create Radically Successful Businesses. Crown Publishing.
¹¹CAROLI, Paulo. Lean Inception: How to Align People and Build the Right Product, Editora
Caroli, 2017.
Acompanhamento Lean 64
exemplo de evolução de produto de forma enxuta
O planejamento do produto e seus
MVPs
Para cada MVP identificado no sequenciador de funcionalidade é
criado um canvas MVP, o qual responde claramente as indagações
de dois aspectos fundamentais sobre produto e MVP: (1) o que são
as funcionalidades, as personas, as jornadas, a proposta, o custo
e cronograma de entrega do MVP, e (2) que resultado é esperado
quando esse for entregue, e como validaremos tal resultado e
aprendizado.
Acompanhamento Lean 65
o canvas MVP
O Canvas MVP é dividido em sete blocos:
1. Proposta do MVP – Qual é a proposta deste MVP?
2. Personas segmentadas – Para quem é esse MVP? Podemos
segmentar e testar este MVP em um grupo menor?
3. Jornadas – Quais jornadas são atendidas ou melhoradas com
este MVP?
4. Funcionalidades – O que vamos construir neste MVP? Que
ações serão simplificadas ou melhoradas neste MVP?
5. Resultado esperado – Que aprendizado ou resultado estamos
buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como pode-
mos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista para
a entrega deste MVP?
O planejamento baseado em MVPs difere de planejamento tradi-
cional de produtos por aceitar que a entrega somente sinaliza o
momento em que dados de aprendizado começarão a ser coletados.
Acompanhamento Lean 66
Exemplo de Canvas MVP – o MVP1 do EasyBola
Com uma visão mais tradicional, o acompanhamento verifica o
quão próximo estamos de completar a construção das funciona-
lidades de tal MVP. Enquanto, com uma visão mais moderna,
o acompanhamento é baseado no aprendizado, na validação de
hipóteses do negócio, em um estilo mais arrojado, digno das start-
ups do Vale do Silício.
Misturando construção com adaptação, convergência com diver-
gência, controle com experimentação, o planejamento baseado no
Canvas MVP auxilia a criação de produtos enxutos equilibrando
inovação e entrega.
O acompanhamento da criação do
produto via MVP
Devemos fazer o acompanhamento periódico (por exemplo sema-
nal) em relação a criação do produto. Tal acompanhamento deve ser
Acompanhamento Lean 67
realizado comparando o estado atual com o que estava planejado
no canvas MVP. Para tanto artefatos devem ser apresentados:
1. Status report do MVP
2. Burn up do MVP em construção
Status report do MVP
modelo de status report do MVP
Uma lista pequena com poucas e visíveis informações. Assim deve
ser um status report efetivo. Por se tratar de features de um MVP,
tal status report não somente é possível, como indicado!
Um status report simples auxilia no entendimento comum sobre
o andamento da criação do MVP. Informações simples e diretas:
Qual nome e o que compõe este MVP? Qual data prevista? Quantas
features já terminaram?
Acompanhamento Lean 68
Burn up do MVP em construção
o burn-up de MVP
O Burn-up de funcionalidades do MVP ajuda com o gerenciamento
de tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
funcionalidades do MVP.
Ao final do planejamento, o gráfico burn-up demonstra a visão
compartilhada do que deve ser alcançado. E isto fica claramente
visível traçando uma linha horizontal de escopo e uma linha
vertical de data de entrega do MVP. A interseção dessas linhas
representa o resultado no tempo esperado.
O gráfico é atualizado conforme as funcionalidades são construídas:
a data atual, e o total de funcionalidades completas são alterados.
Desta forma permite-se identificar possíveis desvios na duração
esperada para a construção do MVP.
Burn-up de Features do
MVP
O Burn-up de Features do MVP ajuda com o gerenciamento de
tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
features do MVP. É uma ferramenta essencial para dar visibilidade
ao planejamento e para realizar o acompanhamento da construção
das features do MVP.
A sequência de imagens mostra um exemplo de burn-up em mo-
mentos diferentes. Começando no dia 30/06, quando o burn-up foi
criado com o planejamento de acordo com o ritmo esperado de
construção das features. Seguindo com instantâneos do burn-up
nos dias 08/07, 18/07 e 28/07, quando todas as features do MVP
terminaram, e o mesmo foi entregue.
burn-up de features do MVP no dia 30/06
Burn-up de Features do MVP 70
burn-up de features do MVP no dia 08/07
burn-up de features do MVP no dia 18/07
burn-up de features do MVP no dia 28/07
Burn-up de Features do MVP 71
Os eixos do burn up
O eixo vertical é a quantidade de features para o MVP, e é medido
em unidades, por exemplo 9 features. O eixo horizontal representa
o tempo, normalmente medido em dias ou semanas.
exemplo de burn-up de MVP iniciado em 30/06 e planejado para 30/07
O ritmo da construção do MVP
Avantagemda gráfico burn-up é a visão compartilhada do que deve
ser alcançado. E isto fica claramente visível traçando uma linha
horizontal de escopo e uma linha vertical de data de entrega do
MVP. A intersecção dessas linhas representa o resultado no tempo
esperado.
Ao desenhar uma linha diagonal a partir do ponto de partida (o
início do tempo para a construção da primeira funcionalidade do
MVP) para o resultado no tempo esperado, você tem uma indicação
do ritmo linear de construção do MVP. Na figura abaixo, este
ritmo está representado como a linha diagonal , representando um
planejamento de ritmo linear.
Burn-up de Features do MVP 72
exemplo de burn-up com ritmo linear
Entretanto o ritmo de término de features de um MVP não é linear.
A figura abaixo demonstra uma curva que melhor representa o
ritmo de entrega esperado.
exemplo de burn-up com ritmo não linear
Equipes ágeis experientes lidam com tal curva de duas formas: (1)
Iteração ou Sprint 0, ou (2) entendimento do tempo de atravessa-
mento inicial.
Iteração ou Sprint 0 é um termo comum utilizado para ressaltar
que não haverá entrega de funcionalidade numa primeira iteração
ou Sprint. O gráfico abaixo demonstra como tal artimanha (Sprint
0) alinha a expectativa de entrega de funcionalidade com o ritmo
inicial ainda por começar.
Burn-up de Features do MVP 73
exemplo de burn-up com Sprint 0
A construção de uma funcionalidade tem um tempo mínimo de
atravessamento (ou lead time, em inglês). Por exemplo, o mínimo
que se leva para criar uma funcionalidade são 5 dias. Por tal
motivo é impossível ter o término de qualquer funcionalidade nos
primeiros cinco dias. Esse fato explica a barriga da curva do ritmo
esperado. Após a entrega das primeiras funcionalidades, o ritmo de
entrega vai ser estabelecido, e a curva tende a virar uma reta na
qual o ritmo de entrega fica estabelecido.
Verificando o progresso
De tempos em tempos você deve verificar a quantidade de features
já construídas e a quantidade total de features planejadas para o
MVP. A distância entre as linhas horizontais marcando as features
atualmente prontas e a última funcionalidade a ser construída é a
indicação da quantidade de features restantes.
Burn-up de Features do MVP 74
features construídas e restantes
Quando as duas linhas se encontram, todas features doMVP estarão
completas. A distância entre essas linhas é uma medida poderosa
de quão perto você está de completar o MVP.
verificando progresso
Verificar regularmente o progresso é uma parte importante da
gestão da construção do MVP. Há duas atualizações básicos para
o burn-up de features do MVP: (1) o tempo mudou; a seta que
representa a data atual deve ser movido para a direita até a posição
que representa a data atual, e a linha da data