Método MoSCoW: como priorizar o que entra no projeto
O método MoSCoW classifica requisitos em Must, Should, Could e Won't para caber no prazo. Veja como priorizar com ele, a regra dos 60% e os erros mais comuns.
O método MoSCoW prioriza o que entra em um projeto com prazo fixo, classificando cada item em quatro grupos: Must have (sem isso a entrega não serve), Should have (importante, mas há contorno), Could have (desejável, sai primeiro se apertar) e Won't have this time (fica fora desta vez, por decisão). A referência do método recomenda que os itens obrigatórios não passem de 60% do esforço.
É uma ferramenta de negociação de escopo mais do que de ranking. Ela responde à pergunta que todo projeto enfrenta em algum momento: se não der para fazer tudo, o que não pode faltar?
O que é o método MoSCoW?
O MoSCoW é parte central do DSDM, método ágil de gestão de projetos mantido pelo Agile Business Consortium. A lógica do DSDM é fixar prazo, recursos e qualidade, e deixar o escopo variar. O MoSCoW é a ferramenta que decide o que varia.
| Categoria | Significado | Teste prático |
|---|---|---|
| Must have | Mínimo utilizável | Se faltar, vale a pena entregar mesmo assim? Se a resposta é não, é Must. |
| Should have | Importante, não vital | Faz falta, mas existe solução provisória (manual, planilha, contorno). |
| Could have | Desejável | Melhora a experiência, pouco impacto se ficar para depois. |
| Won't have this time | Fora desta entrega | Decidido conscientemente, registrado para o futuro. |
As letras "o" minúsculas existem só para tornar a sigla pronunciável.
A regra dos 60% de esforço
O ponto mais ignorado do método é este: a orientação do DSDM, citada no manual do framework, é que os Must haves não ultrapassem 60% do esforço estimado da entrega, com um conjunto razoável de Could haves, em torno de 20%. Ultrapassar esse teto aumenta o risco de falha, a menos que as estimativas sejam muito confiáveis e a equipe conheça bem o trabalho.
A palavra que importa é esforço, não quantidade de itens. Dez requisitos obrigatórios pequenos podem pesar menos que um só grande.
Por que isso funciona? Porque os Should e Could viram a margem de segurança. Se algo atrasa, eles saem e o essencial é entregue no prazo. Um projeto em que tudo é Must não tem margem, e qualquer imprevisto vira atraso. Em uma PME, onde a mesma equipe toca o projeto e a operação do dia a dia, essa margem é ainda mais necessária.
Como priorizar com o método MoSCoW, passo a passo
- Defina o horizonte. MoSCoW é sempre relativo a uma entrega com data: o lançamento de março, a fase um da implantação. "Must para sempre" não existe.
- Liste os itens. Funcionalidades, entregas, requisitos, tarefas de um projeto interno.
- Comece tudo como Won't. Parece radical, mas inverte o ônus: cada item precisa justificar a subida. Sem isso, tudo vira Must na primeira rodada.
- Aplique o teste do Must. Para cada candidato, pergunte se a entrega ainda faz sentido sem ele. Se há contorno, é Should.
- Estime o esforço e confira os 60%. Se os Must passam do teto, algo precisa descer ou o prazo precisa mudar.
- Registre os Won't. Eles são decisão, não esquecimento. Registrar evita que voltem a cada reunião.
- Revise a cada ciclo. O que era Could pode subir quando o contexto muda.
Um exemplo em uma implantação de sistema
Imagine uma distribuidora implantando um portal de pedidos para clientes, com entrega prevista para o fim do trimestre:
- Must: cliente faz login, consulta o catálogo com preço da tabela dele, envia pedido que chega ao ERP.
- Should: acompanhamento do status do pedido (contorno: o comercial informa por WhatsApp).
- Could: histórico de pedidos com botão de "repetir pedido".
- Won't (desta vez): pagamento online, aplicativo para celular.
O portal com os Must já resolve o problema central. O resto melhora a experiência e entra conforme o prazo permitir.
MoSCoW ou matriz impacto x esforço?
As duas ferramentas resolvem problemas diferentes. A matriz impacto x esforço compara iniciativas entre si, para escolher quais projetos fazer. O MoSCoW trabalha dentro de um projeto já escolhido, para decidir o escopo de uma entrega com prazo. Uma vem antes da outra: primeiro escolher o projeto, depois cortar o escopo.
Priorizar não é ordenar o que fazer. É decidir, com antecedência, o que não fazer quando o tempo apertar.
Os erros mais comuns
- Tudo é Must. O sintoma mais frequente, e o mais caro. Sem margem, o método perde a função.
- Contar itens em vez de esforço. A regra dos 60% vale para horas ou pontos, não para linhas na lista.
- Priorizar sem quem decide. Se o dono ou o patrocinador não participa, a classificação é refeita na primeira cobrança.
- Tratar Won't como "nunca". É "não nesta entrega". Isso reduz a resistência na negociação.
- Usar MoSCoW sem prazo. Sem data, nada precisa ser cortado e o método vira só uma etiqueta.
Perguntas frequentes
MoSCoW serve fora de projetos de software?
Serve. Funciona para qualquer entrega com prazo e escopo negociável: evento, reforma, implantação de processo, lançamento de produto.
Quem deve participar da priorização?
Quem paga, quem usa e quem executa. Quem executa estima o esforço, quem usa explica o impacto, e quem paga decide.
O que fazer quando todos os itens parecem obrigatórios?
Aplique o teste do Must item a item e pergunte qual é o contorno. Quase sempre existe uma solução manual temporária. Para o cenário mais amplo, quando a empresa inteira vive no modo urgente, vale ler como priorizar quando tudo é urgente.
Dá para combinar MoSCoW com outras ferramentas?
Sim. É comum usar MoSCoW para definir o escopo e, dentro dos Must, ordenar a execução por dependência ou risco.
Escopo que cabe no prazo
O método MoSCoW é simples de explicar e exige disciplina para aplicar, porque obriga a dizer não com antecedência. É essa disciplina que separa projetos entregues de projetos que se arrastam. Se quiser ver o método aplicado a um exemplo de gestão de produto, o tutorial do canal explica cada categoria na prática.
👉 Assista ao tutorial completo sobre o método MoSCoW no canal do Eric
Fontes
<!-- link interno sugerido: matriz-impacto-x-esforco-como-priorizar-iniciativas --> <!-- link interno sugerido: como-escrever-historia-de-usuario -->Aplicar
Quer aplicar isso no seu negócio?
Uma conversa gratuita pra entender o seu contexto e decidir, juntos, se faz sentido seguir.
Business case de IA: modelo para aprovar o projeto
Modelo de business case de IA para aprovar um projeto na PME: problema, situação atual, solução, custos, ganhos, riscos, piloto e critério de parada.
Gestão da inovação: o que é e como funciona na PME
Gestão da inovação é o conjunto de decisões, rotinas e papéis que faz uma empresa inovar de forma contínua. Entenda o que é, seus elementos e como começar.
Consultoria de inovação ou de gestão: qual contratar
Consultoria de inovação ou de gestão? Uma melhora o que a empresa já faz, a outra ajuda a fazer o que ainda não faz. Veja a diferença e quando usar cada.