MoSCoW Método: Como Fazer o Melhor da Prioritização

A Prioritização desempenhou um papel significativo no sucesso da maioria das aplicações ricas em funcionalidades como Slack e GitLab. Inicialmente, ofereciam um conjunto limitado de funcionalidades essenciais para os seus utilizadores. Com o tempo, este conjunto foi complementado com outras funcionalidades. O Railsware vai partilhar o seu próprio estilo de priorização e mostrar como utilizamos o método MoSCoW para obter longas listas de tarefas feitas.

p>

Por que precisa de priorização?

Como regra, a rotina diária inclui um monte de tarefas. Idealmente, terá tempo e energia suficientes para cobrir todas elas – mas pode acontecer que o número de tarefas seja imenso e que os recursos disponíveis não sejam em abundância. É aí que entra a priorização.

Este termo denota um processo para filtrar o que se tem de fazer, por ordem de importância ou relevância. Por exemplo, se estiver a construir uma casa, não é provável que comece com o telhado ou as paredes até que a sua fundação esteja pronta. É claro que as coisas são muito mais complicadas na indústria de desenvolvimento web, e este exemplo não pode revelar o valor de âmbito total da definição de prioridades.

Projectos complexos e numerosos startups fazem uso de técnicas avançadas de priorização. Estas consistem geralmente em estruturas conhecidas por requisitos ou regras específicas que melhoram a tomada de decisões. O sucesso na definição de prioridades é muitas vezes determinante para o sucesso da própria empresa. O envolvimento em tarefas pendentes e desfeitas é um caminho directo para o fracasso. É por isso que as empresas prestam especial atenção a quais os métodos de priorização a utilizar. Existem alguns deles, mas todos têm algumas características comuns, tais como orientação para o input (interno ou externo), e ferramentas quantitativas ou qualitativas.

Por sinal, estamos a contratar. Verifique as nossas oportunidades de emprego.

Orientação externa significa que é necessário envolver intervenientes externos à equipa de desenvolvimento para estabelecer prioridades, enquanto que os métodos orientados internamente podem ser executados apenas internamente. Os métodos quantitativos implicam um enfoque mais profundo na métrica numérica na definição de prioridades, e o qualitativo repousa em opiniões de peritos, votações, classificações em maior medida. Em vista disto, estão tradicionalmente divididos nas seguintes categorias:

Aqui pode ler sobre diferentes técnicas de priorização ágeis em detalhe.

P>Railsware prefere uma técnica desenvolvida por Dai Clegg em 1994. Inicialmente, chamava-se MSCW, mas dois O’s foram adicionados para melhorar a pronúncia. Isto também o fez parecer a capital da Rússia. Vejamos como funciona.

O que é MoSCoW?

Para compreender a essência do método MoSCoW, precisamos de olhar para a sua origem – método de desenvolvimento de sistemas dinâmicos (DSDM). Trata-se de um quadro para a gestão ágil de projectos adaptados por profissionais com o objectivo de melhorar a qualidade nos processos de RAD (desenvolvimento rápido de aplicações). Uma marca distintiva dos projectos DSDM é a qualidade rigorosamente determinada, os custos e o tempo numa fase inicial. Tendo isto em conta, todas as tarefas do projecto têm de ser atribuídas pela importância. A necessidade de gerir prioridades desencadeou a invenção de um mecanismo de priorização especializado.

Este mecanismo foi implementado via MoSCoW – uma solução simples mas poderosa para estabelecer prioridades tanto com como sem caixas de tempo. Contudo, mostra uma maior eficiência se tiver um determinado prazo para uma tarefa, característica, subcaracterística, funcionalidade, etc. O quadro é aplicável a todos os níveis de priorização de projectos de cima para baixo, bem como a todas as funções e áreas de foco.

A abreviatura MoSCoW (excepto para cartas vogais) é esculpida com as primeiras letras das categorias prioritárias com as quais trabalha. Estas são Must-haves, Should-haves, Could-haves e Won’t-haves. E é assim que se pode definir que tarefa se insere em que categoria.

Regras de prioridade

Estas regras ou requisitos estimam a importância de qualquer tarefa/processo/característica/etc. Cada empresa ou equipa de trabalho utiliza a sua própria abordagem para definir requisitos, mas, em geral, não diferenciam muito e têm o seguinte aspecto.

Must-haves

Estes são requisitos de prioridade máxima, que moldam a fundação do gasoduto principal. Evitá-los significa bloquear todo o projecto ou outras actividades. Como regra, a concepção do produto depende inteiramente da definição de “necessário para o lançamento”, “necessário para a segurança”, “necessário para a validação”, “necessário para fornecer uma solução viável”, etc.

li>Posso avançar com o projecto se esta tarefa for desfeita? – se NÃO, é DEVERÁ

Deveria ter

Este tipo de requisito é de prioridade secundária. Os TERMOS-MEUS não afectam o lançamento e, tradicionalmente, são considerados importantes mas não cruciais. Diferem dos obrigatoriamente necessários pela disponibilidade de uma solução de trabalho. Portanto, é pouco provável que o insucesso de uma tarefa “should-have” cause o insucesso de todo o projecto. Se se estiver a construir um produto, ele ainda será utilizável mesmo que estes requisitos não sejam satisfeitos.

• Possibilidade de avançar com o projecto se esta tarefa for feita um pouco mais tarde? – se SIM, é DEVERÁ

Pode-meter

O próximo requisito é menos importante do que os dois anteriores, mas ainda assim desejado. Se compararmos o “poderia ter” com o “deveria ter”, o primeiro é definido por um menor grau de efeito adverso, se omitido. Tradicionalmente, os requisitos prioritários do terceiro nível no quadro Ágil MoSCoW são realizados se um projecto não for altamente limitado no tempo. Dentro do desenvolvimento do produto, podemos chamar-lhes afinações de baixo custo.

• Podemos sacrificar esta tarefa até ao fim do prazo? – se SIM, é COULD

Won’t-haves

P>Pode também encontrar este tipo de exigência sob o nome de would-have ou wish-to-have, mas estas variantes não são reconhecidas pelo Wiki. No entanto, independentemente do nome escolhido, estes requisitos definem a prioridade mais baixa para tarefas que não são viáveis de implementar com um orçamento e prazo específicos. Não ter não significa uma rejeição completa de algo. Prevê a sua reintrodução em condições favoráveis no futuro.

• Podemos voltar a ela quando as coisas correrem melhor? – se SIM, é NÃO

Como usar

Todas as coisas parecem simples em teoria, mas será na prática? Vamos verificar como funciona uma análise MoSCoW de funcionalidade prioritária através do exemplo de uma aplicação web regular. Como exemplo, vamos utilizar funções básicas retiradas de um dos produtos Railsware:

• Um utilizador pode inscrever-se
• Um utilizador pode entrar
• Um utilizador pode redefinir a senha
• Um utilizador pode escolher o sistema de facturação
• Um utilizador pode eliminar a conta
• Um utilizador pode abrir uma contapágina de rastreio
• Um utilizador pode escolher opções de rastreio temporal
• Um utilizador pode instalar uma versão móvel da aplicação
• Um utilizador pode escolher o tema visual da aplicação

Baseado em requisitos particulares de orçamento e tempo, podemos destacar as características mais fundamentais a serem implementadas no produto mínimo viável. Após a análise prioritária, temos o seguinte:

• Um utilizador DEVE registar-se
• Um utilizador DEVE registar-se
• Um utilizador DEVE redefinir a sua palavra-passe
• Um utilizador DEVE abrir uma página de seguimento temporal

As tarefas prioritárias são seguidas por funcionalidades importantes, embora não vitais para a aplicação. Estas são:

• Um utilizador DEVERÁ escolher o sistema de facturação
• Um utilizador DEVERÁ apagar conta
• Um utilizador DEVERÁ escolher opções de rastreio temporal

A evolução da aplicação prevê a sua disponibilidade em dispositivos móveis. No entanto, esta tarefa é apenas agradável de ter neste ponto.

Um utilizador COULD instala uma versão de aplicação móvel

E agora a característica menos prioritária. O seu objectivo é melhorar a experiência do utilizador assim que a aplicação estiver no bom caminho. A seleccionabilidade do tema não é definitivamente o que vamos fazer agora. Contudo, esta funcionalidade é guardada para mais tarde.

Um utilizador NÃO escolherá o tema visual da aplicação ESTE TEMPO.

O mais difícil da priorização é ser icily inteligente e concentrar-se nas tarefas essenciais a serem feitas. Caso contrário, é possível entrar na armadilha TUDO O QUE É DEVERÁ acontecer, segundo a qual qualquer funcionalidade como a opção do sistema de facturação ou a disponibilidade da aplicação móvel se transforma na armadilha obrigatória. E é por isso que o método MoSCoW Agile é fixe. Permite-lhe definir um conjunto básico de funcionalidades, que tem prioridade máxima e enfatiza que não precisa de abandonar nada. O equilíbrio saudável de must-thaves + should-haves é de 50% de todo o âmbito. Todas as tarefas (ou quase todas) serão implementadas mais tarde, mas na ordem da sua importância para o seu objectivo. O objectivo deste exemplo é construir um MVP, e a categorização acima mostra o progresso esperado da funcionalidade do aplicativo.

Temos muito conhecimento para partilhar consigo. Junte-se à equipa Railsware.

MoSCoW prós e contras

A estrutura é bastante popular entre os projectos Agile com caixas de tempo fixas, uma vez que permite gerir os requisitos para um lançamento específico de um produto. Este método de priorização provou a sua eficiência e fiabilidade também na nossa empresa, e nós aconselhamo-lo aos nossos clientes. Contudo, não é perfeito, claro, e um olhar imparcial pode revelar algumas falhas associadas à técnica MoSCoW. Vejamos os seus pontos fortes e fracos.

MoSCoW priorityzation at Railsware

Vejamos como estabelecemos prioridades dentro da empresa.

Desenvolvimento de produtos: descansamos sobre um roteiro onde são especificadas as características do produto e a ordem da sua implementação. Como regra, aproveitamos MoSCoW para definir qual a característica que vai em primeiro lugar, qual vem em segundo, e assim por diante, tendo em conta a sua importância e a interdependência das características. Os Must-haves e Should-haves destinam-se ao lançamento do produto. Pode-haves e Won’t-haves são adiados para o futuro.

HR e recrutamento: a priorização assenta em requisitos tais como a procura de especialização específica, disponibilidade orçamental, timebox (quão urgentemente precisamos desta especialização), e assim por diante. Aproveitamos os padrões semelhantes de estabelecimento de prioridades noutras áreas de foco, incluindo o “on-boarding”, branding, marketing, etc.

O maior desafio da metodologia é que todos os interessados devem estar familiarizados com o contexto suficiente para estimar correctamente as características. Além disso, os intervenientes que representam diferentes funções como vendas, desenvolvimento, marketing, têm a sua própria visão de estabelecer prioridades, o que nem sempre funciona no sentido de uma correcta definição de prioridades. Os investidores geralmente tratam todas as características como sendo de obrigação a partir da sua perspectiva alargada e precisam que sejam feitas sem qualquer respeito pela sua ordem de implementação.

Railsware tem uma estrutura organizacional Holacrática. Tiramos partido da liderança colectiva com base no modelo RASCI e tomamos decisões sobre diferentes coisas, incluindo a priorização através da votação. Os membros da equipa podem escolher entre várias opções, como realmente querem, querem e não querem. Cada opção implica um ponto em particular. A opção com o maior total de pontos tem a maior prioridade. Para contextos pequenos, um papel responsável (chefe de equipa, gestor de projecto, etc.) pode ser encarregado de estabelecer prioridades por si próprio.

MoSCoW alternativas que pode achar úteis para o seu projecto

Railsware utiliza fortemente a estrutura Ágil MoSCoW e está satisfeito com ela. Contudo, isso não significa que estejamos fechados a outras soluções. Além disso, um bom gestor de produto deve considerar as principais métricas do produto e construir a priorização de acordo com elas. Por isso, aqui estão algumas outras técnicas úteis de que poderá beneficiar.

Kano Model

Com esta estrutura, pode definir o quanto os utilizadores estão satisfeitos com as características do produto. O Modelo Kano baseia-se num questionário, que é utilizado para aprender a atitude dos utilizadores em relação a uma determinada característica (como, por exemplo, esperar, não gostar, ser neutro, etc.). Visualmente, o modelo pode ser expresso através de um diagrama bidimensional onde o eixo vertical é responsável pelo nível de satisfação do utilizador (de totalmente frustrado a incrivelmente feliz) e o horizontal mostra ou quanto foi investido na característica (Investimento), quão bem foi implementado (Implementação), ou quanto os utilizadores beneficiam dele (Funcionalidade).

Categorização de requisitos inclui quatro tipos que são priorizados na seguinte ordem: obrigatório, desempenho, atractivo, e indiferente. Os “must-bes” são algumas coisas básicas que os utilizadores geralmente esperam. Os requisitos de desempenho (também conhecidos como unidimensionais) são a média dourada e permitem aumentar o nível de satisfação. As exigências atractivas são as que melhoram a experiência do utilizador. Estes são bons para ter ou poderiam ter, de acordo com MoSCoW. Os indiferentes são menos priorizados e por vezes até completamente omitidos.

Valor vs. Complexidade

Esta técnica de priorização é uma das mais simples. Pode encontrá-la também sob os nomes de Valor vs. Custo ou Valor vs. Esforço. O método é intuitivo e tem como objectivo maximizar a entrega de valor. A estimativa da importância das características baseia-se no esforço investido para as implementar e no valor que elas trarão. Eis como se apresenta visualmente:

Embrulho

A arte de estabelecer prioridades mostra a eficiência do seu fluxo de trabalho. A escolha do material ferroviário é a estrutura de gestão do projecto MoSCoW, que fez uma boa exibição em funcionalidades e produtos versáteis. No entanto, pode ser menos útil para projectos imensos com múltiplas equipas envolvidas no pipeline. Aconselhamo-lo a encontrar uma solução eficaz de priorização que se adapte às suas necessidades únicas, e a evitar sempre ser apanhado em inúmeras tarefas pendentes.