As 2 etapas do planejamento de projeto

Planejamento de projeto é um assunto que daria uma semana inteira de conteúdo se a gente fosse cobrir tudo. Mas existe uma divisão fundamental que pouca gente percebe desde o início: todo projeto tem dois planejamentos distintos que precisam acontecer, e um não substitui o outro.

O primeiro é o planejamento com o cliente. O segundo é o planejamento técnico. São etapas diferentes, com objetivos diferentes, e precisam acontecer nas duas situações, mesmo quando o cliente é você mesmo.

Etapa 1: o planejamento com o cliente

Essa etapa existe para alinhar expectativas. E alinhar expectativas significa perguntar, não assumir.

O que acontece com frequência é o seguinte: o cliente chega com uma ideia na cabeça, muitas vezes alimentada por algo que viu em algum lugar, e acredita que o resultado vai ser muito além do que o sistema em si pode entregar. Um exemplo clássico, alguém contrata um site achando que só o fato de ter o site vai fazer o negócio explodir. Você faz o site. Um site tecnicamente correto, bem construído. E na entrega, a frustração de ambos os lados é quase certa, porque o cliente esperava uma coisa completamente diferente do que você sabia que estava fazendo.

Esse problema não tem nada a ver com qualidade de código. Ele tem a ver com falta de comunicação antes de qualquer linha ser escrita.

Existem dois pontos principais para focar nessa etapa:

Entender o que o usuário final precisa. O cliente e o usuário final quase sempre são pessoas diferentes. Se você está construindo um sistema de gestão de estoque para uma empresa, o cliente pode ser o dono. Mas o usuário final é a pessoa que vai usar aquilo todo dia. O que o dono quer nem sempre reflete o que quem usa na prática precisa. Os dois precisam estar alinhados no que você vai construir.

Alinhar as expectativas com o cliente. Uma vez que você entende o que o usuário final precisa, você alinha isso com o que o cliente está esperando. Quando as duas coisas batem, o resultado é um sistema que funciona de verdade para quem vai usar e que satisfaz quem contratou.

Para chegar nesse alinhamento existem várias técnicas: entrevistas, brainstorming estruturado com as pessoas envolvidas, prototipagem rápida das telas principais. O brainstorming estruturado, diferente de um papo livre que pode se estender sem conclusão, tem foco definido. Você entra no assunto X com a técnica Y, chega a um resultado, e usa esse resultado como base para o próximo passo. Direto ao ponto.

A prototipagem também serve bem aqui, porque um esboço visual resolve desentendimentos em segundos que levariam horas para resolver em texto ou conversa.

Etapa 2: o planejamento técnico

Depois de entender o que vai ser construído e para quem, começa o planejamento técnico. E aqui tem uma sequência específica que faz diferença.

Na prática do mercado, ninguém vai te pedir quinze tipos de diagrama UML para cada sistema. Empresas muito grandes com muitas equipes podem usar alguns padrões de documentação, mas no dia a dia isso não é a realidade. O que acontece de verdade é essa sequência:

Lista de funcionalidades. Você escreve tudo que o sistema vai ter, baseado no que ficou definido na etapa anterior. Cada item da lista é uma funcionalidade do sistema.

Particularidades de cada funcionalidade. Para cada item da lista, você detalha como vai funcionar. O login vai usar e-mail e senha ou CPF e senha? A autenticação vai usar JWT? A galeria de fotos vai gerar versão miniatura para economizar banda? Esses detalhes precisam estar definidos antes de você abrir o editor.

Banco de dados. Com as funcionalidades e os detalhes mapeados, você desenha o banco. A lógica do código vai girar em torno dessa estrutura, então quanto antes ela estiver definida, mais direto você escreve o código.

Wireframe. Agora você esboça as telas. Papel e caneta funcionam perfeitamente. Não precisa ser bonito, precisa ser suficiente para você saber o que vai construir antes de construir.

A partir do wireframe, existem dois caminhos válidos: você vai direto para o código, usando o wireframe como guia e aplicando o design depois, ou você passa por uma etapa de design visual antes de codificar, entregando as telas definidas para só então implementar. Os dois funcionam dependendo do contexto do projeto e da equipe.

Testes. Com o sistema construído, vêm os testes. Além dos testes unitários no próprio código, existe o que eu chamo de teste Homer Simpson: você usa o sistema tentando quebrá-lo. Clica rápido, clica duas vezes, digita o que não deveria ser digitado, coloca letras onde seria esperado um número. Você faz isso de forma exaustiva antes de qualquer coisa ir ao ar.

Produção controlada. Antes do lançamento definitivo, o sistema vai para um ambiente controlado, pode ser um subdomínio, um servidor de homologação, qualquer coisa que seja o sistema real rodando em condições reais. Você repete os testes nesse ambiente. Só depois disso o sistema vai para produção de verdade.

---

Essas etapas, cobertas nessa ordem, são o mínimo necessário para entregar algo que funcione. Não é planejamento excessivo, não é acadêmico, é o que acontece na prática quando o projeto termina bem.

Quando você pula direto para o código sem esse processo, pode até acertar por sorte. Mas as chances são que a cada manutenção o sistema vai ficando mais difícil de mexer, as expectativas vão estar desalinhadas e o custo de corrigir vai crescendo. Sistema não planejado é igual a uma bagunça que só piora quando você tenta arrumar.

Minimamente bem planejado já é o suficiente para você estar no caminho certo.