Gestion de projet : recueillir le besoin

Rédi­ger un cahier des charges fonc­tion­nel, c’est expri­mer et forma­li­ser le besoin. Et cela est beau­coup moins simple que l’on pour­rait le croire. Vous allez décou­vrir quelles sont les tech­niques de base pour recueillir le besoin et défi­nir le péri­mètre du projet.

Extrait de la vidéo de forma­tion : MOOC Gestion de Projet Perfec­tion­ne­ment

Recueillir le besoin : une tâche déli­cate

Pourquoi recueillir le besoin s’avère-t-il être une tâche déli­cate ? Il y a des besoins qui paraissent si évidents qu’ils sont annon­cés tout de suite : ce sont des exigences incon­tour­nables. Avec ces premières exigences, le défi c’est d’être capable de bien les analy­ser. Mais elles sont telle­ment évidentes, mani­festes 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 situa­tions rares (par exemple des cas de fonc­tion­ne­ment excep­tion­nel, pour un logi­ciel le redé­mar­rage après une coupure de courant) 
• soit parce qu’on ne travaille pas avec la bonne personne. Par exemple pour déve­lop­per un véhi­cule de tourisme c’est impor­tant d’in­ter­ro­ger les futurs conduc­teurs de cette voiture pour connaître leurs attentes. Mais oublier le méca­ni­cien qui doit ouvrir le capot pour l’en­tre­te­nir, là c’est une très grave erreur.

Alors comment faire ? Je vais vous présen­ter les étapes essen­tielles avec leurs outils.

• premiè­re­ment, il faut défi­nir le péri­mètre du projet
• deuxiè­me­ment, suivre le cycle de vie et iden­ti­fier les cas d’uti­li­sa­tion
• troi­siè­me­ment : lister les fonc­tions atten­dues et les carac­té­ri­ser

1ère étape : Défi­nir le péri­mètre du projet 

Premiè­re­ment, il faut défi­nir le péri­mètre du projet : souvent on se foca­lise sur un livrable, typique­ment la compo­sante maté­rielle atten­due par exemple, un nouveau site inter­net. Mais on oublie qu’il y a d’autres livrables tout aussi impor­tants, comme celui d’im­pliquer et de former les utili­sa­teurs. Une forma­tion peut donc être consi­dé­rée comme un livrable.

Donc il est impor­tant de clari­fier ce qui est dans le projet et ce qui est assuré par d’autres acteurs. Atten­tion, 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’igno­rer. Par exemple si on déve­loppe un logi­ciel en confiant la forma­tion des utili­sa­teurs à un pres­ta­taire, peut-être que l’on ne doit pas prévoir la forma­tion, mais il faut tout de même s’as­su­rer de travailler avec le pres­ta­taire pour qu’il puisse lui-même mettre au point la forma­tion et s’as­su­rer de son bon dérou­le­ment.

2ème étape : iden­ti­fier les cas d’uti­li­sa­tion

Deuxiè­me­ment, on doit réali­ser l’in­ven­taire 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. Imagi­nons par exemple si vous conce­vez un stylo. Pour trou­ver son cycle de vie, il faut imagi­ner que vous êtes un stylo. 

L’équi­valent du cycle de vie pour un logi­ciel c’est le cas d’uti­li­sa­tion ou “use case”. Par exemple l’ins­crip­tion à une news­let­ter sur un site web. Dans ce cas, on a une séquence d’évé­ne­ments.

• le client tape une recherche dans Google
• il ouvre le site web sur son navi­ga­teur 
• il trouve la propo­si­tion “abon­nez-vous pour rece­voir des réduc­tions”
• il s’iden­ti­fie en rentrant son mail

3ème étape : lister les fonc­tions atten­dues

Troi­siè­me­ment, à partir de ces infor­ma­tions, on fait la liste des fonc­tions atten­dues

Une bonne manière de procé­der pour mettre en situa­tion un cycle de vie est de dessi­ner en groupe un diagramme comme celui ci :

• d’abord on précise le nom du livrable et la situa­tion étudiée, par exemple un stylo lorsqu’il est utilisé en classe
• ensuite on place autour les éléments de l’en­vi­ron­ne­ment. Ici on pense de suite à la main de l’éco­lier et au papier, mais dans cette situa­tion, on peut aussi remarquer que le stylo est souvent posé sur la table. Et en obser­vant bien une des personnes du groupe de travail pourra ajou­ter que les écoliers mordillent souvent leur stylo et donc que la bouche de l’éco­lier est un élément de l’en­vi­ron­ne­ment
• fina­le­ment, le groupe fait la liste des inter­ac­tions entre le système et les éléments de son envi­ron­ne­ment. La main guide le stylo pour écrire c’est une fonc­tion. Mais on en découvre d’autre : le stylo doit résis­ter à la bouche ! 

Avec la liste de toutes les fonc­tions, il reste à les carac­té­ri­ser et évaluer leur impor­tance :  

• carac­té­ri­ser la fonc­tion : par exemple un stylo doit lais­ser une trace sur le papier, mais de quelle couleur ? De quelle épais­seur ? Pour quelle est la longueur d’écri­ture ?
• prio­ri­ser les fonc­tions les unes par rapport aux autres : qu’est ce qui est prio­ri­taire? Qu’est-ce qui est souhai­table ? 
• on peut par exemple coter les fonc­tions entre 0 et 9 ou bien les compa­rer les unes aux autres

N’ou­bliez pas : quand on carac­té­rise les fonc­tions, on ne doit pas décrire quelle est la solu­tion tech­nique choi­sie, mais unique­ment expri­mer le besoin, c’est à dire les résul­tats atten­dus. Par exemple, si on doit préci­ser que le stylo doit écrire 500 mètres, on ne doit pas impo­ser un stylo à bille ou un stylo à encre. De cette manière, l’équipe du projet sera libre de propo­ser des solu­tions inno­vantes comme la pyro­gra­vure.

Pour appro­fon­dir

Voici quelques thèmes de réflexion pour appro­fon­dir :

• quelles diffé­rences entre besoins expli­cites et besoins impli­cites ? Comment révé­ler les besoins impli­cites ?
• décri­vez le cycle de vie d’un produit “grand public”
• quelles méthodes de travail en groupe pour prio­ri­ser les fonc­tions les unes par rapport aux autres ?