As seis etapas, na prática.
Publicado em 21 de outubro de 2026
Para que serve um método
Software complexo raramente falha porque a equipe não sabe escrever código. Ele falha nas lacunas: entre o que o negócio precisa e o que foi especificado, entre um desenho e a sua implementação, entre uma demo que funciona e um sistema que alguém consegue operar às três da manhã. Um método é uma forma de fechar essas lacunas de propósito.
Organizamos o nosso trabalho em seis etapas: Entender, Desenhar, Construir, Validar, Operar e Evoluir. Nenhuma delas é novidade. O que importa é que cada uma produza algo que uma pessoa de fora da equipe consiga ler, questionar e reaproveitar, e que pular uma etapa seja uma decisão consciente, e não o padrão.
Este artigo descreve para que serve cada etapa, o que ela deve deixar como resultado e por que resistimos a tratar a sequência como uma cascata.
Entender e Desenhar: decidir antes de construir
Entender é a etapa mais comprimida, porque parece atraso. É também onde se cometem os erros mais baratos. O resultado é uma descrição escrita do problema: quem é afetado, o que não pode quebrar, quais restrições são fixas e o que significa estar pronto para o negócio. Se duas pessoas envolvidas descrevem o problema de formas diferentes, queremos descobrir isso agora.
Desenhar transforma essa descrição na menor arquitetura capaz de remover a principal restrição. Registramos as opções que consideramos e as que descartamos, porque o raciocínio é mais reaproveitável do que o diagrama. Um registro de decisão de meia página costuma bastar: contexto, decisão e consequências.
As duas etapas são baratas de repetir e caras de omitir. Elas também criam o vocabulário que o resto do trabalho usa, o que importa mais do que parece quando várias equipes estão envolvidas.
Construir e Validar: um ciclo só, não duas fases
Tratamos construir e validar como partes do mesmo ciclo. O trabalho é dividido em incrementos pequenos o bastante para serem revisados de uma vez, e cada incremento chega com as verificações que mostram que ele faz o que foi combinado: testes automatizados, verificações de contrato nas fronteiras de integração e revisão por alguém que não o escreveu.
Validação não é inspeção final. Uma verificação no fim só consegue avisar que algo está errado quando já é caro corrigir. Colocar as verificações cedo e perto do risco permite que uma falha aponte para uma causa. Quando uma verificação nunca pode falhar, ela não valida nada, e dizemos isso.
Validar também cobre as propriedades que as demos escondem: como o sistema se comporta sob carga, com entrada inválida, com uma dependência fora do ar e com as permissões de um usuário real.
Operar e Evoluir: o sistema vive em produção
Um release é o começo da vida útil de um sistema. Operar é tornar essa vida gerenciável: um caminho de release que pode ser repetido e revertido, monitoramento ligado ao que o usuário percebe, alertas que chegam a quem pode agir e runbooks para os incidentes que dá para prever.
Evoluir fecha o ciclo. A produção gera evidências que nenhum workshop gera: quais funcionalidades são usadas, quais modos de falha ocorrem, onde a equipe perde tempo. Levamos isso de volta para Entender, na próxima decisão, seja uma refatoração, uma nova capacidade ou a decisão de parar de investir em algo.
Se quem é dono do sistema não consegue operá-lo e evoluí-lo sem nós, o trabalho não terminou. A transição faz parte do escopo desde a primeira conversa.
Como usamos as etapas
As etapas não formam uma cascata. Elas se repetem em escalas diferentes: um programa inteiro passa por elas, e uma única funcionalidade também. Um trabalho pode começar em qualquer etapa. Um diagnóstico técnico é, em grande parte, Entender e Desenhar. Uma entrega de projeto cobre a sequência completa. Uma parceria pode passar a maior parte do tempo em Validar e Evoluir.
O que permanece constante é a disciplina de deixar algo durável em cada etapa e de registrar o que ainda não sabemos.
Se você está pensando em trabalhar conosco, uma boa primeira pergunta é simplesmente: qual das seis etapas é a mais fraca na sua organização hoje?
