Quem executa é quem sabe projetar.

Hoje, duas espécies de empresa entregam a fase de projeto no mercado de tecnologia, e nenhuma das duas é corrigida pela realidade. A consultoria que só escreve documento nunca constrói o que desenhou, e por isso nunca descobre onde a estimativa estava errada. A software house que entrega o projeto de graça precisa que o documento leve à contratação, e não que ele esteja certo, porque ali o projeto é isca.

Nós estamos nos dois lados. Escrevemos o projeto e executamos a obra. Isso muda a natureza do documento: cada estimativa que assinamos volta depois como fato medido, na forma de um sistema que entrou em produção dentro ou fora do prazo que nós mesmos previmos. É um tipo de correção que só existe para quem constrói, e é ela que faz o número de um Blueprint ser diferente de um número de apresentação.

Por isso o método é rigoroso justamente onde é mais fácil ser vago. Volume é extraído do sistema, não perguntado. Tempo é cronometrado na operação real, com quem executa o processo, e não estimado por quem gerencia. Integração só é marcada como confirmada quando alguém mostrou a documentação ou uma chamada de teste funcionou, e quando não é possível confirmar, isso fica declarado no documento em vez de virar surpresa no meio da execução. Todo número tem a fonte nomeada na própria linha, e nada entra no dossiê antes de o cliente confirmar por escrito.

E o documento é do cliente, sem reserva. Ele pode levar ao mercado e cotar a execução com quem quiser, inclusive contra nós. Isso não é generosidade. É a única prova possível de que o projeto se sustenta sozinho, e é uma oferta que quem usa projeto como isca não consegue fazer.

Código é commodity. O que sustenta um investimento em tecnologia é a leitura do negócio que vem antes dele, e é isso que o Blueprint documenta. A liderança recebe um número que consegue defender na frente do board. A engenharia recebe escopo com critério de aceite. E a empresa passa a decidir com projeto na mão, em vez de decidir primeiro e descobrir depois.