Modelo de Matriz MoSCoW

Must-have (deve ter), should-have (deveria ter), could-have (poderia ter) e won't-have (não terá), não terá agora, são os quatro tipos de projetos representados pela abreviação MoSCoW. O método Moscou, também reconhecido como priorização MoSCoW ou análise MoSCoW, é uma técnica de priorização usada em gestão, consultoria de gestão, desenvolvimento de produtos e engenharia de software para entender o valor que as partes relevantes atribuem à entrega de cada requisito.

Ao fornecer definições claras para cada nível de prioridade, a priorização MoSCoW aborda uma das principais desvantagens das tecnologias de priorização menos robustas. Quando algo é marcado como um recurso "must-have" no MoSCoW, todos na equipe entendem que isso não pode ser desconsiderado durante o desenvolvimento do projeto. Os membros da equipe de produto e as partes interessadas devem trabalhar juntos para preencher os níveis do modelo MoSCoW. Não apenas os recursos e conceitos devem ser atribuídos a cada nível do modelo MoSCoW, mas cada nível também deve receber uma certa quantidade de recursos. Ao fornecer definições claras para cada nível de prioridade, a priorização MoSCoW aborda uma das principais desvantagens das tecnologias de priorização menos robustas. Quando algo é marcado como um recurso "must-have" no MoSCoW, todos na equipe entendem que isso não pode ser desconsiderado durante o desenvolvimento do projeto. Os membros da equipe de produto e as partes interessadas devem trabalhar juntos para preencher os níveis do modelo MoSCoW. Não apenas os recursos e conceitos devem ser atribuídos a cada nível do modelo MoSCoW, mas cada nível também deve receber uma certa quantidade de recursos.

A abordagem MoSCoW é benéfica para desenvolver um produto sólido por várias razões. Primeiro, ajuda a criar um cronograma de projeto ao decidir quais tarefas devem ser realizadas primeiro. Todos entendem os elementos mais críticos, o que dá ao projeto uma sensação de ordem.

Em segundo lugar, o método MoSCoW é bom para estabelecer objetivos de projeto tanto para a equipe quanto para as partes interessadas. Oferece aos investidores uma boa compreensão do que esperar do projeto, bem como uma estimativa de quanto cada componente custará.

Em terceiro lugar, incluir o MoSCoW em sua abordagem de trabalho ajudará a manter a visão do projeto no caminho certo. É normal que sua equipe se desvie das necessidades e restrições do projeto durante o brainstorming com colegas, despertando sua imaginação e se esforçando para ultrapassar os limites.

Embora isso seja ótimo para a fase de conceito, não é ideal ao trabalhar em um produto. Todos têm uma lista clara do que estão fazendo graças ao MoSCoW, em contraste com uma visão vaga e multidimensional.

Para identificar a relevância dos projetos, as categorias de priorização MoSCoW usam um conjunto simples de critérios. Os critérios MoSCoW ajudam as equipes a priorizar de maneira planejada e lógica. Esta técnica reduz tempo desperdiçado, discussões e desinformação. Também remove o máximo possível de preconceito do processo, permitindo que todos vejam as necessidades objetivamente.

As quatro categorias de necessidades prioritárias são as seguintes.

Estas definem os critérios que o projeto DEVE atender. Alguns dos seguintes podem ser usados para defini-los. Não há propósito em entregar no prazo se isso não for feito; se não for feito, não há valor em implantar a solução no prazo.

• Sem isso, não é legal.
• Sem isso, você está em perigo.
• Sem isso, não poderemos oferecer uma solução viável.

Considere o seguinte cenário: 'O que acontece se esta condição não for atendida?' Se a resposta for 'cancelar o projeto - não faz sentido construir uma solução que não atenda a essa demanda', então o requisito é um Must-Have.

Os seguintes são alguns exemplos de requisitos:

• Importante, mas não necessário.
• Embora possa ser difícil deixar de fora, a solução ainda é prática.
• Alguma forma de solução alternativa pode ser necessária, como gerenciamento de expectativas, ineficiência, uma solução existente, documentação, etc. A solução alternativa pode ser apenas temporária.
• A solução alternativa pode ser apenas temporária.

Examinar o grau de sofrimento causado pela necessidade não ser satisfeita, avaliado em termos de valor comercial ou número de pessoas afetadas, é uma abordagem para distinguir uma demanda Should Have de um requisito Could Have.

Os critérios são definidos como segue:

• Preferido ou desejado, mas não crítico.
• Se você deixar de fora, terá um impacto menor.

Por serem entregues em sua totalidade apenas no melhor cenário possível, são os requisitos que oferecem o maior conjunto de contingência. Quando surge um problema e o prazo está em perigo, um ou ambos os Could Haves oferecem a opção inicial para o que deve ser cortado do cronograma.

Esta é uma lista de requisitos que a equipe do projeto decidiu não cumprir (como parte deste período). Eles estão listados na Lista de Requisitos Priorizados, o que ajuda a definir o plano do projeto. Isso evita que sejam reintroduzidos extraoficialmente em um momento posterior.

Won't Haves podem ser muito eficazes em manter o foco nos Could Haves, Should Haves e especialmente Must-Haves mais importantes neste momento.