A experiência estadunidense US Digital Services Playbook

Quando o site HealthCare.gov foi lançado, em outubro de 2013, a administração Obama tinha um problema grave: ele simplesmente não funcionava.

Levava oito segundos para responder a um clique do mouse. Categorizou por engano menores de Lousiania como se fossem presidiários e, por consequência, inelegíveis para assistência de saúde. Ele quebrava tão frequentemente que, das milhões de pessoas que visitaram a página, praticamente ninguém conseguiu completar o registro39

.

A reforma do sistema de saúde, conhecido como “Patient Protection and Affordable Care Act” ou simplesmente “Obama Care”, era um dos grandes projetos do presidente dos Estados Unidos. Por meio da plataforma era esperado que, entre outubro de 2013 e abril de 2014, mais de oito milhões de pessoas se cadastrassem e contratassem seus planos de saúde. Todo o projeto, que se baseava em grande medida neste serviço digital que conectaria cidadãos e operadoras de planos de saúde, estava ameaçado por um gargalo tecnológico.

Todd Park, CTO40 _{do governo estadunidense, foi chamado e propôs uma solução}

39 “ It took eight seconds to respond to a mouse click. It miscategorized minors in Louisiana as incarcerated prisoners and thus ineligible for health care. It crashed so often that of the millions who came to the site, virtually no one was able to complete an application” America’s Tech Guru Steps Down—But He’s Not Done Rebooting the Government. Disponível em <http://www.wired.com/2014/08/healthcare-gov/>. Acessado em 18/10/2015.

bastante heterodoxa: formar um time com jovens técnicos de startups e grandes empresas do Vale do Silício.

Em 2012, Park havia dado início a um programa chamado “Presidential Innovation Fellows”, que convida pessoas com experiência em tecnologia para uma residência de 6 meses em um projeto específico do governo. Com este programa, que teve mais de setecentos inscritos para as primeiras dezoito vagas abertas, experimentou aplicar melhores práticas do mercado de tecnologia em uma série de projetos da Casa Branca. Quando precisou recrutar, às pressas, um time para salvar healthcare.gov, Park acionou esta rede e montou um time de cerca de sete pessoas que trabalharam sem parar durante pouco menos de dois meses para deixar o serviço funcional.

Quando este time começou a trabalhar, encontrou um cenário curioso. Apesar do estado de alerta, dada a gravidade da situação, as empresas contratadas pareciam estar completamente descoladas da realidade, trabalhando normalmente no desenvolvimento de novas funcionalidades.

Pessoas foram contratadas para trabalhar apenas em discretas partes do quebra-cabeça – as características do website, os protocolos de segurança, os requisitos de acessibilidade e milhares de outros detalhes. Mas nenhum dos contratados teve que lidar com questões gerais de performance, como por exemplo a velocidade com que o website responde uma requisição dos usuários. Nenhum dos contratados ficou responsável até mesmo por garantir que o website era funcional41_.

“Assim que você fizer um desses projetos você irá dividi-los em pedaços e contratar cinco pessoas para trabalhar nele,”42 _{disse Mikey Dickerson, líder do time que acabara de} trabalhar no resgate do projeto. “Eles não estão se ajudando, ninguém se importa com a entrega do projeto, todos eles estão apenas preocupados em quem fechará o próximo contrato. Então tudo que eles fazem é com o intuito de fazer com que os outros contratados pareçam ruins.”43

Além disso, o modelo de desenvolvimento do produto era exatamente o oposto das abordagens enxutas e ágeis. O sucesso alcançado na recuperação do serviço, com um time tão pequeno, em tão pouco tempo, causou impacto no governo por demonstrar que as práticas e metodologias de desenvolvimento que estavam acelerando centenas de empresas no Vale do Silício também poderia ser aplicado a grandes e complexos problemas do Estado, por mais sensíveis que fossem.

41 America’s Tech Guru Steps Down—But He’s Not Done Rebooting the Government. Disponível em <http://www.wired.com/2014/08/healthcare-gov/>. Acessado em 18/10/2015.

42 Ibdem 43 Ibdem

A partir dessa experiência, e inspirado também na experiência britânica do GDS britânico, foi criado o US Digital Service (USDS), para aplicar a mesma abordagem a todos os serviços digitais do governo federal estadunidense. O serviço se apresenta como “um pequeno time formado pelos mais brilhantes talentos da tecnologia do país que trabalharão com as agências para remover as barreiras para a entrega serviços excepcionais e refazer a experiência digital que cidadãos e empresas tem com seus governos44_”.

Para balizar as premissas dessa nova abordagem, o governo americano lançou, ao mesmo tempo, uma cartilha chamada “US Digital Services Playbook”, com as práticas recomendadas de como se desenvolver serviços digitais. Esta cartilha aborda tudo que um gestor deve levar em conta na hora de planejar e desenvolver um serviço digital. Desde o ponto de vista de planejamento global do projeto, como do ponto de vista das metodologias de desenvolvimento de software, citando as metodologias ágeis e as práticas enxutas.

Hoje, muitos dos nossos projetos de serviços digitais não funcionam bem, são entregues com atraso, ou estouram o orçamento. Para aumentar o índice de sucesso destes projetos, o governo dos Estados Unidos precisa de uma nova abordagem. Criamos uma cartilha com 13 passos trazidos de práticas bem-sucedidas do setor privado e do governo que, se seguidos, ajudarão o governo a construir serviços digitais efetivos45_.

A cartilha traz 13 diretrizes, que são apresentadas no Quadro 3 de maneira resumida e em tradução livre. Este quadro resume as melhores práticas adotadas pelo governo estadunidense e nos permite enxergar de maneira clara a abordagem adotada por eles, que é muito semelhante às das “startups” enxutas e do governo britânico.

44 “A small team made up of our country’s brightest digital talent that will work with agencies to remove barriers to exceptional service delivery and help remake the digital experience that people and businesses have with their government.” Delivering a Customer-Focused Government Through Smarter IT. Disponível em

<https://www.whitehouse.gov/blog/2014/08/11/delivering-customer-focused-government-through-smarter-it> . Acessado em 18/10/2015.

45 “Today, too many of our digital services projects do not work well, are delivered late, or are over budget. To increase the success rate of these projects, the U.S. Government needs a new approach. We created a playbook of 13 key “plays” drawn from successful practices from the private sector and government that, if followed together, will help government build effective digital services”. U.S. Digital Services Playbook. Disponível em <https://playbook.cio.gov/>. Acessado em 18/10/2015.

Quadro 3: Cartilha de Serviços Digitais46

1. Entenda o que as pessoas precisam: É preciso ter clareza de quem serão os usuários do serviço e envolvê-los desde os primeiros estágios do processo, para que suas necessidades reais, e a maneira como eles vão usar o serviço na vida real, definam a especificação do projeto. É preciso testar o serviço continuamente com os usuários reais.

2. Se preocupe com o processo todo, do começo ao fim: É preciso entender todas as diferentes maneiras e estágios, online e offline, em que as pessoas vão interagir com o serviço. A partir desta visão completa, desenvolva a parte digital do serviço da maneira que melhor se encaixe no processo.

3. Faça ser simples e intuitivo: O serviço deve ser simples de usar e utilizar uma linguagem familiar aos usuários do serviço.

4. Use práticas ágeis e iterativas: É preciso usar uma abordagem incremental e ágil para o desenvolvimento dos serviços. Lance um “produto mínimo viável” (MVP) em no máximo três meses depois do início do projeto para que o time de designers e desenvolvedores possa ter oportunidade de ajustar o serviço de acordo com o retorno dos usuários. Faça testes de usabilidade com frequência. Lance novas funcionalidades incrementalmente.

5. Estruture o orçamento e os contratos para dar suporte às entregas: É preciso trabalhar com uma pessoa experiente em orçamento e gestão de contratos. Os contratos com fornecedores devem prever pesquisa, prototipagem, evolução do escopo conforme o produto é desenvolvido, análise de soluções em software livre, entregas frequentes, e permitir flexibilidade de contratação de serviços adicionais, como serviços de “cloud computing”.

6. Defina um líder: É preciso haver apenas um “dono do produto” (product owner, parte da metodologia ágil) que terá autoridade para tomar decisões técnicas e de produto. Ele ou ela será responsável por distribuir e priorizar tarefas e garantir que o produto atenda as demandas dos cidadãos. A responsabilidade do sucesso ou fracasso do projeto é deste líder.

7. Forme um time experiente: É preciso trazer para dentro do governo pessoas com experiência em criar serviços digitais modernos. Os fornecedores devem ser capazes de

identificar e recrutar pessoas com essas experiências para colaborarem com o projeto.

8. Escolha um conjunto de tecnologias modernas: O conjunto de ferramentas e softwares escolhido para o projeto devem permitir com que os times trabalhem com eficiência e que os serviços escalem com facilidade e a um preço razoável. Essas escolhas devem evitar amarras com fornecedores específicos. Os times devem considerar utilizar soluções open source e serviços baseados em nuvem (cloud).

9. Implante o serviço em um ambiente flexível: Os serviços devem ser hospedados em ambientes que podem crescer com flexibilidade, permitindo ajustes em tempo real para momentos de pico de acesso.

10. Utilize rotinas de testes e implantação automatizados: Testes automatizados fornecem mais segurança para que seja possível fazer lançamentos frequentes de novas versões do software sem correr o risco de erros já conhecidos e corrigidos voltarem por acidente

11. Administre a segurança e a privacidade por meio de processos reutilizáveis: Os serviços devem proteger informações sensíveis e manter os sistemas seguros. Este é um processo contínuo de manutenção e melhoria. Ao começar a projetar um novo serviço, o líder do projeto deve se reunir com os órgãos legais para discutir que tipo de informação será coletada, como elas serão armazenadas com segurança, por quanto tempo serão mantidas, e como poderão ser utilizadas e compartilhadas. O envolvimento de especialistas em privacidade ajuda a garantir que os dados pessoais estão sendo administrados adequadamente. Deve-se testar e certificar componentes de segurança em todas as camadas do software e, então, reutilizar esses componentes certificados para outros serviços.

12. Use dados para tomar decisões: Em todos os estágios do projeto deve-se medir como o serviço está funcionando para os cidadãos. Isso inclui monitorar a performance do serviço e como as pessoas estão interagindo com ele em tempo real. Por meio da análise desses dados o time deve priorizar quais bugs devem ser corrigidos e quais funcionalidades devem ser desenvolvidas, ou adaptadas. Além de mecanismos automáticos de monitoramento, deve haver um formulário para que os usuários reportem questões diretamente.

13. Aberto por padrão: Ao colaborar de maneira aberta e publicando dados abertos, simplifica-se o acesso do público aos serviços e informações governamentais, permite-se que qualquer pessoa contribua com facilidade e que o código seja reutilizado por empreendedores, organizações não governamentais, outros órgãos do governo, e pelo público em geral.

Apesar das recomendações da cartilha serem bastante diretas, sabia-se que a rigidez das regras de compras (Federal Acquisition Regulation, FAR) seria um obstáculo para os gestores que decidissem implementá-las. Pensando nisso, o USDS lançou um documento complementar chamado TechFAR Handbook, que é um guia para os gestores conseguirem implementar as sugestões apresentadas pela cartilha de acordo com a legislação de compras do governo.

Frequentemente, a falta de orientação encorajando agências a utilizarem práticas inovadoras de contrato resultam em interpretações estreitas e muito rígidas das regras de aquisição e reduzem a habilidade do governo de adotar maneiras mais inteligentes de adquirir serviços digitais de alta qualidade. Este documento guiará agências para contratar serviços de desenvolvimento de software de novas maneiras que dialogam mais proximamente com as práticas modernas de desenvolvimento de

software utilizadas no setor privado47_.

Este guia apresenta vinte e uma orientações diferentes, no formato de perguntas e respostas, e divididas em grandes temas, como “requisitos de desenvolvimento & plano de aquisição”, “uso de contratos de TI existentes”, “considerações sobre precificação”, “uso de competição” e “administração de contrato”.

As recomendações são, evidentemente, bastante específicas para a legislação norte-americana. No entanto, há um ponto que aparece em diversos momentos e sobre o qual é possível trazer uma reflexão para a realidade brasileira: Existe um entendimento de que, nas contratações de soluções de TI, é preciso ter uma especificação bem clara e precisa em relação ao escopo do projeto a ser desenvolvido, no entanto, na abordagem ágil esse escopo é construído e modificado ao longo do projeto. Como conciliar a necessidade de definição do escopo do projeto, para que se possa fiscalizar a execução do contrato, com a natureza de

47 “Too often, the lack of guidance encouraging agency use of innovative contracting practices results in narrow and overly rigid interpretations of federal acquisition rules that complicate the government’s ability to adopt smarter ways of acquiring high-quality digital services. This document will guide agencies in how to procure development services in new ways that more closely match the modern software development techniques used in the private sector”. Delivering Customer Focused Government Through Smarter IT. Disponível em

<https://www.whitehouse.gov/blog/2014/08/11/delivering-customer-focused-government-through-smarter-it> . Acessado em 18/10/2015.

escopo aberto das metodologias ágeis?

A solução apontada para esse dilema é a construção uma “Visão do produto”. Ela não é uma lista exaustiva de funcionalidades, mas sim declaração clara e objetiva de quais problemas devem ser resolvidos, para quem, e quais serão as entregas de valor. Uma visão de produto bem construída, segundo o documento, deve apresentar o cliente da solução, o que e por que ele precisa desta solução, o benefício que a solução trará e uma justificativa de por que esta solução é melhor do que outras alternativas existentes. A partir desta visão, são construídas as “histórias de usuários”, que são descrições das ações que as pessoas serão capazes de realizar na plataforma, são definidos ciclos de desenvolvimento e seus critérios de aceitação.

A visão do produto subsidiará a construção de um orçamento e de um cronograma e deverá ser seguida até o final do contrato, que será dividido em ciclos de desenvolvimento, cada um com seus critérios de aceite próprios.

Nas três primeiras seções deste capítulo conhecemos as melhores práticas adotadas pelo mercado no desenvolvimento de serviços digitais e analisamos como essas práticas foram adotadas pelos governos britânico e estadunidense. A partir da leitura comparada desses quadros, passaremos, a partir da próxima seção, a construção de um quadro próprio, que propões uma série de melhores práticas para serem adotadas pelo governo brasileiro e que servirão de referência para as análises de caso que faremos no próximo capítulo.