Estação 01 · Fundação
Objetivo
Antes de tocar em qualquer linha de código, entenda o que precisa ser feito. Pergunte ao cliente ou responsável qual resultado ele espera com essa demanda — esse questionamento pode mudar ou evoluir o escopo inicial, e evita execuções sem entendimento claro entre todos os envolvidos.
Aproveite para atualizar a documentação de Motivação/Objetivo da tarefa, deixando-a fiel ao objetivo real, de um jeito que qualquer pessoa consiga assumir a execução depois.
Regra do portão: se o objetivo não está claro para todos, a demanda não segue. Ela volta para o cliente/responsável com as perguntas necessárias.
Checklist de saída
Estação 02 · Lógica
Como irei fazer
Com o objetivo claro, descreva o fluxo em lógica simples e abstrata — sem termos técnicos ainda. A ideia é narrar o comportamento como se explicasse para alguém de fora da área, do início ao fim, incluindo o que acontece quando algo dá errado.
Ver exemplo — formulário de contato
"Irei criar um formulário na página X, com campos de nome, assunto (seleção), email (com validação) e mensagem, mais um botão de enviar. Ao clicar, valido se os campos estão preenchidos corretamente — se não estiverem, mostro uma mensagem indicando o que falta. Se estiver válido, envio as informações para o email do cliente em um formato legível e, após o envio, mostro uma mensagem de sucesso para o usuário."
Regra do portão: se não é possível descrever o fluxo com clareza sem cair em termos técnicos, há uma lacuna de entendimento ou de lógica. Busque ajuda de outra pessoa antes de seguir.
Checklist de saída
Estação 03 · Rota
Cronograma
Transforme o fluxo da etapa anterior em um checklist técnico, já considerando como cada parte será construída — plugin, validação em JS, biblioteca de envio de email, etc. Inclua também os passos "invisíveis" que raramente entram na estimativa: setup de ambiente, leitura de documentação, plano de teste, abertura de PR, documentação na ferramenta de gestão e suporte ao QA.
Ver exemplo — cronograma completo
- Configurar ambiente inicial do projeto
- Estudar/entender a documentação do projeto
- Criar campos (nome, email, assunto, texto)
- Criar validação dos campos (email, assunto)
- Criar processo de envio (validação + envio por email)
- Validar a demanda
- Montar plano de teste
- Abrir PR para os responsáveis
- Documentar a demanda na ferramenta de gestão
- Dar suporte ao QA/validação
Regra do portão: sem um cronograma claro, a demanda não segue adiante — ele é a base de tudo que vem depois, inclusive da estimativa.
Checklist de saída
Estação 04 · Régua
Estimativa
Estime cada item do cronograma — não a demanda inteira de uma vez. Estimar "criar validação do campo de email" é muito mais concreto do que estimar "o formulário". Se um item não sai da cabeça, é sinal de falta de experiência ou clareza: desmembre-o em estudar, testar e aplicar, cada um com seu próprio tempo.
Ver exemplo — item desmembrado
Criar validação do campo de email
- Estudar/pesquisar — 30 min
- Testar — 30 min
- Aplicar — 30 min
Regra do portão: item que ninguém consegue estimar é cronograma pouco claro — volte e revise a Estação 03 antes de seguir.
Checklist de saída
Estação 05 · Partida
Desenvolvimento/Execução
Última parada antes do "go": liste tudo que falta para destravar o início — acessos, dados e possíveis impedimentos. É o momento de garantir que nada vai travar a execução no meio do caminho.
Ver exemplo — lista de partida
- Acesso ao repositório
- Acesso ao admin WordPress
- Acesso ao ambiente de homologação
- Dados da ferramenta de SMTP
Checklist de saída
Relatório final
Pronto para documentar na ferramenta
Modelo de report do exemplo do formulário de contato — use como referência de formatação para fechar o cronograma, a estimativa e os acessos necessários na sua própria demanda.
Ainda com dúvida em alguma estação?
Assista ao vídeo com a explicação completa ou consulte o texto original do plano de ação.
Autor do plano
Quem monta esse plano com você
Gustavo Henrique
Sou desenvolvedor WordPress há mais de 15 anos — hoje como tech lead de projetos na Studio Visual e à frente da minha própria consultoria, a g2D. Esse plano de ação nasceu da mesma dor que eu via se repetir: demanda que começa sem clareza, vira retrabalho e desgasta a confiança de quem entrega.
Na mentoria, eu não entrego um curso gravado. Acompanho você aplicando esse processo nas suas demandas reais — seja pra ganhar previsibilidade como freelancer, seja pra crescer dentro do time onde você já está. A gente questiona junto, ajusta a rota e mede o que evoluiu, semana a semana.
Se o que você viu até aqui fez sentido, dá uma olhada no meu trabalho e nas minhas redes — e bora conversar sobre a mentoria.
Próximo passo
Quer ajuda pra aplicar isso no seu dia a dia?
Na minha mentoria eu acompanho de perto a aplicação do plano de ação nas suas demandas reais, além do seu desenvolvimento pessoal e profissional como desenvolvedor. É orientação prática, não só teoria.
💬 Falar sobre a mentoria no WhatsApp