O que entra num documento de âmbito de MVP

A maioria dos «documentos de âmbito» é uma lista de funcionalidades com marcadores e um número. Isso não é um documento de âmbito. É um palpite com formatação.

Um documento real é específico o suficiente para que duas equipas de engenharia diferentes, lendo apenas o documento, construíssem um produto reconhecivelmente idêntico. Eis o que isso realmente exige.

A resposta curta

Oito secções. Faltando duas ou três, tem uma proposta, não um plano.

Uma declaração do problema, não uma lista de funcionalidades

O documento deve abrir com o problema a resolver e quem o tem, em linguagem simples, antes de qualquer funcionalidade ser nomeada. Parece óbvio e é constantemente ignorado.

Porque importa: cada decisão de âmbito seguinte é testada contra isto. Quando surge um pedido de funcionalidade na semana seis, «isto resolve o problema declarado» é um filtro mais rápido e honesto do que «soa útil».

Uma versão fraca: «Uma app para ligar operadores de frotas a mecânicos.» Uma versão que funciona nomeia a dor real - os operadores atualmente gastam duas a seis horas por avaria à procura de um mecânico disponível por telefone, sem forma de verificar a capacidade antecipadamente.

Fluxos de utilizador antes de listas de funcionalidades

Funcionalidades isoladas não dizem se o produto funciona. Os fluxos dizem.

O documento deve mapear os dois ou três caminhos centrais que um utilizador realmente percorre do início ao fim - não cada ecrã, mas a sequência que faz o produto funcionar. É aqui que descobre que «adicionar um sistema de avaliações» exige implicitamente «tratar disputas quando a avaliação é injusta», algo que ninguém tinha pensado em delimitar separadamente.

Uma lista de funcionalidades realmente priorizada

Não uma lista plana de marcadores - uma lista ordenada pelo que quebra o produto se estiver em falta versus o que seria bom ter. Já escrevemos sobre reduzir uma lista de 46 funcionalidades para 11 usando exatamente este teste: se isto faltar, o ciclo central ainda funciona?

Cada funcionalidade que passa esse teste entra em «Indispensável». Tudo o resto vai para uma secção «Fase dois» claramente identificada - documentada, estimada a um nível geral, e explicitamente fora do que está a ser construído agora. Só esta prática evita mais disputas de âmbito do que qualquer cláusula contratual.

Arquitetura técnica, com razões

Não apenas uma lista de tecnologias - o raciocínio por trás de cada escolha, porque é isso que permite a alguém avaliar se as decisões ainda fazem sentido seis meses depois.

Um documento de âmbito deve indicar a stack, a abordagem de alojamento, e as duas ou três decisões caras de reverter - a escolha de base de dados para um produto transacional, se as notificações passam por WhatsApp ou apenas email, se a arquitetura precisa de suportar múltiplas plataformas mais tarde mesmo lançando numa só agora.

Ecrãs ou um protótipo, não uma descrição

«Um painel limpo e moderno» não é uma especificação. Cinco a oito ecrãs-chave, idealmente como protótipo clicável, eliminam a maior fonte de surpresas a meio da construção: o fundador e a equipa terem imagens diferentes da mesma funcionalidade na cabeça.

Não precisa de ser um design final ao pixel. Precisa de ser específico o suficiente para que «o painel de administração» deixe de ser uma abstração e se torne algo real, discutível.

Um orçamento decomposto por módulo, não um número único

Um preço único esconde cada suposição que o produziu. Uma decomposição módulo a módulo - contas e permissões, fluxo transacional central, pagamentos, painel de administração, e assim por diante - faz duas coisas que um número único não consegue: mostra o que é caro e porquê, e permite cortar um módulo específico se o orçamento não chegar, em vez de renegociar tudo.

Riscos e dependências nomeados com precisão

Linguagem genérica de risco («risco técnico», «risco de calendário») não serve para nada. Uma secção de riscos real nomeia a coisa específica que pode atrasar o projeto - o calendário de aprovação de um fornecedor de pagamentos, uma API de terceiros com limites de taxa pouco claros, uma decisão do fundador ainda pendente - e quem é responsável por resolvê-la.

Esta secção é também onde o caminho crítico é identificado: as duas ou três coisas que, se atrasadas, atrasam a data de lançamento independentemente de quão bem correr o resto da engenharia.

O que está explicitamente excluído

Esta é a secção que a maioria dos documentos de âmbito ignora por completo, e é a que mais disputas evita depois.

Declare claramente o que não está incluído: custos de serviços de terceiros, redação de conteúdo, migração de dados, suporte além de uma janela definida, uma segunda plataforma. A melhor versão desta secção é longa e um pouco maçadora de ler. Isso é uma qualidade, não um defeito - a vagueza aqui é a fonte de disputas do tipo «pensei que isso estava incluído».

Como é um real

Publicamos um Blueprint de exemplo anonimizado mostrando as oito secções preenchidas para um projeto real - não um modelo com texto de preenchimento, um documento de âmbito real com decisões reais e números reais. Lê-lo é mais rápido do que ler uma descrição dele.

O teste para saber se o seu é real

Entregue o documento a um engenheiro que nunca falou consigo e peça-lhe para estimar o calendário. Se conseguir sem uma chamada de esclarecimento, é um documento de âmbito. Se voltar com dez perguntas, tem uma lista de funcionalidades com um preço colado - e essas dez perguntas são exatamente o que surgirá como pedidos de alteração quando o projeto já estiver em curso, quando responder-lhes é muito mais caro.

Quer ver como é um documento de âmbito completo face a um projeto real? O nosso Blueprint de exemplo é o documento completo, não um excerto. Ou conte-nos o seu projeto e definimos o âmbito corretamente antes de dar um número.