Análise
Âmbito e priorização
Decida o que pertence à fase 1 e o que passa para a fase 2 ou depois. MoSCoW com ambição realista para entregar algo em vez de fazer tudo a meio.
Atualizado em 23/01/2026
Discovery · 3.7
Porquê primeiro
A maior razão de fracasso: querer demasiado na fase 1. A fase 1 deve ser curta (8 a 12 semanas), funcionar demonstravelmente e criar confiança. Só depois se avança para a fase 2. Uma discussão de âmbito apertada agora = algo em produção dentro do trimestre, em vez de um “pré-go-live sem fim”.
O que entrega?
Tabela MoSCoW
Must / Should / Could / Won't, preenchida com itens da lista de pontos de dor e oportunidades.
Roteiro por fases
Fase 1, 2, 3, com âmbito, objetivos e critérios de sucesso por fase.
Verificação de capacidade
Temos as pessoas para o fazer? Quem, quantos dias, quando.
Lista em pausa
O que não fazemos na fase 1, com data e responsável para revisitar.
As 4 categorias MoSCoW
Must
Sem isto, a fase 1 falhou
~40% do âmbito. Processos críticos, principais pontos de dor, temas de compliance.
Should
Importante, não crítico
~30% do âmbito. Faz-se se a capacidade permitir. Não é impeditivo se atrasar.
Could
Nice-to-have
~20% do âmbito. Ganhos rápidos que polem o resultado. Os primeiros a cair sob pressão.
Won't
Excluído deliberadamente
Registe explicitamente o que não entra na fase 1. Evita scope creep pelo caminho.
Passos
- 1Agrupe os inputs, principais pontos de dor (3.3), processos (3.2), catálogo de serviços (3.5), ações do benchmark (3.6).
- 2Workshop com o steering, sessão de 2 horas. Coloque cada item no quadro MoSCoW. Votação ou consenso.
- 3Force 40/30/20/10, se tudo é "Must", escolha novamente. Disciplina acima de simpatia.
- 4Verificação de capacidade, conseguimos mesmo cumprir os Musts? Quantos dias-pessoa, quando disponíveis?
- 5Defina critérios de sucesso, por fase: o que tem de funcionar demonstravelmente? KPIs concretos vindos de 3.3.
- 6Documente o Won't explicitamente, não fique calado sobre o que não vai fazer, escreva-o com data de revisão.
- 7Aprovação do sponsor, o sponsor assina o âmbito. Alterações posteriores = pedido formal de mudança.
Template — Tabela MoSCoW
| Item | Categoria | Pontuação (de 3.3) | Esforço | Fase | Responsável |
|---|---|---|---|---|---|
| Portal de self-service para tickets | Must | 20 | M | 1 | Head of Facility |
| Add-in para Outlook para reservas | Must | 15 | S | 1 | PM |
| Catering automático para reuniões > 90 min | Should | 12 | S | 2 | Catering |
| AI Agent para tickets de TI | Could | 9 | L | 2/3 | Head of IT |
| App móvel para delegados de segurança | Won't | 6 | M | — | Reavaliar no Q1 de 2027 |
Template — Roteiro por fases
Fase 1 — 8 a 12 semanas
Base + principais pontos de dor
Dados-mestre + 1 a 2 módulos. Resolução demonstrável dos 3 principais pontos de dor.
Critério de sucesso: KPIs de 3.3 melhorados até 3 meses após o go-live.
Fase 2 — 2 a 3 meses depois
Alargar e aprofundar
Itens Should, módulos adicionais, integrações que não eram críticas.
Critério de sucesso: taxa de adoção > 70% entre os utilizadores finais.
Fase 3 — depois disso
Otimizar e IA
Itens Could, AI Agents, relatórios avançados, lista em pausa reavaliada.
Critério de sucesso: ganhos de produtividade mensuráveis, volumes de tickets mais baixos.
Boas práticas
→ Pequenas vitórias
Uma fase 1 a funcionar com 5 funcionalidades > uma fase 1 encalhada com 25.
→ Decida por esforço + pontuação
Pontuação alta + esforço baixo = quick win, vá já. Pontuação baixa + esforço alto = ficar em pausa.
→ Escreva o Won't explicitamente
"Não fazemos X na fase 1" evita perguntas intermináveis de "e o X?".
→ Repriorize sob pressão
Fase 1 a derrapar? Corte Could+Should, não Must. Não alargue a fase.