Meilleure façon de former de nouveaux employés [fermé]

L'équipe dont je fais partie fait actuellement l'expérience d'un roulement de personnel assez élevé, avec des membres qui évoluent généralement vers différents projets au sein d'une même entreprise. Actuellement, notre «formation» pour les nouveaux membres consiste à les jumeler avec un contact principal (généralement la personne la plus récente pour terminer leur formation) qui leur fournira une expérience pratique et demandera à des développeurs plus expérimentés si le nouveau recruteur demande quelque chose au mentor. ne sait pas. Cela permet au nouvel employé de s'impliquer rapidement et incite le mentor à améliorer également sa compréhension du système.

Cependant, comme vous pouvez l'imaginer, ce style de formation prend beaucoup de temps et n'offre pas un très bon transfert de connaissances (les idées fausses se propagent, les lacunes se creusent).

J'ai été chargé de générer de la documentation et du matériel de formation pour nos futures nouvelles recrues. Je fais déjà de la rédaction technique à l'occasion, mais c'est pour l'utilisateur final et est très spécifique avec beaucoup de captures d'écran et prend beaucoup de temps pour terminer.

La création de la nouvelle documentation pour les nouveaux employés est considérée comme une priorité faible et je n'ai actuellement que ~ 40 heures pour y travailler. Documenter le système de la façon dont j'écris actuellement la documentation technique rayerait à peine la surface en 40 heures. Surtout que je dois documenter non seulement sur la base de code, mais aussi sur les déploiements et le support.

Comment puis-je rédiger rapidement de la documentation pour mettre à jour les nouveaux employés le plus rapidement possible sans investir beaucoup de temps dans la rédaction de la documentation?

Informations supplémentaires:
Nous avons actuellement à la fois un wiki et une documentation de formation, mais les deux sont plutôt clairsemés.

Bonne question. La formation en cours d'emploi du programmeur est très rarement prise au sérieux, et on n'en parle pas souvent.

Certaines idées que j'ai vues fonctionnent bien:

• Dans votre wiki, ayez un document d'accélération de la nouvelle embauche (celui que vous écrivez). Dans ce document, décrivez les tâches que le nouvel employé effectuera pendant les 1 à 2 premières semaines. Là où je travaille, il y a beaucoup de choses à savoir dès le départ, des logiciels / outils internes, aux processus, aux emplacements de types spécifiques d'informations. modifier> nous avons des instructions comme "installer x, y, z dans l'ordre" avec des captures d'écran pour la configuration, etc. des sons. Cela vaut pour les autres versions de ces applications que nous prenons en charge.
• Problèmes de pratique. Où je suis, nous avons un produit qui expose une API de grande taille. Il est donc toujours avantageux pour nous de parcourir notre propre documentation sur les produits pour écrire des extensions (prédéterminées) comme le feraient nos clients / clients. Donc, si vous aviez une bibliothèque mathématique dans le cadre de l'API de votre produit, rencontrez un problème de pratique qui est «écrire une calculatrice en utilisant notre API» ou quelque chose comme ça.
• Les mentors sont bons. Garde les. Nous le faisons ici aussi, et non seulement c'est un bon moyen de rencontrer des gens / se faire des amis, mais ils sont inestimables comme source d'apprentissage. Je recommande de ne pas avoir la personne la plus récente pour terminer la formation car ils n'ont pas l'historique des connaissances d'entreprise que quelqu'un d'autre pourrait avoir. Demandez à tout le monde de le faire sur une rotation.
• Nous faisons (à peu près) des présentations / discussions techniques hebdomadaires. Demandez aux nouveaux employés de choisir quelque chose dans votre produit (ou attribuez-le) et faites une présentation après leur 3e semaine. Assurez-vous qu'ils savent qu'il y a place pour qu'ils se trompent et que l'équipe puisse les corriger s'ils foutent quelque chose dans la présentation.
• Demandez aux nouveaux employés de travailler sur la documentation lorsqu'ils commencent. Cela les oblige à le lire.

Comme le note Dan McGrath, c'est une bonne idée d'encourager les nouveaux employés à améliorer également le wiki pour eux.

Tout d'abord, je dirais que vous n'avez pas besoin de rendre votre document de formation à l'embauche aussi complet que quelque chose que vous écririez pour un client. Il doit être suffisamment technique pour qu'un nouveau développeur puisse l'utiliser comme guide, mais pas si détaillé qu'il décrit chaque petite chose. Après tout, ils pourront parler avec l'équipe s'ils ont des questions.

Quelles sont les 10 principales choses qu'un nouvel employé doit savoir pour être utile à votre équipe? Concentrez-vous sur ces choses. Faites-en votre liste de résultats pour qu'un nouveau développeur ait suffisamment à faire et suffisamment d'informations pour continuer. Si vous avez trop de choses sur la liste, demandez-vous si elles le feront au cours de leurs deux ou trois premières semaines. S'ils ne feront pas quelque chose pendant cette période, alors cela ne devrait peut-être pas figurer dans le guide d'intégration.

Pour chaque section de votre guide, assurez-vous qu'une personne de référence est mise en évidence en haut. De cette façon, si le nouvel employé a des questions, il sait à qui s'adresser pour obtenir de l'aide. De plus, assurez-vous qu'un membre de l'équipe n'est pas la personne de référence pour trop de sections. Vous ne voulez pas consacrer du temps à une seule personne pour poser des questions aux nouveaux employés si elle n'est pas le mentor.

Ne passez pas toute votre semaine sur ce document. Laissez-vous le temps de l'ajuster après avoir laissé passer au moins une nouvelle embauche. Voyez ce qui fonctionne bien, ce qui ne fonctionne pas et corrigez.

J'ai récemment commencé sur un document similaire sur mon lieu de travail, avec des contraintes de temps similaires. J'insiste sur le fait qu'il est facile de vouloir l'écrire à un niveau très détaillé, comme je l'ai fait au début aussi, mais cela pourrait en fait être contre-productif.

Si une nouvelle personne commence à jouer un rôle, elle est probablement inondée d'informations pendant les premières semaines. Le fait que leur formation initiale soit une décharge de cerveaux d'un développeur qui travaille dans une entreprise depuis un certain nombre d'années compliquera dans mon esprit ce que quelqu'un a besoin de savoir pendant ses premiers mois ou même sa première année dans ce poste. Gardez-le à un niveau élevé, essayez d'utiliser un jargon et des concepts standard, puis développez-les avec les spécificités des processus de l'entreprise.

Pour moi, la première itération de ce document est simplement un aperçu du SDLC que nous utilisons sur mon lieu de travail, avec une liste des rôles associés à chaque étape, quelques exemples de personnes qui remplissent ces rôles et des listes de contrôle spécifiques associées à à chaque étape du cycle de vie. Personnellement, je trouve les listes de contrôle indispensables à la formation, mais aussi à peu près tout ce que je fais au travail. Par exemple:

• Le chef de projet (Joe) vous attribue une tâche dans Jira.
• Définissez un temps d'achèvement estimé pour la tâche en fonction de la formule x.
• Définissez le ticket comme «en cours» lorsque vous commencez à travailler dessus.
• Créez une branche depuis git, cliquez sur le lien pour voir une vidéo de 30 secondes sur cette progression.
• Écrivez les tests unitaires en fonction des contraintes du document de conception, voir page y pour les conventions de dénomination des tests unitaires.
• Définissez le ticket pour la révision et soumettez le code au système de révision .. 'etc.

Nous espérons que votre nouvel employé connaîtra la majorité des concepts et aura maintenant un guide étape par étape sur la façon dont les processus sont appliqués dans l'entreprise. Je fais également une démo rapide du processus du début à la fin en utilisant de vrais documents de projets qui me semblent bien exécutés.

Comme mentionné, c'est aussi un document évolutif, de sorte que les sections peuvent être développées car il est identifié qu'elles ont besoin de plus d'informations. Toute l'équipe devrait être impliquée dans sa mise à jour. Cela peut être un wiki, un document OneNote, peu importe, mais quelque chose que tout le monde peut éditer et réviser, puis commencer à impliquer d'autres personnes dans l'amélioration quand ils ont une heure de libre ici et là. De cette façon, une personne ne le fait pas et ne propage pas sa propre rotation sur le processus à toutes les nouvelles embauches.

Une fois qu'ils ont examiné le processus, demandez-leur de suivre une petite fonctionnalité / correction de bogue sur un projet non critique et demandez-leur de poser des questions que le document ne couvre pas. Enregistrez quelles sont ces questions, car elles devraient probablement être les premières choses que vous ajoutez au document la prochaine fois que vous y travaillerez.

Vous ne pouvez pas combiner faire quelque chose comme ça sans passer du temps. Au moins, si vous voulez le faire vous-même. Vous devez vous demander s'il est vraiment nécessaire de le documenter aussi précisément que vous essayez?

La seule alternative serait de laisser les nouvelles recrues faire le travail principal. Laissez-les écrire quelques parties. Le temps que vous passez à les corriger (sous forme de feedback) sera moindre que dans vos situations actuelles. Fournissez de bons modèles et vous n'avez pas à vous soucier de la mise en page.

Je crois que vous savez déjà qu'ils vous ont confié une mission impossible. En tant qu'écrivain, vous connaissez probablement déjà la citation de Mark Twain:

Si j'avais plus de temps, j'aurais moins écrit.

Étant donné pratiquement aucune ressource, le mieux que vous puissiez faire est probablement d'obtenir un classeur et de demander à tout le monde de faire une copie de ce qu'ils ont déjà et de le mettre dans le classeur. De cette façon, vous pouvez au moins dire à la nouvelle recrue "Si vous voulez rechercher quelque chose sur le système, le point de départ est dans le classeur".

Une bonne écriture prend du temps, point final. De plus, il doit être adapté au public cible. Ce qui fonctionne pour les utilisateurs finaux ne sera pas ce dont un programmeur a besoin.

Sans oublier qu'une bonne formation ne se limite pas aux documents écrits, elle comprendrait une gamme complète de ressources éducatives, y compris en ligne, en classe, multimédia, etc.

Comme ils disent: "Si vous pensez que l'éducation coûte cher, essayez le coût de l'ignorance."

De plus, il va sans dire que considérer la documentation comme quelque chose à faire après coup plutôt que d'en faire une partie intégrante du processus dès le premier jour est révélateur d'un problème organisationnel systémique.