Lee Provoost

Lee Provoost lidera e constrói equipas de engenharia de software para organizações com requisitos de conformidade regulamentar e de alta segurança. Trabalhar para start-ups mostrou-lhe como desenvolver soluções focadas no utilizador e com baixos custos; organizações altamente regulamentadas e avessas a grandes riscos, ensinaram-lhe conceitos inovadores para implementações globais de grande escala. Lee Provoost respondeu às nossas perguntas sobre os desafios de mudar as ferramentas e os processos que as empresas adotam para fazer o seu trabalho.

Como descreve o trabalho que fez no Serviço Digital do Governo?

No Serviço Digital do Governo (SDG) do Reino Unido tive a tarefa de mudar a forma como o Governo fornece serviços ao público. A tecnologia está no coração do programa de mudança, mas a realidade é que a tecnologia é (como de costume) a parte fácil. O resultado mais visível do trabalho no SDG é o site www.gov.uk, um site que centraliza centenas de sites governamentais geridos separadamente. Algo menos visível foram os anos de trabalho com os principais departamentos do Governo para mudar a forma como disponibilizam os seus serviços digitais.

Enquanto arquiteto técnico, eu fazia parte da equipa que ajudou grandes departamentos do Governo Central a afastarem-se do modelo de serviço clássico liderado pelo fornecedor e outsourcing, para um modelo em que o departamento tem mais controlo sobre os seus serviços e projetos.

O meu papel era de consultor técnico estratégico, construtor e gestor das equipas técnicas, e agente de mudança. O último foi o mais difícil. A criação de um processo de disponibilização contínua é relativamente fácil. Porém, é realmente difícil convencer as equipas de gestão a fazerem mudanças de fundo, em vez de andarem a desperdiçar tempo a arrastarem pequenas mudanças e em processos de revisão exaustivos.

Então, tinha por missão construir as bases de uma organização digital, certo?

Mmmm, eu preferia eliminar a palavra “digital”. Na minha opinião, o trabalho que fizemos foi apenas o de construir as bases para uma organização eficaz e voltada para o cliente, independentemente do seu foco digital.

Inicialmente havia muita tecnologia “sombra”, que nós, pouco a pouco, fomos transformando em “soluções oficiais”. É a armadilha típica de organizações de Tecnologias da Informação (TI), o tornarem-se redundantes por serem o departamento do “não”: “Não, não, não se pode ter um sistema que permita fazer o carregamento de ficheiros e partilhar arquivos com outras pessoas”.

Então, o que fazer quando é preciso partilhar um arquivo?. Independentemente de andarmos a bloquear firewalls ou computadores, as pessoas conseguem ser muito criativas quando se trata de encontrar soluções para estas pequenas frustrações.

Nós introduzimos, aos poucos, ferramentas simples de colaboração e comunicação, muitas vezes por um período experimental de seis meses. Ferramentas como o Google Apps para o e-mail e partilha de documentos, o Slack para mensagens instantâneas, o GitHub para colaboração em torno de código fonte, PagerDuty para alertas, etc..

Depois de seis a doze meses, as pessoas começaram a perceber o valor das ferramentas e de repente a discussão se devemos pagar para uma implantação maior, com mais alguns floreados, torna-se muito mais fácil.

Do ponto de vista cultural, é um incansável foco em três coisas:

1. Lean Thinking: O problema de muitas organizações é estarem em silos, em muitos casos por design. O que muitas vezes se vê acontecer com as organizações que adotam a transformação digital é a “organização de TI de duas etapas”. Esta abordagem é vendida por grandes empresas de consultoria e integradores de sistemas. As empresas que adotam esta abordagem, aceitam que estão com demasiados problemas para que possam ser corrigidas. Apresentar uma solução de TI em duas etapas é como pôr um penso numa ferida: na verdade, não vai resolver os seus principais problemas. A outra abordagem é quando vemos as empresas a nomear Chief Digital Officers que replicam a abordagem de gestão de TI. A desculpa, muitas vezes, é a de que «sim, a nossa organização não consegue fazer isto, portanto vamos contratar um monte de programadores e colocá-los num qualquer espaço de trabalho de startups para estarmos com os miúdos fixes». Isto resulta num desperdício incrível. Vais receber uma equipa de front-end bem sexy e uma equipa de back-end com um legado não tão sexy. As duas vão começar a culpar-se entre si e a definir contratos e acordos de serviço (SLAs – Service Level Agreements) entre si. Trabalham para departamentos com orçamentos distintos pelo que terão prioridades diferentes. O meu principal foco foi conseguir furar isso.
2. Foco no utilizador: Uma vez, quando trabalhei para uma empresa do setor privado, a plataforma Office 365 era detida por três ou mais diretores diferentes. Um era responsável pelo e-mail, outro estava ligado à colaboração, outro pelo Office, etc. Não dá para acreditar o quão ineficiente isto é, e frustrante para o utilizador final. “Porque é que o meu Office não permite a integração com o SharePoint?” – “Bem, isso é porque o diretor X não acredita que isso seja necessário, por isso não demos prioridade a essa tarefa.” – “Então como é que eu vou colaborar em torno de documentos?”. Li uma vez que muitas organizações são criadas para resolver um dado problema mas passado algum tempo estão mais preocupadas com a auto-preservação. Isto é frequente em organizações governamentais (mas para ser justo também em departamentos de empresas do sector privado). Havia uma grande preocupação na satisfação das necessidades do Governo, mas não nas necessidades do utilizador. Tinhamos de repetir todos os dias: “foquem nas necessidades do utilizador”. Às vezes já parecíamos um disco riscado mas, ao fim de 18 meses, vemos essa forma de pensar a impregnar-se na malha organizacional. É preciso manter os utilizadores no centro daquilo que faz.
3. Manter a simplicidade: As grandes organizações têm tendência a complicar as coisas. Quando se está a trabalhar em cascata e a contratar em outsourcing os serviços de TI, estamos treinados a especificar à cabeça todos os requisitos. Por isso tenta-se introduzir tudo o que se pode pois é melhor fazê-lo agora do que tentar fazê-lo mais tarde (o processo de controlo de alterações é um inferno!). Mesmo quando as organizações começam a adoptar a abordagem “agile”, esta cultura ainda está presente. É preciso muito tempo para as pessoas se habituarem à ideia de que não vale a pena tentarem prever o futuro e que devem parar de desperdiçar todo aquele dinheiro.

Os desafios acima não se verificam apenas no sector público, são os mesmos que tenho encontrado em grandes empresas para onde tenho trabalhado. Prestar serviços para o Governo traz alguns desafios adicionais sobre compras e contratação, mas a maioria dos problemas culturais são os mesmos.

No que diz respeito à tecnologia, o que fez?

As escolhas tecnológicas são quase irrelevantes, pois dependendo da oferta do seu mercado, dependendo das suas necessidades e do seu legado, as pessoas vão adotar a linguagem X ou Y.

No entanto, há alguns princípios que se aplicam a todos, independentemente da tecnologia escolhida:

• Recorra a código aberto sempre que puder. O mercado amadureceu muito nos últimos anos. Existem algumas funções verticais onde pode valer a pena comprar, outras alugar.
• Se não puder recorrer a código aberto, utilize a cloud o mais que puder. Tanto faz que seja Infraestrutura como Serviço com a Amazon ou Software como Serviço, muitas vezes faz delegar. Se o seu departamento de TI lhe disser que não, então deve tratar-se de um ato de auto-preservação. Se várias organizações do Governo (nos Estados Unidos e na Europa), e organizações com requisitos de conformidade rigorosos em serviços financeiros e de cuidados de saúde o puderam fazer, certamente a sua instituição também o pode fazer.
• Não se comprometa muito cedo. Vale a pena testar as ferramentas durante três a seis meses. No entanto, nesse período é preciso testar num contexto real de trabalho, não pode simplesmente brincar um bocadinho.

Consegue pensar em 3 a 5 “coisas” que teriam grande impacto na ultrapassagem desses desafios?

1. Contrate pessoas mesmo boas. Não interessa se assinam contrato a termo certo ou se vão diretamente para o quadro, o importante é que tenha à sua disposição os melhores profissionais. Não apenas com as melhores competências mas também com uma boa mentalidade. Pessoas que se preocupem com o seu trabalho, pessoas com sentido de responsabilidade. Vai surpreender-se com o valor que uma equipa assim vai conseguir gerar mesmo sem grande supervisão ou micro-gestão.

2. Adie decisões sobre tecnologia o mais que puder, até que sejam mesmo precisas. Os requisitos mudam, as pessoas mudam e a tecnologia também. Não vale a pena decidir já qual a base de dados que vai usar se só vai precisar de uma versão resiliente em produção daqui a 18 meses. Muitas vezes os responsáveis tomam decisões de tecnologia a) sobre a qual não sabem nada, b) com base em fracos conhecimentos sobre os requisitos, c) antes do tempo.

3. Certifique-se de que as pessoas que tomam decisões sobre tecnologia conhecem o impacto das suas alterações. Muitas vezes as decisões sobre tecnologia são tomadas por pessoas que nunca a vão usar. A única razão pela qual o seu produto X é mau e tem muitas opções úteis desativadas é porque o decisor não vai sentir as frustrações diárias. Essa falta de empatia é, na minha opinião, uma das principais causas da existência de má tecnologia nas grandes instituições.

4. Utilize lean thinking para sair dos silos. Muitas ineficiências são introduzidas porque há muitas pessoas querem ser donas dos processos, cada uma com as suas próprias prioridades e opiniões. Esta é uma das principais causas do desperdício. Livre-se dela.

5. Desenvolvimento à medida usando código aberto como acelerador. Às vezes, para as grandes organizações, faz sentido construir o seu próprio software. A partir de uma determinada dimensão, o custo de uma licença anual de um produto que não lhe dá 100% do que precisa pode ser astronómico. Pode valer a pena decidir criar o que precisa. Isso significa que tem de ter a lição bem estudada no que diz respeito à desenvolvimento de software. Caso contrário, vai tornar-se mais um grande e dispendioso fracasso de TI.