Pense. Porque nós fazemos software?

Você faz software por que outras pessoas precisam dele. Muitos desenvolvedores, mesmo os mais experientes esquecem algumas vezes que o motivo da construção do lindo software que eles estão fazendo é que alguém precisa do sistema para realizar alguma tarefa e eles só vão usar o sistema se ele atender as suas necessidades.

Não importa o quão lindo seja o software tecnicamente, ou quais técnicas e padrões de projeto foram usados na construção do sistema, no final das contas, alguém precisa usar e esse é o motivo de tudo. Essas afirmações tem vindo a minha cabeça ultimamente porque tenho “esbarrado” com muitos artigos e decisões sobre “qualidade” VS “entrega”, diversas são os artigos dizendo a você, quase que como um hino: “Não negocie qualidade.” Eu particularmente discordo, construir algo do zero não é fácil e como tudo na vida, decisões aplicadas ao contexto devem ser tomadas e muitas vezes, o problema é que a falta da qualidade no prazo solicitado não é deixada clara para quem solicitou, ou mesmo que o plano de negócio da empresa não está alinhado com o direcionamento da TI, ou mesmo que não existe plano de negócio.

O fato é que no fim das contas alguém tem de decidir entre entregar valor ao cliente e produzir o melhor software em aspecto técnico, com a melhor estrutura, performance e etc.

Eu particularmente acho que o problema não está no débito-técnico produzido momentaneamente, eu vejo um problema muito maior na falta de alinhamento entre o que é produzido e a estratégia da empresa.

E o que foi produzido para uma demanda pontual, pode ser refeito logo em seguida, desde que os custos adicionais fiquem claros para quem solicitou.

Casos como esse provavelmente aparecem todos os dias, custos adicionais com testes, falta de arquitetura bem definida, problemas com reuso de componentes mal projetados, esses fatores são provavelmente resultado de desconhecimento de engenharia de software ou de decisões de negócio mal planejadas.

Certa vez, tive de lidar com uma demanda relativamente fácil de implementar, porém, o componente que deveríamos alterar era utilizado em uma das áreas de mais demanda do sistema e que operava 24h na empresa, tínhamos 2 dias de prazo para realizar a alteração ou informar a diretoria que não atenderíamos a demanda.

O problema maior não era a dificuldade técnica, mas, a extensão dos testes que teriam de ser feitos e já estávamos no final do sprint, sem falar que os fornecedores de outro estado e outra operadora dependiam da alteração, ou seja, em termos de negócio, o prejuízo seria enorme.

Eu sugeri uma abordagem diferente e “errada”: Minimize o risco, copie o componente atual, modifique e aplique na área que precisa dele.

Uma revolução foi disparada entre os desenvolvedores, eu que sempre defendi fazer o certo, estava sugerindo uma gambiarra, logo obtive a resposta padrão: “faça certo da primeira vez”. Tentei expor os motivos para realizar a gambi, final de sprint, testar o sistema todo sem scripts automáticos, testar as outras alterações realizadas no sprint, horas adicionais de desenvolvimento e alto risco de para o setor por causa de problemas nessa área, novamente, a resposta padrão: “faça certo da primeira vez”.

Pois bem, no final das contas, aconteceu o pior, introduzimos um problema no componente que fez com que tivéssemos de retirar do ar a nova versão do sistema, isso por causa de brilhantismo técnico, depois do transtorno, fica a pergunta, pensamos sempre em entregar mais valor de negócio para o cliente, equilibrando o desafio técnico com a necessidade?

Bom, vou tentar deixar aqui um conjunto de conselhos para que vocês meditem comigo:

1. Lembre sempre, o motivo da construção do software é uma necessidade do cliente. A engenharia de software ajuda você a fazer o um software melhor, mais fácil de manter, com mais qualidade, mas, lembre sempre que sem usuário não existe sistema e que as oportunidades para o sistema podem não esperar você. Veja o exemplo do “Segundo sistema” no livro: o mito do homem-mês.
2. Avalie o impacto. Algumas alterações não são estratégicas e as pressões associadas são somente fogo de palha da diretoria, na verdade, as vezes nem existe um plano para utilização do recurso em questão. Mas, em certas horas, o seu brilhantismo pode aumentar drasticamente os custos do projeto, ou mesmo impossibilitar a utilização do sistema simplesmente porque você foi tão lento que deixou o momento certo passar. Mas, não se engane, não se venda, deixar a qualidade de lado sempre é uma decisão difícil e não existe uma fórmula mágica para decidir o que fazer, dependendo do que for solicitado, eu posso estar errado e o melhor seja dizer não.
3. Deixe as coisas claras. Se você decidir fazer do jeito aparentemente mais fácil, lembre de deixar isso claro para quem pediu e para não levar a culpa depois. Se puder registre formalmente e questione porque as atividades técnicas não estão alinhadas com o planejamento estratégico.
4. Se precisar, refaça. Depois de entregar a funcionalidade, verifique se o que foi entregue realmente tinha tanta importância e se realmente tiver, comece a refazer ou agende tempo para isso, para que sua equipe não acumule débito-técnico desnecessariamente em uma parte importante do sistema e, caso não seja usado, não gaste tempo e dinheiro refazendo algo que não tem valor para o cliente, pegue o caso discuta com os gestores para tentar alinhar o planejamento com o operacional.
5. Refaça seu planejamento. Uma mudança de rumo não é motivo para você deixar a organização de lado. Destrua o sprint, direcione as atividades para o maior valor de negócio, crie um branch, mas, faça tudo isso sabendo quando e o que você tem de entregar e principalmente, informe a todos o que você vai deixar de entregar. Opa, esqueci de mencionar que usamos scrum, adeque se julgar necessário, ao seu processo.