O seu trabalho é feito com qualidade? « Agile Way


18 de Março de 2010

O seu trabalho é feito com qualidade?

Sabe aquele papo de que nossas atitudes podem gerar consequências inimagináveis? Pois este post irá discutir um pouco sobre isso. Vamos falar sobre QUALIDADE, e como a mais simples falta de cuidado com o seu trabalho hoje, pode gerar resultados devastadores para outras pessoas.

A imagem acima não é meramente ilustrativa. É apenas a prova de que uma das empresas mais celebradas quando o quesito é qualidade e execução (afinal de contas, colocar um robô tripulado em Marte não é lá tão fácil!) pode cometer erros devastadores. Em ambos os casos, por mais laudos que tenham sido emitidos, o erro foi de qualidade. E mais ainda: por falha humana. Conheça a seguir outros dois casos para você repensar um pouco a sua forma de trabalho.

THERAC 25 – RADIOTERAPIA – 1985-1987

A radioterapia é um tratamento contra o câncer para controlar as células malígnas evitando sua disseminação pelo corpo do paciente. Normalmente utilizado como terapia primária, este procedimento ganhou as manchetes em meados dos anos 80.

A empresa canadense Atomic Energy of Canada Limited (AECL) produziu um equipamento de radioterapia chamado Therac 25. Ele seria o sucessor do Therac 6 e Therac 20, anteriormente desenvolvidos em parceria com uma empresa francesa.

A nova máquina oferecia dois modos de terapia: DEB (direct electron-beam therapy) e MXR (Megavolt X-ray therapy), ambas com dosagens variadas mas que não passavam de 25 MeV (eletronVolt).

Quando operada no modo DEB, a máquina produzia pequenas doses de impulsos de eletrons que eram emitidos diretamente.

No caso do MXR, a máquina foi desenvolvida para rotacionar quatro componentes no feixe de eletrons emitido: um alvo (target) que convertia os eletrons em raios-x; um filtro que fazia com que o feixe se espalhasse por uma área maior; um colimador que dava formas aos raios-x e uma camara ionica, que media a potência do feixe.

Durante sessões de tratamento com o MXR, por motivos mecânicos ou mesmo por falhas humanas, um dos quatro componentes (o filtro) não se encontrava pronto para o uso. Porém, ainda assim, o sistema continuava a operação, simplesmente ignorando esta falha.

O resultado foi que o feixe que deveria ser espalhado por uma área maior, reduzindo sua potência, era concentrado em um único ponto. Pelo menos seis pacientes receberam uma dose 100 vezes maior do que o recomendado. A dor causada pelo feixe os fazia sair correndo pelos corredores, gritando. Pelo menos três pacientes morreram em decorrência das consequências deste procedimento.

Mesmo com este problema, o equipamento ficou em uso de 1985 a 1987, fazendo não só com que seis pacientes sofressem graves problemas, mas também atordoando a opinião pública sobre como este problema não foi detectado antes.

Uma comissão posteriormente concluiu que a empresa canadense não deu atenção necessária ao código do equipamento. O software sequer foi revisado depois de pronto. Também não foi considerado como deveria, durante o desenvolvimento do hardware (e suas constantes mudanças). Os erros causados pelo equipamento eram tratados de forma pobre pelo sistema, e pior: mesmo sendo um erro grave, ainda dava a opção de continuar com o procedimento. O equipamento, ainda, sequer havia sido testado anteriormente em um ambiente hospitalar! E os treinamentos eram meramente básicos e sem o suporte necessário.

Mais uma série de problemas (de software e hardware) foram identificados, mas o fato de um equipamento de alto risco ter sido desenvolvido de forma tão amadora causou uma preocupação enorme nas pessoas.

ARIANE 5 – VÔO 501 – JUNHO 1996

Ariane 5 é o nome de um foguete espacial não tripulado, desenvolvido pela Agência Espacial Européia em 1995. O seu objetivo primário é levar satélites e demais artefatos para a órbita terrestre, em muitos casos para realizar estudos científicos.

Foi grande um investimento europeu na faixa de sete bilhão de dólares durante sete anos, que visava tornar o continente mais sólido na corrida espacial (muito embora essa corrida tenha perdido a força com o fim da Guerra Fria).

Desenvolvido para ser mais moderno do que o seu antecessor, Ariane 4, o modelo 5 é utilizado até hoje tendo realizado aproximadamente 50 vôos oficiais.

A sua história, no entanto, é composta por um dos maiores erros de desenvolvimento de software da recente história da humanidade.

Quatro de Junho de 1996, base de lançamento na Guiana Francesa. Após sete longos anos de desenvolvimento, a Agência Européia estava pronta para realizar o lançamento do seu mais novo protótipo chamado Ariane 5. Havia muita ansiedade no local, pois aquele foguete representaria uma revolução na modernização da Agência.

O Ariane 5 reutilizou boa parte das especificações do seu sucessor, embora não fosse derivado diretamente dele. Dentre estas reutilizações estava boa parte da estrutura de software.

O problema era que o caminho de vôo do Ariane 5 era consideravelmente diferente e envolvia cálculos e coordenadas muito mais sensíveis e precisas do que fora utilizado até então.

Estava tudo pronto. “Ariane 5 Vôo 501″ estava aprovado. Seriam quatro satélites lançados com sua ajuda. O lançamento foi feito. O foguete Ariane 5 sobe em grande aceleração rumo a órbita terrestre. Por volta de 35 segundos após o seu lançamento, o foguete sai completamente do seu percurso causando sérios danos na aerodinâmica estrutural. O sistema de auto-destruição do foguete é acionado automaticamente e aos 37 segundos ele se desintegra completamente.

Não houve perda de vidas, mas o foguete e seus quatro satélites geraram uma perda estimada em 500 milhões de dólares. Sem contar os anos de pesquisas que cada satélite continha.

Qual foi o motivo deste desastre? O software.

Como mencionado, o Ariane 5 era consideravelmente diferente do seu antecessor. Ainda assim diversos módulos foram reaproveitados, incluindo o software. O Ariane 5 iria atingir cálculos de coordenadas muito mais sensíveis do que seu antecessor. Isso o tornaria extremamente preciso em suas entregas. Os testes realizados em laboratório não identificaram qualquer problema com relação a esta reutilização. Estimava-se, inclusive, um considerável ganho financeiro e de tempo com a reutilização.

O erro fatal foi ocorrido após uma conversão numérica de dados de um valor de ponto flutuante de 64 bits para um valor inteiro de 16 bits. Para aqueles que não são familiarizados com informática, seria como tentar encaixar um elefante em uma caixa de fósforos, ou, caso você queira entender, tente multiplicar 99999999 por 99999999 na sua calculadora comum: o resultado será um estouro aritmético, exatamente o erro que foi produzido pelo sistema. Em consequencia, levou a um erro no hardware controlador. Que gerou a uma série de eventos em cascata que culminaram com a ativação do dispositivo de auto-destruição do Ariane 5 (felizmente ESTE dispositivo funcionou, caso contrário o foguete teria caido em pedaços em terra).

CONCLUSÕES

O caso do Ariane 5 e do Therac-25 (e dos ônibus espaciais Columbia e Challenger que ilustram a introdução do artigo), levaram a discussão do risco de se utilizar softwares para o controle de sistemas críticos. Um nos anos 80. Outro nos anos 90. O caso da Toyota (que será discutido em um artigo futuro) pode representar a nova discussão para a atual década. Notem como o assunto é recorrente.

No final de 1998, a NASA também cometeu um erro de software no seu módulo Mars Climate Orbiter, que resultou na destruição do aparelho assim que ele chegou em Marte. Novamente por falta de qualidade no software.

Não importa se o problema é no software, no hardware ou na estrutura. Não importa se houve um rompimento parcial do metal inoxidável das comportas ou se foi um estouro aritmético. A causa raiz sempre será PESSOAS.

Até que ponto as empresas contratadas e as pessoas envolvidas neste desenvolvimento se preocupam necessariamente com a qualidade do que vai ser entregue?

Dizem que a qualidade está diretamente associada ao valor agregado do produto. De fato, existe uma grande diferença entre o Windows gerar uma tela azul e você perder um documento, e um sistema de piloto-automático de um Boing gerar um erro e fazê-lo descer em queda livre.

Mas muitas empresas de hoje em dia tem se preocupado cada vez menos com qualidade e testes. Até mesmo empresas que criam cargos e comites especiais para isso (Quality Assurance Comitee, Tester Leader, etc.) continuam deixando para testar  seu produto lá no final do projeto. E se der tempo. Pois o conceito de valor, para estas empresas, é apenas entregar (e se livrar) do produto.

Além disso, atente ao fato de que pessoas insatisfeitas produzem trabalhos insatisfatórios. Mas isso é repetido tanto aqui neste blog, que não vale repetir (até porque não caberia tudo).

O que falta para as empresas deixarem a qualidade e a satisfação (e segurança) do cliente realmente em primeiro lugar? Quantos casos você conhece neste sentido? Não é a hora de mudar a mentalidade?

No fim das contas, lembre-se que há uma grande semelhança nestes dois casos com a sua empresa: os clientes que usam o seu produto esperam que ele funcione.

Veja alguns vídeos dos acidentes que ilustram esse artigo. Eles reforçam a mensagem.

Mars Climate Orbiter (animação)

Ariane 5 – Vôo 501

Reentrada da Columbia

E o mais impressionante: a explosão da Challenger



5 Comentários para “O seu trabalho é feito com qualidade?”

  1. Salo diz:

    Thex, dá uma lida no livro CAIXA-PRETA, autor Ivan Santana. Ele relata 3 desastres aéreos brasileiros. Um deles chama atenção. O acidente com o Boeing da Varig em Paris, 1973. O avião pegou começou a pegar fogo na fase final de descida, já em procedimento de aproximação à pista de Orly. As causas? um incêndio no banheiro, provavelmente causado por uma bituca de cigarro. Mas o que mais impressionou foi a velocidade com que as chamas se espalharam pela cabine, devido a um erro de projeto, o material usado no revestimento interno do jato era altamente inflamável.

  2. Flávio,

    O problema é que há pessoas que pensam que testes é preciso só em projetos grandes, ou de software críticos. Quando na verdade, os testes devem ser uma tarefa natural dentro do desenvolvimento de software.

    E as pessoas que gostam de apenas entregar o mais rápido possível, para obter o pagamento do cliente, são as mesmas que ficam apagando incêndios depois, tendo que ficar dando manutenção “eterna”, e assim acabam perdendo um tempo que poderia ser gasto no desenvolvimento de novos produtos.

    Parabéns por mais essa excelente análise!!!

    Abraços!

  3. [...] O seu trabalho é feito com qualidade? – Flávio Steffens (Agile Way); [...]

  4. [...] de dólares em prejuízo e a perda de vidas por causa de falhas, como ocorreu por exemplo no THERAC 25.  Além disso a palestrante deixou uma mensagem muito importante, a de que precisamos aprender com [...]

  5. [...] Você faz seu trabalho com qualidade? Casos onde isso não aconteceu. (Interessante) [...]

Comentar