Pendant longtemps, ma stratégie de priorisation tenait en une phrase : tout faire, le plus vite possible. C’est impossible et épuisant. Surtout, ça ne maximise pas l’impact.
Puis je suis tombé sur une vidéo d’un ingénieur L8, l’un des niveaux les plus élevés de l’échelle des Big Tech. Il y explique comment il priorise son travail. Son framework tient en une formule, assez simple pour être appliquée dans une feuille de calcul, assez puissante pour changer ta façon de choisir ta prochaine tâche.
Avant de l’expliquer, le mieux est de le manipuler. Voici le framework, appliqué à l’exemple de la vidéo (une application de vidéos d’animaux avec 10 000 utilisateurs quotidiens) :
La formule : Impact × Confiance ÷ Coût
Chaque projet ou tâche est évalué sur trois dimensions, chacune notée simplement S, M ou L :
L’impact : la valeur créée si le projet réussit. Ici, elle est mesurée en nouveaux utilisateurs quotidiens, mais ça peut être du revenu, du temps gagné ou des bugs évités.
La confiance : la probabilité que le projet atteigne réellement cet impact. C’est la dimension que tout le monde oublie. Un projet spectaculaire avec 10 % de chances de réussir vaut moins qu’un projet moyen quasi certain d’aboutir.
Le coût : le temps de travail nécessaire, en jours.
La priorité, c’est l’impact multiplié par la confiance, divisé par le coût. Autrement dit : la valeur espérée par jour investi.
Ce que la formule révèle
Ouvre Priority Matrix et regarde le classement. Le projet le plus « sexy » consiste à améliorer l’algorithme de recommandation. Malgré son gros impact et sa haute confiance, il n’est pas le premier à faire. Le partage de vidéos gagne largement, parce qu’il promet le même impact pour un coût quatre fois moindre, même avec une confiance moyenne.
Et les effets de réalité augmentée, le genre de projet dont tout le monde parle en réunion, finissent bons derniers : gros impact espéré, mais faible confiance et coût maximal.
C’est exactement l’inverse de mon réflexe naturel. Quand on veut tout faire vite, on attaque ce qui est devant nous, ou ce qui brille. La formule force à regarder le rapport entre la valeur espérée et le temps investi. Ce rapport est rarement là où on le croit.
Pourquoi ça change tout pour un développeur en mission
Si tu es développeur Angular en ESN, tu ne choisis pas toujours tes tickets. Mais tu choisis constamment : quel bug traiter en premier, quelle dette technique attaquer, quel refactoring proposer, quelle compétence développer ce trimestre.
Sans framework, ces choix se font au feeling, souvent en faveur de la tâche la plus visible ou la plus urgente en apparence. Avec ce framework, tu peux poser trois questions simples avant de t’engager : quelle valeur si ça réussit ? Quelle probabilité que ça réussisse ? Combien de jours ça coûte ?
Tu n’as même pas besoin de chiffres précis. Des ordres de grandeur S/M/L suffisent pour faire émerger des écarts de priorité de 1 à 20, comme dans l’exemple ci-dessus. Et c’est aussi un excellent outil pour défendre tes choix : dire « je commence par ça parce que le rapport valeur/coût est meilleur » est autrement plus crédible que « ça me semblait plus important ».
Newsletter Codeur Senior
Passez de l'exécution au produit.
Recevez les prochaines analyses pour sortir de la régie, piloter des agents sous vos standards et construire une preuve qu'une boîte produit peut évaluer.
Le vrai changement de posture
La leçon que je retiens dépasse la formule : se concentrer sur moins de tâches, mieux choisies, produit plus d’impact que de tout faire vite. La vitesse d’exécution est une compétence de junior. Le choix de ce qu’on exécute est une compétence de senior.