Transformação Digital

O orçamento publicado em março de 2012 (2012 budget), colocava a ambição de posicionar o Reino Unido como polo tecnológico da Europa. Dessa maneira, eles esperavam economizar de 1,7 a 1,8 bilhão de libras por ano29_{. Para isso, além de iniciativas de incentivo} ao mercado, previa:

[O governo] vai transformar a qualidade dos serviços digitais se comprometendo que, a partir de 2014, novos serviços online só serão publicados se o ministro responsável conseguir demonstrar que ele mesmo consegue utilizar o serviço com sucesso. O governo também se certificará que toda informação é publicada em um único domínio 'gov.uk' até o fim de 2012 e mudará para uma abordagem 'digital por padrão' em seus serviços transacionais até 201530

. (tradução nossa)

Por “digital por padrão”, definem: “serviços digitais que são tão fáceis de usar e convenientes que todos aqueles que tiverem possibilidade irão preferir utilizá-los, enquanto quem não puder não será excluído”31_,

Ainda em junho de 2012, foi lançada o plano de reforma do serviço público (civil service reform), que também trazia a migração para serviços digitais como uma prioridade.

O público cada vez mais espera ser capaz de acessar os serviços de forma rápida e conveniente, no tempo e da forma como lhes é mais adequada, e o Civil Service deve anteder a esta expectativa em vez de esperar que os cidadãos se adéquem aos processos do Civil Services. Ele precisa se tornar digital por padrão em suas habilidades, em seu estilo, na forma como se comunica e permite com que as 29 Digital Efficiency Report. Disponível em

<https://www.gov.uk/government/publications/digital-efficiency-report> Acessado em 18/10/2015. 30 Budget 2012. Disponível em

<https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/247119/1853.pdf>. Acessado em 18/10/2015.

31 Government Digital Strategy. Disponível em

<https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/296336/Government_Digital _Stratetegy_-_November_2012.pdf>. Acessado em 18/10/2015.

pessoas interajam com ele32 _{(tradução nossa).}

Como parte do plano proposto, uma Estratégia de Governo Digital foi publicada em novembro de 2012 (e revista em 2013), e cada departamento também publicou uma estratégia digital própria descrevendo como usariam esses princípios para transformar seus serviços.

Nesta estratégia, o GDS (Government Digital Services, alocado dentro do Cabinet Office) se apresenta como facilitador e líder do processo que eles chamam de “transformação digital”, que significa implementar a cultura “digital por padrão” em todos os serviços prestados pelo governo.

Seu papel também engloba consultoria, criação de manuais e material de apoio, formação e auxílio na seleção e contratação de pessoal. O GDS se define como uma equipe que “ajuda o governo a fazer os serviços digitais e a informação mais simples, mais clara e mais rápida. Nós colocamos as necessidades das pessoas antes das necessidades do governo33_”.

Além disso, a estratégia apresenta metas concretas, como a de transformar todos os serviços com mais de 100.000 transações anuais, totalizando 25 serviços que, até março de 2015, teriam que estar totalmente de acordo com o padrão de serviço publicado por eles (Quadro 1).

A estratégia como um todo foi acompanhada em relatórios trimestrais e cada um dos 25 serviços ganharam uma página específica onde era possível ver o status de desenvolvimento deles, desde a fase exploratória, passando pela versão alfa, em que é testada com poucas pessoas em ambiente fechado, a fase beta, onde o serviço é colocado no ar e testado com um grupo maior em um ambiente real e aberto, até o serviço entrar efetivamente no ar.

Em março de 2015, prazo previsto para o término deste programa de transformação, 20 serviços estavam publicados e funcionais e cinco ainda seguiam em desenvolvimento. Entre os que entraram no ar estão o agendamento de visitas nas prisões, o requerimento para auxílio a cuidadores (benefício concedido a pessoas que se dedicam a cuidar de pessoas que precisam de assistência, como familiares idosos), emissão de vistos, consulta as informações sobre licença de direção e um painel de controle para pequenas e médias empresas consultarem e pagarem seus impostos.

Analisando o processo de desenvolvimento do requerimento para auxílio a cuidadores (Carer's allowance), Leigh Mortimer, responsável pelo serviço, narra a mudança radical na

32 Ibdem

33 “We help government make digital services and information simpler, clearer and faster. We put users' needs before the needs of government.” Ibdem.

abordagem de desenvolvimento do serviço.

A DWP34 _{teve experiência com projetos descritos como “ágeis”, mas que não o eram}

de fato. Eles eram, compreensivelmente, um pouco cautelosos. Provamos nosso valor com uma versão alfa, que completava um caso de uso do começo ao fim. Poderia ser utilizado por um pequeno grupo que daria feedback sobre a experiência do início ao fim. O GDS colaborou com a equipe de serviços digitais da DWP e com a equipe operacional da Carer’s Allowance, iterando toda semana. Num prazo de sete semanas tivemos um protótipo propriamente desenvolvido35_{. (tradução nossa)}

Mike Bracken, líder do GDS na ocasião, escreveu:

Eles agora lançam o código em um ciclo de duas semanas, rapidamente iterando a partir do que veio antes. Muitas mudanças, pequenas e constantes. Compare isso com a forma como as coisas eram feitas: lance o produto e deixe-o por cinco anos sem mudanças e sem melhorias. Não é mais assim que o governo faz as coisas36_.

A seguir apresentaremos dois quadros que resumem de maneira bastante didática o conjunto de padrões e práticas introduzidos pelo GDS para todo o governo britânico. Eles são bastante assertivos e demonstram claramente a influência dos modelos enxutos e das metodologias ágeis na maneira como o governo passou a encarar o desenvolvimento de serviços digitais.

Quadro 1: Padrão de serviços digitais do GDS37

1. Entenda as necessidades dos usuários. Pesquise para desenvolver um conhecimento profundo sobre quem os usuários do serviço são e o que isso significa para o design do serviço.

2. Coloque em ação uma pesquisa contínua sobre os usuários e teste a usabilidade continuamente para buscar feedback e melhorar o serviço.

3. Aloque uma equipe multidisciplinar e sustentável que consiga projetar, construir e operar o serviço, liderada por um gerente com habilidades adequadas e responsável pela tomada de decisões.

34 Sigla para Department of Work and Pensions (Departamento de Trabalho e Pensões)

35 Live and Kicking. Disponível em <https://dwpdigital.blog.gov.uk/2013/10/18/live-and-kicking/>. Acessado em 18/10/2015.

36 What we mean when we say "service transformation". Disponível em

<https://gds.blog.gov.uk/2014/07/03/what-we-mean-when-we-say-service-transformation/>. Acessado em 18/10/2015.

37 Tradução nossa de Digital by Default Service Standard. Disponível em

4. Construa o serviço utilizando métodos ágeis, iterativos e centrados nos usuários conforme consta no manual.

5. Construa um serviço que possa ser iterado e melhorado com frequência e garanta que você tem a capacidade, os recursos e a flexibilidade técnica para realizá-lo.

6. Avalie quais ferramentas e sistemas podem ser utilizados para construir, hospedar, operar e medir o serviço e como obtê-lo.

7. Avalie que tipo de informação e dado o serviço digital proverá e guardará e enderece questões de níveis de segurança, responsabilidades legais, privacidade e riscos associados ao serviço (consultando especialistas quando for apropriado).

8. Faça com que todo novo código fonte seja aberto e reutilizável e publique-o sob licenças apropriadas (ou então dê uma explicação convincente de porque isso não pode ser feito para partes específicas do código fonte).

9. Utilize padrões abertos e plataformas de governo compartilhadas sempre que possível.

10. Seja capaz de testar o serviço em um ambiente idêntico àquele da versão da produção, incluindo os navegadores e dispositivos mais comuns, utilizando contas simples e uma amostra representativa de usuários.

11. Faça um plano para caso o serviço digital fique indisponível temporariamente.

12. Crie um serviço que seja simples e intuitivo suficiente para que os usuários saibam como utilizá-lo desde a primeira vez.

13. Construa um serviço consistente com a experiência do usuário do resto do GOV.UK incluso a aplicação de padrões de design gráfico e guias de estilo.

junto com um plano apropriado para eliminar gradualmente canais ou serviços não-digitais.

15. Utilize ferramentas de análise que coletem dados de performance. Utilize esses dados para analisar o sucesso do serviço e transforme isto em novas funcionalidades e tarefas para a próxima fase de desenvolvimento.

16. Identifique indicadores de performance do serviço, incluindo os quatro indicadores chave obrigatórios definidos no manual. Estabeleça uma referência para cada uma das métricas e faça um plano para promover melhorias.

17. Reporte os dados de performance na plataforma de performance.

18. Teste o serviço do início ao fim com o ministro responsável por ele.

O GDS, no seu papel de líder e facilitador, confeccionou muita documentação, tanto de acompanhamento do projeto, como de suporte para as áreas finalísticas realizarem seus projetos digitais. Manuais, vídeos, estudos de casos e muitos outros conteúdos estão disponibilizados no site do programa. As orientações vão desde como e por que manter um blog, até como escolher a melhor tecnologia para determinado serviço. Traz boas práticas de redação e apresenta metodologias inovadoras no campo do planejamento de projetos e desenvolvimento e manutenção de software.

Dentre estes materiais, destacamos os princípios de Design (Design Principles, aqui com sentido de desenho de projeto, e não de desenho gráfico). Estes, em conjunto com os padrões de serviço já apresentados, vão nos ajudar a montar nossa matriz de boas práticas a ser aplicada para comparar com as práticas utilizadas aqui no Brasil.

Quadro 2: Princípios de Design de projetos do GDS38

1 Comece com as

necessidades*

*necessidades das pessoas e não do governo

O design de serviços começa com a identificação das necessidades das pessoas. Se você não sabe quais são as necessidades delas, você não vai desenvolver a coisa certa. Pesquise, analise os dados e converse com as pessoas. Não faça

suposições. Tenha empatia pelas pessoas e lembre-se de que o que as pessoas pedem não necessariamente é o que precisam. 2 Faça menos O governo deve fazer apenas o que pode fazer. Se encontramos

uma forma de fazer algo que funcione, deveríamos fazer com que seja reutilizável e compartilhável ao invés de reinventar a roda a cada vez. Isto significa construir plataformas e registros que outros possam construir sobre, provendo recursos (como APIs), que outros possam utilizar e “linkando” o trabalho dos outros. Deveríamos nos concentrar no cerne irredutível.

3 Projete com dados Na maioria dos casos, podemos aprender com o comportamento do mundo real observando como os serviços reais são utilizados. Deixe com que os dados levem a tomada de decisões, não palpites ou adivinhações. Siga fazendo isso mesmo depois de publicar o serviço, prototipando e testando com as pessoas em ciclos iterativos de resposta. Ferramentas de análise devem ser embutidas por padrão e devem ser de fácil leitura. São essenciais.

4 Faça o trabalho árduo para que o serviço seja simples

Fazer com que algo pareça simples é fácil. Fazer com que algo seja simples de usar é bem mais difícil – ainda mais quando a camada de baixo é complexa – mas é exatamente isso que precisamos fazer. Não aceite “mas sempre foi assim” como resposta. Em geral é mais trabalhoso fazer as coisas ficarem mais simples, mas é a coisa certa a fazer.

5 Itere. Depois, itere novamente.

A melhor forma de construir bons serviços é começar pequeno e iterar repetidas vezes. Lance o “produto mínimo viável” o quanto antes, teste-o com pessoas que o utilizarão, mova da versão alfa para a Beta para a Live adicionando qualidades, apagando coisas que não funcionam e fazendo refinamentos com base nos feedbacks das pessoas. Iterações reduzem riscos. Fazem com que grandes falhas sejam menos prováveis e transformam pequenas falhas em lições. Se um protótipo não está funcionando não hesite em se desfazer dele e começar novamente.

deve ser inclusivo, legível e o mais compreensível possível. Se tivermos que sacrificar a elegância – tudo bem. Estamos construindo necessidades não audiências. Estamos projetando para todo o país, não apenas para aqueles que usam a Web. As pessoas que mais precisam de nossos serviços são exatamente as pessoas que tem dificuldade em utilizá-los. Vamos pensar nessas pessoas desde o início.

7 Compreendendo o

contexto

Não estamos projetando para uma tela, estamos projetando para pessoas. Precisamos pensar seriamente sobre o contexto em que estão utilizando nossos serviços. Estão na biblioteca? Estão ao telefone? Estão realmente familiarizados apenas com o “Facebook”? Eles realmente nunca utilizaram a Web antes?

8 Construa serviços

digitais, não websites

Um serviço é algo que ajuda as pessoas a fazerem algo. Nosso trabalho é descobrir as necessidades das pessoas e construir serviços que atendam a essas necessidades. É claro que boa parte disso serão páginas na Web, mas não estamos aqui para construir websites.

O mundo digital precisa se conectar com o mundo real, então temos que pensar sobre todos os aspectos de um serviço, e garantir que ele adicione algo às expectativas e necessidades das pessoas.

9 Seja consistente, não uniforme

Devemos utilizar a mesma linguagem e o mesmo padrão de design gráfico sempre que possível. Isso ajuda as pessoas a se familiarizarem com nossos serviços, mas quando não é possível devemos garantir que nossa abordagem é consistente. Isto não é uma camisa de força ou uma regra do livro. Cada circunstância é diferente. Quando encontramos padrões que funcionam devemos compartilhá-los e falar sobre os motivos pelos quais o utilizamos. Mas isso não deve nos impedir de melhorar ou mudá-los no futuro quando encontrarmos melhores formas de fazer as cosias ou quando as necessidades das pessoas mudarem. 10 Faça as coisas abertas;

isso faz das coisas melhores

Devemos compartilhar o que estamos fazendo sempre que pudermos. Com colegas, com as pessoas que usam o serviço, com o mundo. Compartilhar código, design, ideias, intenções e

falhas. Quanto mais gente olhando um serviço melhor ele fica – grandes erros são previstos, melhores alternativas são descobertas e a barra é levantada. Muito do que estamos fazendo só é possível devido a códigos abertos e a generosidade da comunidade de web design. Deveríamos pagar isso de volta.

Nesta seção conhecemos as motivações que levaram o governo britânico a implementar um programa governamental para transformar a maneira como o governo desenvolvia serviços digitais. Neste contexto exploramos quais foram as ações concretas tomadas e quais práticas foram desenvolvidas. Em seguida partiremos para a análise do caso estadunidense, que apresenta uma série de semelhanças e foi, em certa medida, já influenciado por esta experiência britânica.