Tag: MoSCoW

Resumo em 30 segundos

• O escopo de um MVP é o menor conjunto de funcionalidades que testa uma hipótese de negócio com usuários reais.
• Comece pela hipótese e pela métrica de sucesso. Só depois liste funcionalidades.
• Classifique o backlog inicial com o método MoSCoW: essencial (Must), importante (Should), desejável (Could) e fora agora (Won’t).
• Na experiência da Hize com sistemas internos, de 5 a 9 funcionalidades essenciais costumam bastar.
• Todo pedido extra passa pelo mesmo filtro: ajuda a testar a hipótese ou fica para a próxima versão.
• Documente cada item com user story e critérios de aceite, em uma página só.

Definir o escopo de um MVP ajuda a decidir o que testar primeiro. A maioria dos projetos atrasa por excesso de funcionalidades, não por falta de código. Neste guia, você aprende um método de priorização em cinco passos e vê como ele funciona num exemplo de sistema interno de uma empresa de engenharia.

Este artigo aprofunda uma etapa do nosso guia Como criar um MVP de software: guia passo a passo. Se você ainda tem dúvida sobre o que conta como MVP, leia antes O que é MVP e o que ele não é.

O que é o escopo de um MVP?

O escopo de um MVP é a lista fechada de funcionalidades, regras e telas que a primeira versão do produto precisa ter para validar uma hipótese. Tudo o que não ajuda a provar ou refutar essa hipótese fica fora, mesmo que seja uma boa ideia.

O conceito vem da metodologia Lean Startup. Eric Ries, autor de A Startup Enxuta, descreve o MVP como a versão de um novo produto que permite à equipe “coletar a quantidade máxima de aprendizado validado sobre os clientes com o mínimo de esforço”. Repare no foco: aprendizado, não volume de entregas.

Por isso, o escopo mínimo de produto não é um produto pela metade. É um produto pequeno, que funciona de ponta a ponta e responde a uma pergunta específica.

Como definir o escopo de um MVP: o que entra?

Para decidir o que entra no MVP, parta de uma hipótese e de uma métrica de sucesso, liste todas as ideias num backlog e classifique cada item pelo impacto nessa hipótese. Entra o que é indispensável para o usuário completar a tarefa principal. O resto espera a próxima versão.

O método abaixo tem cinco passos. Ele é o mesmo que usamos no discovery de duas semanas da Hize, antes de qualquer linha de código.

Passo 1: escreva a hipótese e a métrica de sucesso

Uma hipótese de MVP tem o formato: “se o usuário X conseguir fazer Y, então Z vai acontecer”. A métrica de sucesso é o número que diz se Z aconteceu.

Exemplo de um escritório de engenharia civil: “se os engenheiros de campo registrarem medições pelo celular, o fechamento mensal cai de 5 dias para 2”. A hipótese é clara. A métrica também.

Sem esse par, toda funcionalidade parece importante. Com ele, a maioria deixa de parecer.

Passo 2: monte o backlog inicial sem filtro

O backlog é a lista de tudo o que o produto poderia fazer. Nesta etapa, ninguém corta nada. Reúna quem usa o sistema, quem paga por ele e quem vai desenvolvê-lo, e anote cada ideia em uma linha.

Escreva cada item como user story: “como [perfil], quero [ação], para [resultado]”. Essa forma obriga a dizer quem ganha o quê. Itens sem um “para” claro costumam ser os primeiros a cair.

Passo 3: classifique com MoSCoW

MoSCoW é uma técnica de priorização que divide o backlog em quatro grupos: Must have (essencial), Should have (importante), Could have (desejável) e Won’t have now (fora desta versão). A sigla ajuda a ter essa conversa sem briga.

A tabela mostra como aplicar cada grupo ao escopo do MVP. A regra central: o MVP leva só os itens Must.

Categoria MoSCoW	Pergunta-teste	Destino
Must (essencial)	Sem isso, o usuário consegue completar a tarefa principal? Se não, é Must.	Entra no MVP
Should (importante)	Faz falta, mas existe um jeito manual de contornar?	Versão 2
Could (desejável)	Melhora a experiência, mas ninguém deixa de usar sem isso?	Backlog futuro
Won’t (fora agora)	Não ajuda a testar a hipótese atual?	Descartar ou registrar

Um cuidado: se mais de metade do backlog virou Must, a classificação está frouxa. Refaça com uma pergunta mais dura: “se tirarmos isso, a hipótese ainda pode ser testada?”

Passo 4: corte pelo caminho crítico

O caminho crítico é a sequência mínima de ações que leva o usuário do início ao resultado. Desenhe esse caminho em passos simples, do login até a entrega final. Cada Must precisa estar em algum ponto dele.

O que não está no caminho crítico sai. Relatórios extras, painéis, notificações e personalização quase sempre ficam de fora. Aliás, para painéis, vale esperar dados reais: veja como pensamos isso em instrumentação de dados e painéis de decisão.

Passo 5: escreva user stories e critérios de aceite

Critérios de aceite são as condições objetivas que dizem quando uma user story está pronta. Eles evitam o clássico “está pronto, mas faltou aquilo”.

Exemplo para a story “como engenheiro de campo, quero registrar uma medição pelo celular”:

1. O formulário abre em até 3 toques a partir da tela inicial.
2. Os campos obrigatórios são obra, serviço, quantidade e data.
3. A medição salva sem internet e sincroniza quando a conexão volta.
4. O gestor vê o registro na lista em até um minuto após a sincronização.

Com critérios assim, a equipe estima melhor e o cliente aprova sem ambiguidade.

Exemplo: escopo de um sistema interno de medições de obra

Vamos aplicar o método a um caso ilustrativo. Um escritório de engenharia controla medições de obra em planilhas e perde dias no fechamento mensal. A diretoria pede um sistema interno. A primeira lista de desejos tem 22 itens.

A hipótese: “se as medições forem registradas no campo, o fechamento mensal cai de 5 para 2 dias”. A métrica: dias de fechamento por mês.

Depois do MoSCoW, o backlog ficou assim:

Funcionalidade	Classificação	Motivo
Login com perfis (campo e gestor)	Must	Sem perfil, não há controle de quem mede
Cadastro de obras e serviços	Must	Base de toda medição
Registro de medição pelo celular	Must	É a hipótese em si
Aprovação da medição pelo gestor	Must	Fecha o ciclo até o fechamento
Exportação da planilha de fechamento	Must	Entrega o resultado que o gestor usa
Anexo de fotos na medição	Should	Ajuda, mas dá para enviar por e-mail no início
Histórico e filtros avançados	Should	A lista simples resolve no começo
Painel com gráficos por obra	Could	Precisa de dados antes de fazer sentido
Integração com o ERP financeiro	Could	Exportar a planilha cobre a primeira versão
Assinatura digital com validade jurídica	Won’t	Exige estudo à parte e não testa a hipótese

De 22 itens, cinco viraram Must. O MVP testa a hipótese com cinco funcionalidades e um caminho único: medir, aprovar e exportar.

Quantas funcionalidades cabem num MVP?

Não existe número mágico. Na experiência da Hize com sistemas internos, o escopo costuma caber em 5 a 9 funcionalidades essenciais; é uma referência prática, não uma regra. O limite real é o prazo: se o escopo não cabe em poucas semanas de desenvolvimento, ele ainda guarda itens que não são Must.

Na Hize, os MVPs levam entre 5 e 9 semanas, com demonstração toda semana. Esse prazo funciona como régua. Se a soma das estimativas passa dele, cortamos escopo em vez de esticar a data.

Um teste prático ajuda: cada funcionalidade precisa caber em uma demonstração semanal. Se uma story demora mais de duas semanas, quebre-a em partes menores. Para estimar prazos em mais detalhe, o artigo “Quanto tempo leva para desenvolver um MVP” aprofunda o tema.

Como lidar com pedidos extras durante o projeto?

Trate todo pedido extra como um novo item do backlog. Ele passa pelo mesmo filtro MoSCoW e só entra se substituir algo de peso equivalente. Isso mantém o prazo fixo e transforma a conversa em escolha, não em negativa.

Um roteiro simples para esses momentos:

1. Registre o pedido no backlog, com autor e data.
2. Pergunte qual hipótese ele ajuda a testar.
3. Estime o esforço em dias, junto com quem escreve o código.
4. Mostre o que sai para ele entrar, ou o que atrasa.
5. Decida em conjunto e registre a decisão.

Contato direto entre cliente e desenvolvedor facilita muito esse processo. Sem intermediário, a estimativa sai na hora e o custo do pedido fica claro. Explicamos por que isso importa em squad sem intermediário.

Com o tempo, esses pedidos viram o mapa da versão 2. Esse é o ciclo de iteração: construir, medir, aprender e refinar. A Asana descreve o processo iterativo exatamente como esse ciclo de repetir e melhorar em pequenos passos. O MVP é só a primeira volta.

Como documentar o escopo do MVP?

Para definir o escopo de um MVP em uma página, registre a hipótese, a métrica de sucesso, a lista de funcionalidades Must com critérios de aceite, os itens fora desta versão e o prazo. Quem lê essa página deve entender o que será entregue e o que não será, sem reunião extra.

Um modelo enxuto:

Bloco	O que escrever
Hipótese	Uma frase no formato “se X, então Y”
Métrica de sucesso	Número, meta e prazo para medir
Funcionalidades Must	User stories com critérios de aceite
Fora do escopo	Itens Should, Could e Won’t, com motivo
Prazo e preço	Semanas, entregas semanais e valor fechado

A mesma página preenchida para o caso ilustrativo das medições de obra:

Bloco	Exemplo preenchido
Hipótese	Se as medições forem registradas no campo pelo celular, o fechamento mensal cai de 5 para 2 dias
Métrica de sucesso	Dias de fechamento por mês: de 5 para 2, após dois ciclos de fechamento
Funcionalidades Must	Login com perfis; cadastro de obras e serviços; registro de medição pelo celular; aprovação pelo gestor; exportação da planilha de fechamento
Critérios de aceite	Formulário abre em até 3 toques; campos obrigatórios: obra, serviço, quantidade e data; salva sem internet e sincroniza depois; gestor vê o registro em até um minuto após a sincronização
Fora do escopo	Anexo de fotos e histórico com filtros (Should); painel com gráficos e integração com o ERP (Could); assinatura digital com validade jurídica (Won’t)
Prazo e preço	Prazo em semanas, com demonstração semanal, e valor fechado, definidos no discovery

A lista “fora do escopo” é a parte mais útil. Ela evita a frase “achei que estava incluído” no meio do projeto.

Na Hize, escopo, prazo e preço ficam numa página só, definidos no discovery de duas semanas. Quando um item novo aparece, a página é atualizada e todo mundo vê o efeito. Mais exemplos de como estruturar essa entrega estão no blog da Hize.

Como medir o sucesso do MVP?

Meça o sucesso do MVP com a métrica definida antes do desenvolvimento, comparando o resultado com uma linha de base e uma meta. Se a métrica atinge a meta, isso é uma evidência favorável à hipótese, não uma confirmação automática. Antes de expandir o produto, confira se os usuários realmente adotaram o sistema, se os períodos comparados são equivalentes e se outras causas, como menos obras no mês, explicam a melhora. Se a meta não é atingida, você ajusta ou muda o rumo.

No exemplo das medições, os números seriam:

• Linha de base: 5 dias para fechar o mês.
• Meta: 2 dias, depois de dois ciclos de fechamento.
• Sinais de apoio: percentual de medições registradas pelo celular e tempo médio de aprovação.

Defina também o que fazer em cada resultado. Meta batida: priorizar os Should. Meta próxima: investigar o gargalo. Meta distante: revisar a hipótese antes de gastar mais.

Métricas de vaidade, como número de acessos, enganam. Prefira uma métrica ligada ao resultado do negócio, como tempo economizado ou erros evitados.

Que erros mais incham o escopo de um MVP?

Os erros mais comuns são começar sem hipótese, aceitar tudo que aparece e confundir “simples” com “incompleto”. Todos têm o mesmo efeito: o prazo estoura antes de qualquer usuário testar o produto.

Os cinco que mais vemos:

1. Backlog sem dono. Quando ninguém decide, tudo vira Must.
2. Funcionalidades “para o futuro”. Construir hoje o que só vai fazer sentido depois de validar custa caro.
3. Integrações cedo demais. Exportar uma planilha costuma bastar na primeira versão.
4. Perfeccionismo visual. Um design limpo é suficiente; refinamento vem com dados de uso.
5. Escopo sem critérios de aceite. Sem eles, “pronto” vira opinião.

Na experiência da Hize, com mais de 60 produtos entregues desde 2019, o padrão se repete: os projetos que mantêm o escopo curto chegam ao usuário primeiro e aprendem mais rápido. Hoje, 92% dos nossos clientes voltam para uma segunda etapa. Esse número é um dado interno da Hize: [PREENCHER ANTES DE PUBLICAR: período de apuração, total de clientes considerado, definição de “voltam” e como os dados foram obtidos]. Boa parte dessa volta, na nossa leitura, nasce de uma versão 1 enxuta que gerou aprendizado real.

O mesmo vale para projetos com IA. Antes de automatizar tudo, escolha um fluxo e valide. Em automação com IA, usamos esse mesmo raciocínio: um caso de uso, uma métrica, uma revisão humana.

Conclusão: escopo curto, aprendizado rápido

Definir o escopo de um MVP é, acima de tudo, escolher o que não fazer agora. O método tem cinco passos:

• Escreva a hipótese e a métrica de sucesso.
• Monte o backlog inicial sem filtro.
• Classifique com MoSCoW e deixe só os Must no MVP.
• Corte pelo caminho crítico do usuário.
• Escreva user stories com critérios de aceite e documente tudo numa página.

Para ver onde essa etapa se encaixa no processo completo, volte ao guia Como criar um MVP de software. Se você tem uma ideia ou um sistema interno para tirar do papel, a Hize faz o discovery em duas semanas e entrega escopo, prazo e preço numa página só. Conte sua ideia e a gente começa a cortar o que não precisa entrar.

Perguntas frequentes