Retomar sem reconstruir
Quem já deixou um projeto duas semanas e voltou a ele conhece a sensação: em que ia?, o que ficou a meio?, porque fiz isto assim? Agora multiplique-o por várias pessoas, vários projetos em paralelo e, cada vez mais, assistentes de IA que trabalham por sessões e não se lembram da anterior.
A continuidade não pode depender da memória. Tem de estar escrita, e num formato que se possa ler num minuto.
Dois documentos, duas funções
O estado é uma ficha curta e estruturada que se sobrescreve cada vez que algo muda:
- Em que fase está a aplicação e que portas de aprovação passou.
- Que marcos faltam e quais estão cumpridos.
- O que bloqueia o avanço e quem tem de o resolver.
- Qual é o passo seguinte.
O diário de bordo é um registo cronológico que só cresce: cada sessão de trabalho acrescenta uma entrada com o que se fez, o que se decidiu e o que falta. Nunca se corrige uma entrada anterior; se algo estava errado, uma entrada nova di-lo.
Porque dois e não um
Porque respondem a perguntas diferentes. O estado responde «onde estamos?» em segundos. O diário de bordo responde «como chegámos aqui?» quando é preciso entender uma decisão ou seguir o rasto de um erro. Misturá-los produz um documento demasiado longo para se ler depressa e demasiado editado para se confiar na sua história.
Regras práticas
- Atualizam-se na mesma sessão, não «depois».
- Vivem no repositório da aplicação, junto ao código.
- O que está em bruto vai à parte: as saídas longas de comandos ou os dumps não sujam o diário de bordo; guardam-se no seu próprio ficheiro e citam-se.
- São legíveis por máquinas: o estado tem estrutura fixa, para que a plataforma possa mostrar num painel em que ponto está cada aplicação.
Com a memória do projeto resolvida, é hora de construir. E construir bem começa por uma ideia muito concreta: o que se implementa tem de ser exatamente o que foi testado.
Como o aplicamos: Engenharia de Plataforma.