você já ouviu falar sobre o desaparecimento do armazém? Um dia, desapareceu—não do ponto de vista físico, mas dos olhos atentos do sistema de distribuição automatizado de um conhecido varejista. Uma falha de software de alguma forma apagou a existência do armazém, de modo que as mercadorias destinadas ao armazém foram redirecionadas para outro lugar, enquanto as mercadorias no armazém definhavam. Como a empresa estava com problemas financeiros e estava fechando outros armazéns para economizar dinheiro, os funcionários do armazém “desaparecido” ficaram calados. Por três anos, nada chegou ou saiu. Os funcionários ainda estavam recebendo seus contracheques, no entanto, porque um sistema de computador diferente lidava com a folha de pagamento. Quando a falha do software finalmente veio à tona, a mercadoria no armazém foi vendida e a alta administração disse aos funcionários para não dizerem nada sobre o episódio.
esta história tem flutuado em torno da indústria de tecnologia da informação por 20-alguns anos. Provavelmente é apócrifo, mas para aqueles de nós no negócio, é totalmente plausível. Por quê? Porque episódios como esse acontecem o tempo todo. Em outubro passado, por exemplo, a gigante varejista britânica de alimentos J Sainsbury PLC teve que cancelar seu investimento de US $526 milhões em um sistema automatizado de gerenciamento da cadeia de suprimentos. Parece que a mercadoria estava presa nos depósitos e armazéns da empresa e não estava chegando a muitas de suas lojas. Sainsbury foi forçado a contratar cerca de 3000 funcionários adicionais para estocar suas prateleiras manualmente .
este é apenas um dos mais recentes de uma longa e sombria história de projetos de TI que deram errado . A maioria dos especialistas em TI concorda que tais falhas ocorrem com muito mais frequência do que deveriam. Além disso, as falhas são universalmente sem preconceitos: acontecem em todos os países; para grandes empresas e pequenas; em organizações comerciais, sem fins lucrativos e governamentais; e sem levar em conta o status ou a reputação. Os custos comerciais e sociais dessas falhas—em termos de desperdício de dólares dos contribuintes e dos acionistas, bem como investimentos que não podem ser feitos—estão agora na casa dos bilhões de dólares por ano.
o problema só piora à medida que se torna onipresente. Este ano, organizações e governos gastarão cerca de US $1 trilhão em hardware, software e serviços de TI em todo o mundo. Dos projetos de TI iniciados, de 5 a 15% serão abandonados antes ou logo após o parto como irremediavelmente inadequados. Muitos outros chegarão atrasados e acima do orçamento ou exigirão retrabalho maciço. Poucos projetos de TI, em outras palavras, realmente têm sucesso.
a maior tragédia é que a falha de software é, na maioria das vezes, previsível e evitável. Infelizmente, a maioria das organizações não vê a prevenção do fracasso como um assunto urgente, embora essa visão arrisque prejudicar a organização e talvez até destruí-la. Entender por que essa atitude persiste não é apenas um exercício acadêmico; tem enormes implicações para os negócios e a sociedade.
SOFTWARE ESTÁ EM TODA PARTE. É o que nos permite obter dinheiro de um Caixa eletrônico, fazer um telefonema e dirigir nossos carros. Um celular típico agora contém 2 milhões de linhas de código de software; em 2010, provavelmente terá 10 vezes mais. General Motors Corp. estima-se que até então seus carros terão cada um 100 milhões de linhas de código.
a empresa média gasta cerca de 4 a 5% da receita em tecnologia da informação, com aqueles que são altamente dependentes de TI—como empresas financeiras e de telecomunicações—gastando mais de 10% nela. Em outras palavras, agora é uma das maiores despesas corporativas fora dos custos dos funcionários. Muito desse dinheiro vai para atualizações de hardware e software, taxas de licença de software e assim por diante, mas um grande pedaço é para novos projetos de software destinados a criar um futuro melhor para a organização e seus clientes. Governos também são grandes consumidores de software. Em 2003, o Reino Unido tinha mais de 100 grandes projetos de TI do governo em andamento que totalizaram US $20,3 bilhões. Em 2004, o governo dos EUA catalogou 1200 projetos civis de TI que custavam mais de US $60 bilhões, além de outros US $16 bilhões para software Militar.
qualquer um desses projetos pode custar mais de US $ 1 bilhão. Para dar dois exemplos atuais, o esforço de modernização de computadores no departamento de assuntos de Veteranos dos EUA deverá custar US $3,5 bilhões, enquanto a automação dos registros de saúde do Serviço Nacional de saúde do Reino Unido provavelmente custará mais de US $14,3 bilhões para desenvolvimento e outros us $50,8 bilhões para implantação.
esses projetos megasoftware, antes raros, agora são muito mais comuns, pois operações de TI menores são unidas em “sistemas de sistemas.”O controle de tráfego aéreo é um excelente exemplo, porque depende de conexões entre dezenas de redes que fornecem comunicações, clima, navegação e outros dados. Mas o truque da integração impediu muitos desenvolvedores de TI, a ponto de os pesquisadores acadêmicos acreditarem cada vez mais que a própria ciência da computação pode precisar ser repensada à luz desses sistemas maciçamente complexos.
quando um projeto falha, ele põe em risco as perspectivas de uma organização. Se o fracasso for grande o suficiente, ele pode roubar todo o futuro da empresa. Em um colapso estelar, um sistema de planejamento de recursos mal implementado levou a FoxMeyer Drug Co. uma empresa de distribuição de medicamentos por atacado de US $ 5 bilhões em Carrollton, Texas, para cair em falência em 1996.
falha de TI no governo pode pôr em perigo a segurança nacional, como o desastre de arquivo de caso Virtual do FBI mostrou. O sistema VCF de US $170 milhões, um banco de dados pesquisável destinado a permitir que os agentes “conectem os pontos” e acompanhem informações diferentes, terminou há cinco meses sem que nenhum sistema seja implantado .
falhas de TI também podem prejudicar o crescimento econômico e a qualidade de vida. Em 1981, a Administração Federal de Aviação dos EUA começou a procurar atualizar seu antiquado sistema de controle de tráfego aéreo, mas o esforço para construir uma substituição logo se tornou crivado de problemas . Em 1994, quando a Agência finalmente desistiu do projeto, o custo previsto triplicou, mais de US $2,6 bilhões foram gastos e a data de entrega esperada caiu vários anos. Todo passageiro de avião que está atrasado por causa de passagens aéreas bloqueadas ainda sente esse cancelamento; o impacto econômico cumulativo de todos esses atrasos apenas nas companhias aéreas dos EUA (não importa os passageiros) se aproxima de US $50 bilhões. Em todo o mundo, é difícil dizer quantos projetos de software falham ou quanto dinheiro é desperdiçado como resultado. Se você definir falha como o abandono total de um projeto antes ou logo após a entrega, e se você aceitar uma taxa de falha conservadora de 5 por cento, então bilhões de dólares são desperdiçados a cada ano em software ruim.
por exemplo, em 2004, os EUA o governo gastou US $ 60 bilhões em software (sem contar o software incorporado em sistemas de armas); uma taxa de falha de 5% significa que US $3 bilhões provavelmente foram desperdiçados. No entanto, depois de várias décadas como consultor de TI, estou convencido de que a taxa de falha é de 15 a 20% para projetos com orçamentos de US $10 milhões ou mais. Olhando para o investimento total em novos projetos de software—tanto governamentais quanto corporativos—nos últimos cinco anos, estimo que as falhas do projeto provavelmente custaram à economia dos EUA pelo menos US $25 bilhões e talvez até US $75 bilhões. É claro que US $ 75 bilhões não refletem projetos que excedam seus orçamentos—o que a maioria dos projetos faz. Também não reflete projetos entregues tardiamente-que são a maioria. Ele também não leva em conta os custos de oportunidade de ter que recomeçar uma vez que um projeto é abandonado ou os custos de sistemas com bugs que precisam ser repetidamente retrabalhados.
então, também, há o custo do litígio de clientes irados processando fornecedores por sistemas mal implementados. Quando você soma todos esses custos extras, a guia anual para software falhado e problemático corre conservadoramente de US $60 bilhões para US $70 bilhões apenas nos Estados Unidos. Por esse dinheiro, você poderia lançar o ônibus espacial 100 vezes, construir e implantar todo o sistema de posicionamento global de 24 satélites e desenvolver o Boeing 777 do zero-e ainda ter alguns bilhões restantes.
por que os projetos falham com tanta frequência?
entre os fatores mais comuns:
- Irrealistas ou latentes objetivos do projeto
- Imprecisas, estimativas de recursos necessários,
- Mal definidos os requisitos do sistema
- Pobre relatório do projeto do estado
- não gerenciado riscos
- falta de comunicação entre clientes, desenvolvedores, e os usuários
- Uso de tecnologia imatura
- Incapacidade de lidar com a complexidade do projeto
- Desleixado práticas de desenvolvimento
- Má gestão do projecto
- Participantes política
- pressões Comerciais
De curso, projetos de TI raramente falha por apenas uma ou duas razões. O projeto VCF do FBI sofreu com muitos dos problemas listados acima. A maioria das falhas, de fato, pode ser atribuída a uma combinação de decisões técnicas, de gerenciamento de projetos e de negócios. Cada dimensão interage com os outros de maneiras complicadas que exacerbam os riscos e problemas do projeto e aumentam a probabilidade de falha.
considere uma tarefa simples de software: um sistema de compras que automatiza o pedido, faturamento e envio de peças, para que um vendedor possa inserir o pedido de um cliente, verificá-lo automaticamente em relação aos requisitos de preços e contratos e providenciar o envio das peças e da fatura ao Cliente do armazém.
os requisitos para o sistema especificam quatro etapas básicas. Primeiro, há o processo de vendas, que cria uma fatura de venda. Essa fatura é então enviada por meio de um processo legal, que analisa os Termos e condições contratuais da venda potencial e os aprova. O terceiro em linha é o processo de provisão, que envia as peças contratadas, seguido pelo processo financeiro, que envia uma fatura. Digamos que, como o primeiro processo, para vendas, está sendo escrito, os programadores tratam todos os pedidos como se fossem colocados no local principal da empresa, embora a empresa tenha filiais em vários estados e países. Esse erro, por sua vez, afeta como o imposto é calculado, que tipo de contrato é emitido e assim por diante.
quanto mais cedo a omissão for detectada e Corrigida, melhor. É como tricotar um suéter. Se você detectar um ponto perdido logo depois de fazê-lo, você pode simplesmente desvendar um pouco de fio e seguir em frente. Mas se você não pegar o erro até o final, pode ser necessário desvendar todo o suéter apenas para refazer esse ponto.
se os codificadores de software não pegarem sua omissão até o teste final do sistema—ou pior, até que o sistema tenha sido implementado—os custos incorridos para corrigir o erro provavelmente serão muitas vezes maiores do que se eles tivessem pego o erro enquanto ainda estavam trabalhando no processo inicial de vendas.
e ao contrário de um ponto perdido em um suéter, esse problema é muito mais difícil de identificar; os programadores verão apenas que os erros estão aparecendo e podem ter várias causas. Mesmo depois que o erro original for corrigido, eles precisarão alterar outros cálculos e documentação e, em seguida, testar novamente cada etapa. De fato, estudos mostraram que os especialistas em software gastam cerca de 40 a 50% de seu tempo em retrabalho evitável, em vez do que chamam de trabalho de Valor Agregado, que é basicamente o trabalho que é feito da primeira vez. Uma vez que um software entra em campo, o custo de corrigir um erro pode ser 100 vezes maior do que seria durante o estágio de desenvolvimento.
se houver erros, o retrabalho pode começar a inundar um projeto, como um bote em uma tempestade. O que é pior, as tentativas de corrigir um erro geralmente introduzem novos. É como se você estivesse resgatando aquele bote, mas também está criando vazamentos. Se forem produzidos muitos erros, o custo e o tempo necessários para concluir o sistema tornam-se tão grandes que continuar não faz sentido.
nos termos mais simples, um projeto de TI geralmente falha quando o retrabalho excede o trabalho de valor agregado para o qual foi orçado. Foi o que aconteceu com a Sydney Water Corp., A maior fornecedora de água da Austrália, quando tentou introduzir um sistema automatizado de informações e faturamento do cliente em 2002 . De acordo com uma investigação do Auditor Geral Australiano, entre os fatores que condenaram o projeto estavam o planejamento e as especificações inadequados, O que, por sua vez, levou a inúmeras solicitações de mudança e custos e atrasos adicionais significativos. Sydney Water abortou o projeto no meio do caminho, depois de gastar R $61 milhões (US $ 33,2 milhões).
tudo o que nos leva à pergunta óbvia: por que tantos erros ocorrem?
falhas de projeto de Software têm muito em comum com acidentes de avião. Assim como os pilotos nunca pretendem falhar, os desenvolvedores de software não pretendem falhar. Quando um avião comercial cai, os investigadores analisam muitos fatores, como o clima, registros de manutenção, disposição e treinamento do piloto e fatores culturais dentro da companhia aérea. Da mesma forma, precisamos olhar para o ambiente de negócios, gerenciamento técnico, gerenciamento de projetos e cultura organizacional para chegar às raízes das falhas de software.
entre os principais fatores de negócios estão a concorrência e a necessidade de cortar custos. Cada vez mais, os gerentes seniores esperam que os departamentos de TI façam mais com menos e o façam mais rápido do que antes; eles veem os projetos de software não como investimentos, mas como custos puros que devem ser controlados. Exigências políticas também podem causar estragos no cronograma, custo e qualidade de um projeto de TI. Quando o Aeroporto Internacional de Denver tentou lançar seu sistema automatizado de manuseio de bagagem, os líderes políticos estaduais e locais mantiveram o projeto em um cronograma irrealista após o outro. A falha em entregar o sistema a tempo atrasou a abertura do aeroporto em 1995 (então o maior dos Estados Unidos), o que agravou o impacto financeiro muitíssimo.
mesmo depois que o sistema foi concluído, ele nunca funcionou de forma confiável: mastigou a bagagem e os carrinhos usados para transportar a bagagem frequentemente descarrilavam. Eventualmente, a United Airlines, principal inquilino do aeroporto, processou o empreiteiro do sistema, e o episódio se tornou um testemunho dos perigos da conveniência política.
a falta de apoio da alta administração também pode prejudicar uma empresa de TI. Isso evita a falta de alocação de dinheiro e mão de obra suficientes para não estabelecer claramente a relação do projeto de TI com os negócios da organização. Em 2000, a varejista Kmart Corp., em Troy, Michigan., lançou um $1.4 bilhões de esforços de modernização de TI destinados a vincular seus sistemas de vendas, marketing, fornecimento e logística, para competir melhor com a rival Wal-Mart Corp., em Bentonville, Ark. O Wal-Mart provou ser muito formidável, porém, e 18 meses depois, o Kmart sem dinheiro reduziu a modernização, anulando os US $130 milhões que já havia investido nele. Quatro meses depois, declarou falência; a empresa continua a lutar hoje.
frequentemente, gerentes de projeto de TI ansiosos para obter financiamento recorrer a uma forma de poker do mentiroso, prometendo o que seu projeto vai fazer, quanto vai custar, e quando ele será concluído. Muitos, se não a maioria, projetos de software começam com orçamentos muito pequenos. Quando isso acontece, os desenvolvedores precisam compensar o déficit de alguma forma, normalmente tentando aumentar a produtividade, reduzindo o escopo do esforço ou tomando atalhos arriscados nas fases de revisão e teste. Tudo isso aumenta a probabilidade de erro e, em última análise, falha.
um sistema de reserva de viagens de última geração liderado por um consórcio de Budget Rent-A-Car, Hilton Hotels, Marriott e AMR, pai da American Airlines, é um caso em questão. Em 1992, três anos e meio e US $165 milhões no projeto, o grupo o abandonou, citando duas razões principais: um cronograma de desenvolvimento excessivamente otimista e uma subestimação das dificuldades técnicas envolvidas. Este foi o mesmo grupo que havia construído anteriormente o sistema de reservas sabre de enorme sucesso, provando que o desempenho passado não é garantia de resultados futuros. Depois que os investigadores consideram o clima como um fator em um acidente de avião, eles olham para o próprio avião. Havia algo no projeto do avião que causou o acidente? Estava carregando muito peso?
em falhas de projeto de TI, questões semelhantes invariavelmente surgem em relação aos componentes técnicos do projeto: o hardware e o software usados para desenvolver o sistema e as próprias práticas de desenvolvimento. As organizações são muitas vezes seduzidas pela canção sirene do imperativo tecnológico—o desejo incontrolável de usar a mais recente tecnologia na esperança de ganhar uma vantagem competitiva. Com a tecnologia mudando rapidamente e prometendo novas capacidades fantásticas, é fácil sucumbir. Mas usar tecnologia imatura ou não testada é um caminho certo para o fracasso. Em 1997, depois de gastar US $40 milhões, o estado de Washington fechou um projeto de TI que teria processado Carteiras de motorista e registros de veículos. Funcionários de veículos motorizados admitiram que foram apanhados em perseguir a tecnologia em vez de se concentrarem na implementação de um sistema que atendesse às suas necessidades. O desastre de TI que derrubou a droga FoxMeyer um ano antes também resultou da adoção de um sistema de planejamento de recursos de última geração e, em seguida, empurrando-o além do que poderia fazer de forma viável.
o tamanho de um projeto é uma fonte de fracasso. Estudos indicam que projetos em grande escala falham de três a cinco vezes mais do que os pequenos. Quanto maior o projeto, mais complexidade há em seus elementos estáticos (as peças discretas de software, hardware e assim por diante) e seus elementos dinâmicos (Os acoplamentos e interações entre hardware, software e usuários; conexões com outros sistemas; e assim por diante). Maior complexidade aumenta a possibilidade de erros, porque ninguém realmente entende todas as partes interagentes do todo ou tem a capacidade de testá-las.
sóbrio, mas verdadeiro: é impossível testar completamente um sistema de TI de qualquer tamanho real. Roger S. Pressman apontou em seu livro Engenharia de Software, um dos textos clássicos da área, que “testes exaustivos apresentam certos problemas logísticos….Mesmo um pequeno programa de 100 linhas com alguns caminhos aninhados e um único loop executando menos de vinte vezes pode exigir 10 à potência de 14 caminhos possíveis para serem executados.”Para testar todos esses 100 trilhões de caminhos, ele observou, supondo que cada um pudesse ser avaliado em um milissegundo, levaria 3170 anos. Todos os sistemas de TI são intrinsecamente frágeis. Em um grande edifício de tijolos, você teria que remover centenas de tijolos estrategicamente colocados para fazer um colapso da parede. Mas em um programa de software de 100.000 linhas, são necessárias apenas uma ou duas linhas ruins para produzir grandes problemas. Em 1991, uma parte da rede telefônica da ATandamp;T saiu, deixando 12 milhões de assinantes sem serviço, tudo por causa de um único caractere digitado incorretamente em uma linha de código.
as práticas de desenvolvimento desleixadas são uma rica fonte de falha e podem causar erros em qualquer estágio de um projeto de TI. Para ajudar as organizações a avaliar suas práticas de desenvolvimento de software, OS EUA O Software Engineering Institute, em Pittsburgh, criou o Capability Maturity Model, ou CMM. Ele classifica as práticas de uma empresa em cinco níveis de maturidade crescente. Nível 1 significa que a organização está usando práticas de desenvolvimento ad hoc e possivelmente caóticas. Nível 3 significa que a empresa caracterizou suas práticas e agora as entende. Nível 5 significa que a organização compreende quantitativamente as variações nos processos e práticas que aplica.
em janeiro, quase 2000 organizações governamentais e comerciais relataram voluntariamente os níveis de CMM. Mais da metade reconheceu estar no nível 1 ou 2, 30% estavam no nível 3 e apenas 17% haviam atingido o Nível 4 ou 5. As porcentagens são ainda mais sombrias quando você percebe que este é um grupo auto-selecionado; obviamente, as empresas com as piores práticas de TI não se submeterão a uma avaliação CMM. (O CMM está sendo substituído pelo CMM-Integration, que visa uma avaliação mais ampla da capacidade de uma organização de criar sistemas intensivos em software.)
práticas imaturas de TI condenaram os EUA O esforço de modernização de US $ 4 bilhões do Internal Revenue Service em 1997, e eles continuaram a atormentar a atual modernização de US $8 bilhões do IRS. Pode ser intrinsecamente impossível traduzir o código tributário em código de software—a lei tributária é complexa e baseada em legislação frequentemente vaga, e muda o tempo todo. Do ponto de vista de um desenvolvedor de TI, é um pesadelo de requisitos. Mas o IRS não foi ajudado pela hostilidade aberta entre programadores internos e externos, uma subestimação ridícula do trabalho envolvido e muitas outras práticas ruins. As ações do piloto pouco antes de um acidente de avião são sempre de grande interesse para os investigadores. Isso porque o piloto é o tomador de decisão final, responsável pela operação segura da embarcação. Da mesma forma, os gerentes de projeto desempenham um papel crucial em projetos de software e podem ser uma importante fonte de erros que levam ao fracasso.
em 1986, a bolsa de valores de Londres decidiu automatizar seu sistema de liquidação de transações de ações. Sete anos depois, depois de gastar US $ 600 milhões, ele descartou o desenvolvimento do sistema Taurus, não apenas porque o design era excessivamente complexo e complicado, mas também porque a gestão do projeto era, para usar a palavra de um de seus próprios gerentes seniores, “delirante.”Como as investigações revelaram, ninguém parecia querer saber o verdadeiro status do projeto, mesmo quando mais e mais problemas apareciam, os prazos eram perdidos e os custos disparavam .
a função mais importante do gerente de projetos de TI é alocar recursos para várias atividades. Além disso, o gerente de projeto é responsável pelo planejamento e estimativa de projetos, controle, organização, gerenciamento de contratos, gerenciamento de qualidade, gerenciamento de riscos, comunicações e gerenciamento de Recursos Humanos. As más decisões dos gerentes de projeto são provavelmente a maior causa de falhas de software hoje. A má gestão técnica, por outro lado, pode levar a erros técnicos, mas geralmente podem ser isolados e corrigidos. No entanto, uma má decisão de gerenciamento de projetos—como contratar poucos programadores ou escolher o tipo errado de contrato—pode causar estragos. Por exemplo, os desenvolvedores do condenado sistema de reservas de viagens afirmam que foram prejudicados em parte pelo uso de um contrato de preço fixo. Tal contrato pressupõe que o trabalho será rotineiro; o sistema de reservas acabou sendo tudo menos. As decisões de gerenciamento de projetos são muitas vezes complicadas precisamente porque envolvem compensações baseadas em conhecimento difuso ou incompleto. Estimar quanto custará um projeto de TI e quanto tempo levará é tanto arte quanto ciência. Quanto maior ou mais novo O projeto, menos precisas são as estimativas. É uma piada corrente na indústria que as estimativas de projetos de TI estão, na melhor das hipóteses, dentro de 25% de seu verdadeiro valor, 75% do tempo.
existem outras maneiras pelas quais o mau gerenciamento de projetos pode acelerar a morte de um projeto de software. Um estudo do Project Management Institute, em Newton Square, Pa., mostrou que o gerenciamento de riscos é o menos praticado de todas as disciplinas de gerenciamento de projetos em todos os setores da indústria, e em nenhum lugar é aplicado com mais frequência do que no setor de TI. Sem um gerenciamento eficaz de Riscos, os desenvolvedores de software têm poucas informações sobre o que pode dar errado, por que pode dar errado e o que pode ser feito para eliminar ou mitigar os riscos. Também não há uma maneira de determinar quais riscos são aceitáveis, por sua vez, tomar decisões de projeto em relação a compensações quase impossíveis.
a má gestão de projetos assume muitas outras formas, incluindo a má comunicação, o que cria uma atmosfera inóspita que aumenta a rotatividade; não investir em treinamento de pessoal; e não revisar o progresso do projeto em intervalos regulares. Qualquer um deles pode ajudar a descarrilar um projeto de software.
a última área que os investigadores examinam após um acidente de avião é o ambiente organizacional. A companhia aérea tem uma forte cultura de segurança ou enfatiza o cumprimento do cronograma de voos acima de tudo? Em projetos de TI, uma organização que valoriza a abertura, a honestidade, A comunicação e a colaboração está mais apta a encontrar e resolver erros com antecedência suficiente para que o retrabalho não se torne esmagador.
se há um tema que percorre a história torturada de software ruim, é uma falha em enfrentar a realidade. Em várias ocasiões, o inspetor geral do Departamento de Justiça dos EUA, um painel externo de especialistas, e outros disseram ao chefe do FBI que o sistema VCF era impossível conforme definido, e ainda assim o projeto continuou de qualquer maneira. As mesmas atitudes existiam entre os responsáveis pelo sistema de reservas de viagens, o sistema Taurus da Bolsa de valores de Londres e o projeto de controle de tráfego aéreo da FAA-todos indicativos de culturas organizacionais impulsionadas pelo medo e arrogância.
um relatório recente do National Audit Office no Reino Unido descobriu que vários casos de projetos de TI do Governo estão sendo recomendados para não avançar ainda continuando de qualquer maneira. O Reino Unido até tem um departamento do governo encarregado de evitar falhas de TI, mas, como observou o relatório, mais da metade das agências supervisionadas pelo departamento ignora rotineiramente seus conselhos. Eu chamo esse tipo de escalonamento de projeto irracional de comportamento—a incapacidade de parar um projeto mesmo depois que é óbvio que a probabilidade de sucesso está se aproximando rapidamente de zero. Infelizmente, esse comportamento não é de forma alguma único.
Em última análise , as grandes falhas de software tendem a assemelhar-se a pior concebível acidente de avião, onde o piloto era inexperiente, mas muito erupção cutânea, voou em uma tempestade de gelo em um testados aviões, e trabalhou para uma companhia aérea que deu o serviço de bordo para a segurança durante o corte na formação e manutenção. Se você ler o relatório do investigador depois, você estaria balançando a cabeça e perguntando: “tal acidente não era inevitável? Portanto, também as razões pelas quais os projetos de software falham são bem conhecidas e foram amplamente documentadas em inúmeros artigos, relatórios e livros . E, no entanto, falhas, quase falhas e software ruim simples e antigo continuam a nos atormentar, enquanto práticas conhecidas para evitar erros são evitadas. Parece que obter software de qualidade a tempo e dentro do orçamento não é uma prioridade urgente na maioria das organizações.
não parecia estar na Oxford Health Plans Inc., em Trumbull, Conn., em 1997. O sistema de faturamento automatizado da empresa era vital para seus resultados e, no entanto, os gerentes seniores estavam mais interessados em expandir os negócios da Oxford do que em garantir que seu sistema de faturamento pudesse atender às suas necessidades atuais . Mesmo com o surgimento de problemas, como o envio de faturas com meses de atraso, os gerentes prestaram pouca atenção. Quando o sistema de faturamento efetivamente entrou em colapso, a empresa perdeu dezenas de milhões de dólares, e suas ações caíram de US $68 para US $26 por ação em um dia, eliminando US $3,4 bilhões em valor corporativo. Os acionistas entraram com ações judiciais e várias agências governamentais investigaram a empresa, que acabou sendo multada em US $3 milhões por violações regulatórias. Mesmo as organizações que são queimadas por más experiências de software parecem incapazes ou não querem aprender com seus erros. Em um relatório de 2000, o Conselho de Ciência da Defesa dos EUA, um órgão consultivo do Departamento de Defesa, observou que vários estudos encomendados pelo DOD fizeram 134 recomendações para melhorar seu desenvolvimento de software, mas apenas 21 dessas recomendações foram cumpridas. Os outros 113 ainda eram válidos, observou o conselho, mas estavam sendo ignorados, mesmo quando o DOD reclamou do mau estado de desenvolvimento de software de defesa!
algumas organizações se preocupam com a qualidade do software, como prova a experiência da Empresa de desenvolvimento de software Praxis High Integrity Systems, em Bath, Inglaterra. A Praxis exige que seus clientes estejam comprometidos com o projeto, não apenas financeiramente, mas como participantes ativos na criação do sistema de TI. A empresa também gasta uma quantidade enorme de tempo entendendo e definindo os requisitos do cliente, e desafia os clientes a explicar o que eles querem e por quê. Antes que uma única linha de código seja escrita, o cliente e a práxis concordam com o que é desejado, o que é viável e quais riscos estão envolvidos, dados os recursos disponíveis.
depois disso, a Praxis aplica uma abordagem de desenvolvimento rigorosa que limita o número de erros. Uma das grandes vantagens deste modelo é que ele filtra a muitos clientes dispostos a aceitar a responsabilidade de articular os seus requisitos de TI e gastar o tempo e dinheiro para implementá-las corretamente.
algum nível de falha de software estará sempre conosco. De fato, precisamos de verdadeiros fracassos—em oposição a erros evitáveis—para continuar fazendo progresso técnico e econômico. Mas muitas das falhas que ocorrem hoje são evitáveis. E à medida que nossa sociedade passa a confiar em sistemas de TI cada vez maiores, mais integrados e mais caros, o custo do fracasso pode se tornar desastrosamente alto.
mesmo agora, é possível fazer apostas sobre onde o próximo grande desastre de software ocorrerá. Um dos meus principais candidatos são os sistemas de TI que resultarão da American Health Information Community do governo dos EUA, uma colaboração público-privada que busca definir padrões de dados para registros médicos eletrônicos. A ideia é que, uma vez definidos os padrões, os sistemas de TI serão construídos para permitir que profissionais médicos em todo o país entrem nos registros dos pacientes digitalmente, dando aos médicos, hospitais, seguradoras e outros especialistas em Saúde acesso instantâneo ao histórico médico completo de um paciente. Especialistas em saúde acreditam que esse sistema de sistemas melhorará o atendimento ao paciente, reduzirá os custos em cerca de US $78 bilhões por ano e reduzirá os erros médicos, salvando dezenas de milhares de vidas.
mas essa abordagem é um mero sonho se as práticas de software e as taxas de falha permanecerem como são hoje. Mesmo pelas estimativas mais otimistas, criar um sistema de registro médico eletrônico exigirá 10 anos de esforço, US $320 bilhões em custos de desenvolvimento e US $20 bilhões por ano em despesas operacionais—supondo que não haja falhas, excessos, deslizamentos de cronograma, problemas de segurança ou software de má qualidade. Este não é um cenário realista, especialmente porque a maioria dos especialistas em TI considera a comunidade médica a menos experiente em informática de todas as empresas profissionais.
pacientes e contribuintes acabarão por pagar o preço pelo desenvolvimento, ou o fracasso, de boondoggles como este. Dadas as práticas atuais de TI, o fracasso é uma possibilidade distinta e seria uma perda de magnitude sem precedentes. Mas então, países em todo o mundo estão contemplando ou já trabalhando em muitas iniciativas de tamanho e impacto semelhantes—na aviação, segurança nacional e militares, entre outras arenas. Como eletricidade, água, transporte e outras partes críticas de nossa infraestrutura, ela está rapidamente se tornando intrínseca à nossa existência diária. Em algumas décadas, uma falha de TI em grande escala se tornará mais do que apenas um inconveniente caro: isso colocará nosso modo de vida em risco. Na ausência do tipo de mudanças em todo o setor que mitigarão as falhas de software, quanto do nosso futuro estamos dispostos a apostar nesses sistemas extremamente caros e complexos?
já sabemos como fazer o software bem. Pode finalmente ser hora de agir de acordo com o que sabemos.