Não estimamos escopo: cortamos escopo para caber na data

Todo founder já ouviu a pergunta “quanto tempo vai levar?” ser respondida com um número. E quase todo founder já viu esse número dobrar. Não é desonestidade. É que o número foi calculado do jeito errado.

Em 24 de janeiro de 2026, o engenheiro de software Sean Goedecke publicou um texto que resume o que eu pratico há anos. A primeira frase da tese é seca: “Não é possível estimar com precisão o trabalho de software.” Em How I estimate work, ele explica por que e o que faz no lugar.

Por que estimar escopo não funciona

O argumento de Goedecke é simples. A maior parte do trabalho de software é desconhecida até alguém começar a fazer. Você não sabe quanto tempo leva uma integração com um sistema que nunca abriu, nem quanto custa um fluxo que ninguém testou com usuário real. O trabalho conhecido é fácil de estimar. O desconhecido domina o total.

Ele também observa que, dentro das empresas, a estimativa raramente nasce do engenheiro. Quem pede já tem uma data em mente. A estimativa vira negociação.

O que fazer no lugar: partir da data

Em vez de perguntar “quanto tempo leva este projeto?”, Goedecke pergunta “quais abordagens cabem neste prazo?”. Nas palavras dele, o trabalho é descobrir “o conjunto de abordagens de software que combina com aquela estimativa”.

O processo dele tem quatro passos:

1. Entender o contexto antes do código. Quanta pressão existe, o quanto o projeto é essencial, que prazo se espera.
2. Ir para o código já com a data. E perguntar o que é possível dentro dela.
3. Olhar as incógnitas. Quantas áreas desconhecidas cada abordagem obriga a tocar, e qual o risco de cada uma.
4. Apresentar opções, não um número. Cada caminho com seu risco e sua troca. Quem decide escolhe.

Se nenhuma abordagem cabe, diz ele, talvez seja o requisito que precisa mudar.

Como isso vira método no Studio

Para um founder, o raciocínio de Goedecke tem uma tradução direta. Você tem uma data que importa: uma rodada, uma feira, uma temporada, o fim do caixa. O produto precisa estar no ar nessa data. Então a pergunta certa não é “quanto tempo leva meu produto inteiro?”. É “qual é o melhor produto que cabe até lá?”.

Nós não estimamos escopo. Cortamos escopo para caber na data. Na prática:

• A data vem primeiro. Ela vai escrita no contrato.
• O diagnóstico mapeia as incógnitas. Integrações, dados legados, regras de negócio que ninguém documentou. É onde mora o risco.
• O escopo é desenhado para a data. Cada funcionalidade entra ou sai com uma razão. O que sai vai para uma lista da próxima versão, por escrito.
• O preço é fechado depois do diagnóstico. Só dá para fechar preço quando escopo e data estão amarrados.

Caso 1: AI Vou Eu, no ar em 4 semanas

A AI Vou Eu chegou até nós depois de gastar R$200 mil em 3 estúdios, sem produto no ar. Não faltou dinheiro nem vontade. Faltou alguém que dissesse o que não ia entrar.

Com a data fixada, o trabalho foi escolher o fluxo central que precisava funcionar no lançamento e tirar o resto do caminho. [Detalhes do que entrou e do que ficou para depois, para o Leonel completar.] O produto foi ao ar em 4 semanas.

Caso 2: LCX, um sistema só em 29 dias

A LCX é uma empresa de turismo com operação em mais de 10 países da América do Sul. Ela tinha um sistema por país. O pedido era juntar tudo num sistema só.

Um projeto assim, estimado do jeito tradicional, viraria um cronograma de meses, com cada país pedindo suas exceções. Partindo da data, a pergunta mudou para “o que precisa ser comum a todos os países no primeiro dia?”. [Abordagem técnica e cortes de escopo, para o Leonel completar.] O sistema único foi ao ar em 29 dias.

O que esse método exige de você

Cortar escopo para caber na data não é mágica. Exige três coisas do founder:

1. Uma data real. Não “o quanto antes”. Uma data com motivo.
2. Disposição para dizer não. Para funcionalidades boas, que não são essenciais agora.
3. Confiança na próxima versão. O que sai do lançamento não morre. Volta com dados de uso real para decidir se vale a pena.

Em troca, você ganha uma coisa que nenhuma estimativa dá: um produto no ar na data em que ele importa.

O que isso muda para você

Na próxima vez que alguém responder “quanto tempo leva?” com um número, pergunte de volta: “o que você corta se precisar entregar na metade do tempo?”. Se a resposta for “nada”, aquele número é um chute. Se vier uma lista clara de opções e riscos, você está falando com alguém que entende de onde vem o atraso.

E se você tem uma data e um produto que precisa estar no ar nela, o nosso serviço de sistemas e SaaS começa exatamente por essa conversa.