Método MoSCoW: framework para ajudar a priorizar tarefas

Você já ouviu falar no método MoSCoW? Esse framework ajuda os times de produto na priorização das demandas e tarefas para entregar mais valor para os usuários, de acordo com as necessidades deles. 

Segundo o Panorama do Mercado de Product Management no Brasil 2021-22, 45% dos profissionais entrevistados disseram que as suas empresas lançam novas funcionalidades ou produtos todos os meses. Mas como os times decidem qual funcionalidade será criada? Qual funcionalidade deve ser priorizada e fará mais diferença para os usuários e o negócio? São essas perguntas que o framework MoSCow ajuda a responder. 

Para você saber mais sobre esse modelo, no post de hoje, vamos explicar o que é o método MoSCoW, quando utilizar essa estrutura e quais as vantagens e desvantagens desse framework. Também vamos trazer um exemplo do método na prática e outras técnicas de priorização que podem ser aplicadas no contexto de produto. Boa leitura!

O que é o método MoSCoW

O método MoSCoW é um framework de priorização que pode ser utilizado pelas equipes de Produto na gestão de projetos, ajudando os times no processo de tomada de decisão a respeito das estratégias que serão feitas. Essa técnica faz parte das metodologias ágeis, que permitem executar projetos de forma rápida, otimizando a produtividade dos profissionais e reduzindo custos. 

Alguns dos objetivos dessa estrutura são: identificar o grau de prioridade das tarefas em um projeto e alinhar stakeholders sobre o que deve ser feito, de acordo com a ordem de importância dos elementos considerados.

O método foi criado na década de 1990 por Dai Clegg e Richard Barket, que trabalhavam com desenvolvimento de software na Oracle. O framework foi proposto pela primeira vez no estudo “Case Method Fast-Track:A Rad Approach“. Embora tenha sido criado para atender ao Método de Desenvolvimento de Sistemas Dinâmicos (DDSM), com o tempo, a estrutura sofreu adaptações até chegar ao modelo que conhecemos hoje.

MoSCoW é uma sigla formada pela primeira letra de cada um dos elementos que compõem o método e por duas letras “o” para que o termo possa ser pronunciado. A seguir, vamos ver o significado de cada um desses elementos. 

Must-Have (Tenho que fazer)

Esse pilar do framework corresponde ao das tarefas indispensáveis para a realização do projeto e que precisam ser priorizadas. Tudo que for considerado Must-Have é fundamental para o Produto. Algumas perguntas que podem ajudar o time a decidir se uma tarefa se encaixa nesta categoria são:

• Qual o impacto de não fazer essa iniciativa?
• Existe uma forma mais simples de entregar isso?
• O produto funciona e entrega valor sem esse aspecto?

Iniciativas de alto impacto, que agregam valor ao produto e que prejudicam a experiência do cliente se não forem feitas, devem ser consideradas Must-Have. Essas demandas são as mais urgentes, e o time deve concentrar esforços para resolvê-las primeiro. 

Should-Have (Deveria fazer)

Nesta categoria, você deve incluir o que é importante para a realização do projeto, mas não é fundamental, como as atividades Must-Have. Aqui, as perguntas que podem ajudar na definição das tarefas Should-Have são:

• Qual o impacto de atrasar essa iniciativa?
• O produto funciona e entrega valor para o usuário sem esse aspecto?

Por mais que as iniciativas Should-Have não sejam tão prioritárias quanto as anteriores, elas não devem ser negligenciadas. Na hora de montar um cronograma de acordo com as prioridades de produto, o time precisa colocar essas demandas logo após as atividades Must-Have. Com esse processo, o time consegue organizar e priorizar o backlog de maneira mais eficiente. 

Could-Have (Poderia fazer)

As iniciativas Could-Have correspondem àquelas que são interessantes e poderiam ser feitas, mas não são tão importantes para o sucesso do Produto. Para decidir quais tarefas se encaixam nessa categoria, vale se perguntar:

• Qual o impacto de não fazer essas tarefas em relação às iniciativas Should-Have?
• O objetivo dessa atividade elimina alguma dor urgente do negócio ou do usuário?

No cronograma de execução de um projeto, as tarefas Could-Have devem ser feitas só depois das iniciativas Should-Have, já que seu impacto para os usuários e para o negócio é menor. Por isso, é importante avaliar como cada tarefa irá afetar a experiência dos clientes, esse é um critério determinante para priorizar atividades em Produto. 

Won’t-Have (Não vou fazer)

Tarefas dessa categoria são as menos importantes e que o time decide não fazer em um futuro próximo. Para definir quais são essas tarefas, as perguntas que ajudam são:

• O esforço para realizar essa tarefa justifica o impacto esperado?
• Qual o valor gerado por essa iniciativa?
• Essa atividade vai ao encontro da estratégia de produto hoje?

Por mais que as demandas Won’t-Have não sejam priorizadas no atual momento da empresa, não significa que elas devam ser retiradas do radar para sempre. Se essas iniciativas tiverem alguma relevância para os usuários e para o negócio, é interessante deixá-las em um backlog para serem reavaliadas no futuro. Elas podem não ser prioritárias agora, mas adquirir uma outra importância em um momento posterior. 

A ideia é que, na aplicação do método, a ordem de prioridade atribuída a cada atividade do projeto siga o movimento de cima para baixo, do Must-Have para o Won’t-Have. Alguns modelos utilizam uma variação da técnica MoSCoW, substituindo os elementos que apresentamos acima pela seguinte ordem:

• Business-Critical (Crítico ao negócio);
• Must-Have (Tenho que fazer);
• Nice to have (Seria bom ter);
• Maybe later (Talvez depois).

Além disso, depois que todas as diretrizes do modelo estiverem definidas, é importante compartilhar o material com todos os stakeholders e profissionais envolvidos no projeto. Afinal, essa estrutura serve como um guia que direciona os esforços do time, a partir do que foi priorizado.

Quando usar o Método MoSCoW?

O método MoSCoW pode ser utilizado sempre que o time tiver que decidir quais iniciativas precisam ser priorizadas e quando os critérios para decidir sobre o que deverá ser feito são variados.

O objetivo do modelo é trazer mais clareza para a equipe de Produto entender quais demandas são mais urgentes de acordo com a relevância que elas representam para os usuários e para o negócio. 

Para que o método funcione de forma eficiente, o ideal é reunir várias pessoas do time de Produto e de outras equipes da empresa para discutir quais demandas devem ser priorizadas segundo os critérios do framework MoSCoW.

Para aplicá-lo, o primeiro passo é listar todas as demandas ou tarefas que serão analisadas. Isso deixa mais claro o que deve ser avaliado. Depois, o time pode discutir cada ponto individualmente, aplicando as perguntas correspondentes a cada categoria. 

Além disso, é necessário que todos os envolvidos estejam por dentro dos objetivos do projeto, para que possam ser mais criteriosos na hora de aplicar o modelo de priorização. Como o método resulta em uma ordem de priorização, é interessante estabelecer um cronograma para a entrega das demandas que serão feitas. Assim, o processo de desenvolvimento do produto fica mais organizado e rápido.

Exemplo de priorização de Produto com o método MoSCow

Para você entender melhor como o método MoSCoW funciona na prática, trouxemos um exemplo aplicado no contexto de Produto. A solução considerada é uma plataforma white label de cursos. Nesse caso, o time quer priorizar funcionalidades e vai utilizar o framework para decidir a ordem de priorização. As opções da equipe são:

• Pagamento em pix;
• Permitir agendamento de e-mails de marketing;
• Mais opções de triggers de automação dentro da plataforma;
• Melhorias na usabilidade da tela inicial.

Depois de um brainstorming com o time para responder as perguntas que ajudam a definir a prioridade de cada elemento considerado, a equipe de Produto chegou à seguinte conclusão sobre a ordem de importância de cada funcionalidade:

• Must-Have: Permitir agendamento de e-mails de marketing (ainda não ter essa possibilidade é uma dor constante dos usuários e já causou alguns churns);
• Should-Have: Melhorias na usabilidade da tela inicial (a tela inicial já causou algumas reclamações por parte dos clientes e pode se tornar uma dor maior lá na frente);
• Could-Have: Mais opções de triggers de automação dentro da plataforma (alguns usuários fizeram sugestões sobre gatilhos que poderiam existir no produto para otimizar a performance da solução);
• Won’t-Have: Pagamento em pix (a falta desse meio de pagamento não costuma ser uma reclamação dos usuários, mas pode trazer praticidade para alguns clientes).

O time organizou essas informações em uma tabela no Excel, incluindo a iniciativa Must-Have no topo e seguindo a ordem de prioridades estabelecida, como nesta imagem:

A partir disso, o time pode criar um plano de ação para implementar o agendamento de e-mails de marketing e, depois, partir para as melhorias na usabilidade da tela.

Vantagens e desvantagens de usar a técnica MoSCoW

A técnica MoSCow pode ser bastante benéfica para as equipes de produto, ajudando os times a entregar mais valor para o usuário de acordo com aquilo que trará mais valor para eles. Algumas vantagens de aplicar esse modelo para priorizar as demandas são:

• Torna o processo de priorização mais objetivo, a partir de critérios e perguntas bem definidos que norteiam as decisões do time;
• Torna os resultados de cada iniciativa mais palpáveis (para fazer a priorização, o time precisa pensar no que as demandas irão agregar para o negócio e para o usuário);
• Deixa mais claro quais são as expectativas do time e dos stakeholders em relação às tarefas;
• Leva em conta a experiência dos profissionais do time e daqueles que estão envolvidos no processo de priorização;
• É um método simples de utilizar e de adaptar de acordo com os processos do negócio;
• É uma forma rápida e eficiente de priorizar o que deve ser feito e que está no radar do roadmap de produto;
• Ajuda a alinhar as expectativas dos stakeholders e dos profissionais envolvidos no projeto, principalmente em iniciativas que exigem a participação de muitas pessoas.

Embora o método traga diversos benefícios para os times de produto, ele apresenta algumas desvantagens, como:

• Se o processo de priorização não for feito de maneira objetiva, os critérios para a definição de importância de cada tarefa pode ser pouco precisa;
• É necessário que o time e os stakeholders tenham uma ideia clara dos resultados esperados no caso de cada demanda considerada;
• Os profissionais precisam estar alinhados em relação a esses resultados, caso contrário, as opiniões serão muito diferentes, o que pode dificultar o processo de priorização. Agora, se houver divergências, é interessante ter um plano para resolver essas questões.

Considerando as vantagens e as desvantagens do modelo e os objetivos do time de Produto, os profissionais precisam avaliar se o método vale a pena para alcançar essas metas. O importante é que o framework faça sentido para o contexto considerado e realmente ajude as pessoas a priorizarem o que tem que ser feito. 

Métodos complementares de priorização

Assim como o método MoSCoW, há outros frameworks de priorização de demandas igualmente importantes para os times de Produto. Confira uma lista com alguns deles: 

• Matriz GUT: utilizada para priorizar tarefas e encontrar soluções para problemas a partir de 3 critérios (gravidade, urgência e tendência)
• Matriz RICE: que funciona a partir de um modelo de pontuação, considerando 4 critérios (alcance, impacto, confiança e esforço)
• Portfólio de investimentos: que prioriza os investimentos, considerando algumas regras e critérios racionais para avaliar o ROI do portfólio de produtos de acordo com as necessidades do negócio. 
• Matriz PICK: que avalia o impacto x esforço de cada demanda para priorizar as iniciativas, categorizando as demandas promissoras e as que não valem a pena.
• ICE Score: que funciona a partir de 3 critérios de avaliação das iniciativas (impacto, confiança e facilidade) para priorizá-las.
• Kano Model: que prioriza as necessidades dos clientes, de acordo com 5 categorias (qualidades obrigatórias, qualidades unidimensionais ou de desempenho, qualidades atrativas, qualidades indiferentes, qualidades reversas).
• Mapa de hipóteses: que avalia o impacto e a incerteza das iniciativas para definir a importância de cada uma delas no momento considerado.

E aí, gostou de saber mais sobre o método MoSCoW e outras técnicas de priorização? Para conhecer mais ferramentas estratégicas que ajudam Product Managers na gestão de produtos, baixe gratuitamente o nosso Guia de Frameworks. Aproveite o material!

Perguntas frequentes sobre o método MoSCoW

Como o Método MoSCoW pode ser adaptado para equipes que não são ágeis ou não seguem metodologias ágeis?

O Método MoSCoW pode ser adaptado para equipes que não são ágeis ao se concentrar na flexibilidade e na comunicação clara das prioridades.

Em ambientes não ágeis, é essencial estabelecer critérios claros e objetivos para cada categoria do MoSCoW e garantir que todos os membros da equipe entendam essas prioridades. Isso pode envolver discussões mais detalhadas e revisões periódicas das prioridades para assegurar que as necessidades do projeto sejam atendidas enquanto se mantém um escopo gerenciável.

Existem exemplos específicos de como diferentes indústrias aplicam o Método MoSCoW para priorizar projetos não relacionados a tecnologia ou software?

Sim, diferentes indústrias aplicam o Método MoSCoW para priorizar projetos fora da esfera de tecnologia e software.

Por exemplo, no setor de construção civil, o método pode ser utilizado para definir prioridades na alocação de recursos e na sequência de etapas construtivas. Na indústria de eventos, o MoSCoW ajuda na decisão sobre quais recursos ou atividades são essenciais para o sucesso do evento e quais podem ser descartados ou adiados. Essa abordagem ajuda a otimizar recursos e focar no que realmente trará valor ao projeto final.

Como lidar com conflitos ou desacordos entre stakeholders durante o processo de priorização usando o Método MoSCoW?

Para lidar com conflitos ou desacordos entre stakeholders durante o processo de priorização usando o Método MoSCoW, é crucial estabelecer um ambiente de comunicação aberta e transparente. Envolver todos os stakeholders desde o início do processo e garantir que suas opiniões e necessidades sejam ouvidas pode ajudar a minimizar desentendimentos.

Além disso, é importante destacar a importância do consenso e da flexibilidade, permitindo ajustes nas prioridades conforme novas informações sejam disponibilizadas ou as condições do projeto mudem. A mediação de um facilitador experiente também pode ser benéfica para ajudar a navegar por conflitos e chegar a um acordo coletivo.