Castelo de Mentiras

A primeira grande mentira é acreditar que o escopo deve ser totalmente definido no início e nunca mudar. Mercado evolui, concorrentes avançam, entendimento refina, métricas apontam novas direções — escopo muda porque é natural que mude. Muitas empresas tratam mudança de escopo como problema; na verdade, o problema é a ausência dela.

Três personagens habitam esse andar: o Rei Jassei (que já sabe a solução antes de entender o problema), o Astrônomo Nadamuda (que prevê o futuro com precisão irreal) e a Princesa Jaquê (que aproveita a janela anual de aprovação para pedir tudo de uma vez). O resultado: projetos inchados com funcionalidades questionáveis.

Depois de listar o escopo (cheio das mentiras do primeiro andar), o próximo passo é estimar prazo e custo — tarefa dolorosa que consome horas do time técnico em documentações detalhadas baseadas em requisitos já imprecisos. Três personagens habitam esse andar: o Mago Analista (que faz análise profunda sem consultar quem vai executar), o Arquiteto Medetudo (que tenta medir criação com pontos de função e pessoa-hora) e o Prometeus (que adiciona uma margem de cagaço para sobreviver).

O custo é brutal: improdutividade massiva, artefatos inúteis (WBS, UML, mapas de entidades que se demonstram errados ou incompletos), e um time desmoralizado que já sabe antecipadamente que as estimativas estarão erradas.

O terceiro andar é a estimativa de valor que decide o portfólio do próximo período fiscal: ROI = Retorno Estimado / Custo Estimado. Esse andar tem um único morador, o Masvalia, mas sua mentira é devastadora: na disputa política entre projetos, ele não hesita em inflar absurdamente o retorno do seu para garantir aprovação.

Como há pouca accountability posterior (quando o projeto não entrega, ninguém se lembra de quem prometeu), a mentira prolifera. Portfólios se enchem de projetos que prometem retornos fabulosos e nunca entregam. Uma alternativa muito melhor seria o CoD (Cost of Delay), que mede o custo de adiar uma entrega em vez de apenas estimar ROI.

No quarto andar o projeto está em execução, mas o acompanhamento tradicional perpetua as mentiras dos andares anteriores em vez de expô-las. Gráficos de Gantt, curvas S e índices de desempenho monitoram aderência ao plano original, não progresso real de entrega de valor.

Enquanto o projeto segue o plano (mesmo que aquele plano já esteja obsoleto), os gráficos mostram tudo verde. Quando a realidade bate à porta, é tarde demais. O verdadeiro acompanhamento deveria monitorar entrega frequente de valor, feedback de cliente real e ajustes baseados em aprendizado contínuo.

A primeira solução é introduzir transparência radical e agilidade. Transparência significa parar de esconder incertezas atrás de estimativas falsamente precisas e admitir honestamente que trabalho criativo é imprevisível. Quando alguém pergunta "quando estará pronto?", a resposta honesta é uma faixa de probabilidade, não uma data.

Agilidade significa entregar em ciclos muito curtos (semanas, não meses), permitindo ajustes frequentes baseados em aprendizado real. Times que praticam transparência radical e ciclos curtos têm muito melhor comunicação com stakeholders e muito menos surpresas desagradáveis no final.

Em vez de tentar manter escopo fixo (o que é fundamentalmente impossível), aceite que escopo é flexível e mudanças são esperadas. Você começa com um problema claramente definido (não uma solução), prioriza as soluções potenciais mais valiosas, executa em ciclos curtos, coleta feedback e ajusta o que fazer a seguir.

Escopo flexível reduz drasticamente os itens inúteis porque você descobre rapidamente o que o cliente realmente quer em vez de assumir. Estruturar mudança explicitamente é liberador — remove a pressão de adivinhar tudo certo no início e permite que a organização seja responsiva.

A confusão fundamental nas empresas é focar em soluções em vez de problemas. Você acaba preso em um projeto para implementar a "solução" predefinida sem entender se ela é a melhor — ou se o problema ainda existe. Foco no problema começa perguntando: qual é o verdadeiro problema? Para quem? Qual o impacto de resolvê-lo? Onde ele dói mais?

Uma vez que o problema está cristalino, explore múltiplas soluções, prototipe, teste com usuários reais, colete dados e decida. Essa mudança elimina toda uma classe de projetos inúteis que resultam de resolver a "solução errada".

Lean Startup é uma metodologia para eliminar ideias ruins rapidamente, com mínimo desperdício, através de ciclos de construir-medir-aprender. Em vez de meses estimando e planejando para descobrir que ninguém quer, você constrói o MVP em semanas, coloca diante de usuários, mede, aprende e decide: pivotar, iterar ou matar.

Isso elimina as mentiras dos três primeiros andares: escopo evolui naturalmente, estimativas tornam-se triviais (próximas 2 semanas planejadas, resto incerto) e valor é continuamente validado em vez de estimado. Lean Startup força a organização a pensar em pequenos incrementos e a ser brutalmente honesta sobre o que está funcionando.

Uma dinâmica destrutiva é tentar fazer múltiplos projetos grandes simultaneamente acreditando que isso maximiza utilização de recursos. Na realidade, com 10 projetos em paralelo cada um avança lentamente, context-switching mata produtividade, dependências criam gargalos e nada termina. A Lei de Little: lead time = WIP / throughput.

Triplo L significa três tipos de limitação: limitar trabalho paralelo no nível operacional (por pessoa), no nível de equipe (por time) e no nível organizacional (projetos grandes em andamento). Isso força priorização brutal — coisas começam a terminar, stakeholders veem resultados mais rápido, moral de times melhora.

Em vez de medir aderência ao plano original (que era mentiroso em primeiro lugar), o verdadeiro acompanhamento mede resultado real entregue, feedback do cliente e progresso em direção ao problema que estamos tentando resolver. Métricas como "% de conclusão em linha com o Gantt" permitem que projetos pareçam verdes enquanto estão completamente desalinhados da realidade.

Métricas melhores: funcionalidades entregues, casos de uso validados com usuários reais, valor de negócio gerado, satisfação de cliente, velocidade. Acompanhamento por resultado expõe rapidamente quando um projeto está fora dos trilhos, permitindo que se pivote ou seja morto antes de gastar mais recursos.

Alocação em organizações tradicionais é jogo político: departamentos retêm sua "alocação" mesmo sem produtividade. Pessoas alocadas a um projeto também estão em cinco outros, resultando em atenção dividida e baixa produtividade. A solução é alocação dedicada: pessoas trabalham em um produto/squad por um período focado.

Dedicação produz entendimento profundo do problema, coesão de time e velocidade muito maior. Pessoas ficam mais engajadas porque veem impacto real, aprendem profundamente o domínio e constroem relacionamentos verdadeiros. Liderança consegue entender capacidade real de entrega porque ninguém está fingindo estar em seis lugares ao mesmo tempo.

Pare de pensar em "projetos" (que têm início e fim) e comece a pensar em "produtos" (que evoluem continuamente entregando valor). Projetos têm mentalidade de "fazer uma coisa e terminar", criando incentivos perversos para empilhar tudo no início porque "depois é tarde". Produtos têm mentalidade de evolução contínua.

Quando você pensa em produtos, a maioria dos problemas dos primeiros andares desaparece: não precisa estimar 8 meses porque pensa em ciclos de 2 semanas; não pressiona por escopo completo porque há sempre próximos ciclos; não implementa funcionalidades inúteis porque elas são continuamente validadas.

Orçamento tradicional é exercício anual de adivinhar quanto cada projeto precisará — frequentemente sobra (desperdício) ou falta (recursos travados). Orçamento Ágil reconhece que alocação deve ser contínua e responsiva à realidade de mercado. Estabeleça limite total, divida entre iniciativas e tenha liberdade para realocar mês-a-mês baseado em aprendizado.

Isso permite aumentar recursos para o que funciona e reduzir (ou matar) o que não entrega. Resolve o problema do Masvalia: a aprovação não é decisão única anual, é contínua. Accountability é muito mais clara porque você avalia performance de cada iniciativa contra o investimento real feito nela.