Você não tem atraso. Você tem expectativa errada.

Atraso de projeto quase nunca é falha de execução. É decisão de prazo tomada sobre informação incompleta. “Semana que vem”, alguém escreveu no whiteboard, sem que os requisitos estivessem fechados, sem que a dependência com outro time estivesse resolvida, sem que o design estivesse final. Cinco dias depois, a mesma sala de reunião queria saber por que a entrega atrasou. Quem colocou prazo em cima de coisa que ainda não estava pronta é que prometeu demais.

• O sintoma visível é “time dev lento”. O sintoma real é alguém que escreveu uma data sem ter dados para sustentar a data.
• O problema não está em quem executa. Está em quem estima sem insumo suficiente.
• O framework das Quatro Perguntas de Readiness existe para colocar luz no momento exato em que o prazo vira ficção.

Como um prazo vira ficção

A frase nasce em uma reunião. O time está em volta, o PM ou o tech lead precisa cravar uma data para a próxima sexta, alguém pergunta “dá pra ser semana que vem?”, e o silêncio de três segundos em vez de um “não dá” termina virando um prazo. Não dá é uma resposta incômoda. Dá é um voto de otimismo.

Esse voto vira expectativa coletiva. A partir dali, semana que vira sexta, vira próxima segunda, vira “na semana que vem mesmo”, vira “essa semana sai”. O time que executa sabe que a data é fictícia desde o primeiro dia, mas quem está do lado de fora do código passou a tratar a data como compromisso. Três semanas depois, quando a entrega real acontece, o que se vê é um atraso de projeto. O que aconteceu foi uma mentira útil que durou até a primeira cobrança.

O mecanismo é sempre o mesmo: alguém com baixa informação de execução promete prazo, alguém com informação zero sobre o trabalho aceita o prazo, e a conta chega para quem não participou da promessa.

Quando a feature é só a ponta do atraso

A maioria das equipes jura que sabe o que precisa ser feito. A maioria das equipes está errada sobre isso. Existe uma diferença grande entre “o cliente explicou” e “o time construiu com base no que o cliente explicou e validou que era aquilo mesmo”.

Três sinais de que a feature está mal definida, mesmo quando todos acham que está pronta:

• O escopo cabe em uma frase ambígua. “O sistema precisa ser mais rápido”, “o relatório tem que ficar melhor”, “o cliente quer ver histórico”. Cada uma dessas frases admite pelo menos três interpretações diferentes, e cada interpretação vira uma semana de retrabalho.
• O time precisou perguntar “isso é o que o cliente quis dizer?” mais de duas vezes durante a implementação. Se a dúvida existiu, ela chegou no código como suposição, e suposição não é requisito.
• A aceitação final precisa de reunião de alinhamento de escopo. Se o que foi construído precisa ser renegociado com o cliente no fim, o requisito não estava pronto quando o prazo foi colocado.

A regra é simples. Requisito está 100% definido quando qualquer pessoa do time, lendo o documento de escopo sozinha, consegue descrever o que vai ser entregue sem precisar perguntar nada para ninguém. Se isso não é verdade, prazo é aposta.

A dependência que ninguém mapeou

Dependência externa é o prazo que está escondido dentro de outro prazo. O time assume que a API do parceiro vai estar pronta, que o time de dados vai conseguir entregar o ETL a tempo, que a área de segurança vai liberar a revisão antes do go-live. Cada uma dessas suposições é uma promessa de outra pessoa que virou prazo seu.

Capacidade do time é a segunda pergunta que ninguém faz. O dev sênior está alocado em três projetos. A pessoa de QA está cobrindo dois times. O designer está de férias. O prazo é possível em tese, mas em tese ninguém está de férias e todo mundo está focado. Na prática, a conta fecha no papel e não fecha na agenda.

Interrupção é a terceira variável que some da planilha. Reuniões de descoberta, suporte ao cliente, incidentes em produção, outros times pedindo ajuda. Se a feature é “importante mas não urgente”, ela vai ser interrompida toda vez que aparecer algo urgente. Quem colocou prazo sabia que a feature era “importante mas não urgente” e mesmo assim tratou como se fosse “importante e protegida”.

O Framework das Quatro Perguntas de Readiness

Antes de qualquer prazo ser colocado, quatro perguntas precisam ter resposta “sim”. Não “acho que sim”. Sim, com evidência.

1. Requisitos estão 100% definidos? Critério: qualquer pessoa do time consegue descrever o que vai ser entregue lendo o documento de escopo, sem perguntar nada para ninguém. Se existe ambiguidade, existe prazo fictício.

2. Dependências externas estão mapeadas? Critério: cada dependência tem um responsável, uma data confirmada, e um plano B documentado. Se a dependência está na cabeça de alguém que “vai ver isso”, ela é risco, não é insumo.

3. O time tem capacidade real para isso? Critério: a agenda de cada pessoa envolvida tem horas livres suficientes, descontadas férias, suportes e outros projetos. Se a capacidade é teórica, a entrega é teórica.

4. Ninguém vai interromper para outra coisa? Critério: existe acordo explícito de que a feature é protegida durante o período. Se “importante mas não urgente” virou o prazo, vai ser interrompida.

Qualquer resposta “não” derruba o prazo como compromisso. A entrega pode acontecer, mas o prazo é estimativa, não promessa. E estimativa se renegocia. Promessa se cumpre ou se atrasa, e o atraso é o que sobra quando a promessa é mais forte que a realidade.

A regra de aplicação é esta. Antes de dizer “semana que vem” em uma reunião, aplicar as quatro perguntas. Se uma falhar, dizer “preciso de mais N dias para fechar o escopo, e o prazo real é esse, e o motivo é esse”. O tempo de mais N dias é trocado por um prazo que vale alguma coisa.

Por que o atraso quase nunca é sobre o dev ser lento

A conta do atraso quase sempre cai sobre quem executa. O PM falou “semana que vem”, o cliente ouviu “semana que vem”, o time ouviu “semana que vem” e se organiza para isso, e três semanas depois o atraso de projeto é chamado de “atraso de execução”. A pergunta que não foi feita é: a informação disponível no momento em que o prazo foi colocado era suficiente para colocar aquele prazo.

PM não é cargo de prometer prazo. PM é cargo de proteger a entrega de promessas prematuras. A mesma pessoa que deveria ter dito “ainda não dá para cravar” foi a que cravou, e quando a entrega real aconteceu, a cobrança veio para quem executou sem ter como questionar a data.

Dev não promete atraso. PM promete prazo sem informação suficiente. Colocar a cobrança sobre quem executa é o jeito mais rápido de garantir duas coisas: o próximo prazo também vai ser fictício, e o próximo atraso de projeto também vai chegar. O custo de ser honesto sobre o que não se sabe é sempre menor do que o custo de ser pontual com uma data inventada.

A próxima vez que alguém disser “semana que vem”

Atraso é culpa de quem colocou prazo em coisa que não estava pronta. Antes de qualquer prazo virar compromisso, a pergunta é simples. Está tudo pronto para isso ser uma promessa, ou está pronto para isso ser uma aposta. As quatro perguntas de Readiness existem para que a resposta não dependa de torcida.

Quem executa, e sempre executou, dentro do possível que recebeu, não carrega o atraso. Quem prometeu o possível, e o fez sem perguntar, é quem responde por ele. O framework é uma ferramenta para tirar a expectativa errada da mesa antes de ela virar cobrança. Depois disso, é só entrega, sem desculpa, sem atraso, e sem voto de otimismo.

—

Leitura relacionada

• Sprint feedback não é rito. É termômetro. — feedback loop, e não cerimônia, é o que ajusta a expectativa de prazo antes de virar cobrança.
• Planning poker não é estimativa. É teatro de ansiedade. — política de estimativa que pula Readiness vira voto coletivo, e o atraso é o ressarcimento.
• ERP lento não é problema de infraestrutura. É problema de modelagem. — sintoma aparente mascara causa real, e o mesmo vale para entrega que “demorou demais”.