Lento e estável, por vezes, ganha 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 se tem, de formas que não se pode utilizar. É preciso encontrar boas práticas emergentes que resolvam os problemas que tem, de formas que possa utilizar.
Esta noção foi exposta durante os seminários sobre governação no FreeBalance International Steering Committee conferência em Miami no mês passado. Há uma sensação crescente de que os métodos tradicionais de gestão de projectos se têm revelado ineficazes para os grandes governos. Implementações de TI e reforma da GFP. Isto é particularmente verdade na implementação de sistemas de Planeamento de Recursos Empresariais (ERP) no governo. Embora a utilização de Software Empresarial concebido para o governo, tal como o Planeamento de Recursos Governamentais (GRP), melhore as taxas de sucesso, mais é necessário.
O Legado é o que o Legado faz
Fala-se muito de tecnologia legada no governo. Os governos incorrem em operações informáticas e custos de manutenção mais elevados que as empresas, em média. O problema não é tanto a tecnologia herdada, mas sim pensamento legado. Muitos governos migram da tecnologia obsoleta para o legado, numa altura em que as empresas estão a mudar para a nuvem com aplicações SaaS facilmente adaptáveis e de baixo custo. O nosso ponto de vista é que existe algo fundamentalmente errado com as chamadas "melhores práticas" de TI no governo.
Começando por olhar para o GRP como TI, em vez de reforma e modernização. Não é TI, é transformação.
Explorámos estas práticas de legado informático no FISC.
A maioria das implementações do GRP concentra-se na redução do risco através da documentação, e na separação das preocupações.
Prática excessivamente documentada
A principal estratégia de mitigação do risco no pensamento antigo é a documentação: documentar o projecto, documentar o "como está", documentar o "futuro", documentar o plano de teste, documentar o plano do projecto, documentar as actas de cada reunião, documentar cada passo na aceitação do utilizador....
Percebe-se o objectivo.
Os fornecedores transformam-se em autores e editores. A complexidade da documentação resulta no foco em práticas obsoletas de sistemas anteriores. Mais código é personalizado. O foco na conformidade significa que os fornecedores se baseiam em contratos. Os projectos divergem das necessidades.
E, o tempo necessário para documentar, para compreender documentos, para aprovar documentos cria atrasos. Os atrasos resultam numa crescente resistência à mudança. Isto porque os documentos são uma má representação para o progresso. Os gestores de projectos dos governos tornam-se relutantes em assinar em marcos, porque a documentação complexa é abstracta.
Estas práticas significam que as implementações não irão certamente satisfazer a necessidade original, ou entregar a tempo, ou custar o orçamento original. Muitas falham em satisfazer as três.
E, os pós-mortems de projectos sugerem frequentemente que deveria ter sido redigida mais documentação.
Separação da Preocupação
A ideia tem sido a de utilizar as chamadas "melhores práticas". Por exemplo: separar os fabricantes dos integradores, separar orçamento, finanças, aprovisionamento, recursos humanos, preocupações fiscais em silos.
A separação das preocupações significa 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 de compromissos.
A abordagem de separação tem impedido muitos governos de ter uma visão holística de fazer corresponder o software à reforma esperada, tem criado incentivos perversos para os fornecedores de consultores, 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 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. Como descrito num post anterior:
A gestão tradicional de projectos assume 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 como lidar com as mudanças de temperatura. O progresso do projecto pode ser previsto com base em projectos semelhantes. É claro que o progresso real é 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 governamentais em finanças, recursos humanos, ou aquisições. Tal como os peritos em TI. Os utilizadores precisam de formação especial. (Os utilizadores de pontes não precisam 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 do Governo Legado das Cataratas
As técnicas de cascata pressupõem que todo o planeamento pode ser executado antes de o software poder ser adaptado. Parte-se do princípio de que o resultado final do software irá satisfazer as expectativas devido ao trabalho de concepção rigoroso.
O pensamento legado prevê projectos de reforma das TI e da GFP como previsíveis. As práticas legadas são impostas aos empreiteiros a fim de reduzir os riscos percebidos. A nossa análise de projectos FreeBalance, projectos de outras empresas, e a literatura sobre gestão de projectos e reforma da GFP levou-nos à conclusão de que as práticas de cascata aumentar significativamente o risco do projecto.
O trabalho de concepção, que consiste na análise "As-Is" e "To-Be" nos Documentos de Requisitos de Software leva frequentemente até um ano para ser concluído.
- Implementações de âncoras centradas na documentação sobre como os sistemas legados funcionam, em vez de objectivos governamentais
- A personalização desnecessária do código é feita com base na documentação
- Foco na solução inclui "melhores práticas" inadequadas de diferentes contextos, desligando os projectos dos problemas a ultrapassar
- O foco do contrato dá ênfase a listas de verificação funcionais, em detrimento de necessidades não funcionais como a usabilidade, e manejáveis
Os governos constatam muitas vezes que a análise das necessidades tradicionais não consegue desvendar requisitos abrangentes. Isto porque a análise funciona num vácuo, sem um contexto mais amplo de como os trabalhos governamentais são realmente realizados, que problemas precisam de ser resolvidos, e que práticas emergentes poderiam ser alavancadas para a mudança.
Sejamos realistas: há décadas que os governos têm vindo a implementar software comercial para as necessidades do GRP e da GFP. As práticas legadas têm restringido o sucesso. Isto ocorre numa altura em que os governos são desafiados a transformar digitalmente. Para implementar sistemas móveis centrados no cidadão. Para aumentar a prestação de serviços através do digital. Integrar-se com as redes sociais. Implementar a cadeia de bloqueio e a inteligência artificial.
Os governos estão a enfrentar um ponto de inflexão estratégica. As práticas dominantes de TI do governo restringem o sucesso da transformação digital
![Ponto de Dica para a Gestão de Projectos de TI do Governo]()
A Evolução Ágil do Governo
Os governos, tal como as grandes empresas, operam muitos sistemas informáticos. Preocupações legítimas sobre segurança, desempenho, qualidade e fiabilidade significam que os governos precisam 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. O Grupo Gartner, por exemplo, recomenda um bi-modal abordagem à TI: "Bimodal é a prática de gerir dois estilos de trabalho separados mas coerentes: um centrado na previsibilidade; o outro na exploração. O modo 1 é optimizado para áreas que são mais previsíveis e bem compreendidas. Concentra-se na exploração do que é conhecido, ao mesmo tempo que renova o ambiente legado num estado que é adequado para um mundo digital. O Modo 2 é exploratório, experimentando para resolver novos problemas e optimizado para áreas de incerteza..”
Muitos observadores acreditam que o bi-modal não vai suficientemente longe. O analista Dion Hinchcliffe, por exemplo, afirma que "o mundo real da tecnologia e as actividades que a fazem dar frutos não podem ser compartimentadas numa estrutura dupla.” O sucesso pode ser melhor encontrado numa abordagem multi-modal. Ou, ao considerar processos mais ágeis de implementação e processos mais rígidos pós-implementação.
Ágil 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 dos governos? Estas foram as perguntas que fizemos após o diagnóstico dos problemas de implementação do GRP e do ERP no sector público. Os padrões de sucesso levaram à actualização da nossa metodologia ágil, A-i3+qMTM.
Vimos que as nossas experiências positivas de implementação alinhadas com técnicas ágeis praticadas em empresas inovadoras da Internet. Também alinhou com as práticas emergentes do desenvolvimento do país. Os padrões de sucesso coalesceram em torno de quatro dimensões:
- Integração de produtos: As metodologias de implementação GRP e ERP são tradicionalmente separadas das metodologias de desenvolvimento de produtos. E, o código do software COTS raramente é adaptado pelo fabricante para satisfazer as necessidades dos clientes. Em vez disso, é desenvolvido um código personalizado para órfãos. A FreeBalance tem vindo a integrar a implementação e 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 ágil de desenvolvimento de software.
- Workshops: O contexto é crítico para o sucesso da reforma. Descobrimos que documentos e relatórios raramente contam a história da reforma do sector público. Descobrimos isto através do envolvimento das pessoas. Descobrimos também que os funcionários públicos não foram expostos a contextos de reforma: boas e apropriadas práticas em vez de "melhores práticas" irrealistas ou muito más práticas de legado. Era necessário o envolvimento dos utilizadores e da equipa do projecto. A FreeBalance desenvolveu workshops de envolvimento como um lean mecanismo de comunicação do contexto. E, aprendemos com a abordagem "lona" emergente, como a Modelo de negócio Telapara criar estruturas de oficinas específicas do governo.
- Storyboards: A estrutura das especificações FreeBalance foi revista em 2008 para reflectir a abordagem de componentes reutilizáveis, a que chamamos "entidades governamentais". Isto inclui a articulação dos parâmetros da entidade e da entidade. Estes parâmetros permitem uma configurabilidade massiva. A interacção entre entidades é definida. Isto porque as entidades são reutilizadas entre aplicações. Tudo isto faz perfeito sentido para os nossos criadores de produtos, mas é abstracto 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. (Manifestada durante Workshops FISC 2018.)
- Gestão da Mudança: A gestão da mudança organizacional é particularmente desafiante no governo. Aprendemos com a Adaptação Iterativa Orientada por Problemas (PDIA) a partir da abordagem Harvard Kennedy School. O 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 com eficácia aos potenciais agentes de mudança ou futuros utilizadores. Chegámos à conclusão de que a Tela de Proposta de Valor é uma ferramenta ideal a utilizar. (Demonstrado durante Workshops FISC 2018.)
A-i3+qMTM alavanca os padrões de sucesso para uma metodologia ágil e abrangente que também inclui:
- GESCED: Uma versão adaptada da estratégia empresarial PESTLE (político, económico, social, tecnológico, jurídico, ambiental) para o contexto governamental. (Manifestado 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 passo-a-passo do governo, que inclui o PDIA
Resultados de Implementação Ágil
A-i3+qMTM cobre todo o ciclo de vida do projecto, começando com a nossa proposta aos governos. Avaliamos previamente os factores de risco, tais como restrições do programa, contradições de requisitos, e más práticas. Isto determina a nossa abordagem de risco e informa a negociação de contratos.
A chave A-i3+qMTM característica é a iteração de processos nucleares que são entregues em série em cascata. Estes processos paralelos começam com a formação obrigatória do produto. As equipas de projectos governamentais precisam de ver as capacidades do sistema em acção. Isto é utilizado para oficinas de configuração e personalização. A capacidade é construída em paralelo. As configurações são assinadas quando vistas em acção. Tal como o código personalizado. O progresso é visual.
A-i3+qMTM acelera a implementação, ancorando projectos sobre as aspirações de ganho, e sobre as capacidades do novo sistema. Configuração não precisa de muita documentação, apenas de plantas do conjunto FreeBalance Accountability. O desenvolvimento personalizado o processo reduz a complexidade para que os peritos em GFP articulem e validem as necessidades.
A-i3+qMTM O processo de desenvolvimento personalizado inclui:
- O pessoal dos serviços no local FreeBalance constrói storyboards e utiliza os casos interactivamente com os clientes
- O pessoal de gestão de produtos FreeBalance valida este input utilizando conhecimentos tecnológicos, e identifica mais como as entidades governamentais podem ser alargadas para outros requisitos do Mapa de Componentes PFM
- Os storyboards validados e os casos de utilização são aprovados pelos clientes
- O pessoal de gestão de produtos FreeBalance desenvolve especificações
- O desenvolvimento do produto FreeBalance valida as especificações antes de desenvolver o código
- O pessoal dos serviços no local da FreeBalance acrescenta à garantia de qualidade para assegurar que o resultado satisfaz as necessidades do país
- O teste de aceitação do utilizador cliente valida a utilização do código na produção (ou demonstra 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, tipicamente de parede ou grande quadro branco em tamanho, que pode ser implantado online, 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, tipicamente de parede ou grande quadro branco em tamanho, que pode ser implantado em linha, representando dinamicamente actividades em curso
Em alternativa, pode ser implantado em linha - Plantas: Descrição de uma configuração FreeBalance que inclui a articulação de regras de negócio e fluxo de trabalho, desenvolvimento personalizado por 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-focados com modelos de boas práticas e processos comprovados de gestão de programas. Esta metodologia está centrada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objectivos internos ou arbitrários. A implementação e o desenvolvimento de produtos 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.