PRD : Comment et pourquoi le faire ?

Véritable lien écrit entre l’équipe produit et l’équipe de développement, le document d’exigences produit (Product Requirement Document) est un indispensable dans l’élaboration de tout projet, complexe ou non. Plus qu’un simple document, il devient un guide précieux lors de la réalisation du produit ou du service.

Alors en quoi consiste-t-il exactement ? Comment en rédiger un ?

On te dit tout !

‍

Qu’est-ce qu’un document d’exigences produit ?

Le document d’exigences produit (Product Requirement Document) sert à décrire tous les aspects nécessaires ou souhaités pour travailler un produit complexe. Il sera l’outil qui va accompagner le projet de l’idée jusqu’aux détails techniques à développer.

‍

Dans le cadre du développement d’un projet digital, ce document va définir toutes les exigences du projet. Il donnera la vision globale des valeurs et des objectifs auxquels le projet répond et devra par la même occasion permettre de comprendre les fonctionnalités, les caractéristiques et le comportement de ce dernier.

‍

Véritable outil de transmission d’informations réalisé par le chef de produit, le document d’exigences produit permet à tous les acteurs impliqués d’avoir accès aux informations en limitant les risques de mauvaises interprétations. Inscrit dans une méthode Agile, il a pour vocation d’évoluer en même temps que le développement du projet en passant par des phases fixes et des phases d’itérations.

‍

Comment rédiger un document d’exigences produit

‍

‍

En réalité il n’existe pas de document type. Chacun est libre de rédiger ce document comme il l’entend, sur le support qu’il préfère (ça aide hein ? 😅). On s’accorde cependant sur une structure plus ou moins variable décrivant le projet de la manière la plus globale à la plus détaillée.

‍

De fait, on indique en principe (mais pas toujours, tu l’auras compris) :

• Les informations générales (nom du projet, de la société, rôle et mention des collaborateurs impliqués, date de création, version du projet, etc.).
• Le contexte du projet.
• Les objectifs (ceux de l’entreprise, ceux du produit/service, planning).
• Les problématiques utilisateurs que le projet va résoudre.
• Les caractéristiques (les fonctionnalités à implémenter et leurs priorités par exemple qui aideront les développeurs à comprendre la mise en place des fonctionnalités, des cas concrets d’utilisation).
• Les exigences (en termes de priorité, de chiffres clés, d’ergonomie).
• Hypothèses et contraintes (les facteurs inconnus qui pourront se révéler en cours de route).
• Des exemples de cas et éventuellement des user stories.
• Ce pour quoi le projet n’est pas conçu (dans cette version).

‍

On peut également y ajouter un glossaire et des annexes. Ce qu’il faut comprendre, c’est qu’en tant que document qui définit les informations du projet, il vaut mieux mettre le nécessaire et d’avoir un rendu clair et précis, plutôt que de tartiner jusqu’à noyer les informations dans la masse et devenir ainsi, incompréhensible.

‍

Les inconvénients du document d’exigences produit

On l’a vu, les avantages sont nombreux. Outre le fait que le PRD rende le projet plus concret en posant sur papier tout ce qui le représente, il possède aussi quelques inconvénients.

‍

Rédiger un PRD n’est pas accessible à tout le monde

Et oui, sans surprise, la rédaction de ce document demande de l’expérience et une vraie maîtrise du métier. Il faut donc passer par un professionnel pour plusieurs raisons :

• Si la rédaction est mal construite avec notamment des exigences complexes dès le départ, le document sera sujet à des remises en questions constantes par des interrogations et des discussions sans fin.
• Un PRD trop long et trop détaillé devient une épreuve pour le lecteur qui aura tendance à ignorer.

‍

Le manque de collaboration

Parce que le document d’exigences produit est réalisé suite à l’interrogation des acteurs impliqués dans sa création, un manque de participation peut s’avérer handicapant pour la suite.

‍

La rigidité du processus

Même si le document d’exigences produit se modifie en fonction de l’avancée du projet, son processus est très rigide dans la conception. De ce fait, il peut entraver des discussions intéressantes ou d’autres modes de création qui auraient pu déboucher sur une autre forme du produit.

La solution pour remédier à tout ça ? De le voir au contraire comme un élément qui sert à discuter, négocier et réajuster. Il pourra ainsi servir de roadmap au client puisqu’il s’adapte aux problématiques que l’on rencontre.

De notre côté, on le fournit en livrable suite au design sprint. 😉

‍

En conclusion

On comprend facilement pourquoi le PRD est devenu un indispensable dans la création de produit complexe. De par son intégration dans une méthode agile et son mode collaboratif, le PRD se distingue également d’un cahier des charges et se positionne en guide pour la réalisation du produit depuis la conception jusqu’à la fin du développement.

‍