« MoSCoW (technique externe et qualitative) » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 17 : | Ligne 17 : | ||
* '''Must'''have (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord. | * '''Must'''have (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord. | ||
* '''Should''' have (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have", et partagent généralement l'importance des exigences ''MUST'', sans être aussi sensibles aux échéances. | * '''Should''' have (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have", et partagent généralement l'importance des exigences ''MUST'', sans être aussi sensibles aux échéances. | ||
* '''Could''' have (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau | * '''Could''' have (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau de caractéristiques "Nice to have". | ||
* '''Won't''' have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques ou même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures. | * '''Won't''' have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques ou même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures. | ||
<br/> | <br/> | ||
Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences ''SHOULD'' ou ''COULD'' sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux. | Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences ''SHOULD'' ou ''COULD'' sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux. | ||
Version du 12 août 2018 à 14:03
Auteur : Daniel Zacarias
Source : 20 Product Priorization Techniques: A Map and Guided Tour
Traducteur : Fabrice Aimetti
Date : 12/08/2018
Traduction :
Article de référence : Tableau périodique des techniques de priorisation produit
La méthode MoSCoW est une technique de priorisation utilisée dans de multiples domaines de management pour parvenir à un consensus sur les éléments les plus importants pour les parties prenantes et les clients.
Le terme est un acronyme, chaque lettre représentant l'une des catégories de priorisation possibles (avec des O ajoutés pour le rendre mémorable). Les exigences sont donc classées comme suit :
- Musthave (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord.
- Should have (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have", et partagent généralement l'importance des exigences MUST, sans être aussi sensibles aux échéances.
- Could have (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau de caractéristiques "Nice to have".
- Won't have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques ou même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures.
Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences SHOULD ou COULD sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux.