Por vezes, a lentidão e a constância vencem a corrida. Há algo a dizer sobre as "melhores práticas" controladas nas instituições. A dificuldade com as chamadas "melhores práticas" governamentais é que a maioria foi desenvolvida para resolver problemas que não temos, de formas que não podemos utilizar. É preciso encontrar boas práticas emergentes que resolvam problemas que temos, de formas que possamos utilizar.
Esta noção foi exposta durante os workshops de governação no FreeBalance International Steering Committee em Miami, no mês passado. Há uma sensação crescente de que os métodos tradicionais de gestão de projectos se revelaram ineficazes para os grandes projectos governamentais Implementações informáticas e reforma da GFP. Isto é particularmente verdadeiro quando se implementam sistemas de planeamento de recursos empresariais (ERP) na administração pública. Embora a utilização de software empresarial concebido para a administração pública, como o Planeamento de Recursos Governamentais (GRP), melhore as taxas de sucesso, é necessário mais.
O legado é o que o legado faz
Fala-se muito de tecnologia antiga na administração pública. As administrações públicas incorrem em custos de operação e manutenção de TI mais elevados do que as empresas, em média. O problema não é tanto a tecnologia antiga, mas pensamento herdado. Muitos governos estão a migrar de tecnologias obsoletas para tecnologias herdadas, numa altura em que as empresas estão a migrar para a nuvem com aplicações SaaS facilmente adaptáveis e de baixo custo. A nossa opinião é que há algo fundamentalmente errado com as chamadas "melhores práticas" de TI na administração pública.
Começando por encarar a GRP como TI, em vez de reforma e modernização. Não se trata de TI, mas sim de transformação.
Explorámos estas práticas antigas de TI na FISC.
A maioria das implementações de GRP centra-se na redução de riscos através da documentação e da separação de preocupações.
Prática excessivamente documentada
A principal estratégia de mitigação de riscos no pensamento antigo é a documentação: documentar o projeto, documentar o estado atual, documentar o futuro, documentar o plano de testes, documentar o plano do projeto, documentar as actas de todas as reuniões, documentar cada passo na aceitação do utilizador....
Já perceberam.
Os prestadores de serviços transformam-se em autores e editores. A complexidade da documentação resulta na concentração em práticas obsoletas de sistemas anteriores. Mais código é personalizado. O foco na conformidade significa que os fornecedores se ancoram em contratos. Os projectos divergem das necessidades.
Além disso, o tempo necessário para documentar, compreender e aprovar os documentos gera atrasos. Os atrasos resultam numa maior resistência à mudança. Isto deve-se ao facto de os documentos serem uma má representação do progresso. Os gestores de projectos governamentais tornam-se relutantes em assinar as etapas porque a documentação complexa é abstrata.
Estas práticas significam que as implementações não satisfazem certamente as necessidades originais, ou não são entregues a tempo, ou custam o orçamento original. Muitas não cumprem os três objectivos.
Além disso, as autópsias dos projectos sugerem frequentemente que deveria ter sido redigida mais documentação.
Separação de preocupações
A ideia tem sido utilizar as chamadas "melhores práticas". Por exemplo: separar os fabricantes dos integradores, separar as questões orçamentais, financeiras, de aprovisionamento, de recursos humanos e fiscais em silos.
A separação de preocupações significa uma implementação fora do quadro geral, com diferentes incentivos para os fornecedores, falta de integração, sem cobertura orçamental total - muitas aplicações de despesas funcionam completamente fora da contabilidade das autorizações.
A abordagem de separação impediu muitos governos de terem uma visão holística da correspondência entre o software e a reforma esperada, criou incentivos perversos para fornecedores de consultoria, fabricantes de software, consultores de propostas e pessoal de TI.
A falta de uma visão holística e de integração significa que os sistemas raramente cumprem os objectivos a longo prazo. O destino é um ciclo de substituição de sistemas por novos sistemas que também não satisfazem as necessidades a longo prazo. Tal como descrito num publicação anterior:
A gestão tradicional de projectos parte do princípio de que os projectos são complicados, mas previsíveis. A construção de uma ponte, por exemplo, pode ser complicada, exigindo conhecimentos técnicos de engenharia. Os engenheiros compreendem a resistência dos materiais, como construir em diferentes condições de solo e lidar com as mudanças de temperatura. O progresso do projeto pode ser previsto com base em projectos semelhantes. Naturalmente, o progresso efetivo é muito fácil de ver.
As implementações de software empresarial são complexas. Os projectos de Planeamento de Recursos Governamentais (GRP) são transformacionais. São necessários peritos em finanças, recursos humanos ou aquisições públicas. Tal como os peritos em TI. Os utilizadores necessitam de formação especial. (Os utilizadores do Bridge não necessitam de nova formação). Mais importante ainda, os projectos GRP transformam e automatizam processos que causam uma resistência significativa à mudança.
Projectos de TI da administração pública em cascata
As técnicas em cascata pressupõem que todo o planeamento pode ser efectuado antes de o software ser adaptado. Parte-se do princípio de que o resultado final do software corresponderá às expectativas devido a um trabalho de conceção rigoroso.
O pensamento herdado considera os projectos de reforma das TI e da GFP como previsíveis. As práticas herdadas são impostas aos contratantes para reduzir os riscos percebidos. A nossa análise dos projectos FreeBalance, dos projectos de outras empresas e da literatura sobre gestão de projectos e reforma da GFP levou-nos a concluir que as práticas em cascata aumentar significativamente o risco do projeto.
O trabalho de conceção, que consiste na análise "As-Is" e "To-Be" em documentos de requisitos de software, demora muitas vezes até um ano a ser concluído.
- O foco na documentação ancora as implementações na forma como os sistemas antigos funcionam, em vez de nos objectivos governamentais
- O foco na documentação leva à personalização desnecessária do código
- A focalização na solução inclui "melhores práticas" inadequadas de diferentes contextos, desligando os projectos dos problemas a ultrapassar
- O foco nos contratos dá ênfase às listas de verificação funcionais, em detrimento das necessidades não funcionais, como a usabilidade e a capacidade de gestão
As administrações públicas consideram muitas vezes que a análise tradicional das necessidades não consegue revelar requisitos abrangentes. Isto deve-se ao facto de a análise funcionar num vácuo, sem um contexto mais alargado da forma como as tarefas governamentais são efetivamente realizadas, dos problemas que precisam de ser resolvidos e das práticas emergentes que podem ser aproveitadas para a mudança.
Sejamos realistas: há décadas que os governos têm vindo a implementar software comercial para as necessidades de GRP e PFM. As práticas herdadas têm limitado o sucesso. Isto acontece numa altura em que os governos são desafiados a transformarem-se digitalmente. Implementar sistemas móveis centrados no cidadão. Aumentar a prestação de serviços através do digital. Integrar-se nas redes sociais. Implementar a cadeia de blocos e a inteligência artificial.
As administrações públicas estão a enfrentar um ponto de inflexão estratégico. As práticas dominantes de TI da administração pública restringem o sucesso da transformação digital
![Ponto de viragem da gestão de projectos de TI da administração pública]()
A evolução ágil do governo
Os governos, tal como as grandes empresas, operam muitos sistemas informáticos. As preocupações legítimas com a segurança, o desempenho, a qualidade e a fiabilidade significam que os governos necessitam de uma forte governação das TI. A passagem de uma implementação em cascata para uma implementação ágil não deve comprometer a governação das TI. A Grupo Gartner, por exemplo, recomenda um bi-modal abordagem das TI: "Bimodal é a prática de gerir dois estilos de trabalho distintos mas coerentes: um centrado na previsibilidade e o outro na exploração. O Modo 1 é optimizado para áreas que são mais previsíveis e bem compreendidas. Centra-se na exploração do que é conhecido, ao mesmo tempo que renova o ambiente antigo para um estado adequado a um mundo digital. O modo 2 é exploratório, experimentando para resolver novos problemas e optimizado para áreas de incerteza.”
Muitos observadores consideram que o bimodal não vai suficientemente longe. O analista Dion Hinchcliffe, por exemplo, afirma que "o mundo real da tecnologia e as actividades que a tornam frutífera não podem ser compartimentados numa estrutura dupla." O sucesso pode ser melhor encontrado numa abordagem multimodal. Ou, considerando processos mais ágeis para a implementação e processos mais rígidos após a implementação.
Agile no mundo real
Como é que os gigantes da Internet desenvolvem soluções inovadoras? Que padrões são relevantes para os governos? Existem padrões de sucesso emergentes específicos da administração pública? Estas foram as perguntas que fizemos depois de diagnosticar os problemas de implementação de GRP e ERP no sector público. Os padrões de sucesso levaram à atualização da nossa metodologia ágil, A-i3+qMTM.
Vimos que as nossas experiências positivas de implementação estavam alinhadas com as técnicas ágeis praticadas em empresas inovadoras da Internet. Também se alinhavam com as práticas emergentes do desenvolvimento nacional. Os padrões de sucesso reuniram-se em torno de quatro dimensões:
- Integração de produtos: As metodologias de implementação de GRP e ERP são tradicionalmente separadas das metodologias de desenvolvimento de produtos. Além disso, o código do software COTS raramente é adaptado pelo fabricante para satisfazer as necessidades do cliente. Em vez disso, é desenvolvido código personalizado órfão. A FreeBalance tem integrado a implementação e o desenvolvimento de produtos há décadas. O código personalizado aumenta o nosso software COTS. Esta abordagem funciona de forma semelhante a DevOps, um processo de desenvolvimento de software ágil.
- Workshops: O contexto é fundamental para o sucesso da reforma. Descobrimos que os documentos e relatórios raramente contam a história da reforma do sector público. É possível descobrir isso através do envolvimento das pessoas. Descobrimos também que os funcionários públicos não estavam expostos a contextos de reforma: práticas boas e adequadas em vez de "melhores práticas" irrealistas ou práticas muito pobres herdadas do passado. Era necessário o envolvimento dos utilizadores e das equipas de projeto. A FreeBalance desenvolveu workshops de envolvimento como uma forma de lean mecanismo para comunicar o contexto. E aprendemos com a abordagem "canvas" emergente, como a Modelo de negóciopara criar estruturas de workshops específicas para cada governo.
- Storyboards: A estrutura das especificações do FreeBalance foi revista em 2008 para refletir a abordagem de componentes reutilizáveis, a que chamamos "entidades governamentais". Isto inclui a articulação da entidade e dos parâmetros da entidade. Estes parâmetros permitem uma enorme configurabilidade. A interação entre entidades está definida. Isto porque as entidades são reutilizadas entre aplicações. Tudo isto faz todo o sentido para os nossos programadores de produtos, mas é abstrato para os especialistas em GFP. Desenvolvemos uma abordagem de storyboard para facilitar o desenvolvimento de especificações utilizando uma abordagem de pensamento de design. Isto foi alargado na nossa metodologia ágil actualizada. (Demonstrado durante Workshops FISC 2018.)
- Gestão da mudança: A gestão da mudança organizacional é particularmente difícil na administração pública. Aprendemos com os A abordagem de Adaptação Iterativa Centrada nos Problemas (PDIA) da Escola Kennedy de Harvard. A PDIA abrange muito mais do que a gestão da mudança. A técnica tem uma abordagem ideal centrada no governo para a identificação das partes interessadas (agentes) e abordagens de comunicação. Também descobrimos que o valor da mudança raramente é comunicado de forma eficaz aos potenciais agentes de mudança ou aos futuros utilizadores. Chegámos a perceber que a Tela da Proposta de Valor é uma ferramenta ideal para utilizar. (Demonstrado durante Workshops FISC 2018.)
A-i3+qMTM aproveita os padrões de sucesso para uma metodologia ágil abrangente que também inclui:
- GESCED: Uma versão adaptada da estratégia empresarial PESTLE (política, económica, social, tecnológica, jurídica e ambiental) para o contexto governamental. (Demonstrado durante Workshops FISC 2018.)
- Agile: Uma versão adaptada de Kanban e Scrum para o desenvolvimento iterativo
- Fazendo o desenvolvimento de forma diferente: Uma abordagem ágil, com uma manifesto, para o desenvolvimento governamental passo a passo, que inclui PDIA
Resultados da implementação Agile
A-i3+qMTM abrange todo o ciclo de vida do projeto, começando com a nossa proposta aos governos. Avaliamos os factores de risco desde o início, tais como restrições do programa, contradições de requisitos e más práticas. Isto determina a nossa abordagem ao risco e informa a negociação do contrato.
A chave A-i3+qMTM caraterística é a iteração dos processos principais que são entregues em série em cascata. Estes processos paralelos começam com uma formação obrigatória sobre o produto. As equipas de projeto governamentais precisam de ver as capacidades do sistema em ação. Isto é utilizado para workshops de configuração e personalização. A capacidade é criada em paralelo. As configurações são aprovadas quando vistas em ação. Tal como o código personalizado. O progresso é visual.
A-i3+qMTM acelera a implementação, ancorando os projectos nas aspirações de ganho e nas capacidades do novo sistema. Configuração não precisa de muita documentação, apenas de projectos de saída do FreeBalance Accountability Suite. O desenvolvimento personalizado o processo reduz a complexidade para os peritos em GFP articularem e validarem as necessidades.
A-i3+qMTM O processo de desenvolvimento personalizado inclui:
- A equipa de serviços no local da FreeBalance cria storyboards e casos de utilização de forma interactiva com os clientes
- A equipa de gestão do produto FreeBalance valida estes dados utilizando conhecimentos tecnológicos e identifica outras formas de alargar o âmbito de aplicação das entidades governamentais a outros requisitos do Mapa de Componentes da GFP
- Os storyboards e casos de utilização validados são aprovados pelos clientes
- A equipa de gestão de produtos FreeBalance desenvolve especificações
- O desenvolvimento de produtos FreeBalance valida as especificações antes de desenvolver o código
- A equipa de serviços no local da FreeBalance contribui para a garantia de qualidade para assegurar que o resultado satisfaz as necessidades do país
- Os testes de aceitação do utilizador pelo cliente validam a utilização do código na produção (ou demonstram a necessidade de adaptar as especificações)
A repetibilidade é um desafio fundamental para qualquer metodologia. A-i3+qMTM inclui ferramentas de processo para repetibilidade.
- Tela: Grande espaço de trabalho visível, normalmente numa parede ou num quadro branco de grandes dimensões, que pode ser utilizado em linha, seguindo uma série de etapas de workshop para brainstorming e tomada de decisões
Em alternativa, pode ser implantado em linha - Quadros: Grande espaço de trabalho visível, normalmente numa parede ou num quadro branco de grandes dimensões, que pode ser colocado em linha, representando dinamicamente as actividades em curso
Em alternativa, pode ser implantado em linha - Projectos: Descrição de uma configuração do FreeBalance que inclui regras comerciais e articulação do fluxo de trabalho, desenvolvimento personalizado específico do país, relatórios e interfaces
Descreve qualquer desenvolvimento personalizado específico do país - Modelos: Modelo de documento para a criação de artefactos de projecto
Apêndice: A-i3+qMTM Descrição
As características do A-i3+qM metodologia são:
- Acelerado eliminando tantos processos de cascata legados que levam a problemas no projecto. Isto inclui documentação desnecessária e planos de projecto detalhados, a favor de workshops e passos curtos do processo. As dimensões das equipas são mantidas pequenas para permitir as comunicações do cliente e reduzir as despesas gerais de coordenação.
- Integrado através de uma metodologia única para apoiar o desenvolvimento e a implementação de serviços. Isto é integrado com os requisitos do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores, e a equipa de desenvolvimento. As equipas de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
- Iterativo ser responsiva às mudanças dos clientes e de implementação utilizando fases. A metodologia aproveita o melhor do desenvolvimento de software e metodologias de serviços "lean" comprovadas com workshops, pequenas iterações, histórias de utilizadores, marcos miliários e a capacidade de mostrar progressos. Estas técnicas são alargadas para além da organização de desenvolvimento para serviços de implementação, alavancando ganhos de produtividade e capacidade de reagir às exigências do cliente.
- Implementação-com modelos de boas práticas e processos comprovados de gestão de programas. Esta metodologia centra-se no sucesso da implementação do cliente, em vez de uma versão de software que atinja objectivos internos ou arbitrários. A implementação e o desenvolvimento do produto são geridos através de um Gabinete de Gestão de Programas.
- Qualidade assegura que o software é lançado e apoiado em reuniões de boas práticas de Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, stress e regressão. A qualidade é integrada com a implementação onde os testes FreeBalance são baseados nos ambientes do cliente.