O framework de priorizacao: MoSCoW

O MoSCoW é um framework de priorização de features desenvolvido por Dai Clegg na Oracle. O acrônimo representa 4 categorias diferentes de iniciativas: (1) Obrigatorio ter (must-haves); (2) Deveria ter (should-haves); (3) Poderia ter (could-haves), (4) Não terão no momento. (will not have at this time).

Se você estiver tendo dificuldade em fazer um projeto avançar, porque parece que há muitas coisas que precisam ser feitas, então o MoSCoW pode ajudá-lo nesse desafio. O MoSCoW é um framework de priorização fácil de aprender e simples de aplicar. Também pode ajudá-lo a decidir o que é realmente valioso para seus projetos de experiência do usuário antes de começar a usá-los.

Existem muitas frameworks diferentes que podem ser empregadas em projetos de design, pessoais ou de produto, mas uma das mais simples de usar é o método MoSCoW. Ele é usado em todas as disciplinas de negócios para permitir que as equipes de projeto trabalhem com os stakeholders para definir os requisitos.

É sobre ele que vamos discutir nesse artigo.

Os especialistas Dai Clegg e Richard Barker, durante o tempo que trabalharam na Oracle como desenvolvedores de software, propuseram o método MoSCoW em seu artigo “Método de Caso Fast-Track: A RAD Approach”.

Embora fosse inicialmente planejado para ser usado com o Método de Desenvolvimento de Sistemas Dinâmicos (Dynamic Systems Development Method (DDSM), há muito foi adotado em diversas áreas de negócios. Recentemente, ele se tornou muito popular nas comunidades Agile e RAD (desenvolvimento rápido de aplicativos).

Clegg inicialmente projetou o MoSCoW como um framework de priorização para projetos com prazo determinado com prazos fixos ou apertados, especificamente, para iniciativas em releases.

O MoSCow funciona entendendo a ideia de que todos os requisitos do projeto podem ser considerados importantes, mas devem ser priorizados para dar os maiores benefícios no prazo mais rápido possível.O método é comumente usado para ajudar os stakeholders a entender a importância das iniciativas em um release específico.

Como citado anteriormente, o framework é acrônimo que representa 4 categorias diferentes de iniciativas:

1. Obrigatorio ter (must-haves);
2. Deveria ter (should-haves);
3. Poderia ter (could-haves),
4. Não terão no momento. (will not have at this time).

Como citado anteriormente, esse é um framework especialmente importante para usar na metodologia ágil , que valoriza mais os itens que possuem o maior valor comercial. Os recursos de software que você identifica como mais valiosos têm a maior probabilidade de serem desenvolvidos e implementados.

Nota: Às vezes, o “W” no MoSCoW é usado para significar “desejo” em vez de “não terá agora”.

• Levantar requisitos

Mas antes de priorizar, você deve ter algo para priorizar. Isso é chamado de parte do processo de coleta de requisitos. Não é especificamente uma parte do método MoSCoW, mas você coleta requisitos para priorizar de forma eficaz em um segundo momento.

Isso é mais do que se simplesmente fazer algumas perguntas e depois passar para a próxima fase do projeto. Você deve-se gastar tempo para fazer uma coleta completa de requisitos.

É um processo de quatro etapas que pode ser usado para projetos grandes e pequenos. O tamanho do projeto afetará apenas o tempo que leva para concluir este processo.

1. Etapa 1 – Elicitação: Esta etapa significa que você começa a fazer perguntas e ouvir ativamente as respostas, por meio de entrevistas com os stakeholders, aqueles com experiência, etc., também sessões facilitadas, protótipos e questionários são outras ferramentas que você pode usar.
2. Etapa 2 – Validação: Agora você começa a analisar os dados coletados para ter certeza de que as informações são precisas e representam as necessidades e expectativas dos stakeholders Você começará a consolidar, racionalizar, procurando sobreposições, lacunas, etc.
3. Etapa 3 – Especificação: você passará a priorizar e formalizar os dados em um relatório de definição de requisitos. Você também vai querer ter certeza de que eles podem ser testados.
4. Etapa 4 – Verificação: Por fim, você verificará se os requisitos são precisos e comunicará o resultado aos stakeholders, e por mim revisitar e aprovar o que foi levantado.

Seguindo este processo para definir quais são os requisitos essenciais e não essenciais para o seu projeto ou desenvolvimento de produto, você pode ver rapidamente onde seu foco deve estar. Esse método também ajuda a garantir que você chegue a uma conclusão sobre quais são essas prioridades para cada requisito no início do processo.

• Proporção de cada categoria

As empresas devem garantir que as equipes envolvidas no projeto e outros stakeholders concordem com os objetivos do projeto e os fatores que serão usados ​​para a priorização. Planos para resolver divergências também devem ser estabelecidos.

Em seguida, as equipes devem decidir que porcentagem de recursos será atribuída a cada categoria. Por exemplo, 20% dos requisitos podem ser alocados para os requisitos que podem ter, enquanto 40% são dados aos que deveriam e 60% aos que são obrigatórios.

Uma vez que os requisitos foram reunidos e os acordos foram alcançados entre a empresa e as stakeholders, as equipes podem começar a atribuir requisitos a cada uma das quatro categorias a seguir.

• Must-haves (obrigatório ter)

Todas as iniciativas necessárias para o sucesso do projeto

Como o nome sugere, esta categoria consiste em iniciativas que são importantes para sua equipe. Eles representam necessidades não negociáveis do projeto, produto ou release em questão. Por exemplo, se você estiver lançando um aplicativo de assistência médica, uma iniciativa obrigatória pode ser funcionalidades de segurança que ajudam a manter a conformidade.

Qualquer coisa na categoria “must-have” é considerada obrigatória para a equipe concluir. Se você não tiver certeza se algo pertence a essa categoria, pergunte a si mesmo o seguinte.

• “O que acontece se lançarmos sem isso?”
• “Existe uma maneira alternativa ou mais simples de fazer isso?“
• “O lançamento / projeto / produto funcionará sem essa iniciativa?”

Se o produto não funcionar sem uma iniciativa ou o lançamento se tornar inútil sem ela, a iniciativa provavelmente será um “must-have”.

Dica: quando falamos sobre MPV, essas são as features que precisam existir na sua primeira versão.

• Should-haves (deveria ter)

Requisitos que são importantes para o projeto mas não necessarios

As iniciativas que “deveriam existir” (should-haves) estão apenas um passo abaixo do que você deve ter. Eles são importantes para o produto, projeto ou versão, mas não são vitais. Se deixado de fora, o produto ou projeto ainda funciona. No entanto, se forem incluídos, eles agregam valor significativo.

Iniciativas “deveria ter” são diferentes das iniciativas “devem ter”, pois podem ser programadas para uma versão futura sem impactar a atual. Por exemplo, melhorias de desempenho, pequenas correções de bugs ou novas funcionalidades podem ser iniciativas “necessárias”. Sem eles, o produto ainda funciona.

• Could-haves (poderia ter)

Requisitos que são “legais” de ter, mas tem um impacto muito pequeno se deixadas fora do projeto

Outra maneira de descrever as iniciativas que poderiam ter é o prazer de ter. Iniciativas que “poderiam existir” não são necessárias para a função principal do produto. Comparado com as iniciativas “deveria existir”, elas têm um impacto muito menor no resultado se forem deixadas de fora.

Como resultado, os requisitos que podem ter são geralmente os primeiros a serem despriorizados – os requisitos essenciais e essenciais sempre terão precedência. Os que podem ter podem ser definidos como:

• Um elemento desejável, mas sem importância.
• Deixar de fora esse requisito impactará menos o produto do que deixar de fora um elemento que “deveria ter”.

• Will not have – at this time (Não terão no momento)

Todos os requisitos que foram reconhecidos como não sendo prioritários para o prazo do projeto

Esta categoria final inclui todos os requisitos que foram reconhecidos como não prioritários para o cronograma do projeto. Atribuir elementos à categoria que não terá ajuda a fortalecer o foco nos requisitos nas outras três categorias, ao mesmo tempo em que define expectativas realistas para o que não será incluído no produto final

Isso ajuda a gerenciar as expectativas sobre o que não será incluído em uma versão específica (ou outro período para o qual você esteja priorizando). Se houver iniciativas nessa categoria, a equipe sabe que não deve ser uma prioridade para esse período de tempo específico.

Pode ser porque eles custam muito para implementar ou fornecem muito pouco ROI (Return on Investment) para os esforços necessários para implementá-los. Eles são simplesmente deixados de lado até que sejam removidos da lista de requisitos ou se tornem uma prioridade mais alta.

Dica: Algumas iniciativas do grupo “não-irão-existir” serão priorizadas no futuro, enquanto outras provavelmente não acontecerão. Algumas equipes decidem diferenciar entre elas criando uma subcategoria dentro deste grupo.

Agora que você conhece os fundamentos da priorização do MoSCoW, é hora de utilizar o framework do MoSCoW com sua própria equipe, seguindo as etapas a seguir.

Etapa 1 – Identifique e reúna os stakeholders

Imagine como as coisas ficariam confusas se todos em sua empresa tivessem uma palavra a dizer em todos os aspectos de um projeto. É por isso que a primeira etapa do método MoSCoW é identificar e reunir os stakeholders ​​e a equipe que é diretamente responsável pelo desenvolvimento do projeto em questão. 

Dica: reuna representantes de equipes em toda a organização, mas lembre-se de mantê-la enxuta.

Etapa 2 – Determine o “juiz”

Podem surgir divergências sobre a priorização. É importante determinar como resolver disputas antes de começar a priorização do MoSCoW. 

Você pode escolher que os participantes votem ou determinem o valor comercial de cada característica ou iniciativa e então prossiga com a característica de maior valor. Ao longo desse artigo eu reuni uma lista de perguntas a serem feitas a todos os envolvidos – essas perguntas podem fornecer uma bússola para guiar sua equipe ao longo do processo e ajudar a evitar discussões e resolver quaisquer dificuldades que surjam.

Dica: uma boa prática é determinar o “juiz”do exercício, ou seja, aquele que tem o poder de desempatar alguma disputa ou escolher o caminho que o produto precisa seguir. Normalmente essa pessoa é o gerente de produto.

Etapa 3 – Divida os recursos

Obviamente, a maioria dos recursos deve ser destinada à iniciativa mais crítica. Mas a forma como os recursos são divididos deve ser decidido por sua equipe. 

Decidir o número de recursos alocados para cada categoria pode ajudar a determinar em qual “balde” cada iniciativa deve entrar. A categoria “não terá” obviamente não terá nenhum recurso alocado para ela. Cabe à sua equipe e a outras partes interessadas determinar como o orçamento será dividido entre os três outros grupos.

Etapa 4 – Defina o cronograma

Quanto mais apertado for o prazo, menos iniciativas podem se enquadrar na categoria “obrigatórias”. Identificar o cronograma com antecedência ajuda a trazer um pouco de realidade ao processo. Consulte a equipe que está desenvolvendo o produto para ter uma visão mais realista do desenvolvimento.

Etapa 5 – Liste as features

Se você tiver uma lista de recursos ou iniciativas listadas em seu backlog, é hora de trazê-la Caso contrário, você pode precisar consultar o escopo do projeto e listar os requisitos para o projeto em questão. 

De qualquer forma, é importante ter uma lista completa das iniciativas que você priorizará para que o processo seja completo e organizado. Essa lista dará a qualquer pessoa da organização acesso à sua priorização, incentivará a transparência e manterá uma cópia disponível na nuvem.

Etapa 6 – Comece a priorizar

Durante o processo de priorização, sua equipe precisará fazer perguntas que acompanham cada categoria para determinar melhor onde cada iniciativa pertence. Percorra a lista de maneira sistemática e faça as seguintes perguntas para cada recurso ou iniciativa. É provável que exista mais atrito entre os baldes “deveria ter” e “obrigatória ter”. 

Se não houver consenso no início, continue descendo a lista para identificar as categorias para outros recursos e, em seguida, no final da priorização, determine as categorias apropriadas para os recursos que não eram imediatamente óbvios no início.

Must-have (obrigatório ter)

• “O que acontece se lançarmos o produto sem esta iniciativa?“
• “Existe alguma maneira mais simples de fazer isso?“
• “Este produto funcionará sem esse recurso?“

Should-have (deveria ter):

• “Quanto valor esse recurso agrega ao projeto?“
• “Isso pode esperar até o próximo lançamento?“

Could-have (poderia ter)

• “Isso é necessário para a função central do projeto?”
• “Quanto impacto isso terá no projeto se for deixado de fora?”

Will not have (Não terá)

• “Isso tem pouca ou nenhuma importância para o projeto neste momento?”
• “Há alguma chance de que isso tenha prioridade no futuro?”

Uma vez que os recursos e iniciativas tenham sido divididos nessas categorias de priorização, sua equipe terá uma ideia clara de onde concentrar suas energias. Dê uma olhada nos modelos MoSCoW abaixo para uma forma visual de examinar e priorizar suas iniciativas.

1. Ajuda a manter a visão do projeto no caminho certo. Ao fazer um brainstorming com colegas, estimular sua criatividade e tentar ultrapassar os limites, é natural que sua equipe saia dos requisitos e limites do projeto. 
2. Permite que sua equipe determine quanto esforço será gasto em cada categoria. Portanto, você pode garantir que está entregando uma boa variedade de iniciativas a cada lançamento.
3. Ajuda a criar um cronograma para seu projeto, determinando o que precisa ser concluído primeiro. Todos sabem quais são as características mais importantes, dando a todo o projeto uma sensação de clareza. 
4. A abordagem MoSCoW é excelente para definir as expectativas do projeto. Você consegue determinas as expectativas tanto para a equipe interna quanto para os stakeholders. Dá aos investidores uma boa ideia do que podem esperar do projeto, bem como uma ideia clara de quanto custará cada recurso. 

O MoSCoW fornece a todos uma lista de verificação clara do que eles precisam realizar. em oposição a uma visão vaga e multifacetada.

• Vantagens

O método MoSCoW é fácil de usar e entender. Pode ajudar os indivíduos com a priorização, mas beneficia ainda mais as equipes de projeto. Outras vantagens incluem:

• É bom para envolver os stakeholders sem formação técnica no processo de priorização do produto.
• Forma rápida, fácil e intuitiva de comunicar prioridades à equipe e aos clientes.
• Ele permite que você pense sobre a alocação de recursos ao classificar seus recursos e requisitos em cada intervalo.
• A análise pode ser usada para garantir que um produto mínimo viável (MVP) seja produzido.

Além disso, o método MoSCoW permite que os usuários atribuam porcentagens específicas de recursos a cada uma das quatro categorias. Esta ação irá garantir que os recursos sejam gerenciados de forma eficaz e irá otimizar a análise de produtividade.

• Desvantagens

• É tentador para equipes e stakeholders superestimar o número de recursos essenciais.
• É um exercício de formulação de critérios de liberação mais do que um método de priorização.
• Não há como priorizar os requisitos da mesma categoria.
• Não há nenhum motivo real para explicar por que um requisito é obrigatório e o outro é obrigatório.

O método MoSCoW oferece um processo simples de priorização na entrega do projeto. Ele também pode ser usado para priorizar sua carga de trabalho. Deve ser usado com algum cuidado, pois pode ser muito simples – especialmente para projetos complexos – mas é um bom ponto de partida. Uma das grandes vantagens de seu simplicidade é que deve ser fácil obter a adesão de outras stakeholders para colocá-lo em prática.

É mais útil em situações com limite de tempo e pode ser usado para priorizar sua própria carga de trabalho (geralmente com a adesão de um supervisor ou gerente, se você trabalhar para outra pessoa) com a mesma facilidade com que pode ser usado para o trabalho de projeto.

Referências:

• MoSCoW Prioritization; (LINK)
• Search Software Equality – MoSCoW method; (LINK)
• Lucidchart – Introduction to MosCoW Prioritization; (LINK)
• Interaction Design Foundation – Making Your UX Life Easier with the MoSCoW; (LINK)
• ProjectManager – How to Prioritize with the MoSCoW Method; (LINK)
• Airfocus – MOSCOW; (LINK)
• The Agile Manager – Productivity: MoSCoW the simple prioritization technique for small products; (LINK)
• Roadmunk – Ultimate guide; (LINK)