Discovery: entender antes de construir
Todo projeto começa entendendo a operação como ela é, não como deveria ser. Na etapa de Discovery, quem vai construir o sistema conversa com quem opera no dia a dia — não só com quem contrata — para mapear onde a informação se perde, onde há retrabalho e o que realmente precisa mudar.
O resultado dessa etapa é um escopo priorizado: o que entra na primeira versão, o que fica para depois, e uma proposta com prazo e investimento definidos por escrito, antes de qualquer linha de código.
Design: ver o produto antes de ele existir
Antes de programar, o escopo vira fluxo e o fluxo vira tela. Um protótipo navegável das telas principais é validado com as pessoas que vão operar o sistema — e é a etapa mais barata para corrigir uma decisão errada: mudar uma tela em protótipo custa horas; mudar depois de pronta, custa semanas.
Build: entregas visíveis semana a semana
O desenvolvimento acontece em ciclos curtos, com entregas que podem ser vistas e testadas semana a semana, em vez de um período longo sem nenhum retorno visível. Isso permite ajustar o rumo enquanto ainda é barato, e não só depois de tudo pronto.
O objetivo dessa etapa é colocar a primeira versão útil em produção o quanto antes — o processo da EAE busca ter um MVP no ar em até 12 semanas, com o que ficar fora dessa primeira versão entrando depois, por prioridade.
Evolução: o go-live é o começo, não o fim
Depois do lançamento, o uso real do sistema mostra o que o desenho não previu. Na etapa de Evolução, o time mede como as pessoas estão usando o sistema, ajusta o que a prática ensinou e prioriza novos módulos — além de cuidar de sustentação, monitoramento e segurança contínua.
É por isso que o relacionamento com quem constrói o sistema não termina no lançamento: ele muda de fase. Um software que para de evoluir junto com o negócio vira legado rápido demais.
