Comment gérer les développeurs de logiciels sans microgestion
On m’a demandé plusieurs fois cette année comment mesurer la productivité, la qualité et les résultats d’un développeur de logiciels, en particulier lorsque le leadership promeut des modèles de travail hybrides.
Mais voici la réalité à laquelle les organisations technologiques sont confrontées lorsqu’il est difficile d’embaucher et de retenir de grands développeurs de logiciels : les développeurs de logiciels talentueux se hérissent à l’idée d’être étroitement gérés, et beaucoup quitteront les emplois où il existe une culture de microgestion.
Demander à un développeur de rendre compte à un responsable sans expérience en développement de logiciels peut susciter des craintes de bureaucratie de processus. Certains développeurs de logiciels agiles qui adoptent les extrêmes des principes d’auto-organisation veulent une autonomie totale et peuvent se rebeller à tout signe de leadership tentant de mesurer la productivité, la qualité ou d’autres considérations de performance.
Si les développeurs de logiciels détestent la microgestion, beaucoup méprisent davantage les évaluations annuelles des performances. Les développeurs ciblent des objectifs de performance en temps réel et visent à améliorer la vélocité, la fréquence de déploiement du code, les temps de cycle et d’autres indicateurs de performance clés. Les équipes Scrum discutent de leurs performances à la fin de chaque sprint, de sorte que les commentaires des évaluations de performances annuelles et trimestrielles peuvent sembler superflus ou non pertinents.
Mais il y a aussi la réalité pratique que les organisations ont besoin de méthodes pour reconnaître si les équipes agiles et les développeurs de logiciels atteignent ou dépassent les objectifs de performance, de développement et commerciaux. Comment les managers peuvent-ils obtenir ce dont ils ont besoin sans rendre les développeurs malheureux ?
Vous trouverez ci-dessous sept pratiques recommandées qui s’alignent sur les principes d’agile, de scrum, de devops et du cycle de vie du développement logiciel et qui pourraient être appliquées à l’examen des développeurs de logiciels. Je ne les écris pas comme des objectifs SMART (spécifiques, mesurables, réalisables, pertinents et limités dans le temps), mais les dirigeants doivent adopter les objectifs pertinents en tant que tels en fonction des méthodes de travail agiles et des objectifs commerciaux de l’organisation.
Certains d’entre eux peuvent n’être pertinents qu’au niveau de l’équipe, tandis que les gestionnaires pourraient en utiliser d’autres pour mesurer leurs subordonnés directs.
Définir des objectifs et des résultats clés alignés sur les objectifs commerciaux et techniques
La définition des objectifs et des résultats clés (OKR) est une discussion que les propriétaires de produits, les responsables du développement et les architectes peuvent avoir avec leurs équipes pour s’aligner sur des critères de succès mesurables. Idéalement, c’est une collaboration entre les dirigeants et l’équipe, les dirigeants définissant l’objectif et toute l’équipe discutant, débattant et décidant des résultats clés.
Une bonne pratique consiste à définir les OKR à une cadence significative. S’ils sont trop fréquents, les frais généraux liés à la définition et à la mesure des OKR peuvent être coûteux ; s’ils sont trop peu fréquents, les équipes peuvent perdre de vue les objectifs. Deux exemples :
- L’objectif d’amélioration de la fiabilité des applications peut inclure des résultats tels que la réduction du temps de réponse des pages, l’amélioration de la disponibilité des applications ou la réduction des taux d’erreur d’un pourcentage significatif.
- L’objectif d’amélioration de la fiabilité du déploiement peut inclure des résultats tels que l’augmentation de l’automatisation des tests ou la réduction du temps de génération par des pourcentages significatifs.
Respecter les engagements de sprint et de publication de manière cohérente
Scrum fonctionne sur une base de cadences et de respect des engagements, donc le respect des délais est un moyen de mesurer la discipline d’une équipe et son alignement sur les normes. Je ne m’attends pas à ce que les équipes respectent parfaitement tous les engagements de sprint, mais les dirigeants peuvent définir une barre haute et basse d’attentes agrégées sur plusieurs sprints.
Pour les équipes effectuant des publications à des cadences définies (quotidiennement, hebdomadairement, tous les quatre sprints, etc.), je recommande de vérifier si les équipes publient dans les délais et respectent les critères de qualité. Atteindre la date de sortie mais provoquer des pannes, des incidents de sécurité ou des problèmes de production importants sont des problèmes évidents.
Capter la satisfaction des Product Owners et des parties prenantes
Le manifeste agile identifie la collaboration client plutôt que la négociation de contrat comme une valeur fondamentale. Bien que nous ne devrions pas obliger les développeurs agiles à livrer sans faille dans les délais, la portée et les coûts, le triangle de fer proverbial nous permet de chercher à capturer des mesures indépendantes de satisfaction client.
Une enquête de satisfaction est un outil que les grandes organisations de développement peuvent utiliser pour recueillir les commentaires des développeurs et des équipes agiles. Certaines questions peuvent couvrir :
- Collaboration lors du brainstorming des problèmes et de la documentation des solutions
- Livraison sur le périmètre et satisfaction des résultats
- Qualité des commentaires lors de la planification et de l’estimation des fonctionnalités
La clé est de transmettre les commentaires des clients aux développeurs et aux équipes agiles afin qu’ils puissent réfléchir aux résultats du point de vue des clients et améliorer les performances.
Quantifier les évaluations par les pairs de la conception, de la documentation et de la facilité d’utilisation
Demandez à un développeur s’il est facile d’utiliser les API d’une autre équipe, de mettre à niveau le code d’un autre développeur ou d’apprendre une nouvelle architecture d’application à partir de la documentation disponible. Malheureusement, il est peu probable que vous obteniez une réponse positive ou un développeur heureux, en particulier lorsque vous travaillez sur du code hérité ou dans une architecture monolithique.
Alors, comment déterminez-vous si les développeurs font un meilleur travail aujourd’hui pour développer du code maintenable, une documentation utile et des microservices faciles à utiliser ? Comment pourriez-vous mesurer ce progrès ou cette régression ?
Bien qu’il puisse exister des outils ou des analyses pour obtenir ces mesures, je pense que l’approche la plus simple consiste à créer un processus d’examen par les pairs. Les pairs peuvent commenter la lisibilité du code lors de l’examen d’une demande d’extraction, fournir des évaluations sur la documentation et répondre à des enquêtes lors de l’intégration de microservices ou d’API.
Les revues par les pairs doivent compléter les commentaires des outils de revue de code et d’analyse de la qualité qui peuvent fournir des commentaires granulaires en temps réel sur la qualité du code, la sécurité et les problèmes connexes.
Sélectionner des indicateurs de performance clés non négociables pour les devops
Les propriétaires de produits et leurs pairs fournissent des commentaires importants, mais les responsables doivent également s’assurer que les développeurs et les équipes de développement examinent et répondent aux commentaires opérationnels. Les commentaires doivent inclure des détails sur l’ingénierie de la fiabilité du site, les pratiques de sécurité et la réactivité aux incidents, demandes et autres tickets de gestion des services informatiques (ITSM).
Devops, ITSM et infosec ont des KPI très matures, et les dirigeants doivent sélectionner un nombre significatif et gérable sur lequel les équipes de développement de logiciels doivent se concentrer. Pour les équipes de développement travaillant sur des applications cloud natives, je recommande de définir des objectifs de niveau de service et de les utiliser pour gérer les budgets d’erreur. Pour d’autres groupes de développement, mesurer les réductions des taux d’échec des changements et le temps moyen de récupération après des incidents étaient les principaux KPI de cette recherche.
Démontrer les impacts de l’apprentissage, de l’expérimentation et du mentorat
Aujourd’hui, de plus en plus d’entreprises reconnaissent l’importance de soutenir l’apprentissage continu, de promouvoir des environnements sûrs pour l’expérimentation et d’inscrire les participants à des programmes de mentorat. Bien que tous ces objectifs soient importants, les responsables doivent examiner comment les développeurs mettent ces directives en pratique et où elles ont un impact sur l’entreprise. Les responsables doivent aider les développeurs à créer un plan de développement de carrière et fournir des commentaires sur la manière dont leur apprentissage, leur mentorat et leur participation à des expériences et des preuves de concept s’alignent sur les objectifs de carrière des employés.
Demander aux développeurs de proposer des buts et des objectifs travail-vie personnelle
Dans le Dice 2021 Technologist Sentiment Report, 36 % des répondants ont évalué leur épuisement professionnel à quatre ou cinq sur une échelle de cinq points, et 48 % ont indiqué qu’ils sont susceptibles de changer d’employeur.
Je ne crois pas que les DSI, les CTO, les responsables de la livraison et les responsables du développement de logiciels souhaitent voir leurs développeurs de logiciels s’épuiser et se joindre à la grande démission. Ainsi, bien que je suggère plusieurs façons de faire en sorte développeurs de logiciels, les dirigeants doivent être empathiques à l’environnement de travail d’aujourd’hui et à la situation personnelle de chaque développeur.
Une façon de trouver un équilibre est de travailler avec les ressources humaines sur la définition des buts et objectifs travail-vie personnelle. Les développeurs doivent personnaliser ces objectifs, et l’organisation et les responsables doivent les garder confidentiels. Un objectif travail-vie personnelle peut créer un équilibre dont de nombreux développeurs ont besoin aujourd’hui pour se sentir soutenus.
En fin de compte, la gestion et la mesure des performances nécessitent des discussions fréquentes entre le manager et l’employé. Sommes-nous alignés sur les objectifs et les critères de réussite ? Comprenons-nous les normes et les contraintes ? Même lorsque les métriques fournissent des indicateurs, c’est souvent la discussion et les actions de suivi qui conduisent à l’amélioration des performances. C’est comme ça que les gens fonctionnent.
Copyright © 2022 IDG Communications, Inc.