A pergunta certa é a primeira linha de código

É tentador começar pela tela. Alguém descreve um problema, e a resposta mais rápida — a mais confortável — é abrir o editor e começar a construir. Isso é abandono. Não do trabalho, mas da pergunta.

Toda operação real esconde a própria pergunta atrás de um sintoma. "Precisamos de um app para os representantes" é um sintoma. A pergunta real pode ser outra: por que o representante não sabe quando visitar cada cliente? A resposta muda completamente o que vale a pena construir — e às vezes revela que o problema não é de software.

Investigar não é atrasar

Existe uma crença implícita de que investigar consome tempo que poderia ser usado para construir. É o oposto: cada hora gasta entendendo mal um problema custa muito mais depois, quando o sistema já está em produção e a pergunta errada virou arquitetura.

Investigar, na prática, significa perguntar quem faz o trabalho hoje, como ele faz, o que ele contorna, o que ele evita fazer, e o que aconteceria se ele simplesmente parasse de fazer aquilo. A resposta para essa última pergunta costuma ser mais reveladora do que qualquer especificação de requisitos.

O código é a parte fácil

Com ferramentas atuais, escrever código deixou de ser o gargalo. Isso não torna a engenharia menos importante — torna a pergunta que a engenharia responde mais importante do que nunca. Um sistema bem construído para resolver o problema errado ainda é um sistema errado, só que mais rápido de chegar lá.

Antes de desenvolver um produto, desenvolvemos entendimento.

Essa frase não é um slogan de parede. É um filtro prático: se não conseguimos explicar, em uma frase, qual pergunta operacional real um sistema responde, ainda não é hora de escrever a primeira linha de código — mesmo que já saibamos, tecnicamente, como escrevê-la.