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.
Pourquoi le Q2 est notre obsession
Covey insiste : les personnes efficaces maximisent leur temps en Quadrant II. Quand tu investis en Q2, tu reduis mécaniquement les crises en Q1. Un plugin bien teste tombe moins souvent en panne. Un skill bien documente genere moins de tickets de support.
HBR confirme : les leaders qui consacrent du temps a la réflexion stratégique prennent de meilleures décisions sous pression. Chez PluginFactory, on reserve au minimum 40% du temps de conception au Q2. Architecture, tests, documentation. Pas parce que c'est agréable. Parce que c'est ce qui fait qu'un plugin est encore utilisable 6 mois après le déploiement.
C'est aussi la logique derrière tout bon processus : investir dans la structure aujourd'hui pour éviter le chaos demain.
Comment on classe les features avec le client
Deux questions suffisent pour placer n'importe quelle demande dans le bon quadrant.
"Que se passe-t-il si on ne le fait pas ?" Si la réponse est "un dev perd 30 secondes par jour", ce n'est pas Q1. Si c'est "les commits non securises passent en production", c'est Q1. Ce test elimine les fausses urgences.
"Est-ce que ça peut attendre le prochain sprint ?" Si oui, ce n'est pas urgent. Si non, c'est urgent. La combinaison des deux réponses donne le quadrant. Pas de zone grise.
On fait cet exercice avec le client au début de chaque phase de conception. On liste les demandes, on pose les deux questions, on place chaque feature dans la matrice. Le client voit pourquoi certaines demandes passent en Q3. La transparence evite les frustrations. C'est le même principe que le framework FOCUSED : structurer les décisions pour éviter de disperser l'effort.
Un exemple concret
Un client startup de 8 devs nous contacte avec 7 demandes : code review automatise, génération de tests, hook de sécurité anti-secrets, formatage de PR, changelogs, intégration ticketing, dashboard de metriques.
On applique la matrice. Le hook de sécurité est Q1 : des secrets ont déjà fuite, le risque est immédiat. Le code review et les tests sont Q2 : investissement structurel. Le formatage de PR et l'intégration ticketing sont Q3 : utiles mais pas bloquants. Les changelogs et le dashboard sont Q4 : "nice-to-have" absents des problèmes identifies pendant l'audit.
On livre le hook en semaine 1. On construit le code review et les tests en semaines 2 a 6. Le client a 3 outils qui resolvent 80% de ses problèmes, pas 7 demi-outils qui n'en resolvent aucun. C'est la même logique que savoir quand automatiser : choisir les batailles avec le meilleur rapport effort/impact.
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.
PluginFactory
Guide
