Des métriques pour suivre l’activité d’un dev ?

Des métriques pour suivre l’activité d’un dev ? (le 11/05/2020)

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.

Les mauvaises métriques, parce que c’est NOTRE PROJET

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.

v3 à v4, 50000 ajouts et 3 fois plus de suppressions

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)

Contribution Graph version 1…

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.

Contribution Graph, la vraie version, nous sachons

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.

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1714

3 commentaires

Posté par Superbiche le 11/05/2020 à 19:45:37
Excellent billet Nicolas !
Très bons exemples, et surtout j'adooore la citation du PO à la fin.
C'est exactement ce qu'on essaie de faire dans notre équipe : avoir une idée du travail, faire confiance dans l'autonomie et le professionnalisme (voire la passion) des devs.
Bon, je suis dev/patron (dans cet ordre), mais on en a vu partir en vrille à l'occasion, donc c'est bon de se rappeler ce qui nous donne à tous du plaisir dans ce métier

Je rajouterai juste une chose importante : la communication. Pas de faire un rapport bi-horaire de l'avancement, mais un petit ping quotidien, à la manière du daily ("OK je démarre sur ça aujourd'hui", et le soir si c'est bouclé "demain je pense bosser sur ça, ça devrait me prendre 2 jours, sauf si y'a plus urgent").
Bref, la confiance, et surtout, laisser la créativité s'exprimer.

Merci encore pour ce super post, super inspirant pour écrire les premiers billets sur des thématiques assez proches de notre futur blog (clin d’oeil) (promis on met un lien dans les références)
Posté par sepecat le 13/05/2020 à 8:37:24
J'aime... le ton humoristique, la réalité du propos, le sens du vécu.
J'aime pas... bin rien en fait.
Un billet comme on aimerait en lire plus souvent.
Posté par Grean le 04/07/2020 à 4:23:28
Bonjour
Pour ma part en freelance j'aimerais bien en avoir des métriques, car c'est difficile de s'auto évaluer lorsqu'un projet est long par exemple ; en équipe je conçois le paramètre inter humain mais lorsqu'on n'a de compte à rendre qu'à soit-même... j'en suis encore aux commits, bien renseignés -souvent- et avec une doc évolutive suivie avec, en fin de projet c'est déjà une première base.

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.