Quand Agile a été adopté à grande échelle pour la première fois au début des années 2000, il a révolutionné le développement de logiciels et les méthodes de travail traditionnelles. En conséquence, de nombreux éléments de base de l’approche Waterfall étaient considérés comme dépassés. L’un d’eux était le doc d’exigences du produit (PRD).
Le PRD était autrefois décrit comme le «doc le plus vital le chef de produit maintient » par les technologues Ben Horowitz et David Weiden, mais sa pertinence et sa valeur dans développement de produits a fait l’objet de vifs débats au cours des deux dernières décennies. Il y a des avocats passionnés, des specialists qui la croient caduque (voir cet article de weblog de 2006 du chief d’opinion produit Marty Cagan), et bien d’autres assis sur la clôture.
Ils ont tous des factors valables. Ma conviction, cependant, est que le problème n’est pas si d’utiliser un PRD, mais plutôt remark.
Organisations, produits et marchés tous créent un contexte distinctive pour lequel il n’y a pas de PRD distinctive, mais en mettant en œuvre ces conseils et conseils le cas échéant, et en utilisant le modèle gratuit fourni ci-dessous, vous pouvez faire revivre le PRD et en faire un élément précieux de votre numérique processus de développement de produit.
La valeur d’un bon doc d’exigences produit
Au cours de mes nombreuses années de travail en tant que chef de produit avec divers shoppers et équipes, j’ai trouvé que le PRD était un outil extrêmement utile, mais sa valeur dépend de la façon dont vous l’utilisez et de ce qu’il contient. Lorsqu’un PRD est conçu de manière réfléchie et utilisé avec soin, voici quelques-uns des avantages de haut niveau auxquels vous pouvez vous attendre :
Alignement interne : Un PRD est un wonderful outil pour parvenir à l’alignement de l’équipe, en particulier dans télécommande ou paramètres asynchrones. Il agit comme un doc d’orientation, garantissant que l’équipe comprend ce qu’elle construit, ce qu’elle ne construit pas, pourquoi elle le construit, quelles sont les priorités et remark le succès sera mesuré.
Alignement externe : Un PRD peut avoir les mêmes résultats pour d’autres events prenantes et shoppers, aidant les équipes à gérer la portée et les résultats de leur projet de manière transparente et à communiquer les changements de manière proactive.
Collaboration: Un PRD n’existe pas pour permettre l’autocratie du chef de produit ou de n’importe quel individu. C’est plutôt un outil de et pour collaboration proceed. C’est un endroit où les ingénieurs, les concepteurs et cooks de produits peuvent se réunir pour travailler sur la définition des person tales, par exemple, ou créer un dialogue continu avec les shoppers sur les objectifs et les priorités à mesure que les contextes évoluent et que de nouveaux apprentissages font floor.
Afin de créer un PRD appropriate Agile et de récolter ces avantages, vous et votre équipe devez éviter plusieurs pièges courants.
Remark éviter les pièges courants
Avant la domination d’Agile, le PRD était au cœur de développement de logiciels, capturant l’essence même du produit. En raison de ses origines pré-Agiles, un PRD traditionnel est plus adapté à un système Waterfall avec des étapes séquentielles clairement définies (c.-à-d. définition, conception, livraison). Mais un PRD peut et doit également être utilisé comme élément principal dans les paramètres Agile. Il suffit d’adapter le format et le contenu du PRD au contexte actuel. Voici mes bonnes pratiques :
1. Équilibrer rigidité et flexibilité
Il y a deux façons d’aborder la rigidité : la rigidité du PRD lui-même et la rigidité dans la façon dont il est perçu au sein de l’organisation. Les deux varieties se produisent généralement lors de la création et de l’utilisation d’un PRD, mais nous aborderons d’abord le premier.
Un doc rigide est fermé, ne laissant aucun espace à l’équipe pour rechercher ou mettre en œuvre d’autres options pendant le développement. Mais vous devez faire un effort conscient pour équilibrer la clarté du résultat souhaité d’un projet avec la flexibilité de faire des ajustements au fur et à mesure que vous apprenez de nouvelles informations. Le Méthode Form Updéveloppé par l’ancien chef de produit Basecamp Ryan Singer, peut être utilisé pour vous aider à trouver l’harmonie entre fournir la path fixe promise par un PRD fermé et donner aux équipes la possibilité de créer des produits de manière agile.
Une autre choice pour éviter la rigidité d’un PRD traditionnel est de l’utiliser pour décrire des critères de succès mesurables. Dans le cadre d’une utility de jeu, par exemple, l’objectif serait d’augmenter de 10 % le nombre d’utilisateurs partageant leurs scores sur les réseaux sociaux avec un écran de fin repensé et une expérience de partage plus fluide. Cette choice ne spécifie pas la meilleure answer pour y parvenir, permettant ainsi une analyse plus granulaire recherche et découverte.
2. Traitez-le comme un doc vivant
La façon dont le PRD est perçue au sein de l’organisation est primordiale pour sa valeur. Remark pouvez-vous espérer être un équipe agile lorsque vous travaillez à partir d’un doc fixe ? De même, remark pouvez-vous vous attendre à ce que le doc fonctionne pour vous si vous ne l’utilisez pas dans un agile chemin? Lorsqu’un PRD est utilisé de manière rigide, en étant strictement respecté ou appliqué, il peut entraver les discussions créatives et la découverte de produits, encourager un état d’esprit Waterfall et entraver l’agilité globale.
Suivre inconditionnellement un plan défini est une recette pour un désastre dans le développement de logiciels – considérer votre PRD comme « terminé » est une approche courante mais contre-productive, automotive le doc deviendra rapidement obsolète.
S’efforcer d’affiner en permanence le PRD et de le traiter comme un doc évolutif. Évitez d’avoir une chaîne d’examen ou d’approbation chaque fois qu’un membre de l’équipe effectue un ajustement. Plus vital encore, assurez-vous que votre équipe connaît bien un cadre tel que Mêlée, Kanbanou Programmation extrême, afin qu’ils soient capables de répondre aux commentaires, d’intégrer de nouveaux apprentissages et de réévaluer constamment. Si l’équipe travaille de manière agile, elle est également plus inclined d’utiliser le PRD de manière agile.
3. Gardez les descriptions brèves
Un autre écueil courant consiste à bourrer le PRD avec trop de détails, ce qui donne un doc volumineux et verbeux difficile à comprendre et à maintenir. Cela se produit généralement lorsque des informations excessives sont incluses dans la description de la fonctionnalité (chaque élément de fonctionnalité, spécifications de conception exhaustives ou directions de mise en œuvre).
Cependant, être bref ne signifie pas sacrifier la clarté. Un PRD clair inclura toujours les fondamentaux : l’objectif de chaque fonctionnalité, les éléments essentiels et les directives de livraison. Voici des exemples de différentes descriptions de fonctionnalités pour une utility de rencontres :
|
PAS CLAIR |
BREF ET CLAIR |
VERBEUX |
|---|---|---|
|
Écran de réussite lorsqu’il y a une correspondance entre deux utilisateurs, avec un moyen de se connecter. |
Nous avons besoin d’un écran de réussite pour chaque match qui excitera l’utilisateur et le poussera vers l’étape suivante (c’est-à-dire l’échange de messages). Le type doit correspondre aux normes de la marque et de l’accessibilité. Éléments indispensables :
De plus, nous aimerions voir la personnalisation, par exemple, des images de profil et/ou des surnoms. Le cas échéant, un retour haptique ou des vibrations, des animations, and so forth., doivent également être utilisés. |
Lorsqu’il y a une correspondance, une web page doit apparaître en plein écran qui affichera le message « C’est une correspondance ! » L’écran doit inclure des photographs de profil des deux utilisateurs, dans de grands cercles occupant chacun un quart de l’écran (avec la propre picture de l’utilisateur sur le côté gauche), et le message doit être au-dessus de ces photographs. Sous les photographs, il devrait y avoir deux gros boutons, bout à bout, l’un avec le texte « Message maintenant » et l’autre avec « Continuer à balayer ». Sur les boutons à gauche du texte, il devrait également y avoir des icônes : une bulle de chat pour envoyer un message au match et un petit cœur pour continuer à balayer. Tout le texte doit être en couleur #003366, à l’exception des boutons, qui doivent avoir du texte blanc. L’écran devrait apparaître avec un effet de survol depuis le bas, avec de petits feux d’artifice, des visages souriants et des émojis de cœur volant (sept feux d’artifice, trois visages souriants et quatre cœurs). |
Même dans l’exemple « bref et clair », il y a des informations potentiellement superflues : par exemple, les conseils sur normes de marque et d’accessibilité, ainsi que sur le retour haptique, peuvent ne pas être nécessaires si cela s’applique à chaque fonctionnalité et en particulier lorsque les organisations ont des équipes de conception qui connaissent ces normes. Si tel est le cas, vous pouvez encore resserrer la description de la fonctionnalité.
Plutôt que de décrire en détail ce qui est inclus, il peut être plus efficace dans certains cas d’utiliser une liste « ne fera pas », peut-être dans une part hors champ ou en utilisant le Méthode MoSCoW. La liste ne doit traiter que des éléments uniques au contexte ou lorsqu’il peut y avoir une incertitude, tels que les éléments retirés du champ d’utility qui seraient généralement inclus, les éléments non conformes à la réglementation ou les cas extrêmes.
Un facteur vital dans le niveau de détail que vous choisissez d’inclure sera également l’expérience de l’équipe et la maturité du produit. Si votre équipe comprend des professionnels expérimentés qui ont déjà travaillé ensemble, ou si vous construisez un produit qui a établi des normes et des directives, une brève documentation suffira.
La célèbre quotation « Je n’ai pas eu le temps de t’écrire une courte lettre, alors je t’en ai écrit une longue » s’applique ici. Il faudra beaucoup d’efforts pour garder le PRD bref tout en communiquant toutes les informations nécessaires, mais c’est un investissement qui en vaut la peine.
Utilisez ce modèle de doc d’exigences de produit pour maximiser le succès
Pour vous aider à démarrer, j’ai canalisé tous mes apprentissages et mes conseils dans le modèle gratuit ultime de PRD, disponible pour le téléchargement. Si, dans sa forme actuelle, il ne convient pas à votre contexte distinctive, expérimentez en supprimant ou en incorporant différents éléments pour le faire fonctionner pour vous.
Un PRD appropriate Agile est un outil extrêmement précieux. En le gardant bref, versatile et vivant, votre PRD peut favoriser un alignement, une clarté et une collaboration accrus, qui sont tous essentiels à la création de produits innovants et utiles.
Notes sur le modèle PRD
Le modèle est divisé en deux events : éléments obligatoires et facultatifs. Utiliser uniquement le premier se traduira par un doc allégé, suffisant pour obtenir les principaux avantages. Il est recommandé d’inclure certains des éléments facultatifs pour donner des détails supplémentaires si nécessaire. Voici remark utiliser efficacement le modèle :
1. Objet du doc
Cette part est essentielle pour définir à quoi servira le PRD. Rédigez une courte déclaration ou peut-être trois ou quatre puces décrivant son objectif. Par exemple:
- Découverte de paperwork et collaboration avec le consumer
- Décrire la portée du MVP
- Résumer les différentes applied sciences et possibilités de développement
- Détailler les besoins de l’équipe au fur et à mesure qu’ils surviennent
2. Résumé exécutif
Donnez un aperçu de haut niveau du projet, de ses buts et objectifs, du contexte organisationnel et du marché et des recommandations.
Conseil de professional : remplissez cette part en dernier, une fois que vous avez mis en place les autres éléments.
3. Qui, pourquoi, quoi et quoi non
Pour qui construisons-nous ce produit ? Répertoriez les principaux groupes d’utilisateurs du produit, leurs besoins et leurs factors faibles.
Pourquoi construisons-nous ce produit ? Énumérez les principales opportunités, hypothèses et raisonnements.
Que construisons-nous ? Rédigez une brève description du produit, sa portée approximative ou ses principales caractéristiques/composants.
Que ne construisons-nous pas ? Rédigez une brève description des fonctionnalités qui ne seront pas incluses et les raisons pour lesquelles.
