Por Que o Seu Projeto Precisa de um Documento de Design Antes de Começar a Construir

Um documento de design é um plano escrito que descreve o que você está construindo, por que está construindo e como vai funcionar. Não é um manual do usuário. Não é uma lista de tarefas. É o pensamento que acontece antes de a construção começar. Em essência, um documento de design responde a três perguntas. Qual problema estamos resolvendo? Qual é a solução proposta? E quais são as trocas e alternativas que consideramos? Todo o resto — os detalhes técnicos, os limites de escopo, as estimativas de cronograma — depende dessas três perguntas. Os documentos de design têm nomes diferentes dependendo da área. Equipes de software os chamam de documentos de design técnico ou RFCs. Desenvolvedores de jogos escrevem documentos de design de jogo. Equipes de produto escrevem documentos de requisitos de produto. O formato varia, mas o objetivo é sempre o mesmo: tirar o plano da sua cabeça e colocá-lo em um documento que outras pessoas — ou o você do futuro — possam ler e entender.

Parece contra-intuitivo. Você está animado para começar a construir. A ideia está clara na cabeça. Escrever um documento parece trabalho burocrático que te atrasa. Então você pula e vai direto para a implementação. Duas semanas depois, você percebe que a arquitetura não suporta uma funcionalidade que você assumiu que seria fácil. Ou um colega de equipe construiu algo que contradiz a sua abordagem porque você nunca escreveu o que a abordagem era. Ou você se depara com uma decisão de design que não pensou bem e agora precisa refatorar. Um documento de design captura esses problemas antes que custem tempo real. Quando você escreve como algo deve funcionar, é obrigado a pensar nos detalhes. Você descobre casos extremos. Percebe dependências. Percebe que a funcionalidade "simples" na verdade requer mudanças em três sistemas diferentes. O tempo que você passa escrevendo um documento de design é sempre menor do que o tempo que gastaria corrigindo problemas que o documento teria capturado. Nem é próximo. Algumas horas de escrita podem economizar semanas de retrabalho.

Você não precisa de um template rígido, mas um bom documento de design geralmente cobre estas áreas. Comece com a visão geral. Um ou dois parágrafos explicando o que este documento abrange e por que importa. Qualquer pessoa deve poder ler esta seção e entender o escopo. Em seguida, defina o problema. O que está quebrado, faltando ou sendo necessário? Seja específico. "Os usuários precisam de uma pesquisa melhor" é vago. "Os usuários não conseguem encontrar projetos antigos porque a visualização de lista atual não suporta filtragem ou classificação" é útil. Então descreva a solução proposta. Esta é a maior parte do documento. Explique o que você planeja construir, como vai funcionar e como será a experiência do usuário. Inclua detalhes suficientes para que outra pessoa na equipe possa implementá-lo apenas com base nessa descrição. Adicione uma seção sobre alternativas consideradas. Quais outras abordagens você avaliou? Por que escolheu esta? Isso mostra o raciocínio e ajuda leitores futuros a entender a decisão. Por fim, liste as questões abertas e os itens fora do escopo. O que você decidiu deliberadamente não fazer? O que ainda precisa de discussão? Isso evita o escopo flutuante e mantém o documento honesto sobre o que cobre e o que não cobre.

Um documento de design não é algo que você escreve uma vez e esquece. Os melhores documentos de design evoluem com o projeto. Conforme você constrói, aprende coisas. Algumas suposições se mostrarão erradas. Algumas partes do plano mudarão. Isso é completamente normal. O documento deve refletir essas mudanças. Adicione notas sobre o que mudou e por quê. Atualize as seções que não correspondem mais à realidade. Marque as decisões que foram revisadas. Isso transforma o documento de design em um histórico do projeto. Seis meses depois, quando alguém perguntar "por que construímos desta forma?", a resposta está no documento. Você não precisa depender de ninguém se lembrando de uma conversa de meses atrás. A chave é tornar o documento fácil de atualizar. Se ele vive em uma ferramenta desconectada do projeto real, ninguém vai se dar ao trabalho de atualizá-lo. Se está bem ao lado das tarefas e cronogramas, atualizá-lo se torna parte natural do fluxo de trabalho. O IndieDevBoard inclui um recurso de documentos de design com seções estruturadas que vivem dentro do projeto, para que a especificação permaneça próxima ao trabalho que descreve.

Se você está no desenvolvimento de jogos, pode estar se perguntando como isso se relaciona com um documento de design de jogo, comumente chamado de GDD. Eles são relacionados, mas diferentes. Um GDD é específico para jogos. Normalmente cobre o conceito do jogo, mecânicas, história, design de níveis, direção artística, áudio, UI e muito mais. É a bíblia do jogo. Tudo sobre o jogo deve ser descritível a partir do GDD. Um documento de design no sentido mais amplo é sobre qualquer projeto ou funcionalidade. Pode descrever uma única funcionalidade dentro de um jogo, um design de API, uma reformulação de site ou um novo processo. É mais focado e geralmente mais curto do que um GDD. Na prática, muitas equipes de jogos usam ambos. O GDD é o documento de visão de alto nível. Documentos de design individuais cobrem sistemas ou funcionalidades específicas dentro do jogo, como o sistema de combate, o inventário ou a camada de rede multiplayer. O GDD diz "o jogo tem um sistema de inventário". O documento de design explica exatamente como o sistema de inventário funciona, como é o modelo de dados e como interage com outros sistemas.

Você não precisa escrever um documento de design perfeito na primeira tentativa. Comece com o básico. Escreva o que está construindo e por quê. Descreva a solução com detalhes suficientes para ser útil. Adicione questões abertas para qualquer coisa que não tenha certeza. Conforme você fica mais confortável, naturalmente vai adicionar mais estrutura. Desenvolverá um senso de quanta quantidade de detalhes é suficiente. Aprenderá quais seções importam mais para o tipo de projeto. O importante é começar. Um documento de design aproximado que leva uma hora para escrever é infinitamente mais útil do que um perfeito que você nunca se dá ao trabalho de escrever. O seu eu do futuro e os colegas de equipe vão agradecer.