Guides

Comment Mesurer la Productivite d'une Equipe de Developpement Remote sans Micromanagement

Par Marc Molas·3 août 2024·9 min de lecture

Si vous mesurez votre equipe de developpement remote par les heures de connexion ou les lignes de code ecrites, vous mesurez les mauvaises choses.

Je le dis par experience. J'ai vu des fondateurs installer des logiciels de surveillance, exiger des cameras allumees 8 heures par jour et s'obseser du statut vert de Slack. Le resultat est toujours le meme : les bons ingenieurs partent, ceux qui restent optimisent pour paraitre occupes, et le produit n'avance pas.

Mesurer la productivite d'une equipe remote est possible. Mais cela necessite de mesurer ce qui compte, pas ce qui est facile a compter.

Ce que vous ne devriez PAS mesurer

Avant de parler de ce qui fonctionne, eliminons ce qui ne fonctionne pas :

Heures en ligne : un ingenieur peut etre connecte 10 heures et produire moins qu'un autre qui travaille 6 heures avec du focus. Les heures mesurent la presence, pas la productivite.
Frappes clavier ou activite souris : si vous en arrivez la, vous avez un probleme de confiance, pas de productivite. Les logiciels de surveillance detruisent la motivation et la retention.
Lignes de code : un refactor qui supprime 500 lignes et simplifie l'architecture a plus de valeur que l'ajout de 2 000 lignes de code mal structure. Mesurer les lignes incite au gonflement.
Commits par jour : un commit atomique et bien pense vaut plus que 15 commits de "fix typo". Mesurer les commits incite a fragmenter le travail sans raison.

Toutes ces metriques partagent un probleme : elles sont faciles a manipuler. Quand vous mesurez les mauvaises choses, les gens optimisent pour la metrique, pas pour le resultat. C'est la loi de Goodhart en action : quand une mesure devient un objectif, elle cesse d'etre une bonne mesure.

Ce que vous DEVRIEZ mesurer : les metriques DORA adaptees

Les metriques DORA (DevOps Research and Assessment) sont le standard de l'industrie pour mesurer la performance des equipes d'ingenierie. Elles n'ont pas ete concues pour surveiller les individus, mais pour evaluer la sante de l'equipe et sa capacite de livraison.

Adaptees aux startups, elles sont au nombre de quatre :

1. Frequence de deploiement

A quelle frequence votre equipe deploie en production. Plus c'est frequent, plus le pipeline est sain, moins il y a de risque par deploiement, et plus l'equipe livre en continu au lieu d'accumuler les changements.

Si votre equipe deploie une fois par mois, chaque deploiement est un evenement a haut risque. Si elle deploie plusieurs fois par jour, chaque changement est petit, gerable et facile a annuler.

Reference pour les startups : au moins hebdomadaire. Idealement, plusieurs fois par semaine.

2. Lead time (delai de livraison des changements)

Du moment ou un developpeur fait un commit jusqu'a ce que le changement soit en production. Ce delai inclut la revue de code, le CI/CD, la QA et le deploiement. Plus il est court, meilleures sont les pratiques d'ingenierie.

Un lead time long indique generalement des goulots d'etranglement : des revues de code qui prennent des jours, des pipelines de CI lents, des processus de QA manuels, ou des approbations inutiles.

Reference pour les startups : moins de 2 jours pour les changements standards.

3. Taux d'echec des changements

Quel pourcentage des deploiements cause des incidents ou necessite un rollback. Un taux plus faible signifie une meilleure qualite de code, de meilleurs tests et des revues de code plus efficaces.

Si un deploiement sur trois casse quelque chose, votre equipe deploie vite mais sans qualite. La vitesse sans qualite n'est que de la vitesse pour creer des problemes.

Reference pour les startups : moins de 15 %.

4. Temps de retablissement

Quand quelque chose casse en production, combien de temps met votre equipe a retablir le service. Cette metrique mesure la capacite de reponse, pas la perfection. Les pannes vont arriver. Ce qui compte, c'est la vitesse de retablissement.

Reference pour les startups : moins de 4 heures pour les incidents critiques.

Indicateurs au niveau de l'equipe

Au-dela de DORA, il y a des metriques d'equipe qui vous donnent de la visibilite sur la sante operationnelle :

Cycle time des PRs : combien de temps s'ecoule entre l'ouverture d'une pull request et son merge. Si les PRs s'accumulent sans revue, vous avez un goulot d'etranglement.
Tendance de la velocite de sprint : pas le chiffre absolu (facile a gonfler), mais la tendance. Si la velocite baisse sprint apres sprint, quelque chose ne va pas. Si elle est stable, l'equipe est previsible.
Items bloques : combien de taches sont bloquees et depuis combien de temps. Des blocages prolonges indiquent des dependances non resolues ou un manque de communication.
Bug escape rate : combien de bugs arrivent en production vs. combien sont detectes en testing. Si le taux monte, la qualite du testing baisse.

Aucune de ces metriques ne necessite de surveiller qui que ce soit. Toutes s'extraient des outils que vous utilisez deja : GitHub, Jira, Linear, votre systeme de CI/CD.

Indicateurs individuels (a utiliser avec precaution)

Les metriques individuelles sont un terrain dangereux. Mal utilisees, elles creent une competition toxique et detruisent la collaboration. Mais utilisees avec discernement, elles aident a identifier ou un ingenieur a besoin de soutien ou ou il contribue plus qu'il n'y parait.

Qualite de la revue de PRs : pas combien de PRs il revoit, mais la profondeur de ses commentaires. Un ingenieur qui detecte des problemes d'architecture dans les revues apporte plus qu'il n'y parait.
Partage de connaissances : combien de PRs il revoit dans d'autres equipes ou modules. Les ingenieurs qui sortent de leur zone pour aider les autres multiplient la capacite de l'equipe.
Initiative sur les ameliorations : qui propose des ameliorations au pipeline, automatise des processus, ou documente des decisions techniques sans qu'on le lui demande.
Qualite de la communication : dans les equipes remote, la capacite a communiquer du contexte de maniere asynchrone est une competence critique. Un ingenieur qui ecrit des descriptions de PR claires, documente les decisions et communique les blocages proactivement fait gagner du temps a toute l'equipe.

La cle : ces metriques doivent alimenter des conversations de developpement professionnel, pas des classements ou des evaluations punitives.

L'equation de la confiance

Les metriques sont un outil. Mais le fondement de la productivite dans les equipes remote est la confiance. Et la confiance se construit avec des systemes, pas avec des intentions.

Gestion basee sur l'output : definissez clairement ce qui doit etre livre a chaque sprint. Evaluez sur la base du livre, pas sur le comment ou le quand du travail.

Standups asynchrones : au lieu d'une reunion quotidienne de 30 minutes ou la moitie de l'equipe ne prete pas attention, un message ecrit avec trois points : ce que j'ai fait hier, ce que je ferai aujourd'hui, ce qui me bloque. Chacun l'ecrit quand il commence sa journee.

Demos hebdomadaires : une fois par semaine, l'equipe montre ce qu'elle a construit. Pas de slides, pas de presentations. Du code qui fonctionne. Cela cree de l'accountability sans micromanagement.

Suivi par jalons : au lieu de controler le quotidien, definissez des jalons clairs avec des dates et faites le suivi au niveau du jalon. Si l'equipe atteint les jalons, les details du quotidien sont sans importance.

Les anti-patterns qui detruisent les equipes remote

Si vous faites l'une de ces choses, arretez-vous et reconsiderez :

Logiciels de surveillance : captures d'ecran, tracking de frappes, enregistrement d'activite. Rien ne dit "je ne vous fais pas confiance" plus clairement. Les ingenieurs senior qui decouvrent ca sur leur machine chercheront immediatement un autre emploi.
Cameras obligatoirement allumees : un appel video de 30 minutes avec camera est raisonnable. 8 heures de camera allumee, c'est de la surveillance deguisee en "culture d'equipe".
"Activity scores" : toute metrique qui note l'activite d'un ingenieur sur la base de sa presence en ligne est inutile comme mesure de productivite et destructrice pour le moral.
Verifier le statut Slack : si votre premier reflexe en voyant quelqu'un "absent" sur Slack est de remettre en question son engagement, le probleme c'est vous, pas l'ingenieur.

Les meilleurs ingenieurs produisent davantage dans un environnement de confiance et d'autonomie que dans un environnement de controle et de surveillance. Ce n'est pas une opinion, c'est ce que montrent systematiquement les donnees de la recherche DORA et State of DevOps.

Comment nous travaillons avec les equipes distribuees

Chez Conectia, nos ingenieurs s'integrent directement dans vos processus et vos rythmes de travail. Ils utilisent votre stack, suivent votre methodologie de sprints, participent a vos ceremonies d'equipe et repondent a vos standards de qualite.

Nous n'imposons pas de processus paralleles ni de rapports separes. Ce que nous faisons, c'est un suivi continu de satisfaction et de livraison lors de check-ins tous les 90 jours, avec l'ingenieur comme avec votre equipe. Si quelque chose ne fonctionne pas, nous le detectons tot et nous le corrigeons.

Le resultat : vous avez un ingenieur senior qui fait vraiment partie de votre equipe, avec l'autonomie pour produire et les mecanismes de feedback pour garantir que la livraison est constante. Sans logiciel de surveillance. Sans micromanagement. Avec des metriques qui comptent.

Vous voulez integrer des ingenieurs remote qui livrent sans surveillance constante ? Parlez a un CTO -- nous integrons des ingenieurs senior d'Amerique latine qui travaillent avec vos processus et vos standards de qualite.