Excelência técnica não concorre com entrega de valor em software

A separação entre “trabalho de negócio” e “trabalho técnico” cria uma escolha falsa: em software, funcionalidades são feitas de software. Na palestra de Kevlin Henney no Adaptive Organizations meet Architecture, essa afirmação simples organiza uma crítica a muitas adoções ágeis que preservam cerimônias, treinamentos e estruturas, mas tratam qualidade de código e desenho como atividades adiáveis. Para Henney, agilidade é uma propriedade observável: uma base de código permite mudanças rápidas e fáceis ou não permite. Se a arquitetura torna cada alteração mais cara, a organização pode continuar ocupada, mas fica menos ágil no sentido prático do termo.

O mecanismo aparece quando expressões aparentemente objetivas entram na conversa. “Valor de negócio”, diz Henney, não encerra uma discussão; começa uma. Valor para quem, em qual prazo, medido como? Ele ilustra isso com um caso em que seu chefe queria inserir um banco de dados em um projeto de processamento de imagem para gerar duas semanas adicionais de trabalho cobrável. A solução técnica alternativa, baseada em sistema de arquivos, levaria menos de um dia e evitaria custo de licença para o cliente. Havia valor de negócio, mas não para o mesmo interessado. Sem explicitar o beneficiário e o horizonte temporal, a expressão vira cobertura para decisões ruins.

A mesma precisão vale para priorização. Henney insiste que ninguém prioriza por valor de negócio real, porque esse valor só é conhecido depois de construir, entregar e observar. O máximo possível é priorizar por uma estimativa. A diferença importa porque estimativas carregam incerteza e devem ser tratadas como apostas, não como fatos. Esse enquadramento muda a conversa sobre qualidade: ignorá-la pode não ter custo imediato, pode até trazer uma vantagem curta, mas a pergunta seguinte precisa ser feita antes da decisão — o que acontece no médio e no longo prazo?

A discussão sobre dívida técnica aprofunda o ponto. Para Henney, muitas equipes dizem ter um problema de dívida quando enfrentam, na verdade, negligência técnica: não só há água dentro do barco, há furos por onde ela continua entrando. A metáfora de dívida só faz sentido quando inclui empréstimo, prazo e pagamento; sem isso, vira acúmulo não gerenciado. A consequência prática é deslocar a decisão para quem está perto do trabalho. Desenvolvedores conseguem perceber quando gastam o dia recuperando conhecimento perdido, corrigindo falhas ou lutando contra a arquitetura. Se essa percepção não entra na priorização, a organização chama de entrega aquilo que, cada vez mais, é compensação pelo passado.

Assistir ao episódio original

Referências encontradas

Livros

• Oxford Dictionary Of English — Ver livro na Amazon
• Metáforas de La Vida Cotidiana, de George Lakoff, Mark Johnson — Ver livro na Amazon
• Pattern-Oriented Software Architecture: On Patterns And Pattern Languages: Volume 5, de Frank Buschmann, Kevlin Henney, Douglas C. Schmidt — Ver livro na Amazon

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.