Pergunto-me se os especialistas em gestão de projectos pensam que uma boa documentação teria impedido Otelo de matar Desdémona. Teria Otelo, enraivecido, consultado a espessa pasta que atestava o amor e a fidelidade de Desdémona? Shakespeare chegou ao ponto crucial da tragédia: a comunicação informal de Iago.
No entanto, o âmbito da documentação tornou-se uma "melhor prática" nas implementações de TI na administração pública. As aprovações são atrasadas porque a documentação de apoio não é suficientemente pesada. Parece-me que muitos observadores atribuem a falta de documentação, ou a exactidão da documentação, a tantos problemas informáticos e de segurança. Falhas de ERP na administração pública. Este post expande uma das falha na documentação padrão descrito nas minhas publicações do ano passado: O Paradoxo do Projecto Governamental e A escandalosa fortuna dos processos em cascata na administração pública. Introduz também uma abordagem ágil baseada no risco para a documentação do projecto.
Qual é a razão de ser da documentação detalhada do projecto?
Existe um longo legado de documentação de projectos para implementações de software complexas. É muitas vezes considerada uma solução para o problema frequentemente encontrado na administração pública: o software empresarial não segue os processos necessários. A ideia é que uma articulação profunda dos processos actuais ("tal como estão") garantirá que o software resultante satisfaz as necessidades operacionais. Além disso, uma análise aprofundada desses processos identificará o que precisa de ser alterado ("fit-gap") para descrever integralmente uma situação melhorada ("to-be").
Isto exige frequentemente que as empresas de integração de sistemas se sentem com os peritos em processos governamentais em exercícios complexos de mapeamento de processos. Estas empresas acusam frequentemente os peritos governamentais de não articularem totalmente os processos quando as implementações correm mal.
Qual é o contexto da documentação como solução?
A minha sensação é que a cerimónia de conformidade da documentação tem mais probabilidades de levar o projecto ao fracasso do que ao sucesso. A articulação detalhada do "como está" é tão útil para fazer os sistemas funcionarem como as peças de mobiliário partido na secção "como está" do Ikea são para mobilar uma casa. Há uma razão pela qual os sistemas devem ser substituídos. Portanto, os processos empresariais "a serem" estão no caminho crítico. É necessária uma abordagem mais coerente.
O que acontece durante o longo processo de descoberta e documentação "tal como está"?
- A resistência à mudança aumenta porque as partes interessadas e os utilizadores não vêem qualquer progresso, dá tempo para que as forças contra a mudança sabotem o projecto
- O "tal como está" conduz ao "a ser" porque o primeiro conjunto de documentação se torna a âncora conceptual, especialmente porque a resistência à mudança aumenta
- Código excessivamente personalizado âmbito, tempo e custos de actualização futuros que aumenta porque as partes interessadas exigem que o novo sistema se comporte como o antigo
- A realidade raramente é documentada porque o pessoal da administração pública raramente descreve as soluções alternativas utilizadas nos sistemas actuais, as práticas que não estão em conformidade, como a separação de funções não respeitada, ou a forma como os sistemas são realmente utilizados, por exemplo, para registar transacções que já ocorreram
- O que é artificial torna-se evangélico devido a limitações dos sistemas anteriores, leva os peritos governamentais a concluir que estruturas artificiais como a separação entre classificações orçamentais e classificações contabilísticas, ou a separação entre sistemas executivos e ministeriais, ou métodos estranhos de gestão de autorizações ou de tesouraria são de alguma forma naturais
- O que é importante está escondido em páginas de documentação e a rastreabilidade entre processos, configurações e personalizações torna-se difícil
Muitas vezes, a quantidade de documentação supera a qualidade da documentação porque a quantidade fornece a primeira prova visceral de que a equipa do projecto fez alguma coisa. Mas, como um dos meus professores universitários respondeu à pergunta sobre o tamanho de um ensaio: "20 páginas, mas se tiveres tempo, faz 12".
Como se pode melhorar a qualidade da documentação do projecto reduzindo a quantidade de documentação?
A transparência dos projectos não deve esperar por ninguém. Mas tenho a impressão de que a opinião é a de que nada aconteceu enquanto não foi documentado. Não importa se a árvore que caiu na floresta fez barulho ou não. No software empresarial governamental, a árvore só caiu se estiver documentada. Porque é que as partes interessadas devem esperar tanto tempo para saber se algo aconteceu ou está a acontecer?
A baseado no risco é necessária uma abordagem da gestão de projectos.
É aí que os processos e técnicas ágeis são mais eficazes: mostrar o estado dos projectos quase em tempo real. Os processos ágeis podem utilizar quadros kanban, scrum ou scrumban para mostrar o progresso, as tarefas, as prioridades e a atribuição de tarefas. A diferença entre as histórias de utilizadores reais e estimadas permite prever a conclusão das etapas muito melhor do que os gráficos GANTT tradicionais. As equipas de projecto não têm de documentar o estado do projecto, nem de tirar fotografias do quadro. As quantidades de tarefas não concluídas alertam as equipas de projecto. Os problemas tornam-se visíveis.
Estes problemas devem ser documentados e as partes interessadas devem ser alertadas para que possam ser tomadas decisões. Há uma razão para que os regimes de business intelligence se tenham centrado em relatórios de excepção para as principais partes interessadas. É mais do que tempo de incluir os relatórios de excepção na documentação. E de haver um alerta precoce. As partes interessadas compreenderão que o alerta por correio electrónico é fundamental e não apenas mais um conjunto de documentação actualizada do projecto.
Como pode a documentação do projecto diferir em função do contexto?
A mentalidade de documentação nos projectos governamentais raramente se baseia no risco. O retorno de documentar tudo é cada vez menor. No entanto, é esse o caso de muitos contratos governamentais em que a aprovação final é baseada em testes completos de aceitação do utilizador que incluem a documentação do projecto. Isto acrescenta complexidade aos procedimentos de teste. Nós desenvolvemos um método diferente que recomendamos a qualquer governo que pretenda implementar software comercial fora da prateleira (COTS), incluindo da FreeBalance:
- Ancorar o projecto de forma diferente: começar por dar formação ao pessoal do projecto governamental sobre o novo software COTS, mostrando como os objectivos "a atingir" do governo podem ser alcançados e como o software COTS satisfaz os requisitos de formas diferentes das concebidas no projecto anterior
- Separar a configuração da personalizaçãoalterações de configuração do workshop com o pessoal do projecto governamental e os utilizadores finais, com aprovação da configuração quando demonstrado, enquanto a personalização do código segue processos ágeis
- Personalização baseada no risco e no valor: identificar e documentar os riscos de custo-benefício de qualquer iniciativa de personalização para melhorar a tomada de decisões sobre o projecto
- Documentação ágil: aproveite e documente protótipos e storyboards para obter a aprovação da personalização, em vez de se basear na documentação tradicional
- Testes ágeis: os testes de configuração ao longo da implementação reduzem o ónus dos testes de aceitação final, que se centrarão mais no risco: personalização, em que a qualidade da documentação é extremamente importante
Como é que esta abordagem ágil resolve a tragédia da documentação do projecto?
- Diminuição da resistência à mudança porque as partes interessadas e os utilizadores vêem os progressos da configuração e os seminários demonstram vontade de ter em conta os contributos dos utilizadores
- O "a ser" impulsiona o projecto porque as iterações se centram nos objectivos do governo
- Personalização contida porque as funcionalidades completas do software COTS são exploradas em relação aos objectivos "a atingir", e personalização como excepção está totalmente documentado
- A realidade está incorporada porque o pessoal do governo descreve as práticas durante os seminários de configuração e os peritos dos fornecedores (isto pressupõe que o fornecedor compreende o domínio) explicam as razões para as mudanças de práticas
- O que é artificial torna-se racionalizado porque o software COTS não impõe estas restrições, partindo do princípio de que o software foi efectivamente concebido
- O que é importante é visível com menos páginas de documentação, com uma rastreabilidade eficaz e com a utilização de quadros ágeis para apresentar relatórios em curso