Gestion de projet : recueillir le besoin

Rédiger un cahier des charges fonctionnel, c’est exprimer et formaliser le besoin. Et cela est beaucoup moins simple que l’on pourrait le croire. Vous allez découvrir quelles sont les techniques de base pour recueillir le besoin et définir le périmètre du projet.

Extrait de la vidéo de formation : MOOC Gestion de Projet Perfectionnement

Recueillir le besoin : une tâche délicate

Pourquoi recueillir le besoin s’avère-t-il être une tâche délicate ? Il y a des besoins qui paraissent si évidents qu’ils sont annoncés tout de suite : ce sont des exigences incontournables. Avec ces premières exigences, le défi c’est d’être capable de bien les analyser. Mais elles sont tellement évidentes, manifestes qu’on ne risque pas de les oublier.

Et puis il y les parties du cahier des charges que l’on oublie :

• soit parce ce sont des situations rares (par exemple des cas de fonctionnement exceptionnel, pour un logiciel le redémarrage après une coupure de courant) 
• soit parce qu’on ne travaille pas avec la bonne personne. Par exemple pour développer un véhicule de tourisme c’est important d’interroger les futurs conducteurs de cette voiture pour connaître leurs attentes. Mais oublier le mécanicien qui doit ouvrir le capot pour l’entretenir, là c’est une très grave erreur.

Alors comment faire ? Je vais vous présenter les étapes essentielles avec leurs outils.

• premièrement, il faut définir le périmètre du projet
• deuxièmement, suivre le cycle de vie et identifier les cas d’utilisation
• troisièmement : lister les fonctions attendues et les caractériser

1ère étape : Définir le périmètre du projet 

Premièrement, il faut définir le périmètre du projet : souvent on se focalise sur un livrable, typiquement la composante matérielle attendue par exemple, un nouveau site internet. Mais on oublie qu’il y a d’autres livrables tout aussi importants, comme celui d’impliquer et de former les utilisateurs. Une formation peut donc être considérée comme un livrable.

Donc il est important de clarifier ce qui est dans le projet et ce qui est assuré par d’autres acteurs. Attention, même quand une partie du livrable est déléguée à un autre acteur, cela ne veut pas dire que l’on doit l’ignorer. Par exemple si on développe un logiciel en confiant la formation des utilisateurs à un prestataire, peut-être que l’on ne doit pas prévoir la formation, mais il faut tout de même s’assurer de travailler avec le prestataire pour qu’il puisse lui-même mettre au point la formation et s’assurer de son bon déroulement.

2ème étape : identifier les cas d’utilisation

Deuxièmement, on doit réaliser l’inventaire de toutes les phases du cycle de vie de chaque livrable. Pour cela comment faire ? C’est simple on “se met à la place” du livrable. Imaginons par exemple si vous concevez un stylo. Pour trouver son cycle de vie, il faut imaginer que vous êtes un stylo. 

L’équivalent du cycle de vie pour un logiciel c’est le cas d’utilisation ou “use case”. Par exemple l’inscription à une newsletter sur un site web. Dans ce cas, on a une séquence d’événements.

• le client tape une recherche dans Google
• il ouvre le site web sur son navigateur 
• il trouve la proposition “abonnez-vous pour recevoir des réductions”
• il s’identifie en rentrant son mail

3ème étape : lister les fonctions attendues

Troisièmement, à partir de ces informations, on fait la liste des fonctions attendues

Une bonne manière de procéder pour mettre en situation un cycle de vie est de dessiner en groupe un diagramme comme celui ci :

• d’abord on précise le nom du livrable et la situation étudiée, par exemple un stylo lorsqu’il est utilisé en classe
• ensuite on place autour les éléments de l’environnement. Ici on pense de suite à la main de l’écolier et au papier, mais dans cette situation, on peut aussi remarquer que le stylo est souvent posé sur la table. Et en observant bien une des personnes du groupe de travail pourra ajouter que les écoliers mordillent souvent leur stylo et donc que la bouche de l’écolier est un élément de l’environnement
• finalement, le groupe fait la liste des interactions entre le système et les éléments de son environnement. La main guide le stylo pour écrire c’est une fonction. Mais on en découvre d’autre : le stylo doit résister à la bouche ! 

Avec la liste de toutes les fonctions, il reste à les caractériser et évaluer leur importance :  

• caractériser la fonction : par exemple un stylo doit laisser une trace sur le papier, mais de quelle couleur ? De quelle épaisseur ? Pour quelle est la longueur d’écriture ?
• prioriser les fonctions les unes par rapport aux autres : qu’est ce qui est prioritaire? Qu’est-ce qui est souhaitable ? 
• on peut par exemple coter les fonctions entre 0 et 9 ou bien les comparer les unes aux autres

N’oubliez pas : quand on caractérise les fonctions, on ne doit pas décrire quelle est la solution technique choisie, mais uniquement exprimer le besoin, c’est à dire les résultats attendus. Par exemple, si on doit préciser que le stylo doit écrire 500 mètres, on ne doit pas imposer un stylo à bille ou un stylo à encre. De cette manière, l’équipe du projet sera libre de proposer des solutions innovantes comme la pyrogravure.

Pour approfondir

Voici quelques thèmes de réflexion pour approfondir :

• quelles différences entre besoins explicites et besoins implicites ? Comment révéler les besoins implicites ?
• décrivez le cycle de vie d’un produit “grand public”
• quelles méthodes de travail en groupe pour prioriser les fonctions les unes par rapport aux autres ?