“Os tecnólogos têm a responsabilidade de garantir que a tecnologia não apenas faça o que deveria, mas também não faça o que não deveria.”

Escrevo isto no momento em que os detalhes da causa dos acidentes aéreos do Boeing 737 Max estão apenas começando a aparecer na mídia. Espero que todos nós, envolvidos na tecnologia, sejamos estimulados por esta tragédia a aumentar o nosso nível de profissionalismo.

Dois aviões caíram antes que o padrão fosse observado e a maior parte da frota mundial de 737 Max fosse aterrada. O voo da Ethiopian Airlines há oito dias e o avião da Lion Air em Outubro caíram minutos após a descolagem.

Parece que um sistema que foi concebido para evitar uma falha pode ter realmente contribuído para a causar.

Há um novo sistema de segurança nessas aeronaves projetado para evitar estol (causado quando um avião está subindo abruptamente). Esse sistema de segurança é chamado MCAS e pode instruir automaticamente o sistema de piloto automático para mudar o curso do avião, para descer.

Um único sensor no nariz da aeronave informa ao MCAS o ângulo atual da aeronave. O que pode ter acontecido é que o sensor falhou, deu sinais incorretos ao MCAS e isso afetou o comportamento do avião, com consequências desastrosas.

De acordo com esta reportagem da BBC o software MCAS provavelmente será rebaixado para evitar que o MCAS tenha uma influência tão forte no comportamento do avião.

E haverá mudanças nas pessoas e nos processos. “Haverá também mudanças nos sistemas de alerta da cabine, o manual de operação da tripulação de voo será atualizado e haverá treinamento informatizado para os pilotos”.

De acordo com este artigo no Seattle Times alguns dos riscos eram conhecidos e talvez houvesse alguma pressão comercial para acelerar as aprovações de voo. Talvez uma falha de gestão?

O que podemos aprender com isso?

Explorando a causa raiz

O uso bem-sucedido de qualquer software envolve uma combinação de: pessoas, processos e tecnologia. Uma falha como esta pode muito bem ter surgido devido a uma combinação de erros em cada uma destas áreas.

Pessoas: Os pilotos foram treinados para detectar e lidar com a circunstância de uma falha no sensor informando erroneamente o MCAS sobre o ângulo do avião? Quem diria que um sensor com falha poderia causar esse problema? O que eles poderiam/fizeram sobre isso? O risco de um cenário de falha foi conhecido, mas descartado como “improvável de acontecer”?

Processo: As instruções de operação do piloto foram adaptadas para incluir verificações suficientes do comportamento correto do sistema MCAS? Os pilotos foram informados, ou obrigados a saber, que isso poderia acontecer e foram aconselhados sobre como lidar com isso?

Complexidade: À medida que a tecnologia em que confiamos se torna cada vez mais sofisticada, ela também se torna mais complexa. Em sistemas complexos, contamos com apenas algumas pessoas que compreendem profundamente a capacidade ponta a ponta da tecnologia para construí-la corretamente. Gestores e usuários podem não ter, nem dispor de tempo, para compreender plenamente as complexidades do software que utilizam ou pelo qual são responsáveis. O software normalmente pode funcionar como deveria, mas sistemas complexos correm maior risco de não funcionar corretamente em todas as circunstâncias.

Quando você ouviu pela última vez “devemos adotar uma abordagem de testes baseada em riscos” como forma de encurtar os cronogramas?

Tecnologia: Esta é a área com maior probabilidade de estar sob escrutínio. A culpa foi da tecnologia? Por que um sistema dependente de apenas um sensor poderia arriscar o curso do avião? Uma falha no sensor pode ser detectada? Deveria haver mais de um sensor, caso um deles falhasse? Por que foi permitido que a lógica do software dependesse de uma única entrada?

Se o cenário ocorrido fosse previsto pelos projetistas da aeronave, eles poderiam ter proposto que o piloto pudesse ignorar tal circunstância. Nesse caso, poderemos ter uma falha nas pessoas e nos processos, e não na tecnologia.

A tecnologia pode ter se comportado incorretamente, ou seja, não conforme as especificações, caso em que teria havido uma falha na implementação e nos testes.

Alternativamente, a tecnologia pode ter se comportado de acordo com as especificações, mas a especificação estava errada. Se for esse o caso, deve-se examinar novamente os requisitos. Os requisitos estavam corretos?

Impacto

O impacto para as famílias que perderam entes queridos não pode ser medido. Além de perderem o familiar, também sofrerão consequências financeiras diretas e indiretas. Depois, há o custo para a Boeing, atrasos nas vendas, possível compensação às companhias aéreas pela perda de receitas, uma vez que a maior parte da frota de 737 está imobilizada. E há também o custo para todo o setor aéreo e outros setores relacionados que dependem das viagens aéreas. O impacto desta situação é da ordem de muitos milhares de milhões de dólares. E pode ser devido a uma especificação/requisito inadequado ou a um erro na codificação/teste ou a um erro no gerenciamento ou uma combinação desses fatores.

Conclusão

Numa organização com uma reputação de qualidade tão elevada como a Boeing, é improvável que uma única disciplina cometesse tal erro. A causa raiz deste desastre provavelmente será mais do que as possíveis áreas acima.

Estes eventos devem servir para lembrar a todos os envolvidos no fornecimento de tecnologia que as suas atividades podem ter consequências graves. À medida que nos tornamos mais dependentes de uma maior sofisticação dos sistemas, a necessidade de profissionalismo torna-se cada vez mais importante.

Somente adotando padrões de qualidade excelentes em todos os aspectos de gerenciamento, especificação, design, testes e implementação (que inclui pessoas e processos) a tecnologia poderá ser totalmente confiável..

Os tecnólogos têm responsabilidade profissional para garantir que a tecnologia não apenas faça o que deveria, mas também não faça o que não deveria. Isto só pode ser alcançado através de uma abordagem rigorosa da qualidade.