Construindo e comprando ótimo software para fabricação de metal

scanrail/iStock/Getty Images Plus

O software está se tornando cada vez mais relevante e crítico para as fábricas modernas. Esteja você desenvolvendo código internamente ou comprando uma ferramenta de terceiros, é importante entender o que você está procurando. Isso pode ser difícil sem um conhecimento profundo de como o software é feito.

Healthcare.gov representa um estudo de caso facilmente acessível sobre os riscos do design de software. Foi lançado há 10 anos e pousou imediatamente com um baque surdo. Foi tão lento e problemático que apenas 1% das pessoas interessadas conseguiram se inscrever na primeira semana. O web design falhou em cumprir o básico absoluto, com fluxos de trabalho ruins e interfaces de usuário problemáticas. Para completar, as seguradoras de saúde recebiam informações imprecisas do site, dificultando ou até mesmo impossibilitando o correto manejo das matrículas.

Os testes de estresse que deveriam ter explorado o volume esperado de usuários foram totalmente inadequados. Um dia antes do lançamento, descobriu-se que o site ficou muito lento, com apenas 1.100 usuários simultâneos. A contagem de usuários esperada era de 50.000 a 60.000. Se isso não bastasse, a contagem real de usuários simultâneos disparou para 250.000 na primeira semana, mais de 200 vezes o número de usuários que os testes de estresse de pré-lançamento indicaram que o site poderia suportar. Em retrospectiva, questiona-se porque é que os testes de esforço foram realizados. Seu claro fracasso não alterou em nada o cronograma de lançamento.

O projeto não tropeçou por falta de orçamento. Foi originalmente estimado em US$ 93,7 milhões, uma quantia impressionante, mesmo que o projeto não ultrapassasse o orçamento. Mas as estimativas estavam totalmente incorretas. Antes da conclusão, o custo total subiu para US$ 1,7 bilhão, de cair o queixo e causar lágrimas, quase 20 vezes maior do que o estimado.

Healthcare.gov funcionou muito bem em 2023, mas no lançamento foi talvez o fiasco de software mais espetacular, caro e público da história. Embora grande parte da complexidade em torno da implementação do Healthcare.gov fosse inevitável, podemos usar a sua implementação malfeita para explorar o que faz os projetos de software terem sucesso ou falharem. Suas falhas podem fornecer informações sobre como você pode construir sua própria equipe interna de software. Também pode fornecer informações sobre o que procurar ao comprar software de terceiros.

Em um artigo anterior, escrevi sobre como a Southwest Airlines desmoronou durante as férias de 2022. Resumindo, a empresa contava com um software de décadas que tornava extremamente difícil lidar com interrupções de agendamento. Os trabalhadores compreenderam o problema, mas os executivos das empresas – isolados do sofrimento operacional diário – não conseguiram durante décadas investir em novas infra-estruturas. Essa falha, combinada com uma tempestade de inverno e a alta demanda sazonal, fez com que toda a empresa paralisasse, deixando dezenas de milhares de pessoas presas na semana do Natal. A própria Southwest estima que o desastre custará à empresa quase mil milhões de dólares. Essa despesa extraordinária poderia ter sido evitada se os decisores estivessem suficientemente próximos dos problemas operacionais para compreender a urgência.

A lição é que um bom software é desenvolvido por equipes próximas. Uma boa proximidade implica duas coisas: primeiro, que a equipe de software esteja intimamente familiarizada com o problema que está tentando resolver; segundo, os desenvolvedores têm proximidade com os resultados produzidos pelo seu software. Dito de outra forma, uma equipe com boa proximidade entende a dor e então usa sua própria ferramenta de software para aliviá-la. Se o software errar o alvo, ou apresentar falhas ou for difícil de usar, os desenvolvedores devem ser os primeiros a descobrir.

Esta é uma área onde o projeto Healthcare.gov certamente falhou. Os desenvolvedores podem ter entendido os problemas para os quais seu site foi projetado para resolver, mas o contratante principal operava no Canadá, e não nos Estados Unidos, o país que o Healthcare.gov atende. Diferentes componentes do sistema completo também foram cedidos a muitos subcontratados, nenhum dos quais seria proprietário da aplicação completa. Mesmo que os desenvolvedores entendessem o problema que o software pretendia resolver, a experiência do usuário de ponta a ponta estaria firmemente fora do controle de qualquer desenvolvedor de software individual.