• Habilidades Inteligentes

Se você tem um projeto complexo, siga a “lei de Gall” — ou ele falhará

• O lançamento do Healthcare.gov em 2013 - o site de troca de seguros de saúde vinculado ao Affordable Care Act - foi amplamente considerado desastroso.
• O sucesso pode ter sido baseado na observação fundamental de que sistemas complexos funcionais surgem de sistemas simples funcionais.
• A maioria dos projetos de tecnologia do governo provavelmente poderia custar 10% do que realmente custam, mas ainda fornecer 85% da funcionalidade.

Após o desastre do Healthcare.gov em 2013, zagueiros de todos os cantos apresentaram suas razões para o fracasso. Alguns pensaram que os Centros de Serviços Medicare e Medicaid (CMS) gastaram seu orçamento muito lentamente. Outros disseram que o problema era que a CMS havia tentado ser seu próprio “integrador de sistemas” e deveria ter cobrado da CGI Federal – empresa líder no Healthcare.gov, o site que administrava as trocas de seguros de saúde exigidas pelo Affordable Care Act – de retirar todos os as peças juntas. Outros ainda achavam que a CGI e as dezenas de outros fornecedores envolvidos eram o verdadeiro problema. (De fato, a ausência de funcionalidade verdadeiramente básica, como software de monitoramento de sites, sugere algumas deficiências sérias da parte deles.)

Um relatório do Gabinete do Inspetor-Geral oferece dez razões principais para o desastre, abrangendo tudo, desde a falta de liderança clara e uma cultura excessivamente burocrática até falhas de integração, comunicação, execução e supervisão. O relatório é completo, mas esse é um diagnóstico amplo. Se eu tivesse que escolher apenas uma coisa que talvez, apenas talvez, tivesse feito a diferença, seria esta: o site tinha muitos gerentes de projeto, mas nenhum gerente de produto.

Com toda a disfunção catalogada pelo inspetor-geral circulando, o que um gerente de produto poderia ter feito pelo Healthcare.gov? Em uma palavra, menos.

Healthcare.gov foi um empreendimento verdadeiramente massivo. Não permitia apenas que as pessoas comprassem e escolhessem planos de seguro. Ele precisava se comunicar com dezenas de outros bancos de dados do governo para verificar a renda da pessoa, número do Seguro Social, status de cidadania e se a pessoa estava inscrita em algum outro programa de saúde; tinha que garantir que o inscrito recebesse a quantia certa pela cobertura; e tinha que transmitir inscrito dados para centenas de seguradoras diferentes. O site não apenas precisava ser dimensionado para lidar com um tráfego enorme, mas dezenas de conexões precisavam funcionar perfeitamente para que qualquer transação fosse realizada.

Em qualquer serviço como este, você encontrará um núcleo de usuários cujas circunstâncias são as mais comuns e uma longa cauda de “casos extremos” cada vez mais raros. Por exemplo, o Affordable Care Act geralmente estende a cobertura apenas aos candidatos que são cidadãos dos EUA. Mas existem 17 status de imigração únicos que são exceções a essa regra, e as pessoas que essas exceções abrangem representam uma pequena fração dos usuários. A programação na lógica e nas conexões de banco de dados para verificar automaticamente todas as 17 exceções torna as ordens de magnitude do software mais complexas do que seria necessário para suportar o tipo mais comum de usuário. As pessoas com casos extremos poderiam inicialmente ter sido ajudadas por outros canais, incluindo call centers e vários agentes e assistentes que poderiam atender os clientes pessoalmente. Mike Byrne, o cara que construiu o mapa de banda larga para a Federal Communications Commission (FCC), estima que a maioria dos projetos de tecnologia do governo pode custar 10% do que custam e ainda fornecer 85% da funcionalidade. Eu chamo isso de “Lei de Byrne”.

Não é que esses 15% finais da funcionalidade não devam ser construídos - o software pode e deve eventualmente suportar casos extremos. É só que tentar fazer tudo antes do lançamento, antes que você tenha a chance de resolver os problemas com o funcionamento principal do projeto, muitas vezes atrapalha a operação dos outros 85%. A estimativa moderna de Mike ressoa com uma observação de 1975 conhecida como Lei de Gall, batizada em homenagem ao pediatra e teórico de design de sistemas John Gall. “Um sistema complexo que funciona invariavelmente evoluiu de um sistema simples que funcionou”, escreveu Gall. “Um sistema complexo projetado do zero nunca funciona e não pode ser corrigido para fazê-lo funcionar. Você tem que começar de novo com um sistema simples e funcional.” Como o CMS tentou criar algo muito complexo que funcionou para todos desde o lançamento, o Healthcare.gov não funcionou para ninguém. Todos lotaram o call center e os atendentes presenciais. Esses canais de alto contato deveriam ter sido reservados principalmente para pessoas com casos incomuns, sem acesso à Internet e outros que precisavam de ajuda extra, mas, em vez disso, estavam lotados de casos que o software poderia facilmente resolver.

Teoricamente, o CMS poderia ter seguido a Lei de Gall: limitou a funcionalidade do site para lançamento, planejou suporte de call center para pessoas cujas circunstâncias o site não poderia lidar e, conforme os recursos permitidos, adicionou suporte on-line de forma incremental para os casos extremos após lançar. Na prática, no entanto, o Congresso ordenou um site totalmente funcional, portanto, um site totalmente funcional era o que o CMS tinha para oferecer. Os gerentes de projeto tinham todos os seus requisitos para verificar. A ideia de que algumas escolhas poderiam ser feitas, e de fato precisariam ser feitas, era indescritível, talvez impensável. Muitos consideraram qualquer coisa, exceto as nove jardas, ilegais. Clay Shirky descreve estar na Harvard Kennedy School, uma das principais instituições de políticas públicas do país, um mês após o lançamento do Healthcare.gov e ser informado de que o site simplesmente não poderia ter sido construído e testado iterativamente ao longo do tempo porque não é assim que o governo funciona. “É difícil para o pessoal da política imaginar que o HealthCare.gov poderia ter uma implementação em fases, mesmo enquanto está tendo uma”, escreveu ele na época. Correções incrementais é exatamente o que a agência conseguiu, apenas da pior maneira possível.

Compartilhar: