Modèle de documentation du projet principal

Dans les deux premières sections de ce modèle, creusez le but de votre projet. Dans la section Besoins non satisfaits, expliquez pourquoi ce projet existe en premier lieu. Qu'est-ce que vos clients attendent de vous qu'ils ne peuvent pas accomplir pour l'instant et comment ce projet va-t-il y remédier ? Dans la section Objectifs, indiquez ce que vous espérez accomplir. Qu'il s'agisse d'augmenter les inscriptions payantes ou d'améliorer les avis des utilisateurs, identifiez votre objectif final afin que votre équipe sache vers quoi elle tend.

Une fois le « pourquoi » éliminé, il est temps de se concentrer sur le « qui ». Dans la section Personas utilisateur du modèle, énumérez les personas client qui sont les principales cibles de ce changement. Il est difficile de comprendre un projet dans son ensemble sans savoir à qui il est destiné. Ainsi, le fait de documenter ce contexte ici aide tous les membres de votre équipe à mieux saisir les tenants et aboutissants de ce projet.

Les job stories constituent un moyen utile d'exposer les problèmes auxquels vos utilisateurs sont confrontés et d'indiquer comment vous allez les résoudre. Dans la section du modèle dédiée aux tâches, suivez les instructions pour reconstituer votre propre job story à l'aide de cette formule :

Lorsque je : décrivez le contexte spécifique.
Je souhaite : décrivez le besoin de l'utilisateur.
Afin de pouvoir : décrivez la raison d'être de ce besoin.

Par exemple, voici à quoi ressemble une job story de MURAL :

Lorsque je participe à un atelier de design dans MURAL et que nous identifions des éléments d'action
Je souhaite pouvoir les envoyer facilement au système de suivi des tickets utilisé par mon équipe
Afin de pouvoir continuer à travailler sans changer mon workflow

Votre projet ne se déroule pas en vase clos, et il est important d'avoir une trace des considérations et décisions passées. Dans la section Un peu d'histoire du modèle, décrivez d'autres stratégies que vous avez essayé d'appliquer aux tickets et ce que vous en avez appris. La section Contraintes vous permet de noter si le ticket est affecté par un projet ou s'il affecte un autre projet, car ces dépendances importantes sont à garder en mémoire. Enfin, la section Explorations + décisions permet de consigner les autres approches envisagées, ainsi que les avantages et les inconvénients de chacune. Vous ne voulez pas perdre de vue les idées de votre équipe (même si vous n'y donnez pas suite pour l'instant). Vous pourriez utiliser ces sources d'inspiration plus tard !

Si votre projet dispose de versions, présentez-les dans le tableau Versions du modèle. Le modèle vous donne l'espace nécessaire pour indiquer le nom de la version, la valeur qu'elle ajoute ainsi que le périmètre. Vous pouvez également définir un état pour chaque version afin de suivre son avancement.

Vous avez l'impression que votre projet ne fait que déboucher sur, eh bien, d'autres projets ? C'est normal et également pour cette raison qu'il est si important de noter les éléments d'action de suivi. Quoi qu'il faille ensuite faire, ajoutez-le à la checklist dans l'espace Étapes suivantes. Vous pouvez également définir un état pour chaque élément afin de vous assurer que ces choses sont bien faites et que votre équipe n'en oublie pas.

Même si nous aimerions vous assurer que chaque projet sera un franc succès, vous savez que ce n'est pas la réalité. C'est pourquoi il est important de fixer un point de référence, afin que vous sachiez si votre projet a répondu à vos attentes. Notez votre point de repère dans la section Impact du modèle. Que vous ayez atteint ou non cette barre, vous serez heureux de voir cette mesure documentée, tant pour la motivation que pour le contexte historique.