Carnet de produit

Un carnet de produit est la liste unique et priorisée des travaux d’un service : les fonctionnalités, les correctifs et les améliorations qui restent à faire, ordonnés pour que le travail le plus utile vienne en premier. Les normes relatives au numérique du gouvernement du Canada le disent simplement : tenez un carnet de produit et servez-vous-en pour établir les priorités. Chaque élément se rattache à un besoin réel d’utilisateur, une seule personne en fixe l’ordre, et il n’est jamais terminé : il est affiné à mesure que le service apprend et change.

À quoi ressemble la réussite

  • Il y a un seul carnet de produit, une seule liste ordonnée des travaux à faire, et non les mêmes travaux éparpillés entre boîtes de réception et tableurs.

  • Une seule personne, le responsable de produit ou de service, répond de l’ordre.

  • Chaque élément se rattache à un besoin réel d’utilisateur, habituellement rédigé sous forme de courte histoire d’utilisateur.

  • Les priorités sont établies selon l’incidence sur les utilisateurs, la concordance avec les objectifs, et l’effort, et elles sont réexaminées régulièrement, non fixées une fois pour toutes.

  • Le carnet de produit contient plus que de nouvelles fonctionnalités : le travail de soutien et la dette technique se disputent les mêmes places.

  • Une définition claire de « terminé » détermine quand un élément est achevé, et le travail inachevé retourne sur la liste plutôt que d’aller au public.

  • Le carnet de produit est tenu à découvert, là où l’équipe et les utilisateurs peuvent voir et influencer ce qui est priorisé.

  • Il n’est jamais complet : il continue d’être affiné sur toute la vie du service.

À l’intérieur d’un carnet de produit

Un élément de carnet de produit prend habituellement cette forme, ici avec un service de demande de subvention comme exemple :

En tant qu’organisme qui demande du financement, je veux pouvoir enregistrer une demande partiellement remplie afin de pouvoir y revenir et la terminer plus tard.

C’est terminé quand :

  • le demandeur peut enregistrer une version provisoire et y revenir
  • le demandeur peut voir quelles sections sont encore incomplètes
  • une version provisoire enregistrée est stockée de façon sécuritaire et rattachée au compte du demandeur

La première ligne est l’histoire d’utilisateur (qui, quoi et pourquoi), et la liste « c’est terminé quand… » en constitue les critères d’acceptation, le test qui dit quand l’élément est achevé. Pour plus de détails sur la rédaction des éléments sous cette forme, le Guide de conception de services de l’Ontario et le guide de GOV.UK sur la rédaction d’histoires d’utilisateur emploient tous deux ce format.

Pourquoi cela compte

Sans une seule liste priorisée, les travaux sont menés par qui demande le plus fort, et les choses importantes mais peu spectaculaires — le correctif de sécurité, la lacune d’accessibilité, ce sur quoi les utilisateurs butent sans cesse — ne remontent jamais au sommet. Un bon carnet de produit est ce qui permet à un service de continuer de s’améliorer régulièrement après le lancement plutôt que de stagner, ce qui compte parce que les années d’exploitation sont la plus longue partie de sa vie. Les normes du gouvernement du Canada demandent aux équipes d’itérer et d’améliorer fréquemment et d’être transparentes sur ce qu’elles priorisent.

À qui revient ce travail

La tenue d’un carnet de produit est partagée au sein de l’équipe, chaque rôle en portant une partie différente :

  • Le responsable de produit ou de service tient la liste unique, l’ordonne et l’affine; c’est lui qui décide de ce qui vient ensuite.
  • L’équipe (concepteurs, développeurs, chercheurs) décompose les éléments, les estime, et les livre.
  • Le responsable opérationnel de l’application veille à ce qu’il y ait un responsable clair et à ce que les priorités servent les utilisateurs et les objectifs du service.

Un regard de plus près

Comparaison

Deux façons de tenir un carnet de produit

Pax

Voici Pax, gestionnaire de service. L’équipe menait le service de renouvellement de permis à partir d’un seul carnet de produit :

  • tenait une liste unique et ordonnée, chaque élément rattaché à un besoin d’utilisateur
  • priorisait selon l’incidence et l’effort, à l’aide de MoSCoW, et revoyait l’ordre chaque semaine
  • avait fixé une définition claire de « terminé », de sorte que le travail inachevé retournait sur la liste plutôt que de sortir

Le résultat : une amélioration régulière et visible, les correctifs importants ont été faits, et tout le monde, y compris les utilisateurs, pouvait voir ce qui s’en venait.

À quoi ressemble le carnet de produit à chaque phase

Le carnet de produit change de forme au fil de la vie d’un service.

Le carnet de produit commence à la découverte comme une liste priorisée d’histoires d’utilisateur tirées de la recherche sur les utilisateurs. Quand la construction commence, l’équipe traite d’abord les éléments du haut, et la première mise en production livre les besoins les plus essentiels plutôt que tout d’un coup. L’ordre est fixé selon l’incidence et l’effort, et on s’attend déjà à ce qu’il change.

Questions courantes

Pour aller plus loin

Pour un mode d’emploi général qui relie le tout, le Service Manual du Royaume-Uni sur la livraison agile est l’aperçu le plus simple. Pour voir comment une équipe du gouvernement du Canada décide de la suite, les orientations sur l’amélioration continue de design.canada.ca parcourent le choix de ce qu’il faut améliorer et la mesure de son effet. Pour rédiger les éléments eux-mêmes, le guide de Mike Cohn sur les histoires d’utilisateur donne le modèle, des exemples travaillés, et la façon de décomposer une épopée. Et pour comprendre pourquoi un carnet de produit devrait être mené comme un produit plutôt que comme un projet, « Product vs Feature Teams » de Marty Cagan explique pourquoi il faut confier au responsable des problèmes à résoudre plutôt qu’une liste fixe à livrer.

Voir aussi

Les hypothèses de cette page

Vous travaillez déjà selon les Normes relatives au numérique du gouvernement du Canada : concevoir avec les utilisateurs, itérer et améliorer fréquemment, travailler ouvertement, utiliser des normes et des solutions ouvertes, gérer les risques en matière de sécurité et de protection des renseignements personnels, intégrer l’accessibilité dès le début, permettre au personnel d’offrir de meilleurs services, être de bons gestionnaires de données, concevoir des services éthiques et collaborer largement, ainsi que selon la loi en matière de protection des renseignements personnels, de sécurité, de langues officielles et d’accessibilité. Les normes précisent comment le gouvernement travaille dans le monde numérique. Les six compétences numériques du gouvernement du Canada précisent ce que chaque fonctionnaire doit être capable de faire pour travailler ainsi, et la page sur l’équipe les présente. Le présent guide s’appuie sur elles.