De développeur à responsable technique : introspection et leçons apprises
Je suis responsable technique d'un projet complexe multi-équipes avec un autre collègue depuis un an et demi. Les journées typiques vont de la navigation calme au chaos absolu, avec plusieurs incendies brûlant simultanément. Vous trouverez ci-dessous quelques leçons que j'ai apprises et quelques conseils qui m'ont permis de rester sain d'esprit et nous ont aidés à livrer à temps.
L'architecture et le code seront imparfaits
L'une de mes difficultés était de réfléchir à la manière dont je pourrais améliorer notre base de code et l'architecture de nos applications. En tant que développeur, je suis fier du savoir-faire et de la qualité des logiciels . J'ai constamment mesuré la qualité du travail par rapport à mes normes et j'ai oublié que l'évaluation provenait d'années d'expérience en conception et en développement. Les connaissances qui viennent naturellement avec l'expérience ne sont pas toujours intuitives pour une équipe de jeunes développeurs. En conséquence, j'ai perdu de vue les améliorations remarquables que mon équipe avait apportées.
Les exigences et les priorités changent. L'architecture et le code « parfaits » d'aujourd'hui pourraient ne plus être pertinents la semaine prochaine. Ces artefacts sont un moyen d'atteindre les objectifs organisationnels, ils doivent donc être évolutifs. Tant qu'ils conservent une certaine modularité et qu'ils sont pour la plupart faiblement couplés et réutilisables, il n'y a pas de problème si les solutions n'ont pas la forme exacte que nous avons en tête pour pouvoir les livrer. Au lieu de s'attarder sur la qualité dans des domaines moins critiques, il est plus évolutif de guider et de faire confiance à l'équipe pour comprendre le comment.
En tant que contributeur individuel, je n'ai aucune autorité de gestion officielle, mais je suis toujours responsable de la production des personnes avec lesquelles je travaille et de la réussite d'un projet. Pendant ce temps, ma production personnelle, si elle était mesurée par des demandes d'extraction fusionnées, avait été la plus faible depuis que je suis devenu développeur. Il m'a fallu un certain temps pour réaliser que dire: «Tu as compris. Voici les ressources et informations dont vous avez besoin. Je serai là si tu as besoin d'aide. permet aux autres d'apprendre et d'agir. Lorsque les choses commencent enfin à aller dans la bonne direction pour s'aligner sur notre vision technique, cela fait chaud au cœur.
L'autonomie est un avantage, mais l'engagement excessif ne l'est pas
Être digne de confiance pour créer mon carnet de commandes magique en fonction des priorités actuelles des produits est satisfaisant. Mais il est difficile de savoir ce qui a un impact et de choisir la portée et la granularité appropriées sur lesquelles se concentrer.
Mon archétype dans l'équipe actuelle avec laquelle je travaille est un mélange de responsable technique, d'architecte et de solveur. L'équipe du projet comprend deux équipes de deux pizzas, toutes deux relativement peu familières avec la pile technologique . Certains membres étaient nouveaux dans l'organisation. L'ancien système d'adhésion que nous modernisons gère une partie essentielle des activités de l'AMA. De nombreuses applications couvrant plusieurs domaines au sein du département s'y intègrent pour des opérations commerciales spécifiques.
Avec un espace de problèmes aussi complexe, je suis tiré dans un million de directions chaque jour. Tout a un coût d'opportunité - passer du temps à préparer une proposition visant à améliorer la robustesse et l'évolutivité de notre architecture logicielle prend du temps à passer des revues de relations publiques et à débloquer l'équipe. Mais si je devenais trop zélé avec la direction technique et le contrôle d'accès, mon équipe passerait à côté d'expériences d'apprentissage précieuses.
Parfois, il est difficile de décider quand intervenir ou rester au-dessus de l'eau.
En tant que contributeur individuel vétéran, je reste conscient des choses sous-optimales autour de moi : architectures qui ne s'adaptent pas, processus qui nuisent à la santé de l'équipe, opportunités d'essayer quelque chose de nouveau, etc. Cependant, tout faire n'est pas durable. Un conseil à mon responsable pour m'avoir rappelé que mon temps est précieux - cela fait des merveilles pour ma santé de déléguer le cas échéant et de me concentrer sur des choses sur lesquelles je suis particulièrement bien placé pour travailler. La délégation est difficile car résoudre n'importe quel problème a été mon outil par défaut. C'est donc l'un de mes objectifs de carrière pour l'année.
Les défis techniques sont loin d'être le seul problème
Mes années de conseil m'ont bien appris un concept : rien n'est jamais qu'un projet informatique. Les consultants portent souvent plusieurs chapeaux pour aider les clients à réussir, et être un responsable technique amplifie cette notion. Contrairement aux concerts de conseil, les projets ou initiatives ne "s'arrêtent pas". Il y a toujours plus de travaux de maintenance, plus de contexte global à absorber et un terrain encore plus accidenté à parcourir.
L'écriture de code et la création de solutions brillantes ne sont qu'une partie de la réussite d'un projet interdisciplinaire de longue date.
Parmi les autres préoccupations, il convient de s'assurer que les user stories ont le bon niveau de détails techniques, d'expliquer comment certaines décisions architecturales s'inscrivent dans la vision globale, de convaincre d'autres groupes avec des objectifs concurrents de nos priorités ou de collaborer avec les chefs d'équipe pour identifier les processus nécessaires et les changements culturels.
Hélas, contrairement au débogage, obtenir des commentaires sur l'effet de mon travail peut prendre des semaines ou des mois. Néanmoins, je suis responsable du résultat final en tant que responsable technique. Cela signifie que je dois considérer l'ensemble du problème et effectuer d'autres tâches qui feront avancer les choses, mais qui passeront entre les mailles du filet si personne n'intervient pour attirer l'attention sur eux.
Dernières pensées
Mon parcours pour devenir un responsable technique a été rempli de défis passionnants, et j'ai la chance d'avoir un excellent système de soutien de leaders et de pairs au travail. De plus, voir une équipe s'épanouir et être reconnue pour avoir atteint des jalons vitaux est incroyablement édifiant, car cela montre ma persévérance et les cheveux gris sur ma tête ont vraiment porté leurs fruits.
Winnie Ho est un développeur de logiciels senior à l'Alberta Motor Association qui a un désir insatiable d'apprendre, de lire et d'écrire sur tout ce qui concerne AWS et le Web.