« Document sur les Exigences du Marché (MRD) » : différence entre les versions

De Wiki Agile
Aller à la navigation Aller à la recherche
m Fabrice Aimetti a déplacé la page Document sur les Exigences du Marché vers Document sur les Exigences du Marché (MRD) sans laisser de redirection
 
(2 versions intermédiaires par le même utilisateur non affichées)
Ligne 4 : Ligne 4 :
----
----
Traducteur : Fabrice Aimetti<br />
Traducteur : Fabrice Aimetti<br />
Date : 12/12/2022<br />
Date : 12/10/2022<br />
----
----
Traduction :<br />
Traduction :<br />
Ligne 24 : Ligne 24 :
<br/>
<br/>
Le qualificatif "non techniques" est crucial, car la plupart des logiciels de préparation de données nécessitent des compétences en codage ou une connaissance du fonctionnement du backend technique des bases de données. Vous avez identifié un marché - les analystes métiers qui n'ont pas de connaissances techniques - qui bénéficierait d'une application conviviale permettant à ces analystes de rassembler des données en faisant simplement glisser et déposer des champs ou même des bases de données entières provenant de différentes sources.
Le qualificatif "non techniques" est crucial, car la plupart des logiciels de préparation de données nécessitent des compétences en codage ou une connaissance du fonctionnement du backend technique des bases de données. Vous avez identifié un marché - les analystes métiers qui n'ont pas de connaissances techniques - qui bénéficierait d'une application conviviale permettant à ces analystes de rassembler des données en faisant simplement glisser et déposer des champs ou même des bases de données entières provenant de différentes sources.
==5 questions à poser lors de l'élaboration de votre MRD==
==Cinq questions à poser lors de l'élaboration de votre MRD==
===Quel est le marché que nous ciblons, et pourquoi croyons-nous qu'il vaut la peine d'être développé ?===
===Quel est le marché que nous ciblons, et pourquoi croyons-nous qu'il vaut la peine d'être développé ?===
Vous pourriez déterminer que le marché pour ce produit concernera plusieurs industries qui, historiquement, n'ont pas acheté d'outils de préparation des données et qui ont donc besoin d'une solution très simple et conviviale pour les analystes métiers.
Vous pourriez déterminer que le marché pour ce produit concernera plusieurs industries qui, historiquement, n'ont pas acheté d'outils de préparation des données et qui ont donc besoin d'une solution très simple et conviviale pour les analystes métiers.

Dernière version du 17 octobre 2022 à 15:24

Auteur : ProductPlan
Source : Market Requirements Document (MRD)


Traducteur : Fabrice Aimetti
Date : 12/10/2022


Traduction :

Qu'est-ce qu'un document sur les exigences du marché (Market Requirements Document ~ MRD) ?

Un document sur les exigences du marché est un document stratégique rédigé par un product manager ou un product marketing manager pour aider à définir les besoins ou la demande du marché pour un produit spécifique. Un MRD contient généralement des informations sur la vision du produit, le paysage concurrentiel, l'analyse commerciale et les opportunités de revenus, ainsi qu'une liste de caractéristiques ou tout au moins des catégories de caractéristiques de haut niveau.

Que contient un document sur les exigences du marché (MRD) ?

Un document sur les exigences du marché doit répondre à plusieurs questions stratégiques qui aident l'entreprise à identifier un besoin potentiel du marché. Les questions clés à poser sont les suivantes :

  • Quel est le marché que nous ciblons, et pourquoi croyons-nous qu'il vaut la peine d'être poursuivi ?
  • Quel est le revenu potentiel de ce marché ?
  • Qui sont les personas d'acheteurs et les personas d'utilisateurs de ce marché ?
  • Quels sont les problèmes que nous pouvons résoudre pour ces personas ?
  • Comment allons-nous résoudre ces problèmes ?

Exemple : Les informations que devrait contenir un MRD

Disons que vous êtes le product manager d'une société de logiciels qui fabrique des outils d'analyse de données. Vous envisagez de créer un nouvel outil de préparation des données. Il s'agirait d'une application qui aiderait les analystes et les chercheurs non techniques à rassembler des données provenant de plusieurs sources différentes pour créer des rapports utiles.

Le qualificatif "non techniques" est crucial, car la plupart des logiciels de préparation de données nécessitent des compétences en codage ou une connaissance du fonctionnement du backend technique des bases de données. Vous avez identifié un marché - les analystes métiers qui n'ont pas de connaissances techniques - qui bénéficierait d'une application conviviale permettant à ces analystes de rassembler des données en faisant simplement glisser et déposer des champs ou même des bases de données entières provenant de différentes sources.

Cinq questions à poser lors de l'élaboration de votre MRD

Quel est le marché que nous ciblons, et pourquoi croyons-nous qu'il vaut la peine d'être développé ?

Vous pourriez déterminer que le marché pour ce produit concernera plusieurs industries qui, historiquement, n'ont pas acheté d'outils de préparation des données et qui ont donc besoin d'une solution très simple et conviviale pour les analystes métiers.

Quel est le revenu potentiel pouvant être généré par ce marché ?

Le chiffre d'affaires auquel vous arrivez peut prendre plusieurs formes. Par exemple, vous pouvez estimer le marché total adressable (total addressable market ~ TAM), puis estimer le pourcentage de part de marché que votre produit pourrait gagner sur ce TAM. Vous pouvez également estimer le nombre d'utilisateurs ou de licences que votre entreprise sera en mesure de vendre au fil du temps, puis multiplier ce nombre par le tarif mensuel que vous prévoyez de pratiquer. Vous obtiendrez ainsi une estimation du revenu mensuel récurrent (monthly recurring revenue ~ MRR).

Quelles sont les personas d'acheteurs et les personas d'utilisateurs sur ce marché ?

Les utilisateurs seront des analystes métiers non techniques dans de grandes organisations. Les personas d'acheteurs seront les responsables commerciaux de ces grandes entreprises qui ont besoin de rapports sur les données de leurs équipes et les responsables informatiques qui achètent généralement des solutions logicielles pour leur entreprise.

Quels sont les problèmes auxquels ces personas sont confrontées et que nous pouvons résoudre ?

Disons que vous constatez que ces personas d'utilisateurs ont des difficultés à rassembler des données provenant de diverses bases de données et applications. Leurs entreprises n'ont pas acheté d'applications spécifiques pour cette fonction auparavant, de sorte que ces analystes ont trouvé des moyens de compiler et d'étudier les données manuellement. Il est donc difficile et long pour leurs entreprises d'accéder à la veille stratégique dont elles ont besoin pour prendre des décisions éclairées.

Comment allons-nous résoudre ces problèmes ?

Pour répondre à cette question, vous allez rédiger une brève description des caractéristiques ou des récapitulatifs des types de fonctionnalités dont votre produit aura besoin. Pour un nouvel outil de préparation des données, cette liste pourrait inclure les éléments suivants :

  • Connexion aux données : Connexion aux bases de données de différentes sources
  • Fusionnement des données : Normalisation des données de différentes sources pour en faciliter l'analyse.
  • Génération de rapports : Produisez des rapports visuels et intuitifs en quelques clics.

Remarque : le MRD est un document stratégique à un stade préliminaire. Il doit rester de haut niveau et la partie "Comment nous résolvons le problème" ne doit comprendre que de courtes descriptions stratégiques des fonctionnalités que vous proposez. Les discussions détaillées sur chaque feature et les user stories qui les accompagnent ne doivent venir que plus tard, une fois que votre équipe a décidé de développer le produit.

Les équipes produits agiles utilisent-elles des MRDs ?

La réponse courte est oui : de nombreuses équipes agiles rédigent des MRDs.

Les documents sur les exigences du marché ont été utilisés pendant des décennies dans les entreprises qui construisaient des produits en utilisant ce que nous appelons aujourd'hui la méthode waterfall. En utilisant cette approche séquentielle, une organisation établit un planning exhaustif pour construire le produit avant de commencer à travailler. Une fois qu'elle a commencé, l'équipe ne revient pas en arrière, et elle n'ajuste pas ses planifications quel que soit les premiers retours des utilisateurs.

Dans cet environnement waterfall, les MRDs sont des documents précieux car ils permettent de définir le plan à long terme pour le développement du produit. Dans les organisations en waterfall, les équipes rédigent souvent des MRDs très détaillés qui peuvent compter des dizaines de pages.

D'autre part, dans une entreprise agile, un MRD est également un outil utile. Il aide l'équipe produit à identifier une opportunité de marché et à la transmettre au reste de l'organisation. La principale différence est que dans une organisation agile, le MRD est très court et de haut niveau. C'est parce que l'équipe utilise le MRD uniquement comme un guide stratégique initial. Une entreprise agile se laisse la possibilité de changer de cap souvent en fonction de la façon dont le marché réagit au produit.

Quelle est la place d'un MRD dans le processus de product management ?

Pour les organisations agiles qui rédigent des MRDs, voici une séquence type des principaux documents que l'équipe va élaborer. Chacun d'entre eux aide à guider la rédaction du suivant.

Document sur les exigences du marché (market requirements document ~ MRD)

Ce document identifie une opportunité de marché potentielle : le qui, le quoi et le pourquoi du marché, et une explication de haut niveau de la façon dont la solution proposée aidera ce marché.

Document sur les exigences du produit (product requirements document ~ PRD)

Ce document communique les capacités/fonctionnalités dont le produit aura besoin.

Feuille de route du produit

Il s'agit d'un plan stratégique de haut niveau qui communique le plan stratégique et les objectifs du produit.

Backlog de produit

Il s'agit de la liste priorisée des tâches suffisamment détaillées et nécessaires à l'exécution du plan stratégique décrit dans la feuille de route du produit.

Backlog du sprint

Tiré du backlog du produit, il s'agit de la liste des éléments sur lesquels l'équipe pluridisciplinaire prévoit de travailler au cours du prochain sprint.