Inovação com sistemas vitais

Toda empresa tem uma infraestrutura “crítica”. Geralmente, isso significa que, se o sistema ficar offline, partes (ou todos) do negócio pararão até que os técnicos possam colocá-lo em funcionamento novamente. Isso geralmente ocorre quando grandes atualizações de software, hardware ou rede são necessárias: sistemas recém-implantados contêm bugs inesperados que causam uma falha no sistema ou usuários cometem erros com o novo sistema porque não estão familiarizados com ele, e a produtividade é interrompida até que os técnicos possam trabalhar com os bugs de implantação ou treinar os usuários. Na maioria das vezes, um período de inatividade ou produtividade reduzida é um risco aceitável em troca da promessa de melhor desempenho e eficiência da nova tecnologia, mas isso não é universal. A maioria das empresas pode arcar com um certo tempo de inatividade sem arriscar muita receita ou antagonizar seus clientes.

Mas o que acontece quando os sistemas que você precisa modificar são sistemas críticos para a vida , onde a segurança da vida depende da capacidade de usar o sistema de forma confiável?

Este artigo se afasta do desenvolvimento de software mais tradicional no qual passamos a maior parte do nosso tempo e, em vez disso, analisa o elemento humano em sistemas críticos para a vida. Meus pensamentos sobre este tópico derivam de minha experiência como Diretor de Tecnologia da Informação para um serviço de ambulância 911, como especialista em tecnologia para uma organização internacional de resposta a desastres humanitários e com meu Ph.D. em Integração de Sistemas Humanos concluído no Massachusetts Institute of Technology.

Antes de começarmos, gostaria de explicar por que isso pode ser relevante para você. Embora possa não ser óbvio que seu projeto realmente envolva um sistema crítico para a vida, é muito mais provável do que você imagina. Todos os itens a seguir se qualificam, bem como inúmeros outros tópicos:

• Automotivo. Trabalhando em um projeto com um fabricante de veículos ou algum de seus fornecedores? Recrutado da universidade por uma startup de carros autônomos? Frenagem automática, controle de cruzeiro, controle de faixa, visão computacional, reconhecimento de obstáculos, módulos de controle eletrônico do motor, etc. Cada um deles é um sistema crítico para a vida, onde uma falha pode ser fatal.
• Aviação. Quando você está a 30.000 pés no ar, quase qualquer falha do sistema pode ser crítica. Considerando os eventos recentes com o Boeing 737 MAX, existem os óbvios sistemas críticos de vida de piloto automático e controle de voo computadorizado, mas também há muitas coisas nas quais você pode não pensar. Em casa, se o ventilador do seu sistema HVAC falhar e produzir um pouco de fumaça, você abre a janela ou sai para tomar ar fresco. Você já tentou abrir a janela e sair durante um voo transatlântico? Mesmo os sistemas mais básicos, desde as tomadas na cozinha até os freios nas rodas do carrinho de bebidas, podem ser críticos para a vida das aeronaves.
• Comunicações. A maioria dos desenvolvedores ou engenheiros, em algum momento de suas carreiras, trabalhará em um projeto de sistema de comunicação em uma capacidade ou outra. Para muitas pessoas, as telecomunicações não parecem inicialmente críticas para a vida; afinal, a civilização se saiu muito bem antes dos telefones e da internet. Como alguém que foi implantado em zonas de desastre onde a infraestrutura de telecomunicações foi destruída, deixe-me dizer o que realmente acontece: as pessoas ficam muito doentes ou feridas e não podem ligar para o 911; os idosos não podem ligar para os filhos para pedir que retirem as receitas na farmácia; os atendentes de emergência não podem se comunicar com seus despachantes ou entre si; e as pessoas que não conseguem contatar seus familiares ficam preocupadas e se colocam em situações extremamente perigosas para tentar encontrá-los. Os sistemas de comunicação são absolutamente críticos para a vida.

No mundo atual de forte dependência da tecnologia, projetos que você nunca considerou semi-importantes podem acabar sendo um componente vital de um sistema vital.

Mas se não estiver quebrado, não conserte

Você já ouviu ou usou a palavra “patrimônio” em relação a um sistema tecnológico? É uma palavra forte, evocando pensamentos de tradições de longa data, linhagem e tempos difíceis de outrora. No mundo da engenharia, é usado para denotar projetos que existem há muito tempo e que comprovadamente funcionam de maneira confiável e geralmente são vistos como uma característica desejável para reduzir o risco. Na realidade, é um eufemismo para tecnologia arcaica que nunca foi atualizada devido à aversão ao risco e é difundida em indústrias onde falhas de sistema podem levar a consequências terríveis.

Há uma boa razão por trás dessa afinidade com software e hardware herdados. Sabe-se que funciona, é improvável que surjam bugs desconhecidos e seus custos são estáveis ​​e previsíveis. Um excelente exemplo é a indústria de voos espaciais: a espaçonave russa Soyuz lança astronautas ao espaço há mais de 50 anos, com apenas pequenas revisões durante esse período, e continua a ser usada porque é confiável e segura. Infelizmente, isso significa que também é extremamente ineficiente em comparação com os designs modernos: enquanto a Soyuz custa à NASA US$ 81 milhões por assento para levar astronautas à estação espacial usando seu hardware tradicional, espera-se que a SpaceX e a Boeing ofereçam assentos por US$ 58 milhões cada. usando seus designs de foguetes modernos.

É compreensível que poucas pessoas queiram atualizar sistemas antigos que ainda funcionam; os executivos não querem o risco, os técnicos não querem lidar com o misterioso servidor no armário com um tempo de atividade de 12 anos e os clientes não querem ter que aprender novos designs. Infelizmente, há um ponto de inflexão entre a minimização de riscos e a economia de custos: os projetos de patrimônio precisarão ser atualizados eventualmente, mesmo em ambientes de alto risco .

O restante deste artigo abrange algumas das etapas mais importantes no processo de fazer isso quando seus sistemas são críticos para a vida, como aqueles usados ​​por socorristas, unidades militares ou aeronaves.

Convencendo o latão

Na minha experiência, possivelmente a etapa mais difícil do processo é convencer os tomadores de decisão e as partes interessadas de que as atualizações são necessárias. Os sistemas que operam em ambientes críticos para a vida são frequentemente regidos por extensa regulamentação legal e política organizacional, o que significa que você precisa convencê-los de que eles não devem apenas assumir o risco e gastar o dinheiro, mas também se envolver no que poderia facilmente ser vários anos de cortes burocráticos. A oposição mais forte que você enfrentará provavelmente será da equipe jurídica, que apresentará em detalhes excruciantes a responsabilidade potencial para a qual você abrirá a organização ao introduzir novas tecnologias. Eles estão certos: a responsabilidade é uma questão importante e, se algo quebrar e alguém se machucar ou morrer, pode ser um enorme fardo ético, de reputação e financeiro.

Independentemente de você estar trabalhando com uma corporação Fortune 500 ou com seu corpo de bombeiros voluntário local, sempre se resume à mesma coisa: dinheiro. As corporações não querem perdê-lo, e as organizações sem fins lucrativos não têm muito com o que trabalhar em primeiro lugar. A única maneira confiável que encontrei para convencer a liderança de uma organização a assumir o risco de mudar um sistema crítico de vida é demonstrar que, probabilisticamente, eles têm mais probabilidade de ganhar/economizar dinheiro do que perdê-lo, ou que podem reduzir sua responsabilidade modernizando sua tecnologia e melhorando a segurança.

O que isso significa é que você precisa fazer as contas. Qual é a probabilidade de haver tempo de inatividade prolongado ou falhas futuras devido a bugs (com base em implantações anteriores em sua organização ou dados de outras organizações)? Qual é o impacto esperado se falhar e quanto isso custaria? Por outro lado, quais são os ganhos de desempenho ou confiabilidade esperados e qual seria o valor deles? Se você puder mostrar que há uma alta probabilidade de sair na frente, há uma boa chance de obter a luz verde.

Não é sobre você

Você pode estar familiarizado com a frase “por engenheiros, para engenheiros”, uma expressão idiomática que sugere que os engenheiros construíram algo para ser usado por pessoas com qualificações semelhantes às suas. É uma ocorrência extremamente comum e foi um dos principais fatores precipitantes para o surgimento dos estudos de usabilidade de computadores no início da década de 1990. Como engenheiros, muitas vezes temos modelos mentais diferentes de como os sistemas tecnológicos funcionam do que o usuário final médio, levando a uma tendência de projetar sistemas com a suposição de que o usuário final já sabe como ele funciona. Em sistemas convencionais, isso leva a erros e clientes insatisfeitos; em sistemas vitais, pode levar à morte.

Considere o caso do voo 447 da Air France. Em 1º de junho de 2009, o Airbus A330 sobrevoava o Oceano Atlântico a caminho do Rio de Janeiro para Paris. Cristais de gelo obstruíram os tubos de pitot, causando inconsistências nas medições de velocidade do ar. O computador de voo desativou o piloto automático, reconhecendo que não poderia pilotar o avião de forma confiável com dados incorretos de velocidade do ar. Em seguida, ele se colocou em um modo de “envelope de voo estendido” , o que permitiu aos pilotos realizar manobras que o computador normalmente não permitiria. Você pode imaginar os engenheiros que construíram o sistema pensando “se o piloto automático se desligar, provavelmente é porque há uma situação em que os pilotos podem precisar de controle extra! ”

Essa é a linha de pensamento natural dos engenheiros, que entendem que tipos de coisas podem fazer com que o piloto automático desligue. Para os pilotos, não foi o caso. Eles forçaram a aeronave a uma subida íngreme, ignorando os avisos de “ESTOLHE”, até que ela perdeu toda a velocidade no ar e despencou no oceano. Todos os 228 passageiros e tripulantes morreram. Embora existam várias ideias sobre a motivação exata para suas ações, a teoria predominante é que os pilotos assumiram que o computador de voo impediria entradas de controle que parariam a aeronave (o que é verdade para o envelope de voo normal), e não perceberam que ele havia mudado para o modo de envelope estendido porque eles não compartilhavam o modelo mental dos engenheiros da lógica que conduzia as decisões do computador.

Embora seja um caminho um pouco tortuoso, isso nos leva ao meu ponto principal: as ações que você deseja que os usuários executem sob condições específicas devem ser as ações que parecem naturais para o usuário .

Os usuários podem ser instruídos a seguir procedimentos específicos, mas eles simplesmente nem sempre vão se lembrar da coisa certa a fazer ou entender o que está acontecendo sob condições de alto estresse. É sua responsabilidade projetar software, controles e interfaces de uma maneira intuitiva que faça com que os usuários queiram inerentemente fazer as coisas que deveriam fazer.

O que isso significa é que é absolutamente crítico que os usuários finais estejam envolvidos em cada estágio do processo de design e desenvolvimento. Não pode haver suposições sobre o que os usuários provavelmente farão; tudo deve ser baseado em evidências. Ao projetar interfaces, você deve realizar estudos para determinar os padrões de pensamento que elas induzem nos usuários e ajustar conforme necessário. Ao testar seus novos sistemas, você deve testá-los com usuários reais em ambientes reais sob condições realistas. E, infelizmente, quando você altera seus designs, você deve fazer essas etapas novamente.

Embora cada sistema complexo seja único, gostaria de mencionar três considerações de design, em particular, que devem ser aplicadas universalmente:

• Os controles devem ser representativos das ações que invocam. Felizmente, este é bastante comum, geralmente visto na forma de selecionar ícones relevantes para botões GUI ou formas relevantes para controles físicos. Os botões “Novo arquivo” usam um ícone de folha de papel em branco, e as alavancas do trem de pouso em aeronaves têm um botão em forma de roda. No entanto, é fácil tornar-se complacente. Por que ainda vemos ícones de disquete de 3,5” para os botões “Salvar”? Alguém com menos de 25 anos sabe o que é um disquete? Continuamos a usá-lo porque achamos que é representativo, mas na verdade não é mais. Requer um esforço constante para garantir que as representações dos controles sejam significativas para os usuários, mas também é necessário e difícil equilibrar isso com continuidade.
• Se um sistema de aviso quebrar, ele deve ser detectável. Costumamos usar luzes de aviso que são ativadas quando há um problema, como um indicador vermelho piscando. É ótimo para chamar a atenção do usuário, mas o que acontece se a luz queimar? A espaçonave usada nas missões lunares Apollo tinha dezenas de luzes de alerta para todos os tipos de sistemas, mas não funcionava de maneira convencional. Em vez de iluminar quando havia um problema, eles permaneciam iluminados quando tudo estava bem e desligados quando havia um problema. Isso garantiu que uma luz de aviso queimada não fizesse com que os astronautas perdessem um erro de sistema potencialmente fatal. Não estou dizendo que você deva usar esse design, já que as lâmpadas percorreram um longo caminho em termos de confiabilidade desde a década de 1960, mas dá uma ideia de quão profundo deve ser parte de seu planejamento. Quantas vezes um sistema travou, mas você não sabia disso, porque o registro ou as notificações não estavam funcionando corretamente?
• As transições de modo devem ser óbvias para o usuário. O que acontece se um Airbus A330 passar do modo de controle normal para o modo de controle avançado sem que o usuário perceba e, de repente, a aeronave fizer coisas que o usuário não achava que poderia fazer? O que acontece se um carro autônomo desligar o piloto automático, deixando o usuário inesperadamente no controle total? O que acontece quando há uma grande transição no modo ou funcionalidade que requer uma mudança imediata nas ações do usuário, mas leva um ou dois minutos para o usuário descobrir o que acabou de acontecer? Embora uma variedade de modos de operação possa ser necessária em um sistema complexo, os modos não podem fazer a transição sem aviso, explicação e interação adequados com o usuário ao fazê-lo.

Lançando sistemas críticos para a vida fora da oficina

De acordo com as melhores práticas do setor, uma fase beta é crucial para implantações de novos sistemas críticos para a vida. Testes de sua nova tecnologia podem ter ajudado a corrigir a maioria dos bugs e problemas de usabilidade, mas perigos ocultos podem surgir quando ela precisa ser usada junto com outros sistemas em ambientes do mundo real. Na disciplina de engenharia de sistemas, isso é conhecido como “emergência”. Propriedades emergentes são “comportamentos inesperados que resultam da interação entre os componentes de um aplicativo e seu ambiente” e, por sua própria natureza, são essencialmente impossíveis de detectar em um ambiente de laboratório. Ao convidar um grupo representativo de usuários finais para testar seu novo sistema sob supervisão cuidadosa, muitas dessas propriedades podem ser detectadas e avaliadas quanto às consequências negativas que podem aparecer na implantação em grande escala.

Outro tópico que muitas vezes surge nas discussões de arquitetura com meus clientes é o lançamento em fases. Esta é a escolha entre substituir gradualmente elementos de um sistema pré-existente por elementos de um novo até que eventualmente tudo seja substituído ou mudar tudo de uma vez. Há prós e contras para cada um: um lançamento em fases permite a adaptação gradual dos usuários ao novo design, garantindo que as mudanças venham em quantidades gerenciáveis ​​e os usuários não fiquem sobrecarregados; por outro lado, pode arrastar o processo por longos períodos e resultar em um estado constante de transição. Os lançamentos imediatos são benéficos porque “arrancam o band-aid” e aceleram as coisas, mas as mudanças drásticas repentinas podem sobrecarregar os usuários.

Para sistemas de vida crítica, descobri que as distribuições em fases geralmente são mais seguras, pois permitem a avaliação incremental de componentes individuais em um ambiente de produção e permitem reversões menores se algo precisar ser revertido. Isso é algo que precisa ser avaliado caso a caso, no entanto.

Normalização do Desvio

OK, então seus testes de usuário ajudaram você a projetar um sistema intuitivo, sua fase beta identificou problemas emergentes, seu lançamento em fases permitiu que os usuários se sentissem confortáveis ​​com o design e tudo está funcionando sem problemas. Você terminou, certo? Infelizmente não.

Problemas com seu sistema inevitavelmente surgirão, não há como contornar isso. Quando os usuários se deparam com esses problemas, eles geralmente desenvolvem soluções alternativas em vez de relatar o problema à equipe de tecnologia. As soluções alternativas se tornarão uma prática padrão, compartilhadas como “dicas” de veteranos a novatos. A socióloga Diane Vaughan cunhou uma frase para descrever esse fenômeno: “normalização do desvio”. Os usuários ficam tão acostumados ao comportamento desviante que não conseguem se lembrar de que é, de fato, desviante.

O exemplo clássico é o Space Shuttle Challenger: um componente nos propulsores de foguetes sólidos era regularmente observado a erodir durante o lançamento e, embora todos soubessem que a erosão dos componentes do foguete era uma coisa ruim, acontecia com tanta frequência que as isenções eram emitidas regularmente e era considerado normal. Em 28 de janeiro de 1986, o problema que todos originalmente sabiam que não deveria ser permitido, mas que haviam normalizado, resultou na explosão do Challenger e na morte de sete astronautas.

Como administrador de um sistema crítico para a vida, cabe a você evitar que tais ocorrências aconteçam. Estude como seus usuários interagem com o sistema. Faça sombra neles por alguns dias e veja se eles estão usando soluções inesperadas. Envie pesquisas periodicamente para solicitar alterações e melhorias sugeridas. Dedique tempo e esforço para melhorar seu sistema antes que seus usuários encontrem maneiras de contornar os problemas sem você.

Treinamento para desempenho sob pressão

Muitas vezes, falhas em sistemas críticos para a vida ocorrem quando os usuários sofrem de estresse, picos de adrenalina e visão de túnel. Aconteceu com os pilotos da Air France 447, aconteceu com paramédicos que não conseguem se lembrar de como operar seu monitor cardíaco em seu primeiro paciente com parada cardíaca, e aconteceu com soldados que não conseguem operar seus rádios corretamente enquanto estão sob fogo.

Parte desse risco é atenuada pelo uso de designs intuitivos, conforme discutido anteriormente, mas isso por si só é insuficiente. Particularmente em ambientes onde ocorrem cenários de alto estresse, mas ocorrem com pouca frequência, é essencial treinar seus usuários não apenas como operar seu sistema, mas como pensar com clareza sob tais condições. Se os usuários memorizarem ações relacionadas ao equipamento operacional, eles não poderão lidar com falhas inesperadas porque as ações que aprenderam podem não ser mais apropriadas; se eles treinam para pensar de forma lógica e clara sob estresse, eles podem responder a mudanças nas circunstâncias e ajudar seu sistema a permanecer vivo quando algo quebra.

Conclusão

Obviamente, desenvolver, implantar e manter softwares críticos para a vida é muito mais complexo do que pode ser detalhado em um único artigo. No entanto, essas áreas de consideração podem ajudar a dar uma ideia melhor do que esperar quando você estiver pensando em trabalhar em um projeto desse tipo. Resumindo:

• A inovação é necessária, mesmo quando tudo está funcionando bem
• É difícil convencer os executivos de que o risco vale a pena, mas os números não mentem
• Os usuários finais devem estar envolvidos em todas as etapas do processo
• Teste e teste novamente com usuários reais em ambientes reais sob condições realistas
• Não assuma que você acertou da primeira vez; mesmo que esteja funcionando, pode haver problemas não detectados que seus usuários não estão informando a você.
• Treine seus usuários não apenas sobre como usar o sistema, mas como pensar com clareza e se adaptar sob estresse.

Para encerrar, gostaria de observar que em sistemas críticos de segurança complexos, as coisas vão dar errado em algum ponto, não importa quanto planejamento, teste e manutenção você faça. Quando esses sistemas são críticos para a vida, é bem possível que uma falha possa levar à perda de vida ou de um membro.

No caso de tal tragédia ocorrer com algo pelo qual você é responsável, será um peso esmagador em sua consciência e você provavelmente pensará que poderia ter evitado isso se tivesse prestado mais atenção ou trabalhado mais. Talvez seja verdade, talvez não, mas é impossível prever todas as ocorrências possíveis.

Trabalhe meticulosamente, não seja arrogante, e você estará fazendo do mundo um lugar melhor.