Aller au contenu
Nos produitsSur-mesureSites & boutiquesRéférencesWe AreBlogNous contacter
Apparence
← Tous les articles
· 6 min de lecture#méthode#cadrage#produit

Prioriser quand tout est urgent

A

Alban

Product manager & product owner

En bref

Comment prioriser un backlog quand toutes les demandes sont présentées comme urgentes ?

En remplaçant la question « est-ce urgent ? » par « que se passe-t-il si on ne le fait pas ce trimestre ? ». Cette reformulation fait apparaître le coût réel de l'attente, qui est souvent nul. Ensuite, imposez une contrainte de rareté : une liste ordonnée sans ex æquo, et une capacité affichée. Tant que plusieurs demandes peuvent être « prioritaires » simultanément, aucune priorisation n'a lieu.

Toutes les demandes qui arrivent sur mon bureau sont urgentes. C’est normal : personne ne demande une fonctionnalité en précisant qu’elle peut attendre un an.

Le travail consiste donc à faire apparaître une hiérarchie que les demandeurs, individuellement, n’ont aucune raison de produire.

La question qui change tout

J’ai arrêté de demander « est-ce urgent ? ». La réponse est toujours oui, et elle n’apporte aucune information.

Je demande maintenant : « que se passe-t-il concrètement si on ne le fait pas ce trimestre ? »

Les réponses se répartissent en trois catégories, et le tri se fait presque tout seul.

Il se passe quelque chose de mesurable. « On perd le client X. » « On ne peut pas facturer le nouveau contrat. » « On reste non conforme au 1er janvier. » C’est prioritaire, et personne ne le conteste.

Il se passe quelque chose de diffus. « Les équipes continueront de perdre du temps. » Souvent vrai, rarement chiffré. Je demande alors combien de temps, pour combien de personnes. La moitié du temps, on découvre que c’est deux minutes par semaine pour trois personnes — et la demande redescend d’elle-même.

Il ne se passe rien. « Ce serait mieux. » C’est parfois vrai. Ce n’est jamais prioritaire.

Cette question a un avantage supplémentaire : elle ne met personne en défaut. Je ne dis pas non, je demande une information. C’est le demandeur qui, souvent, conclut lui-même que ça peut attendre.

Rendre la rareté visible

Le vrai problème d’un backlog n’est pas l’absence d’ordre. C’est que rien ne matérialise le fait que la capacité est limitée.

Deux règles que j’applique sans exception.

Une liste strictement ordonnée, sans ex æquo. Pas de catégories « haute priorité » qui contiennent dix-sept éléments. Une liste numérotée où le 3 passe avant le 4. C’est inconfortable, et c’est exactement pour ça que ça marche : cela force la conversation entre demandeurs plutôt qu’entre chaque demandeur et moi.

La capacité affichée à côté. « Le trimestre contient environ huit semaines de développement. Voici où tombe la ligne. » Tout ce qui est en dessous ne sera pas fait — ce n’est pas une menace, c’est une soustraction.

Quand une nouvelle demande arrive, la question devient : au-dessus ou en dessous de quoi ? Ajouter quelque chose oblige à déclasser autre chose, et ce déclassement est visible par tout le monde.

Photo : Verne Ho — licence CC0.

Ce que je fais quand deux directions s’opposent

Ça arrive, et ce n’est pas à moi de trancher. Mon rôle est de rendre l’arbitrage possible, pas de le confisquer.

Je prépare une note d’une page : les deux demandes, ce que chacune apporte, ce que coûte le report de l’autre, et ma recommandation avec ses raisons. Puis je demande une décision à qui de droit.

Deux effets. La décision se prend, parce qu’elle est posée clairement. Et elle est assumée par quelqu’un qui a l’autorité pour la porter — ce qui évite qu’elle soit rediscutée trois semaines plus tard.

L’urgence fabriquée

Il existe une catégorie de demandes urgentes dont l’urgence vient uniquement du fait qu’elles ont été demandées tard.

Je les traite comme les autres. Céder une fois enseigne à toute l’organisation que le meilleur moyen d’être prioritaire est de demander au dernier moment — et cette leçon est retenue très vite.

En revanche, je rends visible ce qu’a coûté l’insertion : « nous prenons cette demande, la fonctionnalité Y sort du trimestre ». Le coût doit être payé par quelqu’un, et il vaut mieux qu’il soit su.

Photo : domaine public (CC0).

Les demandes qui reviennent

Une même demande refusée trois fois mérite une attention particulière. Soit elle est effectivement importante et j’ai mal évalué, soit elle répond à un besoin réel exprimé de la mauvaise façon.

C’est souvent le second cas. Quelqu’un demande un bouton d’export parce qu’il n’arrive pas à retrouver une information ; le vrai besoin est un filtre, et il coûte trois fois moins cher.

Une demande qui insiste est un signal — pas forcément sur la solution demandée, presque toujours sur l’existence d’un problème.

Photo : rawpixel — licence CC0.

Le budget d’imprévu

Un backlog rempli à 100 % de la capacité est un backlog qui ne tiendra pas. Il y aura une anomalie bloquante, une demande réglementaire, un client important à dépanner.

Je réserve donc systématiquement 20 % de la capacité pour l’imprévu. Si rien ne survient — c’est rare — la marge sert à traiter des sujets de fond qui n’ont jamais leur tour : dette technique, ergonomie, documentation.

Ce budget a un effet secondaire précieux : quand une urgence tombe, elle ne fait plus sauter le plan. Je peux l’absorber sans rien déclasser, donc sans négociation. Cela retire beaucoup de tension à des moments qui en ont déjà.

Ce qu’on gagne à dire non clairement

J’ai longtemps cru qu’un refus flou ménageait les relations. C’est l’inverse.

« On verra plus tard » laisse le demandeur dans l’attente. Il relance, s’agace, et finit par penser qu’on ne l’écoute pas. « Ce n’est pas prévu ce trimestre, voici pourquoi, et voici ce qui passerait devant » est désagréable dix secondes, puis accepté.

Les demandeurs avec qui je travaille depuis longtemps ne me demandent plus si c’est urgent : ils m’expliquent d’emblée ce qui se passe s’ils ne l’ont pas. C’est le meilleur indicateur que la méthode a été comprise — et cela fait gagner un temps considérable à tout le monde.

Le tri qui précède la priorisation

Avant d’ordonner, j’écarte — et c’est souvent l’étape qui rapporte le plus.

Trois catégories sortent de la liste sans arbitrage. Ce qui n’a pas de demandeur identifié : une demande dont personne ne réclame le suivi depuis six mois n’existe plus. Ce qui a déjà été résolu autrement, par un contournement devenu la norme. Ce qui relève d’un autre outil, et qui a atterri là parce que c’était le seul endroit où déposer une demande.

Une liste de deux cents éléments passe couramment sous cent après ce tri. Et une liste plus courte se priorise, alors qu’une liste trop longue se contente d’exister.

Ce que je ne fais plus

Les scores de priorisation. J’ai utilisé des matrices valeur/effort avec des notes de 1 à 5. Le résultat était une fausse objectivité : les notes étaient discutées jusqu’à produire le classement souhaité. Une discussion honnête sur deux demandes vaut mieux qu’un tableau qui maquille le rapport de force.

Promettre un « après ». « On le fera au trimestre prochain » pour clore une conversation. Sauf engagement réel, c’est un report du conflit, avec des intérêts. Je préfère dire « ce n’est pas prévu », qui est désagréable sur le moment et honnête.

Prioriser seul. Un backlog ordonné par une seule personne est contesté en permanence. Le même backlog ordonné en trente minutes avec les demandeurs autour de la table tient tout le trimestre — parce que chacun a vu ce que l’autre défendait.

À lire aussi

Vous cherchez qui peut construire votre application ?

We IT conçoit, développe et exploite des applications web métier depuis 2022, à Lyon et partout en France. Cadrage, développement, mise en production et RUN.