Gestão Tradicional de Portfólio:

Um Castelo de Mentiras

Rodrigo de Toledo
Avelino F. Gomes Filho

12 de Outubro de 2020
Índice

I As mentiras do castelo 1
1 1o andar de mentiras: Escopo fixo 6

2 2o andar de mentiras: Estimativas de prazo

e custo 14

3 3o andar de mentiras: Estimativa de valor 22

4 4o andar de mentiras: Acompanhamento

de projetos 26

II Limpando o castelo 31
5 Transparência e Agilidade 34

6 Escopo flexível 45

7 Foco no problema e não na solução 60

IIIDerrubando o Castelo 73
8 Lean startup e eliminação de ideias 76

9 Triplo L: Limitando o Trabalho Paralelo 82

10 Acompanhamento por Resultado 97

IVEvoluindo para Valor Contínuo 122

11 Produtos mais que projetos 125

12 Alocação de pessoas 128

13 Redistribuição orçamentária 137

A A décima mentira: dragão Caopex 138

Bibliografia 139
 Parte I

As mentiras do castelo
O castelo

É triste ver como nas grandes empresas as pessoas vêm

se enganando por tanto tempo.

O atual modelo projetizado das empresas acaba por

criar um Castelo de Mentiras. A existência de tal cas-
telo de enganação não é o único problema. A construção
desse castelo é feita envolvendo diversas pessoas, muitas
delas de altíssimo nível hierárquico, com as horas mais
caras da organização. O esforço empenhado no castelo é
um desperdício de custo gigantesco. Porém, isso ainda é
pequeno se comparado ao impacto que a mentira traz:
• projetos inócuos;
• estruturas inúteis;
• burocracias extremas;
• falta de foco;
• verdadeiros valores ignorados; e
• desperdício de tempo de vidas humanas.
 O último item é o pior deles!

Recentemente em uma palestra nossa, havia mais de

trezentas pessoas, fizemos a clássica pergunta:

– Quem já trabalhou em algo que no final nunca foi

usado?

Mais uma vez, vimos quase a totalidade de mãos le-

vantadas. Mas dessa vez esticamos um pouco mais:

– Quem trabalhou mais de um ano permaneça com a

mão levantada!

Várias mãos ainda permaneceram...

– dois anos, três anos, quatro anos?

Achamos uma recordista daquele grupo (em outras

sessões já vi tempos maiores, chegando até oito anos).
Mas esticamos ainda mais:

– Quantas pessoas trabalharam nesse projeto de qua-

tro anos?

Com a resposta de trinta pessoas, pudemos fazer agora

as contas (30 x 4): cento e vinte anos jogados fora.
Ou seja, considerando que pessoas podem trabalhar por
quarenta anos, aquele projeto matou o equivalente a três

2
vidas de trabalho para nada. É como se falássemos para
três pessoas que acabaram de sair da faculdade que tudo
o que eles farão até se aposentarem não servirá nunca
para ninguém. Se você já trabalhou em algo que nunca
foi usado, faça também as suas contas (multiplique o nú-
mero de pessoas pelo tempo) e veja o desperdício de vidas
humanas (muito mais doloroso do que falar de dinheiro
desperdiçado).

Portfólio anual de projetos

Todo ano, diversas organizações têm que fechar o orça-
mento e o portfólio de projetos para o ano seguinte. Num
processo cíclico que inclui um grande esforço no ano an-
terior para essa tomada de decisão.

Nos dias de hoje há uma demanda crescente de ideias

que podem virar projeto. O avanço tecnológico impulsi-
ona para que a quantidade de opções seja muito maior
que a nossa capacidade de executar os projetos. Isso re-
quer alguma política de escolha de quais são os projetos
que entrarão no nosso portfólio, em detrimento de outros
que ficarão de fora.

As mentiras descritas neste livro são reflexos dessa

escassez, afinal, não será possível fazer tudo o que se
deseja. Começam a aparecer jogos políticos, desconfiança

3
mútua, pressões, práticas de autodefesa etc.

Esse castelo de mentiras tem vários andares sobre-

postos da base até a cobertura. Na nossa experiência
profissional ajudando diferentes organizações, foi possível
identificar alguns padrões de mentiras. Decidimos então
mapeá-las em diversos personagens, moradores desse cas-
telo, como descritos nos primeiros capítulos do livro.

Aviso 1
Há dois anos temos apresentado os nove personagens do
castelo em conferências, workshops e treinamentos. Os
atendentes geram uma conexão imediata com as menti-
ras, reforçando a nossa crença de que há um padrão de
repetição em diferentes organizações. Aliás, parece ser
internacional, pois o mesmo aconteceu em diferentes paí-
ses (Brasil, EUA, México, França e Áustria).

É muito comum, em um processo de empatia, o pú-

blico mapear os personagens às pessoas reais em suas
empresas. Porém, avisamos que não há uma relação um
para um entre personagens e pessoas na vida real. Al-
gumas das mentiras que vamos relatar são executadas às
vezes por mais de uma pessoa; e uma mesma pessoa pode
interpretar mais de um personagem.

Qualquer semelhança com a realidade é mera coinci-

4
dência! Ou não.

Aviso 2
Cuidado para não culpar diretamente as pessoas!

O problema está no sistema e não nas pessoas [15].

Se os padrões se repetem, então não adianta trocar as
pessoas dentro da empresa, porque as mentiras estarão
lá novamente. Mas então, o que fazer? Temos que mu-
dar o sistema! Uma vez que criamos consciência sobre os
padrões de mentiras e todas as mazelas decorrentes dele,
é nossa obrigação alterarmos o sistema para que isso não
se perpetue na vida das pessoas! Se não nos esforçamos
nesse sentido, nós nos tornamos os culpados dessa histó-
ria!

Não culpe as pessoas, culpe o sistema!

Donella Meadows

5
Capítulo 1

1o andar de mentiras:
Escopo fixo

A primeira grande mentira está na crença de que o escopo

de um projeto deve ser todo escrito no início e que isso
não deveria mudar. Todas as vezes em que perguntamos
em empresas quais são os maiores problemas de projetos
de longo prazo, as respostas sempre incluem pelo menos
um desses itens:

• o escopo vive mudando,

• os requisitos foram mal levantados no início, ou

• o cliente não sabe o que quer.

Figura 1.1: No primeiro andar de mentira, o escopo fixo,
moram três personagens: Rei Jassei, Astrônomo Nada-
muda, e a Princesa Jaquê.

Esse relato aparece em todos os tipos de empresa:

startups ou grandes corporações, empresas novas ou tra-
dicionais, no Brasil ou no exterior. Se isso sempre é re-
latado, não deveríamos mais considerar um problema,
deveríamos considerar isso um fato! FATO: o escopo vai
mudar; FATO: o cliente não sabe o que quer! Uma vez
que consideramos isso um fato, a pergunta é: qual é o
melhor método que podemos usar? (Nossa resposta aqui
é a adoção de métodos ágeis com escopo flexível. Mais
sobre isso na Parte “Qual é a alternativa?”)

Portanto, o primeiro personagem é o Rei Jassei (vide

Figura 1.2). O Rei representa aquela pessoa que está
confiante que já sabe a solução. A verdade é que muitas
vezes nem o problema ele sabe.

7
Figura 1.2: A primeira mentira do nosso castelo é o Rei
Jassei. Ele sabe exatamente o que quer. Ele fecha o
escopo do projeto e assume a paternidade ou maternidade
da solução. “Aqui quem manda sou eu”.

Fica ainda pior quando essa ideia leva o nome do rei.

Agora ele irá defender sua ideia como se a sua sobrevivên-
cia dependesse dela. Essa relação entre criador e criatura
impede que o seu pedido seja questionável, e à medida
que o tempo passa, o apego vai se tornando ainda maior.

Essa individualização da criação (“ideia do fulano”,

“ideia da beltrana”) é reflexo de um processo criativo
ruim. Na verdade, as melhores criações são aquelas que

8
consideram a inteligência coletiva, pessoas criando em
cima das sugestões uns dos outros (vide TED talk: “When
ideas have sex” [21]).

Em um processo criativo saudável, não

se sabe de quem foi a ideia.
Rodrigo de Toledo

A verdade é que é natural o escopo mudar. São di-

versos os motivos:

• o cenário do mercado muda;

• a concorrência avança;
• o nosso entendimento refina; e
• as métricas do produto apontam novas direções.

Portanto, é desejado que o escopo mude! Muitas

empresas têm um termômetro medindo se um projeto
muda de escopo. Esse termômetro é importante, mas
estávamos medindo na direção errada. Devemos conti-
nuar usando esse termômetro sim, mas para disparar um
alarme toda vez em que haja um projeto em que o escopo
não está mudando. “Toca o alarme aí porque esse pro-
jeto não está mudando o escopo”. Se o escopo não está

9
Figura 1.3: Astrônomo Nadamuda é aquela mentira
em que a pessoa consegue prever com exatidão um ce-
nário futuro. Sendo assim, ele tem certeza de que nada
mudará nos próximos meses ou anos antes da entrega do
produto.

mudando, isso é sinal de que ou não estamos entregando

com frequência, ou não estamos mostrando para as pes-
soas certas ou não há mais valor no que está sendo feito.
O normal é mudar como veremos no Capítulo 7, Foco
no problema e não na solução.

O personagem Astrônomo Nadamuda (Figura 1.3) é

aquele que está se iludindo sobre o futuro. Ele usa a

10
situação atual como justificativa do que será feito, mas
que só estará pronto depois de um ano, como se o cenário
não fosse mudar nesse meio tempo. Acreditar nisso, ou
similarmente, acreditar que somos capazes de prever o
futuro, é a mentira representada por esse personagem.

Segundo o Standish group, mesmo os projetos que en-

tregaram com sucesso o escopo definido no início, apenas
20% das funcionalidades são efetivamente usadas (e quase
50% rarissimamente usadas) [25]. Parte desse grande nú-
mero de inutilidades é decorrente da forma como levanta-
mos os requisitos de grandes projetos. Quando uma área
cliente finalmente tem um projeto aprovado, ele sente
como uma oportunidade para fazer demanda. É claro
que isso o induz a pedir itens de utilidade duvidosa, pois
ele quer aproveitar ao máximo a janela de oportunidade.
Falaremos sobre a solução de problemas decorrentes desta
mentira no Capítulo 6, Escopo flexível.

Finalmente, a última mentira desse primeiro andar.

O processo atual de grandes empresas para aprovação ou
reprovação de projetos, criou um modelo de filas, onde os
clientes internos ficam esperando a sua vez. Isso leva a
um entendimento de que quando finalmente o seu projeto
está em discussão, há a tal janela de oportunidade. Se
perder essa janela, nem sabemos mais quando haverá ou-
tra. Ou seja, é o momento para se pedir tudo, até mesmo
aquilo que não sabemos se será necessário.

11
 Nesse ponto entra a princesa Jaquê (Figura 1.4). “Já
que estamos fazendo isso, vamos aproveitar e fazer mais
aquilo e aquilo outro”. Quando alguém pergunta se a
lista de requisitos está completa, antes mesmo que o Rei
Jassei responda a princesa entra: “Papai, já que estamos
pedindo essas coisas, que tal mais esses penduricalhos”.
Com isso, vamos aumentando a quantidade de itens inú-
teis dentro do projeto. Conversaremos sobre possíveis
soluções para esse problema no Capítulo ??, ??.

A base mentirosa desse primeiro andar já deveria ser

o suficiente para interromper qualquer etapa posterior.
Mas a enganação continua com novos andares mentirosos
que veremos a seguir.

12
Figura 1.4: A Princesa Jaquê sempre quer tirar pro-
veito de uma janela de oportunidade. Uma vez que ela
ganhou a chance do projeto ser executado, ela pede um
monte de coisas antes que a janela se feche. Muitas das
coisas são irrelevantes, mas já que ganhou a oportuni-
dade, é melhor pedir, mesmo que aumente os pendurica-
lhos inúteis que vemos nos projetos por aí.

13
Capítulo 2

2o andar de mentiras:
Estimativas de prazo e
custo

Uma vez que já listamos “todo” escopo (mentiras do 1o

andar), agora é a hora de estimar o prazo e custo do
projeto. Esse andar de mentira é muito doloroso por
envolver várias horas do time técnico. Para fazer uma
estimativa de prazo, temos que saber o esforço de cada
etapa técnica. O esforço envolve o detalhamento técnico,
especificações e a interpretação do que foi definido no
levantamento de requisitos, a base do castelo de mentiras
descrita no Capítulo 1.
 A pressão pela estimativa muitas vezes vem do ne-
gócio. Afinal, precisamos da estimativa para saber se
o custo caberá no orçamento da nossa carteira do ano
que vem. Porém o primeiro personagem mentiroso deste
andar está do lado técnico: o Mago Analista.

Para sermos capazes de estimar, primeiro precisamos

ter uma noção exata do que deve ser feito. A partir do es-
copo (com todas as mentiras do 1o andar) podemos fazer
uma análise técnica da execução. Surgem então artefa-
tos mentirosos: projeto lógico, Work Breakdown Struc-
ture (WBS), mapa de entidades e relacionamentos etc.
Há linguagens e símbolos desenvolvidos para que seja-
mos capazes de fazer toda essa especificação em forma
de texto e diagramas.

Figura 2.1: No segundo andar de mentira, o momento das

estimativas de prazo e custo, moram três personagens:
Arquiteto Medetudo, Mago Analista e o Prometeus.

15
Figura 2.2: O Mago Analista garante que é capaz de
fazer uma profunda análise em todo o trabalho antes de
consultar as pessoas que desenvolverão o projeto. Através
de uma série de modelos ele desenha um mundo perfeito,
porém irreal.

O Mago Analista (Figura 2.2) representa múltiplos

papéis da vida real: analista de sistemas, analista de
requisitos, analista de processos, analista de estratégia,
analista de negócios, etc. Quando posteriormente o de-
senvolvimento do projeto começa, essas diversas docu-
mentações produzidas se demonstram erradas, incomple-
tas ou irreais. É muito comum também uma total se-
gregação entre quem faz a análise e quem executa, nor-

16
malmente acentuada por um distanciamento no tempo.
O time acaba por ter um enorme esforço de interpreta-
ção desses artefatos sem a ajuda de quem os criou. No
Capítulo ??, ??, abordaremos algumas soluções para evi-
tarmos esse problema.

É errado utilizar ferramentas como WBS, BPMN,

UML, etc.? Na verdade, o problema está na forma como
as utilizamos. O mundo real é complexo e até mesmo
caótico, por isso que não conseguimos “encaixotá-lo” em
documentos e diagramas. Essas ferramentas são úteis
quando usadas de apoio ao diálogo e à troca de conheci-
mento para que a compreensão seja muito mais eficaz. As
ferramentas são boas, mas não podemos ser subordinados
a elas.

O ser humano tem que ser soberano às

ferramentas.
Rodrigo de Toledo

Uma vez que se tem o detalhamento do trabalho, fi-

nalmente pode-se estimar. Entra então outro persona-
gem: o Arquiteto Medetudo (Figura 2.3)! Munido de fer-
ramentas inapropriadas (pontos de função, homem-hora,
homem-dia, etc.) o arquiteto então irá medir o custo e
prazo do projeto. Mas estamos falando de um trabalho
criativo. Trabalho criativo é não linear, não pode ser

17
Figura 2.3: Arquiteto Medetudo, acha que é capaz de
medir uma obra de arte com centímetros e um trabalho
intelectual criativo com homem-horas.

medido em horas.

O trabalhador do conhecimento é diferente do traba-

lhador repetitivo ou braçal [7]. É fácil estimar o tempo
que levará um pintor de parede para executar o seu tra-
balho pela própria linearidade da sua execução. Se em
duas horas ele pintou metade da parede, em quatro ho-
ras se espera que o trabalho esteja inteiramente realizado.
Já um pintor de um quadro artístico se torna muito mais
imprevisível. O mesmo acontece com o trabalhador do
conhecimento: programadores, designers, redatores etc.

18
Uma previsão nesses casos só é honesta se for uma faixa
no tempo com distribuição de probabilidade. Ex.: 20%
de chance de estar pronto em 100 dias, 60% em 115 dias,
95% em 130 dias, etc. No Capítulo 11, Produtos mais
que projetos, trataremos sobre a nova visão que temos
que ter sobre o resultado do nosso trabalho.

O arquiteto Medetudo finalmente pode ter a estima-

tiva de prazo e, portanto, custo. Sustentado por mais um
outro conjunto de artefatos enganadores: Gantt charts,
gráficos de dependências, etc.

Quando finalmente estamos prontos para reportar ao

negócio as nossas estimativas, entra o último personagem
deste andar: o Prometeus.

Prometeus é um personagem já experiente, que so-

freu diversas vezes a pressão por ter estimado e não con-
seguido cumprir. Ele tem medo de estar numa situação
dessas novamente. Digamos que depois de todo esse deta-
lhamento e estimativas, chegamos a um prazo de 8 meses
para o desenvolvimento. Prometeus irá então dizer 12
meses.

Tal como na Figura 2.4 que, com o receio de ser in-

suficiente, inclui uma espadinha a mais além da espada
principal, O Prometeus precisa incluir uma gordurinha.
O conceito de gordurinha, é para que haja espaço para

19
Figura 2.4: O Prometeus tem medo de ser pego de
surpresa. Se o time ou o analista disse que o projeto será
entregue em 8 meses, por via das dúvidas, ele insere uma
“gordurinha” no prazo e promete para 12 meses. Vai que
algo dá errado?

queimar mais tarde. Esse termo “gordurinha” é tipica-

mente brasileiro, em português lusitano, o termo é mais
honesto: “margem de cagaço”.

O 2o andar é muito desgastante. O time é obrigado

a parar sua atividade produtiva para fazer estimativa,
muitas vezes por semanas. A moral do time é abalada!
Alguns se sentem enganados por antecipação porque sa-

20
bem que o escopo irá mudar. Outros sabem que estão
enganando, pois terão que dar prazos sobre um trabalho
criativo, como se ele fosse linear, igual ao de um trabalho
braçal. Há ainda aqueles que propositadamente incluem
uma “gordurinha” para não serem cobrados com muito
aperto. Muitas vezes o time que executará nem é o time
que faz a previsão. Como eles podem se comprometer
com um prazo que não foi dado por eles? Transparência
(Capítulo 5) é fundamental.

Resultado deste andar: improdutividade; cálculo de

prazo (e custo) irreal; produção de artefatos inúteis; e
mais um time desmoralizado que já antevê as consequên-
cias ruins.

Mas ainda não acabou, pois restam mais dois andares

de mentiras.

21
Capítulo 3

3o andar de mentiras:
Estimativa de valor

Este andar de mentiras é inerente ao modelo de gestão

tradicional de portfólio. Como veremos, a mentira que
mora aqui é fácil de ser criada, seu resultado é extrema-
mente danoso.

A gestão tradicional de portfólio, normalmente segue

um rito de escolha sazonal dos projetos para o próximo
período fiscal. Dependendo da organização a sazonali-
dade pode ser diferente (ex.: trimestral, anual ou até tri-
enal). Para a tomada de decisão, cada projeto tem que
ter seu escopo fechado (1o andar de mentira, Capítulo
1) e sua estimativa de prazo/custo (2o andar de mentira,
Capítulo 2). Mas isso não basta, pois para a decisão se
um projeto entra ou não vai depender do ROI desse pro-
jeto. O ROI (Return On Investiment, Retorno sobre o
Investimento) estimado para um projeto é uma equação
simples:

R Retornoestimado
ROIestimado = = (3.1)
I Custoestimado

A Equação 3.1 é uma aproximação do cálculo de ROI,

pois o dividendo deveria ser lucro, mas isso é irrelevante
para o contexto aqui [18].

Como mostraremos na segunda parte do livro, o cál-

culo de ROI nem é a ferramenta adequada para essa to-
mada de decisão. Preferimos usar o CoD (Cost of Delay
- Custo de Retardo), que calcula o custo ao retardar uma
entrega (veja Capítulo ??). Decidir retardar o início de
um projeto é particularmente importante porque come-
çar todos ao mesmo tempo é ineficiente (veja Lei de Little
no Capítulo 9).

Numa discussão de portfólio, há uma grande quanti-

dade de projetos de diversas áreas que disputam entre si
para serem os escolhidos. É natural que haja muita po-
lítica envolvida e, nessa briga, muitas vezes o vencedor é
“quem grita mais alto”. Para evitar decisões subjetivas,

23
Figura 3.1: No terceiro andar de mentira, há apenas um
morador: o Masvalia. Ele fará de tudo para que o pro-
jeto entre no portfólio do próximo ano. Para isso, se
necessário, ele “estimará” um retorno absurdo do pro-
jeto dele, mesmo que seja algo totalmente irreal. É uma
mentira fácil de fazer, porém com um impacto terrível.

o ROI (Equação 3.1) deveria ser uma ferramenta de de-

cisão racional. Porém, é claro que um bom Retorno (R)
favorece a decisão a favor de um projeto e por isso vemos
uma inflação dessa variável. Colocar um zero a mais nela
não é tão custoso, e aumenta dez vezes a chance de ser
um projeto escolhido para entrar na próxima carteira de
projetos em andamento.

24
 Demos o nome de Masvalia (Figura 3.1) para o único
morador deste andar. Muitas vezes ele é o cara de negócio
que estava esperando na fila de projetos há um tempo.
Ele não quer perder essa oportunidade, nem que para isso
tenha que colocar alguns zeros a mais. “Retorno de 10
milhões não é suficiente para entrar no portfólio? Então
vamos dizer que o Retorno esperado é de 10 bilhões!”

Como há pouco embasamento de dados para a es-

timativa de valor, essa mentira é de baixo custo, pois
não requer muito esforço. Porém, ela pode se tornar a
maior das mentiras. Nas empresas que prestamos con-
sultoria, ouvimos relatos de projetos cujo valor esperado
era da ordem de muitos milhões. Todavia, quando dis-
ponibilizados, não houve nenhum interesse por parte do
consumidor final.

Há ainda outro fator importante dessa mentira: O

Masvalia normalmente não é cobrado por esse resultado
negativo, muitas vezes as pessoas nem lembram mais
quem era ele. Comentaremos sobre soluções para o Mas-
valia no Capítulo 13, Redistribuição orçamentária.

25
Capítulo 4

4o andar de mentiras:
Acompanhamento de
projetos

Numa sequência de mentiras sobrepostas, a última é a

que será menos crível. Tal como num prédio feito de
gelatina, o último andar é completamente instável.

No modelo projetizado das empresas, a cobrança de

acompanhamento do estado do projeto é a ferramenta
usada para medição de avanço. Mais do que isso, o alto
nível hierárquico usa essa métrica como instrumento de
pressão e de cobrança. Soma-se a isso o fato de que o
número total de projetos é muito maior do que deveria
Figura 4.1: No último andar, o ápice da enganação, mo-
ram duas mentiras: o Equilibrista (com seu comitê real)
e o Verde Melancia.

ser (vide Little’s Law na Seção 9.2). Com o intuito de

acelerar o julgamento dos diversos projetos (há empresas
com centenas de iniciativas sendo executadas em para-
lelo) um mecanismo de sinalização baseado em cores é
usado. Verde significa que o projeto está dentro do prazo,
Amarelo ligeiramente fora do prazo, e Vermelho bem fora
do prazo.

A primeira mentira a ser mencionada deste andar é

justamente o fato de acompanharmos prazo ao invés de
resultado. Como veremos na Seção 10.2, Está na hora
de acompanhar a eficácia, ter os resultados alcançados
(eficácia) é muito mais relevante que terminar no prazo
(eficiência). A reunião de acompanhamento é muitas ve-
zes onde estão os maiores salários de uma organização.

27
Figura 4.2: O Equilibrista com as cores verde, ama-
relo e vermelho quer mostrar o andamento dos projetos
para o Comitê real, discutindo a mentira da mentira da
mentira.

Já vimos reuniões semanais com quatro Vice-Presidentes

de um grande banco de varejo - imaginando o custo do
minuto deste “comitê real” (Figura 4.2). Eles deveriam
usar esse momento para discutir assuntos extremamente
mais relevantes como: aumento da carteira, diminuição
de taxa de abandono, aumento da margem ou qualquer
outro assunto ligado a resultados de negócio. Mas não é
isso que acontece, as pessoas acabam por discutir o que
está ou não dentro do cronograma esperado. O equili-

28
brista, também presente na Figura 4.2 (muitas vezes o
Project Management Office - PMO da empresa) passa a
fazer malabarismo para mostrar esses avanços de crono-
grama.

Como há uma alta cobrança para que os projetos es-

tejam no prazo, os relatórios são orientados para que de
fato eles fiquem verdes. Os responsáveis pelos projetos
não querem que o seu fique vermelho ou amarelo, senão
receberão cobrança diretamente do comitê real. Devida
à pressão, as pessoas manipulam os números para que
seus projetos pareçam verdes sob os olhos do alto esca-
lão. Surge então o chamado verde melancia 4.3, projetos
que parecem verdes por fora, mas estão vermelhos por
dentro.

Durante todo a vida útil do projeto, o percentual

cresce proporcional ao tempo que se passou (ex.: me-
tade do tempo, então 50% de andamento), mas quando
se aproximam do prazo, ficam em 99% e se arrastam nesse
estado, atrasando a entrega.

Nessa etapa de acompanhamento da carteira de pro-

jetos, o acúmulo de mentiras é tão grande e tóxico que o
problema não é encarado frontalmente. Os personagens
dessa história preferem omitir a realidade trágica e as-
sumem que a única coisa a fazer é a pressão pelo prazo
para que acabe de vez o sofrimento.

29
Figura 4.3: A mentira Verde Melancia acontece porque
mesmo que o projeto esteja no vermelho, ele é apresen-
tado com uma casca de verde, afinal, todos querem fugir
da pressão de estar fora do prazo.

30
 Parte II

Limpando o castelo
Limpando o castelo

Não existe uma alternativa única ao castelo. Existem

diversos princípios e práticas recomendadas para fugir
desse ciclo vicioso de mentiras. Nos próximos nove capí-
tulos, apresentamos algumas dessas recomendações, numa
possível ordem cronológica. Porém, não é uma receita de
bolo. Vários desses itens podem ser aplicados isolada-
mente ou mesmo em uma ordem que melhor resolva os
problemas do seu time ou empresa.

Nesta parte trataremos sobre as melhorias na gestão

de projetos. Os três capítulos de Limpando o castelo
abordam mudanças evolucionárias e podem ser adotadas
pelos times sem grande necessidade de interferência de
gestores ou diretores.

Segue uma explicação breve sobre os três capítulos

desta segunda parte:
• Capítulo 5, Transparência e Agilidade: obvi-
amente, para eliminar as mentiras, precisamos ter
mais transparência. Para isso, usamos os princípios
dos métodos ágeis para tornar visível a realidade.

• Capítulo 6, Escopo flexível: para derrubar o

castelo tem que se começar limpando a base, ou
seja, se opondo ao escopo fixo. Nesse capítulo, des-
crevemos diferentes níveis de flexibilização e dife-
rentes formas de responder à pergunta: “Quando
fica pronto?”.

• Capítulo 7, Foco no problema e não na so-

lução: uma das enganações que está por trás das
mentiras no castelo é a crença em que a solução
desenhada é o objetivo; até o ponto que as pessoas
nem lembrarem mais qual era o problema a ser re-
solvido.

33
Capítulo 5

Transparência e
Agilidade

Dizemos que os métodos ágeis não resolvem os proble-

mas, mas os expõe. As pessoas é que resolvem os pro-
blemas! Essa é uma forte mudança de paradigma cul-
tural em empresas tradicionais. Em muitas empresas,
é comum o comportamento de esconder o problema. O
castelo de mentiras existe porque há uma “vista grossa”
para não expor a realidade. Isso é uma consequência
forte do modelo de hierarquias e promoções. Ninguém
quer ser o portador da notícia ruim para não levar uma
bronca do chefe que diminua a chance de uma promoção.
Surge então o comportamento de camuflar ou minimizar
os problemas, por exemplo, a mentira Verde Melancia do
Capítulo 4 e o Prometeus no Capítulo 2. Cuidado para
não culpar especificamente alguém por esse comporta-
mento, pois o problema está muito mais no sistema do
que nas pessoas envolvidas nas mentiras [15].

O Scrum não resolve seus problemas. O

Scrum mostra seus problemas. Você é
quem deve corrigi-los.
Ron Jeffries

Precisamos criar uma cultura onde a exposição de um

problema não pode ser algo temido. Se há uma cultura
de busca pelo culpado, a consequência é levar as pessoas
a não experimentarem mais nada, inclusive nos seus pro-
cessos de trabalho. Ou seja, zero inovação e zero melhoria
contínua. Muitas vezes, a causa raiz está em uma men-
talidade de desconfiança máxima: “sem chefe ninguém
trabalha direito”. Como reverter esse cenário de descon-
fiança? Transparência e ciclos curtos de aprendizado são
a chave para reverter esse cenário.

Como reconstruir confiança? Ciclos

curtos e transparência.
Rodrigo de Toledo

35
5.1 Ciclos curtos
Quando o time inicia o projeto e só volta a apresentar os
resultados após um ano de trabalho, é provável que esteja
de frente para uma catástrofe. Primeiro porque o cliente
acumulou um ano de expectativa sobre um produto ou
serviço, segundo porque o esforço do time provavelmente
foi direcionado em um sentido errado feito em uma visão
que está desatualizada há um ano. Pouca iteração acaba
tornando qualquer interpretação excessivamente ambígua
[20].

Ciclos curtos em que a evolução do trabalho seja apre-

sentada no formato de resultados concretos são funda-
mentais para evitar esse cenário. Imagine agora que ao
invés de fazer uma entrega ao ano, o time passe a fazer
uma entrega por mês. Em um ano esse time terá 12 chan-
ces de apresentar resultados e corrigir rumos. Agora, se
o time fizer entregas semanais, teremos 52 chances para
tal.

Temos que ter uma mentalidade onde o erro tem que

ser visto como oportunidade de aprendizado. Temos que
nos permitir pequenos erros e criar um ambiente de rá-
pido aprendizado a partir do erro. Por isso usamos a
frase: “falhar rápido e aprender mais rápido ainda!” (“Fail
fast, learn faster!” [5]). Em um mundo de constantes
mudanças, a capacidade de reação ao imprevisto é muito

36
mais importante que a soberba de querer acertar de pri-
meira.

Figura 5.1: Falhe rápido e aprenda mais rápido ainda.

Além da mudança cultural, é importante trazer uma

mudança organizacional, na forma como trabalhamos.
Queremos ter entregas frequentes! Estamos falando de
entregas ponta-a-ponta, não de entregas parciais, ou seja,
entregas de valor para o cliente final. Tradicionalmente,
só é possível ver valor sendo entregue quando termina
o prazo de entrega (às vezes só depois devido aos atra-
sos). Queremos ver os times entregando valor com alta
frequência.

Há uma analogia muito interessante descrita por [17].

A frequência de entrega é equivalente à altura da lâmina

37
d’água em um lago. Os problemas são as imperfeições
no fundo do lago. Quanto maior a lâmina d’água, menos
vamos enxergar os problemas. Porém, quanto menor for
a lâmina d’água, mais as pedras do fundo do lago vão
aparecer. Assim acontece quando reduzimos o ciclo de
entrega. Quanto menor o ciclo (ou maior frequência),
mais os problemas irão aparecer. Essa transparência é o
primeiro passo da melhoria contínua.

Ou seja, temos que alterar os nossos processos para

ter a maior frequência possível de entregas. Levar um
ano para entregar algo de valor é muito para os dias de
hoje. Queremos ciclos menores, três meses, um mês, a
cada duas semanas, semanalmente... Quanto menor o
ciclo, melhor. Até chegarmos num modelo de “Entrega
Contínua (continuous delivery [8])”. É claro que a redu-
ção do ciclo é mais fácil ou difícil dependendo do domínio
de atuação da organização. No mundo digital, a continui-
dade é mais natural, mas também é possível no mundo
físico.

5.2 Agilidade fora do digital?

Se estivermos falando de uma obra civil, certamente é
mais difícil ser ágil. Já em produtos digitais, a tendên-
cia é ser muito mais fácil pela natureza do conteúdo. No
primeiro caso, estamos falando de tijolos, no segundo es-

38
tamos tratando de bits, 0 ou 1. Mesmo em obra civil,
há cenários onde pode haver entregas de valor durante
a construção. Por exemplo, ao construir um condomí-
nio, entregar casa a casa é melhor do que por etapas de
construção (todo o terreno, todas as paredes, por último
todos os telhados); ou entregar uma estrada quilômetro
a quilômetro pronto, ao invés de toda a terraplanagem,
depois toda a brita, depois asfalto e depois a tinta de
tudo.

A expansão da adoção de métodos ágeis em diferen-

tes indústrias se dá por dois motivos, como dois vetores
que se encontram. Cada vez mais nos desafiamos a ex-
pandir a Agilidade. Numa primeira onda, nos anos 90,
os métodos ágeis começaram apenas em TI. A segunda
onda, veio como consequência do sucesso: a TI deixa de
ser o patinho feio, aquela área que é cara, demorada e
que quando entrega não era o que se esperava. Como
a TI começa a entregar valor desde o início, corrigindo
rumos etc., outras áreas dentro das empresas passam a
querer fazer igual. Finalmente, numa terceira onda mais
recente, as empresas passam a querer adotar métodos
ágeis, independentemente da TI. Indústria de cosméti-
cos, educação, fabricantes de hardware etc., querem que
suas equipes trabalhem de forma ágil.

Além disso, há uma outra mudança, a transforma-

ção digital. Cada vez mais indústrias tão tradicionais no

39
Figura 5.2: A fronteira até onde vai a agilidade conti-
nua se expandindo por causa desses dois vetores. Cada
vez mais temos desafiado áreas longe do digital a usa-
rem métodos ágeis (RH, Financeiro, Auditoria, Jurídico
etc.). Ao mesmo tempo, cada vez mais há negócios mi-
grando do mundo físico para o mundo digital, a chamada
transformação digital.

mundo físico, começam a rever o entendimento do seu

business. Muitas dessas indústrias entendem que ou elas
se tornam digitais, ou elas tenderão a desaparecer.

Esses dois vetores se encontrando fazem com que a

demanda por agilidade cresça. Há, portanto, um ciclo de
crescimento, dado a maior variedade de cases, nos desa-
fiamos ainda mais a expandir a agilidade e assim suces-
sivamente. Vamos tratar mais desse assunto no Capítulo
11, Produtos mais que projetos.

40
5.3 Transparência para geração
de melhoria
Claro que a transparência inclui expor também outras
coisas além dos problemas: propósito de negócio claro,
acordos internos de times, métricas etc. Também es-
tamos falando em parar de mentir, a final de contas,
o propósito deste livro é derrubar o castelo de menti-
ras. Porém, o que estamos reforçando é que a verdadeira
transparência acontece quando colocamos o bode na sala
(Figura 5.3). Por isso, que todos os métodos ágeis estão
calcados na ideia de melhoria contínua.

Os dois principais pontos dos métodos

ágeis são: ciclos curtos e melhoria
contínua.
Rodrigo de Toledo

(O terceiro ponto é foco no valor, mas se estivermos

fazendo os dois primeiros, então o foco no valor virá na-
turalmente.)

A prática mais popular para realizarmos a melhoria

contínua é a reunião de retrospectiva. Ela deve acontecer
em ciclos curtos e regulares. Não deve ser muito longa
e termina quando chegamos a uma ação concreta para

41
Figura 5.3: “Bote o bode na sala!” É uma expressão
usada para dizer que não devemos esconder o problema,
mas colocá-lo bem exposto, para que ao incomodar nos
force a falar sobre ele. Tal como se colocássemos um
bode na nossa sala de jantar, inevitavelmente o espaço,
aparência e odor nos fariam ter que falar sobre o bode!

a melhoria do trabalho do time. Essa ação deverá ser

experimentada no próximo ciclo enquanto métricas são
coletadas para validar a eficácia da ação. Se for aprovada,
a ação passa a fazer parte do trabalho do time enquanto
for necessária.

42
Como ser transparente?
Uma vez expostos os problemas, quem irá resolvê-los? As
pessoas!

Somos nós que temos que resolver num modelo de

experimentações curtas. Podemos aproveitar o mesmo
ciclo curto de entrega para fazer a validação de melhorias.
Isso é chamado de melhoria contínua!

Quadros físicos na parede são uma boa forma de dar

transparência aos problemas. Quando mapeamos nosso
fluxo de valor e representamos os itens que proporcionam
agregação de valor nele, temos uma visão real do estado
em que cada coisa se encontra, mesmo num quadro digi-
tal, como apresentado na Figura 5.4.

A característica fundamental da transparência é não

ter medo de apresentar erros e problemas que o time ou
empresa enfrenta. Essas coisas são normais e na maio-
ria das vezes inevitáveis. Se os ciclos curtos estão sendo
realizados e há consciência que a melhoria contínua deve
ser aplicada, eles representarão grandes oportunidades de
aprendizado.

Esconder problemas hoje é criar uma

briga futura.
Avelino F. Gomes Filho

43
Figura 5.4: Quadro físico mapeando o fluxo de valor de
um time.

44
Capítulo 6

Escopo flexível

Para fugir das mentiras do Rei Jassei e do Astrônomo

Nadamuda, temos que abraçar a incerteza. A verdade é
que o cliente não sabe o que quer enquanto não começa a
usar [9]. Então a única coisa honesta a fazer é não fechar
o escopo completo no início.

O uso define o produto!

Rafael Sabbagh

Flexibilizar o escopo não é trivial, afinal, como saber

quando termina? Talvez até essa pergunta devesse ser
reformulada, pois o que mais vemos hoje são produtos
de sucesso que não terminam, são continuamente atua-
 Figura 6.1: O uso define o produto.

lizados (vide Capítulo 11, Produtos mais que projetos).

Normalmente se um produto digital não está sendo atu-
alizado, provavelmente é porque não deu certo.

Para poder falar de flexibilização, primeiro vamos en-

tender as três variáveis pré-fixadas do mundo tradicional:
escopo, prazo e custo.

6.1 O Triângulo de Ferro

Em gerenciamento tradicional, a analogia do triângulo é
usada para representar as três variáveis básicas de um
projeto: escopo, prazo e custo. O ferro simboliza a ri-
gidez, pois essas variáveis só podem ser modificadas du-
rante a concepção inicial, pois uma vez estabelecidas elas

46
Figura 6.2: Triângulo de Ferro Tradicional: Escopo,
prazo e custo fixados.

estão rigidamente fixadas.

Na prática, esse triângulo está na base do castelo de

mentiras, onde o primeiro passo é o escopo (1o andar),
para depois estimarmos o prazo e o custo (2o andar),
sabendo que muitas vezes o custo é um resultado quase
direto do prazo. Ou seja, o escopo é dado e então o prazo
e custo são estimados (vide triângulo na Figura 6.2).

A compreensão de que isso é uma mentira, dado tudo

o que vimos nos primeiros capítulos, leva ao questiona-
mento natural:

– Se permitimos escopo flexível, como calcular o prazo

e o custo?

Na verdade, existe uma gradação de diferentes formas

de flexibilizar o escopo. Vamos ver alguns desses passos,

47
começando por um degrau intermediário entre o escopo
fixo e a flexibilidade máxima: a inversão do triângulo de
ferro.

A inversão do triângulo de ferro

Existe um segredo por trás da fatídica pergunta: “Quando
fica pronto?”. O segredo é que é muito comum prazo e
verba já estarem pré-estabelecidos antes mesmo de esti-
mar, porém, não de forma explícita no início. Muitas
vezes o time técnico calcula um prazo (por exemplo, 8
meses) e quando o apresenta, ouve do lado do negócio
que o prazo tem que ser menor (por exemplo, 6 meses).
Ou seja, a restrição já estava lá, só não estava explícita!

Isso acontece porque o cliente já tem uma ideia de

prazo, provavelmente atrelada a alguma oportunidade de
negócio. Mesma coisa acontece com o custo, pois diversas
vezes há um orçamento definido para gastar. No governo,
por exemplo, esse orçamento costuma ser aprovado no
ano anterior, antes mesmo da definição exata do escopo.

Neste ponto aqui, estamos propondo uma inversão do

triângulo: dado um prazo e um custo, o escopo é
estimado. Ao inverter o Triângulo de Ferro, fixamos as
principais restrições no início, podendo até estimular o
descarte de escopo desnecessário antes de começarmos a
construir os primeiros andares do Castelo de Mentiras.

48
 Figura 6.3: Triângulo de Ferro Invertido

O triângulo invertido pode ser visto como uma opção

para contratos (tanto entre empresas quanto acordos in-
ternos). Ao invés de partir de um escopo para estimar
prazo e custo, podemos fazer a lógica invertida. Dado um
prazo e um custo já fixados, qual será o escopo? Mesmo
que isso não nos leve a um escopo continuamente flexível,
já é um excelente começo. Mas atenção, existem modelos
de contrato mais inteligentes que esse, como venda por
empreitada ou Money for Nothing and Your Change for
Free (vamos ver mais a frente).

49
6.2 Planejamento contínuo
O primeiro andar do castelo de mentiras só será desfeito
se as empresas abraçarem a flexibilidade do escopo. A
motivação primária está no fato de que não sabemos pre-
ver todas as necessidades ao longo do caminho. Além
disso, o mundo muda, os concorrentes se mexem, as leis
se alteram, a tecnologia avança, etc. Queremos evitar a
mentira do Astrônomo Nadamuda. Especificar tudo no
início é um contrassenso, num mundo onde a complexi-
dade e a volatilidade são cada vez mais latentes. Isso é
o chamado mundo VUCA: Volatility, Uncertainty, Com-
plexity, and Ambiguity (volátil, incerto, complexo e am-
bíguo) [4].

Analogia do horizonte
Vamos explicar aqui a analogia do horizonte criada por
Rafael Sabbagh [23]. Observe a Figura 6.4, imagine que
você é aquele gestor que está olhando para a rua na cidade
de São Francisco. Se alguém pedir para você descrever
tudo o que você está vendo no primeiro quarteirão, é
possível dar bastante detalhes. Por exemplo: quantos
andares em cada prédio; quantas janelas por andar; se
há uma escada na frente; quantos degraus; se houver um
carro, pode-se descrever cor, modelo e até placa. Mas se
te pedirem para descrever do 2o ao 4o quarteirão sem sair
daquela posição? Ainda é possível dar detalhes: total de

50
Figura 6.4: Analogia do horizonte. Nível de detalha-
mento é menor quanto mais longe no tempo.

andares dos prédios, mas não quantas janelas por andar;

se há uma escada na frente, mas não o total de degraus;
cor e modelo de carros, mas talvez não suas placas. Um
pouco mais distante, do 5o ao 10o quarteirão? Talvez
ainda você ainda possa dizer altura dos prédios, mas não
será mais possível dizer se há escadas na frente; talvez
possamos dizer cor de carro, mas não modelo ou placa.
Finalmente, se te pedirem para descrever o que está lá
no final da rua? A resposta será algo como: “mais prédio
pra cá e mais carro pra lá” e nada mais além disso.

Mas se você insistir em dar todos os detalhes da rua

51
do início ao fim (sem sair daquela posição), das três, pelo
menos uma:
• ou você está se enganando;
• ou você está sendo enganado;
• ou você está enganando alguém;
porque não dá para descrever a rua inteira no mesmo
nível de detalhe do primeiro quarteirão!

Qual é a analogia aqui? A rua representa a linha

do tempo do seu projeto, não dá para planejar tudo no
mesmo nível de detalhe. Se você tentar descrever o es-
copo e o plano de trabalho no mesmo nível de detalhe do
início ao fim, das três, pelo menos uma:
• ou você está se enganando;
• ou você está sendo enganado;
• ou você está enganando alguém.

Ou seja, aquilo que vamos fazer no nosso projeto ou

iniciativa daqui a mais de 6 meses, descrevemos apenas
superficialmente; o que faremos daqui a 3 meses, um
pouco mais detalhe; o que vamos fazer daqui a um mês,
mais detalhe ainda; e o que vamos fazer nos próximos
dias, aí vamos até o detalhe técnico. À medida que o
tempo vai passando, é como se na Figura 6.4 tirásse-
mos a mão do bolso e começássemos a andar pela rua
de São Francisco. Em algum momento, aquilo que es-
tava descrito superficialmente poderá ter mais detalhes;

52
aquilo que estava com detalhamento intermediário, po-
derá ser melhor descrito; até finalmente selecionarmos as
próximas coisas a serem feitas para então detalharmos
tecnicamente.

O detalhamento de um planejamento
deve ser inversamente proporcional
à distância no tempo.
Rodrigo de Toledo

Ao fazer um planejamento minucioso de todos os itens

no início do projeto criamos um grande problema ligado
à complexidade do excesso de detalhamento. As mudan-
ças são difíceis e dolorosas, pois uma alteração mínima
de uma tarefa técnica produzirá impacto exponencial no
detalhe de diversos outros itens. Mesmo quando esses
estão planejados para começar a construção para daqui
há um ano.

Entretanto, tente lembrar-se de quantas vezes você

executou um planejamento de ponta a ponta sem fazer
nenhuma alteração no escopo. Provavelmente a sua res-
posta foi: zero! A natureza do escopo de um projeto
é mutante, pois a cada passo que damos na construção,
aprendemos um pouco mais sobre ele.

53
6.3 Valor Contínuo
Ao permitir a flexibilidade do escopo, combatemos direta-
mente as mentiras do primeiro andar. Porém, nos livrar
desses personagens mentirosos para sermos mais since-
ros uns com os outros é apenas uma das vantagens. Há
uma motivação enorme relativa ao valor do que estamos
entregando. Seguem três impactos de valor:
1. A antecipação do valor a ser entregue.
2. É possível adaptar o escopo às mudanças externas,
tais como mercado, concorrentes, alteração do per-
fil do consumidor, etc;
3. Os aprendizados no caminho permitem descobrir
mais sobre onde está o maior valor;

A flexibilidade do que será feito, aliada aos ciclos cur-

tos (Seção 5.1) permite entregas de valor desde o início.
Se ainda combinarmos com uma boa priorização, pode-
mos ter um impacto exponencial na curva de valor, vide
Figura 6.5.

Há outro fato importantíssimo quando assumimos que

o escopo é mutável: os itens mais valiosos são os que
emergem no meio do caminho. Observamos isso toda vez
que permitimos alterações na demanda. Com as entre-
gas recebemos feedback, seja ele qualitativo ou quanti-
tativo, conhecemos melhor os nossos clientes, necessida-
des, expectativas, mercado e daí surgem itens capazes

54
Figura 6.5: Curva de entrega de valor. Quando há ciclos
curtos, escopo flexível e priorização, a curva de valor é
muito acentuada no início.

de produzir um resultado muito superior ao que havía-

mos imaginado no início do projeto. Como na analogia
do horizonte (Seção 6.2), há coisas que só conseguiremos
ver quando caminhamos um pouco mais. Ao desconsi-
derar os itens emergentes ou criar uma alta burocracia
para incorporá-los, reduzimos significativamente o valor
daquilo que poderíamos entregar. Muitas das vezes cum-
prindo um escopo falido e insignificante para nossos cli-
entes.

Podemos fazer uma analogia com o minerador de ouro,

o qual está a procura de uma veia da pedra para que então

55
explore essa veia. Isso é consequência do fato que a cada
passo dado na construção de um produto, aprendemos
mais sobre ele e podemos explorar onde há verdadeiro
valor.

Antigamente, pensávamos: Se o escopo está mudando,

é sinal que temos problemas. Hoje, temos que pensar o
oposto disso: Se o escopo está imutável, esse sim é um
sinal de que há um grande problema. Em geral, isso
é resultado de um desses problemas: ou não estarmos
conseguindo entregar algo de fato ponta-a-ponta; ou não
estamos coletando feedback com as pessoas corretas; ou
o que fazemos se tornou irrelevante. Pois o esperado é
que a demanda mude o tempo todo.

Se o escopo não está mudando, disparem

os alarmes! Tem alguma coisa errada!
Rodrigo de Toledo

Por esse motivo que o Manifesto Ágil [3] fala que as

mudanças são bem-vindas. Não estão afirmando que as
mudanças no escopo são aceitas. É muito mais que isso,
elas são bem-vindas, desejadas!

Mas se o escopo é flexível, como podemos alinhar ex-

pectativas das áreas demandantes? Existe mais de uma
maneira de lidar com isso, a mais simples é a inversão do

56
triângulo de ferro (Seção 6.1). Mas atenção, flexibilizar o
escopo não significa especificar tudo detalhado e depois
alterar, mas ao mesmo tempo, também não é para não
especificar nada. É exatamente entre esses dois pontos,
tal como na analogia do horizonte. A seguir, veremos que
podem existir diferentes níveis de flexibilização.

57
6.4 Níveis de Flexibilização
Há diversos modelos de contrato que tratam sobre a de-
finição do escopo. Estamos falando de contrato não ape-
nas entre duas empresas, mas também acordos entre área
de negócio e de execução. Vimos um desses modelos na
Seção 6.1.

Existem diferentes níveis de flexibilização do escopo.

Os níveis dependem do contexto, veja a tabela a seguir:

Flexibilização Contexto

∅ só uma entrega de tudo no final

escopo priorizável escopo/prazo/custo fixos, mas múltiplas entregas

escopo negociável prazo/custo fixos, escopo alterável

término antecipado prazo/custo dentro de um limite máximo

por sprint (empreitada) prazo/custo controlados

flexibilidade contínua negócio abraçando a incerteza

Tabela 6.1: Níveis de flexibilização do escopo.

58
Figura 6.6: Níveis de Flexibilização

59
Capítulo 7

Foco no problema e
não na solução

As soluções são sedutoras. O desafio que envolve criá-las

é tão amplo que facilmente nos apaixonamos por elas. É
glamouroso debater soluções, pensar em novos serviços
e funcionalidades. Há sensação de prazer ao praticar a
criatividade. Porém, isso não vale de nada se não sou-
bermos exatamente qual problema estamos resolvendo.
7.1 Qual o problema de focar na
solução?
O prazer que temos na discussão sobre a solução cria a
ilusão de que ao implementá-la, certamente teremos su-
cesso. Esta ilusão causa dois efeitos antagônicos que, no
entanto, produzem resultados similares. O primeiro é o
fortalecimento da fixação do escopo. Sucesso passa a ser
entregar tudo o que foi discutido e não mais resolver os
problemas de negócio que geraram a discussão inicial. O
segundo é a paralisia pela análise (em inglês: paralyses
analyses). A discussão por soluções é tão atraente e o
escopo tão volátil que continuamente retardamos a im-
plementação de fato das ideias.

Em ambos os casos, há um foco excessivo na solução

e esquece-se de avaliar se ela está resolvendo ou não o
problema. Na maioria das vezes, nem sequer se avalia
se o problema realmente existe. Vejamos dois casos reais
em que o foco na discussão trouxe grandes prejuízos para
as empresas.

Caso real: Escopo fixo há dez anos

Em uma empresa que prestamos consultoria entre 2016 e
2018, havia um projeto que já consumira quase dez anos
de trabalho e mais de 100 milhões de reais. As entregas

61
realizadas produziam um resultado baixíssimo e que não
compensavam o investimento. Quando perguntávamos
para as pessoas quais os problemas que o projeto resolvia,
elas não sabiam. O foco era unicamente em entregar o
escopo da solução que havia sido levantado há dez anos.

A solução já havia consumido tanto dinheiro e tantas

pessoas que os envolvidos estavam excessivamente ape-
gados em construi-la, mesmo que isso não fizesse mais
nenhum sentido do ponto de vista comercial.

Caso real: Paralisia pela Análise com

Design Thinking de um ano
Outra empresa na qual prestamos consultoria havia mais
de um ano eles utilizavam as técnicas de Design Thinking
para criar a solução perfeita no mercado de investimen-
tos. Quando chegamos, eles já haviam mapeado na per-
sona 1 do Universitário Investidor que fazia investimentos
agressivos.

Perguntamos qual era o tamanho da representativi-

dade da população que tinha tal perfil e descobrimos que
nunca haviam feito tal levantamento. Sabiam apenas que
era muito baixa. Todavia, para começar o desenvolvi-
1
personagens fictícios criados para representar diferentes tipos
de consumidores dentro de um alvo demográfico para um produto
ou serviço

62
mento do serviço de investimento era “fundamental” de-
terminar todos os perfis de investidores possíveis.

7.2 O dono da ideia

Outro efeito nocivo que acontece em alguns cenários é a
personalização da solução. Isso ocorre quando uma pes-
soa tem uma ideia e a iniciativa passa a levar o seu nome:
“Projeto do Fulano” ou “O projeto do diretor Beltrano”
(falamos sobre isso no 1 sobre o Rei Jassei. A partir desse
ponto, ter a solução implantada passa a ser uma questão
de sobrevivência para o “dono”. Seu nome está em jogo,
às vezes é o sobrenome da família. A pessoa fará de tudo
para não manchar sua reputação. Para ela, se entregar
tudo o que prometeu, estará livre da culpa mesmo que
a empresa não tenha um resultado favorável com o que
foi desenvolvido.

Um bom processo de criação de ideia acontece quando

várias pessoas contribuem e dão feedbacks uns aos outros.
Por exemplo, pode-se seguir o chamado double diamond
do Design Thinking. Onde uma etapa de investigação
do problema é realizada antes da discussão da solução.
Durante o processo de geração da solução, primeiro há
um brainstorming com contribuições de várias pessoas
para depois gerar um foco no que pode ser a primeira
versão de solução.

63
 Em ambientes saudáveis, compreende-se que a ideia
não foi elaborada por uma única pessoa. Na verdade, ela
é a composição de várias ideias vindas de várias pessoas e
ninguém pode assumir sozinho a autoria dela. Conforme
escrito por Bernardo de Chartres (?-1160) e aperfeiçoado
por Isaac Newton (1643 - 1727): “Se eu vi mais longe, foi
por estar sobre ombros de gigantes”.

7.3 O que são problemas?

Imagine que os problemas são alvos móveis e há diver-
sas empresas tentando acertá-lo. Se olharmos para ele
uma vez, abaixarmos a cabeça para preparar o melhor
disparo do mundo e meses depois efetuarmos o disparo
imaginando que o alvo ainda está ali, o erro será gigan-
tesco. Além disso, quando sair o nosso disparo “perfeito”,
pode ser que o problema já tenha sido alvejado diversas
vezes por outras empresas.

O problema é uma oportunidade de negócio que a

empresa decide aproveitar. Pode ser porque ela percebeu
alguma necessidade de clientes que ainda não é atendida
pelo mercado, ou algo que o mercado já atende, mas ela
pode aperfeiçoar.

Vantagens do foco no problema:

64
 • permite a flexibilidade do escopo (vide Capítulo 6,
Escopo flexível);

• há um entendimento do porquê, em especial, para

quem está construindo uma solução;

• gera maior engajamento das pessoas na cadeia pro-

dutiva;

• foco na solução leva as pessoas a terem mais apego

às ideias, tornando mais difícil descartar as que não
se provarem boas.

O foco no problema é uma forma de limpar as men-

tiras de todo o primeiro andar do castelo (vide Capítulo
1, 1o andar de mentiras: Escopo fixo): o Rei Jassei, o
Astrônomo Nadamuda e a Princesa Jaquê.

7.4 Como tratar problemas

O primeiro passo para tratar um problema é reconhecer
que não temos uma compreensão plena dele. Precisamos
de métricas que nos ajudem a verificar se:

• o problema existe;

• estamos resolvendo o problema;

65
 • compensa solucioná-lo;

• temos que adaptar a solução, pois o problema está

se movendo.

7.5 Como saber se a solução

resolve o problema?
Learning Driven Design
(LDD)
A solução do problema é um aprendizado constante sobre
ele. A princípio parece um paradoxo.

Só entendemos realmente o problema

se tentarmos solucioná-lo e só
conseguimos solucioná-lo se
entendermos realmente o problema.
Avelino F. Gomes Filho

Na verdade, é um ciclo de aprendizado. O Learning

Driven Design (LDD) é uma forma simples de enten-
der esse processo. Partimos de um problema do ponto
de vista do consumidor final. A partir daí temos ideias
para resolver o problema. Antes de criarmos a solução, é

66
necessário criar métricas para validarmos se o problema
está sendo solucionado ou não. Após isso, a ideia torna-se
produto e com ele obtemos feedback através de métricas.
Agora é possível concluir se a solução foi capaz de resol-
ver o problema ou não. O importante é que esse processo
sempre gere aprendizado.

Figura 7.1: LDD: Learning Driven Design

Caso real: foco no problema

Um órgão público do Rio de Janeiro estava lançando um
novo serviço para os cidadãos fluminenses. O público
é bastante heterogêneo em todos os aspectos possíveis:
idade, classe social e educação, pois se tratava de toda a
população adulta de mais de 10 milhões de pessoas. O ór-
gão percebeu que os cidadãos tinham muitas dificuldades
para informar o endereço e sem ele, era impossível reali-

67
zar a execução do serviço. A reclamação mais comum era:
“O sistema não encontra o meu endereço”. Se focasse na
solução apenas, provavelmente esse órgão tentaria criar
formas melhores de informar endereços. Todavia eles já
praticavam o LDD e sabiam que essa era a consequência
do problema e não a causa. Após pesquisas na base de
dados para melhor compreender a causa raiz, descobriu-
se que as pessoas informavam o município como Rio de
Janeiro, porém ao colocar o logradouro, informavam ruas
e avenidas de outros municípios. Utilizando o LDD tive-
mos:

Hipótese de Problema: Pessoas informam o mu-

nicípio Rio de Janeiro, porém escrevem logradouros de
outros municípios.

O rótulo MUNICÍPIO provavelmente não é compre-

endido para a população.

Métrica: Quantidade de vezes que o sistema não

encontra o logradouro na Cidade informada pelo cidadão.

Hipótese de solução: Podemos experimentar alte-

rar o rótulo para CIDADE.

Após a alteração do rótulo (Solução) verificou-se uma

queda de 75% na quantidade de vezes que o sistema não
encontrava o endereço (Feedback). Isso gerou um apren-

68
dizado. A partir desse ponto, todo serviço que é oferecido
pelo órgão utiliza o rótulo cidade ao invés de município.

Veja que ao focar no problema, foi possível chegar em

uma solução simples, rápida e eficaz. Além de criar um
aprendizado que serve para toda a organização.

User-centered Design
Os problemas que o LDD trata tem seu foco no consu-
midor final, a pessoa que sofre o problema. Coisas como
aumentar a receita, aumentar a satisfação são metas do
negócio, consequência de resolvermos bem o problema
do cliente. Uma dica importante é: conheça seu cliente e
entenda as dores que ele tem. Se não fizer isso, provavel-
mente serão criadas excelentes soluções que não atendem
às necessidades do cliente (Veja o Seção 10.2, Está na
hora de acompanhar a eficácia).

Tanque de Decantação
Uma forma de estruturar o LDD é utilizando o Tanque de
Decantação [1]. Ele é um canvas conforme demonstrado
na Figura 7.2

• Propósitos do time: Qual o motivo de estarmos

aqui? Para que esse time existe? O que a empresa
perderia se não estivéssemos aqui?

69
 Figura 7.2: Quadro do Tanque de Decantação

• Problemas: De acordo com o nosso propósito,

quais são os problemas que as pessoas têm e que
devemos / podemos resolver?

• Métricas: Para saber se resolvemos estamos resol-

vendo os problemas, o que deveremos medir?

• Ideias: Quais são as possíveis soluções que irão

impactar uma métrica e ajudar a resolver um pro-
blema?

• Foco: De todas as ideias que tivemos, selecionamos

aquela com o melhor custo/benefício para impactar
a métrica que indica se estamos resolvendo o pro-
blema.

70
 Perceba que há relações de causa e efeito entre todos
os itens do Tanque é essencial. Temos um propósito que
nos leva a problemas que devemos resolver que por sua
vez devem ser avaliados com métricas e as possíveis solu-
ções devem impactar a métrica que por sua vez informam
se estão resolvendo o problema e portanto nos ajudando
a cumprir o nosso propósito. O Tanque de decantação se
tornou uma ferramenta muito útil para a etapa de pro-
duct discovery. Ela se distingue de outras técnicas (como
Design Thinking ou Lean Inception) por trazer a discus-
são das métricas antes mesmo da discussão das ideias.

7.6 Ame o problema, não a

solução!
A conclusão deste capítulo está intimamente ligada a essa
frase. Na K21 há um adesivo com esses dizeres.

Dizemos que esse é o único dos adesivos que não é

auto-explicativo. Sem o raciocínio apresentado neste ca-
pítulo, alguém pode interpretar errado, achando que não
nos interessa a solução. Mas na verdade, o que queremos
é um desapego à uma proposta de solução. Uma vez que
amamos o problema, com total empatia com as pessoas
que sentem aquela dor, a busca pela solução é apenas
uma consequência natural. O apego ao desenho de uma
solução, pode levar a uma paixão irracional, onde só in-

71
Figura 7.3: Adesivo da K21: Ame o problema, não a
solução!

teressa a sua finalização sem checar se estamos realmente

resolvendo o problema original.

72
 Parte III

Derrubando o Castelo
Derrubando o castelo

Na parte anterior, Limpando o castelo, apresentamos so-

luções mais diretas de serem adotadas pelos times e or-
ganizações. As mudanças que colocamos ali podem ser
praticadas imediatamente nos times sem a necessidade
de participação da alta gestão.

Agora, nesta parte do livro, vamos começar a derru-

bar o castelo de mentiras. As soluções daqui envolvem
vários níveis da hierarquia institucional e provavelmente
exigem participação das lideranças da organização. São
mudanças que iniciam a real transformação cultural tão
desejada pelas empresas. Segue uma explicação breve
sobre os três capítulos:

• Capítulo 8, Lean startup e eliminação de

ideias: como foi exposto na Introdução do livro,
há uma infinidade de projetos e iniciativas que não
 deveriam nem existir, pois estão fadados a nunca
serem úteis. Nesse capítulo trazemos técnicas de
como se livrar de tais iniciativas.

• Capítulo 9, Triplo L: Limitando o Trabalho

Paralelo: os três conceitos desse capítulo (Lead
Time, Lei de Little e Limitação de WIP) estão li-
gados ao fluxo de trabalho e à teoria das filas. Criar
um fluxo estável também faz parte da derrubada do
castelo.

• Capítulo 10, Acompanhamento por Resul-

tado: esse capítulo, em especial, traz uma forma
inovadora de acompanhamento dos projetos ou ini-
ciativas. Ele faz parte da derrubada do quarto an-
dar. É aqui que apresentamos uma forma de fazer
acompanhamento baseado em resultados de eficá-
cia.

75
 Parte IV

Evoluindo para Valor

Contínuo
Evoluindo para Valor
Contínuo

Segue uma explicação breve sobre alguns dos capítulos

da última parte do nosso livro:

• Capítulo 11, Produtos mais que projetos: em

especial, consideramos este capítulo um divisor de
águas nas empresas e passo importante para os ca-
pítulos seguintes. A partir da década de 2020, cada
vez menos falaremos de projetos e cada vez mais fa-
laremos de produtos (e serviços).

• Capítulo 12, Alocação de pessoas: Para au-

mentar a colaboração, nesse capítulo trazemos for-
mas alternativas de alocação de pessoas, bem di-
ferentes do modelo projetizado tradicional, o qual
 induz a uma constante realocação, sem jamais for-
mar times de alta performance.

• Capítulo 13, Redistribuição orçamentária: tal-

vez um dos capítulos mais ousados, nele propomos
uma forma diferente de se fazer orçamento nas em-
presas. Esse é o golpe final no castelo.

124
Bibliografia

[1] D. Alencar. Tanque de decantação: um

canvas como solução., 2018. Disponível
em: https://knowledge21.com.br/blog/
canvas-tanque-de-decantacao.

[2] D. Anderson. Kanban: Successful Evolutionary

Change for Your Technology Business. Blue Hole
Press, 2010.

[3] K. Beck, M. Beedle, A. van Bennekum, A. Cock-

burn, W. Cunningham, M. Fowler, J. Gren-
ning, J. Highsmith, A. Hunt, and R. Jeffries.
Agile manifesto, 2001. Disponível em: http://
agilemanifesto.org. Acesso em: 13 fev. 2019.

[4] N. Bennett and J. Lemoine. What vuca really means

for you, 2014. Disponível em: https://hbr.org/
2014/01/what-vuca-really-means-for-you.
[5] G. Burnison. No Fear of Failure: Real Stories of
How Leaders Deal with Risk and Change. Wiley,
New Jersey, 2011.
[6] R. de Toledo. Kanban visibilidade, fluxo conti´nuo
e wip.
[7] R. de Toledo. Humanos sim, recursos não!, 2018.
Disponível em: https://www.knowledge21.com.
br/blog/humanos-sim-recursos-nao.
[8] J. Humble and D. Farley. Continuous Delivery: Re-
liable Software Releases Through Build, Test, and
Deployment Automation. Addison-Wesley Professi-
onal, 1st edition, 2010.
[9] W. Humphrey. A Discipline for Software Enginee-
ring. Addison-Wesley, 1995.
[10] K. Leopold. Rethinking Agile: Why Agile Teams
Have Nothing to Do with Business Agility. Leanabi-
lity Press, 2018.
[11] J. Liker. The Toyota Way : 14 Management Prin-
ciples from the World’s Greatest Manufacturer: 14
Management Principles from the World’s Greatest
Manufacturer. Business/ Management. Mcgraw-hill,
2003.
[12] J. Little and S. Graves. Little’s Law, pages 81–100.
07 2008.

140
[13] J. D. C. Little. A proof for the queuing formula: L
= $λ$w. Oper.Res., 9(3) : 383 − −387, June1961.

[14] D. McClure. Product marketing for pirates:

Aarrr! (aka startup metrics for internet marke-
ting & product management), 2007. Disponível
em: https://500hats.typepad.com/500blogs/
2007/06/internet-market.html.

[15] D. Meadows and D. Wright. Thinking in Systems:

A Primer. Chelsea Green Pub., 2008.

[16] D. Minter and M. Reid. Lightning in a Bottle: The

Proven System to Create New Ideas and Products
That Work. Sourcebooks, 2007.

[17] T. Ohno. Toyota Production System: Beyond Large-

Scale Production. Taylor & Francis, New York, 1988.

[18] J. J. Phillips. Return on investment in training

and performance improvement programs. Routledge,
Londres, 2012.

[19] M. Poppendieck and T. Poppendieck. Lean Software

Development: An Agile Toolkit. Addison-Wesley,
Boston, MA, 2003.

[20] L. L. Putnam and R. L. Sorenson. Equivocal mes-

sages in organizations. Human Communication Re-
search, 8(2):114–132, 1981.

141
[21] M. Ridley. When ideas have sex, 2010. Disponível
em: https://www.ted.com/talks/matt_ridley_
when_ideas_have_sex.

[22] E. Ries. A startup enxuta. Leya, São Paulo, 2012.

[23] R. Sabbagh. Scrum: Gestão ágil para projetos de

sucesso. Casa do Código, 2014.

[24] K. Schwaber and J. Sutherland. The scrum guide,

Nov. 2017.

[25] STANDISH GROUP. Exceeding value. In CHAOS

Report 2014. Standish Group, Boston, 2014.

[26] J. Sutherland. SCRUM: A arte de fazer o dobro de

trabalho na metade do tempo. LEYA BRASIL, 2014.

[27] S. Thomke and D. Reinertsen. Six myths of product

development. Harvard business review, 90:84–94, 05
2012.

142