Valider les requirements: Que des avantages!

En Requirement Management, le bottleneck réside bien souvent dans la validation des requirements. En effet, bien que la collecte et la description des besoins nécessitent de la patience, la validation est un processus non moins important et potentiellement semé d'embuches.

Une bonne gestion des requirements implique d'identifier, décrire, évaluer et valider les besoins et leurs transpositions en projets ou produits. L'identification et la description des besoins du métier requiert patience, écoute et souplesse pour arriver à une parfaite compréhension mutuelle de l'analyste en charge et des gens du métier. 

L'évaluation d'un requirement se fait sur les critères suivants:

  • L'importance.
  • L'urgence.
  • L'impact.
  • Les moyens nécessaires à son implémentation.

L'évaluation permet de prioritiser les requirements et de les regrouper en lots (une fois leur implémentation décidée, on parle de package ou release), selon la terminologie "MoSCoW": "Must-have", "Should-have", "Could-have", "Won't-have".

La combinaison des cotes associées à chaque critère pour chaque requirement permet de fixer les scopes des différents packages et d'établir le planning d'implémentation de ceux-ci. 

La pleine validation des requirements offre plusieurs avantages:

  • S'assurer que toutes les parties prenantes partagent un même compréhension des besoins et requirements.
  • S'assurer de la continuité de l'implication de ces mêmes parties prenantes.
  • Fixer un cadre solide et stable pour les phases ultérieures du projet concerné, et notamment le planning initial de la suite du projet.
  • Pouvoir passer à la suite du projet l'esprit (à priori) tranquille.

Des avantages précieux pour une conduite efficace d'un projet!

 

L'analyste: un métier à plusieurs casquettes

Le métier d'analyste est une profession dont j'ai remarqué que beaucoup d'autres professionnels se posaient la question de sa finalité, voire de son utilité. En fait, le métier d'analyste est très important car il se situe à la frontière entre l'humain et "la machine".

D'une certaine manière, le métier d'analyste peut se définir comme ceci: Analyser, c'est:

  1. S’informer:
    • Lire
    • Questionner
    • Écouter
  2. Comprendre
  3. Synthétiser
  4. Communiquer

… sur un « produit » (au sens large).

L'analyse consiste à enquêter sur le "produit" selon divers points de vue:

  1. Comment le public visé par l'enquête travaille, éventuellement avec ou sans le produit?
  2. Que fait le public visé avec le produit?
  3. Comme est conçu le produit?

Chaque facette de l'enquête illustre le caractère multiforme du métier d'analyste: 

  • On parle d'analyse métier (business analysis) dans le cadre d'une enquête portant sur les méthodes de travail, ce qu'on appelle les processus métier.
  • On parle d'analyse fonctionnel dans le cadre d'une enquête sur les opérations effectuées et les résultats attendus dans l'utilisation d'un produit donné.
  • On parle d'analyse technique quand l'enquête porte sur la conception même du produit, plus précisément sa fabrication.

 

Ces 3 aspects sont complémentaires, indépendants mais ne peuvent s'ignorer mutuellement. 

Ces 3 aspects sont les casquettes principales du métier d'analyste.

Le Requirement Management, la base d'une bonne gestion

La gestion des requirements (demandes) est un aspect de la gestion continue qui prend de plus en plus de place dans les projets et maintenances informatique. Trop longtemps, le Requirement Management s'est limité à collecter des besoins pendant des périodes limitées et les décrires dans des documents d'analyse dite fonctionnelle. Nous allons voir ici que la gestion des requirements est bien plus vaste et importante que cela.

Contenu

  1. Qu'est-ce qu'un requirement?
  2. Définir un requirement
  3. Valider un requirement
  4. Gérer le changement
  5. Conclusion

Qu'est-ce qu'un requirement?

Un requirement est l'expression formelle d'un besoin.

Dans le cadre d'un projet, d'une gestion opérationnelle, il y a lieu d'identifier et d'analyser les besoins d'une organisation ou d'un ou plusieurs publics-cibles. Ces besoins sont collectés lors de réunions préparatoires du type atelier ou brainstorming. L'écoute du client, du public cible, est primordiale, tout comme la capacité de reformuler les besoins exprimés. Il est essentiel que l'analyste - qui identifie et décrit les requirements - et son interlocuteur se comprennent parfaitement et parlent le même langage.  

Prenons le cas d'une société qui souhaite renouveler son parc de voitures de sociétés destinées à ses cadres de vente. Nous pouvons identifier déjà deux publics-cibles dont les besoins ne seront pas toujours compatibles:

  • La société souhaite attirer et motiver les meilleurs commerciaux mais limiter les coûts d'acquisition et de gestion de ce parc de véhicules autant que possible.
  • Les cadres commerciaux, qui utiliseront leurs voitures de société au quotidien, auront des besoins en termes de confort, de performance, d'équipement, éventuellement d'ambiance à bord, etc.

Ces besoins sont exprimés de la manière suivante, comme par exemple: "Le prix d'achat d'un véhicule ne peut pas dépasser 50000 EUR".

Définition des requirements

Le besoin est exprimé sous la forme d'un requirement quand il prend une structure plus formelle. La définition du requirement doit comprendre:

  • L'initiateur du besoin, en général un groupe type de personnes, un rôle, voire un utilisateur clé.
  • L'expression du besoin sous la forme d'une phrase courte, claire, spécifique, comme par exemple: "La valeur d'acquisition d'un véhicule destiné à un cadre de vente ne pourra pas dépasser 50000 EUR HTVA, toutes options comprises".
  • Un identifiant de référence.
  • Un numéro de version.
  • La référence du projet ou d'une phase de maintenance.
  • L'état du requirement, par exemple: "Nouveau, Mise à jour, Validé, En exploitation, Obsolète, ...".
  • Son importance: est-il indispensable ou souhaitable, etc.
  • Son impact sur le projet, produit ou processus existant.

Toutes ces données peuvent être présentée sous la forme d'un petit tableau, style fiche d'identité. 

La définition d'un requirement obéit donc à certaines contraintes:

  • Son expression doit être aussi claire et concise que possible. Une phrase courte est le meilleur moyen.
  • Il doit pouvoir être confronté à sa réalisation, et son expression doit donc donner les éléments de mesure nécessaires en ce sens.
  • Son importance et son impact sont nécessaires à sa validation et sa planification.
  • Les références associées permettent d'en identifier le contexte, ici le renouvellement d'une flotte de véhicules de sociétés pour les cadres commerciaux.
  • L'état du requirement permet de suivre son cycle de vie.

L'ensemble des requirements pour un projet donné peut également se présenter sous la forme d'un tableau général, ce qui permet une vision d'ensemble et peut faciliter la gestion ultérieure de ces requirements.

Valider un requirement

Un requirement qui est validé est un requirement qui est pris en compte, avec une certaine priorité, dans le cycle de vie du produit auquel il se rapporte. Considérons la maintenance d'un programme développé en interne dans une entreprise. Ce programme demande régulièrement des mises à jour techniques, mais également des modifications concernant ses fonctionnalités, comme par exemple l'ajout d'une possibilité de partager un article ou un lien sur les réseaux sociaux les plus courants comme Facebook, Twitter, Viadeo, Google+, Tumbir, Vimeo, etc.

A ce stade, on peut considérer que cette possibilité d'ajout constitue un requirement validé, avec sa priorité. Cette priorité est établie en fonction de l'importance accordée à cette nouvelle fonctionnalité et de l'impact - en termes de coûts ou de changement des habitudes de travail notamment - que l'implémentation de cette nouvelle fonctionnalité aura sur l'utilisation du programme concerné.

Urgence * Impact = Priorité
  • Urgence: Evaluée par exemple sur une échelle de 1 à 5, 5 correspondant à l'urgence la plus élevée.
  • Impact: Evalué par exemple sur une échelle de 1 à 5, 5 correspondant à l'impact le plus faible.

Dans le cas d'une entreprise de vente via Internet, la priorité de ce requirement sera élevée si l'entreprise a décidé d'axer une grande partie de sa communication sur l'exploitation des réseaux sociaux. On pourra alors évaluer l'urgence à 4 ou 5, et son impact relativement faible car n'impactant que les clients en termes d'utilisation. 

On parle de méthode MoSCoW (Must-have / Should-have / Could-have / Won't-have) pour prioritiser grossièrement les requirements (cf. ce lien).

Une fois les requirements validés, ils constituent une liste de requirements classés par priorité. Cette prioritisation des requirements, basées sur des évaluations concrètes, permet de:

  • s'assurer que chaque requirement validé sera pris en compte, 
  • et que le délai d'implémentation sera conforme à l'urgence de la demande.

On parle parfois de "Product Backlog".

Gérer le changement

La liste des requirements évolue constamment. C'est normal, les besoins de l'organisation, ceux des utilisateurs, ceux des clients, évoluent. Cette évolution peut se traduire:

  • en nouveaux requirements (cf. l'exemple des réseaux sociaux ci-dessus), 
  • en requirements adaptés (par exemple, intégrer plus d'information sur un même écran de programme).

C'est le domaine du Change Management (Gestion du changement), lequel s'appuie, comme pour la collecte des besoins initiaux, sur une grande capacité d'écoute et de communication. Par l'organisation d'ateliers, de brainstorming, etc., la gestion du changement est un processus d'amélioration continue du produit. Le produit "colle" de mieux en mieux au client, à son utilisateur, à l'entreprise qui l'a mis en place, il fidélise et fédère toutes ces parties prenantes (stakeholders) autour de lui.

Conclusion

Le Requirement Management est au coeur de ce qu'on peut appeler la relation fournisseur-client au sens large du terme. Etre à l'écoute du client, de l'utilisateur, du partenaire, c'est s'assurer d'une parfaite compréhension mutuelle des besoins de chacun, afin d'aboutir à un produit (terme pris également au sens large) qui convienne à tous: le juste coût pour le résultat optimal. 

L'approfondissement de la relation fournisseur-client sur un plus long terme est tout le challenge du Change Management. Dans ce contexte, le Requirement Management prend également tout son sens puisqu'il est le foyer de la gestion du changement.