APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um projeto de TI deve ligar uma necessidade a resultados que alguém consegue reconhecer e aceitar. Começa por identificar patrocinador, utilizadores, responsáveis de serviço e quem decide alterações de âmbito, orçamento e prazo. Distingue o produto entregue do benefício esperado: instalar uma plataforma não demonstra que o fecho ficou mais rápido ou que o suporte ganhou autonomia. Define fronteiras, exclusões, pressupostos e dependências. Os critérios de aceitação devem indicar resultado, evidência e responsável, incluindo requisitos não funcionais relevantes. PM² é uma referência pública para organizar estas decisões; a sua estrutura deve ser adaptada ao contexto e não representa regras internas de qualquer banco.
Aplicação guiada
Num projeto fictício de migração de relatórios, o pedido inicial é mover a aplicação para cloud. Pergunta que problema resolve, que fluxos e consumidores inclui e como serão demonstradas correção, desempenho e recuperação. Inclui a atualização dos runbooks e formação do suporte no âmbito, em vez de os deixar como trabalho implícito. Um business case explica a razão do investimento; o mandato e os planos tornam o compromisso executável. Combina revisões formais com entregas incrementais quando isso permite aprender mais cedo. A adoção de práticas ágeis não elimina responsáveis por aceitação, decisões de financiamento ou condições de passagem à fase seguinte.
Construir uma matriz de aceitação
Liga cada resultado obrigatório a uma verificação, responsável e evidência. Uma matriz simples pode separar integração, recuperação e formação. Se integração passou, recuperação falhou e formação não foi observada, conserva os três estados. Uma falha exige correção ou decisão aplicável; ausência de evidência exige demonstração antes de concluir. Não calcules maioria de critérios quando todos são obrigatórios. A assinatura final deve refletir o resultado real, incluindo condições e ações, e não apenas a existência de documentos ou o esforço já gasto pela equipa.
Resolver fronteiras contraditórias
Num protótipo fictício, o âmbito exclui dados anteriores a dois anos, mas a consulta obrigatória exige cinco. O PM deve tornar a contradição visível antes de construir a solução definitiva. Compara alternativas, como acesso histórico separado ou alteração autorizada do âmbito, e identifica impactos em custo, operação e aceitação. A assinatura de dois textos incompatíveis não torna ambos executáveis. Evita alterar apenas o teste para obter sucesso aparente. Quando muda o representante do negócio, revê também estes compromissos e confirma quem tem mandato para aceitar.
Prática: concluir apenas dentro da evidência
Usa a matriz abaixo para redigir a recomendação. Identifica o que passou, o que falhou e o que continua desconhecido, sem transformar esses estados numa percentagem de sucesso global. Depois aplica o mesmo raciocínio a um teste de cem ficheiros pequenos: o resultado não demonstra comportamento de ficheiros grandes e nomes multilingues. No trabalho, pede classes representativas dos fluxos acordados e conserva o alcance da amostra. Termina com a decisão necessária, o responsável por produzir a evidência em falta e o prazo para voltar a avaliar.
Synthetic acceptance matrix / Matriz fictícia
integration = passed
recovery = failed
training = unknown
all_required = true
acceptance_demonstrated = false
failed_checks = [recovery]; missing_evidence = [training]Entrega: plataforma instalada. Aceitação: fluxo reconciliado. Benefício: redução medida do tempo de fecho.
Armadilhas comuns
Cloud como objetivo suficiente; âmbito implícito; aceitação sem evidência; agilidade como ausência de governance.
Tópicos relacionados: Capacidade, dependências e previsão · Risco, mudança e decisões de arquitetura · Governance, fornecedores e comunicação
Liga objetivo, entrega, critério de aceitação e dono do benefício.
Referência: PM² Project Management · PM² reference practices and cloud operational governance; primary guidance reviewed 2026-09-30