Cone of Uncertainty: Por que as Estimativas Iniciais Erram

Por Tara Minh · Atualizado em 10 de outubro de 2026

O cone of uncertainty é um modelo que mostra que as estimativas de projeto são menos confiáveis no início e só se tornam mais confiáveis à medida que as incógnitas são resolvidas. A versão de Steve McConnell coloca as estimativas iniciais de software entre 0,25x e 4x o resultado final, estreitando-se rumo a 1,0x conforme as decisões são tomadas.

Fatos principais

• 4x para qualquer lado: Estimativas feitas na fase de Initial Concept podem errar por um fator de 4x para cima ou 4x para baixo (0,25x), uma dispersão de 16x entre o valor mais baixo e o mais alto, segundo o white paper sobre o Cone of Uncertainty da Construx.
• Melhor cenário, não uma promessa: O cone mostra a melhor precisão que estimadores experientes conseguem alcançar. Fazer pior é fácil, e ser mais preciso só é possível com mais sorte (mesmo white paper da Construx).
• Origem subjetiva: Barry Boehm desenhou a primeira versão em seu livro de 1981, Software Engineering Economics, e suas faixas foram definidas por julgamento, como limites de confiança de 80%, e não medidas a partir de dados de projetos (Bossavit, The Leprechauns of Software Engineering).
• Estreitar dá trabalho: A maior parte do estreitamento acontece nos primeiros 20 a 30% do tempo de calendário, e somente porque a equipe toma decisões que eliminam a variabilidade (Construx).

O que é o cone of uncertainty?

Imagine um funil deitado de lado. À esquerda, no início do projeto, ele é largo. À direita, perto da entrega, termina em ponta. O eixo vertical mostra o quanto uma estimativa de esforço, custo, prazo ou escopo pode se afastar do que você acaba entregando. O eixo horizontal é o tempo, marcado por marcos: conceito inicial, definição do produto aprovada, requisitos completos, design completo e finalizado.

A ideia é simples. No começo de um projeto, você não sabe exatamente o que está construindo, quem vai construir, quais riscos vão se concretizar nem quais requisitos vão mudar. Cada uma dessas incógnitas adiciona variação à estimativa. À medida que cada uma é definida, a faixa plausível de resultados diminui.

Essa é a parte que todo mundo cita. A parte que ignoram é o que McConnell diz logo ao lado: a incerteza não diminui porque o tempo passa. Ela diminui porque alguém tomou uma decisão. O white paper da Construx afirma com clareza que a única forma de reduzir a variabilidade da estimativa é reduzir a variabilidade do próprio projeto. Pedir à equipe "mais uma semana para refinar a estimativa" não funciona se nada no projeto foi definido durante essa semana.

De onde veio o cone

Barry Boehm esboçou a versão mais antiga em Software Engineering Economics (1981), chamando-a de curva em funil. Na fase mais inicial, as estimativas podiam errar por um fator de 4 para qualquer lado: o white paper da Construx de McConnell coloca a faixa do Initial Concept em 4x para cima e 0,25x para baixo, uma dispersão de 16x.

Steve McConnell depois deu a ele o nome "cone of uncertainty" e o incorporou aos seus livros sobre estimativa, incluindo Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). A Construx, empresa que ele fundou, ainda publica o modelo como white paper.

Aqui vai a ressalva honesta. A análise de Laurent Bossavit sobre a história do cone concluiu que as faixas de Boehm vieram de julgamento, e não de um conjunto de dados medido. Bossavit também aponta os dados de 2006 de Todd Little, extraídos de relatórios de status de projetos reais e publicados na IEEE Software, que não correspondiam ao funil simétrico. Projetos reais atrasam com muito mais frequência do que terminam antes, e muitos ficam parados em "90% concluído" por um bom tempo.

A resposta de McConnell, no paper da Construx, é que o cone é o melhor cenário e que projetos mal conduzidos produzem uma "nuvem" de incerteza que nunca se estreita. Portanto, trate o cone como um modelo didático útil e uma disciplina de planejamento, não como uma lei estatística. A lição prática vale de qualquer forma: números iniciais merecem faixas amplas.

Cone of uncertainty vs. outros conceitos de estimativa

O cone não é uma técnica de estimativa. É uma lente para avaliar o quanto confiar no resultado de qualquer técnica em determinado momento. Por isso ele complementa os métodos abaixo, em vez de substituí-los.

Uma boa regra prática: escolha o método cuja precisão corresponda à largura do cone. Uma estimativa bottom-up ao nível de hora é falsa precisão no conceito inicial. Uma estimativa análoga aproximada é desperdício quando o design já está pronto e o escopo está fechado.

Por que as estimativas iniciais erram

É tentador culpar o estimador. Em geral, o estimador não é o problema. Quatro fatores alargam o cone no início.

Os requisitos são vagos. "Construir um portal do cliente" pode significar uma página de login e uma lista de faturas, ou uma plataforma de autoatendimento completa com pagamentos. Ambas são leituras honestas. A diferença de esforço entre elas é enorme.

O escopo é um alvo móvel. As partes interessadas adicionam e removem funcionalidades quando veem algo concreto. Isso é expansão do escopo em sua forma inicial, antes mesmo de existir uma linha de base da qual se afastar.

As dependências são desconhecidas. Você ainda não sabe que a equipe de pagamentos tem uma fila de seis semanas, ou que o sistema legado precisa ser reescrito antes de você integrá-lo.

A equipe ainda não está consolidada. Habilidades, disponibilidade e velocity são palpites até que as pessoas tenham trabalhado juntas no projeto real.

Há ainda a camada humana. O otimismo é o padrão, e um número dito em voz alta numa reunião tende a virar promessa. Se um sponsor ouve "cerca de quatro meses" no conceito inicial, esse número vai parar num plano, num orçamento e, às vezes, num contrato com o cliente. Ninguém lembra que ele veio acompanhado de uma faixa de "um a dezesseis".

A Construx aponta isso como o verdadeiro perigo. As organizações que assumem compromissos enquanto o cone ainda está largo, nas palavras do paper, prejudicam a previsibilidade e aumentam o risco. Comprometer-se no conceito inicial ou na definição do produto significa conviver com um erro de estimativa de 2x a 4x.

Como usar o cone of uncertainty (passo a passo)

Você não consegue fazer o cone desaparecer, mas pode usá-lo de forma deliberada. Aqui vai uma sequência prática.

Passo 1: Dê o nome honesto à fase

Decida em que ponto o projeto está hoje: ideia inicial, escopo aprovado, requisitos completos, design completo ou em construção. Seja criterioso. Um projeto com orçamento aprovado e um documento de requisitos pela metade ainda está na extremidade larga.

Passo 2: Dê uma faixa, não um ponto

Converta sua melhor estimativa em um valor mínimo e um máximo. No conceito inicial, o modelo da Construx permite de 0,25x a 4x, então um palpite de 100 dias vira 25 a 400 dias. Isso parece absurdo num slide, e é justamente o objetivo. Se a amplitude alarmar as pessoas, elas concordarão com o trabalho que a estreita.

Para faixas no nível de tarefa, a estimativa de três pontos oferece uma forma defensável de produzir os valores mínimo, provável e máximo.

Passo 3: Liste as incógnitas que criam a largura

Anote cada pergunta em aberto que move a estimativa: requisitos indefinidos, integrações desconhecidas, equipe não confirmada, tecnologia não comprovada. Ordene-as pelo quanto cada uma acrescenta à faixa. Essa lista também é o ponto de partida do seu registro de riscos.

Passo 4: Agende o trabalho que elimina incógnitas

Trate a descoberta como entregáveis. Defina a visão do produto, incluindo o que está fora do escopo. Conclua os requisitos. Prototipe a interface mais arriscada. Faça um technical spike na integração que ninguém testou. Cada uma dessas ações elimina variabilidade, e cada uma deve ter um responsável e uma data.

Passo 5: Adie o compromisso firme

A orientação de McConnell é que compromissos significativos não são possíveis na parte inicial e larga do cone, e que organizações eficazes esperam até forçá-lo a se estreitar. O paper dele descreve compromissos assumidos cerca de 30% adiante no projeto como possíveis e apropriados. Se o negócio precisa de um número antes, informe a faixa e identifique-a como faixa.

Passo 6: Reestime a cada marco

Refaça a estimativa sempre que uma incógnita importante for resolvida, e não conforme o calendário. Compare cada nova faixa com a anterior. Se ela não está se estreitando, você tem uma nuvem, e o projeto precisa de uma conversa sobre escopo, equipe ou abordagem.

Passo 7: Defina a linha de base quando a faixa estiver estreita

Quando a faixa estiver estreita o bastante para o sponsor financiar e a equipe se comprometer, registre-a como a linha de base do projeto. Acompanhe a variação em relação a esse valor a partir daí.

Template pronto para copiar: rastreador de faixa de estimativa

Copie esta tabela para o seu plano de projeto e atualize-a a cada marco. A coluna "Largura" é simplesmente o valor máximo dividido pelo mínimo, o que mostra de relance se o cone está se estreitando.

Como preencher:

1. Mínimo e máximo vêm de estimativas de três pontos somadas ao longo do trabalho, ou dos multiplicadores do cone aplicados a um único melhor palpite.
2. Incógnitas resolvidas é uma lista simples das decisões tomadas desde a última linha. Se essa célula está vazia e a largura não mudou, isso é esperado.
3. Compromisso permitido? é uma coluna de política. Combine-a com seu sponsor desde o início para que ninguém discuta sobre isso no começo.

Se a coluna de largura parar de cair por dois marcos seguidos, escale o problema. Algo no projeto não está convergindo.

Exemplos por função de negócio

O cone não se limita a software. Qualquer trabalho com escopo indefinido e etapas desconhecidas se comporta assim. Os valores abaixo são aritmética ilustrativa, aplicando os multiplicadores da fase inicial do cone (0,25x a 4x) a um primeiro palpite aproximado, e não benchmarks.

Tome o lançamento de marketing. "Oito semanas" parece razoável até você perguntar o que está incluído. Se o brief não foi aprovado, não se sabe quem aprova os textos e não se definiu se o jurídico precisa revisar as alegações, então "oito semanas" é uma esperança. Depois que o brief, o sitemap e a cadeia de aprovação forem fixados, o mesmo projeto poderia ser honestamente cotado em seis a dez semanas.

A mesma lógica vale para uma implantação de operações. Antes do mapeamento de processos, o valor de $200,000 não tem mais fundamento do que $600,000. Depois do mapeamento e de uma shortlist de fornecedores, a faixa pode se estreitar até algo que um diretor financeiro consiga assinar.

O cone e as equipes Agile

Uma objeção comum: "Somos Agile, então o cone não se aplica." Ele se aplica de outra forma, não deixa de se aplicar.

O próprio paper da Construx diz que, em projetos iterativos, você passa por um cone em miniatura a cada iteração. Antes do trabalho de requisitos de uma iteração, você está na parte do cone correspondente à definição de produto aprovada. Com iterações curtas, uma equipe consegue percorrer requisitos e design de UI em poucos dias, reduzindo a variabilidade de 4x para 1,6x naquela fatia do trabalho. Se o cronograma é fixo, essa variabilidade aparece como incerteza sobre quais funcionalidades cabem, e não sobre a data final.

O que se perde, observa o paper, é a previsibilidade de longo prazo do custo, do cronograma e das funcionalidades combinados, várias iterações adiante. Muitas equipes adotam um caminho intermediário: definir a maior parte dos requisitos de antemão e depois construir em iterações curtas. O paper afirma que isso leva a variabilidade do cone para cerca de mais ou menos 25%.

Na prática, isso significa que as equipes Agile ainda precisam de faixas para roadmaps e datas de release, e métodos de dimensionamento relativo como story points funcionam melhor para o trabalho de curto prazo. Itens distantes merecem um dimensionamento grosseiro e um honesto "saberemos mais depois".

Dos e don'ts do cone of uncertainty

Dos

• Informe faixas desde cedo. Diga "de quatro a dezesseis meses" no conceito, não "oito meses". Uma faixa protege você e educa o sponsor.
• Vincule o estreitamento a decisões nomeadas. Cada linha do seu rastreador deve mostrar o que foi resolvido desde a última estimativa.
• Reestime nos marcos. Uma nova estimativa depois que os requisitos estão completos vale mais do que uma atualização mensal sem nada de novo.
• Use as faixas para priorizar a descoberta. A incógnita que mais acrescenta largura é trabalhada primeiro.
• Separe estimativas de compromissos. Uma estimativa é o que você espera. Um compromisso é uma promessa. Não devem ser confundidos na mesma frase.
• Combine o cone com um método quantitativo como a simulação de Monte Carlo quando você tiver detalhe suficiente para modelar.

Don'ts

• Não trate o cone como automático. O passar do tempo não o estreita. Decisões, sim, e o paper da Construx diz que o cone pode virar uma nuvem quando um projeto não é bem controlado.
• Não prometa uma precisão que o modelo não entrega. Nem estimadores experientes conseguem superar o cone. Só conseguem errar por mais.
• Não comprima a faixa para agradar o sponsor. Um número mais apertado sem informação nova por trás é apenas um risco maior.
• Não ignore a assimetria. Projetos reais atrasam com mais frequência do que terminam antes, então não presuma que os extremos baixo e alto são igualmente prováveis. Incline sua faixa para o lado pessimista.
• Não deixe uma estimativa pontual sair da sala. Quando "cerca de quatro meses" aparece num e-mail sem a faixa, vira promessa.
• Não use um método preciso numa fase vaga. Estimativas bottom-up em nível de hora sobre um conceito de uma página são teatro.

Erros comuns com o cone

Algumas equipes ouvem "estimativas são pouco confiáveis no início" e concluem que planejar é inútil. Não é. O cone diz para planejar na proporção do que você sabe e para gastar o esforço inicial resolvendo as maiores incógnitas, em vez de polir um número.

Outras levam o formato simétrico ao pé da letra. A crítica de Bossavit é um bom lembrete de que um diagrama limpo não é evidência de uma distribuição limpa. Use os multiplicadores como ponto de partida para uma conversa e depois ajuste ao seu próprio histórico. Se os projetos anteriores da sua organização estouraram 40% em média, leve isso em conta.

Um terceiro erro é usar o cone para justificar o descumprimento de uma linha de base. Quando escopo e design estão estáveis, o cone cumpriu seu papel. Nesse ponto, o desvio em relação à linha de base é uma questão de gestão, não de incerteza. Os trade-offs de escopo, prazo e custo passam a ser a conversa certa.

Principais conclusões

O cone of uncertainty oferece uma resposta defensável a uma pergunta que todo sponsor faz: "Quanto tempo vai levar?" A resposta honesta no início é uma faixa, e a largura dessa faixa é informação. Estreite-a tomando decisões, não esperando. Mantenha compromissos firmes até que o cone tenha se estreitado. E revise seus números a cada vez que uma incógnita real for resolvida.