Méthode MoSCoW : Comment tirer le meilleur parti de la hiérarchisation

La hiérarchisation a joué un rôle important dans le succès de la plupart des applications riches en fonctionnalités comme Slack et GitLab. Au départ, elles offraient un ensemble limité de fonctionnalités essentielles pour leurs utilisateurs. Avec le temps, cet ensemble a été complété par d’autres fonctionnalités. Railsware va partager son propre style de priorisation et montrer comment nous utilisons la méthode MoSCoW pour réaliser de longues listes de tâches.

Pourquoi avez-vous besoin de priorisation ?

En règle générale, la routine quotidienne comprend un tas de tâches. Idéalement, vous aurez suffisamment de temps et d’énergie pour les couvrir toutes – mais il se pourrait bien que le nombre de tâches soit immense et que les ressources disponibles ne soient pas en abondance. C’est là qu’intervient la hiérarchisation des priorités.

Ce terme désigne un processus visant à filtrer ce que vous avez à faire par ordre d’importance ou de pertinence. Par exemple, si vous construisez une maison, il est peu probable que vous commenciez par le toit ou les murs avant que vos fondations ne soient faites. Bien sûr, les choses sont beaucoup plus compliquées dans le secteur du développement web, et cet exemple ne peut pas révéler toute la valeur de l’établissement de priorités.

Les projets complexes et les nombreuses startups font appel à des techniques de priorisation avancées. Celles-ci consistent généralement en des cadres connus pour des exigences spécifiques ou des règles qui améliorent la prise de décision. Le succès de la hiérarchisation des priorités est souvent déterminant pour le succès de l’entreprise elle-même. S’empêtrer dans des tâches en attente et non réalisées est une voie directe vers l’échec. C’est pourquoi les entreprises accordent une attention particulière aux méthodes de hiérarchisation à utiliser. Il en existe un bon nombre, mais elles ont toutes des caractéristiques communes, comme l’orientation vers les apports (internes ou externes) et les outils quantitatifs ou qualitatifs.

A propos, nous embauchons. Consultez nos offres d’emploi.

L’orientation externe signifie que vous devez impliquer des parties prenantes extérieures à l’équipe de développement pour établir les priorités, tandis que les méthodes orientées vers l’interne peuvent être exécutées purement en interne. Les méthodes quantitatives impliquent un accent plus profond sur les métriques numériques dans la priorisation, et la qualitative repose sur les avis d’experts, les votes, les classifications dans une plus grande mesure. Compte tenu de cela, elles sont traditionnellement divisées dans les catégories suivantes :

Vous pouvez lire ici les différentes techniques de priorisation Agile en détail.

Railsware préfère une technique développée par Dai Clegg en loin 1994. Initialement, elle était nommée MSCW, mais deux O ont été ajoutés pour améliorer la prononciation. Cela lui a également permis de ressembler à la capitale de la Russie. Voyons comment cela fonctionne.

Qu’est-ce que MoSCoW ?

Pour comprendre l’essentiel de la méthode MoSCoW, nous devons nous pencher sur son origine – la méthode de développement de systèmes dynamiques (DSDM). Il s’agit d’un cadre de gestion de projet Agile conçu par des praticiens dans le but d’améliorer la qualité des processus RAD (rapid app development). L’une des caractéristiques des projets DSDM est la détermination stricte de la qualité, des coûts et des délais à un stade précoce. Dans cette optique, toutes les tâches du projet doivent être réparties en fonction de leur importance. La nécessité de gérer les priorités a déclenché l’invention d’un mécanisme de priorisation spécialisé.

Ce mécanisme a été mis en œuvre via MoSCoW – une solution simple mais puissante pour définir les priorités à la fois avec et sans timeboxes. Cependant, il montre une meilleure efficacité si vous avez une certaine date limite pour une tâche, une fonctionnalité, une sous-fonction, une fonctionnalité, etc. Le cadre est applicable à tous les niveaux de hiérarchisation des projets, de haut en bas, ainsi qu’à toutes les fonctions et domaines d’intérêt.

L’abréviation MoSCoW (à l’exception des voyelles) est sculptée avec les premières lettres des catégories de priorité avec lesquelles elle fonctionne. Il s’agit de Must-haves, Should-haves, Could-haves et Won’t-haves. Et c’est ainsi que vous pouvez définir quelle tâche tombe sur quelle catégorie.

Règles de priorisation

Ces règles ou exigences estiment l’importance de toute tâche/processus/fonctionnalité/etc. Chaque entreprise ou équipe de travail utilise sa propre approche pour définir les exigences, mais, en général, elles ne se différencient pas beaucoup et se présentent comme suit.

Must-haves

Il s’agit d’exigences de première priorité, qui façonnent les fondements du principal pipeline. Les éviter revient à bloquer l’ensemble du projet ou des activités ultérieures. En règle générale, la conception d’un produit dépend entièrement de la définition des must-haves en utilisant des pointeurs tels que « requis pour le lancement », « requis pour la sécurité », « requis pour la validation », « requis pour fournir une solution viable », etc.

• Pouvons-nous avancer dans le projet si cette tâche est annulée ? – si NON, c’est un DOIT

Doit-on

Ce type d’exigence est de priorité secondaire. Les should-haves n’affectent pas le lancement et, traditionnellement, sont considérés comme importants mais pas cruciaux. Ils se distinguent des must-haves par la disponibilité d’une solution de contournement. Par conséquent, il est peu probable que l’échec d’une tâche indispensable entraîne l’échec de l’ensemble du projet. Si vous construisez un produit, il sera toujours utilisable même si ces exigences ne sont pas satisfaites.

• Pourrons-nous avancer dans le projet si cette tâche est effectuée un peu plus tard ? – si OUI, c’est DEVRAIT

Could-haves

L’exigence suivante est moins importante que les deux précédentes mais toujours souhaitée. Si l’on compare les could-haves aux should-haves, les premiers sont définis par un degré plus faible d’effet négatif en cas d’omission. Traditionnellement, les exigences prioritaires de troisième niveau dans le cadre Agile MoSCoW sont réalisées si un projet n’est pas fortement limité dans le temps. Dans le cadre du développement de produits, nous pouvons les appeler des mises au point à faible coût.

• Pouvons-nous sacrifier cette tâche jusqu’à la date limite ? – si OUI, c’est COULD

Vous ne voulez pas

Vous pouvez également rencontrer ce type d’exigence sous le nom de would-have ou wish-to-have, mais ces variantes ne sont pas reconnues par le Wiki. Cependant, quel que soit le nom choisi, ces exigences définissent la priorité la plus basse pour les tâches qu’il n’est pas viable de mettre en œuvre avec un budget et un délai particuliers. Won’t-have ne signifie pas un rejet complet de quelque chose. Elle envisage une réintroduction dans des conditions favorables à l’avenir.

• Pouvons-nous y revenir lorsque les choses iront mieux ? – si OUI, c’est WON’T

Comment utiliser

Tout semble simple en théorie, mais l’est-il en pratique ? Vérifions comment fonctionne une analyse MoSCoW de priorisation des fonctionnalités à travers l’exemple d’une application web ordinaire. En guise d’échantillon, nous allons utiliser des fonctions de base tirées de l’un des produits Railsware :

• Un utilisateur peut s’inscrire
• Un utilisateur peut se connecter
• Un utilisateur peut réinitialiser son mot de passe
• Un utilisateur peut choisir le système de facturation
• Un utilisateur peut supprimer le compte
• Un utilisateur peut ouvrir une page de suivi du temps-.page de suivi du temps
• Un utilisateur peut choisir les options de suivi du temps
• Un utilisateur peut installer une version d’application mobile
• Un utilisateur peut choisir le thème visuel de l’application

Selon des exigences particulières en matière de budget et de temps, nous pouvons isoler les fonctionnalités les plus fondamentales à mettre en œuvre dans le produit minimum viable. Après l’analyse des priorités, nous obtenons ce qui suit :

• Un utilisateur DOIT s’inscrire
• Un utilisateur DOIT se connecter
• Un utilisateur DOIT réinitialiser son mot de passe
• Un utilisateur DOIT ouvrir une page de suivi du temps

Les tâches les plus prioritaires sont suivies de fonctionnalités importantes, mais pas vitales pour l’application. Ce sont :

• Un utilisateur DOIT choisir le système de facturation
• Un utilisateur DOIT supprimer son compte
• Un utilisateur DOIT choisir les options de suivi du temps

L’évolution de l’appli prévoit bien sa disponibilité sur les appareils mobiles. Cependant, cette tâche n’est qu’agréable à réaliser à ce stade.

• Un utilisateur POURRAIT installer une version de l’application mobile

Et maintenant la fonctionnalité la moins prioritaire. Elle vise à améliorer l’expérience utilisateur une fois l’app sur les rails. La sélection de thèmes n’est certainement pas ce que nous allons faire maintenant. Cependant, cette fonctionnalité est gardée pour plus tard.

• Un utilisateur ne choisira pas le thème visuel de l’appli CETTE FOIS.

Le plus difficile dans la priorisation est d’être d’une intelligence glacée et de se concentrer sur les tâches essentielles à réaliser. Sinon, vous pouvez tomber dans le piège du TOUT EST INDISPENSABLE, selon lequel n’importe quelle fonctionnalité comme l’option du système de facturation ou la disponibilité de l’application mobile se transforme en incontournable. Et c’est pourquoi la méthode Agile MoSCoW est cool. Elle vous permet de définir un ensemble de fonctionnalités de base, qui ont la priorité absolue et souligne que vous ne devez rien abandonner. L’équilibre sain entre must-haves + should-haves est de 50% de la portée totale. Toutes les tâches (ou presque) seront mises en œuvre plus tard, mais dans l’ordre de leur importance pour votre objectif. L’objectif de cet exemple est de construire un MVP, et la catégorisation ci-dessus montre la progression attendue des fonctionnalités de l’app.

Nous avons beaucoup de connaissances à partager avec vous. Rejoignez l’équipe Railsware.

Pour et contre MoSCoW

Le framework est assez populaire parmi les projets Agile avec des timebox fixes puisqu’il permet de gérer les exigences pour une version spécifique d’un produit. Cette méthode de priorisation a prouvé son efficacité et sa fiabilité au sein de notre entreprise également, et nous la conseillons effectivement à nos clients. Cependant, elle n’est pas parfaite, bien sûr, et un regard impartial peut révéler certains défauts associés à la technique MoSCoW. Examinons ses forces et ses faiblesses.

La priorisation MoSCoW chez Railsware

Regardons comment nous établissons les priorités au sein de l’entreprise.

Développement de produits : nous nous appuyons sur une feuille de route où sont précisées les fonctionnalités du produit et l’ordre de leur mise en œuvre. En règle générale, nous nous appuyons sur les MoSCoW pour définir quelle fonctionnalité passe en premier, laquelle vient en second, et ainsi de suite, en tenant compte de leur importance et de l’interdépendance des fonctionnalités. Les Must-haves et Should-haves sont destinés à la sortie du produit. Les Could-haves et Won’t-haves sont reportés à l’avenir.

RH et recrutement : la priorisation repose sur des exigences telles que la demande d’une expertise particulière, la disponibilité du budget, le timebox (l’urgence de cette expertise), etc. Nous tirons parti des schémas similaires d’établissement des priorités dans d’autres domaines d’intérêt, notamment l’accueil, la marque, le marketing, etc.

Le plus grand défi de la méthodologie est que toutes les parties prenantes doivent être familiarisées avec un contexte suffisant pour estimer correctement les fonctionnalités. En outre, les parties prenantes qui représentent différentes fonctions comme les ventes, le développement, le marketing ont leur propre vision de l’établissement des priorités, ce qui ne fonctionne pas toujours vers une priorisation correcte. Les investisseurs traitent généralement toutes les fonctionnalités comme des Must-haves de leur point de vue général et ont besoin qu’elles soient réalisées sans aucun respect de leur ordre de mise en œuvre.

Railsware a une structure organisationnelle holacratique. Nous profitons d’un leadership collectif basé sur le modèle RASCI et prenons des décisions sur différentes choses, y compris la priorisation par le biais du vote. Les membres de l’équipe peuvent choisir parmi plusieurs options comme vraiment vouloir, vouloir et ne pas vouloir. Chaque option implique un point particulier. L’option ayant le plus grand nombre de points a la plus haute priorité. Pour les petits contextes, un rôle responsable (chef d’équipe, chef de projet, etc.) peut être chargé de fixer les priorités par lui-même.

Les alternatives MoSCoW que vous pourriez trouver utiles pour votre projet

Railsware utilise fortement le cadre Agile MoSCoW et en est satisfait. Cependant, cela ne signifie pas que nous sommes fermés à d’autres solutions. D’ailleurs, un bon chef de produit doit considérer les métriques clés du produit et construire la priorisation en fonction de celles-ci. Voici donc d’autres techniques intéressantes dont vous pourriez bénéficier.

Modèle de Kano

Avec ce cadre, vous pouvez définir dans quelle mesure les utilisateurs sont satisfaits des fonctionnalités du produit. Le modèle de Kano repose sur un questionnaire, qui est utilisé pour apprendre l’attitude des utilisateurs à l’égard d’une fonctionnalité particulière (aime, attend, n’aime pas, neutre, etc.). Visuellement, le modèle peut être exprimé via un diagramme à deux dimensions où l’axe vertical est responsable du niveau de satisfaction des utilisateurs (de totalement frustré à incroyablement heureux) et où l’axe horizontal montre soit combien a été investi dans la fonctionnalité (Investissement), soit à quel point elle a été mise en œuvre (Mise en œuvre), soit à quel point les utilisateurs en bénéficient (Fonctionnalité).

La catégorisation des exigences comprend quatre types qui sont hiérarchisés dans l’ordre suivant : must-be, performance, attractif et indifférent. Les must-bes sont des éléments de base que les utilisateurs attendent généralement. Les exigences de performance (également appelées unidimensionnelles) représentent le juste milieu et permettent d’augmenter le niveau de satisfaction. Les exigences attrayantes sont celles qui améliorent l’expérience de l’utilisateur. Ce sont des « nice-to-haves » ou des « could-haves » selon le MoSCoW. Les indifférentes sont moins priorisées et parfois même entièrement omises.

Valeur contre complexité

Cette technique de priorisation est l’une des plus simples. Vous pouvez la rencontrer sous les noms de valeur par rapport au coût ou valeur par rapport à l’effort également. La méthode semble intuitive et vise à maximiser la fourniture de valeur. L’estimation de l’importance des fonctionnalités repose sur l’effort investi pour les mettre en œuvre et sur la valeur qu’elles apporteront. Voici comment cela se présente visuellement:

Wrapping up

L’art de définir des priorités montre l’efficacité de votre flux de travail. Le choix de Railsware se porte sur le cadre de gestion de projet MoSCoW, qui a fait bonne figure en matière de fonctionnalités et de produits polyvalents. Cependant, il peut s’avérer moins utile pour des projets immenses avec plusieurs équipes impliquées dans le pipeline. Nous vous conseillons de trouver une solution de priorisation efficace qui correspond à vos besoins uniques, et de toujours éviter de vous laisser entraîner par d’innombrables tâches en attente.