O método MoSCoW é uma técnica de priorização utilizada em gestão de projetos, desenvolvimento de software e análise de negócios. Ele ajuda a priorizar requisitos com base em sua importância e urgência, permitindo que os gerentes de projetos alocem recursos e orçamento de forma adequada. Neste artigo, exploraremos o método MoSCoW e apresentaremos um exemplo de sua implementação.
O que é o Método MoSCoW?
O método MoSCoW é uma técnica de priorização que categoriza requisitos em quatro grupos: Obrigatórios, Desejáveis, Possíveis e Não serão feitos. O acrônimo MoSCoW significa:
- Obrigatório:requisitos críticos que são essenciais para o sucesso do projeto. Esses requisitos são obrigatórios e devem ser incluídos no escopo do projeto.
- Desejável:requisitos importantes que são necessários para o sucesso do projeto, mas podem ser adiados, se necessário. Esses requisitos são importantes, mas não críticos, e podem ser adiados para uma fase posterior do projeto.
- Possível:requisitos desejáveis que não são essenciais para o sucesso do projeto, mas podem aumentar o valor do projeto. Esses requisitos são opcionais e podem ser incluídos se houver tempo e orçamento disponíveis.
- Não serão feitos:requisitos que não são necessários para o sucesso do projeto e não estão incluídos no escopo do projeto.
O método MoSCoW ajuda os gerentes de projetos a priorizar requisitos com base em sua importância e urgência. Permite que eles se concentrem nos requisitos críticos e alocam recursos e orçamento de forma adequada.
Exemplo do Método MoSCoW
Vamos considerar um exemplo de um projeto de desenvolvimento de software para entender como o método MoSCoW funciona.
Suponha que uma empresa deseje desenvolver um novo aplicativo móvel para seus clientes. O aplicativo deverá permitir que os clientes façam pedidos, acompanhem seus pedidos e recebam notificações. A empresa também deseja incluir algumas funcionalidades adicionais para tornar o aplicativo mais atraente para os clientes.
A equipe do projeto identifica os seguintes requisitos:
- Obrigatório: O aplicativo deve permitir que os clientes façam pedidos, acompanhem seus pedidos e recebam notificações.
- Desejável: O aplicativo deverá ter um recurso de busca que permita aos clientes pesquisar produtos, e um recurso de pagamento que permita aos clientes pagar seus pedidos por meio de diversos métodos.
- Possível: O aplicativo poderia ter um recurso de programa de fidelidade que recompense os clientes por suas compras, e um recurso de programa de indicação que incentive os clientes a indicar o aplicativo para amigos e familiares.
- Não serão feitos: O aplicativo não terá um recurso de integração com redes sociais que permita aos clientes compartilhar suas compras em plataformas de redes sociais.
Usando o método MoSCoW, a equipe do projeto priorizou os requisitos com base em sua importância e urgência. Os requisitos obrigatórios são críticos para o sucesso do projeto e devem ser incluídos no aplicativo. Os requisitos desejáveis são importantes, mas podem ser adiados para uma fase posterior do projeto, se necessário. Os requisitos possíveis são opcionais e podem ser incluídos se houver tempo e orçamento disponíveis. Os requisitos que não serão feitos não são necessários para o sucesso do projeto e não estão incluídos no escopo do projeto.
Exemplo do Mundo Real – Sistema de CRM
Descrição do Projeto: Desenvolvimento de um Sistema de Gestão de Relacionamento com o Cliente (CRM)
O objetivo deste projeto Ágil é desenvolver um sistema de CRM para uma pequena empresa especializada em fornecer soluções personalizadas para seus clientes. O sistema de CRM será projetado para simplificar o processo de vendas e melhorar as interações com os clientes, permitindo que a empresa aumente a satisfação e a fidelidade dos clientes.
O projeto seguirá a metodologia Ágil, que envolve desenvolvimento iterativo e incremental. A equipe Ágil trabalhará de perto com o cliente para coletar requisitos, desenvolver protótipos e entregar incrementos funcionais de software em iterações curtas, geralmente de duas semanas.
Identifique uma Lista de Histórias de Usuários
Para criar a lista de histórias de usuários, você pode considerar os diferentes papéis que interagirão com o sistema, como representantes de vendas, gerentes e clientes, e pensar nas diversas tarefas que precisarão realizar para alcançar seus objetivos. Você também pode considerar os diferentes tipos de dados que precisarão ser armazenados e gerenciados no sistema, como informações de clientes, dados de vendas e campanhas de marketing.
Com base nesta análise, você poderá então gerar uma lista de histórias de usuários que abranjam uma ampla gama de funcionalidades, desde rastreamento de leads e atendimento ao cliente, até propostas de vendas e relatórios. A lista de histórias de usuários tem como objetivo fornecer um ponto de partida para a equipe de desenvolvimento, usada na priorização e planejamento do desenvolvimento do sistema de CRM.
Aqui está uma lista de histórias de usuários para o projeto de desenvolvimento do sistema de CRM:
- Como representante de vendas, quero ser capaz de rastrear todos os meus leads em um único local para que eu possa gerenciar facilmente minha pipeline de vendas.
- Como gerente de vendas, quero ser capaz de visualizar e monitorar o progresso da minha equipe em tempo real para que eu possa oferecer orientação e suporte conforme necessário.
- Como representante de atendimento ao cliente, quero ser capaz de visualizar todas as interações de um cliente com nossa empresa para que eu possa oferecer suporte personalizado.
- Como gerente de marketing, quero ser capaz de segmentar nossos clientes com base em suas preferências e comportamentos para que eu possa direcioná-los com campanhas relevantes.
- Como cliente, quero ser capaz de visualizar meu histórico de compras e informações da minha conta para que eu possa gerenciar facilmente minha relação com a empresa.
- Como representante de atendimento ao cliente, quero ser capaz de registrar e rastrear reclamações e consultas dos clientes para que eu possa garantir que sejam resolvidas em tempo hábil.
- Como representante de vendas, quero ser capaz de gerar orçamentos e propostas rapidamente e facilmente para que eu possa fechar negócios mais rápido.
- Como administrador, quero ser capaz de gerenciar permissões de usuário e níveis de acesso para que eu possa controlar quem tem acesso a informações sensíveis.
- Como representante de vendas, quero ser capaz de agendar e gerenciar reuniões com meus clientes para que eu possa me manter organizado e atualizado com minha agenda.
- Como gerente, quero ser capaz de gerar relatórios sobre desempenho de vendas, satisfação do cliente e outras métricas para que eu possa tomar decisões empresariais informadas.
Essas histórias de usuário cobrem uma gama de funcionalidades que o sistema de CRM deveria oferecer. A equipe de desenvolvimento pode usar essas histórias de usuário para priorizar os recursos mais importantes para o sistema e garantir que o sistema atenda às necessidades de todos os interessados.
Em formato de tabela, vamos apresentar um resumo claro e conciso das 10 histórias de usuário relacionadas a um cenário empresarial para fornecer uma visão geral das histórias de usuário.
| História do Usuário | Papel do Usuário | Objetivo |
|---|---|---|
| 1 | Representante de Vendas | Rastrear todos os leads em um único local para gerenciar a pipeline de vendas |
| 2 | Gerente de Vendas | Visualizar e monitorar o progresso da equipe em tempo real para orientação e suporte |
| 3 | Representante de Atendimento ao Cliente | Visualizar todas as interações do cliente para suporte personalizado |
| 4 | Gerente de Marketing | Segmentar clientes com base em preferências e comportamentos para campanhas direcionadas |
| 5 | Cliente | Visualizar o histórico de compras e informações da conta para gerenciamento fácil |
| 6 | Representante de Atendimento ao Cliente | Registrar e acompanhar reclamações e consultas dos clientes para resolução oportuna |
| 7 | Representante de Vendas | Gerar orçamentos e propostas rapidamente e facilmente para fechar negócios mais rápido |
| 8 | Administrador | Gerenciar permissões de usuário e níveis de acesso para informações sensíveis |
| 9 | Representante de Vendas | Agendar e gerenciar reuniões com clientes para permanecer organizado |
| 10 | Gerente | Gerar relatórios sobre desempenho de vendas, satisfação do cliente e outras métricas para decisões empresariais informadas |
A tabela fornece informações sobre o papel do usuário, o objetivo específico que deseja alcançar e o número da história do usuário para referenciar facilmente cada história. Ao organizar as histórias do usuário em uma tabela, fica mais fácil compreender e priorizar os recursos que precisam ser desenvolvidos para atender às necessidades dos interessados envolvidos no projeto. Esta tabela pode servir como referência para a equipe de desenvolvimento ao projetar e implementar recursos alinhados às necessidades dos usuários finais e dos interessados.
Priorize as Histórias do Usuário
É importante priorizar as histórias do usuário com base no seu valor para o negócio e no impacto sobre os objetivos do projeto. Isso garante que o esforço de desenvolvimento esteja focado nas características mais importantes e valiosas, e que o projeto possa ser entregue dentro do prazo e dentro do orçamento.
A priorização pode ser feita usando várias técnicas, como o método MoSCoW, que categoriza as histórias do usuário como “devem ter”, “deveriam ter”, “poderiam ter” e “não terão”. As histórias do usuário classificadas como “devem ter” são as mais críticas e devem ser desenvolvidas primeiro, enquanto as “deveriam ter” e “poderiam ter” podem ser desenvolvidas posteriormente em iterações ou lançamentos subsequentes.
Aqui está uma tabela com as 10 histórias do usuário mencionadas anteriormente, com as informações relevantes e a priorização com base no método MoSCoW:
É importante priorizar as histórias do usuário com base no seu valor para o negócio e no impacto sobre os objetivos do projeto. Isso garante que o esforço de desenvolvimento esteja focado nas características mais importantes e valiosas, e que o projeto possa ser entregue dentro do prazo e dentro do orçamento.
A priorização pode ser feita usando várias técnicas, como o método MoSCoW, que categoriza as histórias do usuário como “devem ter”, “deveriam ter”, “poderiam ter” e “não terão”. As histórias do usuário classificadas como “devem ter” são as mais críticas e devem ser desenvolvidas primeiro, enquanto as “deveriam ter” e “poderiam ter” podem ser desenvolvidas posteriormente em iterações ou lançamentos subsequentes.
Aqui está uma tabela com as 10 histórias do usuário mencionadas anteriormente, com as informações relevantes e a priorização com base no método MoSCoW:
| História do Usuário | Descrição | Prioridade |
|---|---|---|
| 1 | Como representante de vendas, quero ser capaz de rastrear todas as minhas oportunidades em um único local para que eu possa gerenciar facilmente minha pipeline de vendas. | Deve Ter |
| 2 | Como gerente de vendas, quero ser capaz de visualizar e monitorar o progresso da minha equipe em tempo real para que eu possa fornecer orientação e suporte conforme necessário. | Obrigatório |
| 3 | Como representante de atendimento ao cliente, quero ser capaz de visualizar todas as interações de um cliente com nossa empresa para que eu possa fornecer suporte personalizado. | Obrigatório |
| 4 | Como gerente de marketing, quero ser capaz de segmentar nossos clientes com base em suas preferências e comportamentos para que eu possa direcioná-los com campanhas relevantes. | Desejável |
| 5 | Como cliente, quero ser capaz de visualizar meu histórico de compras e informações da minha conta para que eu possa gerenciar facilmente minha relação com a empresa. | Desejável |
| 6 | Como representante de atendimento ao cliente, quero ser capaz de registrar e acompanhar reclamações e consultas dos clientes para que eu possa garantir que sejam resolvidas em tempo hábil. | Desejável |
| 7 | Como representante de vendas, quero ser capaz de gerar orçamentos e propostas rapidamente e facilmente para que eu possa fechar negócios mais rápido. | Poderia ter |
| 8 | Como administrador, quero ser capaz de gerenciar permissões de usuário e níveis de acesso para que eu possa controlar quem tem acesso a informações sensíveis. | Poderia ter |
| 9 | Como representante de vendas, quero ser capaz de agendar e gerenciar reuniões com meus clientes para que eu possa me manter organizado e atualizado com meu cronograma. | Poderia ter |
| 10 | Como gerente, quero ser capaz de gerar relatórios sobre desempenho de vendas, satisfação do cliente e outras métricas para que eu possa tomar decisões empresariais informadas. | Não terá |
Nesta tabela, as histórias de usuário são listadas por ordem de prioridade, com os recursos “obrigatórios” listados primeiro, seguidos pelos “desejáveis” e “poderia ter”. O recurso “não terá” não está planejado para implementação neste projeto, mas pode ser considerado para desenvolvimento futuro.
Ao priorizar as histórias de usuário, a equipe de desenvolvimento pode garantir que os recursos mais críticos sejam desenvolvidos primeiro, proporcionando valor aos stakeholders e permitindo que o projeto alcance seus objetivos dentro das restrições de tempo e orçamento.
Exemplo: Um plano de desenvolvimento Scrum para o CRM
Aqui está um esboço de alto nível para um plano de desenvolvimento Scrum para iniciar o projeto ágil. No entanto, os detalhes específicos do plano dependerão dos requisitos do projeto, da estrutura da equipe e de outros fatores. Aqui está um exemplo de um plano de desenvolvimento Scrum:
- Defina o Backlog do Produto:O primeiro passo é definir o backlog do produto, que é uma lista priorizada de todas as funcionalidades, características e requisitos que precisam ser implementados no projeto. Esse backlog será mantido ao longo do projeto e será continuamente refinado e atualizado com base nas necessidades em mudança dos stakeholders.
- Realize a Planejamento do Sprint:Depois que o backlog do produto tiver sido definido, a equipe realizará uma reunião de planejamento do sprint para selecionar um conjunto de histórias de usuário do backlog a serem desenvolvidas no próximo sprint. A equipe estimará o esforço necessário para cada história de usuário e selecionará as histórias que podem ser concluídas dentro do prazo do sprint.
- Realize Reuniões Diárias de Scrum: Assim que o sprint começar, a equipe realizará reuniões diárias de Scrum para revisar o progresso, identificar quaisquer obstáculos ou desafios e ajustar o plano conforme necessário. As reuniões diárias de Scrum devem ser breves e focadas, com cada membro da equipe fornecendo um atualização sobre seu progresso.
- Desenvolva o Incremento do Produto:Durante o sprint, a equipe trabalhará no desenvolvimento das histórias de usuário selecionadas, com foco em entregar um incremento funcional do produto ao final do sprint. A equipe colaborará estreitamente, com desenvolvedores, testadores e outros membros trabalhando juntos para entregar o incremento do produto.
- Realize a Revisão do Sprint:No final do sprint, a equipe realizará uma reunião de revisão do sprint para demonstrar o incremento do produto aos stakeholders, coletar feedback e revisar o progresso alcançado durante o sprint.
- Realize a Retrospectiva do Sprint:Após a revisão do sprint, a equipe realizará uma reunião de retrospectiva do sprint para revisar o processo do sprint, identificar áreas de melhoria e planejar o próximo sprint.
- Repita o processo:A equipe repetirá esse processo para cada sprint subsequente, continuando a refinar e atualizar o backlog do produto, e se concentrando em entregar um incremento funcional do produto ao final de cada sprint.
Este plano de desenvolvimento Scrum fornece um framework para gerenciar o projeto ágil, com reuniões e revisões regulares para garantir que o projeto esteja no caminho certo e esteja gerando valor para os stakeholders.
Conclusão
O artigo discute o método MoSCoW, que é uma técnica de priorização usada na gestão de projetos ágeis para priorizar os requisitos do projeto. O método MoSCoW divide os requisitos em quatro categorias: Obrigatórios, Desejáveis, Possíveis e Não serão feitos. O artigo apresenta um exemplo real de um projeto ágil e como identificar histórias de usuário para o projeto. As histórias de usuário são então priorizadas usando o método MoSCoW, com os requisitos Obrigatórios recebendo a maior prioridade.
O artigo também descreve um plano de desenvolvimento Scrum, que inclui definir o backlog do produto, realizar o planejamento do sprint, reuniões diárias de Scrum, desenvolver o incremento do produto, revisão do sprint, retrospectiva do sprint e repetir o processo. O plano de desenvolvimento Scrum fornece um framework para gerenciar o projeto ágil, garantindo que o projeto esteja no caminho certo e esteja gerando valor para os stakeholders.