Como contratar software sob medida sem cair no escopo infinito

Escopo infinito não é algo que fornecedores fazem com você. É o que acontece quando ninguém na sala define o que o software não deve fazer. Um projeto sem fronteiras explícitas se expande para absorver toda boa ideia que surge pelo caminho, e cada uma dessas ideias é, isoladamente, razoável. O resultado é uma construção que está permanentemente a três meses de ficar pronta.

A solução não é um negociador mais duro nem um contrato mais grosso. É outra forma de escopar: definir o projeto pelos resultados operacionais que ele precisa produzir, não pela lista de funcionalidades que ele deveria conter. Dizemos isso como um time que constrói software e também opera os próprios produtos em produção. Operar software depois de entregá-lo ensina rápido que um escopo pequeno funcionando num dia real vale mais do que um escopo grande que só existe num documento.

Por que listas de funcionalidades criam escopo infinito

Uma lista de funcionalidades parece rigor, mas vem com uma válvula de mão única embutida. Toda reunião adiciona uma funcionalidade, porque adicionar parece progresso e não custa nada na hora do planejamento. Ninguém remove nenhuma, porque remover parece abrir mão de algo já pago. Então a lista só cresce, e cada adição torna a próxima mais fácil de justificar.

Depois a lista vira a especificação, e a especificação vira a briga. Toda ambiguidade, como saber se 'relatórios' incluía exportar para Excel, vira uma negociação sobre quem deve o quê. O documento que deveria proteger os dois lados vira o terreno onde eles brigam. E enquanto essa briga corre, ninguém faz a única pergunta que importa: o item 23 muda alguma coisa em como o negócio realmente opera?

Escope por resultado

Um resultado operacional é um momento específico do negócio que precisa ficar diferente quando o software existir. Por exemplo: um trabalhador de campo fotografa um recibo, e a despesa existe no sistema, categorizada, antes de ele voltar para o caminhão. Essa única frase vale mais do que três páginas de funcionalidades de módulo de despesas, porque nomeia quem, fazendo o quê, com qual resultado, e pode ser verificada observando uma pessoa real num dia real, em vez de lendo um checklist.

É assim que a Cazullo escopa projetos: como um conjunto curto de momentos nomeados, cada um testável na operação real. Funcionalidades viram detalhes de implementação, escolhidos por quem constrói e julgados pelo momento que servem. O que não serve a um momento nomeado está, por definição, fora do escopo. Não foi rejeitado, só não está neste projeto.

A disciplina da v1

Com os momentos nomeados, a primeira versão exige mais um ato de disciplina: recusar amplitude. Nós seguramos essa linha nos nossos próprios produtos por um motivo egoísta, porque somos nós que temos que operar o que quer que seja entregue.

• Um fluxo completo de ponta a ponta vale mais do que cinco fluxos pela metade. Um recibo que vira despesa categorizada, sempre, é um produto. Cinco módulos a 60 por cento é uma demo.
• Software que roda um dia real ganha o direito de crescer. Quando um fluxo sustenta a operação de verdade, a próxima conversa de escopo se apoia em uso, não em imaginação.
• Todo o resto é backlog rotulado, não promessa. Anote as ideias cortadas com nome e motivo, para que tirá-las da v1 pareça arquivar, não perder.

Formatos de contrato que ajudam

Nenhum formato de contrato elimina o inchaço de escopo, então desconfie de quem afirma que o dele elimina. Alguns formatos, porém, facilitam a honestidade. O principal são fases em que cada fase termina em algo que opera: uma entrega que uma pessoa real usa no trabalho real. 'Requisitos concluídos' e 'arquitetura aprovada' são marcos de documentação, não entregas. Um trabalhador registrando uma despesa real pelo sistema é uma entrega.

O outro formato útil é poder parar depois de cada fase sem deixar destroços. Se o cliente pode sair depois da fase um com software funcionando e que é dele, o construtor precisa fazer a fase um ser genuinamente útil, e o cliente precisa colocar nela o que importa de verdade. Essa opção de saída mantém todo mundo honesto, inclusive a gente.

Perguntas que encolhem escopo

Quando a conversa de escopo começa a inflar, estas perguntas a desinflam:

• Qual planilha morre na v1? Se nenhuma planilha, grupo de mensagens ou processo em papel desaparece, o software é um acréscimo em vez de uma substituição, e a adoção vai mostrar isso.
• Quem usa isso no primeiro dia? Nomeie pessoas reais. Funcionalidade que nenhuma pessoa nomeada vai tocar no primeiro mês pertence ao backlog.
• O que quebra se cortarmos isto? Se a resposta honesta é 'nada, por enquanto', corte.
• Como a operação se vira enquanto isto é construído? O improviso manual costuma revelar qual parte é urgente de verdade.
• Quais destas funcionalidades alguém pediu, e quais nós imaginamos que alguém ia querer?
• O que precisa ser verdade em noventa dias para esta fase ser chamada de sucesso, sem ninguém rodar uma demo?
• Se o orçamento caísse pela metade, o que manteríamos? O que sobrevive a essa pergunta é o escopo de verdade.

Comece menor do que parece confortável

Nossa recomendação é direta: contrate o menor software que muda um momento operacional real, coloque nas mãos de gente de verdade e deixe o que acontecer escrever o próximo escopo. Uma v1 pequena, no ar e usada ensina mais sobre o que construir a seguir do que qualquer ciclo de planejamento. Vindo de um time que precisa operar o que constrói, isso não é uma concessão. É o caminho mais rápido que conhecemos para software que importa.