A framework que todo mundo ignora até o projeto dar errado
O que, quando e onde é mais do que um exercício de alinhamento. É o que separa um plano que vira ação real de um documento que fica trancado num SharePoint. A maioria das equipes pula direto para o como e já começa a executar sem terRespondido as três perguntas básicas. O resultado é previsível: escopo que muta, datas que se perdem, e responsabilidades que ninguém assume.
O que when and where realmente funciona
O que define o objeto da ação. Não o objetivo abstrato, o deliverável concreto. Quando estabelece o temporizador. E onde o locus de execução ou entrega. Parece óbvio, mas na prática é onde os projetos acumulam dívida. Eu já vi uma vez um programa inteiro de migração de dados ser desviado porque ninguém havia definido explicitamente onde a nova camada ficaria hospedada. A equipe assumiu que era na nuvem, mas a governança de TI tinha outra regra. Perdi seis semanas refazendo infraestrutura que já estava paga. O fluxo que eu recomendo é simples, mas exige disciplina. Você começa pelo que. Isso parece contra-intuitivo porque a cultura corporativa adora começar pelo porquê. Mas o porquê é variável. O que é fixo. Escreva o que em uma frase que um estagiário consegue repetir sem consultar o gestor. Se você precisa de mais de uma frase, o que ainda não está definido.
Depois vem o quando. E aqui tem uma armadilha que poucos percebem. As datas não são compromissos. Elas são hipóteses. Eu costumo marcar sempre três níveis: data otimista, data base e data limite. A data otimista é aquela que a equipe sonha. A data base é a que leva em conta gargalos reais, como dependências externas e férias. A data limite é o dia em que, se o projeto ainda não estiver entregue, você cancela e aprende com o que aconteceu. Isso elimina a ilusão de que uma data única resolve tudo. Por fim, o onde. Aqui é onde a maioria trava. Onde significa dois things: onde o trabalho acontece e onde o resultado é entregue. Se você está desenvolvendo um produto, o onde técnico é o repositório, a arquitetura, o ambiente de staging. O onde operacional é o ponto de contato com o cliente ou usuário final. Anotar ambos evita aquele clássico erro de equipe que entrega a feature no lugar errado, com a documentação certa, mas no canal errado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Existem limites para esse framework. Ele não funciona bem em ambientes de extrema incerteza, como pesquisa exploratória ou startups de estágio zero. Nesses casos, o que ainda não existe. Forçar esse modelo nesses cenários só gera falsa sensação de controle. O ideal é usar o que when and where em iniciativas com ciclo de vida médio, entre quatro semanas e doze meses, onde há estabilidade suficiente para definir parâmetros sem precisar de revisões diárias. Se o seu contexto é muito volátil, considere alternar com um loop de aprendizado rápido. Defina o que, quando e onde para um sprint ou experimento curto, revise semanalmente e ajuste. A estrutura existe para dar clareza, não para prender você a um plano que já morreu.
Como aplicar na prática sem perder tempo
Crie um documento único, no máximo três páginas. Cole as três perguntas no topo. Responda cada uma com clareza. Liste as dependências externas. Anote os riscos conhecidos. Compartilhe com todas as partes interessadas antes de qualquer execução. Leva uns dez minutos para fazer isso direito. Levanta-se duas horas de reuniões de alinhamento que acontecem depois quando as coisas saem do controle. Eu mantenho um template fixo pra isso. Começa com uma linha de definição, seguida de tabelas simples: uma para cronograma, outra para localização e responsabilidades. Nada de diagramas complexos. Tabelas funcionam. Elas são fáceis de atualizar, fáceis de comparar e não exigem software específico. Qualquer planilha ou editor de texto serve.
O erro mais comum é tratar isso como coisa de documentação. Não é. É coisa de comunicação. O documento existe para que qualquer pessoa nova no projeto consiga entender o estado atual em três minutos. Se levar mais tempo que isso, algo está mal escrito ou mal estruturado. Volte e simplifique. Outro detalhe prático. Atualize o quê, quando e onde a cada mudança significativa, não apenas no início. Projetos vivem. Se o escopo muda, o quando precisa refletir. Se o ambiente de entrega muda, o onde também. Documentar essa evolução evita surpresas e cria um histórico útil para próximas iterações.
