Récemment, j’ai eu l’occasion de prendre du recul sur l’organisation du développement des produits dans mon entreprise et l’impact que j’ai pu avoir. J’ai notamment pris conscience des deux activités principales que j’organisais et de ce que je pense être mon rôle dans chacune d’elles : la priorisation et la planification.
Voici comment je les définis :
La priorisation est l’ordonnancement des tâches en fonction de leur valeur. Elle répond à la question : “quel est le prochain changement susceptible de nous permettre d’atteindre notre objectif le plus rapidement ?”
La planification est l’ordonnancement des tâches en fonction des dépendances entre elles, et des ressources disponibles pour les réaliser. Elle répond à la question : “quand est-ce que ce sera terminé ?”
Ce sont deux activités distinctes, utiles, et complémentaires. Malheureusement, j’ai l’impression qu’on a tendance à les confondre, voire à faire disparaître la priorisation au profit de la planification.
La conséquence directe pour l’équipe est la suivante : on mesure son succès à sa capacité à réaliser le plan et pas à faire avancer l’objectif (qui peut être acquérir de nouveaux clients, éviter que les clients existants partent…). L’équipe est vue comme un appareil productif dont on cherche à optimiser la capacité, comme dans une usine.
Vingt années d’agilité sont passées par là. Nous savons désormais que pour réussir à suivre le plan, il doit être petit. En réalité, nous avons désormais deux plans : le Grand Plan (sur 3 mois, 6 mois, 1 an), et le Petit Plan (de deux semaines) que l’on appelle un “sprint”.
Et la priorisation dans tout ça ? Il en reste un tout petit peu. Au début de chaque cycle du Grand Plan, on se réunit pendant 2 heures avec tous les gens qui ont des choses à raconter (commerciaux, marketing, gestionnaires de comptes, support, direction, développeurs…) pour le définir. Chacun·e défend ses priorités. Il existe beaucoup de façons de le faire, et cela se passe plus ou moins bien selon les organisations et les personnes.
Dans le pire des cas, la personne la mieux payée, ou celle qui hurle le plus fort obtient gain de cause. Dans la plupart des cas, on obtient une collection de fonctionnalités sans lien entre elles, en essayant de satisfaire tout le monde (commerciaux, support…). Ce n’est d’ailleurs jamais satisfaisant. Chacun·e a un morceau et a compris qu’il ou elle doit partager. On est plus proche du dépit.
Et généralement, il n’y a pas d’ordre, car tout est obligatoire et urgent.
Pendant l’exécution du plan, les priorités changent sans arrêt, des urgences surviennent, et il faut faire plus sur la même période, à ressources égales (à cause des promesses faites). On organise des réunions toutes les deux semaines, voire toutes les semaines, pour ajuster le plan. Après tout, on est agile !
On oublie que le résultat de la priorisation est un pari et on se concentre sur la certitude illusoire offerte par une date.
Petit à petit, on utilise les deux mots de façon interchangeable, et l’on finit par ne plus faire la différence.
C’est un sujet qui m’interpelle depuis longtemps. Pourquoi ce que j’observe autour de moi (privilégier la planification à la priorisation) est-il à l’opposé de tout ce que je peux lire dans les bonnes pratiques et dans les articles d’auteurs qui semblent avoir trouvé la bonne réponse ? Pourquoi nos entreprises survivent-elles alors qu’elles font manifestement n’importe quoi ?
Je commence à discerner des morceaux de réponse :
Alors, est-ce un problème ? Et bien, pour les raisons citées ci-dessus, à court terme : non. Surtout si l’on ajoute un peu de chance par-dessus.
La question se pose en revanche à moyen et long terme. Le marché évolue, les besoins des clients aussi. Privilégier la planification à la priorisation, c’est avant tout laisser peu de place aux réflexions de fond nécessaires pour agir stratégiquement. Cela nuit à la capacité d’adaptation et d’innovation.
Je suis persuadé que bien prioriser octroie un avantage concurrentiel.
Je suis persuadé qu’on peut largement dépasser ses objectifs court terme en priorisant efficacement, plutôt que de juste les approcher.
Une observation me conforte dans cette idée. Je ne pense pas que ce soit un hasard si beaucoup de startups adoptent des pratiques de gestion de produit, basées sur une priorisation impitoyable.
Je n’ai aucune donnée pour appuyer mon propos, seulement mes observations de l’écosystème. Biais de confirmation (est-ce que je ne vois que les aspects qui me donneraient raison) ?
J’aimerais évoquer un dernier point, qui n’est pas vrai pour tout le monde. Les membres d’une équipe peuvent trouver démotivant d’enchainer les fonctionnalités dont l’impact individuel est quasi-invisible. La priorisation fait le lien entre la stratégie et le quotidien. Une priorisation claire et percutante donne du sens à son travail. Je sais que certain·e·s apprécient au contraire d’être isolé·e·s de ces problématiques et trouvent leur plaisir et leur confort dans la pure exécution du plan. Ce n’est pas incompatible avec une priorisation au top, mais l’incertitude peut être une source de stress au quotidien.
On peut résumer le problème à la dichotomie Stratégie vs Tactique. La priorisation est stratégique, la planification est tactique. Ne pas se préoccuper de la stratégie ne marche qu’un temps.
Partons du principe que la priorisation comme essentielle. Comment lui redonner toute sa place ? Plus précisément, comment faire quand on est n’est pas chef ? Je mentionne beaucoup la direction. Comme tous les sujets stratégiques et culturels, cela part d’en haut !
Voici ce que j’ai mis en place dans mon entreprise, à mon niveau, pour faire bouger les lignes.
Il existe toujours une liste d’idées, dans Excel, qui recense la liste de toutes les demandes d’évolutions et des anomalies. Ce fichier sert de base à la priorisation et la planification. Les éléments de la liste sont différents en valeur et en effort, parfois dans des ordres de grandeur différents, ce qui rend leur comparaison une à une compliquée. Par ailleurs, la valeur de deux éléments n’est pas toujours comparable, car leur nature est différente. Tous les changements n’ont pas de traduction directe en argent sonnant et trébuchant. C’est souvent le cas des améliorations de performances par exemple. Notons néanmoins que cela dépend du produit. Pour un site e-commerce, il est tout à fait possible de faire lien entre temps de chargement et taux de conversion.
Avec ces contraintes, comment prioriser la petite amélioration d’utilisabilité qui ennuie beaucoup d’utilisateurs face à une nouveauté qui permet d’acquérir de nouveaux clients ?
Regrouper plusieurs fonctionnalités qui concourent à un objectif commun dans un thème permet d’homogénéiser l’effort et la valeur. De plus, cela rend visible le “pourquoi” associé. Cela donne une base de discussions différentes, plus stratégiques, et donc plus pertinentes pour prioriser. On peut voir un thème comme un problème à résoudre, et les fonctionnalités comme des parties de la solution. Prioriser des thèmes est sain : on s’attache alors plus aux problèmes qu’aux solutions, qui deviennent des détails d’implémentation. Attention néanmoins à ne pas créer des thèmes trop abstraits.
Une astuce : imaginez que les thèmes seront sur votre communication client et interne. Est-ce que cela parle ? Excite ? Le cas échéant, vos thèmes sont bons.
C’est un des points les plus sensibles. Les clients ont besoin de dates pour s’organiser, donc on leur fournit des dates. Le problème est que raisonner à date fixe n’est pas le plus confortable en développement logiciel. C’est lié à l’incertitude : on découvre des cas limites, de nouvelles solutions plus adaptées au besoin, on s’aperçoit qu’on s’était trompé de besoin, et l’on fait aussi des erreurs. J’essaye (et je commence à avoir du succès) de promouvoir un horizon temporel avec une incertitude associée. C’est plus honnête vis-à-vis du client ! Et cela n’empêche pas, de temps en temps, de courir après une date.
Ce mode de fonctionnement devient obligatoire quand on commence à raisonner par thème. Mieux, il devient naturel. Les thèmes sont par définition des objectifs macro, on ne sait pas exactement ce qu’ils vont contenir (ou l’on ne s’interdit pas de le changer). Il devient alors difficile (et inutile) de donner une date précise. L’étape suivante (nous n’y sommes pas encore dans mon entreprise) est de remplacer l’estimation (cela va prendre tant de temps) par un budget (on alloue tant de temps à cela). Les faiseurs s’engagent à fournir un résultat dans le budget (sur un périmètre défini au fur et à mesure), et les décideurs assument de rallonger le budget ou pas selon les progrès. C’est d’ailleurs un excellent moyen de gérer l’incertitude, encore faut-il être confortable avec cela.
Une réaction que j’ai entendue :
Comment ? Qu’ouïe-je ? Plus d’engagements de date ? Mais ça va être la foire à la saucisse, et rien n’avancera.
Premièrement, si c’est ce que pense l’équipe dirigeante de ses équipes, cela signifie qu’ils ont mal recruté ou instauré un climat peu propice à la productivité. Bien fait pour elle.
Deuxièmement, on peut recadrer le problème (car la confiance, ça peut être difficile). On s’engage à livrer quelque chose tous les X temps. Livrer signifie ici “à disposition de la clientèle”. Il y a donc toujours un engagement de date. Voilà qui fera les pieds aux tirs aux flancs !
L’entreprise a forcément des objectifs à atteindre. Le rôle de responsable produit est de rendre tangible le lien (ou visible l’absence de lien) entre les objectifs de l’entreprise et les thèmes à prioriser. Il suffit de poser la question : est-ce que le thème X va nous faire plus progresser vers l’objectif que le thème Y ? L’intérêt est la discussion qui va suivre, qui devrait éclairer des incompréhensions et permettre à chacun de se réaligner.
L’incertitude est omniprésente en gestion de produit. Je pense que la capacité d’une organisation à embrasser l’incertitude est la clé d’une bonne priorisation. J’en parle d’ailleurs dans mon article sur les histoires utilisateurs. Pourquoi ? Ne pas être sûr, c’est pouvoir se remettre en question, et accepter de changer de direction avant de dépenser beaucoup d’argent pour rien.
La priorisation est l’activité idéale pour faire prendre conscience de l’incertitude de nos décisions. Commencez par essayer de noter des objectifs, des informations transmises, les “educated guess”, et autre “gut feeling” lors des sessions de priorisation. Vous pouvez déjà les questionner : qu’est-ce qui te fait dire ça ? Quel est ton degré de certitude ? As-tu des preuves ? Lors de la session suivante, commencez par un debrief : où en est-on par rapport à ce que nous nous sommes dit ? Évidemment, plus nous mesurons, plus cet exercice est simple. N’oublions pas que les mesures peuvent être qualitatives ou quantitatives et que les deux sont très complémentaires. L’important est d’avoir des éléments de verification qui font écho aux hypothèses émises lors de la priorisation.
Je veux conclure sur un point dédié aux anomalies. Je ne connais pas de logiciel sans anomalies, mais j’en connais qui en ont tellement que cela devient un casse-tête à gérer.
Si c’est votre cas, vous passez sûrement beaucoup de temps à planifier leur résolution et à jongler avec les autres priorités (qui sont toujours aussi urgentes). La non-qualité ne se gère pas, elle se corrige. Ce n’est jamais facile, surtout dans les vieux logiciels. Je suis très bien placé pour le savoir. En revanche, on peut mettre en place des procédures ou des outils pour améliorer la stabilité du produit. Si c’est possible, vous pouvez même en faire une priorité qui s’appuie sur un objectif chiffré : garantir la stabilité du logiciel en réduisant le nombre de tickets ouverts à X et le nombre de tickets créés à Y/semaine.
Malheureusement, il n’est pas rare que les autres fonctionnalités prévues soient liées à des engagements clients qui s’attendent à être livrés à temps. Il n’est pas possible de tout faire. Il n’y a pas de solution miracle, il faut prioriser :
Je veux être sûr d’être clair : ça ne veut pas dire que l’on ne développe aucune fonctionnalité pour se consacrer entièrement à la correction d’anomalies, ou inversement. Cela veut dire que l’une occupera la majorité du temps au détriment de l’autre, et que cela va impacter d’autres personnes que l’équipe de développement (ici les commerciaux et le support). C’est donc une décision stratégique (comme toutes les décisions de priorisation). Je peux vous expliquer comment on a résolu le problème chez nous en privé si cela vous intéresse.
Je l’ai écrit dans l’introduction : priorisation et planification sont deux activités complémentaires. Je ne pense pas qu’il soit possible (ni souhaitable) de faire disparaître la planification. En revanche, je milite pour que cette activité soit aussi limitée que possible (vue comme un déchet au sens lean du terme). En effet, est-il pertinent de passer du temps à déterminer la date précise de la fin d’une tâche ? Probablement pas, à condition que l’on ait confiance dans le fait qu’elle sera bientôt terminée (quelques jours, au pire quelques semaines). Pour cela, deux idées :
Ainsi, elle peut disparaître des discussions stratégiques (la priorisation) grâce à la promesse d’une livraison régulière et continue de valeur.
Dans le modèle que je décris, le Grand Plan n’est plus une liste ordonnée de fonctionnalités, mais d’objectifs à atteindre ou de problèmes à résoudre, il n’y a plus besoin de planification à ce niveau. En revanche, le Petit Plan consiste lui à planifier les actions pour déterminer quels changements concrets doivent être apportés et les implémenter.
Cela fait deux ans que j’ai rejoint mon entreprise. Lors de la dernière réunion de planification, il s’est passé un truc nouveau. Comme d’habitude, nous avons proposé un plan composé d’une liste de thèmes avec une estimation d’effort pour chacune. Nous avons même ajouté des fonctionnalités sans lien entre elles dans le plan.
La nouveauté est que nous avons parlé stratégie. Stratégie commerciale, positionnement face à la concurrence. La discussion s’est faite naturellement. Deux éléments ont joué :
Je considère que c’est une réussite. C’est d’autant plus vrai qu’il n’a quasiment pas été question de date.
De plus, nous avons radicalement changé le périmètre du thème majeur dès les premières semaines de travail. Nous avons même suffisamment avancé sur l’implémentation pour fournir à notre département marketing et nos vendeurs des informations très précises sur les fonctionnalités. C’est accompagné de contenus sur les cas d’usage traités (et ceux non traités) et de quoi améliorer leur culture des problématiques clients sur ces questions.
Tout cela est encore timide, mais je suis convaincu que nous sommes sur la bonne voie.
Deux ans ! Le changement prend du temps, soyons patients 😊.