Documentation as a Gate: o modelo de maturidade que a CDPR levou 20 anos para adotar

A CD Projekt Red construiu alguns dos RPGs mais aclamados da história — e quase perdeu o conhecimento técnico que os tornou possíveis. A história dos seus erros de documentação é, na verdade, um manual do que não fazer.


No início de maio de 2025, durante o painel "Old Docs Die Hard" na conferência Digital Dragons, em Cracóvia, dois technical writers da CD Projekt Red subiram ao palco para fazer algo incomum no mercado de games AAA: admitir, publicamente, que a documentação interna da empresa foi um caos por décadas.

Jarosław Ruciński (lead technical writer) e Adrian Fulneczek (senior technical writer) não vieram defender a empresa. Vieram com um diagnóstico clínico — e com a proposta de um novo modelo que, esperançosamente, vai evitar que The Witcher 4 e Cyberpunk 2 repitam os erros do passado.

Para quem trabalha com documentação técnica, a apresentação deles é obrigatória. Não porque fala de videogames, mas porque descreve, com rara honestidade, um padrão de falha que ocorre em praticamente qualquer organização que cresce rápido demais para os seus próprios processos.


A linha do tempo do caos

A CDPR não cometeu um erro único e catastrófico. Ela cometeu erros diferentes, em momentos diferentes, por razões diferentes — o que é, na verdade, muito mais instrutivo.

Projeto Problema central Impacto posterior
The Witcher 1 & 2 Cultura oral; nenhuma documentação estruturada produzida Conhecimento técnico irrecuperável; reconstrução por engenharia reversa necessária para o Remake
The Witcher 3 Wiki interna desligada pela gestão ao fim do projeto, por corte de custos Equipes subsequentes sem acesso ao contexto de decisões de design e arquitetura
Cyberpunk 2077 Mais de 8.000 páginas produzidas, mas sem processo de manutenção Documentação obsoleta ou inconsistente; custo de manutenção insustentável

O padrão aqui não é falta de esforço — é falta de estrutura. Em cada fase, a CDPR resolveu o problema aparente do momento anterior e criou um problema novo.

  • Nos primeiros jogos, o problema era a ausência de documentação.
  • No Witcher 3, o problema foi tratar documentação como artefato descartável ao fim do ciclo.
  • No Cyberpunk 2077, o problema foi escalar volume sem escalar governança.

O problema que ninguém menciona: documentação como custo, não como ativo

Existe uma crença organizacional difundida — especialmente em empresas de produto — de que documentação é overhead. Um custo que se paga quando há tempo sobrando, que se corta quando o prazo aperta, e que se abandona quando o projeto termina.

A decisão de desligar a wiki do Witcher 3 após o lançamento é o exemplo perfeito dessa lógica. Do ponto de vista do trimestre financeiro, faz sentido: o projeto acabou, a equipe foi realocada, o servidor custa dinheiro. Do ponto de vista do ciclo de vida do produto — especialmente considerando remakes, DLCs, sequências — é uma decisão que transfere custo para o futuro com juros compostos.

Quando a equipe do Witcher Remake foi convocada, descobriu que praticamente não havia documentação técnica do jogo original. O conhecimento estava nas cabeças de pessoas que, em muitos casos, já não trabalhavam mais na empresa. A solução foi engenharia reversa — que é, basicamente, pagar pela documentação que deveria ter sido feita, com o preço acrescido de incerteza, tempo e risco de erro.


O modelo antigo: documentação como entregável paralelo

Nos projetos anteriores à mudança, a documentação na CDPR funcionava como a maioria das organizações ainda opera hoje:

Desenvolvimento → [acontece] → Documentação → (eventualmente, talvez)

A documentação era produzida depois, ao lado, ou quando havia tempo. Ela não estava acoplada ao processo de desenvolvimento — era um artefato que se esperava que emergisse naturalmente do trabalho, sem dono definido, sem critério de completude e sem consequência caso não existisse.

Esse modelo tem um nome na literatura de processos: documentação como subproduto. E ele falha de formas previsíveis:

  1. Amnésia de decisão — as razões por trás de escolhas arquiteturais se perdem; versões futuras reintroduzem problemas já resolvidos
  2. Silos de conhecimento — o que uma equipe aprende não chega às outras
  3. Bus factor elevado — o conhecimento crítico reside em pessoas, não em sistemas
  4. Onboarding degradado — novos membros levam meses para atingir produtividade porque o contexto não está registrado

O modelo novo: documentation as a gate

A mudança que Ruciński e Fulneczek apresentaram no Digital Dragons tem um nome simples, mas uma implicação profunda: documentation as a gate.

A ideia é direta: um milestone de desenvolvimento não pode ser fechado sem que a documentação correspondente esteja completa e aprovada. Documentar deixa de ser uma atividade paralela e passa a ser uma condição de progresso.

Desenvolvimento → [gate de documentação] → Próximo milestone
                         ↑
               Documentação incompleta
               bloqueia o avanço

A citação de Fulneczek resume o espírito da mudança:

"Part of the requirements to pass that gate is the documentation — which wasn't the case before."

Isso muda a dinâmica de incentivo completamente. Antes, documentar era algo que se fazia quando havia tempo. Agora, não documentar tem uma consequência concreta e imediata: o projeto não avança.


O que muda na prática

Além da mecânica do gate, a CDPR implementou outras mudanças estruturais que merecem atenção:

Base de conhecimento compartilhada entre projetos

The Witcher 4 e Cyberpunk 2 são desenvolvidos em paralelo, por equipes geograficamente distribuídas (Europa e América do Norte). O risco de siloing era enorme.

A solução adotada foi eliminar as permissões por equipe na base de conhecimento. Se a equipe do Witcher 4 encontra uma solução técnica para Unreal Engine 5, essa solução fica disponível para a equipe do Cyberpunk 2 — e vice-versa. O conhecimento circula horizontalmente, não fica preso nas fronteiras organizacionais.

Documentação como substituto de comunicação síncrona

Com equipes em fusos horários diferentes, a comunicação verbal e informal não escala. A documentação estruturada passa a funcionar como o mecanismo primário de transferência de contexto — não como um backup da comunicação, mas como o canal principal.

Esse é um princípio que empresas como GitLab e Basecamp já aplicam há anos com o conceito de async-first: se não está escrito, não existe.

Nova definição de "done"

A mudança mais cirúrgica talvez seja a mais simples: redefinir o que significa um item de trabalho estar concluído. Antes, "done" era uma questão funcional — o código roda, a feature foi entregue. Agora, "done" inclui documentação como critério explícito.

Essa é uma mudança de contrato. Não é uma recomendação de boas práticas; é um requisito que afeta diretamente o fluxo de trabalho de cada desenvolvedor, designer e engenheiro da empresa.


O modelo de maturidade implícito

Olhando para a trajetória da CDPR, é possível mapear um modelo de maturidade de documentação que, curiosamente, espelha o que muitas organizações vivem em ordem similar:

Nível Característica Exemplo na CDPR
0 — Ausência Nenhuma prática estabelecida; conhecimento é oral The Witcher 1 e 2
1 — Espontânea Documentação existe, mas é produzida de forma ad hoc e sem processo Início do Witcher 3
2 — Descartável Documentação é produzida, mas abandonada ao fim do ciclo Wiki do Witcher 3 desligada após lançamento
3 — Escalada sem governança Alto volume de documentação, mas sem processo de manutenção e revisão Cyberpunk 2077 (8.000+ páginas obsoletas)
4 — Integrada Documentação é parte do processo de desenvolvimento; gate obrigatório Witcher 4 / Cyberpunk 2 (modelo atual)

A maioria das organizações que conheço oscila entre os níveis 1 e 3. O salto para o nível 4 não é técnico — é cultural e processual. Requer que a liderança trate documentação como um ativo de produto, não como overhead operacional.


Por que isso importa além dos games

A história da CDPR é sobre documentação de desenvolvimento de software — mas o padrão de falha é universal.

Qualquer organização que cresce sem investir em knowledge management vai, eventualmente, enfrentar uma versão do problema da CDPR: um momento em que o custo de não ter documentado supera em muito o custo que a documentação teria representado.

A diferença é que a CDPR teve a coragem de expor esse ciclo publicamente, com nomes e datas, em um painel gravado. Isso é raro — e é exatamente por isso que vale a atenção.

O que Ruciński e Fulneczek descreveram no Digital Dragons não é uma solução nova. É uma solução antiga que finalmente ganhou força suficiente para mudar o processo de uma das maiores produtoras de RPG do mundo.


Fontes: GamesRadar+, VideoCardz, WCCFTech, Insider Gaming — cobertura do painel "Old Docs Die Hard", Digital Dragons 2025.