Ce qu'on n'apprend pas à l'école : comment nous formons les ingénieurs du support technique

Voici l'histoire tant attendue.

Défi

Si quatre ans auparavant on m'avait demandé : « Comment peut-on former des débutants dans un service informatique / une entreprise ? » — j'aurais répondu sans hésiter : « En utilisant la méthode 'la singe voit - le singe imite', c'est-à-dire attachez le débutant à un employé plus expérimenté et qu'il observe comment les tâches typiques sont effectuées. » Cette approche a fonctionné pour moi par le passé, elle fonctionne encore aujourd'hui, et il y a quelques temps chez Veeam, quand les arbres étaient grands, les logos verts et le produit petit, on pouvait aussi former de cette manière — et on le faisait !

Avec le temps, le produit est devenu grand et complexe, de plus en plus d'ingénieurs sont arrivés et l'approche RTFM (Read The Freaking Manual) a de moins en moins bien fonctionné — le fait est que cette méthode est adaptée à ceux qui sont déjà 'dans le coup', qui comprennent la spécificité du travail et ont besoin de certaines détails, moins critiques.

Mais que faire avec ceux qui viennent d'autres domaines et souhaitent grandir et se développer, mais ne savent pas comment s'y prendre ? Que dire, par exemple, de ceux qui maîtrisent une langue relativement rare (comme un italien rare pour un informaticien moyen) ? Ou comment former de cette manière un jeune diplômé prometteur qui n'a pas encore beaucoup d'expérience professionnelle ?

Suspendons un instant notre récit et imaginons : vous, team lead dans une équipe de support, anciennement un bon et réussi ingénieur, avec une grande expérience en administration système et en communication avec différentes personnes. Votre tâche est de transmettre votre expérience à un nouveau (on peut même dire 'vert') ingénieur, diplômé de l'université, intelligent et judicieux. Il y a juste un détail — c'est une personne sans expérience en support et même en simple helpline, et en plus, il sera le premier ingénieur turcophone dans votre entreprise.

Comment allez-vous résoudre ce problème ?

Et quand vous aurez répondu à cette question (et vous le ferez, j'en suis sûr), compliquons la tâche — que se passerait-il si de tels ingénieurs étaient dix ? Et si vingt ? Et si ce développement de département était constant, avec à tout moment un nouveau venu à former, à qui montrer le standard minimal de qualité de travail (et ce standard est élevé) et faire en sorte que la personne ne veuille pas s'en aller le plus vite possible ?

(Veuillez réfléchir à cette question avant de lire plus loin.)

Notre Histoire

C'est exactement ce à quoi nous avons été confrontés.

Tant que le département était relativement petit, le schéma de « fournir un mentor au nouvel arrivant, une liste de documents et de le laisser travailler - nage ou coule » fonctionnait bien. C'est un schéma bon, universel, établi par des années et même des siècles d'expérience humaine - mais à un moment donné, nous avons réalisé que nous étions fatigués des répétitions. Il faut expliquer certaines choses à chaque nouvel arrivant - la même chose qui pourrait lui être utile dans son travail. Dans le schéma « traditionnel », cela est pris en charge par le mentor, mais que faire si certains mentors ont des protégés qui suivent l'un après l'autre ? Répéter la même chose devient vite ennuyeux, ce qui crée un risque d'épuisement.

C'est alors que nous nous souvenons d'un autre schéma tout aussi traditionnel - rassembler les nouveaux dans des groupes et leur donner des cours - c'est ainsi qu'est née notre programme de formation.

… Parfois, nos ingénieurs participent à des conférences, qu'elles soient internes, externes, tierces ou organisées par nous-mêmes. C'est à partir de l'un de nos événements que la formation dans le support a commencé, telle qu'elle est aujourd'hui.

Un de nos ingénieurs a présenté une brillante présentation sur Veeam Backup & Replication à VeeamOn à Las Vegas, et avec quelques ajustements, elle est devenue la conférence “Composants”. À ce moment-là, nous avions déjà plusieurs cours sur différentes parties de la fonctionnalité, mais c'est cette présentation qui a « donné le ton » à toutes celles qui ont suivi. C'est la manière dont cette présentation a été structurée, les matériaux utilisés, etc., qui est devenue notre standard.

Nous avons commencé à parler beaucoup de virtualisation, des technologies Microsoft, de nos propres produits, et avons introduit des formations de base pour nos nouveaux arrivants sans expérience en IT, au cours desquelles nous expliquons tout ce qui peut être nécessaire à un ingénieur du support - en commençant par le « matériel » et en augmentant les niveaux d'abstraction : API de disque, systèmes d'exploitation, applications, mise en réseau, virtualisation.

Bien sûr, nous savions et savons que tenter de couvrir toute la gamme des technologies que nous utilisons par des formations serait impossible ou, du moins, peu judicieux. Pour former à toutes les fonctionnalités d'un produit, il faut déjà plusieurs mois, et le produit n'est pas statique, de nouvelles choses apparaissent en permanence. De plus, seules les formations-conférences, telles qu'elles sont, ne peuvent pas fournir tout ce dont un futur ingénieur a besoin.

Mais que fait-on d'autre ?

J'aime dire que nous appliquons la règle de Pareto : grâce à nos formations, nous fournissons environ 20 % de ce qu'un ingénieur à succès doit connaître, et les 80 % restent de sa responsabilité - lecture de manuels, travail en laboratoire, résolution de tickets de test et d'incidents, etc.

20 % - la formation - est en réalité presque 100 % de la base théorique, mais une théorie seule ne suffit pas - le schéma classique des Connaissances-Compétences-Savoir-faire s'applique. Nous pouvons fournir des Connaissances, mais développer des Compétences et les transformer en Savoir-faire est une tâche complètement différente.

C'est pourquoi nos premières leçons théoriques ont rapidement été complétées par d'autres éléments, et maintenant le schéma général se présente ainsi :

• Cours/ Formations ;
• Travail autonome ;
• Mentorat.

Pour le premier point, c'est assez clair : nous prenons un groupe de débutants, leur expliquons la théorie et passons doucement au deuxième point, en leur assignant à la fin de la leçon un « devoir à domicile » - une tâche pratique que le débutant doit « jouer » en laboratoire et rendre un rapport d'une certaine forme (généralement sous forme libre, mais il peut y avoir des exceptions).

Nous formulons intentionnellement les tâches de manière assez générale, évitant les instructions précises « va là, fais cela, note ce que tu vois ». Au lieu de cela, nous posons simplement une tâche (par exemple : déploie une machine virtuelle avec cette liste de composants) et demandons de réaliser une sorte d’« étude » sur le résultat obtenu, sans s'attarder sur la méthode à adopter ni sur la manière de vérifier le résultat. Cela vise à enseigner aux débutants (surtout ceux qui sont éloignés au début de leur parcours du monde de l'IT et de la façon de penser de la communauté ingénieure) à penser de manière autonome, à lire de la documentation et à analyser les problèmes émergents, et surtout, à comprendre leurs limites.

Nous savons tous que parfois, résoudre un problème peut conduire à une impasse, comme si une muraille se dressait devant nous, que l'on ne peut pas franchir. Comprendre dans quels cas il vaut mieux persévérer à frapper la tête contre le mur et quand il est temps de trouver quelqu'un qui peut aider est également une compétence très importante pour un ingénieur travaillant en équipe.

Pour nous, ce « guide » pour les débutants est le mentor.

Il est tout simplement impossible de sous-estimer un mentor. Jugez par vous-même, il est le premier "point de contact" pour le novice qui lui est assigné, celui qui peut répondre à la plupart des questions et aider dans la majorité des situations — et corriger les mauvais schémas (dans le domaine technique, l’éthique des affaires, la culture de l’entreprise) que peut manquer un entraîneur, voire même un chef d’équipe.

Et c’est tout à son sujet ?

Des cours, du mentorat, du travail autonome — voilà trois éléments fondamentaux qui composent notre programme de formation. Mais est-ce tout ce qu’on peut dire ? Bien sûr que non !
Même avec un bon schéma, quatre programmes de formation complets (le cinquième est en préparation), nous ne cessons d'enrichir notre "réservoir de connaissances". La formation est aussi vivante que notre produit, et par conséquent, de nouvelles informations et de nouvelles façons de les transmettre émergent constamment.

Par exemple, une étape importante pour nous a été la prise de conscience que nous répétons en effet l'apprentissage scolaire/universitaire presque à l’identique, et cela ne fonctionne pas toujours. Nous enseignons à des adultes, avec de l’expérience, avec leurs peurs et préférences. Et ce système "scolaire" en effraie un peu certains (appelons les choses par leur nom — dans 95 % des cas, toute frustration liée à ce modèle scolaire provient de la peur) : nous avons tous traversé l’école et l’université d’une manière ou d’une autre, et la plupart du temps, cela a été une expérience traumatique, donc nous n’avons vraiment pas envie de la répéter.

C’est de là que nous commençons (oui, seulement commençons, mais "le chemin de mille lieues..." et ainsi de suite) à repenser nos approches. Nous avons rappelé/découvert l'andragogie (l'enseignement des adultes — par opposition à la pédagogie, qui concerne essentiellement l'enseignement des enfants) avec son orientation sur l'expérience, la compréhension des objectifs, les nuances concernant l’assimilation de l’information et le confort des apprenants, l’importance de l’aspect émotionnel (qui est même plus critique pour les enfants), la nécessité de pratiques concrètes, etc. Nous avons pris conscience du cycle de Kolb et maintenant nous faisons évoluer nos formations, réfléchissant à la façon d’amener même des personnes totalement "hors-sujet" à la formation avec un certain vécu, que nous allons aider à actualiser et à enrichir, approfondir et polir, et, ce qui est important, fournir non seulement une théorie creuse, mais aussi des connaissances pratiques pouvant être transformées en compétences grâce à un mentor ou de manière autonome.

Nous avons invité des formateurs professionnels qui ont travaillé avec nos conférenciers sur leurs compétences en prise de parole en public, leur ont parlé des émotions, ont pratiqué l'assertivité, ont donné des outils pour gérer la dynamique de groupe et, bien sûr, nous ont aidés à répondre aux questions « que voulons-nous apprendre ? » et « quel est notre objectif final ? ». Les résultats sont déjà là — certains séminaires qui recevaient le plus de retours du type « c'est ennuyeux et incompréhensible » sont maintenant considérés comme les plus intéressants et touchants — alors que le conférencier est resté le même !

De plus, il y a peu de temps, nous avons accueilli une paire de jeunes très motivés, qui parlent du Support Centré sur les Connaissances et de la façon de construire des cours vidéo — et nous en avons tiré de nombreuses bonnes idées pour les transformer et passer d'un style « enregistrement de webinaire » à des cours attrayants et simples, qui expliquent clairement tout ce que nous voulons, sans se noyer dans la diversité des méthodes de présentation de l'information.

De plus, nous nous consacrons maintenant non seulement à la composante technique de l'apprentissage, c'est-à-dire les fameuses hard skills, mais nous travaillons également sur les soft skills, non seulement pour les conférenciers ou la direction, mais aussi pour les ingénieurs. Nous faisons cela pour qu'un certain Ignat, en rejoignant l'entreprise, puisse pratiquer les compétences qui lui seront à 100 % nécessaires dans son travail, gérer ses émotions et savoir que dans n'importe quelle situation, même la plus complexe et désespérée, il ne sera pas seul : car le Support, c'est avant tout une question humaine, et « nous ne laissons pas les nôtres dans le besoin ». Avant les premiers appels entrants, nous jouerons avec le nouveau dans des jeux de rôle, l'aidant à s'intégrer dans le processus et à trouver son style de réponse ; avant les premiers cas, nous expliquerons comment les traiter au mieux et quoi surveiller, et tout au long du processus, nous veillerons et aiderons.
Nous sommes le support. Et qui devrions-nous aider d'abord, sinon les nôtres ?

Et pour conclure, quelques mots…

Je suis conscient que mon discours semble élogieux. Et pourtant, je ne me vante pas — c'est notre histoire, notre présent et juste une petite partie de nos projets futurs.

Notre formation n'est pas parfaite. Nous avons de nombreux défauts et nous avons commis beaucoup d'erreurs — quelle galère ! Nous recevons beaucoup de retours, et la plupart du temps, ce ne sont pas des éloges. On nous parle de problèmes, de défauts, d'améliorations souhaitées — et comme nous formons à l'échelle mondiale, cela génère une grande variété de retours, sans mentionner les différences culturelles…

Nous avons des marges de progression, et Dieu merci, nous avons des personnes prêtes à travailler, à critiquer, à débattre et à proposer des nouveautés. C'est une grande ressource et un précieux soutien.

Et le Support — c'est à propos des personnes — ce sont justement les gens qui rendent la formation efficace, et cette formation aide les nouveaux employés à apporter de la valeur plus rapidement et à devenir de bons ingénieurs plus vite, tandis que de bons ingénieurs rendent le monde meilleur.

… et sur ce, permettez-moi de terminer mon discours autorisé.

Source : habr.com