Manutenção de software: um monstro indomável
A interminável necessidade de que tudo é para ontem, a falta de processos para o levantamento dos requisitos e a baixa automatização nos deploys, somados, criam um monstro que, no dia a dia das corporações, provoca estragos incalculáveis.
Como diz o velho ditado popular: “o que começa mal, vai terminar pior”. O momento da solicitação pela área de negócio para o desenvolvimento de uma nova aplicação normalmente é confuso, corrido e sem grandes detalhes sobre o que se quer.
O time de TI é chamado e a equipe de requisitos inicia seus trabalhos. Essa equipe é tratada como os chatos que necessitam de muitos detalhes e informações para estruturar uma solução que, para a área de negócios, é algo tão simples de ser entendido e desenvolvido.
É exatamente neste momento que o monstro é concebido e irá assombrar a vida da aplicação enquanto ela existir. A necessidade de fazer tudo para ontem e colocar rapidamente no ar um sistema que ninguém sabe exatamente o que vai fazer, coloca em risco os anseios que a área de negócio tem em gerar novas receitas utilizando-se da nova ferramenta, e aterroriza quem terá a responsabilidade de sustentar a operação de uma aplicação que nasce com sérias falhas em sua concepção.
Como os requisitos foram coletados de maneira abrupta, sem muitos critérios e detalhamento, não existe como conceber uma aplicação sem uma quantidade de dúvidas e subjetividade que, com certeza, irá gerar, antes mesmo do término do seu desenvolvimento, uma enorme quantidade de alterações e manutenções daquilo que foi inicialmente previsto.
Não podemos esquecer que a urgência gera foco apenas no desenvolvimento e um relaxamento no seu entorno, principalmente no que diz respeito a documentar o que está sendo feito e como. Neste momento, não se pensa no amanhã, o objetivo é o ontem. Estamos sempre atrasados.
A primeira validação com o cliente é um verdadeiro “show de horrores”. E nem poderia ser diferente. Se o solicitante não sabia exatamente o que queria, é humanamente impossível para a área de desenvolvimento acertar na solução.
Como o foco está na urgência e não na solução, o monstro da manutenção é alimentado e cresce. Por outro lado, os processos e as documentações vão definhando mais e mais e perdendo forças.
Com o passar do tempo e a demora na entrega definitiva da solução, se no início do projeto existia qualquer intenção de planejar antes de desenvolver, agora torna-se apenas uma necessidade desenfreada desenvolver e entregar para atender o cliente. Os processos para desenvolvimento são descartados e entra em cena a técnica baseada na tentativa e erro: de um lado, os técnicos desenvolvem por inspiração e, do outro, a área de negócio mudando tudo a todo momento.
Não há mais tempo para espera e se coloca em produção aquilo que não atende quem solicitou muito menos quem o concebeu, mas, como diriam os mais afobados: precisamos atender às necessidades do negócio.
O que era até ontem projeto, hoje se tornou sustentação; o que antes era solicitação de requisito, agora é necessidade de manutenção. E estas não serão poucas nem de fácil execução, porque se quem desenvolveu não documentou, quem estará com a responsabilidade de manter e sustentar não saberá, quando os problemas aparecerem, nem por onde começar.
O monstro tomou conta da produção. Os problemas de sustentação são constantes e as solicitações de alterações não se findam; o que no início do novo sistema era a grande promessa de solução que mudaria a empresa, hoje passa a ser o grande legado que, se continuar como está, poderá afundar a corporação.
O bom desta história é que já vai longe a crença, tanto dos profissionais da área de negócio quanto dos de TI, que sem profissionalismo e seriedade pode-se gerar soluções consistentes e vencedoras. Hoje, mesmo ainda resistindo em alguns grotões a falta de planejamento, documentação e ferramentas para deploy, nossa realidade é que, dia após dia, monstros como estes estão se transformando em um passado que, para quem trabalha com tecnologia, não se tem saudade alguma.
