Prioriser la conception : comment nous utilisons Eisenhower
Comment PluginFactory applique la matrice d'Eisenhower pour prioriser les features d'un projet plugin. Les 4 quadrants mappes a des cas concrets.
Un client demande 15 features. On en livre 3. Les bonnes. Chaque engagement PluginFactory commence par cette tension : le client a une liste longué, et nous avons une capacité limitee. La question n'est pas "que peut-on construire ?". C'est "que doit-on construire en premier ?".
Zhu, Yang et Hsee l'ont mesure dans le Journal of Consumer Research : 35% des participants choisissent une tâche a faible rendement simplement parce qu'elle semble urgente. Le cerveau confond pression temporelle et valeur reelle. Le client qui signale un bug a 17h un vendredi créé une urgence percue. Le skill de code review qui eviterait 80% des bugs futurs peut toujours attendre. C'est ce piège que la matrice d'Eisenhower nous aide a désamorcer.
Les 4 quadrants d'un projet plugin
La matrice vient d'une citation d'Eisenhower en 1954 : "Ce qui est important est rarement urgent, et ce qui est urgent est rarement important." Stephen Covey l'a formalisee en 4 quadrants. On l'a adaptee a notre contexte.
| Urgent | Pas urgent | |
|---|---|---|
| Important | Q1 : Corriger maintenant | Q2 : Concevoir et planifier |
| Pas important | Q3 : Négocier avec le client | Q4 : Éliminer |
Quadrant 1 : les blocages critiques. Un hook de sécurité qui laisse passer des commits non valides. Un plugin qui crashe en production. Ça ne peut pas attendre. On corrigé immédiatement, on documente la cause, on créé un test pour que ça ne revienne pas.
Quadrant 2 : l'architecture et la qualité. Les tests automatises. La documentation des skills. Le refactoring d'un plugin devenu trop complexe. Ça peut toujours attendre "la semaine prochaine". C'est pour ça que ça n'arrive jamais. Et c'est la ou se construit toute la valeur a long terme.
Quadrant 3 : les demandes non critiques. "Est-ce qu'on peut ajouter un raccourci pour générer les changelogs ?" Ce sont des demandes legitimes, mais qui ne resolvent pas les problèmes identifies dans l'audit. On les note, on les replanifie.
Quadrant 4 : les features cosmetiques. Personnaliser les couleurs des logs. Optimiser un prompt qui fonctionne déjà a 95%. Zéro urgence, zéro impact business. On elimine.
La priorisation est une conversation
Mais attention : la matrice n'est pas un verdict unilatéral. C'est un support de discussion. Quand on place une feature en Q3, on explique pourquoi. Quand le client n'est pas d'accord, on reevalue ensemble. La logique ISO 31000 utilise la même approche a 2 axes : probabilité et impact. On l'aide a voir ses priorités avec un outil structure.
Le Kanban avec limites WIP prend le relais après. Eisenhower classe. Kanban organise. Les deux transforment une liste de 15 features en un plan de livraison lisible.
En resume
- 15 demandes, 3 livrables : prioriser, c'est choisir les features qui resolvent les vrais problèmes.
- Q1 = blocages critiques : bugs de sécurité, crashs, tout ce qui empêché l'équipe de travailler.
- Q2 = notre focus principal : architecture, tests, documentation. 40% du temps de conception minimum.
- Q3 = demandes legitimes a replanifier : utile mais pas bloquant, on negocie le timing avec le client.
- La matrice est un outil de dialogue : pas un verdict, une conversation structuree sur les priorités.
Ce qui est urgent sollicite. Ce qui est important construit. La matrice aide a voir la différence, et a la partager avec le client.