HealthCare.gov: o que salvou o site não foi só colocar mais gente

Caso real e público. A Hábil não participou do HealthCare.gov. Nós o analisamos a partir dos relatórios do governo dos Estados Unidos e da imprensa; as fontes estão no final.

É meia-noite de 1º de outubro de 2013. O pessoal terceirizado que opera o sistema de contas e identidade do HealthCare.gov vê o site entrar no ar. Ele acaba de abrir, e por ele milhões de pessoas devem comparar e contratar um seguro de saúde. Um deles se lembraria assim diante dos auditores: «Estávamos sentados no escritório à meia-noite quando começou a rodar, e não parecia nada bem. Tudo estava ficando vermelho nas nossas telas» (tradução própria) [1].

Naquele dia chegaram ao site 250.000 usuários ao mesmo tempo, muitas vezes mais do que o planejado. As quedas começaram duas horas depois da abertura. No fim do dia, segundo o relatório do Inspetor-Geral do Departamento de Saúde dos Estados Unidos, só seis pessoas conseguiram enviar uma solicitação e escolher um plano [1].

Seis. No site que devia atender milhões de pessoas em 36 estados [1].

Esta é a história de como esse site se recuperou em cerca de dois meses. Não a conto pela política nem pelo seguro de saúde. Conto-a porque qualquer diretor de tecnologia já esteve, em escala menor, na mesma sala: um sistema que não pode falhar, uma data que não se move e alguém à mesa dizendo «vamos colocar mais gente». O interessante do caso é que isso já tinha sido tentado, e sozinho não bastou. O site se recuperou quando, além de somar gente, mudou a forma de trabalhar: um núcleo pequeno de engenheiros experientes, integrado em uma única mesa com a agência e os fornecedores, métricas do sistema inteiro e prioridades cortadas sem dó. Os auditores apontam várias causas, não uma só [1].

Setenta e duas horas antes

O problema não começou em 1º de outubro. Os auditores do governo o rastreiam anos para trás. O Inspetor-Geral (OIG, o escritório que audita o Departamento de Saúde) entrevistou 86 funcionários e fornecedores e revisou milhares de documentos. A conclusão principal cabe em uma linha: o mais grave foi a ausência de uma liderança clara, que atrasou decisões, deixou tarefas mal definidas e impediu enxergar o tamanho do problema enquanto ele crescia [1].

Os últimos dias antes do lançamento parecem escritos para um filme.

Em 24 de setembro, a responsável pela segurança da informação da agência que construía o site (CMS, os Centros de Serviços do Medicare e do Medicaid) advertiu que uma peça central não cumpria razoavelmente os requisitos de segurança. No dia 27, em vez de uma permissão normal, a Administradora do CMS assinou uma autorização provisória para operar por seis meses [1].

Em 26 de setembro, a menos de cinco dias da estreia, técnicos do CMS fizeram testes de carga e descobriram que o site suportava muito menos usuários simultâneos do que o planejado. Foram de carro direto aos escritórios do fornecedor de infraestrutura e pediram que ele dobrasse toda a capacidade em 72 horas. Um gerente do fornecedor contou assim: «O pedido era dobrar tudo a 72 horas do lançamento. […] Alugamos aviões para trazer equipamento que estava destinado a outros clientes» (tradução própria) [1].

Em 29 de setembro, o sistema de contas e identidade, a porta pela qual cada usuário devia passar, sofreu quedas. Nesse mesmo dia, a Administradora do CMS escreveu ao diretor de tecnologia dos Estados Unidos que o site estaria pronto em 1º de outubro [1].

Há um detalhe que o relatório destaca e que vale para qualquer empresa: várias pessoas da equipe acreditavam que a data do site estava na lei. Não estava. A lei exigia que a cobertura começasse até 1º de janeiro de 2014 e deixava ao Departamento de Saúde fixar o período de inscrição, que por regulamentação começou em 1º de outubro de 2013 [1]. Somava-se a isso a política: a Casa Branca tinha se comprometido publicamente com essa data, e no Departamento temia-se que um atraso desse argumentos a quem buscava revogar a lei no Congresso [1]. A data que ninguém se atrevia a mover não vinha da lei, e sim de uma regulamentação e da política. E ninguém na direção do CMS discutiu formalmente movê-la [1].

E mais um: não houve testes completos de ponta a ponta. Um fornecedor resumiu para os auditores: «Os testes de ponta a ponta são críticos. Não fazê-los é suicídio» (tradução própria) [1].

Já se tinha tentado somar gente

Aqui está o dado que quase ninguém conta sobre o caso.

Em agosto de 2013, dois meses antes do lançamento, o CMS viu que o projeto estava muito atrasado e reagiu como quase qualquer organização reagiria: designou temporariamente mais 60 pessoas de outras áreas para se somar às 51 que já trabalhavam no site. Um aumento de 117% [1].

Não foi suficiente. O próprio relatório registra o que alguns dos envolvidos sentiram: que já era tarde para envolver outros, pela curva de aprendizado íngreme, e que tinham vergonha de «colocar outros em uma bagunça» (tradução própria) [1].

Em 1975, Frederick P. Brooks Jr., que tinha dirigido o desenvolvimento do sistema operacional OS/360 na IBM, escreveu em The Mythical Man-Month uma frase hoje conhecida como a lei de Brooks: «Adicionar pessoal a um projeto de software atrasado o atrasa ainda mais» (tradução própria) [5]. O raciocínio dele: o trabalho não se divide em pedaços independentes, cada pessoa nova precisa que alguém lhe explique, e os canais de comunicação crescem mais rápido que a equipe.

Convém ser preciso. O relatório do OIG não cita Brooks, e não se pode afirmar que essas 60 pessoas atrasaram o site. O que ele documenta é que somá-las tarde, sem uma liderança clara e sobre um projeto desorganizado, não evitou o desfecho. A relação com Brooks é minha, e a ofereço como leitura, não como achado dos auditores.

Duas semanas às cegas

Depois de 1º de outubro, a primeira reação também foi mandar mais gente. Em poucos dias, pessoal do CMS e do fornecedor principal se instalou na central de comando do fornecedor em Herndon, Virgínia, e outros fornecedores foram se juntando [1].

Mas havia um problema de fundo: ninguém via o sistema inteiro. Cada fornecedor vigiava a própria peça e não conseguia ver as demais, embora todas trabalhassem juntas. Havia várias «centrais de comando» em lugares diferentes, uma em Herndon e outra em Columbia, Maryland, cada uma com as próprias ferramentas, e nenhum líder ou equipe com visão do sistema inteiro e autoridade para agir. Ninguém atuava formalmente como integrador de sistemas [1].

Um dos engenheiros que chegariam depois disse isso em uma conferência em 2014: «Não havia onde ver se o site estava no ar ou não, a não ser a CNN, que foi literalmente como ficamos sabendo dos problemas boa parte do tempo no começo» (tradução própria) [1].

Para complicar ainda mais, na manhã do lançamento o governo federal fechou por falta de orçamento. A paralisação durou 16 dias, e o pessoal dos escritórios-chave do projeto foi reduzido a cerca de um terço [1].

Enquanto isso, o site quase não inscrevia ninguém. Segundo a TIME, em todo o mês de outubro 26.794 pessoas se inscreveram pelo mercado federal [4]. E a capacidade real, segundo um membro da equipe que depois o consertou, era de «talvez alguns milhares de usuários» (tradução própria), quando o número oficial falava em 50.000 [4].

17 de outubro: remendar ou jogar fora?

Em 17 de outubro, segundo a reconstituição do jornalista Steven Brill na TIME, discutia-se na Casa Branca se valia a pena consertar o site ou descartá-lo e começar do zero [4]. Nesse dia, Todd Park, então diretor de tecnologia da Casa Branca, mudou de trabalho sem mudar de escritório: «Em 17 de outubro, passei de CTO da Casa Branca a consertador do HealthCare.gov em tempo integral» (tradução própria) [4].

Park recrutou um grupo de engenheiros que não tinham participado da construção. O OIG os descreve como «vários líderes e engenheiros das principais empresas de tecnologia» (tradução própria) [1]. Entre eles estava Mikey Dickerson, engenheiro de confiabilidade de sites no Google, ou seja, alguém cujo trabalho diário era fazer com que um site enorme não caísse [4]. Um detalhe do relatório diz muito sobre como chegaram: em grande parte doaram o próprio tempo, embora, pelas regras de contratação do governo, tenham sido pagos por hora por meio de um dos fornecedores [1].

A primeira coisa que fizeram não foi programar correções. Foi medir. Na noite da sexta-feira, 18 de outubro, segundo a TIME, Gabriel Burt, diretor de tecnologia de uma empresa de análise de dados, e outros passaram cerca de cinco horas montando um painel, porque o site não tinha uma forma rápida de saber o que estava acontecendo [4]. Com esse painel encontraram uma das primeiras correções rápidas: na noite de 22 de outubro, o tempo de carregamento de uma página caiu de oito segundos para dois [4].

Nesse mesmo 22 de outubro, a Secretária de Saúde anunciou publicamente o que chamou de «tech surge», uma onda tecnológica: Jeff Zients, administrador com experiência em dirigir empresas, juntava-se como assessor de gestão, com «especialistas» do governo, dos fornecedores e da indústria, «incluindo veteranos das principais empresas do Vale do Silício» e «um punhado» de integrantes do programa Presidential Innovation Fellows da Casa Branca (tradução própria) [3].

Primeira decisão importante, tomada com esse grupo: refatorar o código existente, não reconstruir do zero. Começar de novo teria custado um tempo que não havia, e o pessoal da agência e dos fornecedores estava disposto a trabalhar com os recém-chegados [1].

A sala de Columbia

No fim de outubro, a central de comando se mudou para uma sala de uns 370 metros quadrados (4.000 pés quadrados) que um dos fornecedores alugava em um parque de escritórios em Columbia, Maryland [4]. Com o tempo, ela se tornaria o centro de operações formal do site [1].

Dickerson convocou a primeira reunião em pé em 24 de outubro. A partir daí, todos os dias, inclusive nos fins de semana, durante outubro e novembro: às 10h e às 18h30, cerca de 45 minutos cada uma, com uma linha telefônica aberta 24 horas para que quem trabalhava em outro lugar pudesse falar com os demais assim que surgisse algo [4].

As regras, ele as colou em uma parede, do lado de fora da sala de controle. A TIME as reproduz [4]:

1. «A sala e as reuniões são para resolver problemas. Há muitos outros lugares onde as pessoas dedicam a energia criativa a jogar a culpa nos outros» (tradução própria).
2. «Quem deve falar são as pessoas que mais sabem de um assunto, não as de maior cargo» (tradução própria).
3. «É preciso se concentrar no mais urgente, como o que vai nos ferir nas próximas 24 a 48 horas» (tradução própria).

O relatório do OIG descreve a mesma mudança com outras palavras. Adotou-se uma cultura «sem crachá e sem cargo» (tradução própria): as tarefas eram atribuídas por habilidade e disponibilidade, sem importar se a pessoa era funcionária do governo ou de qualquer fornecedor [1]. Pela primeira vez, a equipe técnica e a de políticas do programa trabalhavam juntas. Um dos engenheiros descreveu assim: «Tínhamos o pessoal de políticas decifrando as mensagens de erro. O que o código fazia ou não fazia? O que deveria acontecer?» (tradução própria) [1]. E a agência contratou um integrador técnico de sistemas, alguém cujo trabalho era fazer com que todas as peças conversassem entre si. Segundo o relatório, isso melhorou a coordenação «na opinião de todos» (tradução própria) [1].

Há uma frase de um funcionário do CMS, registrada pelos auditores, que resume o caso melhor do que qualquer análise: «O CMS não precisava de uma onda tecnológica; precisávamos de uma onda organizacional» (tradução própria) [1].

E a pressão para colocar mais gente? Continuava lá. Brill conta assim: Zients tinha «carta branca para adicionar recursos», mas pôr dez pessoas em uma correção que um programador levaria dez dias para fazer não a transforma em um projeto de um dia. «Programar não funciona assim» (tradução própria) [4].

O relógio de novembro

Em 25 de outubro, Zients fixou publicamente uma meta: o site funcionaria bem para a grande maioria dos usuários no fim de novembro [1]. Os líderes técnicos da sala disseram depois aos auditores que não foram consultados sobre essa data [1].

O caminho até essa meta foi duro. No fim de outubro, duas falhas no equipamento do fornecedor de infraestrutura deixaram o site fora do ar por 24 e 36 horas [1]. Alguns dormiram em hotéis próximos e trabalharam em turnos de 24 horas [1]. «Foram dias sombrios», disse um funcionário (tradução própria) [1].

Mas os números começaram a se mexer. Segundo o relatório do CMS de 1º de dezembro, citado pelo OIG, o tempo em que o site estava funcionando passou de 42% no início de novembro para mais de 90% no fim de novembro [1]. (A TIME reportou 43% e 95% [4]; uso o número do relatório oficial.) Em 1º de dezembro, o site aguentava mais de 35.000 usuários simultâneos sem cair, segundo o OIG; a TIME falou em pelo menos 50.000 [1][4]. Agora havia painéis de desempenho do sistema inteiro e, quando a carga transbordava, uma «sala de espera» que pedia ao usuário que aguardasse ou deixasse o e-mail [1].

O prazo para ter cobertura em 1º de janeiro foi estendido de 15 para 24 de dezembro. No último dia, o site recebeu 49.156 usuários simultâneos, segundo o OIG [1]; a TIME reportou um pico maior, de 83.000, em 23 de dezembro [4]. Em 28 de dezembro, cerca de 1,2 milhão de pessoas tinham escolhido um plano pelo HealthCare.gov [1]. Ao fechar o primeiro período de inscrição, 5,4 milhões de pessoas tinham escolhido um plano no mercado federal [1].

De seis pessoas no primeiro dia a mais de um milhão em dezembro.

O que custou

O resgate não apagou a conta. O OIG relata que seis contratos-chave foram estimados no início em 464 milhões de dólares e, no começo de 2014, já eram calculados em 824 milhões; o do sistema central passou de 58 para 207 milhões [1]. O Escritório de Prestação de Contas do governo (GAO) concluiu que o site foi lançado sem verificar se cumpria os requisitos de desempenho, e que as obrigações do contrato do sistema central cresceram de 56 para mais de 209 milhões entre setembro de 2011 e fevereiro de 2014 [2].

Em janeiro de 2014, o CMS trocou de fornecedor principal. O fornecedor que saía, diz o OIG, ficou sabendo pelo Washington Post, dias antes da chegada do novo [1].

O que este caso ensina

1. Somar gente não basta, e às vezes atrapalha

Houve duas ondas de gente. A de agosto de 2013, mais 60 pessoas sobre um projeto sem liderança clara, não evitou o desastre [1]. A de outubro, que também somou pessoal da agência, dos fornecedores e do setor privado, a maior parte em três semanas [1], fez parte da recuperação, porque chegou acompanhada de liderança, métricas, integração e prioridades claras [1]. O caso não permite atribuir o resultado a um único fator.

Sejamos honestos com o dado: o resgate não foi feito com menos gente. Foi feito com gente diferente, organizada de outra forma. A diferença não esteve no número, e sim em quem chegou, como se integrou e com que instrumentos trabalhou. Brooks tinha razão no que advertiu, mas o caso não diz «nunca adicione pessoas». Diz: não espere que o número resolva o que a organização não resolve.

2. Um núcleo pequeno, experiente e integrado

O núcleo que chegou em meados de outubro era pequeno: «vários» engenheiros, segundo o OIG; «um punhado» de integrantes desse programa da Casa Branca, segundo o anúncio oficial [1][3]. Não chegaram para fazer o trabalho de todos. Chegaram com experiência em sites que não caem, sentaram-se com os engenheiros dos fornecedores, que já conheciam o código, e os dirigiram. A TIME fala de «dezenas» de engenheiros, dispostos e até entusiasmados, que esse núcleo coordenou (tradução própria) [4].

Esse núcleo foi uma peça, não a explicação inteira. Entre os fatores-chave da recuperação, o OIG destaca que todo o pessoal do CMS e dos fornecedores tenha trabalhado como uma única equipe, sem crachá, e uma «priorização implacável» (tradução própria) que alinhou o trabalho às metas mais importantes e alcançáveis [1].

A palavra-chave é integrado. Sem crachá e sem cargo: quem sabe, fala; quem pode, assume a tarefa. Um engenheiro externo que chega para «auditar» de fora acrescenta uma camada. Um que se senta na mesma sala, com as mesmas regras, tira uma.

3. Medir antes de consertar

A primeira coisa foi um painel montado em uma noite [4]. Antes disso, a melhor fonte para saber se o site estava no ar era a televisão [1]. Sem métricas, cada pessoa nova opina; com métricas, cada pessoa nova ataca o que o painel aponta.

4. Uma única mesa, com regras

Não mais uma reunião diária, e sim a reunião: uma única sala, dois cortes por dia, 45 minutos, uma linha aberta permanente e três regras na parede [4]. Discute-se o que dói nas próximas 24 a 48 horas, fala quem sabe e não se buscam culpados. É o oposto de várias centrais de comando que não se enxergam [1].

5. Alguém responsável por fazer tudo conversar

Antes do lançamento, ninguém atuava como integrador de sistemas e cada fornecedor olhava a própria peça [1]. No resgate, a agência contratou um [1]. Quando um sistema é feito de muitas peças e muitos fornecedores, alguém tem de ser dono das junções. Se ninguém for, o problema mora exatamente ali.

6. A data que ninguém move merece uma pergunta

A data de 1º de outubro não era fixada pela lei: saiu de uma regulamentação e era sustentada por um compromisso político, e ninguém discutiu formalmente movê-la [1]. Antes de somar gente para chegar a uma data, vale a pena perguntar quem a fixou, o que acontece se ela for movida e qual é o mínimo que deve funcionar nesse dia.

Aplicação: dois engenheiros-chave a menos antes do Buen Fin

Cenário (ilustrativo, sem cliente nem caso real). Aplico as lições do HealthCare.gov a uma situação que muitos diretores no México reconhecerão.

É setembro. O comércio eletrônico da empresa se prepara para o Buen Fin, o fim de semana de novembro em que se concentra boa parte das vendas do ano. Em uma mesma quinzena, pedem demissão os dois engenheiros que melhor conhecem a integração entre a loja, o estoque e os pagamentos. Restam sete semanas.

A reação natural é a de agosto de 2013: «vamos contratar cinco». As lições do caso sugerem outra ordem:

1. Primeiro, medir. Antes que eles saiam, peça uma sessão para deixar à vista o que só eles viam: que alertas revisavam, que painéis, que processos reiniciavam à mão. Se não existir um painel do fluxo de compra completo (da loja ao pagamento e ao estoque), esse é o primeiro entregável, não o último.
2. Depois, somar poucos e experientes. Não cinco perfis genéricos que é preciso treinar a sete semanas da alta temporada. Um ou dois engenheiros que já tenham trabalhado em integrações parecidas e em temporadas de alto volume, que a equipe da empresa possa entrevistar antes de começar.
3. Integrá-los, não designá-los. Que entrem com as contas da empresa, nos repositórios dela, no horário dela e nas reuniões dela. Sem «equipe do fornecedor» e «equipe da casa»: uma única mesa.
4. Uma reunião curta, com regras. Dois cortes por dia nas semanas anteriores, focados no que pode derrubar as vendas nas próximas 48 horas.
5. Cortar sem dó. O que não for indispensável para vender, cobrar e entregar nesse fim de semana fica para depois.
6. Revisar a data de cada mudança, não a do Buen Fin. Essa não se move. Mas a do redesenho do carrinho, a do novo gateway de pagamento ou a da migração do catálogo, talvez sim.

Posto assim, o Buen Fin não se ganha com mais gente. Ganha-se com a gente certa, a tempo e sentada à mesma mesa.

Cinco perguntas para o próximo comitê

1. Se amanhã saírem os dois engenheiros que mais sabem das nossas integrações, o que deixa de funcionar, e alguém mais sabe disso?
2. Temos um painel do fluxo completo que importa ao negócio, ou cada área vigia só a própria peça?
3. Quem é dono das junções entre os nossos sistemas e os nossos fornecedores?
4. Quando somamos pessoas a um projeto atrasado, quanto tempo levam para ser úteis, e quem as integra?
5. As datas que «não podem ser movidas» estão em um contrato, em uma lei ou em uma apresentação?

Se duas ou mais respostas forem «não sei», ali pode estar o próximo outubro da empresa.

O que a Hábil faz quando falta conhecimento crítico

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006, que soma engenheiros seniores a equipes de empresas no México e nos Estados Unidos. Não mandamos «mais gente»: apresentamos perfis com experiência em integração, nuvem e sistemas regulados que a empresa entrevista e valida antes de começar, e que trabalham dentro dos controles dela: com a identidade da empresa, nos repositórios dela e em uma janela diária de horário compartilhado com a equipe.

É possível começar com um ou dois engenheiros que se integram à equipe, com uma célula que nós coordenamos ou com um projeto de escopo fechado. Veja a página Somar engenheiros à equipe.

Peça a primeira conversa, sem custo. Ela parte do que a empresa precisa sustentar ou construir, de qual perfil convém e em que forma de trabalho. Escreva-nos pelo WhatsApp.

Perguntas frequentes

O que foi o «tech surge» do HealthCare.gov?

Foi o nome que o Departamento de Saúde dos Estados Unidos deu, em 22 de outubro de 2013, ao reforço para consertar o site: um assessor de gestão, Jeff Zients, e especialistas do governo, dos fornecedores e de empresas de tecnologia [3]. O núcleo técnico foi recrutado pela Casa Branca com engenheiros que não tinham construído o site [1].

Quanto tempo levou o resgate?

O OIG conclui que o CMS recuperou o site para uso intenso em cerca de dois meses: a meta de melhoria foi cumprida em 1º de dezembro de 2013 [1].

O que diz a lei de Brooks?

Em tradução livre: «Adicionar pessoal a um projeto de software atrasado o atrasa ainda mais» (tradução própria). Vem do livro The Mythical Man-Month, de Frederick P. Brooks Jr., publicado em 1975 [5]. É uma advertência, não uma proibição: o custo está no tempo que leva integrar cada pessoa e na comunicação que se multiplica.

Então nunca convém somar engenheiros a um projeto atrasado?

O caso não diz isso. Em outubro de 2013 somou-se gente e o site se recuperou, mas essa gente chegou com experiência, integrou-se em uma única mesa sem distinção de empregador e trabalhou com métricas e prioridades cortadas [1][4]. O caso não permite atribuir o resultado a um único fator. O que não bastou foi somar sem liderança nem visibilidade [1].

A Hábil participou do caso HealthCare.gov?

Não. É um caso público, documentado pelo governo dos Estados Unidos e pela imprensa. Nós o usamos porque as lições dele se aplicam a qualquer equipe que sustenta um sistema que não pode falhar.

Quanto tempo um engenheiro da Hábil leva para se integrar à minha equipe?

Depende de três coisas: o perfil de que a empresa precisa, as entrevistas com que a equipe o valida e o tempo que a empresa leva para lhe dar contas e acessos aos repositórios. Na primeira conversa definimos o perfil e indicamos quão cedo pode começar no contexto da empresa.

As citações foram traduzidas do inglês. Os números são os que cada fonte reporta; quando duas fontes não coincidem, o texto diz isso e usa a oficial.