Article original : Have you tried turning your software team’s identity off and on again?
Par Victoriya Kalmanovich
Cette série décrit mon expérience en tant que responsable d'un groupe de R&D dont le comportement ressemble à celui d'une startup en difficulté. Dans mes deux derniers articles de blog, j'ai présenté un bref contexte concernant les développeurs et les technologies. Cet article traitera de la définition vague de l'identité d'un groupe.
Dans mon dernier article de blog, j'ai dépeint une image presque trop belle pour être vraie. Une image d'un groupe de développement productif, plein d'énergie et avide de projets. Je savais que je devais détourner le regard des succès récemment acquis et me concentrer uniquement sur les problèmes, aussi malheureux que cela puisse me rendre.
D'une part, j'ai ressenti le besoin de présenter les étapes que j'ai franchies pour restaurer une certaine productivité. Je voulais montrer à mon supérieur tous les succès récents — la méthodologie de codage, les règlements de travail et autres concepts que nous avions commencé à mettre en œuvre. Je voulais présenter les concepts et procédures de formation que nous avions établis. Je voulais montrer la forte coopération que j'avais menée avec une autre organisation. Cette coopération a offert l'opportunité de combiner le pool de connaissances de l'organisation et de créer une meilleure formation professionnelle pour mon groupe. En plus de cela, l'un de nos projets a été accepté dans un programme d'accélération. J'avais vraiment envie de le montrer également.
Mais je savais que cette image s'estomperait bientôt à moins que je continue à cibler les problèmes principaux. Le problème principal était cette vérité difficile suivante. Le groupe n'avait pas de base solide et ce n'était qu'une question de temps avant qu'il ne s'effondre à nouveau. Je l'ai identifié comme la perte d'identité du groupe.
Qu'est-ce qu'une identité de groupe ?
Lorsque nous atteignons un point dans la vie où nous cherchons notre identité unique, nous nous posons diverses questions. D'où viens-je ? Quel est mon héritage ? Qui m'influence ? Qu'est-ce qui m'excite ? Quelle est la raison pour laquelle je me lève le matin ? Ces questions m'ont aidée à façonner mon identité personnelle, à la fois en tant qu'être humain et en tant que leader. Le même processus se produit d'une manière ou d'une autre dans toute structure organisationnelle.
Définir l'identité d'un groupe doit se faire dès qu'un manager prend les rênes. Il doit examiner les responsabilités du groupe et définir la position de chaque membre du groupe. Cela clarifie beaucoup de choses. Cela fournit des frontières claires concernant les responsabilités du manager et des développeurs.
Ce processus doit se produire au niveau du manager de groupe et même plus haut. Il est rare qu'une compréhension organisationnelle complexe telle qu'une identité puisse dépendre de la portée des responsables d'équipe ou moins. Il est également injuste pour les responsables d'équipe, qui ont déjà suffisamment à faire.
Comme vous vous en souvenez peut-être de mon précédent article de blog, j'ai parlé du cycle vicieux des zéro-produits. Ce cycle a commencé quelque part, alors j'ai commencé à retracer les étapes du groupe. J'ai réalisé que le moment où la dernière version officielle du produit avait été publiée était le point de rupture. C'était le moment où il n'y avait pas de vision claire sur quel était l'objectif principal du groupe, quel était son but et quel était le produit dont il était responsable de la livraison.
Quel était l'objectif principal ?
L'objectif principal était la maintenance logicielle et système pour un système très complexe. Afin de réaliser la maintenance logicielle sur une telle quantité de code, un développeur doit travailler sur le code. Le développeur doit le comprendre et connaître ses fonctions géniales, mais aussi ses défauts et ses lacunes inhérents. Le développeur doit ressentir le code. Il ne peut acquérir ce sentiment qu'à travers une recherche massive et une compréhension approfondie des procédures au sein du système.
À mon avis, il est impossible de maintenir l'ensemble du système simultanément, en raison d'un petit nombre de développeurs dédiés à la maintenance et d'un manque très sérieux de connaissances. J'ai donc déclaré que la maintenance de domaines spécifiques chaque année était suffisante pour nous. L'alternative serait une maintenance dispersée qui ne mènerait qu'à plus de lacunes à long terme.
Prenons un exemple simple comme l'insertion d'une image sur un écran. Cela est facile dans les systèmes modernes écrits en code lisible qui suit des méthodologies de codage appropriées.
Dans notre cas, pour insérer une fonctionnalité, le développeur devait suivre des étapes plus complexes. Il devait rechercher l'ensemble du code de l'écran et l'ensemble du code des écrans qui pourraient être affectés par le changement. Cela pouvait prendre jusqu'à un mois de recherche. Après la recherche, certaines conclusions auraient été développées. Ils auraient essayé de déchiffrer la partie pertinente de l'architecture du système et de trouver quelques moyens d'implémenter l'insertion d'image.
En parallèle, et c'est la partie importante, le développeur doit documenter TOUT. Chaque méthode difficile. Chaque processus qu'ils découvrent. Chaque insight d'architecture ou de réseau qu'ils ont. Chaque phénomène inhabituel et son investigation jusqu'à son origine. Cela est crucial puisque la documentation existante et la plupart du code écrit sont à peine lisibles.
L'objectif semble très simple, mais la documentation réglementée et la maintenance du code ne sont pas les seules choses qui définissent l'identité d'un groupe. Le groupe doit avoir un but. Notre but a disparu.
Où est passé le but ?
À un moment donné, la maintenance logicielle a été effectuée sans réglementation et a lentement quitté le focus professionnel. Ce qui a commencé à couler à la place étaient des projets secondaires. Les projets secondaires sont devenus l'objectif principal. Chaque fois qu'un client s'adressait à l'une des équipes, ayant besoin d'une solution rapide, le groupe pivotait dans cette direction. Les gens travaillaient sur des projets secondaires pour le simple plaisir de travailler. La maintenance difficile mais cruciale a été complètement abandonnée.
Lorsque j'ai commencé mon poste de responsable de groupe, presque chaque membre du groupe m'a dit qu'il ne savait pas exactement ce que le groupe était censé faire. Ils avaient l'impression de ne pas avoir de vrais objectifs lorsqu'ils venaient travailler. Les projets secondaires ont dispersé le but.
Pourquoi devons-nous parfois gérer nos clients ?
Un groupe de développement ne peut pas faire aveuglément ce que le client veut. Surtout lorsque le client change souvent d'avis. Par exemple — lorsque j'étais développeuse logicielle, mon équipe et moi travaillions sur un projet de navigation similaire à "Waze". Notre responsable produit continuait à demander des changements qui ne faisaient aucune différence avec la fonctionnalité du système. C'était toujours une demande pour changer les couleurs des boutons ou déplacer les barres d'outils autour de l'interface utilisateur. Cela a empêché l'équipe de faire des progrès pendant très longtemps.
Dans mon groupe de développement, le problème était à plus grande échelle. Le groupe n'avait pas un seul client indécis. Il avait quelques clients séparés et chaque client tirait dans sa propre direction. Il n'y avait pas un facteur d'intégration, regardant le tableau d'ensemble et gérant les clients et les projets. Pendant longtemps, le groupe a travaillé à travers une file d'attente — le premier client entrant signifiait le premier projet que le groupe développait. Par conséquent, presque tout type de projet pouvait être apporté au groupe. Avec le temps, le groupe a commencé à traiter des problèmes de QA, d'IT et même de matériel, plutôt que de développement logiciel.
Récupérer le but, et par conséquent la motivation, a été un processus continu. Il a commencé avec une définition — j'ai défini, avec mes responsables d'équipe, nos projets. Nous les avons priorisés en accord avec les demandes de nos clients, établissant ainsi une feuille de route dont nous ne dévierons pas, comme cela s'est produit dans le passé. Cette feuille de route indiquait notre objectif — la maintenance logicielle du système a été déclarée comme notre but.
Nous avons ajouté un autre projet à la feuille de route, un deuxième projet principal, lié au système mais pas directement. Il a ajouté au but puisqu'il avait un grand potentiel non exploité. Je croyais qu'il serait idéal pour les relations publiques et pour renforcer la croyance des développeurs en leurs propres compétences. Cette feuille de route dédiée a concentré les équipes. Nous savions qu'à la fin de l'année, nous devions livrer deux produits de bout en bout.
Définir la boussole professionnelle était important. Le plus gros problème était de regagner la confiance des développeurs dans le groupe. Après tant d'années, mes développeurs — à la fois expérimentés et nouveaux — n'avaient plus de carburant ni de volonté pour travailler. Après certaines de mes conversations individuelles planifiées, j'ai cartographié les forces de chaque développeur. Si, par exemple, un développeur était vraiment bon en recherche — je les ai laissés faire la recherche.
Après avoir cartographié les forces individuelles, j'ai cartographié les forces de l'équipe. Une certaine programmation en binôme a été effectuée afin de renforcer l'estime de soi de certains développeurs. Nous avons organisé un atelier professionnel pour les responsables d'équipe, afin de renforcer les capacités de gestion. J'ai abordé les problèmes que j'ai relevés lorsque j'ai observé le processus de programmation et les problèmes que les développeurs eux-mêmes avaient présentés.
Comment l'identité a-t-elle été restaurée ?
En trouvant une définition et en restaurant l'ordre. Nous avons défini notre domaine d'expertise. J'ai mis des frontières autour de nos projets désignés et n'ai laissé aucun autre projet franchir cette frontière. J'ai limité les problèmes sur lesquels nous travaillons (plus de problèmes matériels !). J'ai veillé à ce qu'il y ait une utilisation appropriée des méthodologies de codage et du contrôle de version. J'ai fait en sorte que tout le monde documente son travail. J'ai renforcé les forces de chaque programmeur. J'ai affûté l'ensemble des compétences douces des responsables d'équipe.
J'ai ciblé à la fois les valeurs professionnelles et personnelles afin de restaurer l'ADN logiciel inévitable du groupe.
Les difficultés de diriger des changements dans un environnement impitoyable, de diriger l'innovation au lieu de couler et comment survivre en tant que jeune femme dans un environnement très égoïste dominé par les hommes ? Restez à l'écoute, tout cela et plus encore alors que la série se déroule !
Partie 1 — Comment les entreprises peuvent-elles guérir un groupe de développement en difficulté ?
Partie 2 — Surmonter un écart technologique — une circonstance horrible ou une aventure créative ?