Agilizar ou não agilizar, essa é a questão de classe=

Agilizar ou não agilizar, eis a questão

Posted on em Transformação Digital do Governo

A fortuna escandalosa dos processos em cascata na administração pública

"Se é mais nobre na mente sofrer
Os golpes da fortuna escandalosa,
Ou para pegar em armas contra um mar de problemas,
E por oposição a eles?" - Hamlet por William Shakespeare
Muitas iniciativas governamentais no domínio das TI funcionam como tragédias gregas: todos o esforço para reduzir o risco do projeto acaba por aumentar o risco. E as elevadas taxas de insucesso, especialmente quando adaptar o software de planeamento de recursos empresariais (ERP), originalmente desenvolvido para o sector privado, à administração pública.
As TI governamentais têm também uma conotação de tragédia shakespeariana. Os governos e os parceiros doadores impõem frequentemente as "melhores práticas" de gestão de projectos a fornecedores como a FreeBalance. Uma dessas "melhores práticas" é a imposição de gestão de projectos do tipo queda de água que pressupõe que os projectos de software são tão previsíveis como os projectos de construção. A construção beneficia de restrições físicas, como a resistência dos materiais. O software tem muito menos restrições e mais oportunidades de personalização.
Conceção do projeto FreeBalance Waterfall
A imposição de práticas em cascata aumenta a "fortuna escandalosa". A gestão ágil de projectos pode aumentar os rácios de sucesso?

Batalhões de cascatas de tristezas

"Quando as tristezas chegam, não vêm sozinhas. Mas em batalhões!" - Hamlet por William Shakespeare
Um inquérito recente realizado por Accenture e NASCIO (National Association of State Chief Information Officers) concluiu que "quando questionados sobre os resultados que poderiam ser evitados com a utilização do método ágil, 70% dos profissionais de TI consideraram que ajudava a evitar o desperdício de dinheiro em projectos de TI ineficazes, 66% consideraram que ajudava a evitar grandes fracassos de projectos de TI e 58% afirmaram que ajudava a evitar programas que não satisfazem as necessidades da empresa.”
Técnicas ágeis como magra, pensamento de design, Extremo, Kanbane Scrum têm sido frequentemente associadas a pequenos projectos. A ideia, entre os observadores tradicionais, é que o Agile não é adequado para grandes projectos de TI. Como um Mitre estudo para o Departamento de Defesa dos Estados Unidos assinalouNa maioria dos projectos ágeis, os projectos em cascata assumem incorretamente requisitos bem definidos com mudanças limitadas. A realidade é que a metodologia ágil é muito mais resistente à mudança e à incerteza do que a metodologia em cascata. O Agile é ideal para iniciativas substanciais de Planeamento de Recursos Governamentais (GRP). Isto deve-se aos conhecimentos adquiridos durante a implementação do projeto que podem alinhar melhor a funcionalidade com as necessidades reais do governo. A maioria das implementações de sistemas GRP segue-se à reforma e modernização do governo. Não se trata apenas de TI, trata-se de transformação.
É aqui que o ágil se destaca.
Escalas ágeis. De pequenos a grandes projectos.

Agilizar ou não agilizar? Uma lista de controlo ABC

"Há mais coisas no céu e na terra, Horácio,
do que sonha a vossa filosofia". - Hamlet por William Shakespeare
Nem todos os projectos em cascata falham. Nem todos os projectos ágeis são bem sucedidos. (Para ser justo, o ágil centra-se na aprendizagem, por isso falhar rapidamente é frequentemente um fator de sucesso).
O Grupo de Estratégia e Inovação FreeBalance analisou a literatura sobre projectos e as nossas experiências governamentais. (Ao contrário dos antigos fornecedores de software empresarial, a FreeBalance participa em todas as implementações para ajudar a melhorar os produtos e serviços). Essa análise levou ao nosso A-i3+qM metodologia. Levou também a uma reavaliação significativa das práticas tradicionais e da filosofia dessas práticas.
Criámos também uma lista de verificação de 26 pontos para a classificação dos factores. Os factores são classificados entre baixo e alto. O seu contexto pode ser diferente.
Factores que favorecem a queda de água A-F
Lista de verificação Agile ou Waterfall no GRP
Factores que favorecem o Agile G-Z
Factores que favorecem o Agile G-Z

  1. Complexidade arquitetónicaA necessidade de desenvolver arquitecturas de software a partir do zero tende a exigir longos períodos de conceção para além de múltiplas iterações embora isto não se aplique a arquitecturas disponíveis no mercado, como o Plataforma de responsabilização FreeBalance
  2. Problemas bem compreendidos: uma visão aprofundada dos problemas reduz a necessidade de obter informações adicionais através de uma abordagem ágil. embora muitos (a maioria?) dos grandes projectos de TI da administração pública estejam centrados em soluções que raramente resolvem problemas reais sem alterações
  3. Experiência em circunstâncias semelhantesA experiência da organização governamental na implementação de iniciativas semelhantes torna os projectos mais previsíveis. embora muitas organizações governamentais assumam a experiência do fornecedor fora de contexto, como a experiência do fornecedor noutros contextos
  4. Número de efectivos: o método ágil funciona bem com pequenas equipas motivadas que operam de forma eficiente embora se deva notar que os projectos em cascata requerem mais pessoal para comunicações, coordenação e documentação do que os projectos ágeis
  5. Âmbito de aplicaçãoO âmbito do projeto totalmente articulado e a atenção centrada no âmbito que determina o tempo e os recursos, presta-se a controlos em cascata que reduzem o "desfasamento do âmbito". embora muitos projectos fracassem devido a alterações de âmbito inflexíveis que privilegiam as disposições contratuais em detrimento das necessidades reais do governo
  6. Capacidade humanaA elevada capacidade humana do governo em matéria de tecnologia, gestão de projectos e gestão das finanças públicas (GFP) atenua muitos dos riscos associados à abordagem em cascata. embora uma capacidade elevada esteja frequentemente associada a um excesso de confiança
  7. Complexidade do projeto: o método ágil ajuda a decompor a complexidade e a estruturar as actividades com base em prioridades, através de protótipos, contributos dos utilizadores e análise da conceção
  8. Incerteza do projeto: o método ágil é ideal quando a incerteza do projeto é elevada
  9. Taxas de falha de TI: o método ágil fornece ferramentas de sucesso para as equipas de TI que tenham tido um historial de resultados pouco satisfatórios
  10. Funções inter-domíniosO método cascata funciona melhor em silos, envolvendo especialistas no domínio, e o método ágil funciona melhor quando as funções se cruzam em silos como as finanças, as aquisições, os salários e a administração fiscal
  11. Orientado para os resultados: os projectos concebidos para obter resultados beneficiam dos processos ágeis porque os projectos em cascata se centram no cumprimento dos contratos
  12. Mudança transformacional: os projectos que seguem a modernização, reforma ou reorganização beneficiam de processos ágeis que são mais transparentes, comunicativos e flexíveis do que os processos em cascata
  13. Desenvolvimento personalizado: expetativa de desenvolvimento personalizado (por exemplo, desenvolvimento personalizado utilizando uma plataforma técnica, desenvolvimento personalizado utilizando um plataforma de governaçãoou desenvolvimento personalizado utilizando ERP) beneficia de uma abordagem ágil que identifica o valor de cada elemento personalizado
  14. Nível atual da tecnologia herdadaA organização governamental que utiliza tecnologia antiga (mainframes, COBOL, 4GLs) ou tecnologia herdada (a maioria dos sistemas ERP proprietários, incluindo os de nível 1) beneficia dos novos olhares associados à agilidade
  15. Envolvimento do utilizador: o método ágil é excelente quando os utilizadores têm de articular problemas, identificar soluções, testar funcionalidades e defender novos sistemas
  16. Mudança de funcionalidade: o método ágil é excelente quando são introduzidas muitas funções novas em relação ao sistema antigo
  17. Implementação Greenfield: as actualizações dos sistemas existentes podem ser implementadas em cascata, ao passo que a implementação de software novo em rede beneficia do método ágil
  18. Alteração de requisitosO método cascata prevê muito poucas alterações aos requisitos, enquanto o método ágil é resistente à mudança, identificando as alterações às especificações numa fase precoce para reduzir os custos, em comparação com a identificação das alterações necessárias numa fase posterior dos projectos
  19. Dependências do sistemaOs processos em cascata beneficiam de menos dependências do sistema, tais como pontos de integração com outros sistemas, enquanto os processos ágeis são mais capazes de se integrar em múltiplos domínios governamentais e tecnologias subjacentes
  20. Novidade do produtoO método ágil é ideal quando os projectos estão a implementar conjuntos de produtos relativamente novos
  21. Resistência à mudançaA abordagem em cascata não é eficaz em situações em que a resistência dos utilizadores e dos gestores à mudança é elevada, ao passo que a abordagem ágil dispõe de processos mais integrados que facilitam e integram a gestão da mudança (a gestão da mudança em projectos em cascata é frequentemente ineficaz)
  22. Foco na qualidadeOs processos em cascata colocam os testes e a garantia de qualidade numa fase tardia da metodologia, ao passo que os processos ágeis se centram na qualidade em cada "história do utilizador", o que permite melhorar a qualidade desde o início
  23. Extensibilidade do sistema: o método ágil é excelente quando o software existente ou novo precisa de ser alargado a funções adicionais através da reutilização
  24. Relatórios e painéis de controlo personalizadosa articulação dos relatórios, incluindo a replicação de relatórios obrigatórios em novo software e a criação de novos relatórios, painéis de controlo e análises, beneficia de iterações ágeis, porque os utilizadores reconhecem frequentemente as melhorias quando vêem os resultados dos relatórios
  25. Velocidade de implementaçãoO método ágil é excelente em termos de velocidade de implementação e fornece informações de desempenho mais eficazes ("cadência") do que o método cascata, para prever o tempo de conclusão do projeto
  26. Transparência dos projectosO método cascata pressupõe a existência de equipas separadas que reportam em função de marcos, enquanto o método ágil pressupõe uma transparência constante do projeto através de quadros Kanban, Scrum ou Srumban e um envolvimento frequente com os utilizadores e as partes interessadas

Notas importantes

  • Os diagramas acima mostram que o método ágil é preferível nas duas primeiras colunas da lista de controlo. Não se trata de um erro.
  • É provável que a sua lista de controlo apresente itens nas 3 colunas. Utilize isto como um risco

Metodologias "ágeis" de fornecedores intrigantes

"Isso confunde a vontade." - Hamlet por William Shakespeare
Muitos fornecedores de software empresarial estabelecidos, incluindo fornecedores de ERP de nível 1, estão a promover processos ágeis. Os integradores de sistemas precisam de apoiar estes processos orientados para os fornecedores de forma a obterem certificação. É surpreendente como esses chamados processos ágeis não são ágeis.
O método ágil é muitas vezes adicionado ao método cascata, acrescentando complexidade ao processo. Ou, descrevendo apresentações de comunicação de marcos como ágeis. Muitos destes processos impõem "boas práticas" em funções que raramente são as melhores ou as mais adequadas. A aceleração do projeto nestas metodologias centra-se na execução do que está no software sem alterações, em vez de se adequar às necessidades reais do governo. (As implementações "Vanilla" raramente satisfazem as necessidades do governo.)

Uma rosa ágil?

"Uma rosa com qualquer outro nome teria um cheiro tão doce" - Romeu e Julieta por William Shakespeare
Muitos fornecedores tentam redefinir a cascata como ágil. Isso não mudará a natureza do processo. Não terá o cheiro doce do ágil.

Fontes adicionais

Referências específicas do governo

Referências gerais

Tópicos

Contacto