La productivité des développeurs est devenue un phénomène mondial, même le géant Google, qui pèse mille milliards de dollars, en parle. Récemment, Pichai de Google a parlé de la crise de productivité sans fin d’un million de dollars, avec un objectif ambitieux d’augmenter les chiffres de 20 %. Cependant, Google n’est pas la première ni la dernière entreprise technologique à parler d’EngProd.
Les embauches d’ingénieurs sont un gâchis malgré une légère augmentation du salaire moyen du développeur de logiciels. Même si 2022 a produit 373 licornes technologiques, l’année a également vu la grande démission des ingénieurs. Ce dualisme structurel dans la technologie a une raison fondamentale : les développeurs sont mécontents, insatisfaits et, même quelque part, improductifs.
Aujourd’hui, la plupart des entreprises subissent une perte de 300 milliards de dollars par an en raison de la faible productivité des développeurs. Pourtant, alors que neuf responsables techniques sur dix sont aux prises avec une faible efficacité technique, ils ne savent tout simplement pas comment résoudre ce problème, malgré une volonté colossale.
Qu’est-ce qui tue la productivité des développeurs ? Réponses à toutes les questions
Un SDLC obstrué et des workflows de développement inefficaces
Un SDLC idéal ne consiste pas seulement à écrire et à expédier du code pour créer des applications en cours d’exécution, mais s’occupe également des révisions de code, de la gestion des retours d’informations et de la publication du code à temps (et pas seulement de son écriture).
Les développeurs sont efficaces pour écrire du code, mais tout le code écrit ne voit pas la lumière des jours de production. Pour les responsables de l’ingénierie, la quantité de code finalement libérée dans la mise en scène et la production est un sujet de préoccupation. Les développeurs sont souvent confrontés au syndrome de l’imposteur, ce qui en fait leurs pires critiques. Le manque de confiance dans leur code est encore aggravé par un cycle de révision de code brisé, ce qui nous amène à la deuxième partie du problème.
La plupart des organisations ne disposent pas d’un processus de révision de code établi et documenté ; il n’y a pas d’enregistrement approprié de qui fait quoi. Traditionnellement, les équipes logicielles ne considèrent pas les révisions de code comme une tâche principale, de sorte qu’aucune heure de travail officielle n’est allouée à ce processus fastidieux. Parfois, un code sera mis de côté pendant des jours parce que les experts du domaine ne sont pas disponibles ou que les développeurs ne font pas confiance au code qu’ils écrivent.
Attendre les mainteneurs de code ou les pairs pour les révisions de code bloque les développeurs pendant des heures et finit par nuire à la cohésion de l’équipe. Dans d’autres scénarios, les révisions effectuées pourraient être inefficaces et le processus devra être choisi par d’autres développeurs à partir de zéro. Ce cycle de rétroaction interrompu coûte à un développeur moyen cinq à dix heures par semaine et constitue la troisième principale raison de la frustration des développeurs dans le monde.
Défis d’alignement : vos équipes commerciales et d’ingénierie sont-elles sur la même longueur d’onde ?
Un produit réussi est construit avec la collaboration des équipes d’ingénierie et d’affaires. Malheureusement, les deux équipes apportent une expertise et des objectifs différents à la table, et prioriser ceux sur lesquels se concentrer en premier devient une pomme de discorde. De plus, les deux équipes travaillent souvent avec des mentalités complètement disparates : travailler de manière indépendante, se diviser l’attention et, par conséquent, s’écarter de la vision principale du produit.
Même parfois, les responsables de l’ingénierie ne peuvent pas bien articuler leur mission aux techniciens et comment leur travail s’intègre dans le tableau d’ensemble. En conséquence, sans aucun contexte approprié, la plupart des ingénieurs se tournent vers des projets fantômes avec une valeur commerciale minimale ou se sentent désenchantés par le produit lui-même. Cet éloignement est si endémique que 16 % des ingénieurs ont commencé à se sentir activement désengagés du produit (et du processus) qu’ils construisent.
De plus, un manque d’alignement des développeurs pourrait même suspendre indéfiniment la publication de votre projet, faisant de tout l’argent, du temps et des ressources humaines dépensés un gaspillage colossal. Le processus peut avoir de graves conséquences, surtout lorsque la récession est à nos portes et que les entreprises, en particulier la technologie, réduisent les coûts et gèlent les embauches.
Débordement de tâches non essentielles
Dans un monde idéal, le travail principal d’un ingénieur logiciel comprend l’écriture de code et l’exécution de logiciels. Mais, ironiquement, un ingénieur moyen ne code qu’environ 30 % du temps. Alors, où vont les 70 % restants ? La plupart des ingénieurs passent leurs principales heures de travail à gérer l’aspect commercial des choses, y compris la maintenance des logiciels et la modernisation de l’infrastructure existante. De plus, si une organisation est à un niveau de maturité DevOps inférieur, les ingénieurs doivent également diriger les opérations : stabilité du service, correction des bogues qui ont échappé à l’AQ, développement d’outils de productivité et de workflows CI/CD, et gestion des tests pré-commit.
Une autre tâche non essentielle qui entrave la productivité des développeurs est l’embauche, les entretiens et la fidélisation des talents logiciels. Les chiffres en disent long ici; 40 % des ingénieurs dénigrent les entretiens téléphoniques et qualifient le processus de trop lourd à suivre. De plus, les appels d’embauche constants du niveau supérieur laissent la plupart des ingénieurs éloignés de leurs tâches de codage de base, provoquant de la frustration et même un épuisement chronique des développeurs.
Changement de contexte : tueur de productivité à coût élevé et à fort impact
En 2021, les jours de codage de base pour les ingénieurs sont tombés à 1,6 jour par semaine. Pour les ingénieurs, les réunions constantes tout au long d’une journée de travail prennent la majeure partie de leur temps de fabrication. Un développeur moyen a près de 87 interruptions par jour, et chaque interruption lui enlève 10 à 15 minutes supplémentaires avant que le développeur puisse se remettre à réécrire le code. La plupart de ces interruptions sont causées par des alertes de pagination constantes et des notifications de stand-up.
Alors que les stand-ups modernes sont censés durer dix minutes, ils s’étendent involontairement sur une heure. La participation aux réunions n’est pas un problème pour les autres, mais leur répartition quotidienne insoutenable l’est. Un autre problème est la mauvaise gestion des ressources en faveur de KLTO. Les développeurs subissent déjà une énorme pression pour sortir des produits complexes. De plus, la maintenance constante et les tâches opérationnelles les maintiennent accrochés même en dehors des heures de travail. Cette lutte contre les incendies fréquente pour maintenir les systèmes opérationnels surcharge les développeurs et crée des problèmes de bien-être. Au cours des six derniers mois, 82 % des ingénieurs ont été victimes d’épuisement professionnel et de graves problèmes de santé. Les chiffres parlent d’eux-mêmes ici !
Tout ce basculement constant ne laisse pas de temps aux développeurs pour un travail approfondi. En moyenne, un programmeur n’obtient qu’une seule session de travail non perturbée de deux heures par jour.
Note d’adieu
Une faible productivité des développeurs peut faire boule de neige dans un carnet de commandes de produits élevé, une qualité médiocre et une fidélisation difficile des clients, ce qui affecte négativement le consensus de la marque. Cependant, la productivité ne consiste pas seulement à remplir des cases à cocher chaque semaine ; c’est aimer travailler et grandir dans un environnement tout en prenant soin de son bien-être.
Alors, comment les responsables de l’ingénierie peuvent-ils stimuler la productivité des développeurs ? La meilleure façon de commencer avec le problème brûlant est d’identifier ce qui empêche les développeurs de faire de leur mieux ; pour certaines équipes, il s’agit d’une dette de communication plus élevée, tandis que pour d’autres, il s’agit d’un SDLC non rationalisé. Les vraies raisons ne pouvaient être déterminées que par une plus grande visibilité sur le système d’ingénierie. Un outil d’analyse technique offre aux responsables une visibilité sur les activités de travail de leur équipe afin que les réunions deviennent plus axées sur les données et soient plus productives.
Qualitativement parlant, les développeurs doivent également retenir de leur emploi du temps du temps dédié à la croissance et à l’innovation. La pratique aide à créer des développeurs plus complets et à augmenter les profils personnels, ce qui peut ensuite faire boule de neige dans le bonheur des développeurs et une meilleure expérience des développeurs. Larry Page conseille de bloquer 20% pour les bousculades secondaires. C’est ainsi que Gmail a été créé en premier lieu.