A revista Veja desta semana, em reportagem sobre a tragédia terrível com o Airbus da Air France, trouxe o seguinte trecho: "Nada ilustra melhor a aviação comercial do que a máxima de que a solução parcial de um problema acaba criando novos problemas. (...) O mais intrigante é que as modernas tecnologias digitais embarcadas, ao invés de mitigar os desafios colocados aos projetistas, tornaram-nos ainda mais flagrantes. Uma dessas esteve no centro de algumas tragédias: o dispositivo digital projetado para impedir que os freios aerodinâmicos do avião, em especial aqueles que invertem o fluxo de ar das turbinas, os reversos, fossem acionados em pleno voo. Melhor: eles seriam acionados automaticamente quando do pouso. Os engenheiros basearam seu dispositivo no que parecia ser algo infalível. Um leitor digital de altitude trancava os reversos mesmo que o piloto os acionasse manualmente. A inovação destinada a resolver um problema acabaria criando vários. Em 1991, um Boeing 767 da Lauda Air caiu na Tailândia depois que, sem explicação aparente, os reversos se abriram em pleno voo. A investigação mostrou que o avião perdeu altitude em uma turbulência e o computador interpretou o fenômeno como um pouso, acionando os freios. Como resolver isso sem perder a automação? Os engenheiros modificaram o dispositivo de acionamento dos reversos, de modo que os sensores informariam ao computador para abri-los apenas depois que os dois conjuntos de pneus do trem de pouso tocassem o solo. A modificação foi considerada perfeita e adotada universalmente pelos fabricantes. Mas... e há sempre um mas... dois anos depois um Airbus A320 da Lufthansa não conseguiu acionar os reversos ao pousar na pista gelada do Aeroporto de Varsóvia, matando dois dos setenta passageiros. A causa? Ventos laterais fortes fizeram com que o trem de pouso da esquerda tocasse o solo nove segundos depois do da direita. O computador, fiel a sua programação, não
acionou os reversos e impediu os pilotos de ativá-los até que todos os pneus tivessem tocado o solo. Mais uma modificação foi feita, então, no desenho do dispositivo. Agora ele apenas informa o piloto, que decide quando acionar os freios."
Para quem tabalha com o desenvolvimento de sistemas, os casos acima citados são incrivelmente familiares. Um dos maiores desafios da engenharia de software tem sido conseguir obter do usuário as suas reais necessidades. É muito mais comum do que deveria, existir retrabalho no desenvolvimento de sistemas justamente porque, ou o usuário não soube dizer o que queria ou então o analista não conseguiu entender.
Investimentos vultosos têm sido feitos na área de Gerência de Requisitos, tanto no desenvolvimento de metodologias quanto na quantidade de horas gastas nessa etapa do processo. As empresas de tecnologia já perceberam que fica muito mais caro "remendar" do que fazer certo a primeira vez.
O trecho acima transcrito cita alguns exemplos clássicos de problemas de Gerência de Requisitos. No caso da abertura automática do reverso, alguém deveria ter alertado aos desenvolvedores do sistema que uma queda abrupta de altitude não poderia ser interpretada erroneamente como pouso. Ou então, se foram avisados, pior ainda, o produto final não atendeu aos requisitos. Na tentativa de fazer o "remendo", incluíram mais um requisito ao sistema: o reverso deveria ser acionado apenas quando os dois conjuntos do trem de pouco tocassem o solo. Mais uma vez houve falha de requisitos, deixando escapar que, em alguns casos, ele deveria ser acionado, mesmo não estando com os dois conjuntos encostados no chão.
Problemas parecidos, a grande maioria menos sérios, acontecem todos os dias em várias empresas. A busca incessante por automatização de todos os processos acaba fazendo com que gerentes e analistas de requisitos tenham trabalho redobrado, pois é exigido muitas vezes que o sistema comece a tomar decisões pelos seus usuários. Estes, por sua vez, não querem ou não sabem expressar todo o seu conhecimento. Com isso, exige-se desse tipo de profissional de tecnologia conhecimento apurado não somente da parte técnica como também dos detalhes de negócio. Por outro lado, pouco exige-se do usuário em termos de capacitação técnica e de negócio. A impressão que dá é que eles estão se sentindo cada vez menos responsáveis pelo desenvolvimento e uso dos sistemas. Estamos diante de um curioso paradoxo: as empresas querem automatizar tudo porque não confiam no que seus funcionários fazem e, por outro lado, os softwares vêm tendo comportamentos ambíguos justamente por terem a
responsabilidade de tomar decisões que deveriam caber à seres humanos.
Na minha opinião muito peso tem sido colocado nas equipes de desenvolvimento de software e nos próprios sistemas. É urgente e indispensável que se invista também na cultura geral e raciocínio lógico dos usuários. Ao contrário do que muita gente pensa, o maior sonho de um desenvolver de sistema não é substituir pessoas por softwares e sim ter pessoas inteligentes usando-os.
Nenhum comentário:
Postar um comentário