Porque falha o caderno de encargos clássico
O caderno de encargos tradicional tem um defeito estrutural: descreve a ferramenta imaginada em vez do negócio real. Enumeram-se ecrãs, botões e requisitos («o sistema deverá permitir…») antes de se ter colocado a única coisa que importa: que dados existem, como se ligam, quem os mantém vivos.
Um resultado que todos os projetos informáticos conhecem: a ferramenta entregue está conforme o documento e desajustada do terreno — porque o próprio documento era uma ficção. E a sua redação custou semanas que não produziram software algum.
A estrutura numa página: quatro blocos
Uma aplicação de gestão descreve-se inteiramente com quatro blocos. É a estrutura que os projetistas experientes usam — e exatamente o que o Blueprint Maker extrai da sua descrição para construir o plano da aplicação.
- AS COISAS (entidades): o que acompanha — clientes, obras, artigos, intervenções. Uma lista de 3 a 8 nomes, cada um com as suas informações-chave (campos).
- AS LIGAÇÕES (relações): como as coisas se ligam — «uma obra pertence a um cliente», «uma intervenção diz respeito a um equipamento». Uma frase por ligação.
- OS ESTADOS (estados): o ciclo de vida dos seus objetos — «orçamento, assinado, em curso, concluído, faturado». As suas próprias palavras, na ordem real.
- OS NÚMEROS (indicadores): o que quer ver todas as manhãs — montantes a faturar, processos em atraso, stock abaixo do limiar. De três a seis indicadores.
Exemplo completo: uma página que basta
«Empresa de instalação de vedações, 4 pessoas. COISAS: clientes (nome, morada, telefone), obras (morada, tipo de vedação, metragem, montante do orçamento, data prevista), intervenções (data, horas realizadas, equipa), materiais (referência, stock). LIGAÇÕES: uma obra pertence a um cliente; uma intervenção realiza-se numa obra; os materiais consomem-se por obra. ESTADOS de uma obra: orçamento enviado, assinado, planeado, em curso, concluído, faturado, liquidado. NÚMEROS: obras em curso, metragem instalada do mês, montante a faturar, materiais abaixo do limiar.»
Esta página contém tudo o que é preciso para construir a aplicação — por um programador ou por um gerador. O que não contém é igualmente significativo: nenhuma descrição de ecrã, nenhuma escolha técnica, nenhum requisito numerado. Os ecrãs DECORREM da estrutura.
As três armadilhas de redação
Armadilha 1 — descrever a ferramenta atual: «quero as colunas A a R da minha folha de cálculo». A folha de cálculo é uma fonte de informação, não um alvo: extraia dela as coisas e as ligações, não a disposição.
Armadilha 2 — o âmbito excessivo: querer cobrir a faturação legal, os salários, a contabilidade. Esses domínios regulados têm as suas próprias ferramentas; a sua aplicação termina onde eles começam e destaca-se no seu acompanhamento operacional.
Armadilha 3 — os casos particulares primeiro: «e quando um cliente é também fornecedor?». Descreva primeiro o fluxo normal que cobre 90 % dos dias; os casos particulares acrescentam-se depois, sobre uma estrutura sã.
Da página à aplicação: dois caminhos
Caminho clássico: a página serve de briefing a um programador ou a uma agência — reduz drasticamente o risco de mal-entendidos e o tempo de análise faturado.
Caminho direto: a página É o prompt. Submetida ao Blueprint Maker, torna-se um plano de aplicação estruturado — entidades, relações, estados, indicadores — que valida antes de gerar. A aplicação chega implementada, com dados de demonstração: o seu caderno de encargos verifica-se em ecrãs reais, não em reuniões de receção. E se um programador intervier mais tarde, parte do código gerado (exportação ZIP, push para GitHub) em vez de uma página em branco.
O modelo a copiar
Retome estas quatro linhas e preencha-as com as suas palavras: «A minha atividade: … COISAS acompanhadas (com as suas informações-chave): … LIGAÇÕES entre elas: … ESTADOS atravessados: … NÚMEROS a ver todas as manhãs: …» Dez linhas bastam; o plano Descoberta (0 €) permite testar de imediato a aplicação que a sua página produz.