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

28

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.
Graviton
la source
4
Vous pouvez toujours mentionner que la redondance dans une zone donnée vous permet de GARDER cette zone au lieu d'avoir à chercher une autre zone. Cela vaut également pour la connaissance de la programmation, ce qui permet de garder leur travail PLUS SÛR que les autres savent ce qu'ils savent.
1
À un emploi, nous avions une piscine de loterie de bureau. Le directeur a insisté pour se joindre, au motif qu'il ne voulait pas être coincé là si nous étions tous libérés sous caution.
David Thornley
3
Jeff? Est-ce vous! Bon sang, il vaut mieux ne pas essayer de nous tuer!
2
Pourquoi dans le monde le titre a-t-il changé - "frappé par un bus" est une idée si connue, ce sujet a son propre nom et un article Wikipedia: numéro de bus . Vous n'entendez pas les gens parler du «numéro de loterie» de leur équipe .
Nicole
1
@Carra, malheureusement, la question n'est pas la même - vous ne pouvez pas persuader quelqu'un qui a été heurté par un bus de rester pour l'amour du jeu! :)
Nicole

Réponses:

19

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 .

Péter Török
la source
Team/project wiki, Pouvez-vous élaborer sur ce sujet? Et aussi, face-to-face knowledge transfer sessionstenez-vous ce genre de session régulièrement à une heure fixe?
Graviton
@Graviton, nous nous efforçons de documenter la conception et la mise en œuvre de notre système (hérité) sur le wiki du projet. Ceci est plus facile à éditer et à mettre à jour (par n'importe quel membre de l'équipe) que par exemple des documents Word séparés, et permet également des liens gratuits entre n'importe laquelle des pages. Les transferts de connaissances que nous effectuons en cas de besoin, sur un outil spécifique ou une partie du projet.
Péter Török
Knowledge transfers we do on when needed, c'est probablement pendant le temps où un membre du personnel démissionne? Le temps nécessaire pour cela n'est-il pas un peu trop court?
Graviton
@Graviton, non, ce que je voulais dire, c'est à chaque fois que certains d'entre nous sont affectés à une tâche dans un domaine mieux connu par quelqu'un d'autre. (J'ajouterai cela à la liste ci-dessus, car c'est en fait un excellent moyen de créer une "sauvegarde des connaissances".)
Péter Török
12

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.

dr Hannibal Lecter
la source
4

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.

user281377
la source
@ammoQ, pas trop sûr que cela évolue; que se passe-t-il après avoir employé de nouvelles personnes, allez-vous dessiner à nouveau l'UML? Et si l'architecture de conception change? Avez-vous un système pour les examiner?
Graviton
2
@Graviton: Les nouvelles personnes viennent de lire la documentation écrite par le personnel existant. Pas besoin de dessiner à nouveau les diagrammes UML. Si l'architecture change, vous devez adopter la documentation. Ouais, ça craint, je sais. Mais il existe des outils UML pour vous aider, ils lisent le code source et génèrent des diagrammes de classe et d'autres choses.
user281377
BTW, comment pensez-vous que le nouveau personnel apprendra les composants internes du logiciel alors qu'il n'y a que le code source à apprendre et les programmeurs existants à demander?
user281377
@ammoQ, je ne sais pas; si je savais que je n'aurais pas à poser la question.
Graviton
1
@oosterwal, heureusement, nous pouvons utiliser un système de gestion de build standard (Maven) maintenant, donc il n'y a qu'un besoin minime de documenter les détails du processus de build. (Et si un membre de l'équipe ajoute de nouveaux modules sans mettre à jour la configuration de build, nous recevons tous un mail du serveur d'intégration continue en 5 minutes, disant que la build est cassée, et par qui.) Mais oui, quand j'ai écrit personnalisé des scripts pour automatiser les builds et les releases, je les ai bien documentés.
Péter Török
4

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.

Vitor Py
la source
4

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é.

Amy Patterson
la source
4

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.

Berin Loritsch
la source
2

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.

Mahmoud Hossam
la source
1

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.

Tangurena
la source
Je ne suis pas d'accord. La valeur d'une entreprise dépend fortement de la propriété intellectuelle (PI). Cela inclut les brevets, les processus et toute la documentation interne. Un employé qui ne veut pas partager ses connaissances secrètes en les documentant ne vaut pas le papier sur lequel leurs connaissances secrètes sont écrites. Les connaissances secrètes d'un employé n'ajoutent pas de valeur tangible à une entreprise.
oosterwal
1
@oosterwol - être capable de constituer et de gérer une équipe de développement productif est un bien meilleur prédicteur de l'évaluation. Dire que vous avez une bonne documentation, c'est comme dire que vous avez un excellent contrôle des sources. Bien sûr, ils sont nécessaires, mais cela ne vous différenciera pas de la concurrence.
JeffO
@Jeff O: La documentation ne vous différenciera pas de vos concurrents aujourd'hui car toutes les connaissances IP sont dans la tête des développeurs actuels . Dans cinq ans, lorsque tous les développeurs actuels seront passés à des entreprises qui valorisent la documentation, les nouveaux développeurs auront du mal à maintenir l'ancien code et à ne pas mettre en œuvre des idées qui se sont avérées mauvaises par le passé, mais qui n'ont jamais été documentées.
oosterwal
1

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é.

oosterwal
la source
Pourriez-vous fournir un lien vers un document sur Internet qui illustre une spécification suffisamment bien écrite pour créer une application entière de taille importante? Je pense que cela relève du mythe urbain.
JeffO
1
@Jeff O: Vous avez raison - il n'y a pas de document unique suffisamment complet pour décrire un système complet de taille substantielle. L'idée que vous pourriez décrire un tel système dans un seul document est le résultat d'une mauvaise gestion de projet et d'un historique de spécifications mal écrites. Un système substantiel doit être spécifié avec une série hiérarchique de documents. Le document racine fournit une présentation de haut niveau du système et des liens vers ses documents enfants. Chaque document enfant fournit des informations supplémentaires jusqu'à ce que les documents du nœud final spécifient une seule entité tangible.
oosterwal
1

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.

crosenblum
la source
1

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.

Carson63000
la source
0

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?

JeffO
la source
0

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.

SnoopDougieDoug
la source