GovOps: DevOps e governança
Este artigo foi traduzido automaticamente do japonês por uma IA (Claude). Pode conter erros. Ler o artigo original em japonês.
Penso que, na governança pública do futuro e na governança de certas áreas, pode-se conceber algo como o GovOps, em vez do DevOps.

Com a criação da Agência Digital, a DX dos órgãos públicos e a DX das empresas, a tecnologia digital está finalmente prestes a ser incorporada de verdade à sociedade. Há muitas visões sobre a DX: algumas a reduzem à simples introdução de software, outras apontam para a melhoria de serviços e da UX por meio da DX, e outras sugerem mudanças em todo um setor.
Pessoalmente, porém, considero que o cerne da DX é a transformação dos "mecanismos" e, mais concretamente, que as "inovações complementares" (de Brynjolfsson e outros), como instituições e sistemas, são importantes. Sobre isso, peço que consultem o livro que publiquei recentemente, "Implementando o Futuro". Desta vez, vou falar sobre por que o GovOps.
Governance as Code
Hoje, a tecnologia digital não está apenas tornando as Ops (Operations) mais eficientes: o próprio Dev (Development) de leis e regras está começando a mudar.
Como apontam a inovação em governança e a governança ágil, a tecnologia digital não apenas torna mais eficiente a aplicação das regras, como também pode mudar a própria maneira de criá-las.
Por exemplo, se o Estado passasse a gerenciar a plataforma de drones, seria possível alterar em tempo real as áreas em que os drones podem voar. Como resultado, talvez deixasse de ser necessário definir minuciosamente em lei as áreas restritas. Além disso, se as inspeções feitas até agora por pessoas em fábricas, elevadores e outros equipamentos pudessem ser substituídas por monitoramento em tempo real com sensores, talvez fosse possível alongar um pouco o intervalo das inspeções periódicas feitas por pessoas. Inspeções que eram anuais poderiam passar a ser feitas a cada três anos, mais ou menos. Mais recentemente, o eKYC é um exemplo de como a tecnologia digital possibilitou uma verificação de identidade diferente da anterior. São exemplos em que a tecnologia digital mudou a forma de operar e, como consequência, mudou também a forma de criar as regras.
As operações se tornam mais eficientes por meio do código e, além disso, a própria maneira de construir as coisas muda. Isso lembra o movimento de Infrastructure as Code / Operations as Code que ocorreu no mundo de TI cerca de dez anos atrás. A ideia é que, ao definir e operar a infraestrutura e as operações por meio de código, a infraestrutura se torna programável e, com isso, muda também a maneira de fazer o Dev.
Aplicando isso ao contexto da governança, não seria possível pensar que Governance as Code, ou Governance by Code, está surgindo?
GovOps
No mundo de TI, em paralelo ao movimento de Infrastructure as Code / Operations as Code e influenciando-se mutuamente com ele, ocorreu a reintegração de Dev e Ops. Isso é o DevOps. Pensando nisso no contexto da governança, pode ser que exista algo como o GovOps.
Se, de certo modo, o produto dos burocratas é a "lei", fazer o seu deploy com rapidez e, ao mesmo tempo, operá-lo de forma estável é algo semelhante ao objetivo do DevOps.
De fato, o "sandbox regulatório", mencionado na governança ágil e em outros contextos, pode ser entendido como o rollout gradual do DevOps. Considerando que os mecanismos para assegurar agilidade provavelmente serão semelhantes, creio que a maneira de trabalhar do DevOps pode servir de referência para pensar o futuro da governança pública e da governança corporativa.
Dito isso, imitar o DevOps e "fazer o deploy de leis e decretos dez vezes por dia" causaria confusão demais na sociedade e, além disso, ao contrário dos sistemas de TI, as leis em geral são difíceis de "reverter"; por isso, acho melhor evitar copiá-lo tal qual. No entanto, se for possível, por meio da tecnologia digital, otimizar o fluxo de trabalho desde a aprovação do projeto de lei até a operação e o serviço, e assim aumentar o número de projetos de lei que podem ser propostos em um ano (e se for possível deliberá-los no Parlamento de forma eficiente e com grande transparência), talvez se torne possível uma governança altamente ágil diante das mudanças da sociedade.
Ao mesmo tempo, fica mais fácil entender o papel de cada medida relacionada à DX do trabalho burocrático, como "introduzir IA na verificação dos projetos de lei existentes para aumentar o número de deploys de leis".
GRE
Seguindo a lógica do SRE (site reliability engineer), também é possível pensar numa analogia como o GRE (governance reliability engineer).
Do que a abordagem do SRE oferece, o que pode ser usado são provavelmente o error budget e o toil. O error budget é um mecanismo em que se define previamente a faixa tolerável de erros e, dentro dela, assume-se risco para enfrentar com cautela novos desafios. Já o toil designa o trabalho manual que ocorre com frequência e pode ser automatizado.
No SRE, o error budget costuma ser calculado com base no uptime. No caso dos órgãos públicos, é preciso definir indicadores (KPIs) adequados e, naturalmente, há áreas em que erros não podem ser tolerados, de modo que não é algo aplicável a tudo. Mas, como uma forma de pensar para criar margem para novos desafios, acho que poderia ser aplicado em alguns casos.
Definir uma meta anual de redução de toil também seria uma das maneiras. Toil é, por assim dizer, o "trabalho penoso que as pessoas não precisariam fazer". Parece haver muito toil nas tarefas da administração pública; reduzindo-o, seria possível dedicar mais tempo ao que de fato importa, como o atendimento aos cidadãos e a escuta das pessoas. Acredito que esse tipo de ganho de eficiência já era algo que se fazia, mas penso que, ao receber o nome de toil, fica um pouco mais fácil de executar.
Rumo ao GovOps
Ao pensar assim no GovOps, creio que as ideias cultivadas até agora no meio do DevOps talvez possam ser usadas, em certa medida, também na governança.
Por exemplo, costuma-se repetir que o DevOps é cultura, é prática e é ferramenta, e a digitalização da governança tampouco deveria ficar restrita a uma questão de ferramentas.
Além disso, também ao melhorar o GovOps, é possível pensar com base nos seguintes "três princípios" do DevOps:
- Princípio do fluxo: tornar o fluxo de trabalho rápido
- Princípio do feedback: viabilizar o fluxo de feedback
- Princípio do aprendizado e da experimentação contínuos: gerar uma cultura organizacional
Aplicando isso à governança existente (por ora, a governança pública), seria algo como organizar o fluxo de trabalho por meio de mapeamento do fluxo de valor e acelerar o fluxo de trabalho das atividades existentes com tecnologia digital; viabilizar o fluxo de feedback usando sensores, Decidim e similares; e realizar aprendizado e experimentação contínuos.
Conclusão
Ainda hoje há partes em que eu mesmo penso, sem muita confiança, "será que é isso?", mas, como saiu o relatório sobre a governança ágil, pensei que, falando em ágil, vem à mente o DevOps, e escrevi seguindo essa associação. De fato, no relatório sobre governança ágil há a seguinte figura, que me parece ter semelhança com a figura do DevOps (GovOps) do início.

Nos slides sobre xOps que escrevi há algum tempo, na verdade também incluí o GovOps.
Sei que uma analogia grosseira dificilmente funciona tão bem assim, mas, ainda assim, acredito que a maneira de pensar do DevOps seja um conceito que pode servir de referência nas discussões sobre governo digital daqui para a frente e na DX de cada empresa.
xOps: o dia em que os engenheiros se tornam a força motriz do crescimento das startups from Takaaki Umada