O custo do atalho em desenvolvimento de softwareO custo do atalho em desenvolvimento de software

A conversa mais difícil que tive com um cliente, foi também a mais importante

O projeto era de risco elevado, chegou até nós já a derrapar e a razão não era uma só. O âmbito não estava bem definido desde o início, a equipa facilitou onde não se pode facilitar, e o próprio cliente não tinha uma visão clara do produto final.

Uma tempestade perfeita de decisões adiadas e sinais ignorados.

As reuniões de ponto de situação eram tensas. Havia momentos de compreensão, até de empatia genuína da parte do cliente, mas o elefante estava sempre na sala.

E eu tinha de o apontar.

O momento em que temos de parar

Antes de progredir mais, era necessário refazer uma parte significativa da arquitetura da aplicação. Não era uma questão de preferência técnica, a estrutura de dados não suportava o volume que sabíamos que vinha a seguir, os módulos estavam desenvolvidos de forma que tornava qualquer evolução futura num risco de regressão em cascata e cada nova funcionalidade iria certamente amplificar o problema, não o resolver.

Isto, logicamente significava tempo, custo, conversas difíceis, e o desconforto de assumir que parte do caminho percorrido até então teria de ser refeito.

Ninguém quer ouvir isto… Nem o cliente, nem a equipa que do projeto, nem eu.

Mas havia uma decisão real a fazer, e ela não era técnica, mas sim de carácter.

Entregar rapidamente e dentro do prazo estipulado, resolver o problema imediato e acumular dívida técnica que alguém pagaria mais tarde ou, travar, fazer bem, e garantir que o que ficava construído aguentava o que viria a seguir.

O custo do atalho

Em desenvolvimento de software, especialmente em projetos que tocam dados sensíveis e fluxos críticos de recursos humanos com impacto real na vida dos utilizadores, o custo do atalho raramente é imediatamente visível. Aparece mais tarde, quando a aplicação já está em produção, o volume aumentou ou alguém precisa de uma funcionalidade nova e descobre que a arquitetura não a suporta.

É nesse momento que a confiança, construída ao longo de meses de trabalho conjunto, pode ruir muito rapidamente.

O atalho tem sempre um custo. A única questão é quando nos é apresentada a fatura.

O que fizemos, e o que não aconteceu

Fizemos o refactor.

Não foi rápido nem indolor, mas a plataforma entrou em produção, escalou, aguentou o crescimento que veio a seguir e os problemas que teríamos tido, os bugs em cascata, as limitações de arquitetura e os refactors de emergência, nunca chegaram a existir.

Quase sempre, o melhor trabalho que uma equipa faz é o que o cliente não vê: os problemas que foram evitados, a facilidade e o custo reduzido de escalar a plataforma que simplesmente funciona, mês após mês, sem dramas.

O que ficou

Os projetos de software raramente falham por falta de tecnologia.

Falham porque ninguém teve a conversa difícil no momento certo!

Quem lidera projetos, seja do lado do cliente ou da equipa de desenvolvimento, sabe que existe um momento em que a escolha real não é técnica, mas sim entre agradar agora ou servir bem a seguir.

Nós ficamos sempre com a segunda opção. Não porque seja mais fácil, porque não é. É a única que nos permite olhar para o trabalho entregue e saber que foi feito para durar.

Quiteamind, uma década a construir soluções digitais “que aguentam o que vem a seguir”. 


Jorge Ferreira
Head of Digital, Quiteamind