Lento e estável às vezes vence a corrida. Há algo a ser dito 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 você não tem, de maneiras que você não pode usar. Você precisa encontrar boas práticas emergentes que resolvam os problemas que você tem, de maneiras que você possa usar.
Esta noção foi exposta durante as oficinas de governança no Comitê de Direção Internacional FreeBalance conferência em Miami, no mês passado. Há uma sensação crescente de que os métodos tradicionais de gerenciamento de projetos têm se mostrado ineficazes para grandes governos. Implementações de TI e reforma da GFP. Isto é particularmente verdadeiro na implementação de sistemas de Planejamento de Recursos Empresariais (ERP) no governo. Embora o uso de Software Empresarial projetado para o governo, como o Planejamento de Recursos Governamentais (GRP), melhore as taxas de sucesso, mais é necessário.
Legado é o que o Legado faz
Fala-se muito de tecnologia legada no governo. Os governos incorrem em operações de TI e custos de manutenção mais elevados que as empresas, em média. O problema não é tanto a tecnologia legada, mas pensamento legado. Muitos governos estão migrando da tecnologia obsoleta para o legado, em um momento em que as empresas estão se movendo para a nuvem com aplicações SaaS facilmente adaptáveis e de baixo custo. Nossa visão é que existe algo fundamentalmente errado com as chamadas "melhores práticas" de TI no governo.
Começando com o GRP como TI, e não como reforma e modernização. Não é TI, é transformação.
Exploramos estas práticas de legado de TI no FISC.
A maioria das implementações do GRP se concentra na redução de riscos através de documentação e na separação de preocupações.
Prática excessivamente documentada
A principal estratégia de mitigação de risco no pensamento antigo é a documentação: documente o projeto, documente o como está, documente o que está por vir, documente o plano de teste, documente o plano do projeto, documente as atas de cada reunião, documente cada etapa na aceitação do usuário....
Você entendeu o ponto.
Os fornecedores se transformam 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 provedores se ancoram nos contratos. Os projetos divergem das necessidades.
E, o tempo necessário para documentar, para entender os documentos, para aprovar documentos, cria atrasos. Os atrasos resultam em uma crescente resistência às mudanças. Isso porque os documentos são uma má representação para o progresso. Os gerentes de projetos dos governos se tornam relutantes em assinar em marcos, porque a documentação complexa é abstrata.
Essas práticas significam que as implementações certamente não atenderão à necessidade original, ou não cumprirão o prazo, ou custarão o orçamento original. Muitos falham em atender a todos os três.
E, os pós-mortems de projetos freqüentemente sugerem que mais documentação deveria ter sido escrita.
Separação da Preocupação
A idéia tem sido utilizar as chamadas "melhores práticas". Por exemplo: separar os fabricantes dos integradores, separar o orçamento, as finanças, as compras, os recursos humanos, as 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 total do orçamento - muitas aplicações de despesas operam 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 com a reforma esperada, tem criado incentivos perversos para os 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 atingem metas de longo prazo. O destino é um ciclo de substituição de sistemas por novos sistemas que também não atendem à necessidade a longo prazo. Como descrito em um posto anterior:
A gestão tradicional de projetos assume que os projetos 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 entendem 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 projetos similares. É claro que o progresso real é muito fácil de se ver.
As implementações de software empresarial são complexas. Os projetos de Planejamento de Recursos Governamentais (GRP) são transformacionais. São necessários especialistas em finanças, recursos humanos ou aquisições governamentais. Assim como os especialistas em TI. Os usuários precisam de treinamento especial. (Os usuários de ponte não precisam de treinamento novo). Mais importante ainda, os projetos de GRP transformam e automatizam processos que causam resistência significativa a mudanças.
Projetos de TI do Governo Legado em Cascata
As técnicas de cascata assumem que todo o planejamento pode ser realizado antes que o software possa ser adaptado. Assume-se que o resultado final do software atenderá às expectativas devido ao trabalho de projeto rigoroso.
O pensamento antigo prevê que os projetos de reforma de TI e PFM sejam previsíveis. As práticas legadas são impostas aos empreiteiros a fim de reduzir os riscos percebidos. Nossa análise dos projetos FreeBalance, projetos de outras empresas e a literatura sobre gerenciamento de projetos e reforma da GFP nos levou à conclusão de que as práticas de cascata aumentar significativamente o risco do projeto.
O trabalho de projeto, que consiste na análise "As-Is" e "To-Be" nos Documentos de Requisitos de Software, muitas vezes leva até um ano para ser concluído.
- Implementações de âncoras com foco em documentação sobre como os sistemas legados funcionam, em vez de objetivos governamentais
- O foco na documentação conduz a uma personalização desnecessária do código
- O foco na solução inclui "melhores práticas" inadequadas de diferentes contextos, desconectando projetos de problemas a serem superados
- O foco no contrato dá ênfase a listas de verificação funcionais, em detrimento de necessidades não-funcionais como a usabilidade, e manejáveis
Os governos freqüentemente descobrem que a análise das necessidades tradicionais não consegue descobrir as exigências abrangentes. Isso porque a análise opera em um vácuo, sem um contexto mais amplo de como os trabalhos governamentais são realmente realizados, que problemas precisam ser resolvidos e que práticas emergentes poderiam ser alavancadas para a mudança.
Sejamos francos: há décadas os governos vêm implementando software comercial para as necessidades de GRP e PFM. As práticas legadas têm restringido o sucesso. Isto ocorre em um momento 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 redes sociais. Implementar a cadeia de bloqueio e a inteligência artificial.
Os governos estão enfrentando 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 o Gerenciamento de Projetos de TI do Governo]()
A Evolução Ágil do Governo
Os governos, como as grandes empresas, operam muitos sistemas de TI. Preocupações legítimas sobre segurança, desempenho, qualidade e confiabilidade significam que os governos precisam de uma forte governança de TI. A mudança de uma implementação ágil para uma implementação ágil não deve comprometer a governança de TI. O Grupo Gartner, por exemplo, recomenda um bi-modal abordagem à TI: "Bimodal é a prática de gerenciar dois estilos de trabalho separados, mas coerentes: um focado na previsibilidade; o outro na exploração. O modo 1 é otimizado para áreas que são mais previsíveis e bem compreendidas. Ele se concentra na exploração do que é conhecido, enquanto renova o ambiente legado em um estado que é adequado para um mundo digital. O Modo 2 é exploratório, experimentando para resolver novos problemas e otimizado para áreas de incerteza..”
Muitos observadores acreditam que o bi-modal não vai longe o suficiente. O analista Dion Hinchcliffe, por exemplo, afirma que "o bi-modal não vai longe o suficiente.o mundo real da tecnologia e as atividades que a fazem frutificar não podem ser compartimentadas em uma estrutura dupla.” O sucesso pode ser melhor encontrado em uma abordagem multimodal. Ou, considerando processos mais ágeis de implementação e processos mais rígidos pós-implementação.
Ágil no mundo real
Como 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 setor público. Os padrões de sucesso levaram à atualização de nossa ágil metodologia, A-i3+qMTM.
Vimos que nossas experiências positivas de implementação alinhadas com as técnicas ágeis praticadas em empresas inovadoras da Internet. Também se alinhou com as práticas emergentes do desenvolvimento do país. Os padrões de sucesso se coalesceram 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. E, o código do software COTS raramente é adaptado pelo fabricante para atender às necessidades do cliente. O código personalizado órfão é desenvolvido em seu lugar. A FreeBalance tem integrado a implementação e o desenvolvimento de produtos há décadas. O código personalizado aumenta nosso software COTS. Esta abordagem opera de forma semelhante a DevOpsUm 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 setor público. Descobrimos isso 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 práticas muito ruins de legado. Era necessário o engajamento dos usuários e da equipe do projeto. A FreeBalance desenvolveu oficinas de engajamento como um lean mecanismo para comunicar o contexto. E, aprendemos com a abordagem emergente da "tela", como a Modelo de negócio Telapara criar estruturas de oficinas específicas do governo.
- Storyboards: A estrutura de especificações do FreeBalance foi revisada em 2008 para refletir a abordagem de componentes reutilizáveis, que chamamos de "entidades governamentais". Isto inclui a articulação dos parâmetros da entidade e da entidade. Estes parâmetros permitem uma configurabilidade massiva. A interação entre as entidades é definida. Isso porque as entidades são reutilizadas entre as aplicações. Tudo isso faz perfeito sentido para os desenvolvedores de nossos produtos, mas é abstrato para os especialistas em PFM. Desenvolvemos uma abordagem de storyboard para facilitar o desenvolvimento de especificações usando uma abordagem de pensamento em design. Isto foi ampliado em nossa metodologia ágil e atualizada. (Demonstrado durante Oficinas FISC 2018.)
- Gerenciamento de mudanças: A gestão da mudança organizacional é particularmente desafiadora no governo. Aprendemos com o Adaptação Iterativa Orientada por Problemas (PDIA) a partir da abordagem Escola Kennedy de Harvard. A PDIA abrange muito mais do que a gestão de mudanças. A técnica tem uma abordagem ideal focada 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 usuários. Chegamos à conclusão de que a Tela de Proposta de Valor é uma ferramenta ideal a ser usada. (Demonstrado durante Oficinas 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 comercial PESTLE (político, econômico, social, tecnológico, jurídico, ambiental) para o contexto governamental. (Manifestado durante Oficinas 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 um manifesto, para o desenvolvimento passo a passo do governo, que inclui a PDIA
Resultados da implementação ágil
A-i3+qMTM cobre todo o ciclo de vida do projeto, começando com nossa proposta aos governos. Avaliamos previamente fatores de risco, tais como restrições do programa, contradições de requisitos e más práticas. Isto determina nossa abordagem de risco e informa a negociação de contratos.
A chave A-i3+qMTM característica é a iteração de processos centrais que são entregues em série em cascata. Estes processos paralelos começam com o treinamento obrigatório do produto. As equipes de projeto do governo precisam ver as capacidades do sistema em ação. Isto é usado para oficinas de configuração e customização. A capacidade é construída em paralelo. As configurações são assinadas quando vistas em ação. Assim como o código personalizado. O progresso é visual.
A-i3+qMTM acelera a implementação, ancorando os projetos nas aspirações de ganho e nas capacidades do novo sistema. Configuração não precisa de muita documentação, apenas de um plano de saída da suíte FreeBalance Accountability. O desenvolvimento personalizado processo reduz a complexidade para que os especialistas em PFM articulem e validem as necessidades.
A-i3+qMTM O processo de desenvolvimento personalizado inclui:
- A equipe de serviços no local da FreeBalance constrói storyboards e utiliza os casos de forma interativa com os clientes
- A equipe de gerenciamento de produtos FreeBalance valida essa entrada usando conhecimento tecnológico e identifica como as entidades governamentais podem ser ampliadas para outros requisitos do Mapa de Componentes PFM
- Os storyboards validados e os casos de uso são aprovados pelos clientes
- O pessoal de gerenciamento de produtos FreeBalance desenvolve especificações
- O desenvolvimento de produtos FreeBalance valida as especificações antes de desenvolver o código
- O pessoal de serviços no local da FreeBalance acrescenta à garantia de qualidade para garantir que o resultado atenda às necessidades do país
- O teste de aceitação do usuário cliente valida o uso do código na produção (ou demonstra a necessidade de adaptar as especificações)
A repetibilidade é um desafio central 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, que pode ser implantado on-line, seguindo uma série de etapas de oficina para brainstorming e tomada de decisão
Alternativamente, pode ser implantado on-line - Pranchas: Grande espaço de trabalho visível, normalmente de parede ou grande quadro branco, que pode ser implantado on-line, representando dinamicamente as atividades em andamento
Alternativamente, pode ser implantado on-line - Plantas: Descrição de uma configuração FreeBalance que inclui regras comerciais e articulação de fluxo de trabalho, desenvolvimento customizado 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 artefatos de projeto
Apêndice: A-i3+qMTM Descrição
As características do A-i3+qM metodologia são:
- Acelerado eliminando tantos processos legados de cascata que levam a problemas no projeto. Isto inclui documentação desnecessária e planos detalhados do projeto, em favor de oficinas e etapas curtas do processo. Os tamanhos das equipes são mantidos pequenos para permitir a comunicação com o 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 às exigências do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores e a equipe de desenvolvimento. As equipes de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
- Iterativo ser responsiva às mudanças do cliente e de implementação utilizando fases. A metodologia alavanca o melhor das metodologias comprovadas de desenvolvimento de software e serviços "lean" com workshops, pequenas iterações, histórias de usuários, marcos miliários e a capacidade de mostrar progresso. Estas técnicas são estendidas além da organização de desenvolvimento para serviços de implementação alavancando ganhos de produtividade e a capacidade de reagir às exigências do cliente.
- Implementação-focados com modelos de boas práticas e processos comprovados de gerenciamento de programas. Esta metodologia está focada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objetivos internos ou arbitrários. A implementação e o desenvolvimento de produtos são gerenciados através de um Escritório de Gerenciamento de Programas.
- Qualidade assegura que o software seja liberado e suportado atendendo às boas práticas do Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, estresse e regressão. A qualidade é integrada com a implementação onde os testes FreeBalance são baseados nos ambientes do cliente.