Teve um projeto grande, daqueles que refazem o que já existe, em que o prazo foi cortado pela metade antes mesmo de começar.

Ele terminou depois da estimativa original. A conservadora. A que tinha sido considerada lenta demais.

Antes de contar o que deu errado

Preciso contar por que a decisão de comprimir fazia sentido.

Projeto desse tipo não gera receita nova. Você refaz o que já existe, com uma jornada melhor e uma experiência melhor, e no fim do trimestre a empresa fatura exatamente o mesmo que faturaria sem ele. Enquanto isso, as pessoas alocadas ali são exatamente as que sairiam de trabalho que traz receita.

O retorno existia e era real. Só que era qualitativo.

E retorno qualitativo é difícil de defender num mundo em que cada vez mais é preciso otimizar custo e maximizar margem. Isso não é distorção nem vilania. É disso que empresa vive.

Comprimir o prazo era uma forma de limitar essa exposição. Menos meses com boa parte da engenharia fora da receita. Do lado de quem decide, é uma conta racional.

O que comprimir significou na prática

Significou fazer tudo ao mesmo tempo.

Boa parte do time de engenharia foi para o projeto, e todos os módulos passaram a ser desenvolvidos em paralelo. Inclusive a fundação, a base sobre a qual todos esses módulos seriam construídos.

Esse é o ponto que eu demorei a enxergar direito, e é o que eu mais quero deixar registrado aqui.

O problema não foi gente demais. Foi paralelizar em cima de uma fundação que ainda não existia.

E aqui vem a parte que me cabe: eu deveria ter sido mais firme. Dava para segurar o resto até a fundação estar pronta, e eu não segurei. A pressão do prazo era real, mas quem tinha a informação técnica para dizer o que aquela ordem ia custar era eu.

As consequências apareceram rápido

E todas pelo mesmo motivo.

Gente parada, esperando outro time entregar a peça de que precisava para seguir.

Como ninguém podia esperar, cada time resolvia do seu jeito. O débito técnico começou a nascer no primeiro mês de um projeto que ainda tinha muitos meses pela frente.

E o mesmo comportamento aparecia com bug em vários lugares diferentes, porque não deu tempo de criar os componentes compartilhados que aquilo pedia. Cada time tinha implementado a sua versão.

Acima de cinco devs, o time se divide sozinho

Nas minhas experiências, toda vez que tive times maiores do que cinco desenvolvedores, o time começou a se dividir sozinho.

Ninguém decide isso. O próprio time sente a necessidade de paralelizar as atividades e vai formando micro-squads dentro da squad.

O que se perde nisso é o objetivo comum. A squad deixa de perseguir uma coisa só e passa a tocar pedaços separados. Depois de algumas sprints, cada dev já pega demanda de um tipo só, porque não está por dentro da outra iniciativa. E quando não está por dentro, pegar aquele item custa caro.

O sintoma disso é fácil de reconhecer: a squad começa muitas coisas e termina poucas. Tem trabalho acontecendo em todo lugar e pouca coisa chegando ao fim.

A carga sobe na esteira inteira

Quando o trabalho se fragmenta assim, todo mundo passa a carregar mais contexto do que consegue segurar.

Isso não é impressão minha. É um dos argumentos de Team Topologies, do Matthew Skelton e do Manuel Pais: a carga cognitiva de um time deveria limitar o tamanho do domínio que ele cuida. Quando o domínio cresce além dessa capacidade, degrada a velocidade e, junto com ela, a qualidade do que sai.

Na prática, a conta chega em ordem.

Chega no PO primeiro. Para escrever uma estória boa de três frentes que não conversam entre si, ele precisa estar por dentro das três. Não estando, escreve mais raso. E requisito raso é o começo de tudo o que veio depois.

Chega no dev, que passa a pegar o item de sempre porque é o único em que está por dentro.

E chega no QA com mais força, porque a proporção de QA por desenvolvedor é sempre menor. Ele não recebe só mais itens. Recebe itens mais diferentes entre si, e passa o dia chaveando contexto.

O custo óbvio disso é produtividade. O custo caro é a qualidade da análise. Quem troca de contexto o tempo todo testa mais raso.

É sempre aqui que as mesmas frases aparecem

"O QA está demorando muito."

"Sobe assim e vai validando em produção até o cliente começar a usar de fato."

"É algo simples, não precisa demorar tanto."

Nenhuma delas é má-fé. São o que sobra quando o prazo já foi comprimido e a única variável que ainda parece negociável é o cuidado.

Quem paga é o usuário na ponta

Quando tudo isso se acumula, o problema atravessa a esteira inteira e vai parar na mão de quem abre o software para trabalhar.

Esse usuário não participou de nenhuma dessas decisões. Não estava na conversa sobre prazo, não sabe que o time dobrou de tamanho, não faz ideia de que os componentes compartilhados não deram tempo de ser feitos.

Ele só encontra o bug.

Essa é a parte que costuma sumir das discussões sobre produtividade, porque é a única em que a pessoa afetada não está na sala.

Quando já dava pra ver

A distância entre planejado e realizado foi aumentando, e num certo ponto ficou claro que não ia fechar.

O que acontece a partir daí é bastante previsível. Começam as horas extras no fim do dia e no fim de semana.

Vale olhar para isso com atenção, porque parece solução e não é. Hora extra só antecipa a capacidade da semana seguinte. É empréstimo, e empréstimo aparece no extrato depois.

No fim, custou mais caro

A compressão nasceu para reduzir a exposição da empresa a um investimento cujo retorno era difícil de medir.

Ela conseguiu o contrário.

O time grande ficou fora da receita por mais tempo do que ficaria no plano conservador, e ainda deixou débito técnico e retrabalho para os meses seguintes. A tentativa de encurtar a conta fez a conta ficar maior.

O que eu faria diferente hoje

Começo pela parte desconfortável: provavelmente eu não teria conseguido evitar a compressão.

O argumento do outro lado era bom, e eu não tinha como provar o custo antes de ele acontecer. Continuaria tentando mostrar que velocidade daquele tamanho cobra em qualidade, mas não acho que ganharia essa discussão com o que eu tinha na mão na época.

O que eu mudaria é outra coisa. Não o prazo: a forma da entrega.

Em vez de abrir tudo ao mesmo tempo, entregaria em partes, com a fundação pronta e provada antes de qualquer coisa ser erguida em cima dela.

Isso resolve os dois problemas de uma vez. A fundação para de ser construída no escuro. E o retorno começa a aparecer cedo, em vez de ficar guardado para o fim.

O segundo efeito importa mais do que parece. O que gerava a pressão, lá no começo, era um investimento longo e caro sem nenhum sinal de retorno no meio do caminho. Entrega parcial dá sinal. E sinal alivia pressão, em vez de alimentar.

Uma conta de dois minutos

Se você quiser saber se isso está acontecendo no seu time agora:

Conte quantos temas diferentes sua squad tem em andamento hoje. Depois conte quantos ela terminou na última sprint.

A distância entre os dois números é o argumento.