So Acaba Quando Termina

O problema que ninguém discute

Você já tentou estimar quanto tempo uma tarefa vai levar e o resultado sempre sai errado? Eu também. Já passei por reuniões de planejamento onde eu dizia "dois dias" e levava cinco, ou então acertava no palpite mas não entendia por quê. A questão é que a maioria das pessoas trata estimativas como se fossem fórmulas matemáticas, quando na verdade são mais sobre intuição calibrada do que cálculo puro. Existe um conceito que eu descobri por acaso em 2019, durante um projeto de desenvolvimento de software em São Paulo. Meu colega de equipe costumava dizer: "so acaba quando termina". No início eu achava que era preguiça disfarçada de filosofia. Depois de três anos trabalhando com metodologias ágeis, percebi que ele tinha razão — e não da forma como todo mundo imagina.

A armadilha da linearidade

O erro mais comum é pensar que trabalho criativo ou técnico segue uma linha reta. Você divide as etapas, calcula o tempo de cada uma, some tudo e chega num número. Parece lógico, mas falha porque ignora fatores que só aparecem no meio do processo. Quando eu comecei a aplicar a lógica do so acaba quando termina em meus projetos pessoais, o tempo médio de entrega caiu de 4 semanas para 11 dias em média. Isso acontece porque você para de superestimar tarefas que têm incertezas escondidas. Em vez de adivinhar o final antes de começar, você foca em remover obstáculos progressivamente. A meta não é prever o destino, é remover bloqueios até que o trabalho esteja feito. É um mindset diferente, mas tem base empírica sólida quando aplicado corretamente.

Como implementar na prática

Primeiro, pare de definir prazos fixos para entregas incompletas. Quando você diz "termina sexta", mas ainda não sabe o que vai acontecer durante a semana, está mentindo para si mesmo. A alternativa é dividir em ciclos de trabalho curtos — dois dias no máximo — e revisar o progresso ao final de cada ciclo. Segundo, use a técnica de "checkpoints de realidade". Após cada ciclo, pergunte: "o que mudou desde a última vez que verifiquei?" Se a resposta for "nada", talvez você esteja trabalhando na direção errada. Se for "apareceu um problema novo", isso é informação valiosa que precisa ser considerada no próximo ciclo. Terceiro, documente os desvios. Eu mantinha uma planilha simples onde registrava o tempo esperado versus o tempo real de cada tarefa. Após seis meses, os dados mostravam que minhas estimativas sistematicamente subestimavam tarefas de implementação em 40%, mas superestimavam tarefas de planejamento em 25%. Esse tipo de insight não aparece em teoria alguma — só na prática.

O caso específico que mudou minha perspectiva

Em 2021, estava construindo um sistema de automação para uma loja online. A estimativa inicial era de 3 semanas. Apliquei o método do so acaba quando termina literalmente: dividi em sprints de 2 dias, revisei diariamente, e ajustava o escopo conforme descobria complexidades. O projeto levou exatamente 2 semanas e 4 dias — e o mais importante, a qualidade foi muito superior porque pude refinar cada componente durante o caminho. O que aprendi foi que o segredo não é estimar melhor, é transformar estimativas em hipóteses testáveis. Quando você trata o prazo como uma suposição em vez de uma promessa, muda completamente a dinâmica do trabalho. A pressão por cumprir um timeline arbitrário desaparece, e sobra espaço para fazer o trabalho direito.

Limitações que ninguém menciona

Este método não funciona para tudo. Projetos com dependencies externas rígidas — como integrações com APIs de terceiros que têm SLAs fixos ou licenças de software com datas de vencimento — podem exigir prazos mais estruturados. Nesses casos, a abordagem híbrida funciona melhor: use o mindset flexível para o núcleo do trabalho, mas mantenha marcos rígidos para as partes que dependem de outros. Também existe o risco de escopo creeping. Sem um prazo fixo, é fácil deixar o projeto crescer indefinidamente. A proteção contra isso é estabelecer critérios claros de "pronto". Para cada funcionalidade, defina antes de começar: quais testes precisam passar? Quais métricas de performance devem ser atendidas? Quando isso estiver completo, o trabalho para. Outra limitação é social. Trabalhar dessa forma exige transparência com stakeholders. Se você não consegue explicar por que está mudando o escopo durante o processo, as pessoas vão achar que você não sabe o que está fazendo. A habilidade de comunicar progresso sem dar garantias vazias é tão importante quanto o método em si.

A versão refinada do conceito

Depois de aplicar o so acaba quando termina por dois anos, desenvolvi uma variação que chamo de "fim condicional". A ideia é simples: o trabalho termina quando todas as condições de aceitação forem atendidas, e essas condições são reavaliadas a cada ciclo. Isso combina a flexibilidade do método original com algum nível de previsibilidade que stakeholders costumam exigir. Na prática, significa que você mantém um backlog priorizado e trabalha até que os itens de maior valor estejam completos. Se sobrar tempo, continua nos próximos. Se faltar, para quando os critérios essenciais forem atingidos. É uma diferença sutil, mas faz todo o sentido quando se lida com times multidisciplinares ou orçamentos limitados. O resultado costuma ser entregas com qualidade consistente e times menos estressados. Não é perfeito — nenhum método é — mas resolve o problema central que a maioria dos profissionais enfrenta: a ansiedade gerada por prazos irreais e a frustração de entregar algo incompleto ou mal feito porque o tempo acabou antes do trabalho terminar.