Pergunto-me se os especialistas em gerenciamento de projetos acham que uma boa documentação teria impedido Otelo de matar Desdêmona. Será que Otelo, em um acesso de fúria, teria 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 escopo da documentação se tornou uma "prática recomendada" nas implementações de TI no governo. As assinaturas 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 precisão da documentação, a tantos problemas de TI e de gerenciamento de riscos. Falhas de ERP no governo. Esta postagem expande uma das falha na documentação padrão descrito em minhas publicações do ano passado: O paradoxo do projeto governamental e Fortuna ultrajante dos processos em cascata no governo. Ele também apresenta uma abordagem ágil baseada em riscos para a documentação do projeto.
Qual é a justificativa para a documentação detalhada do projeto?
Há um longo legado de documentação de projetos para implementações complexas de software. Muitas vezes, ela é considerada uma solução para o problema frequentemente encontrado no governo: o software corporativo não segue os processos necessários. A ideia é que uma articulação profunda dos processos atuais ("como estão") garantirá que o software resultante atenda às necessidades operacionais. Além disso, uma análise detalhada desses processos identificará o que precisa ser alterado ("fit-gap") para descrever completamente uma situação aprimorada ("to-be").
Isso geralmente exige que as empresas de integração de sistemas se reúnam com especialistas em processos do governo em exercícios complexos de mapeamento de processos. Essas empresas geralmente culpam os especialistas do governo por não articularem totalmente os processos quando as implementações dão errado.
Qual é o contexto da documentação como solução?
Minha impressão é que a cerimônia de conformidade da documentação tem mais probabilidade de levar o projeto ao fracasso do que ao sucesso. A articulação detalhada do "como está" é tão útil para fazer os sistemas funcionarem quanto as peças de mobília quebradas na seção "como está" da Ikea são para mobiliar uma casa. Há um motivo pelo qual os sistemas devem ser substituídos. Portanto, os processos de negócios "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 "como está"?
- A resistência à mudança aumenta Como as partes interessadas e os usuários não veem progresso, isso dá tempo para que as forças contrárias à mudança sabotem o projeto
- "Tal como está" aciona "a ser" porque o primeiro conjunto de documentação se torna a âncora conceitual, especialmente porque a resistência à mudança aumenta
- Código excessivamente personalizado escopo, tempo e custos futuros de atualização que aumenta porque as partes interessadas exigem que o novo sistema se comporte como o antigo
- A realidade raramente é documentada porque os funcionários do governo raramente descrevem as soluções alternativas usadas nos sistemas atuais, as práticas que não estão em conformidade, como a segregação de funções não respeitada, ou como os sistemas são realmente usados, como, por exemplo, para registrar transações que já ocorreram
- O que é artificial se torna evangélico por causa das limitações dos sistemas anteriores, leva os especialistas do governo a concluir que estruturas artificiais, como a separação das classificações orçamentárias das classificações contábeis, ou a separação dos sistemas executivo e ministerial, ou métodos estranhos de gerenciamento de compromissos ou caixa, são de alguma forma naturais
- O que é importante está oculto em páginas de documentação e a rastreabilidade entre processos, configurações e personalizações torna-se difícil
A quantidade de documentação geralmente supera a qualidade da documentação porque a quantidade fornece a primeira prova visceral de que a equipe do projeto fez algo. Mas, como um de meus professores universitários respondeu à pergunta sobre o tamanho de uma redação: "20 páginas, mas se você tiver tempo, faça 12."
Como a qualidade da documentação do projeto pode melhorar com a redução da quantidade de documentação?
A transparência do projeto não deve esperar por ninguém. Mas tenho a impressão de que a opinião é que nada aconteceu até que tenha sido documentado. Não importa se a árvore que caiu na floresta fez barulho ou não. No software empresarial do governo, a árvore só caiu se tiver sido documentada. Por que as partes interessadas devem esperar tanto tempo para descobrir se algo aconteceu ou está acontecendo?
A baseado em riscos é necessária uma abordagem de gerenciamento de projetos.
É nesse ponto que os processos e técnicas ágeis são mais eficazes: mostrar o status dos projetos quase em tempo real. Os processos ágeis podem usar quadros kanban, scrum ou scrumban para mostrar o progresso, as tarefas, as prioridades e as atribuições de tarefas. A diferença entre as histórias de usuários reais e estimadas permite prever a conclusão de marcos muito melhor do que os gráficos GANTT tradicionais. As equipes de projeto não precisam documentar o status para tirar fotos do quadro. A quantidade de tarefas não concluídas alerta as equipes de projeto. Os problemas se tornam visíveis.
Esses problemas devem ser documentados e as partes interessadas alertadas para que as decisões possam ser tomadas. Há uma razão para que os regimes de business intelligence tenham se concentrado em relatórios de exceções para as principais partes interessadas. Está mais do que na hora de ter relatórios de exceções na documentação. E ter um alerta antecipado. As partes interessadas entenderão que o alerta por e-mail é fundamental, e não apenas mais um conjunto de documentação atualizada do projeto.
Como a documentação do projeto pode variar de acordo com o contexto?
A mentalidade de documentação em projetos governamentais raramente é baseada em riscos. 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 usuário que incluem a documentação do projeto. Isso aumenta a complexidade dos procedimentos de teste. Desenvolvemos um método diferente que recomendamos a qualquer governo que pretenda implementar software COTS (Commercial-Off-The-Shelf), inclusive da FreeBalance:
- Ancorar o projeto de forma diferenteTreinamento: comece treinando a equipe do projeto do governo no novo software COTS, mostrando como os objetivos "a serem" do governo podem ser alcançados e como o software COTS atende aos requisitos de maneiras diferentes das concebidas no projeto anterior.
- Separe a configuração da personalizaçãoalterações de configuração do workshop com a equipe do projeto do governo e os usuários finais, com assinaturas de configuração quando demonstradas, enquanto a personalização do código segue processos ágeis
- Personalização baseada em risco e valorIdentificar e documentar os riscos de custo-benefício de qualquer iniciativa de personalização para melhorar a tomada de decisões sobre o projeto
- Documentação ágilUtilize e documente protótipos e storyboards para obter a aprovação da personalização, em vez de confiar na documentação tradicional.
- Testes ágeisO teste de configuração durante toda a implementação reduz a carga sobre o teste de aceitação final, que será mais focado no risco: personalização, em que a qualidade da documentação é extremamente importante
Como essa abordagem ágil resolve a tragédia da documentação do projeto?
- Diminuição da resistência à mudança porque as partes interessadas e os usuários veem o progresso da configuração e os workshops demonstram disposição para receber as contribuições dos usuários
- O "To-be" impulsiona o projeto porque as iterações se concentram nos objetivos do governo
- Personalização contida porque os recursos completos do software COTS são explorados em relação aos objetivos "a serem", e personalização como exceção está totalmente documentado
- A realidade está incorporada porque a equipe do governo descreve as práticas durante os workshops de configuração e os especialistas do fornecedor (isso pressupõe que o fornecedor entenda o domínio) explicam os motivos das mudanças nas práticas
- O que é artificial se torna racionalizado porque o software COTS não impõe essas restrições, supondo que o software tenha sido efetivamente projetado
- O que é importante é visível em menos páginas de documentação com rastreabilidade eficaz e uso de quadros ágeis para fornecer relatórios em andamento