Comment vous assurer que votre entreprise ne va pas sous l'eau si vos programmeurs gagnent à la loterie [fermé]

J'ai quelques programmeurs sous moi, ils font tous très bien et très intelligemment évidemment. Merci beaucoup.

Mais le problème est que chacun d'entre eux est responsable d'un domaine central, dont personne d'autre dans l'équipe n'a la moindre idée de ce que c'est. Cela signifie que si l'un d'eux est retiré, mon entreprise en tant qu'entreprise est morte car ils ne sont pas remplaçables.

Je pense à faire venir de nouveaux programmeurs pour les couvrir, juste au cas où ils seraient frappés par un bus, ou démissionner ou quoi que ce soit. Mais j'ai peur que

1. Les anciens programmeurs pourraient résister activement à l'idée de transfert de connaissances, craignant qu'une sauvegarde ne réduise leur valeur.
2. Je n'ai pas de système pour faciliter le transfert de technologie entre différents développeurs, donc même si je leur demande de le faire, je n'ai aucune assurance qu'ils le feront correctement.

Ma question est,

1. Comment le mettre aux anciens programmeurs de telle sorte qu'ils seraient d'accord
2. Quels systèmes utilisez-vous pour faciliter ce type de «sauvegarde»? Je peux comprendre que vous pouvez effectuer une révision du code, mais existe-t-il un moyen simple de procéder? Je pense que nous ne sommes pas prêts pour une vérification complète du code d'enregistrement par l'enregistrement.

Comment le mettre aux anciens programmeurs de telle sorte qu'ils seraient d'accord

Présentez-leur le problème ouvertement, de manière à ce qu'ils ne le voient pas comme une menace, mais plutôt comme une opportunité de faire mieux fonctionner l'équipe et le projet. Par exemple, "j'aimerais que d'autres personnes sachent ce que vous savez au cas où vous seriez viré" est évidemment une mauvaise approche :-) "j'aimerais assurer le bon fonctionnement du projet même si certains d'entre vous partent en vacances ou tombent malades " c'est bien mieux.

Habituellement, les développeurs eux-mêmes rencontrent eux-mêmes les problèmes chaque fois que certains d'entre eux sont en vacances et doivent les couvrir. De plus, les bons développeurs se sentent responsables du projet sur lequel ils travaillent, ils seront donc probablement d'accord avec cette idée. Néanmoins, donnez-leur le temps de discuter et (espérons-le) de vous engager dans l'idée. De plus, permettez-leur de s'exprimer sur comment et avec qui partager leurs connaissances au sein de l'équipe. Il se peut que Joe se sente d'accord pour travailler (et partager ses connaissances) avec Jim, mais pas avec Jack, etc.

Quels systèmes utilisez-vous pour faciliter ce type de «sauvegarde»? Je peux comprendre que vous pouvez effectuer une révision du code, mais existe-t-il un moyen simple de procéder? Je pense que nous ne sommes pas prêts pour une vérification complète du code d'enregistrement par l'enregistrement.

Dans notre équipe, outre les revues de code / conception, nous utilisons

• Rotation des tâches et des domaines de responsabilité entre les membres de l'équipe (chacun de nous a ses principaux domaines de responsabilité, mais de temps en temps, nous effectuons des tâches dans un domaine mieux connu d'un autre membre de l'équipe)
• Séances de transfert de connaissances en face à face (généralement lorsque les tâches ci-dessus l'exigent, mais aussi avant que quelqu'un ne quitte l'équipe)
• Wiki équipe / projet

La revue de code en elle-même peut ne pas être suffisante car dans de nombreux domaines, le développeur a généralement bien plus à savoir que ce qui est directement lisible à partir du code. En d'autres termes, il existe également le modèle de domaine . Vous pouvez lire ce que fait réellement le code, mais sans le modèle, vous ne saurez pas pourquoi .

Une façon de les motiver à partager leurs connaissances serait de leur demander de faire une courte présentation de leur travail à d'autres personnes. Les programmeurs sont normalement très fiers de leur travail, et ce serait l'occasion de le montrer. Une présentation est une bonne occasion de leur faire montrer certaines des bizarreries rarement connues des étrangers.

Aussi, pourquoi ne pas simplement être ouvert à ce sujet et dire à tout le monde que vous devez tous trouver un système de partage des connaissances au cas où quelqu'un serait heurté par un bus. Je ne vois pas cela comme déraisonnable. Cela se produit dans mon entreprise en ce moment, et bien que certains soient défensifs à ce sujet, ils savent que cela doit être fait.

Peut-être qu'ils pourraient travailler en binômes sur certaines choses, s'ils sont de nature curieuse, il ne devrait pas y avoir de problème.

La mise à jour de la documentation interne du logiciel devrait être la première étape, avant de commencer à embaucher de nouvelles personnes. Bien sûr, cela signifie que vos précieux programmeurs passeront du temps avec les outils Office et UML au lieu de l'IDE, mais je pense que cela en vaut la peine dans tous les cas.

Une fois que vous avez une documentation actuelle, vous pouvez laisser vos programmeurs la recouper pour vous assurer que tout le monde comprend ce que les autres ont écrit. Toujours pas besoin de nouvelles personnes.

Ensuite, vous pouvez envisager d'embaucher de nouvelles personnes. Ou non, selon la charge de travail de votre entreprise.

Si vous êtes dans une grande entreprise, vous pouvez appeler les RH et parler de ce problème. Croyez-moi, les gars de la comptabilité ont le même problème si le personnel clé est heurté par un bus. Les spécialistes du marketing auront également beaucoup de mal si un vendeur clé devient un zombie au milieu de négociations importantes - cela arrive souvent, du moins m'a-t-on dit.

Je crois que le bon langage RH pour cela est la planification de la succession . Votre entreprise a peut-être déjà une politique et des cadres pour y faire face.

Un endroit où je travaillais avait le même problème. Ils ont embauché un développeur junior pour travailler avec chaque développeur senior. Ils ont créé de petites équipes de 2 qui ont travaillé ensemble sur des projets. Tous les quelques mois ou projets, ils faisaient tourner les développeurs juniors entre les équipes. De cette façon, les développeurs seniors sont restés les experts en la matière, mais les développeurs juniors ont commencé à avoir une bonne compréhension de tous les systèmes et de la façon dont ils fonctionnaient ensemble. De plus, avec la taille de l'équipe, les projets de doublage ont été réalisés plus rapidement.

Pour les projets plus importants qui ont vu le jour, les développeurs seniors ont parfois été invités à agir en tant que développeur junior sur une autre partie du système pour la durée d'un projet afin qu'ils puissent commencer à apprendre les autres systèmes.

La clé était de respecter les connaissances et l'ancienneté des développeurs existants tout en élargissant et en développant l'équipe. Ce fut un processus lent mais au fil du temps a très bien fonctionné.

L'une des choses qui fait le succès des projets open source est le manque de «propriété» du code. J'entends par là que personne n'est le seul responsable d'un domaine de l'application - n'importe qui peut et est encouragé à contribuer à n'importe quelle partie de l'application. C'est quelque chose en quoi je crois fermement.

Ce que vous voulez faire, c'est d'expliquer que la façon dont les choses sont en fait nuit à l'équipe que vous avez actuellement. Voici les points que vous souhaitez faire passer, et de préférence dans cet ordre:

• Je ne peux pas vous libérer pour travailler sur d'autres trucs sympas qui descendent du brochet si vous êtes le seul à savoir comment cela fonctionne.
• Nous voulons que vous puissiez prendre de bonnes vacances, mais vous ne pouvez pas vous le permettre car personne d'autre ne peut faire ce que vous faites.
• C'est un fait désagréable que les gens changent d'emploi parce qu'ils ne sont pas satisfaits de leur position actuelle, nous ne voulons pas vous perdre parce que vous vous sentez piégé par la zone dans laquelle vous travaillez.

Sur une note personnelle, j'ai dû faire face à un collègue décédé. Bien qu'il n'y ait pas de silos d'informations, la perte a tout de même durement touché. Les chances que cela se produise sont bien inférieures au troisième point ci-dessus.

Une fois que vous avez présenté votre cas, demandez leur aide pour des idées sur la façon de résoudre le problème. Venez avec le vôtre bien sûr. Leurs idées les aideront à réaliser qu'ils font partie d'une équipe et qu'ils sont nécessaires pour plus que leur domaine d'expertise. Il se peut que Jane s'intéresse à ce que Joe fait, mais qu'elle se sent un peu intimidée par cela. Savoir cela peut aider à rendre le transfert de connaissances plus amusant. Certaines des choses que vous voudrez faire sont:

• Entraînez l'équipe actuelle. Vous pourriez perdre un peu d'efficacité à court terme, mais il peut y avoir des leçons apprises dans un coin de l'application qui peuvent être appliquées à d'autres parties de l'application. Demandez à Jane et Joe de travailler ensemble sur le projet de l'autre pendant un certain temps.
• Favorisez une culture de partage des connaissances. Une entreprise pour laquelle je travaillais avait un programme "brown bag tech talk". N'importe qui pouvait présenter un sujet approuvé (présentant généralement des processus technologiques ou logiciels). L'entreprise a pris le déjeuner et le présentateur a obtenu quelques centaines de dollars pour leurs efforts.
• Le mentorat devrait être un mode de vie. Le mentorat d'autres personnes a pour but de vous libérer pour faire de nouvelles choses et vous rend encore plus précieux pour l'entreprise.
• Trouvez des moyens de franchir les frontières du silo d'informations sans tirer de rang. Plus vous vous amusez, moins il sera menaçant. Si les gens de votre équipe sont aussi bons que vous le dites, ils ne sont probablement pas complètement satisfaits de la façon dont les choses sont. Vous devrez juger si l'équipe peut y faire face, mais vous pouvez avoir une semaine «choisissons telle ou telle chose». Commencez toujours par vous-même ici. L'idée est d'obtenir les yeux de tout le monde sur les responsabilités de "tel ou tel" et sur la manière dont ils peuvent mieux résoudre les problèmes qu'ils rencontrent. Tant que vous commencez avec votre cou sur la ligne, ils auront l'idée que personne n'est sorti pour faire leur travail

En général, essayez de leur faire comprendre que vous voulez rendre le travail plus agréable et que vous avez besoin de leur aide pour le faire.

Les stagiaires peuvent être une bonne idée, ils seront directement subordonnés aux développeurs actuels, donc ils ne se sentiront pas menacés.

Au fur et à mesure que l'entreprise se développe, vous aurez besoin à la fois d'anciens développeurs ET de ceux qui l'ont fait après leur stage.

Je pense que cela pourrait fonctionner.

Généralement, lorsqu'un gestionnaire commence soudain à se soucier de la documentation et de la planification de la relève, c'est un signe d'avertissement fort que les programmeurs sont sur le point d'être licenciés ou licenciés. C'est un tel écart par rapport au comportement de gestion typique et aux préoccupations qu'il déclenche toutes sortes de signaux d'avertissement chez les programmeurs.

Chacun est invité à documenter toutes ses procédures et processus

Niveau 3 de " Signes avant-coureurs de la mort d'entreprise ».

Comme alternative, un essai suggère que nous encouragerions une culture de " Up or Out " bien que le contre-argument soit que très peu d'entreprises ont une échelle de carrière technique qui ressemble en quelque sorte au spectre financier et de puissance que l'échelle de carrière (mauvaise) managériale contient.

S'appuyant sur le concept de documentation complète que @ammoQ a commencé dans sa réponse ...

Un bon gestionnaire s'efforce de développer les compétences de ses subordonnés directs afin que n'importe lequel des subordonnés puisse les remplacer. Faites comprendre à vos développeurs qu'un employé qui assure une transparence totale de son travail a plus de valeur qu'un employé qui garde tout son travail secret et caché. Si le développeur «secret» mourait aujourd'hui, il serait très coûteux pour l'entreprise de retrouver cette perte de connaissances. Si l'employé «divulgation complète» décédait aujourd'hui, l'entreprise serait toujours à perte, mais ce serait moins dévastateur. Par conséquent, l'employé «divulgation complète» a plus de valeur.

Tout employé qui essaie de garder des connaissances cachées afin de se mettre à l'abri du licenciement se met également à l'abri d'une promotion. Vous ne pouvez pas déplacer un développeur vers une position plus stimulante et gratifiante s'il n'y a personne pour accomplir les tâches banales dont il est chargé aujourd'hui. Si les tâches banales sont entièrement documentées et entièrement divulguées, vous pouvez embaucher un nouveau développeur junior pour remplacer et promouvoir le développeur précédent à un poste plus élevé.

Cela signifie que vous aussi devez documenter ce que vous faites et fournir une formation à chacun de vos subordonnés directs. De cette façon, si vous décédez aujourd'hui, l'un d'eux pourrait vous remplacer jusqu'à ce qu'un remplaçant à temps plein soit trouvé.

Avant de commencer à faire venir de nouveaux programmeurs, je demanderais à chacun d'aider à créer son propre héritage documenté.

Soit avec un wiki, soit une bible à 3 anneaux de documents sur tous les aspects de leur travail.

Ou si vous voulez une documentation vraiment détaillée et approfondie, embauchez un rédacteur technique, pour interviewer chaque programmeur et ensuite créer une documentation de tout, tout le monde le fait, quotidiennement, hebdomadairement, mensuellement, annuellement.

Ensuite, faites-en une version wiki, que votre programmeur peut mettre à jour / modifier / participer / commenter.

Ensuite, vous avez un système qui grandira avec le temps et sera la courbe d'apprentissage améliorée pour tout nouveau programmeur.

Honnêtement, il n'est pas sage d'avoir un programmeur simplement coincé dans un domaine central, cela paie vraiment de s'entraîner, de travailler entre des cœurs.

Ensuite, vous pouvez utiliser votre personnel existant, lorsqu'une personne prend des vacances ou quelque chose comme ça.

Chaque fois qu'un de vos programmeurs est malade, appelez-le à plusieurs reprises pour lui poser des questions et lui poser des problèmes.

Chaque fois qu'un de vos programmeurs est en vacances, appelez-le à plusieurs reprises pour lui poser des questions et lui poser des problèmes.

Ils se rendront bientôt compte qu'il est préférable pour eux ainsi que pour l'entreprise de ne pas avoir de personnes seules responsables des domaines clés.

Personne ne veut se faire frapper par le bus, mais il ne veut pas non plus avoir à reprendre le projet de quelqu'un à court préavis et à maintenir son projet également. Ensuite, tout le monde court le risque de faire faillite.

Si vous développez en silos, vous devez commencer à déplacer les gens d'un projet à un autre. Commencez par la documentation, la révision du code ou la correction d'un simple bug. Tout petit acte de protection / territorialité du code doit être traité avant que cela ne devienne trop incontrôlable.

Avoir un seul spécialiste sur un morceau de votre code est une illusion d'efficacité.

Quelqu'un a-t-il déjà voulu partir en vacances?

J'ai eu de nombreuses autres entreprises en raison d'erreurs stupides de la part de la direction. Vous ne planterez pas et ne brûlerez pas si un ou deux ingénieurs partent, vous devrez juste travailler un peu plus dur pendant un certain temps. Sheesh, je gère une équipe offshore qui perd quelqu'un chaque trimestre. Commencez à déplacer les tâches. Aujourd'hui.