Dans une start-up que je conseille, les tâches déposées par les PMs pour les ingénieurs à mettre en œuvre avaient une hiérarchisation faible / moyenne / élevée.
Comme il s’agit d’une start-up en phase de démarrage, il y a toujours plus de travail à faire que de temps ou de personnes, donc les ingénieurs n’ont jamais eu le temps de faire des tâches faibles ou moyennes.
PMs a donc cessé de classer les tâches de priorité faible et moyenne.
Maintenant, toutes les tâches sont hautement prioritaires. Les priorités sont donc communiquées de manière informelle: « Oui, les deux sont hautement prioritaires, mais X vient avant Y ». Ce qui conduit naturellement à des désaccords: » Pourquoi n’as-tu pas fini un ? »Parce que je travaillais sur B. » Mais A est une priorité plus élevée. »Non, ils ont la même priorité de haut. »
Ce qui est intéressant, c’est que cela ne s’est pas produit parce qu’un côté a subverti le système. Au contraire, les deux parties faisaient ce qu’elles étaient censées faire dans le cadre du système. Les ingénieurs abandonnant les tâches faibles et moyennes avaient du sens car le but de la hiérarchisation est de dire ce qui peut être abandonné alors qu’elles ne peuvent pas toutes être faites. La décision du PM de ne déposer que des tâches hautement prioritaires était à nouveau logique, car à quoi bon classer des tâches qui ne seront pas effectuées, de toute façon? Cela ne fait que perdre du temps à toutes les personnes impliquées. Classez-le comme élevé ou ne le faites pas.
Donc le système est tombé en panne.
Quelles sont les alternatives?
Une méthode de hiérarchisation qui fonctionne consiste à définir des priorités objectivement. Chez Google, par exemple, P0 signifiait une urgence de production: arrêtez ce que vous faites et travaillez dessus. Il n’est pas déraisonnable que les gens soient paginés pour réparer un P0, réveillé au milieu de la nuit. P1 signifiait une tâche exceptionnellement prioritaire – vous n’avez pas besoin d’arrêter ce que vous faites pour travailler sur le P1 (ce n’est pas un P0), mais lorsque vous avez terminé ce que vous faites, vous devez travailler sur le P1. P2 a été utilisé pour la plupart des tâches. Et P3 et P4 ne se feraient jamais.
Ce système a fonctionné parce que les priorités étaient objectivement définies et largement comprises, afin que les gens puissent repousser et définir la bonne priorité: « Non, ce n’est pas un P0 — ce n’est pas une urgence de production » ou « Non, ce n’est pas un P1 — oui, c’est important, mais cela ne prime pas sur tout le travail que nous avons. »Alors qu’avec faible / moyen / élevé, une tâche particulière est-elle moyenne ou élevée? C’est une question d’opinion. Cela peut signifier n’importe quoi, provoquant la panne du système.
Une deuxième méthode de hiérarchisation qui fonctionne consiste pour le PM à définir un cycle ou un sprint consistant en une liste définie de tâches à effectuer dans un laps de temps convenu. Si une tâche est incluse dans le cycle en cours, cela signifie qu’elle doit être effectuée ce cycle, donc la priorité est moins pertinente.
Une troisième méthode de hiérarchisation qui fonctionne consiste pour le PM à définir une liste de tâches hiérarchisées. Une liste numérotée où le 1er est plus important que le 2e, qui est plus important que le troisième, et ainsi de suite. Cela a encore du sens. En fin de compte, ce qui compte, c’est de savoir si un ingénieur doit effectuer la tâche X ou Y, alors qu’il n’y a pas le temps de faire les deux. Pas si X est moyen dans un sens absolu, ce qui n’a aucun sens de toute façon.
Dans tous les cas, n’utilisez pas une hiérarchisation faible / moyenne / élevée. Utilisez quelque chose comme Trello où vous faites glisser les tâches vers le haut ou vers le bas pour définir une priorité implicite.
Cela fonctionne particulièrement bien si la liste comprend un objectif de haut niveau, comme lancer la fonctionnalité X. Cela donne aux gens l’appropriation et les motive.
Bien sûr, tout cela suppose que vous avez un SPm compétent et bien intentionné. J’ai travaillé avec des PMS de second ordre qui essaient d’entasser autant de tâches que possible dans un cycle, et sont ensuite en colère lorsque les choses sont plus longues que prévu. Ils ne peuvent pas établir de priorités. Ils veulent tout. Ou ils ne comprennent pas le compromis fondamental dans la gestion de projet, à savoir le compromis entre le temps, la portée et la qualité.
Ou ils comprennent tout ce qui précède mais l’utilisent pour manipuler les ingénieurs pour en tirer plus de travail. Cela ne fonctionne pas longtemps — j’ai cessé de donner des informations pertinentes au Premier ministre, car il en profiterait généralement pour me critiquer. Je négligerais tout ce qu’il dit. Quand il avait un désaccord avec quelqu’un d’autre dans l’équipe, je commençais par supposer que l’autre personne avait raison.
Si vous avez des PMS de second ordre ou mal intentionnés, aucune méthode de hiérarchisation ne fonctionnera bien.
Il est intéressant de noter que les outils de suivi des bogues conçus pour les ingénieurs ne fonctionnent pas aussi bien que les outils de suivi des tâches conçus pour tout type de tâche. Cela est probablement dû au parti pris des ingénieurs de simplement mettre une interface utilisateur au-dessus d’une base de données. Mais les humains ne pensent pas comme une base de données. Une métaphore du monde réel comme un tas de cartes disposées et triées sur un bureau peut être un meilleur modèle.