Como uma queda de avião pode melhorar a análise de TI

Na noite de 16 de agosto de 1987, o voo 255 da Northwest Airlines partiu do aeroporto de Detroit. Ele caiu um minuto depois e 156 pessoas morreram no acidente. O erro aparentemente óbvio dos pilotos levou a pesquisas envolvendo a NASA, mudanças no projeto de aeronaves e procedimentos de voo. Esta história também se relaciona com o gerenciamento da qualidade, o gerenciamento de projetos e a questão da culpa e punição, não apenas para os colecionadores do Soyuz MS-10 ferido, mas também para as pessoas que cometeram erros no seu trabalho.


Foto da cena do acidente do Bureau of Aviation Incident Archives

Catástrofe

A noite de 16 de agosto de 1987 em Detroit não agradou o clima. Uma tempestade se aproximava e a tripulação do voo 255 da Northwest Airlines estava com pressa de continuar o vôo - Detroit era o terceiro dos cinco aeroportos na rota e o atraso já era de meia hora. De acordo com a lei da maldade, a direção do vento mudou e os controladores redirecionaram o avião para outra pista. Como era o menor em todo o aeroporto, o co-piloto teve que recontar a massa da aeronave e sua quilometragem durante a decolagem para garantir que era possível decolar. O problema não vem sozinho - à noite, na chuva, a tripulação estava perdida nas pistas de táxi e, quando o avião finalmente foi para a pista, o atraso do cronograma já era de 45 minutos.

A decolagem ocorreu às 20:44 e imediatamente ficou claro que algo havia saído completamente errado - um aviso sobre o perigo de parar soou no cockpit, o avião não queria ganhar altitude e tombou de um lado para o outro. Depois de alguns segundos, ele colidiu com um poste de iluminação em um estacionamento, perdeu parte da asa e, já incontrolável, caiu em uma estrada, deslizou ao longo do viaduto, colidindo com o qual desabou completamente. Os dois pilotos, quatro comissários de bordo, 149 passageiros e duas pessoas em um carro esmagado foram mortos no acidente. Mais cinco pessoas no terreno ficaram feridas. A única sobrevivente foi Cecilia Chin, de quatro anos, que perdeu o pai, a mãe e o irmão mais velho em um desastre.


Padrão de voo, origem

Investigação

A evidência material e os dados das "caixas pretas" mostraram uma coisa incrível - uma equipe experiente e profissional cometeu um erro completamente "infantil" - esqueceu de soltar as abas!


Decolagem da família MD-80 semelhante à foto acidentada do Wikimedia Commons


Foto ampliada, a mecanização das asas é claramente visível

Um pequeno programa educacional. Slats e flaps são superfícies especiais que desviam e / ou se estendem na frente e na parte traseira da asa para criar elevação adicional em baixa velocidade. Usado para decolagem e pouso.

A investigação mostrou que não foram apenas as abas que foram esquecidas, mas um mapa de vôo inteiro (lista de verificação) de vários pontos que precisavam ser executados no táxi. Durante a decolagem, a tripulação até teve uma dica de que havia perdido alguma coisa - o computador de bordo não estava no modo de vôo e o controle de tração não foi ativado. Mas uma pessoa, especialmente em condições de estresse e pressa, é capaz de não perceber ou esquecer nada - a tripulação ignorou o aviso e não interrompeu a decolagem.

Não há menos perguntas, pelo contrário. Caso a tripulação se esquecesse de preparar o avião para a decolagem, foi criado um sistema especial que deveria sinalizar que as abas e ripas não estavam na posição de decolagem. Mas, por algum motivo, ela ficou em silêncio. Além disso, o sinal sobre o perigo de parar teve que vir de dois alto-falantes para garantir a confiabilidade e veio de apenas um. Uma investigação oficial descobriu que, por algum motivo desconhecido, o interruptor P-40 foi aberto, localizado atrás do assento esquerdo - esse interruptor acionava simultaneamente um aviso sobre uma configuração inquebrável e um dos alto-falantes do sistema de aviso de estol. O painel com esse comutador ficou gravemente danificado na falha e não funcionou para determinar se o comutador quebrou ou foi desligado manualmente. Mas uma história é uma evidência indireta muito importante.


Painel de interruptores à esquerda da cabine MD-80, fonte

Como parte da investigação, um investigador do Conselho Nacional de Segurança em Transportes (NTSB) John Clark pediu ao piloto do mesmo tipo com um MD-80 acidentado que mostrasse vários avisos. O piloto também reproduziu o aviso correto sobre a interrupção de dois alto-falantes e uma indicação dos retalhos que não foram liberados. Para demonstrar o sinal monofônico emitido durante um vôo fatídico, um dos canais teve que ser desconectado. E o piloto disse: "É claro que nunca fiz isso, mas alguns dizem que desativam especificamente o aviso sobre as abas não liberadas, porque muitas vezes funciona falsamente no táxi e é muito irritante", após o que, sem olhar, peguei o interruptor O P-40 atrás dele e com um movimento claramente familiar o desligou. E no painel do interruptor ao redor da P-40 havia mais sujeira, como se estivesse constantemente ligando e desligando ...

Portanto, a conclusão aparentemente óbvia "erro do piloto" mascara dois grandes problemas:

1. Há algo errado com os cartões de controle, pois eles são esquecidos de executar.
2. Se removermos os falsos alarmes do sistema de alerta para retalhos não lançados, os pilotos serão tentados a desligá-lo.

Vou repetir de novo especialmente - profissionais experientes também cometem erros. Tentativas de corrigir a situação através de medidas repressivas combateriam a investigação, não a causa - a tripulação do voo 255 não era irresponsável e, é claro, não queria morrer e levar pessoas inocentes para o túmulo. O comandante do navio trabalhou para esta companhia aérea por 31 anos, o co-piloto teve um vôo de vários milhares de horas, ambos, segundo colegas, eram bons pilotos, mas isso não ajudou em nada.

Infelizmente, eles não conseguiram encontrar soluções rapidamente - no próximo ano pela mesma razão (eles esqueceram de liberar as abas), um avião de outro modelo caiu, um Boeing 727, em Dallas. Das 108 pessoas a bordo, 14 foram mortas, mas houve mais falhas na tripulação - os pilotos violaram claramente a regra do cockpit "estéril" e conversaram com uma aeromoça que havia entrado antes da decolagem. Mas na gravação do gravador de voz, o copiloto diz que as abas são liberadas no ângulo certo, apesar do fato de que não é assim.

O problema dos cartões de controle foi tratado na NASA. Como resultado, apareceram recomendações para melhorias, começando pelo comprimento das listas de verificação e terminando com a fonte em que foram impressas. Além disso, os computadores foram ativamente introduzidos na aviação no final dos anos 80, e os listas de verificação começaram a fabricar eletrônicos - o computador não apenas lembra onde você parou quando estava distraído, mas também verifica se você fez o que marcou como concluído. Mas, infelizmente, ainda há algo a melhorar - o desastre da An-148 em fevereiro deste ano ocorreu porque os pilotos adiaram um dos pontos da lista de verificação e se esqueceram de executá-lo mais tarde (por uma questão de justiça, note-se que os projetistas da aeronave também falharam - este item não pode ser Foi feito com antecedência em um ambiente descontraído).

Os falsos positivos foram removidos não apenas no MD-80, mas também em outras máquinas - eles mudaram os requisitos do sistema como um todo, para que os vôos se tornassem mais seguros.

E onde está a TI?

A história do voo 255, na minha opinião, traz conclusões que podemos aplicar em casa na TI.

• A organização deve estar aberta à mudança - se alguém vê que algo está errado, é melhor que tenha a oportunidade de falar sobre isso e ser ouvido, não punido.
• Ao analisar o que aconteceu, o fakap deve se esforçar para encontrar as verdadeiras razões, e não se envolver na busca dos culpados. Corrigir problemas é mais importante que punição.

Uma metodologia para implementar esses princípios é chamada de autópsia sem culpa. A opção usada na empresa em que trabalho é chamada de solução sem culpa, SWOB. Deixe-me citar brevemente seus princípios:

Objetivos:

• O incidente é investigado pelos funcionários a ele relacionados, com o único objetivo de estabelecer que é possível melhorar e / ou aprender com seus erros (quem não faz nada não se engana).
• Registre conclusões para outras equipes para que elas possam aprender coisas novas e / ou oferecer idéias.

Importante:

• Melhorar processos é da conta de todos.
• Todos serão ouvidos.
• As autoridades estão abertas ao novo.

Promessas:

• Não tenha medo de cavar fundo e expressar razões desagradáveis. Ninguém será punido por participar de um SWOB ou qualquer coisa descoberta em um SWOB.
• Intolerável apenas desrespeito um pelo outro.

Destaques organizacionais:

• Escolha um facilitador independente que faça anotações e modere a discussão. Os facilitadores escolhem uma pessoa que é respeitada, por isso é uma honra ser. Mas a liderança não pode ser escolhida como facilitadora.
• É melhor realizar um SWOB com não muito tempo depois do fakap para se acalmar, mas também não é tarde demais para que as pessoas não esqueçam o que aconteceu. Ideal por uma semana após o problema.
• Formato da documentação: primeiro uma descrição do evento, depois idéias para melhorar os processos.

Conclusão

Se os pilotos pudessem transmitir aos projetistas que os falsos alarmes do sistema de alerta para retalhos não lançados estão muito atrapalhados, não haveria catástrofe no voo 255. Ainda não foram recebidas notícias no MS-10 Union exatamente como o sensor foi dobrado , mas no caso da introdução de análogos SWOB, os seguintes cenários são bem possíveis:

• Os catadores dobraram acidentalmente o sensor, mas, sabendo que não seriam punidos por se renderem, relataram que o sensor foi substituído, não houve acidente.
• Os catadores não entenderam alguma operação, sabendo que não seriam punidos, relataram isso, foram instruídos, não houve acidente.
• Os colecionadores descobriram que era inconveniente trabalhar, sabendo que não seriam punidos, conversaram sobre isso, processos mudaram, não houve acidente.

Não existe uma bala de prata, mas as idéias SWOB podem ajudar qualquer um de vocês. Boa sorte na melhoria dos processos!