Arquitetura de trabalho: como parei de tratar oito projetos como oito problemas diferentes

Eu costumava pensar em arquitetura de projeto principalmente como uma decisão técnica.

Escolher stack, organizar pastas, separar serviços, decidir onde cada responsabilidade vive.

Hoje eu vejo arquitetura de uma forma muito mais ampla.

Para mim, arquitetura também é como o trabalho entra, como ele é entendido, como vira decisão, como vira tarefa e como finalmente vira execução.

Essa mudança de visão foi o que tornou possível trabalhar em várias frentes ao mesmo tempo — software, automações, ferramentas internas e até games — sem sentir que estou reaprendendo a trabalhar toda vez que troco de projeto.

Hoje eu consigo tocar algo próximo de oito projetos em paralelo com uma sensação curiosa:

não parece que estou trabalhando em oito sistemas diferentes. Parece que estou aplicando o mesmo sistema de trabalho em oito contextos diferentes.

E essa diferença mudou bastante a forma como eu desenvolvo.

Antes, cada projeto começava do zero

Durante muito tempo, meu processo era muito mais direto.

Eu tinha uma ideia.

Explicava a ideia.

Abriria um agente, passaria o contexto e começaria a construir.

Isso funciona surpreendentemente bem para coisas pequenas.

O problema aparece quando o projeto cresce.

Começam a surgir decisões antigas que ninguém lembra, features que dependem umas das outras, bugs que na verdade são problemas de requisito, coisas que pareciam importantes e deixam de ser, novas ideias que aparecem no meio do caminho e mudanças que afetam várias partes do sistema ao mesmo tempo.

Quando isso acontece, não é mais suficiente ter um bom agente ou escrever um prompt melhor.

O problema deixa de ser "como implementar isso?" e passa a ser:

como organizar tudo isso sem perder a intenção original do produto?

Foi aí que práticas que eu conhecia mais superficialmente começaram a fazer muito mais sentido: PRD, backlog, critérios de aceite, roadmap, discovery e ciclos Agile.

PRD virou uma camada de compressão

Eu não vejo mais PRD como um documento enorme que precisa existir porque algum processo manda.

Para mim, ele virou uma forma de comprimir o projeto.

Se eu preciso explicar um produto inteiro toda vez que vou tomar uma decisão, a arquitetura de trabalho já começou errada.

Um PRD bem montado me permite voltar rapidamente para algumas perguntas fundamentais:

• qual problema estamos tentando resolver?
• para quem?
• qual comportamento realmente importa?
• o que está dentro e fora do escopo?
• quais decisões já foram tomadas?
• quais restrições existem?
• como sabemos que a solução deu certo?

Essa estrutura serve tanto para um produto corporativo quanto para uma ferramenta open source ou para um jogo.

O domínio muda.

O esqueleto mental não.

E isso reduz muito o custo de trocar de contexto.

Backlog não é uma lista de coisas para fazer

Outra mudança importante foi parar de olhar backlog como uma fila enorme de tarefas.

Um backlog útil conta uma história.

Existem coisas que desbloqueiam outras.

Existem hipóteses.

Existem débitos conhecidos.

Existem features que só fazem sentido depois que uma fundação está pronta.

Existem ideias interessantes que ainda não deveriam consumir energia.

Quando esse mapa está bem organizado, eu não preciso manter o projeto inteiro na cabeça.

Posso sair de um projeto, passar alguns dias em outro e voltar sabendo:

onde estamos, o que vem depois e por que essa ordem existe.

Isso é especialmente importante quando trabalho com agentes.

Se eu simplesmente entregar uma lista solta, o agente pode executar muito bem uma tarefa que nem deveria estar sendo feita naquele momento.

A qualidade da implementação não corrige uma prioridade errada.

Critérios de aceite reduziram muito a ambiguidade

Talvez uma das coisas que mais mudou meu trabalho tenha sido aprender a escrever critérios de aceite melhores.

Uma tarefa como:

"criar sistema de inventário"

pode significar vinte coisas diferentes.

Mas quando eu começo a definir:

• o que o usuário consegue fazer;
• o que ele não consegue fazer;
• o que deve acontecer em estados vazios;
• como erros são tratados;
• quais condições encerram o fluxo;
• quais comportamentos precisam continuar funcionando;

a tarefa deixa de ser uma intenção e começa a virar algo verificável.

Isso tem um impacto enorme quando existe IA no processo.

Quanto mais aberto o pedido, mais decisões o agente precisa inventar.

Quanto melhores os critérios, menos ele precisa adivinhar.

Eu não preciso especificar cada linha de código.

Mas preciso reduzir a quantidade de decisões de produto que acabam sendo tomadas acidentalmente durante a implementação.

Roadmap deixou de ser uma promessa

Também mudei bastante a minha relação com roadmap.

Antes eu tinha uma tendência maior a pensar em roadmap como uma sequência:

primeiro fazemos A, depois B, depois C.

Hoje vejo mais como uma direção que precisa sobreviver ao contato com a realidade.

O objetivo continua existindo.

Mas novas informações podem mudar a rota.

Uma discovery pode invalidar uma feature.

Um teste pode mostrar que uma fundação precisa ser refeita.

Uma implementação pode revelar uma oportunidade melhor do que aquela que estava planejada.

Para mim, trabalhar de forma Agile começou a fazer sentido justamente aí.

Não como "fazer sprint".

Mas como a capacidade de manter estrutura sem transformar planejamento em rigidez.

Eu sei onde quero chegar, sei quais são as próximas apostas e sei por que elas estão naquela ordem.

Mas o sistema aceita mudança.

O mesmo processo começou a funcionar até para games

Uma das coisas mais interessantes foi perceber que isso não funciona apenas para software tradicional.

Tenho usado o mesmo raciocínio em desenvolvimento de jogos.

Um jogo também tem visão.

Também tem escopo.

Também tem sistemas que dependem de outros sistemas.

Também possui backlog.

Também precisa de critérios de aceite.

Uma mecânica como "inimigo persegue o jogador" parece simples até você perguntar:

• quando ele começa a perseguir?
• quando desiste?
• qual distância?
• o que acontece se perder linha de visão?
• pode atravessar determinadas áreas?
• qual comportamento tem prioridade?
• como sabemos visualmente que ele mudou de estado?

De repente, uma mecânica de game design começa a se beneficiar exatamente das mesmas ferramentas que eu usaria numa feature de produto.

Isso foi uma virada importante para mim.

A metodologia deixou de pertencer ao tipo de projeto.

Ela passou a pertencer à forma como eu resolvo problemas.

Conviver com mais pessoas mudou meu jeito de pensar

Outro fator que acelerou muito essa mudança foi passar mais tempo em ambientes com pessoas diferentes resolvendo problemas diferentes.

Quando você trabalha muito sozinho, existe um risco silencioso:

você começa a confundir a sua forma de resolver um problema com a forma de resolver o problema.

Em ambientes com mais gente, isso quebra rápido.

Uma pessoa enxerga uma dependência que você ignorou.

Outra faz uma pergunta que muda a discovery.

Um desenvolvedor encontra uma limitação técnica.

Alguém do negócio explica uma exceção que não aparecia no fluxo.

Um stakeholder muda completamente o peso de uma decisão com uma informação que você não tinha.

Esse contato foi me ensinando algo que hoje considero uma das habilidades mais importantes:

identificar que tipo de problema está na minha frente antes de tentar resolvê-lo.

Hoje eu tento encontrar a raiz antes da solução

Antes, quando alguma coisa quebrava, minha tendência era ir rapidamente para a implementação.

Qual código precisamos mudar?

Qual agente pode resolver?

Onde está o bug?

Hoje eu tento classificar primeiro.

É realmente um bug?

É uma regra de negócio mal definida?

É uma decisão de arquitetura?

É um requisito incompleto?

É uma dependência?

É um problema de prioridade?

É uma inconsistência entre documentação e implementação?

É uma feature tentando compensar um problema que deveria ser resolvido em outra camada?

Essa classificação parece simples, mas economiza uma quantidade absurda de trabalho.

Às vezes o time pode passar horas tentando corrigir código para um problema que nasceu numa decisão de produto mal definida.

Quanto mais rápido consigo chegar à raiz, menos energia é desperdiçada tratando sintomas.

Isso também mudou como eu trabalho com agentes

Talvez seja onde essa evolução fica mais visível.

Antes, eu tinha muito mais tendência a jogar um problema inteiro para um único agente.

O agente entendia, planejava, implementava e tentava validar tudo dentro do mesmo contexto.

Hoje eu prefiro pensar em orquestração.

Não necessariamente vários agentes executando tudo simultaneamente, mas responsabilidades mais claras.

Posso ter uma etapa focada em discovery.

Outra estruturando arquitetura.

Outra quebrando backlog.

Outra implementando.

Outra revisando critérios de aceite.

Outra olhando testes, regressões ou segurança.

A arquitetura do projeto vira uma espécie de protocolo compartilhado entre essas etapas.

Isso permite inclusive trabalhar em vários projetos ao mesmo tempo.

Eu não preciso que um único contexto carregue toda a minha vida.

O projeto carrega o próprio contexto.

O segredo de vários projetos é reduzir o custo de voltar

Acho que esse é o ponto central.

Trabalhar em muitos projetos não deveria significar lembrar de muitas coisas.

Deveria significar conseguir recuperar rapidamente o estado de qualquer projeto.

Se eu volto para um repositório depois de uma semana e preciso passar duas horas tentando descobrir o que eu estava fazendo, existe um problema de arquitetura de trabalho.

Quando o projeto tem:

• visão;
• PRD;
• decisões registradas;
• roadmap;
• backlog priorizado;
• critérios de aceite;
• documentação técnica;
• estado atual explícito;

voltar fica barato.

E quando voltar fica barato, paralelismo deixa de ser tão assustador.

O gargalo deixa de ser memória.

Minha arquitetura hoje é tão importante quanto minha stack

Eu continuo gostando de testar frameworks, modelos, IDEs, agentes, ferramentas de automação e novas stacks.

Mas comecei a perceber que trocar uma tecnologia raramente muda minha produtividade tanto quanto melhorar o sistema em volta dela.

Um agente mais inteligente ajuda.

Uma IDE melhor ajuda.

Um modelo novo ajuda.

Mas se o projeto não sabe o que quer, nenhuma dessas coisas resolve.

Por outro lado, quando o contexto está bem estruturado, quase qualquer boa ferramenta consegue produzir resultado.

Por isso hoje eu considero PRD, backlog, critérios de aceite, documentação e roadmap parte da minha arquitetura de desenvolvimento.

Não são coisas que ficam ao redor do código.

São parte da infraestrutura que permite que o código continue evoluindo.

O que mudou de verdade

Talvez a maior diferença seja que hoje eu sinto menos necessidade de controlar cada detalhe da execução.

Meu trabalho passou a ser muito mais montar um sistema onde as decisões certas consigam acontecer.

Definir bem o problema.

Quebrar o problema.

Explicitar as restrições.

Organizar dependências.

Determinar critérios.

Criar formas de validação.

E então distribuir execução.

É isso que tem permitido que eu passe de um navegador para uma automação, de uma ferramenta desktop para um jogo e depois volte para outro produto sem sentir que estou mudando completamente minha forma de trabalhar.

Os projetos são diferentes.

A arquitetura do trabalho continua sendo a mesma.

Próximo: meu workflow completo

Esse post ficou mais focado no porquê dessa estrutura.

No próximo quero entrar no como.

Quero documentar o workflow completo que uso hoje: como organizo projetos, onde ficam PRDs e documentação, como estruturo backlog e roadmap, como distribuo tarefas entre agentes, como mantenho memória entre sessões, quais ferramentas uso no computador e na VPS e como conecto tudo isso para trabalhar em várias frentes sem transformar o processo numa bagunça.

Provavelmente vai ser o post mais próximo de um "making of" do jeito que eu desenvolvo hoje.

Porque, no fim, a stack mudou muitas vezes.

O que realmente começou a escalar foi o sistema em volta dela.