Obtenir un consensus sur le problème à résoudre
Une façon simple d'obtenir un consensus sur la définition du problème consiste à le mettre par écrit pour voir si tout
le monde est d'accord.
Demandez au groupe : Quel est le problème ?
-
Très souvent, on s'attelle immédiatement à la recherche d'une solution, sans avoir d'abord pris le temps de bien
comprendre le problème. Mettez le problème par écrit et voyez si tout le monde est d'accord avec votre définition.
Ensuite, redemandez au groupe : Quel est le problème réel ?
-
Recherchez les causes, ou le problème à l'origine du problème. Le vrai problème se cache souvent derrière un
problème de façade.
N'acceptez pas la première formulation du problème. Continuez à demander "pourquoi ?". Examinez la nature du problème.
Parfois, le groupe est tellement convaincu de la solution à mettre en place qu'il est difficile de mettre en évidence
le problème sous-jacent. Dans ce cas, il peut être intéressant de répertorier les avantages de la solution envisagée,
puis de chercher à identifier les problèmes résolus par ces avantages. Vous pourrez alors déterminer si ces problèmes
sont de réels problèmes auxquels l'organisation est confrontée. Parmi les techniques couramment utilisées pour
identifier le problème derrière le problème, nous citerons le brainstorming, les diagrammes
causes-effets et les diagrammes de
Pareto.
|
Identifier les parties prenantes
Selon le niveau de compétence de l'équipe de développement, l'identification des parties prenantes peut être une étape
simple ou complexe. Souvent, il suffit d'interroger les décisionnaires, les utilisateurs potentiels et autres parties
concernées. Les questions suivantes vous seront utiles :
-
Qui sont les utilisateurs du système ?
-
Qui est l'acheteur du système ?
-
Qui d'autre sera affecté par les résultats obtenus via le système ?
-
Qui sera chargé d'évaluer et de valider le système lorsqu'il sera livré et déployé ?
-
Existe-t-il d'autres utilisateurs internes et externes dont les besoins doivent être pris en compte ?
-
Qui va gérer le nouveau système ?
-
Avons-nous oublié quelqu'un ?
-
OK, avons-nous oublié quelqu'un d'autre ?
Commencez à définir les profils des utilisateurs potentiels (ou réels) du système. Les premières informations sur
les principaux utilisateurs et leur environnement doivent être incluses dans le document Vision.
|
Définir les limites du système
Les limites du système définissent la frontière entre la solution et le monde réel autour de cette solution. En
d'autres termes, les limites du système définissent une enveloppe dans laquelle se trouve la solution. Sous forme
d'entrées et de sorties, des informations sont échangées entre le système et les utilisateurs qui se trouvent en dehors
du système. Toutes les interactions avec le système ont lieu via des interfaces entre le système et le monde extérieur.
Souvent, les limites du système sont évidentes. Par exemple, les limites d'un gestionnaire de contacts shrink-wrap
mono-utilisateur qui s'exécute sous Microsoft Windows sont relativement claires. Il n'y a qu'un seul utilisateur et une
seule plate-forme. Les interfaces entre l'utilisateur et l'application se résument aux boîtes de dialogue via
lesquelles l'utilisateur peut entrer des informations dans le système, et aux rapports de sortie et chemins de
communication utilisés par le système pour documenter et transmettre ses réponses.
|
Identifier les contraintes à imposer au système
Il existe un certain nombre de contraintes à prendre en compte. Vous trouverez ci-dessous une liste des sources de
contraintes potentielles et des questions à poser :
-
Politique : Existe-t-il des problèmes politiques internes ou externes susceptibles d'affecter les solutions
potentielles ? Entre départements ?
-
Economie : Quelles sont les contraintes financières ou budgétaires applicables ? Existe-t-il des considérations
relatives au coût des marchandises vendues ou à la tarification des produits ? Certains problèmes de licence
doivent-ils être pris en compte ?
-
Environnement : Existe-t-il des contraintes environnementales ou réglementaires ? Légales ? D'autres standards qui
nous limitent ?
-
Technique : Sommes-nous limités dans nos choix technologiques ? Sommes-nous contraints de travailler avec les
plates-formes et technologies existantes ? Existe-t-il des technologies nouvelles qu'il nous est impossible
d'envisager ?
-
Faisabilité : Le planning est-il défini ? Sommes-nous limités aux ressources existantes ? Pouvons-nous utiliser de
la main d'oeuvre extérieure ? Pouvons-nous accroître les ressources ? Temporairement ? De façon définitive ?
-
Système : La solution doit-elle être mise en oeuvre sur nos systèmes existants ? Devons-nous assurer la
compatibilité avec les solutions existantes ? Quels sont les systèmes d'exploitation et environnements à prendre en
charge ?
|
Formuler le problème
Avec l'ensemble du groupe, travaillez sur un chevalet et décrivez chaque problème identifié à l'aide du canevas suivant
:
Le problème de <décrire le problème>
affecte <parties prenantes affectées par le problème>.
Les conséquences de ce problème sont : <répercussions du problème>.
Une solution adaptée permettrait de <répertorier les principales caractéristiques d'une solution adaptée>.
Ce canevas a pour but de vous aider à distinguer les solutions/réponses des problèmes/questions.
Exemple :
Le problème de : résolution insatisfaisante et tardive des problèmes de service après-vente
affecte : nos clients, notre personnel du service après-vente et nos techniciens de maintenance.
Les conséquences de ce problème sont : clients mécontents, niveau de qualité insuffisant, employés insatisfaits
et perte de chiffre d'affaires.
Une solution adaptée permettrait de : fournir un accès en temps réel à une base de données de dépannage pour le
personnel de support et de faciliter l'affectation immédiate de techniciens de maintenance sur les sites nécessitant
réellement leur intervention.
|
Définir les caractéristiques du système
A partir de la liste d'avantages établie, définissez une liste des caractéristiques souhaitées pour le système.
Décrivez-les brièvement et affectez-leur des attributs afin de définir leur état général et leur niveau de priorité au
sein du projet.
|
Evaluer vos résultats
Vous devez évaluer votre vision à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile
de faire un contrôle détaillé. Consultez la liste de contrôle du document Vision (Liste de contrôle :
Vision).
|
|