Produto não é uma esteira de datas

Neste artigo · 7 seções

1. projeto é output, produto é outcome
2. a estratégia mais arriscada é parar de arriscar
3. a fábrica de features mata a própria velocidade
4. velocidade e estabilidade não são trade-off
5. produto que não entende o domínio decide no escuro
6. a pergunta certa
7. Insights & Takeaways

Toda reunião de status começa igual. "Qual a data de entrega?" O time responde, alguém anota, e a conversa segue como se o trabalho estivesse encaminhado. Parece a pergunta mais responsável do mundo. Quase sempre é a errada.

Errada porque mede a coisa errada. Data é quando o código sai. Não diz nada sobre o que ele muda quando sai. E "saiu na data" convive perfeitamente com "não moveu nada".

A tese aqui é direta: produto é outcome, não output. A fábrica de features, aquela máquina afinada pra cuspir item de roadmap dentro do prazo, é ótima numa coisa só: entregar pontualmente o que não importa. Ela acumula passivo, apodrece a arquitetura e mata justamente a velocidade que dizia proteger.

projeto é output, produto é outcome

Marty Cagan tem a frase que devia estar colada no monitor de todo PO. "Projetos são output e produto é totalmente sobre outcome. Esse processo leva, de forma previsível, a projetos órfãos. Sim, alguma coisa finalmente foi lançada, mas não cumpre seus objetivos, então qual era mesmo o ponto?" (no original, "projects are output and product is all about outcome. This process predictably leads to orphaned projects. Yes, something was finally released, but it doesn't meet its objectives so what really was the point?").

Projeto órfão. O nome é perfeito. Nasceu, foi entregue na data, bateram palma no release, e nunca cumpriu o que prometia. Ninguém volta pra medir, porque medir resultado não estava no escopo. O escopo era entregar.

E tem um motivo estrutural pra isso falhar tão rápido. Cagan é honesto sobre as probabilidades: "pelo menos metade das nossas ideias simplesmente não vão funcionar" (no original, "at least half of our ideas are just not going to work"). Pensa no que isso faz com a pergunta da data. Se metade das apostas não vinga, cravar escopo e data lá no começo é se comprometer publicamente com uma ficção, e ainda com a pior informação que você vai ter sobre aquilo. O erro nunca é a incerteza existir; é fingir que ela não está lá.

A diferença entre time bom e ruim mora aqui. "Times bons comemoram quando alcançam um impacto significativo nos resultados de negócio. Times ruins comemoram quando finalmente lançam alguma coisa" (no original, "Good teams celebrate when they achieve a significant impact to the business results. Bad teams celebrate when they finally release something.", Cagan). Olhe o que o seu time comemora no Slack. Já te diz qual dos dois ele é.

a estratégia mais arriscada é parar de arriscar

Quando a régua é só a data, o time aprende rápido o que fazer: parar de arriscar. Entregar o que está no papel, do jeito mais previsível, sem perguntar se aquilo resolve algo. É racional, dado o incentivo. E é a morte lenta do produto.

Cagan não suaviza: "a estratégia mais arriscada de todas é parar de correr riscos" (no original, "the riskiest strategy of all is to stop taking risks."). Parece que entregar roadmap fechado é o caminho seguro. Não é. É o caminho que garante mediocridade no prazo. E custa o time: "se você regrediu a só entregar aos seus times roadmaps de features, então não pode mais esperar os benefícios de times de produto empoderados" (no original, "if you've reverted to just handing your teams roadmaps of features, then you no longer can expect the benefits of empowered product teams.").

Esse é o fio que puxei no artigo anterior desta série, sobre o gestor que só sabe pedir. Time que recebe lista de feature e data vira executor de pedido. Para de trazer o caminho mais barato, para de apontar a feature que vai falhar antes de construir, para de se importar com o resultado, porque o resultado não é a régua dele. Você troca missionário por mercenário e depois reclama que o time não tem dono. O dono você tirou, no dia em que trocou objetivo de negócio por esteira de entrega.

a fábrica de features mata a própria velocidade

Aqui está a ironia que devia tirar o sono de quem decide. A fábrica de features se vende como o jeito de ir rápido. É, na verdade, o jeito mais confiável de ficar lento.

Cagan lista as maiores causas de perda de velocidade de um time, e a número um não é falta de gente nem de esforço. É dívida técnica: "Com frequência, a arquitetura não facilita nem habilita a evolução rápida do produto... ela precisa ser atacada num esforço contínuo e concentrado" (no original, "Often, the architecture does not facilitate or enable the rapid evolution of the product... it needs to be attacked in an ongoing and concerted effort.", Cagan). Dívida técnica não é o código feio que ofende o sênior. É a arquitetura que não deixa o produto mudar rápido. O custo de cada alteração subindo, mês a mês, até a mudança simples levar uma sprint.

E quem produz essa dívida em escala industrial? A fábrica de features. Cada item entregue no grito, sem espaço pra cuidar da estrutura, deixa mais um pouco de cola e gambiarra no caminho. No mês seguinte, o próximo item demora mais. No outro, mais ainda. O time que prometeu velocidade entregando feature atrás de feature está, a cada entrega, comprando a própria lentidão futura. Já defendi isso em Code design não é sobre código bonito, é sobre AGILIZAR e MITIGAR RISCOS de mudança: design existe pra fazer mudança ser barata e segura, não pra ganhar concurso de elegância.

Preciso separar o que é meu do que é dos autores. Cagan escreveu isso em 2017, sem falar de IA generativa. A ponte é minha: a IA é o turbo da fábrica de features. Ela deixa despejar output mais rápido do que nunca, o que, sem outcome como régua, significa produzir projeto órfão e dívida técnica numa velocidade que a gente nunca viu. Não é especulação. O relatório DORA de 2024, já na era dos assistentes de código, mediu a adoção de IA acompanhada de queda de 1,5% no throughput de entrega e de 7,2% na estabilidade, e foi seco: "a IA não parece ser uma panaceia" (no original, "AI does not appear to be a panacea.", DORA 2024). A ferramenta acelera o digitar. Se o que você acelera é a esteira errada, ela só te leva mais rápido pro buraco.

velocidade e estabilidade não são trade-off

Tem uma desculpa que sustenta a fábrica inteira: "preciso entregar rápido, qualidade fica pra depois". A maior base de dados que existe sobre entrega de software diz que isso é falso.

O Accelerate, de Forsgren, Humble e Kim, mediu mais de 23 mil respostas e foi categórico: "De forma surpreendente, esses resultados demonstram que não há trade-off entre melhorar performance e atingir níveis mais altos de estabilidade e qualidade. Pelo contrário, os high performers são melhores em todas essas medidas" (no original, "Astonishingly, these results demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures."). Os bons não escolhem velocidade e pagam com instabilidade. São bons nas duas ao mesmo tempo, porque a qualidade é o que os mantém rápidos.

Os números são de outra ordem de grandeza. Comparados aos low performers, os high performers faziam 46 vezes mais deploys, com lead time do commit ao deploy 440 vezes menor, restauravam serviço 170 vezes mais rápido e falhavam cinco vezes menos nas mudanças. Já destrinchei essas quatro réguas em DORA Metrics. Repare que nenhuma dessas quatro réguas é "entregou na data prometida". São tempo de fluxo e qualidade do fluxo. A velocidade que importa não é a da promessa; é a da mudança, e essa quem define é a arquitetura, como argumentei em A Primeira Derivativa.

produto que não entende o domínio decide no escuro

Sobra a pergunta de onde vem o outcome certo. Não vem de adivinhar no PowerPoint. Vem de entender o domínio fundo o suficiente pra saber qual feature move o ponteiro e qual é teatro.

Cagan toca num ponto que parece técnico e é de produto: "os sistemas sempre parecem crescer em complexidade e tamanho muito mais rápido do que qualquer um consegue documentar, e, com software, a resposta definitiva sempre vive no próprio código-fonte" (no original, "the systems always seem to grow in complexity and size much faster than anyone can document, and with software, the definitive answer always lives in the source code itself.", Cagan). A verdade do que o produto faz não está no slide. Está no domínio, que o código encarna. Produto que não entende o domínio decide no escuro, prioriza pela intuição do mais graúdo na sala e chama isso de estratégia.

Em bolsa, banco e exchange isso fica gritante. Dá pra entregar na data uma tela nova enquanto a latência do book de ofertas, que é o que de fato move receita, continua igual. Output cheio, outcome zero. A diferença entre as duas coisas é entender o negócio, não o framework. Vou dedicar um artigo inteiro a isso mais pra frente na série, porque a complexidade que quebra o seu produto é quase sempre do domínio, e ela ficou ainda mais decisiva agora que a IA gera a coisa certa ou lixo plausível dependendo de quanto você entende.

a pergunta certa

Trocar a pergunta muda o jogo. Sai "quando isso fica pronto" e entra "que resultado isso muda, e como vamos saber". A data continua existindo; negócio precisa de previsibilidade. Mas ela vira consequência de uma aposta que você entende, não a régua única que disfarça a ausência de aposta.

Data sem outcome é o desperdício mais caro que existe, porque vem embrulhado de produtividade. O board fica verde, o roadmap anda, todo mundo parece ocupado e entregando. E o ponteiro do negócio não se move. É a fábrica a todo vapor, produzindo projeto órfão no prazo e dívida que vai cobrar a velocidade de amanhã. Pontual. E inútil.

O time bom não é o que entrega tudo o que prometeu na data. É o que tem coragem de não construir metade do que estava no papel, porque descobriu a tempo que não ia mover nada. Essa coragem não cabe numa esteira de datas. Cabe numa pergunta melhor.

Insights & Takeaways

• Data mede quando o código sai, não o que ele muda. "Entregou no prazo" convive numa boa com "não moveu nada". Produto é outcome, não output.
• Cravar escopo e data no início é se comprometer com uma ficção: na média, metade das ideias não funciona. Compromisso de data honesto vem depois da descoberta, não antes.
• A fábrica de features mata a própria velocidade. Dívida técnica é a causa número um de perda de velocidade, e é exatamente o que a esteira de entrega produz em escala.
• Velocidade e estabilidade não são trade-off. Os high performers ganham nas duas, e a régua é o fluxo: frequência de deploy, lead time, tempo de recuperação e taxa de falha. Data prometida não entra na conta.
• A IA acelera o digitar, não o julgamento. Sobre a esteira errada, ela só entrega projeto órfão e dívida mais rápido. Troque a pergunta de "quando entrega" para "que resultado isso muda".