Je suis fan de musique live et j’apprécie particulièrement les festivals de musique. Si vous n’êtes jamais allé à un festival de musique, vous ratez quelque chose. Ils impliquent généralement plusieurs jours d’écoute de musique, de danse et de divertissement. Il y a souvent plusieurs étapes, donc un défi consiste à décider quels groupes écouter.
Je me suis souvenu de ce fait l’été dernier lorsque j’ai croisé un de mes amis (qui est aussi un BA) lors d’un festival de musique. Il s’est avéré que nous avions tous les deux créé (et imprimé) des feuilles de calcul indiquant qui jouait quand et à quelle heure. Ma feuille de calcul utilisait même un codage couleur, le vert étant les bandes que nous avions prévu de voir et le jaune étant des “sauvegardes” (au cas où le premier choix serait trop plein, ou s’il y avait une autre raison pour laquelle nous ne pouvions pas y arriver). Eh bien, tout le monde aime les feuilles de calcul, n’est-ce pas ?
Comparaison et coût d’opportunité
Feuilles de calcul mises à part, cela illustre un point qui est également important dans les projets et les initiatives de développement de produits. Généralement, chaque action ou décision a un coût d’opportunité associé avec. Prendre un plan d’action signifie qu’il n’est pas possible d’en poursuivre d’autres (car le temps et le budget sont concentrés sur le plan d’action qui a été choisi).
Lors d’un festival de musique, le coût d’opportunité est assez facile à calculer. Si je vois le groupe A sur la scène principale à 20h, je ne peut pas voir Band B sur une autre scène en même temps. Je ne peux pas non plus aller au bar (probablement pour le mieux), ni prendre un hot-dog hors de prix. Le fait de décider d’une action signifie que d’autres options ne s’offrent plus à moi.
Il en va de même lorsqu’il s’agit de décider des projets à faire progresser, des fonctionnalités sur lesquelles se concentrer ou des exigences à prioriser. Lors de la rédaction d’un document d’options, il est habituel de considérer l’impact de « ne rien faire », mais dans certains cas, il peut être utile d’approfondir encore la réflexion et de considérer ce autre pourrait être fait avec le temps et l’argent.
Lors de la hiérarchisation des exigences, il y a toujours des compromis. Il est souhaitable de fournir d’abord les fonctionnalités qui permettront de réaliser le plus d’avantages. C’est certainement vrai, et c’est quelque chose auquel je suis sûr que nous aspirons tous… mais en réalité, les choses ne sont-elles pas souvent un peu plus compliquées que cela ? Il y a souvent des conflits de ressources (plusieurs équipes de développement et de test, souvent avec des ressources limitées), des défis au niveau organisationnel (gels de code, changements de budget) et toute une série d’autres opportunités et menaces dehors de l’orbite immédiate du projet.
Parfois, il est logique de faire la deuxième meilleure chose
Il peut y avoir des cas où il est en fait logique de faire le deuxième chose la plus bénéfique. Imaginez qu’il existe un ensemble d’exigences hautement prioritaires. Tout le monde s’accorde à dire que ceux-ci apporteront le plus d’avantages. Cependant, les experts techniques qui doivent y travailler sont également nécessaires pour effectuer certaines opérations de maintenance essentielles. Bien que la maintenance des systèmes et l’art de “garder les lumières allumées” ne soient jamais aussi glamour que de fournir de nouvelles fonctionnalités, cela reste très important.
Au sein du projet, la décision logique est d’opter pour les exigences les plus prioritaires. Mais, il y a un coût d’opportunité pour l’organisation. Si cette mesure est prise, la maintenance est retardée. Cela pourrait être une très mauvaise idée, selon la nature de l’entretien.
Le point clé ici est que progresser est la deuxième meilleure chose pour le projet pourrait en fait être la meilleure chose pour l’organisation dans son ensemble.
Publicité
Savoir quelles options de décision sont « périssables »
Certaines options qui s’offrent à nous « périssent » si elles ne sont pas prises. Si vous êtes dans un aéroport et que vous retardez trop longtemps la décision de monter dans l’avion, vous avez la possibilité d’embarquer ce l’avion finira par disparaître (car il aura décollé sans vous). La même chose est vraie lors d’un festival de musique, si le groupe A entre en conflit avec le groupe B, alors vous avez un choix direct à faire. Choisir la bande A signifie que vous ne le faites pas voir Band B à ce festival.
Celles-ci sont différentes des décisions de priorisation où vous pouvez faire les deux choses de manière séquentielle. Retarder l’exigence A afin que l’équipe puisse effectuer une maintenance urgente ne signifie probablement pas que l’exigence A jamais être livré… il sera juste retardé. Il y aura un impact sur le moment de la réalisation des avantages, mais ce n’est pas une décision binaire « oui ou non ». Il est important que ces types de décisions de priorisation soient séparés de ceux où il y a vraiment est une chance, et une seule chance.
Les BA en tant que facilitateurs de la prise de décision
Tout cela mène à une conclusion intéressante : un élément important et souvent négligé du rôle du BA est de faciliter la prise de décision. Qu’il s’agisse de hiérarchiser les projets, les demandes de fonctionnalités, les exigences ou autre chose, nous sommes à votre disposition pour analyser les différentes perspectives et nous assurer qu’une décision éclairée est prise.
Il est crucial de veiller à ce que nous le fassions consciemment, en tenant compte de plusieurs facteurs (tout en gardant à l’esprit le « coût d’opportunité »). C’est l’un des nombreux domaines où les BA ajoutent de la valeur !
Vues : 263
