productivity-decision-matrix

name	productivity-decision-matrix
description	Aide à prendre une décision complexe en structurant les options et critères. À utiliser quand l'utilisateur hésite entre plusieurs choix. Se déclenche aussi avec "je ne sais pas quoi choisir", "avantages inconvénients", "comparer les options", "matrice de décision", "quel choix faire". Also triggers on "help me decide", "weighted decision matrix", "compare options".

Decision Matrix

Quand utiliser ce skill

• 2 options ou plus avec des trade-offs non évidents.
• Décisions techniques : choix de stack, d'outil, de cloud provider, d'architecture.
• Décisions stratégiques : priorisation de projets, choix de prestataire, recrutement.
• Décisions personnelles : changement de poste, investissement, formation.

Workflow en 7 étapes

1. Inventorier les options

Lister toutes les alternatives réalistes. Ne pas en exclure prématurément.

Options identifiées :
- A : PostgreSQL
- B : MongoDB
- C : DynamoDB

2. Collecter les critères

Poser la question : "Qu'est-ce qui ferait que vous regretteriez votre choix dans 12 mois ?"

Exemples de critères courants selon le contexte :

Contexte	Critères typiques
Tech/outil	Coût, courbe d'apprentissage, scalabilité, support
Architecture	Couplage, testabilité, temps de déploiement, dette
Prestataire	Prix, délai, références, risque de dépendance
Projet/produit	Valeur métier, effort, time-to-market, risque

3. Pondérer les critères (poids 1–5)

Chaque critère reçoit un poids reflétant son importance relative.

Critère          | Poids
-----------------|------
Performance      |   5
Coût licence     |   4
Facilité d'admin |   3
Écosystème OSS   |   2

4. Évaluer chaque option (note 1–5)

Note objective par critère. Demander les données concrètes si disponibles (bench, devis, avis).

5. Construire la matrice pondérée

Score pondéré = note × poids. Score total = somme des scores pondérés.

Option       | Perf (×5) | Coût (×4) | Admin (×3) | OSS (×2) | TOTAL
-------------|-----------|-----------|------------|----------|------
PostgreSQL   | 4×5=20    | 5×4=20    | 4×3=12     | 5×2=10   |  62
MongoDB      | 4×5=20    | 4×4=16    | 3×3=9      | 4×2=8    |  53
DynamoDB     | 5×5=25    | 2×4=8     | 5×3=15     | 1×2=2    |  50

6. Analyser les résultats

• L'option avec le score total le plus élevé est le choix rationnel pondéré.
• Identifier les trade-offs clés : où l'option gagnante sacrifie quoi.
• Vérifier les dealbreakers : un critère à poids 5 avec note 1 peut éliminer une option indépendamment du total.

7. Résumer de façon décisionnelle

Toujours conclure par une formule conditionnelle :

"Si tu privilégies la maîtrise des coûts → PostgreSQL (score 62). Si la scalabilité serverless est prioritaire → DynamoDB malgré le coût. Recommandation neutre : PostgreSQL couvre 90% des critères avec le meilleur équilibre."

Critères de qualité d'une bonne matrice

• Exhaustivité : 3–7 options, 4–8 critères (au-delà, la lisibilité chute).
• Indépendance : critères non redondants (ne pas avoir "coût" ET "budget" séparément).
• Mesurabilité : chaque critère doit pouvoir être noté sans ambiguïté.
• Représentativité : les poids reflètent les vraies priorités du décideur, pas des suppositions.

Anti-patterns / pièges

Piège	Symptôme	Correctif
Sunk cost fallacy	"On a déjà investi 6 mois sur X"	Ignorer le passé, évaluer sur les coûts futurs
Status quo bias	Note systématiquement plus haute à l'existant	Forcer une évaluation à blanc sans label
Critères post-rationalisation	Critères ajoutés pour justifier un choix déjà fait	Définir les critères AVANT de noter les options
Paralysie par l'analyse	Matrice infinie avec 15 critères	Limiter à 6 critères max, timebox la réflexion
Score total trompeur	Une option domine mais a un 1 sur un critère critique	Vérifier les minimums acceptables par critère
Poids uniformes	Tous les critères à 3	Forcer un tri : au moins un critère à 5, un à 1

Garde-fous

• Ne pas choisir à la place de l'utilisateur : présenter les résultats, nommer le gagnant, laisser la décision finale.
• Si deux options sont à moins de 10% d'écart, signaler que la différence n'est pas significative : d'autres facteurs (intuition, politique interne, contrainte cachée) peuvent primer.
• Signaler explicitement si un critère important manque de données objectives (ex. : estimation de coût incertaine).
• En contexte technique, toujours mentionner le coût de réversibilité : changer d'avis dans 18 mois, quelle est la peine ?

Exemple complet condensé (choix de framework frontend)

Critères          | Poids | React | Vue | Svelte
------------------|-------|-------|-----|-------
Ecosystem/libs    |   5   |   5   |  4  |   3
Courbe apprenti.  |   4   |   3   |  5  |   5
Perf bundle       |   3   |   3   |  3  |   5
Recrutement       |   5   |   5   |  3  |   2
Community/support |   4   |   5   |  4  |   3
TOTAL PONDÉRÉ     |       |  91   | 80  |  72

Recommandation : React si l'équipe grossit (recrutement critique). Svelte si projet solo ou perf bundle primordiale.

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.