Quem constrói não é quem aprova

Em projeto de software, a velocidade de construção raramente é o gargalo. O gargalo é a aprovação: decidir, com critério, que uma entrega está pronta para produção. O método da Neuraldata existe para essa segunda parte.

Regra um: quem constrói não é quem aprova. Quem desenvolveu uma funcionalidade nunca é quem decide se ela está pronta. Outra pessoa revisa, com o critério por escrito desde a proposta. A mesma lógica que se aplica a fornecedores em qualquer área: quem inspeciona não pode ser quem entrega.

Regra dois: a régua mede a coisa certa. Um teste que passa não prova nada se mede o que é fácil medir em vez do que o cliente usa. Quando o cliente encontra um defeito que os testes não encontraram, o primeiro conserto é na régua.

Regra três: homologação em ambiente real. Interface se aprova usando, no navegador e no celular, com dados parecidos com os de produção. Uma captura de tela parada não aprova um fluxo.

Regra quatro: uma correção pronta não é uma correção entregue. O conserto só conta quando está no ambiente em que o problema aparecia, com a prova de que o caso que falhava passou a funcionar.

É assim que os sistemas dos nossos cases são mantidos, e é assim que os projetos de clientes são conduzidos. O escopo fica por escrito, a construção anda em ciclos curtos, e a aprovação é criteriosa de propósito.