Pourquoi votre projet a besoin d'un document de design avant de commencer à construire

Un document de design est un plan écrit qui décrit ce que vous construisez, pourquoi vous le construisez, et comment cela fonctionnera. Ce n'est pas un manuel utilisateur. Ce n'est pas une liste de tâches. C'est la réflexion qui a lieu avant que la construction commence. Fondamentalement, un document de design répond à trois questions. Quel problème résolvons-nous ? Quelle est la solution proposée ? Et quels sont les compromis et alternatives que nous avons envisagés ? Tout le reste, les détails techniques, les limites du périmètre, les estimations de calendrier, découle de ces trois questions. Les documents de design portent différents noms selon l'industrie. Les équipes logicielles les appellent documents de conception technique ou RFC. Les développeurs de jeux rédigent des documents de game design. Les équipes produit écrivent des documents d'exigences produit. Le format varie, mais l'objectif est toujours le même : sortir le plan de votre tête et le mettre dans un document que d'autres personnes, ou votre futur vous, peuvent lire et comprendre.

Cela semble contre-intuitif. Vous avez hâte de commencer à construire. L'idée est claire dans votre tête. Rédiger un document semble être du travail administratif qui vous ralentit. Alors vous le sautez et plongez directement dans l'implémentation. Deux semaines plus tard, vous réalisez que l'architecture ne supporte pas une fonctionnalité que vous pensiez simple. Ou un coéquipier a construit quelque chose qui contredit votre approche parce que vous n'avez jamais écrit quelle était l'approche. Ou vous tombez sur une décision de design que vous n'avez pas approfondie et maintenant vous devez refactoriser. Un document de design détecte ces problèmes avant qu'ils ne vous coûtent du temps réel. Quand vous écrivez comment quelque chose doit fonctionner, vous êtes obligé de réfléchir aux détails. Vous découvrez des cas limites. Vous remarquez des dépendances. Vous réalisez que la fonctionnalité « simple » nécessite en fait des modifications dans trois systèmes différents. Le temps passé à rédiger un document de design est toujours inférieur au temps que vous auriez passé à corriger les problèmes que le document aurait détectés. Ce n'est même pas comparable. Quelques heures de rédaction peuvent faire économiser des semaines de retravail.

Vous n'avez pas besoin d'un modèle rigide, mais un bon document de design couvre généralement ces domaines. Commencez par l'aperçu. Un ou deux paragraphes qui expliquent ce que couvre ce document et pourquoi c'est important. N'importe qui devrait pouvoir lire cette section et comprendre le périmètre. Ensuite, définissez le problème. Qu'est-ce qui est cassé, manquant ou nécessaire ? Soyez précis. « Les utilisateurs ont besoin d'une meilleure recherche » est vague. « Les utilisateurs ne peuvent pas retrouver leurs anciens projets parce que la vue en liste actuelle ne supporte ni le filtrage ni le tri » est utile. Puis décrivez la solution proposée. C'est le cœur du document. Expliquez ce que vous prévoyez de construire, comment cela fonctionnera, et à quoi ressemblera l'expérience utilisateur. Incluez suffisamment de détails pour que quelqu'un d'autre dans l'équipe puisse l'implémenter à partir de cette seule description. Ajoutez une section sur les alternatives envisagées. Quelles autres approches avez-vous évaluées ? Pourquoi avez-vous choisi celle-ci ? Cela montre votre raisonnement et aide les futurs lecteurs à comprendre la décision. Enfin, listez les questions ouvertes et les éléments hors périmètre. Qu'avez-vous délibérément décidé de ne pas faire ? Qu'est-ce qui nécessite encore discussion ? Cela empêche la dérive du périmètre et maintient le document honnête sur ce qu'il couvre et ne couvre pas.

Un document de design n'est pas quelque chose que vous écrivez une fois pour l'oublier. Les meilleurs documents de design évoluent avec le projet. En construisant, vous apprendrez des choses. Certaines hypothèses s'avéreront fausses. Certaines parties du plan changeront. C'est tout à fait normal. Le document devrait refléter ces changements. Ajoutez des notes sur ce qui a changé et pourquoi. Mettez à jour les sections qui ne correspondent plus à la réalité. Marquez les décisions qui ont été révisées. Cela transforme votre document de design en historique de projet. Six mois plus tard, quand quelqu'un demande « pourquoi l'avons-nous construit ainsi ? », la réponse est dans le document. Vous n'avez pas à compter sur le souvenir que quelqu'un pourrait avoir d'une conversation datant de plusieurs mois. La clé est de rendre le document facile à mettre à jour. S'il vit dans un outil déconnecté de votre projet réel, personne ne prendra la peine de le mettre à jour. S'il est juste à côté de vos tâches et chronologies, sa mise à jour devient une partie naturelle du workflow. IndieDevBoard inclut une fonctionnalité de documents de design avec des sections structurées qui vivent à l'intérieur de votre projet, pour que les spécifications restent proches du travail qu'elles décrivent.

Si vous êtes dans le développement de jeux, vous vous demandez peut-être quel est le rapport avec un document de game design, communément appelé GDD. Ils sont liés mais différents. Un GDD est spécifique aux jeux. Il couvre généralement le concept du jeu, les mécaniques, l'histoire, le level design, la direction artistique, l'audio, l'interface, et plus encore. C'est la bible du jeu. Tout ce qui concerne le jeu devrait être descriptible à partir du GDD. Un document de design au sens large concerne tout projet ou fonctionnalité. Il pourrait décrire une seule fonctionnalité au sein d'un jeu, une conception d'API, une refonte de site web ou un nouveau processus. Il est plus ciblé et généralement plus court qu'un GDD. En pratique, beaucoup d'équipes de jeux utilisent les deux. Le GDD est le document de vision de haut niveau. Les documents de design individuels couvrent des systèmes ou fonctionnalités spécifiques dans le jeu, comme le système de combat, l'inventaire ou la couche réseau multijoueur. Le GDD dit « le jeu a un système d'inventaire ». Le document de design explique exactement comment le système d'inventaire fonctionne, à quoi ressemble le modèle de données, et comment il interagit avec les autres systèmes.

Vous n'avez pas besoin d'écrire un document de design parfait du premier coup. Commencez par les bases. Écrivez ce que vous construisez et pourquoi. Décrivez la solution avec suffisamment de détails pour que ce soit utile. Ajoutez des questions ouvertes pour tout ce dont vous n'êtes pas sûr. À mesure que vous vous familiariserez, vous commencerez naturellement à ajouter plus de structure. Vous développerez un sens pour savoir quel niveau de détail est suffisant. Vous apprendrez quelles sections comptent le plus pour votre type de projet. L'important est de commencer. Un document de design brut qui prend une heure à écrire est infiniment plus utile qu'un document parfait que vous ne prenez jamais le temps de rédiger. Votre futur vous et vos coéquipiers vous en remercieront.