O Custo do Trabalho Invisível

Trabalho invisível é qualquer esforço que a equipe está gastando que não é rastreado em um sistema compartilhado. É mais comum do que a maioria das equipes admite, e assume formas previsíveis:

• Decisões em threads do Slack. Uma thread de 40 mensagens entre dois desenvolvedores resolve uma questão de design, mas a decisão nunca chega ao ticket ou à descrição do PR. Seis meses depois, alguém reverte a decisão porque não sabia que ela havia sido tomada.
• Tarefas "eu só vou fazer". Um desenvolvedor nota um teste instável, gasta duas horas corrigindo-o e nunca cria um ticket. O trabalho aconteceu, o tempo foi gasto, mas o plano de capacidade da equipe não reflete isso — e ninguém aprende com a correção.
• Projetos paralelos e spikes. Trabalho exploratório que vive em um branch local, nunca é revisado e ou morre silenciosamente ou surge como um PR surpresa três semanas depois.
• Hotfixes não documentados. Um problema de produção é corrigido às 23h com um commit direto na main. Sem ticket, sem post-mortem, sem registro de que a correção existe ou por que foi necessária. O próximo desenvolvedor que tocar naquele código não tem ideia do que as três linhas misteriosas estão protegendo.

Nenhum desses casos é malicioso. Desenvolvedores fazem trabalho invisível porque o atrito de rastreá-lo parece maior do que o custo de simplesmente fazê-lo. E para qualquer instância única, eles estão certos — criar um ticket para uma correção de 20 minutos parece overhead.

O problema não é nenhuma instância única. O problema é o padrão.

O trabalho invisível não permanece barato. Ele se acumula de três maneiras que ficam mais caras com o tempo.

O custo de onboarding aumenta. Cada decisão que vive na cabeça de alguém em vez de em um ticket ou documento é uma decisão que um novo membro da equipe não consegue encontrar. Uma equipe com seis meses de trabalho invisível requer um download verbal de várias semanas para integrar alguém — e esse download é incompleto, porque as pessoas que o dão esqueceram metade do que fizeram. Equipes com altas cargas de trabalho invisível rotineiramente relatam tempos de onboarding de 4–8 semanas para trabalho que deveria levar 2.

O trabalho é duplicado. Quando o desenvolvedor A não sabe que o desenvolvedor B já resolveu o mesmo problema no mês passado, o desenvolvedor A resolve novamente. Em uma equipe de 10 pessoas, isso acontece com mais frequência do que qualquer um percebe — particularmente com trabalho de infraestrutura, funções utilitárias e mudanças de configuração que vivem fora da base de código principal do produto.

O contexto evapora. Código sem um rastro de ticket é código sem um "por quê". O próximo desenvolvedor que o lê vê o que foi feito, mas não por que foi feito, o que significa que não pode mudá-lo com segurança. Ele ou o deixa em paz (acumulando débito técnico) ou o muda e quebra a suposição que o autor original estava protegendo (criando um bug). Ambos os resultados são caros, e ambos são evitáveis com uma descrição de ticket de um parágrafo escrita no momento do trabalho.

O acúmulo é o que torna o trabalho invisível perigoso. Um único hotfix não documentado custa cinco minutos de perda de contexto. Um ano de hotfixes não documentados custa semanas de arqueologia toda vez que alguém toca naquela parte do sistema.