Comment Google débloque et mesure la productivité des développeurs

La période de croissance rapide est suspendue, obligeant les équipes d’ingénierie à tenter de faire plus avec moins. Le géant de la technologie Google n’y échappe pas après avoir licencié 6 % de ses effectifs en janvier dernier. Et où que vous soyez, les budgets clients plus serrés entraînent une demande accrue pour publier plus rapidement des fonctionnalités différenciantes.

Libérer la productivité pour l’une des dépenses les plus importantes du développement logiciel – les humains qui le réalisent – ​​est plus important que jamais.

La recherche sur la productivité des développeurs mesure la capacité d’un ingénieur à produire une certaine quantité de travail dans un temps donné. Cette discipline étudie non seulement le résultat final mais aussi les facteurs socio-techniques qui l’influencent. De plus en plus, il tente également de mesurer l’expérience des développeurs, car il est prouvé que DevEx stimule la productivité.

Après tout, le développement de logiciels est avant tout un travail créatif, ce qui signifie que tout effort visant à améliorer la productivité des développeurs doit se concentrer à la fois sur l’interaction homme-ordinateur et homme-homme entre les personnes, les processus et la technologie. Ce qui est plus difficile que vous ne le pensez, car l’expérience humaine est rarement à choix multiples.

La recherche sur la productivité des développeurs est également un sujet naissant, car l’expérience des développeurs en général a tendance à être difficile à mesurer.

Dans un épisode récent du podcast Engineering Enablement, l’animateur Abi Noda a interviewé Ciera Jaspan et Collin Green, qui dirigent ensemble l’équipe de recherche sur la productivité en ingénierie chez Google. Chez Google, la productivité de l’ingénierie de dizaines de milliers d’ingénieurs se résume à « fournir une ingénierie sans friction et d’excellents produits ».

Dans cet article, nous réfléchissons aux dernières recherches et leçons des ingénieurs, des chercheurs en expérience utilisateur (UX) et des psychologues qui cherchent à mesurer et à améliorer l’expérience et la productivité des développeurs chez Google.

La configuration : qui fait partie de l’équipe ?

L’équipe de productivité d’ingénierie de Google compte environ 2 000 ingénieurs, principalement chargés de rendre les outils et processus de développement plus efficaces. À l’intérieur, il y a une équipe beaucoup plus petite qui se concentre sur la recherche sur la productivité en ingénierie – pas nécessairement sur le comment, mais plutôt sur le pourquoi, le quand, le quoi et le combien.

C’est une équipe à méthodes mixtes qui effectue des recherches à la fois quantitatives et qualitatives. Il s’agit également d’une équipe mixte d’environ moitié ingénieurs et moitié chercheurs en expérience utilisateur, avec des personnes qui ont déjà travaillé comme économistes du comportement, psychologues sociaux, psychologues industriels-organisationnels et même quelqu’un de la santé publique.

Selon Jaspan, la formation en sciences sociales fournit le contexte nécessaire. L’analyse des journaux – un point de départ courant pour la recherche sur la productivité des développeurs – ne fournit qu’une partie du tableau. « Cela vous indique ce que font les développeurs. Mais ça ne vous dit pas pourquoi ils font ça. Cela ne vous dit pas ce qu’ils en pensent, [or] si ce qu’ils font est bon ou mauvais. Cela ne vous dit pas s’il y a place à amélioration. Cela vous donne seulement un chiffre, mais vous ne pouvez pas interpréter ce chiffre », a-t-elle déclaré sur le podcast. « À moins que vous n’ayez plus de côté qualitatif du monde, et que vous compreniez les comportements et comment ces comportements changent avec le temps, en fonction de la façon dont vous changez le contexte. »

C’est pourquoi l’équipe de recherche en productivité a embauché son premier chercheur UX il y a environ cinq ans pour l’aider à concevoir de meilleures enquêtes. Ensuite, en associant les spécialistes UX à des ingénieurs, ils sont en mesure d’optimiser non seulement ce qu’ils demandaient, mais aussi le quand et le comment. Par exemple, ce couplage a permis l’échantillonnage d’expérience, intégrant des enquêtes au moment où les développeurs exécutent une build. Les ingénieurs peuvent contribuer à fournir à la fois une expérience directe et des solutions techniques qui font évoluer la recherche UX.

« L’accès direct à des experts en la matière qui y sont profondément ancrés et qui sont au sommet de leur domaine est une augmentation vraiment puissante à avoir dans ce carquois de flèches qu’est les méthodes de recherche comportementale », a déclaré Green. « L’expertise du domaine, l’évolutivité et les compétences techniques du côté de l’ingénierie, combinées à la grande variété de méthodes de recherche comportementale et à une installation prenant en compte des éléments tels que les préjugés, la façon dont les gens travaillent et ce qu’il faut surveiller dans les réponses aux enquêtes ou des entretiens », des spécialistes des sciences sociales se combinent pour la recherche UX d’une manière qui peut être unique à Google. Les gens de l’UX ont découvert un biais de non-réponse et les ingénieurs ont découvert des bogues en amont parce que les choses n’allaient tout simplement pas bien.

La productivité des développeurs est un objectif à l’échelle de l’organisation

Le premier client de cette équipe est l’équipe de développeurs propriétaires qui crée les outils de développement pour l’ensemble de l’organisation. L’objectif est de les aider à améliorer les outils d’infrastructure, les processus et les meilleures pratiques.

« Lorsqu’ils souhaitent, par exemple, comprendre ce qui rend les développeurs productifs et ce qui pourrait les rendre plus productifs, nos données [and] nos recherches sont l’un des endroits où ils vont pour comprendre comment mesurer cela », a déclaré Green.

L’équipe de recherche sur la productivité collabore également avec d’autres équipes, y compris les opérations, l’immobilier et les espaces de travail, l’ingénierie d’entreprise – qui créent des outils pour tous les Googleurs, pas seulement les ingénieurs – et d’autres équipes qui peuvent affecter l’expérience globale des développeurs. Et puis, bien sûr, les enseignements tirés de la productivité des développeurs pourraient profiter à d’autres équipes non techniques. Tant que la communication inter-entreprises s’ensuit.

« Ainsi, lorsque vous vous concentrez sur la productivité de l’ingénierie, vous vous concentrez sur une grande partie de la population de Google et il y a donc un grand intérêt pour ce que nous trouvons », a déclaré Green.

L’équipe de productivité d’ingénierie de Google sert également d’intermédiaire entre les différentes équipes de développement. Comme Jaspan l’a dit : « L’entreprise est vraiment grande. Les gens font différents types de développement. Les personnes qui construisent les outils peuvent ne pas connaître tous les différents types de travail en cours. »

Tout cela constitue ce que Green appelle un « terrain de jeu de données bien formées » associé à des ingénieurs qui ont une réelle expérience des problèmes à résoudre.

La rapidité, la facilité et la qualité stimulent la productivité

Alors, si vous aviez le budget d’ingénierie de Google, que mesureriez-vous ?

Avec l’essor de l’ingénierie des plates-formes et la consolidation des outils inter-organisationnels, il est devenu plus facile de suivre l’expérience des développeurs techniques. Ce qui reste un défi, c’est l’effet de cette technologie sur ses utilisateurs humains et l’effet des personnes et des processus autour de cette expérience. Aucune mesure ne pourrait à elle seule permettre de saisir cela.

L’équipe de recherche sur la productivité des développeurs, a déclaré Jaspan, défend une philosophie : il n’y a pas de métrique unique qui vous permettra d’obtenir la productivité des développeurs. À partir de là, a-t-elle expliqué, l’équipe triangule selon trois axes qui se croisent :

Par exemple, Green a proposé une fois – ironiquement, pour faire valoir un point – que le moyen le plus rapide d’améliorer la productivité serait de supprimer les revues de code – ce à quoi tout le monde a bien sûr résisté car, même si cela augmenterait la vitesse et la facilité de publication, il ‘ d diminuer la qualité. Et les recherches de l’équipe ont prouvé que la qualité du code améliore la productivité des développeurs.

Pour la vitesse, ils mesurent les journaux, mais ils mesurent également la perception des ingénieurs de la vitesse à laquelle ils pensent qu’ils vont, ainsi que des études de journaux et des entretiens. Jaspan a déclaré : « Il s’agit à la fois d’utiliser plusieurs mesures, mais également de s’assurer qu’elles sont validées les unes par rapport aux autres. »

La recherche à méthodes mixtes valide les données

Pour avoir une étude plus approfondie du comportement de développement de logiciels de Google, l’équipe a réalisé une étude de journaux multi-outils, en ingérant les journaux de plusieurs outils de développement. Ils ont également réalisé une étude de journal dans laquelle, toutes les quelques minutes, les ingénieurs écrivaient ce qu’ils faisaient. Ils ont comparé les deux afin de créer la confiance dans les journaux de données. Étant donné que chaque ingénieur travaille et perçoit son travail différemment, cela peut devenir une situation de pommes et d’oranges, alors ils appliquent ce qu’on appelle la fiabilité interévaluateur pour calculer l’accord entre les deux études.

« Nous supposons qu’il existe une vérité là-bas que nous ne pouvons pas observer directement sans être assis à côté du développeur et probablement le déranger », a déclaré Green. « Et donc nous prenons ces deux sources et nous disons : ces deux lentilles nous parlent-elles du même monde ? »

L’étude du journal de données peut être effectuée à grande échelle de manière passive, sans avoir à déranger les ingénieurs, tandis que les études de journal ne peuvent être effectuées que par 50 ingénieurs à la fois – et cela peut devenir ennuyeux.

« Une fois que nous avons en quelque sorte trouvé de bonnes preuves que nous obtenons les mêmes informations des deux sources, nous pouvons alors nous pencher sur la méthode évolutive », a-t-il expliqué.

Dette technique et enquête de satisfaction des ingénieurs

Depuis 2018, un autre outil de mesure puissant chez Google est l’enquête trimestrielle sur la satisfaction de l’ingénierie, qui touche environ un tiers de la force d’ingénierie à la fois. Green a admis qu’au début les dirigeants étaient réticents à l’égard de cette mesure parce qu’il s’agissait « simplement de l’opinion des gens ». Pendant les fermetures pandémiques de 2020, l’enquête a d’abord révélé une légère augmentation de la productivité, suivie d’une forte baisse le trimestre suivant, alors que le temps à la maison se poursuivait souvent seul.

Il est prouvé que la dette technique affecte négativement le moral des développeurs et réduit la vitesse de développement. Il n’est donc pas surprenant que, dès le début, l’enquête comportait deux questions sur l’impact de la dette technique sur la productivité :

• Quelles sont les causes sous-jacentes de la dette technique que vous rencontrez ?
• Quelles mesures d’atténuation seraient appropriées pour remédier à cette dette technique ?

Au fil des ans, en réponse, l’équipe de Jaspan et Green a combiné les réponses jusqu’à ce qu’ils se soient mis d’accord sur 10 catégories de dette technique qui pourraient entraver la productivité de l’ingénierie :

• La migration est nécessaire ou en cours.
• La documentation sur le projet et/ou les API est difficile à trouver, manquante ou incomplète.
• Mauvaise qualité ou couverture des tests.
• La qualité du code n’est pas bien conçue.
• Le code mort et/ou abandonné n’a pas été supprimé.
• La base de code s’est dégradée ou n’a pas suivi l’évolution des normes.
• Une équipe manque de l’expertise nécessaire.
• Les dépendances sont instables, évoluent rapidement ou déclenchent des restaurations.
• La migration a été mal exécutée ou abandonnée, ce qui a peut-être entraîné le maintien de deux versions.
• Le processus de publication doit être mis à jour, migré ou maintenu.

Les ingénieurs peuvent choisir une ou toutes les options. Les données qui en résultent ont révélé différentes interventions de dette technique nécessaires pour différents publics, comme les ingénieurs en apprentissage automatique par rapport aux ingénieurs backend. Ils découpent également les données selon des critères organisationnels pour montrer et comparer les progrès accomplis dans la conquête de cette dette.

L’article sur cette question de la dette technique reconnaît que les mesures basées sur des enquêtes sont un indicateur retardé – cela n’apparaît comme un véritable problème que lorsque cette dette technique est devenue suffisamment grave pour gêner les ingénieurs. Cependant, après avoir exploré 117 indicateurs, l’équipe de Google doit encore identifier et prédire quand la dette technique entravera bientôt la productivité.

Ils ont également ajouté quatre questions sur la manière dont les équipes gèrent la dette, dans un souci d’amélioration continue.

À mesure que cette enquête devenait de plus en plus importante pour l’organisation dans son ensemble, les vice-présidents de l’ingénierie ont commencé à poser leurs propres questions. Cela a été utile pendant un certain temps, mais l’enquête a ensuite dû être rationalisée. Désormais, un chercheur UX différent est en charge de l’enquête chaque trimestre avec le soutien d’un ingénieur différent, parallèlement aux retours d’équipe. Green a admis que l’enquête était encore assez « lourde ».

Quelle que soit la taille (et le budget) de votre organisation, nous vous encourageons à investir dans un mélange de recherche automatisée et mesurable, d’observation et d’expérience pour comprendre votre expérience de développeur et la productivité qu’elle soutient ou entrave.

N’oubliez pas que les métriques changeront au fur et à mesure que vos équipes et votre code changeront. Comme l’a dit Jaspan, « Nous savons qu’il n’y a pas une seule métrique pour la productivité des développeurs, nous essayons donc d’utiliser toutes ces différentes méthodes de recherche pour voir : sont-elles toutes alignées ? Nous disent-ils que la même chose se produit ? Ou sont-ils mal alignés ? Dans ce cas, nous devons creuser plus profondément pour comprendre ce qui se passe.