La productivité des développeurs est vraiment une question d'autonomisation

Devenez, à votre échelle, acteur du changement ?

Vos idées nous intéressent, votre opinion nous importe et votre point de vue est essentiel.

Proposez votre contenu

La productivité des développeurs est vraiment une question d'autonomisation

29 juillet 2022

Ces derniers temps, de nombreuses organisations m'ont fait part de leur désir d'accroître la productivité de leurs équipes de développeurs. Chaque entreprise est désormais une entreprise de logiciels et il est clair que le secteur manque de développeurs et de technologues talentueux capables d'aider les entreprises à réaliser leur "transformation numérique".

Il n'est donc pas étonnant que les dirigeants cherchent des moyens de tirer le meilleur parti de leur investissement dans leurs équipes d'ingénieurs. Ils sont à la recherche de systèmes et d'outils qui aideront leurs équipes à livrer des logiciels plus rapidement que jamais. La conviction essentielle est que les développeurs sont plus productifs lorsqu'ils ont accès aux meilleurs systèmes, outils et services d'ingénierie.

Il est certain que l'élimination des frictions des systèmes d'ingénierie est essentielle pour avoir une équipe de produits performante. Il est difficile pour une équipe d'ingénierie d'atteindre son plein potentiel si elle est embourbée dans des problèmes qui affectent le délai de modification, la fréquence de déploiement, le temps de résolution ou les taux d'échec. Ces mesures sont absolument importantes et des cadres comme DORA font un travail fantastique pour les mettre en évidence pour les organisations.

Cependant, je pense qu'il y a une autre dimension qui est tout aussi importante et qui n'est pas souvent abordée lorsque l'on discute de la productivité des développeurs.

Dans quelle mesure un développeur s'épanouit-il dans son travail ?

Aborder la productivité des développeurs comme un problème à dimension unique, en cherchant uniquement à supprimer les frictions dans vos systèmes d'ingénierie, vous amènera à n'appliquer la pensée systémique qu'à un problème très nuancé. Cette stratégie est incomplète et vous expose au risque d'améliorer l'efficacité au détriment du bien-être général des développeurs.

Une meilleure approche consiste à aborder la productivité des développeurs comme deux dimensions de l'expérience globale du développeur, en réduisant la friction des systèmes et en améliorant la satisfaction. Cette approche reconnaît plus précisément que la productivité des développeurs nécessite une réflexion à la fois systémique et humaniste. Elle cherche à aller au-delà de la simple amélioration de la productivité des développeurs et à atteindre l'objectif d'autonomisation des développeurs.

En bref, les développeurs responsabilisés sont des développeurs productifs, mais ils sont aussi beaucoup plus. Ils sont motivés pour atteindre leur plein potentiel et ont un lien personnel fort avec l'objectif de l'organisation.

Nous avons peut-être une certaine idée de ce que signifie réduire les frictions dans nos systèmes d'ingénierie, mais qu'est-ce que cela signifie de favoriser l'épanouissement ?

L'épanouissement, en tant qu'objectif, cherche à améliorer les expériences des développeurs, telles que :

L'appartenance : Un développeur a le sentiment d'appartenir à son équipe et que ses contributions sont appréciées. Les nouveaux membres de l'équipe se sentent accueillis et soutenus, ce qui leur donne rapidement la confiance nécessaire pour commencer à contribuer à la base de code.

Sécurité psychologique : Les équipes produit ont la liberté de partager des points de vue différents et sont soutenues lorsque les données suggèrent qu'elles devraient abandonner des idées qui ne fonctionnent pas. Elles disposent d'outils pour donner aux responsables un retour sur leur expérience, et ce retour est reconnu et pris en compte.

Diversité et inclusion : Les équipes intègrent diverses expériences vécues et recherchent activement d'autres points de vue, en particulier ceux des groupes sous-représentés au sein de leur équipe, de leur organisation et de leur secteur.

Connexion avec le client : Les équipes se sentent habilitées à créer des liens avec les clients qu'elles servent. Il n'y a pas de "distance zéro" entre les équipes et leurs clients et l'apprentissage auprès des clients est continu et collaboratif.

Alignement sur la mission et les valeurs : Les développeurs croient en l'objectif de l'organisation et peuvent établir des liens clairs entre leur travail et l'impact qu'il a sur les objectifs commerciaux de l'organisation.

Développement de carrière : Les développeurs pensent qu'ils ont la possibilité de résoudre des problèmes difficiles en offrant leurs compétences uniques. L'organisation investit continuellement dans le potentiel du développeur en lui offrant autonomie et maîtrise. Comme le dit Marty Cagan, "les équipes de produits fortes reçoivent des problèmes à résoudre, plutôt que des fonctionnalités à construire."

Des développeurs autonomes sont des développeurs productifs

Pour explorer ces deux dimensions : la friction et l'épanouissement des systèmes, je propose le modèle d'expérience du développeur. Il s'agit d'un moyen pour les organisations de suivre les deux dimensions de l'expérience du développeur. En examinant les deux dimensions de manière égale, les organisations peuvent s'assurer qu'elles évitent de mettre en œuvre des solutions qui entraînent des conséquences inattendues.

Chaque quadrant représente l'état de l'expérience d'un développeur. Ces états sont fluides et peuvent changer en fonction du parcours d'un développeur au sein d'une organisation. Il peut se sentir passer d'un état à l'autre en raison d'un pivot dans la stratégie du produit, de la mise en œuvre d'un nouveau processus d'ingénierie, de l'achèvement d'un projet important, d'une réorganisation à l'échelle de l'organisation, du départ d'un chef d'ingénierie reconnu, ou même d'une migration vers un système d'ingénierie différent. Le fait est que ces états ne sont pas fixes et que nous devons nous adapter à la façon dont l'expérience du développeur évolue dans le temps.

Une matrice à deux dimensions avec un taux de satisfaction élevé à faible sur l'axe des Y et une friction des systèmes élevée à faible sur l'axe des X. Le quadrant supérieur gauche indique Démoralisé. Le quadrant inférieur gauche indique Dysfonctionnement. Le quadrant inférieur droit indique Exploité et le quadrant supérieur droit indique Habilité.

Le modèle d'expérience des développeurs comporte deux dimensions : Friction des systèmes et Accomplissement

Examinons de plus près chaque état d'expérience :

Dysfonctionnement : Les équipes qui connaissent une faible satisfaction et une forte friction des systèmes ont du mal à accomplir les tâches les plus courantes. Elles sont envahies par des comportements toxiques, des luttes intestines et une complexité excessive. La vision du produit est malléable et change constamment, selon la personne à qui vous parlez. La réaction aux échecs est chaotique et les équipes continuent de répéter les erreurs du passé.

Exploité : Les équipes qui ont des systèmes d'ingénierie très bien réglés, mais qui manquent d'épanouissement, se sentent exploitées. Elles pensent que leurs organisations ne les considèrent que comme un "rouage" - un clavier humain, tapant du code basé sur des fiches techniques peu inspirées. Remettre en question "le plan" est considéré comme perturbateur et les développeurs apprennent que l'efficacité impitoyable est privilégiée par rapport à la connexion avec le client. Les développeurs qui se sentent exploités quittent souvent leur entreprise ou se laissent distraire par des projets secondaires qui les satisfont davantage que leur travail quotidien.

Démoralisation : Les équipes qui tirent une grande satisfaction de leur travail, mais qui sont également confrontées à des frictions importantes dans leurs systèmes d'ingénierie, se sentent souvent impuissantes et frustrées. Ils ont une grande cohésion avec leur équipe, et ils croient en la vision de leur organisation, mais la frustration constante d'accomplir les tâches les plus basiques est ce qui les pousse à chercher la porte. Les développeurs démoralisés ne veulent souvent pas partir, mais ils ne peuvent plus tolérer les outils, services et systèmes inefficaces et défaillants avec lesquels ils doivent interagir chaque jour.

« Empowered » : C'est l'état souhaité. Ces équipes disposent de systèmes d'ingénierie de pointe, mais aussi de cultures saines et robustes. Les équipes responsabilisées atténuent les problèmes ensemble, partagent librement leurs connaissances et s'investissent dans le développement de chacun. Les équipes de produits responsabilisées sont inspirées chaque jour pour donner le meilleur d'elles-mêmes au travail, car elles sont non seulement alignées sur l'objectif de l'organisation, mais elles voient également l'impact direct qu'elles ont sur les clients, grâce à des interactions continues et directes avec eux. Les développeurs responsabilisés restent concentrés sur les objectifs de l'entreprise, car ils sont convaincus que celle-ci investit dans leur potentiel.

La productivité, la vélocité, le bien-être et le bonheur des développeurs sont des questions multidimensionnelles. C'est pourquoi il existe des cadres multidimensionnels tels que S.P.A.C.E. pour détruire le mythe selon lequel la productivité des développeurs ne concerne que leur "activité" ou leurs "performances". S.P.A.C.E. s'attaque aux problèmes d'épanouissement des développeurs en intégrant des mesures telles que la satisfaction et le bien-être des développeurs.

Nous devons recadrer la façon dont nous parlons de la productivité des développeurs. Il faut comprendre que l'investissement dans les outils et services pour développeurs est important, mais qu'il n'englobe pas l'expérience complète du développeur - et qu'il n'est pas le seul moteur de la productivité.

Lorsque les dirigeants d'une organisation s'engagent sur la voie de l'autonomisation des développeurs, ils constatent non seulement que leurs équipes de produits sont plus productives, mais aussi qu'elles sont inspirées et déterminées à donner le meilleur d'elles-mêmes pour leur organisation, leurs clients et leurs collègues.


Cet article est une traduction française de “developer-productivity-is-really-about-empowerment” écrit par Travis Lowdermilk