Comment rédiger un cahier des charges produit (PRD) parfait ?

Nous avons répertorié ici quelques éléments couramment utilisés pour créer un cahier des charges :

• Objectif : Définir pourquoi le produit est développé, qui l'utilisera, quel problème il résout et en quoi il s'inscrit dans les objectifs de l'entreprise.
• Caractéristiques : Décrivez les principales caractéristiques du produit. Indiquez également les spécifications détaillées.
• Contenu : énumère les éléments qui seront inclus dans cette version. Dans certains cas, les éléments qui ne seront pas inclus y sont également mentionnés.
• Calendrier du projet : Indiquez le calendrier prévisionnel pour chaque étape clé.
• Questions en suspens : les points qui n'ont pas encore été tranchés. Le fait de les garder à l'esprit permet aux équipes d'éviter toute confusion par la suite.

Comment rédiger un cahier des charges produit (étape par étape)

L'objectif principal de la rédaction d'un PRD est d'aligner l'équipe produit et l'équipe de développement sur un objectif commun. Les équipes peuvent suivre la procédure étape par étape présentée ci-dessous pour rédiger un document PRD solide :

1. Commencez par le problème, pas par la solution

Au début, résumez le problème et expliquez pourquoi vous développez ce produit.

• Exemple : « Les utilisateurs abandonnent leur panier lors du paiement car la connexion en tant qu'invité n'est pas disponible. »

Une phrase comme celle-ci définit l'objectif de la fonctionnalité. Si le problème n'est pas clairement identifié, la fonctionnalité risque fort de passer à côté de son objectif.

2. Formulez vos objectifs en termes clairs

Évitez les fioritures. Expliquez clairement ce que le produit ou la fonctionnalité doit permettre de réaliser. Une ou deux lignes suffisent.

• Exemple : « Permettre aux utilisateurs de finaliser leurs achats sans créer de compte. »

Cela aide l'équipe à rester concentrée. Si des éléments supplémentaires sont ajoutés par la suite, ils peuvent être évalués à la lumière de l'objectif initial.

3. Définir ce qui relève du champ d'application et ce qui n'en relève pas

Définissez également ce qui est inclus et ce qui n'est pas inclus dans le périmètre du produit. Ainsi, les équipes sauront quelles fonctionnalités sont incluses et lesquelles sont exclues de la prochaine version.

• Par exemple :
  • Dans le périmètre : Ajouter une connexion en tant qu'invité, envoyer un e-mail de confirmation.
  • Hors du champ d'application : enregistrer les données de l'utilisateur pour ses prochaines visites.

Ce genre de petites notes permet d'éviter les malentendus par la suite.

4. Caractéristiques de la liste

Écrivez maintenant ce que le système doit faire. Formulez vos idées en phrases courtes et claires. Utilisez un langage simple et précis.

Exemple :

• Si l'utilisateur choisit « Passer à la caisse en tant qu'invité », ignorez la création de compte
• L'adresse e-mail doit être enregistrée avant le paiement
• La confirmation de commande doit être envoyée dans les 5 minutes

Veillez également à définir clairement les exigences fonctionnelles et non fonctionnelles de haut niveau.

5. Ajouter le calendrier de lancement du produit

Personne ne peut déterminer avec précision le délai nécessaire à la finalisation du produit. Cependant, vous pouvez définir un délai estimatif pour la mise en place de chaque fonctionnalité de la version. Sur la base de ces délais, les équipes de développement peuvent établir des priorités pour le développement des fonctionnalités.

Exemple :

• La connexion via les réseaux sociaux devrait être mise en place dans les cinq premiers jours ouvrables.
• Des modifications de l'API de paiement sont prévues le mois prochain

En s'en rendant compte dès le début, on peut éviter les mauvaises surprises par la suite.

6. Définir les critères de réussite

Dans cette section, définissez les critères qui permettront aux équipes de déterminer si le produit est achevé et prêt à être proposé aux clients.

Par exemple :

• 100 % des opérations utilisateur valides (inscription/désinscription) ont été traitées sans erreur.
• Aucune faille de sécurité liée à un accès non autorisé à un compte.

7. Examen par les parties prenantes

Une fois le document créé, veillez à ce que toutes les parties prenantes l'examinent ensemble. Ainsi, les équipes peuvent s'assurer qu'aucune fonctionnalité n'a été oubliée et que tous les membres de l'équipe sont sur la même longueur d'onde.

Un cahier des charges ne se rédige pas une fois pour toutes. Les équipes doivent le mettre à jour au fur et à mesure que les exigences évoluent.

Téléchargez le document PRD de démonstration ici.

Création de cahiers des charges à l'aide de Modern Requirements

Rédiger des PRD dans Microsoft Word peut sembler pratique au premier abord, mais cela se transforme souvent en véritable casse-tête dès que les équipes s'agrandissent ou que les modifications s'accumulent. Il n'y a pas de suivi des versions. Les révisions se font par e-mail. Les modèles sont copiés et modifiés manuellement, ce qui augmente le risque d'oublier quelque chose.

C'est là qu'il convient d'envisager l'utilisation d'un outil de gestion des exigences adapté.

Grâce à Modern Requirements4DevOps, les équipes peuvent utiliser les fonctionnalité Smart Docs pour rédiger des PRD directement dans Azure DevOps. Pour créer un PRD, vous pouvez utiliser les méta-modèles prédéfinis ou en créer un nouveau, comme le montre la vidéo ci-dessous.