Un utilisateur est incapable de définir ses besoins métiers… Vrai ou Faux !
De nombreux projets et produits de directions des systèmes d’information ou de services informatiques échouent. Une des causes de ce phénomène est de sous-estimer la formalisation des besoins métiers avec les utilisateurs. C’est d’ailleurs principalement un problème méthodologique qui mène à penser que les utilisateurs n’en sont pas capables. La conclusion incontournable qui jette les chances de réussite d’un projet aux oubliettes est la fameuse citation d’Henry Ford, très utilisée par Steve Jobs : « Si j’avais demandé à mes clients ce qu’ils attendaient, ils auraient répondu « un cheval plus rapide » et non des voitures. D’ailleurs, cette citation montre très bien le problème méthodologique : on demande une solution à ses clients et non d’exprimer leurs problèmes, leurs besoins. En posant les bonnes questions, on doit finr par avoir : « se déplacer rapidement » et la voiture ou un cheval sous stéroïdes sont des solutions possibles que les ingénieurs ou les biologistes peuvent proposer.
Heureusement les problèmes méthodologiques ont toujours des solutions !
Je vous déconseille donc de faire comme Steve Jobs sauf si vous avez ses capacités. En effet les utilisateurs connaissent leur métier, ont des attentes, il faut donc les aider à formaliser et à exprimer leurs besoins métiers. Au placard le col roulé noir, mettez vos chaussures et allez comprendre le métier de vos utilisateurs !
Quand et pourquoi définir les besoins métiers ?
En général, le cadrage d’avant projet se compose de plusieurs étapes :
- L’identification ou l’émergence d’un besoin par un chef de projet et par les décideurs
- La réalisation d’une courte analyse du besoin, des bénéfices, des coûts et une esquisse d’une potentielle solution technique
- La définition des besoins métiers avec les utilisateurs, indépendamment des technologies. Lors de cette étape le chef de projet en profite pour comprendre le processus métier de l’utilisateur
- Le croisement des besoins métiers avec la connaissance technologique des experts/architectes SI et du chef de projet. Cette étape mène à une étude de couverture fonctionnelle de plusieurs solutions et à l’identification d’une sélection de solutions pouvant répondre aux besoins
- Cette sélection de solutions est ensuite analysée, testée par le chef de projet. La ou les solutions les plus simples et les moins coûteuses seront alors présentées et testées avec l’utilisateur pour valider ou non la sélection.
- Un dossier de cadrage est constitué par le chef de projet. Il inclut la définition du périmètre, des livrables, de la solution technique, du budget, des ressources, de l’exploitation…
- Le dossier est présenté aux décideurs qui lancent ou non le projet
La définition des besoins métiers est donc primordiale dans le lancement d’un projet. Les besoins métiers sont votre guide, vos « cases à cocher » dans l’identification des solutions, et le test de ces solutions lors de la recette. Si le métier de l’utilisateur n’est pas compris ou ses attentes ne sont pas ou mal perçues, le projet a donc de grandes chances d’échouer car il produira des solutions à côté de la plaque !
Quel est le problème méthodologique de l’expression des besoins métiers ?
Comme vous avez pu le voir dans la partie précédente, à aucun moment le chef de projet ne doit demander à l’utilisateur quelle solution technologique peut répondre à son besoin ! Et pourtant, il y a encore beaucoup de chefs de projet qui font l’inverse ! Le marketing des éditeurs de logiciels, le conformisme (« on ne m’en voudra jamais d’avoir échoué en ayant choisi le leader du marché ») et les discussions avec les pairs poussent à cela.
Ils vont voir les utilisateurs, leur demandent ce dont ils ont besoins. En général les utilisateurs :
- répondent « je ne sais pas »
- citent une solution à la mode et très cher
- demandent une nouvelle fonctionnalité sur le système existant
- décrivent leur activité, comme ils la vivent avec le logiciel existant. Ce qui est déjà pas mal car cela permet de comprendre leur processus mais est un énorme frein pour trouver « LA SOLUTION » la plus adaptée à leur besoin métier
Le chef de projet formalise donc ces informations et il finit par se dire que les utilisateurs métiers sont incapables d’exprimer leurs besoins métiers… Mais le chef de projet se trompe fondamentalement ! Il a demandé des besoins et est reparti avec des solutions ou des fonctionnalités. Il n’a pas posé les bonnes questions aux utilisateurs
De nombreux chefs de projet omettent de demander les besoins métiers indépendamment des technologies aux utilisateurs
Et oui ! Les utilisateurs ne sont pas des experts technologiques et rarement technophiles. Ce ne sont pas eux qui vont dire quelles solutions vont répondre à leurs problèmes. Ce sont aux architectes SI et aux chefs de projet d’identifier les solutions indépendants des technologies.
Et seulement une fois que des solutions auront été testées par le chef de projet, ce dernier pourra décider de présenter les solutions aux utilisateurs pour avoir leurs ressentis et voir si cela semble répondre à leurs besoins avant le lancement du projet.
Une fois que l’avant projet est validé, le projet pourra débuter. Une des étapes importantes d’un projet est de lancer un ou plusieurs POC. L’objectif d’un POC est de valider officiellement qu’une solution est la bonne pour répondre aux problèmes des utilisateurs. Si vous voulez en savoir plus sur le POC
