Il y a quelques mois, j’ai suggéré sur Twitter l’idée de faire un billet pour dénoncer les fausses-bonnes idées en matière de métriques pour suivre l’activité d’un développeur.

Hasard du calendrier, le confinement a pu tenter certains emm… – pardon, je reformule – certaines personnes stressées par le contrôle peuvent vouloir suivre l’activité d’un développeur.

Qu’on soit clair, je comprends le besoin… non pas de contrôle bête, mais de suivi. Le suivi est utile. Pour pouvoir planifier, intercaler, gérer d’autres personnes. C’est légitime. Le contrôle bête et méchant l’est sûrement beaucoup moins.

Et dans notre Startuffe Nation, on peut se poser la question d’une métrique magique pouvant quantifier l’activité d’un développeur. En clair, il y a les bonnes et les mauvaises façons de le faire. Commençons par… les mauvaises.

Idée débile numéro 1 : au poids !

Afin de rester poli, j’évacue de suite l’angle « Le dev est là pour pisser des lignes de code ». C’est idiot. Si vous considérez vos dévs ainsi, ne vous fatiguez pas avec de l’humain. Et si d’aventure, vous aviez quelqu’un correspondant à ce profil, gare ! Certes, certaines tâches sont répétitives et/ou reviennent entre divers projets. Mais cela veut peut-être dire que votre organisation paie des gens pour faire du travail de robot. Autrement dit, si c’est le cas, cela peut tuer leur créativité, et donc leur capacité à résoudre vos problèmes. Ou alors, vous avez embauché quelqu’un de pas bon.

Hein, je te regarde, toi, chef de projet/directeur/dev qui clame un « on a toujours fait comme ça, on n’a aucune raison de changer ». C’est bien connu, le Web est réputé pour être quelque chose d’immuable, et tous les projets/contextes sont exactement les mêmes ! (sarcasmes inside)

Revenons au poids, et prenons un petit exemple. Si je regarde la PR qui fait passer ProtonMail de sa v3 à la v4 en cours de conception, nous avons réussi quelque chose d’extraordinaire.

Si on paie au poids, nous avons réussi l’exploit de produire une nouvelle version, et les devs paieront pour cela, vu que le code a diminué de manière drastique ! Je passe les chiffres en détail, mais le dégraissage du mammouth a été violent.

Plus sérieusement, on voit bien que cette métrique n’a pas de sens. Une refonte peut être l’occasion de dégager du vieux code moisi ou des parties devenues inutiles.

Idée débile numéro 2 : au commit !

Regardons le contribution graph de react-components, un projet de composants React faits chez ProtonMail (en gros, des trucs partagés dont on se sert sur tous les projets). Quelque chose vous surprend ? (vous pouvez cliquer pour agrandir)

Je suis 3e, moi, le spécialiste CSS de la boite !! Seuls deux devs me dépassent au nombre de commits, et je suis devant 5 autres devs JS. Qu’on me donne une augmentation de suite !!!

Sauf que… il est possible, je dis bien possible, que j’aie été très légèrement malhonnête en présentant cela. Déjà… il ne faut pas croire tout ce qu’on lit sur Internet, et aller à la source.

Déjà, on voit le rapport de grandeur est très relatif vu le nombre d’ajouts/suppressions. Et cela n’a aucun sens de comparer des choux et des carottes. En l’occurrence, il est aisé de voir que j’opère moins de modifications, et si on creuse un peu, mon job consiste à ajouter des classes, modifier quelques bricoles sur les composants. En outre :

• Les 4e, 5e et 6e modifient bien plus de choses que moi et c’est normal, c’est leur job de faire du JavaScript !
• Cela ne rend également pas compte de l’activité réelle d’autres, qui travaillent plus sur d’autres projets, sont amenés à opérer sur d’autres aspects, etc.

Bref, pour tuer cette idée, j’ajouterai que j’ai même déjà entendu des devs démotivés se sachant surveillés ainsi… multiplier les commits pour chaque virgule ou point-virgule changé. À bon entendeur.

Idée débile numéro 3 : au temps !

Si on regarde bêtement le changement dans la PR : « Punaise, il lui a fallu 4H pour changer deux classes dans les templates de l’app ? Il fait quoi le dev UI, il se fait bronzer les doigts de pied ? »

C’est possible que le dev UI se fasse bronzer oui. Mais ce qui est possible aussi :

• c’est qu’il ait galéré à trouver le maillon qui foire dans un projet complexe avec des abstractions de malade ;
• qu’il ait été dérangé entre temps ou demandé sur d’autres trucs ;
• que le souci ait été particulièrement dur à reproduire ;
• ou que la sacro-sainte solution soit éclatée sur 4 projets avec 20 contextes, la rendant particulièrement délicate ;
• ou qu’il soit parti sur une autre piste, et qu’après 20 tentatives, 2 crises de nerfs, 4 arbitrages, un npm i et une crucifixion, le problème ait été réglé différemment (genre le lendemain, un éclair de génie, paf, problème réglé).

Le temps est quelque chose d’impossible à estimer. J’ai plus de 15 ans de métier, et je me gourre encore lourdement sur mes estimations, parce que quantifier l’imprévu ou l’inconnu est tout sauf une science exacte.

Encore ces derniers jours, j’ai estimé deux demandes en mode « oui ça c’est simple, une demi-journée max tout compris », et sans pêcher par orgueil, ça me semblait vraiment simple. Sauf que non : effets de bord, soucis divers imprévisibles. 2 jours de taf.

Et par pitié, ne confondez pas durée et délai. Un jour de taf, si on est sur plusieurs projets, ça peut s’étaler sur plusieurs jours. Allez, je passe sur toutes les autres idées complètement débiles.

De meilleures métriques

Désolé de ce truisme (j’adore placer ce mot), mais faire confiance à vos devs, ça fera partir tout le monde sur de bonnes bases.

Si vos devs disent que c’est compliqué de développer, c’est que ça l’est. Et s’ils disent qu’estimer est difficile/impossible, c’est que ça l’est vraiment. Si on le dit tous, c’est pas un complot des francs-développeurs dans le monde, c’est que c’est vrai.

Voici quelques pistes :

• De la valeur business est-elle produite dans le temps sur un même produit (je cite une réponse très juste) ?
• Les clients sont-ils contents ?
• Est-ce que votre dev est apprécié des autres humainement ?
• Est-ce que son travail facilite celui des autres ?
• Maîtrise-t-il sa partie ?
• Est-ce que les tâches sont expédiées et résolues ?
• Est-ce qu’au long cours, son travail permet de continuer à garder la vélocité de l’équipe, ou est-ce que cela devient de plus en plus dur ?
• Est-ce que sa partie facilite des évolutions non prévues initialement ?
• Etc.

Certes, tout cela est plus difficile à quantifier via une formule magique. Surtout sur des mastodontes que personne ne maitrise.
Ceci dit, avec de la confiance et surtout des ambiances saines, cela se construit.

Après, cela ne veut pas dire que les estimations sont à jeter, mais il faut les considérer comme ce qu’elles sont : des approximations. Cela peut donner une idée – imprécise – de la charge de travail.

Pas plus tard qu’il y a 3 jours, j’ai entendu un Product Owner dire « je me fous de l’exactitude des estimations, tout ce que je veux, c’est avoir une idée de la quantité de boulot, et voir qu’on avance. Et si un jour, la boîte commençait à avoir des lemmings qui n’ont d’autres boulots que de surveiller ça, vous vous barrerez vite car la boite sera devenue merdique ». Tout est dit.

Mais pour conclure : comptez le coût induit par la mise en place d’outils pour gérer la non-confiance, que ce soit en humain, temps, argent, processus, bien-être… et comptez le coût de la confiance. C’est peut-être délirant, mais croyez que la balance est nettement en faveur de cette dernière, sans compter les effets bénéfiques induits.