Créer un Brief Produit avec Documents

Vous pouvez utiliser les Documents ClickUp pour communiquer les exigences du produit avec votre équipe d'ingénierie et les parties prenantes.

Lisez la suite pour savoir comment Sam a résolu un problème de communication majeur pour leur équipe Agile !

Réunion avec Sam

Sam est chef de produit pour une entreprise de logiciels basée sur le cloud. Ils travaillent sur une fonctionnalité spécifique de leur produit avec une équipe dédiée comprenant :

  • Un designer

  • Deux développeurs

  • Un ingénieur QA

Le défi

L'équipe s'entend bien, mais Sam remarque que lors des réunions quotidiennes de compte rendu, la majorité des questions sont adressées à Sam concernant la fonctionnalité et son fonctionnement.

Sam décide de donner des directives à l'équipe en dehors des résumés rapides en utilisant ClickUp Docs.

La solution

Sam décide que chaque fonctionnalité devrait avoir son propre Document. Lorsque l'équipe travaille sur une fonctionnalité, toutes les informations pertinentes doivent être rassemblées au même endroit.

L'utilisation de pages au sein d'un document permet à l'équipe de trouver rapidement les réponses pertinentes sans avoir à chercher et fouiller dans différents documents.

Sam crée quelques pages dans le document pour structurer le brief du produit en fonction de ce que l’équipe a besoin de savoir et de ce qu’elle pourrait rechercher.

  1. Charte de l'équipe de fonctionnalité

  2. Exigences de conception

  3. Exigences fonctionnelles

  4. Exigences UX

Conseil : Utilisez la fonction de recherche pour trouver des pages spécifiques ou du contenu dans un document !

page.png

Sam ajoute un titre et d’autres éléments de formatage à chaque page pour communiquer leur vision de la fonctionnalité.

Sam partage le document avec l'équipe des fonctionnalités. Ils collaborent pour rédiger et approuver la charte.

Sam invite l'équipe à poser des questions en ajoutant des commentaires sur le document afin que tout le monde puisse voir les questions et les réponses.

Rétrospective

Quelques Sprints passent rapidement, et l'équipe est reconnaissante pour le document qui les a guidés. Les réunions de type stand-up sont désormais bien plus efficaces et productives.

Une amélioration de fonctionnalité est expédiée et ajoutée au produit. Malheureusement, cela provoque un nouveau bug dans une autre partie de la fonctionnalité qui n'était pas mise à jour dans la version.

Les développeurs corrigent rapidement le bug et lors de leur prochaine rétrospective, l'équipe de fonctionnalités discute des moyens d'éviter cela à l'avenir.

Un ingénieur QA suggère certains critères d'acceptation afin qu'aucune modification ne soit envoyée en production à moins que tous les critères de test ne soient validés.

L'équipe est d'accord ! Sam ajoute une nouvelle page au cahier des charges pour documenter les critères d'acceptation de la fonctionnalité.

Sam utilise des blocs de code ( /co ) pour formater leurs critères d'acceptation, car l'équipe est déjà familiarisée avec Gherkin, et ClickUp le prend en charge pour les blocs de code !

gherkincodeblock.png

Le résultat

À mesure que l'équipe des fonctionnalités déploie plus d'améliorations et corrige des bugs, les clients adoptent de plus en plus la fonctionnalité. L'équipe en charge des fonctionnalités s'agrandit pour inclure deux développeurs supplémentaires et un autre ingénieur QA.

Les nouveaux membres de l'équipe s'adaptent rapidement et commencent à contribuer grâce au document de présentation des fonctionnalités de Sam !

Sam partage également le modèle de document de présentation de fonctionnalité avec d'autres chefs de produit afin qu'ils puissent l'adapter à leurs équipes basées sur des fonctionnalités.

C'est une grande victoire pour l'équipe de Sam, et pour d'autres aussi ! 

 

 

 

Cet article vous a-t-il été utile ?