Meu prazo de 3 semanas virou 7: rodei um git log nos arquivos que o escopo encostava

Dei três semanas para uma entrega que levou perto de sete. O código novo saiu na primeira semana, mais ou menos como eu tinha imaginado. O resto do tempo foi embora em dois arquivos que a tarefa encostava de raspão e que ninguém do time atual tinha aberto na vida.

Depois dessa eu parei de responder "quanto tempo leva?" antes de rodar duas coisas no repositório. As duas juntas levam menos de dez minutos e não precisam de ferramenta nenhuma além do git.

1. Que idade tem o código que o escopo encosta

Primeiro eu escrevo num arquivo os caminhos que a tarefa provavelmente toca. Chute mesmo, uns 10 a 15 caminhos, sem preciosismo. Depois pergunto ao git quando cada um foi mexido pela última vez e quantas pessoas distintas já assinaram commit ali.

# escopo.txt: um caminho por linha
while read -r f; do
  printf '%s\t%s\t%s\n' \
    "$(git log -1 --format=%as -- "$f")" \
    "$(git log --format=%an -- "$f" | sort -u | wc -l | tr -d ' ')" \
    "$f"
done < escopo.txt | sort

A saída do repositório em questão, com os nomes trocados:

2021-03-19	2	src/integracao/erp/cliente.py
2021-08-02	1	src/integracao/erp/mapeamento.py
2024-11-30	6	src/pedidos/service.py
2026-07-14	9	src/pedidos/api.py
2026-08-03	11	src/checkout/handler.py

As duas primeiras linhas são o meu prazo estourado. Código de 2021, um deles com um único autor na história inteira, e esse autor saiu da empresa em 2023. Eu tinha somado aqueles dois arquivos ao chute como se fossem os de baixo.

Para saber se ainda existe alguém vivo que conhece o arquivo, vale o complemento:

git log --format='%an' -- src/integracao/erp/cliente.py | sort | uniq -c | sort -rn

2. Quanto daquele código está vivo

Data de último commit sozinha engana. Um arquivo pode ser velho e trivial. O segundo comando mostra o que o time realmente mexe no dia a dia:

git log --since="12 months ago" --no-merges --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -20

  87 src/checkout/handler.py
  63 src/pedidos/api.py
  12 src/pedidos/service.py

Os dois arquivos de 2021 não aparecem em lugar nenhum dessa lista. É isso que eu procuro: o cruzamento entre "ninguém tocou" e "ninguém que tocou ainda está aqui". Ali mora a variância, e variância é o que destrói data. Prazo médio errado eu corrijo na semana seguinte, desvio de três semanas mata um lançamento.

O que eu faço com a tabela

Eu quebro o chute em dois grupos. O que é recente e tem gente do time no histórico eu estimo no feeling mesmo, porque o feedback ali é rápido e o erro é pequeno. O que é órfão e antigo eu multiplico por uns 2,5 e marco como não medido.

Aí a resposta sai assim, em voz alta: "entre três e cinco semanas. O trecho que conversa com o ERP não é tocado desde 2021 e ninguém aqui assinou commit nele, então eu não sei medir ainda. Me dá até quinta, eu abro aquele módulo e volto com uma faixa menor."

A faixa não é bonita, mas ela sobrevive ao mês seguinte. E ela cria uma segunda conversa combinada, que é o que falta quando você entrega um número seco e some.

Onde a medição mente

• Commit de formatação em massa. Alguém rodou prettier, black ou trocou o lint no repositório inteiro e todo arquivo passou a ter data de ontem. O jeito de conviver é registrar esses hashes num .git-blame-ignore-revs e, para a idade real, olhar git log -1 --format=%as --skip=1 ou filtrar por autor de bot.
• Migração de repositório. Se o histórico foi importado com um commit inicial gigante, todo arquivo nasce no mesmo dia e a tabela vira enfeite.
• Squash merge. Você perde a granularidade de quem escreveu o quê dentro da branch, e a contagem de autores fica menor que a realidade.
• Greenfield. Sem histórico, não tem o que medir, e a medição aqui não te ajuda em nada.

A parte que o assistente de código não encolheu

Um detalhe que apareceu neste ano e bagunça a estimativa: o rascunho da feature agora sai em duas horas, e o dev sente que o card acabou. A faixa que ele te dá encolhe junto.

O que não encolheu foi a fila depois do commit. Num outro repositório eu medi a mediana de espera de um PR por um humano com contexto e deu 19,4 horas, sem contar o tempo de revisão em si. Escrever nunca foi o gargalo, e acelerar justamente o trecho que já era rápido só empurra a fila para frente. Continua valendo para o arquivo de 2021: o assistente escreve rápido nele também, e não tem como saber por que aquele if estranho existe.

Pergunta honesta

Qual medição vocês rodam no repositório antes de cravar uma data? E quem aqui já viu a data de último commit mentir por causa de um reformat em massa, teve que reconstruir a idade real do arquivo e achou um jeito melhor que ignorar hash na mão?

---

Publicado originalmente no blog da Revin: https://revin.com.br/pt/blog/como-responder-pedido-de-estimativa-prazo