Recebi recentemente um comentário que ficou na minha cabeça:

“Já vivi casos onde todos sabem o que é preciso ser feito, porém o corpo técnico acaba abrindo mão de algumas práticas por pressão na entrega. O backlog vai só crescendo. Uma das saídas que encontramos foi empacotar coisas técnicas junto dos pedidos de feature, mas isso não soa tão transparente.”

Primeiro, quero agradecer por essa sinceridade. É muito raro ver alguém expor, com tanta clareza, um conflito que muitos times vivem — mas poucos admitem. Sim, acontece nas melhores equipes. Sim, mesmo quando o time é sênior, experiente, competente.

E sim — já vivi isso também.

Esse tipo de decisão não nasce da ignorância. Nasce do atrito.

O time sabe o que precisa ser feito. Mas o ambiente está pressionando na direção contrária.

E aí surgem os atalhos: Refatorações “escondidas”, melhorias de arquitetura que viram “parte da entrega”, ajustes estruturais que são feitos “no tempo que sobrar”.

Essa prática — empacotar qualidade dentro das features — é uma saída prática. Funciona. Ajuda. E, na maioria das vezes, é feita por zelo.

Mas é também um sinal. Um sinal de que a qualidade ainda não conquistou espaço próprio no processo de decisão.

Por que isso incomoda? Porque a gente quer jogar limpo.

O desconforto com a transparência é legítimo. Fazemos isso para proteger o produto. O time. O futuro. Mas, ao mesmo tempo, sentimos que estamos “trapaceando” a governança do backlog.

É como disse Michael Feathers:

“A maioria dos problemas difíceis no desenvolvimento de software não são técnicos. São sociais.”

O que pode ajudar? Três ideias que aprendi apanhando bastante:

1. Reposicionar a conversa técnica

Não é sobre “refatorar porque ficou feio”. É sobre “evitar erros recorrentes”, “aumentar a previsibilidade”, “diminuir o esforço de manutenção”.

Como disse Martin Fowler, refatoração é uma técnica para manter o sistema saudável. Mas, para o negócio, vale mais dizer:

“Essa parte do sistema está nos custando tempo e criando riscos. Com essa melhoria, ganhamos agilidade e segurança.”

2. Criar espaço explícito para melhorias

Se tudo tem que virar feature para acontecer, então estamos forçando um jogo perigoso. Alguns times conseguem adotar o modelo 80/20: 80% do sprint para entregas de negócio, 20% para melhorias estruturais.

Outros fazem “sprints técnicos” a cada 3 ou 4 ciclos. O importante não é o modelo — é a legitimidade. A qualidade precisa ter espaço com nome e sobrenome.

3. Tornar o técnico mais visível no dia a dia

Uma Definition of Done que inclua testes, revisão de código, alertas de monitoramento, etc., ajuda a lembrar que essas práticas não são luxo — são parte do que significa “estar pronto”.

E quando essas coisas estão visíveis, o time não precisa mais escondê-las. Elas deixam de ser “desculpas” e viram parte do acordo.

No fim das contas: não é sobre culpa. É sobre maturidade.

A gente se sente mal porque quer fazer o certo. E às vezes, fazer o certo precisa de estratégias de guerrilha.

Mas, com o tempo, o ideal é que isso possa ser feito à luz do dia.

Equipes maduras devem poder conversar abertamente sobre qualidade, sem parecerem “chatas”, “perfeccionistas” ou “atrasadas”.

Obrigado por compartilhar sua vivência.

É desse tipo de relato que nascem reflexões honestas — e mudanças reais.

Se você está aí, tentando equilibrar a entrega com responsabilidade técnica, saiba que isso já diz muito sobre sua maturidade.

E mais importante: você não está sozinho nessa luta.