Les leçons surprenantes que j'ai apprises en tant que responsable technique

Bonjour à tous ! Après une période d'absence d'écriture, je suis de retour pour essayer de me remettre dans le bain. Je tiens à souligner que les expériences partagées dans cet espace sont basées sur mes expériences académiques et professionnelles. Il est donc important de se rappeler que ce qui est décrit ici ne représente peut-être qu'une fraction de la réalité et ne doit pas être interprété comme une formule définitive pour des processus, des procédures ou des services spécifiques.

Je suis actuellement très enthousiaste à l’idée de cette nouvelle étape de ma carrière. J’ai beaucoup appris et j’aimerais partager une partie de ce parcours avec la communauté. J’espère que les informations présentées ici seront d’une grande utilité pour les lecteurs.

L'humain d'abord - L'importance des compétences générales

Lorsque j’ai participé à mon premier processus de sélection, il y a quelques années, je me souviens clairement des étapes presque ennuyeuses que j’ai traversées : l’entretien avec les RH, le test pratique, l’entretien avec le responsable technique et, enfin, l’entretien avec le manager. Tout au long de ma carrière de développeur, j’ai participé à plusieurs entretiens avec différents modèles. À cette époque, je me sentais toujours mal à l’aise lors des entretiens avec les RH. Je ne comprenais pas très bien pourquoi, pensant : « Si je peux faire ce qui est demandé dans le test technique, je montre déjà suffisamment de compétences pour le poste. »

Lorsque j'ai pris mes fonctions de responsable du développement technique, l'une de mes responsabilités était de collaborer avec les RH (oui, les mêmes personnes avec lesquelles je ne comprenais pas la raison de participer au processus de sélection) pour préparer un test technique et définir le format d'entretien pour deux candidats débutants dans le domaine du backend. Je pensais déjà savoir ce qu'un développeur débutant dans le domaine du backend devait fournir et ce qui serait considéré comme un élément différenciateur dans le test. Cependant, ce à quoi je ne m'attendais pas, c'est que, malgré l'importance du code, d'autres exigences surgissent au-delà de la livraison du projet : comment évaluer les candidats en termes de communication ? Quel est leur intérêt pour le poste ? Et comment le contexte qu'ils présentent peut-il influencer leur adéquation au poste proposé ? Ces questions et d'autres se sont avérées aussi pertinentes que le code présenté par les deux candidats, quelque chose que je n'avais pas pris en compte auparavant au cours de mes premières années en tant que développeur.

Je me souviens d'avoir été assis à la table de réunion pour prendre la décision finale et d'avoir été un peu surpris de constater à quel point les compétences techniques de chaque candidat étaient peu évoquées. Cela était dû en partie au fait qu'il s'agissait de candidats débutants, il était donc normal que leurs compétences techniques ne soient pas aussi développées, et ce n'était pas le principal sujet de discussion.

Cependant, même pour les postes plus avancés, notamment pour les postes de niveau supérieur, il est essentiel de prendre en compte des compétences telles que la communication, la documentation, l’adaptabilité, la proactivité et d’autres compétences souvent mentionnées. Ces soft skills sont fondamentales et peuvent être décisives pour réussir dans le rôle, en plus des compétences techniques. C’est d’ailleurs mon prochain point.

La ligne entre Junior et Senior (non, pas de niveau intermédiaire).

Je sais qu'il y a beaucoup de discussions sur la signification et la classification des termes liés aux niveaux d'expérience, comme "senior". Certains disent que "le senior est défini par les années d'expérience", d'autres affirment que "dans certaines entreprises, on acquiert une expérience senior après un an". Il y a aussi ceux qui disent qu'"il n'y a pas de distinction claire entre junior et senior" ou que "les seniors ne font que des revues de code et approuvent les PR". Certaines de ces affirmations sont comiques, d'autres ont un fond de vérité. Le fait est que le concept de "senior" est assez varié et il ne m'appartient pas de définir une norme universelle, mais je peux offrir quelques conseils pour comprendre cette classification d'une manière plus individuelle.

Être senior ne se résume pas seulement à des connaissances techniques, même si celles-ci sont sans aucun doute très importantes. Un vrai senior, ou du moins un bon senior, est une personne capable de résoudre des problèmes complexes tant en termes de code que d'architecture système. Maintenir la qualité du code, suivre de bonnes pratiques de développement et avoir des connaissances en gestion de projet sont des aspects cruciaux.

La différence principale est qu’un senior doit être capable d’exécuter tout cela de manière autonome et, plus important encore, de collaborer avec des équipes de différents niveaux et secteurs pour livrer le meilleur projet possible. De plus, un vrai senior (ou du moins les meilleurs) dirige et guide non seulement l’équipe, mais développe et prépare également d’autres développeurs à assumer de nouveaux postes et responsabilités.

Ma première expérience à la tête d'un projet

Lorsque j'ai pris en charge mon premier projet, mon patron savait que je n'avais jamais dirigé auparavant aucun autre projet. J'ai juste participé au développement et travaillé sur certains éléments qui faciliteraient le développement en termes de communication avec la direction. La première question qu'il m'a posée était : "Combien de personnes et quel type de personnes seront suffisantes pour compléter le projet". Je n'ai pas su répondre tout de suite, c'était une question très complexe. Comme le projet n'était qu'au stade des grandes lignes, nous n'avions aucune idée de la pile, du temps qu'il faudrait pour terminer chaque tâche et d'autres métriques intéressantes pour les personnes au-dessus. J'ai fait une étude complète pour pouvoir livrer le lendemain sur plusieurs méthodologies de gestion de projet : Pert, Planning Poker. Nous avons choisi de manière collaborative celle qui convenait le mieux et le défi a commencé. pour chaque membre de l'équipe, quelle est la meilleure plateforme de développement, quelle est la meilleure pile à utiliser, comment fonctionnera l'architecture du système, en étudiant d'autres solutions sur le marché, en surveillant le niveau de chaque développeur, en faisant des réunions, des réunions et encore des réunions avec la direction .

Au moment où je m'en rendais le moins compte, je m'éloignais de plus en plus du code. Mon rôle était de suggérer des améliorations et de corriger certains bugs critiques afin que le projet puisse fonctionner, ou au moins fournir une base solide aux développeurs pour commencer. Le reste du travail consistait à communiquer avec les développeurs, à répartir les tâches, à surveiller les indicateurs et, en gros, à garder un œil sur Asana (pour estimer le délai de livraison du projet) et un autre sur Meet pour m'assurer que mon micro n'était pas allumé et que rien d'indésirable ne passait « accidentellement » entre les mailles du filet.

Conclusion et regard sur le passé - au maître avec affection

J'ai commencé ma carrière en tant que stagiaire en développement et, curieusement (et vous pourriez trouver cela un peu contradictoire de ma part), je n'ai pas eu d'expérience concrète (du moins pas formellement consignée dans mon dossier professionnel) qui me classerait comme développeur junior, à temps plein ou senior. Une grande partie de l'expérience que j'ai acquise est venue de projets personnels et de recherches à l'université. Ce fut un processus graduel jusqu'à ce que je réalise que mes compétences avaient évolué depuis ces premiers jours.

Mais oui, j'ai travaillé intensément en tant que développeur à différents niveaux et j'ai eu l'occasion de rencontrer différents types de professionnels seniors tout au long de ma carrière :

1. Le senior très compétent et efficace, mais peu communicatif, qui résolvait les problèmes sans fournir d'explications sur sa démarche.
2. L'aîné est excellent en communication et en enseignement, mais il est souvent débordé par des tâches urgentes et n'a pas le temps d'enseigner.
3. Le senior qui était enthousiaste à l’idée de sur-ingénierie et de centralisation de la technologie, mais qui respectait les délais et livrait ce qu’il avait promis.

Le plus important est que, malgré leurs défauts justifiables (même si c'est possible, il est très difficile de concilier les exigences), tous ces professionnels avaient quelque chose de précieux à enseigner. Ces expériences ont contribué à façonner ma carrière et m'ont donné une vision claire de ce qui fonctionne et de ce qui ne fonctionne pas dans le développement de systèmes.