Article épinglé

Vous et votre liste des tâches — quand faire le point boucle la boucle

Pilier Programmation, article 7 - Fonction Evaluer / apprendre « J 'ai bien avancé aujourd'hui, je crois. » Le je crois di...

Résoudre des problèmes : des ressentis aux faits (et des mots au dessin)


Pilier Résolution de problèmes, article 3 - Un problème bien formulé est à moitié résolu

Nous avons posé la question du moment (article 1 :La résolution de problèmes est-elle une des méthodes de la gestion du temps ? ), puis démontré que vous savez déjà résoudre des problèmes — mais avec le mauvais regard (article 2 : Vous résolvez déjà des problèmes sans le savoir). Voici donc la méthodologie. Elle tient en cinq étapes, et la première d'entre elles est celle que tout le monde saute : poser le problème. Le sujet de cet article est ce premier acte de régulation.

Voyons comment transformer une plainte ou un malaise diffus en énoncé exploitable, avec un cas de terrain et trois dessins.

Où en sommes-nous ?

La démarche de résolution d'un problème d'organisation se déroule en cinq étapes. Chacune a son point de vigilance :

L'étape Le point de vigilance
1. Poser le problème
→ Transformer un ressenti en énoncé factuel et exploitable
La description est entachée de subjectivité : se mettre d'accord à plusieurs sur ce qu'on voit et comprend est déjà difficile. Tout seul, c'est encore plus compliqué.
2. Identifier les causes
→ Chercher ce qui produit l'écart, pas qui le provoque
Traiter toutes les causes disperse le capital de temps, d'énergie et d'attention (TEA) : chercher les causes maîtresses - 20 % des causes pèsent 80 % des effets (cf. loi de Pareto).
3. Imaginer des solutions
→ Ouvrir plusieurs hypothèses, pas une seule
On ne peut pas inventer ce qu'on ne connaît pas : aller chercher ailleurs : benchmarks, créativité, penser à côté (la pensée latérale).
4. Choisir
→ Expliciter les critères et arbitrer
Inutile de se disperser sur toutes les solutions imaginables : se concentrer sur celles qui produisent le plus de résultats (Pareto, encore).
5. Vérifier
→ S'assurer que la solution contribue à la résolution
La faiblesse habituelle de la démarche : l'insuffisance de la rétroaction et du suivi.

Ce troisième article traite de la première ligne, et elle n'est pas la moindre des étapes.

Le problème mal posé

Prenons un cas de terrain, authentique dans sa forme :

« Les projets que nous gérons sont constamment ralentis par un processus de validation hiérarchique trop lourd. Comment obtenir les Go/No-Go sans bloquer l'avancement ? »

Voilà un énoncé de problème. Il en a l'apparence : un sujet, une gêne, une question. Devant une telle plainte, les réactions fusent : râler contre l'administration, vouloir supprimer les contrôles, accuser un service. Chacun a son idée, chacun repart avec la sienne, et le sujet s'enlise.

Regardons-y de plus près. « Trop lourd » : un jugement. « Constamment ralentis » : un ressenti. Cet énoncé ne décrit pas un problème : il exprime une opinion sur un problème. Et il y a pire, un piège plus sournois : l'énoncé qui contient sa propre solution toute faite. « Le problème, c'est qu'on n'a pas le bon outil de validation numérique ». Voilà une formulation qui décrète d'avance la cause et le remède.

Traiter le sujet sous ces formes garantit une chose : apporter une fausse solution à un vrai symptôme.

Les filtres qui polluent le regard

Car face au réel, nous ne sommes jamais neutres. La description d'un problème est immédiatement biaisée par trois filtres :

Ce que l'on connaît
On cherche l'explication là où on a l'habitude de regarder — ou là où cela nous arrange. 
→ Le comptable voit une question de chiffres, l'informaticien une question d'outil, le manager une question de personnes.

Ce dont on a envie
Le biais de confirmation est sournois : on oriente la description pour valider une solution qu'on a déjà en tête.
→ Celui qui rêve d'un nouvel outil vous décrira un problème d'outil.

Les idées reçues du moment
« La hiérarchie est déconnectée », « les outils sont obsolètes ».
→ Les poncifs de l'époque font office d'explications toutes faites et masquent la réalité du terrain.

Aucun de ces filtres ne relève de la mauvaise foi. Ils relèvent de l'économie de pensée : juger est rapide, décrire est coûteux. C'est précisément pour cela qu'il faut une méthode, un tamis qui filtre les jugements et ne conserve que des faits mesurables ou observables.

D'abord, l'analyse fonctionnelle

Avant même d'interroger le problème, il faut traduire le malaise. 

C'est le rôle de l'analyse fonctionnelle, la clé de lecture de toute cette démarche, à laquelle ce blog a déjà consacré un article complet (voir : Votre gestion du temps : ce que l'analyse fonctionnelle peut faire pour vous) . 

Elle commence par une question déconcertante de simplicité : en quoi est-ce un problème ? Pour qui ? Avec quelles conséquences ? 

Tant que cette question n'est pas posée, on traite un malaise diffus ; une fois posée, le malaise devient réalité observable, avec des conséquences, des faits.

Retour au cas. En quoi les lenteurs de validation sont-elles un problème ? 

  • Pour le chef de projet : des jalons qui glissent et des équipes qui marquent le pas en attendant. 
  • Pour la direction : une capacité à lancer moins de projets dans l'année. 
  • Pour le demandeur : une fenêtre d'opportunité qui peut se refermer pendant que le dossier dort. 

Voilà déjà trois problèmes distincts sous une seule plainte — et le début d'un énoncé.

Du jugement au fait : le QQOQCCP passé au « Est / N'est pas »

Premier outil d'objectivation : le QQOQCCP. Qui, Quoi, Où, Quand, Comment, Combien, Pourquoi. Rien d'exotique : une grille d'interrogation systématique qui force à couvrir tout le champ.

Mais la grille seule ne suffit pas : on peut répondre au QQOQCCP avec des jugements (« Combien ? — Beaucoup trop »). D'où le second filtre, emprunté à Kepner-Tregoe : la méthode Est / N'est pas. Pour chaque fait, décrire ce qu'il est et ce qu'il n'est pas. C'est la logique de la négative : ce que le problème n'est pas délimite aussi sûrement le champ d'investigation que ce qu'il est.

Retour au cas. Passons-le au crible, en se limitant à trois questions pour l'exemple :

Question Est N'est pas
Quoi ? La validation budgétaire des projets L'arbitrage technique, qui circule vite
Quand ? Lors des projets transverses Sur les projets métiers récurrents, qui suivent le même circuit pourtant
Combien ? 8 jours ouvrés d'attente mesurés « Une éternité » - l'écart est chiffrable, donc discutable, donc négociable

Trois questions, six réponses, et le champ s'est resserré tout seul. Le mot « validation » du ressenti initial cachait deux circuits très différents. La cause n'est pas dans le circuit lui même : sinon, tous les projets seraient bloqués. Et l'écart est chiffré : huit jours, pas une éternité.

Nous n'avons pas encore cherché les causes. Nous ne les chercherons qu'au prochain article. Mais elles ont déjà moins de places où se cacher.

Dessiner pour voir

Reste un ennui : même avec objectivité, le problème reste des mots. Et l'esprit humain peine à se représenter spontanément la complexité d'un système : ses dépendances, ses boucles d'attente, ses allers-retours invisibles. La description textuelle ne suffit pas : il faut dessiner.

Le logigramme
L'ordinogramme, le fluxgramme — le nom importe peu.
→ Une colonne par acteur, et le cheminement réel du dossier, étape par étape. C'est ici qu'apparaissent les allers-retours invisibles : le dossier reparti trois fois entre le chef de projet et la direction financière parce que le budget était posé dans le mauvais format. Personne ne le voyait. Le dessin, lui, le crie.

La frise temporelle
Le temps de travail effectif d'un côté — 30 minutes de relecture —, le temps de traversée de l'autre : 8 jours dans des boîtes mail.
→ Le contraste est saisissant, et il est le problème. Avant la frise, personne ne l'avait énoncé ainsi.

La carte heuristique
La mind map.
→ À plat : les acteurs, les entrants, les sortants, avant d'analyser les nœuds du réseau. Nous y reviendrons dans cette série avec son mode d'emploi complet : ici, elle sert surtout à poser le problème à plat, pas encore à le résoudre.

Ces trois dessins n'exigent ni logiciel, ni méthode formalisée : une feuille, un crayon, un paperboard, des post-its. Et ce ne sont pas des livrables, ni de « beaux schémas » à déposer sur le bureau de la hiérarchie. Ce sont des objets de pensée, et de pensée partagée : quand le chef de projet et le financier se mettent devant le même dessin, ils regardent la même réalité au lieu de se renvoyer des abstractions. Leur rôle n'est pas d'embellir la démarche. Il est de révéler ce que les mots cachent.

Le problème, à moitié résolu

Retour à notre plainte initiale. « Le processus de validation est trop lourd. » Voici maintenant ce que dit le même problème, une fois filtré, délimité et dessiné :

« La validation financière des projets transverses subit 8 jours d'attente, dont 30 minutes de travail effectif, à l'étape du contrôle budgétaire, par manque de transmission du document X au bon format. »

Comparons. La première formulation ne permet aucune action : elle est un jugement, on peut la contester. La seconde désigne un phénomène daté, mesuré, localisé - et une piste de cause qui, si elle se confirme, se traite en une procédure de transmission. C'est un énoncé de problème : exploitable.

Et regardez ce qu'il révèle : le phénomène se joue à l'interface de deux systèmes (le système projet et le système financier) qui ne suivent ni la même temporalité ni les mêmes règles. Un problème qui revient chaque semaine à la même place, ce n'est pas un grain de sable : c'est encore un message du système sur lui-même.

Un problème bien formulé est à moitié résolu. Vous voyez maintenant ce que l'aphorisme veut dire : ce n'est pas de la littérature, c'est du travail, le premier acte de régulation.

Le problème est posé, mais pas expliqué. Pourquoi le format du document fait-il perdre 8 jours à un circuit qui, ailleurs, tourne ? La réponse est au prochain article : plonger sous la surface pour remonter aux causes racines — et faire les bons arbitrages sans se perdre dans la technique.

📌 À retenir

  • La méthodologie tient en cinq étapes ; la première (poser le problème) est celle qui mérite le plus d'attention, car elle conditionne la suite.
  • Une plainte n'est pas un énoncé : « trop lourd » est un jugement, et certains énoncés contiennent leur propre solution toute faite.
  • Trois filtres biaisent la description : ce qu'on connaît, ce dont on a envie, les idées reçues du moment.
  • L'analyse fonctionnelle ouvre le travail : en quoi est-ce un problème, pour qui, avec quelles conséquences ?
  • Le QQOQCCP passé au « Est / N'est pas » transforme le ressenti en fait délimité ; les dessins révèlent ce que les mots cachent.
  • Un phénomène qui se répète à l'interface de deux systèmes est un message du système sur lui-même.

Et vous ?

Quelle est la plainte que vous formulez depuis des semaines — et que dirait-elle, reformulée en faits ?

📚 Articles liés

Aucun commentaire:

Enregistrer un commentaire

A lire aussi