Comment empêcher un employé de prendre l'entreprise en otage ?

Que puis-je faire pour remédier à cette situation ?

Rien, vous n'êtes là que depuis quelques mois, ce n'est pas votre rôle et vous n'avez pas le pouvoir de faire quoi que ce soit sauf vous plaindre.

Vos supérieurs ont beaucoup de recours, mais ne les ont pas utilisés depuis 7 ans, donc à ce stade, vous ne faites que remettre en question leurs raisons et analyser un collègue au lieu de vous concentrer sur vos propres responsabilités et tâches.

Engagez deux ou trois des développeurs les plus intelligents que vous pouvez trouver. Donnez-leur tout le code. Laissez-les vérifier qu'ils ont bien tout le code, tout ce qui est nécessaire pour faire fonctionner le logiciel. Faites-leur apprendre ce que fait le code, documentez-le, refaites-le, jusqu'à ce qu'ils arrivent au point où ils peuvent résoudre les problèmes plus rapidement que M. A. Tout cela évidemment sans aucune connaissance de A.

À ce stade, vous vous assurez de couper complètement les ressources de M. A, de transférer le travail à vos nouveaux développeurs, et d'informer M. A que son emploi est terminé.

Je pense qu'avec les méthodes de développement de M. A, la quantité de travail que son code fait est en fait bien inférieure à sept ans de développement normalement produits, et que le code est obscurci, mais pas vraiment difficile, ce qui rend le travail des nouveaux beaucoup plus facile.

PS. En raison de certains commentaires, je tiens à souligner à nouveau ce point : Le problème n'est pas seulement l'argent, le problème est que le logiciel est beaucoup moins bien développé qu'il ne pourrait l'être, parce que A se concentre sur le fait de rendre le développement difficile, et non sur l'amélioration du logiciel.

Réponse courte: Votre organisation est actuellement en grave danger de The Bus Factor .

C'est pourquoi vous ne laissez jamais une seule personne détenir toutes les connaissances. C'est un risque énorme. Que se passerait-il si cette personne décidait d'arrêter, ou se faisait littéralement renverser par un bus ? Si la situation est telle que vous la décrivez, alors toute l'entreprise a disparu. Vous devez signaler ce problème à vos responsables comme un risque organisationnel, et non comme un problème de ressources humaines.

Commencez à faire passer le code à d'autres personnes, avec ou sans M. A. De préférence sans, parce que vous l'avez déjà identifié comme le problème.

Souvenez-vous que si M. A ne veut pas aider à atténuer ce risque pour votre organisation, alors il est lui-même un danger pour l'organisation et doit être géré. Enlevez-lui son pouvoir pour que, s'il se fait vraiment renverser par un bus, vous ne vous retrouviez pas tous sans issue.

Les autres réponses sont plutôt bonnes, mais il y a une chose supplémentaire que je prendrais en considération :

Mon conseil personnel serait d'envisager de commencer à chercher d'autres lieux de travail… si la direction n'a pris aucune mesure en 7 ans, je ne suis pas sûr que ce soit un endroit pour lequel vous aimeriez travailler à long terme. Pour moi, c'est un signal d'alarme pour d'autres types de problèmes dans l'entreprise.

et il prend à plusieurs reprises de mauvaises décisions dans le but de maintenir le produit logiciel instable, difficile à entretenir et à dépanner

Alors pourquoi votre équipe laisse-t-elle ces “mauvaises décisions” passer la revue de conception ou la revue de code ? Si vous n'avez pas de processus de révision du code ou même de révision de la conception, plaidez pour cela sur le long terme

Mais en attendant, tout ce que vous devez savoir se trouve dans l'article du blog Joel on Software : Obtenir des résultats alors que vous n'êtes qu'un grincheux

Et il a un appel spécifique pour traiter avec les bozos : FILE BUGS. Per Spolsky :

En tant que grognon, votre but est de minimiser les dégâts, c'est-à-dire de les contenir. À un moment donné, un de ces génies va passer deux semaines à écrire un bout de code si incroyablement mauvais qu'il ne pourra jamais fonctionner. Vous êtes tenté de passer les quinze minutes qu'il faut pour réécrire correctement la chose à partir de zéro. Résistez à cette tentation. Vous avez une occasion parfaite de neutraliser cet imbécile pendant plusieurs mois. Continuez à lui signaler les bugs de son code. Ils n'auront pas d'autre choix que de continuer à le faire pendant des mois jusqu'à ce que vous ne trouviez plus de bogues. Ce sont des mois durant lesquels ils ne peuvent faire aucun dégât ailleurs.

Sinon, en tant que nouveau membre de l'équipe, votre objectif devrait être de développer votre propre réputation d'excellence.

Juste pour le dire plus clairement que les réponses actuelles…

Votre problème :

personne ne savait comment le résoudre.

Votre solution :

• Apprenez à le résoudre vous-même.

Voilà, maintenant la société n'a plus besoin de l'autre gars.

Affichez ceci sur le mur : (Vous devrez changer certains noms et lieux).

Il y a quelques années, j'ai passé une semaine à donner un cours interne de conception de programmes dans une entreprise manufacturière du Midwest des États-Unis. Le vendredi après-midi, tout était terminé. Le directeur du DP, qui avait organisé le cours et le payait sur son budget, m'a demandé de venir dans son bureau. “Qu'en pensez-vous ?” me demanda-t-il. Il me demandait de lui faire part de mes impressions sur son fonctionnement et son personnel. “Plutôt bonnes”, lui ai-je répondu. “Vous avez de bonnes personnes là-bas.” Les cours de conception de programmes sont un travail difficile ; j'étais très fatiguée ; et le conseil en évaluation du personnel est facturé en sus. Quoi qu'il en soit, je savais qu'il voulait vraiment me dire ce qu'il pensait…

“Qu'avez-vous pensé de Fred ?” a-t-il demandé. Nous pensons tous que Fred est brillant". “Il est très intelligent”, ai-je dit. “Il n'est pas très enthousiaste sur les méthodes, mais il en sait beaucoup sur la programmation.” “Oui”, a déclaré le directeur du DP. Il se retourna dans son fauteuil pour faire face à un énorme organigramme collé au mur : environ cinq grandes feuilles de papier pour imprimante à lignes, peut-être deux cents symboles, des centaines de lignes de connexion. “Fred a fait ça. C'est l'accumulation des salaires bruts pour notre paie hebdomadaire. Personne d'autre que Fred ne le comprend”. Sa voix est tombée dans un silence révérencieux. “Fred me dit qu'il n'est pas sûr de le comprendre lui-même”

“Superbe”, ai-je marmonné respectueusement. J'ai bien compris. Fred en Frankenstein, Fred le brillant créateur de l'organigramme du monstre incontrôlable. “Mais qu'en est-il de Jane ?” J'ai dit. “Je pensais que Jane était très bonne. Elle a très vite repris les idées de conception du programme”

“Oui”, a déclaré le responsable du PD. “Jane est venue à nous avec une grande réputation. Nous pensions qu'elle allait être aussi brillante que Fred. Mais elle n'a pas encore vraiment fait ses preuves. Nous lui avons donné quelques problèmes que nous pensions être très difficiles, mais quand elle a fini, il s'est avéré qu'ils n'étaient pas vraiment difficiles du tout. La plupart d'entre eux se sont avérés assez simples. Elle n'a pas encore vraiment fait ses preuves — si vous voyez ce que je veux dire”

“J'ai vu ce qu'il voulait dire”

• Extrait du livre Software Requirements & Specifications - Michel Jackson (Ça vaut le coup de lire).

La réponse est simple : virez-le. Vous devrez peut-être payer une somme d'argent non négligeable à court terme pour réparer le gâchis qu'il a fait, mais M. A n'est pas plus intelligent que quiconque dans le monde - quelqu'un d'autre _sera capable de maintenir le logiciel à court terme, et de l'améliorer à long terme.

Il y a une perspective à prendre en compte.

L'entreprise se plaît ainsi. S'ils ne l'ont pas fait, 7 ans, c'est long pour qu'elle perdure.

Nous avons tendance à oublier, en tant que développeurs, que ce n'est pas notre travail d'écrire du bon code ou du code intelligent. C'est notre travail de faire exister un produit. Écrire un bon code ne fait qu'améliorer ce processus, mais vous pouvez obtenir un produit totalement génial avec un code totalement merdique.

La société a soutenu ses décisions et l'a même réengagé. Ils l'ont “aimé” lui et sa façon de faire les choses. Vous ne changerez probablement pas cela, même si vous parvenez à le faire licencier. Ce qui risque d'arriver, c'est qu'ils choisissent une nouvelle personne pour être “le gars” et le processus recommence.

Ce n'est pas à vous de diriger l'entreprise. L'entreprise a fait son choix. Vous devez faire le vôtre. Apprenez du type (il a occupé le même poste pendant 7 ans, il doit faire quelque chose de bien) ou passez à autre chose.

Pour le meilleur ou pour le pire, ni rien ni personne n'est irremplaçable. Si les gens connaissent la solution, ils peuvent commencer à faire de la rétro-ingénierie.

J'ai été à votre place plus de deux fois dans le passé. Dans la situation la plus similaire à la vôtre, “Mr. A” était parti depuis longtemps, mais j'avais une solution monolithique travaillant pour l'arrière d'une société de câble où je n'avais pas le code source des bibliothèques développées localement, et pour couronner le tout, j'étais un débutant dans ce secteur.

Je l'ai attaqué en adoptant une approche modulaire, en examinant le code existant, en faisant de la rétro-ingénierie là où il manquait et en écrivant des modules qui ont été remplacés à tour de rôle par de meilleures fonctionnalités et en accélérant les tâches principales. J'ai perfectionné chaque module avant de passer au suivant. En quelques mois, j'avais tué l'ancienne application.

Être irremplaçable est exagéré.

S'occuper aussi de l'héritage n'est pas une tâche facile, peut-être que votre collègue le fait par inertie ou parce qu'il ne sait pas mieux.

D'un point de vue commercial, il existe essentiellement deux solutions :

1. Transition progressive, c'est-à-dire prendre un petit morceau de la fonctionnalité, le réimplanter à un niveau élevé, le mettre en production et continuer à faire cela morceau par morceau jusqu'à ce que l'ancien système puisse être totalement mis hors service.
2. 2. Construire entièrement un nouveau système, puis passer à celui-ci, soit d'un seul coup, soit progressivement, par exemple en y installant de nouveaux clients et en y faisant passer progressivement d'anciens clients. Les avantages de l'option 1 sont qu'elle ne nécessite pas un investissement initial important, que votre nouveau code est testé progressivement sur le terrain au lieu de l'être d'un seul coup et que vous commencez à en retirer des avantages rapidement (parce que l'entreprise passe moins de temps et d'argent à entretenir les parties de l'ancien système qui ne sont plus actives). Toutefois, les inconvénients sont que la structure du nouveau système peut être fortement influencée par celle de l'ancien et, dans certains cas, il est vraiment difficile de remplacer les parties d'un système très désordonné. Parfois, un peu de créativité est nécessaire - si tout le reste échoue, votre nouveau code peut simuler des pressions de touches et des clics de boutons sur l'ancien système ! Mais l'interface avec l'ancien système peut générer tellement de travail qu'il est préférable de choisir l'option 2.

Dans tous les cas, il y a quelque chose à faire. La question est de savoir combien cela va coûter et combien cela va permettre d'économiser. Essayer d'estimer cela pour chacune des options ci-dessus aidera à déterminer l'option à choisir (le cas échéant). Cela dépendra des exigences fonctionnelles, de la structure du système existant et de la volonté de l'entreprise de dépenser de l'argent ou d'utiliser le crédit dès le départ pour réaliser des économies futures.

En tant que membre de l'équipe chargée des logiciels, votre travail n'est pas de gérer l'entreprise et ses employés.

Votre travail est d'écrire de bons logiciels. Vous vous souciez donc du logiciel et non des personnes.

Vous voyez les problèmes du logiciel, et d'après votre question, il semble que vous ayez quelques idées pour les résoudre. Apportez ces idées à votre responsable et battez-vous pour elles.

“Manger, ce logiciel n'est pas testé et sa mise en œuvre actuelle n'est pas testable. Je suggère que nous travaillions à la réimplémentation dans un langage plus testable, en utilisant des modèles de conception qui permettent des tests plus faciles”

Maintenant, il est très probable que :

A. Il s'agit d'une grande entreprise dans laquelle l'entreprise n'est pas prête à investir, parce qu'elle n'en voit pas la nécessité

B. M. A argumentera contre ce genre de choses et sera écouté puisqu'il est plus expérimenté

Si cela arrive, vous avez essayé de bien faire votre travail et avez été étouffé. Il est temps de chercher un nouvel emploi.

Si cela se passe et qu'on vous écoute, vous vous engagez pour une tonne de travail.

Vous ne pouvez pas présumer de l'intention derrière la situation.

Il est volontairement tenu à l'écart des cadres de développement logiciel modernes

Il pourrait être plus à l'aise avec ce qu'il connaît le mieux…

J'ai travaillé dans de grandes entreprises dont le pipeline était un patchwork de code ancien et tout nouveau et où certains morceaux de code “fonctionnaient juste” et n'étaient jamais touchés. En plus, les programmeurs qui l'ont écrit étaient partis depuis longtemps et personne ne comprenait vraiment comment ils travaillaient, alors ils ont juste ajouté de nouvelles fonctions pour s'adapter à l'évolution des besoins. Ils ont donc ajouté de nouvelles fonctions pour s'adapter à l'évolution des besoins. Leur pipeline était toujours en ligne, de sorte que tout déploiement majeur pouvait avoir des conséquences désastreuses (c'est-à-dire des travaux très coûteux et des interruptions de livraison), et ils ont donc évité de trop y toucher.

C'est une mauvaise habitude qui fait que l'infrastructure n'est pas optimisée, mais elle a en fait son mérite.

Ce que vous pourriez faire, surtout si vous devez travailler sur une grande partie ou sur la totalité du code : S'il n'y a pas de documentation appropriée, proposez d'en créer une (si vous savez que vous êtes qualifié et que vous avez le temps) ou demandez s'il faut en créer une pour accélérer le travail.

Vous devriez (comme vous le faites déjà) parler de l'adaptation de nouvelles technologies ou d'améliorations avec votre responsable mais vous attendre à ce que rien n'en résulte, même s'il est d'accord avec vous. Il y a de fortes chances que personne à un niveau supérieur ne voie l'intérêt de dépenser des ressources à cet effet et votre tentative pourrait être considérée comme ah, le sang neuf pense qu'il peut changer le monde et nous apprendre l'erreur de nos méthodes. Malheureusement, les structures des entreprises résistent aux changements soudains et les modernisations consistent à user progressivement cette résistance ou à la mettre en œuvre petit à petit, à moins que vous ne puissiez montrer que vos “changements révolutionnaires apporteront un âge d'or de profit financier sans risques”.

Même s'il fait cela par malveillance pour garder son emploi, je ne vois pas en quoi il est de votre responsabilité de faire sauter le couvercle, surtout si votre supérieur immédiat en est informé.

Que feriez-vous ? Parler avec votre supérieur ou sans lui à la direction supérieure ou au collègue en question ? Votre supérieur hiérarchique ayant décidé de ne pas poursuivre l'affaire, il ne voudra probablement pas parler à ses supérieurs avec ou sans vous, ou il l'a déjà fait et a rencontré un blocage à cet endroit. Si vous parlez à ses supérieurs sans lui, vous risquez de l'aliéner.

La seule façon de régler ce problème est d'enlever le contrôle de M. A.

Obtenir d'abord l'approbation de la direction.

Faire un tout nouveau git.

1. Importer un bien, point de départ convenu.

2. Commencer à partir de là, et faire avancer le code.

3. Ne donnez pas du tout l'accès à M. A (ne lui dites même pas qu'il existe)

4. Portez M. A. à votre propre repo, ou réécrivez.

5. Laissez M. A. faire ce qu'il veut de sa repo, car vous ne l'utiliserez pas.

6. Faites de faux changements de code pour le faire paraître actif si nécessaire afin de lui cacher votre nouvelle prise en pension.

7. Le code finira par diverger suffisamment pour qu'il devienne automatiquement obsolète.

Vous devez prendre une décision cruciale pour conserver ou abandonner la stratégie des modules. Les modules ne sont pas nécessairement mauvais, vous devez les garder synchronisés et en état de marche.

Cela va représenter beaucoup de travail car vous devez réécrire une grande partie du code existant.

Un avantage supplémentaire est que le code finira par diverger suffisamment pour qu'il ne puisse plus prétendre à son propre code. Il lui sera complètement étranger.

Soyez conscient qu'en tant que non-manager, cela n'a pas à être votre problème à résoudre (à part suivre les instructions pour faire des choses qui ont été décidées dans le cadre d'une solution).

Aussi, n'interprétez jamais aveuglément “Nous voulons que le problème XY soit résolu” en une déclaration “…à cause du problème XY”.

Sachez également qu'une fois que vous prenez une initiative, même approuvée, pour changer la situation, vous vous impliquez dans la politique de l'entreprise. Dans la politique d'entreprise, il n'existe pas de “innovateur innocent sans programme personnel, que nous ne pouvons pas tenir responsable des conséquences involontaires”. Si vous le faites, faites-le avec un programme personnel, et assumez les conséquences de toute façon.

@MightyPizza - Vous perdez votre temps. Allez travailler pour une autre entreprise qui a un avenir meilleur et plus brillant. Vous ne devriez dépenser autant d'énergie à résoudre ce problème que si cette entreprise est votre dernier arrêt.

C'est la meilleure réponse que vous obtiendrez. Préparez-vous au saut.

“Je veux rendre le logiciel moderne, maintenable et stable”.

La meilleure façon d'y parvenir est de le faire le premier jour, à la première ligne de code, et non avec le tas de déchets brûlants de quelqu'un d'autre.

Le fait qu'il soit resté si longtemps à ce poste montre que l'entreprise applique consciemment ou inconsciemment le rasoir de Hanlon :

Ne jamais attribuer à la malveillance ce qui s'explique adéquatement par la stupidité.

Il semble qu'il soit très difficile de trouver des cas réels de malveillance, juste des choses qui n'ont pas si bien fonctionné avec le temps. En fait, il semble que M. A a laissé les gens essayer de changer les choses et les a ensuite réparées héroïquement lorsqu'elles ont mal tourné.

Vous devriez également considérer que M. A peut souffrir de l’effet Dunning-Kruger, en ce sens qu'il est incapable de voir que ce qu'il fait est mal.

Il se peut qu'il ait été bon autrefois, mais qu'il ait cessé d'apprendre et d'essayer. Qui sait ? Ce qu'il faut prendre comme premier principe, c'est que peu importe à quel point il est exaspérant, vous devez le traiter comme s'il n'était pas un agent malveillant.

Votre question semble prendre l'hypothèse qu'il est juste après la sécurité de l'emploi et refuse de mettre à jour les choses pour intégrer cela. Vous avez peut-être raison, mais vous ne pouvez pas traiter avec lui sur cette base.

Je suis sûr que certaines de vos brillantes idées se heurtent à la résistance du “nous avons essayé une fois et ça n'a pas marché à cause de X.” D'un point de vue commercial, c'est logique, ils ont pris le risque que quelque chose ne fonctionne pas, alors pourquoi devraient-ils essayer à nouveau.

Vous indiquez comme objectif.

Je veux rendre le logiciel moderne, maintenable et stable.

Décomposons cela par besoin commercial

1. Moderne

Il n'y a pas de valeur commerciale implicite dans le moderne. Elle est en tout cas défendable. Vous dites Java 8, d'autres diraient que Rust ou Golag sont modernes. Tant qu'un système est supporté, il n'y a pas de grande valeur à le mettre à jour.

2. Maintenable

Cela pourrait aussi être difficile à argumenter. M. A fera valoir qu'il est maintenable, puisqu'il le maintient. Il faudrait argumenter que le coût de maintenance diminuerait considérablement pour justifier un changement complet du cadre.

3. Stable

Vous dites que vous voulez rendre le système HA, mais vous dites aussi qu'il

le logiciel surveille les événements, fait certains traitements sur eux et prend ensuite les mesures appropriées.

Qui ne semble pas avoir besoin de HA. Votre système ressemble à une grosse boule de boue défini par

Une grosse boule de boue est une jungle désordonnée, tentaculaire, bâclée, avec du ruban adhésif et du fil de fer, avec un code de spaghetti. Ces systèmes montrent des signes évidents de croissance non régulée et de réparation répétée et rapide.

S'attaquer à ce problème de front, avec un développeur peu coopératif qui le gère, sera très frustrant, et probablement inutile. Ce que vous pouvez faire, c'est commencer à le contourner :

• Si vous ne pouvez pas rendre le système HA, alors utilisez un système de bus de messages ou autre pour capturer les messages de telle sorte que si le système tombe en panne, vous ne perdiez pas de données.
• Si vous ne pouvez pas écrire de tests unitaires, écrivez des tests système. Ils ne sont pas aussi soignés mais ils permettent de faire des tests sur le système
• La prochaine fois qu'une action est nécessaire, commencez à l'intégrer dans un sous-système indépendant qui peut écouter le bus de messages et effectuer sa propre action. Si vous pouvez commencer à affecter certains effets en aval (par exemple, encapsuler les actions qui sont prises), alors mettez-les dans un sous-système. Il existe des arguments en faveur du monolithe majectique par rapport aux micro-services , mais ils supposent que le monolithe est bien conçu. Dans votre cas, le système peut convenir en tant que monolithe bien conçu, mais s'il n'est pas bien conçu, vous devez séparer les choses. This semble être un bon article pour commencer :

Une approche plus courante consiste à commencer avec un monolithe et à enlever progressivement les microservices sur les bords. Une telle approche peut laisser un monolithe substantiel au cœur de l'architecture des microservices, mais la plupart des nouveaux développements ont lieu dans les microservices alors que le monolithe est relativement au repos.

Il est cependant important de jouer le jeu avec M. A, ne lui dites pas que vous remplacez le système, mais que vous “améliorez la fiabilité” ou ajoutez de la redondance. Si vous attaquez ce qu'il a fait, il vous sera plus difficile d'atteindre vos objectifs.

Vous risquez d'être critiqué parce que vous rendez le système plus complexe. C'est vrai, mais c'est nécessaire si vous voulez aller de l'avant à long terme.

Pourquoi tout le monde veut-il tant virer M. A ? Je pense qu'il n'a rien fait de mal ici. Le développement de logiciels ne consiste pas à créer de nouvelles choses en utilisant des outils ou un cadre de travail sympa. Il s'agit de créer une chose stable qui “fonctionne”. Votre entreprise aime M. A et est satisfaite de son travail.

L'entreprise est délibérément tenue à l'écart des cadres de développement logiciel modernes

Votre système est actuellement en état stable, alors pourquoi l'équipe a-t-elle même besoin d'utiliser un cadre de développement logiciel moderne comme Scrum ou agile ?

Logique d'entreprise principale écrite dans des langages qui ne peuvent pas être testés

Y a-t-il une exigence selon laquelle la logique d'entreprise principale doit être automatiquement testée ?

Re-architecture des composants logiciels en 30 modules pour ajouter de la complexité et des problèmes de certification de version

Combien cette mise en œuvre a-t-elle coûté de plus à votre entreprise ?

Conception non évolutive, garantissant l'absence de capacités HA (haute disponibilité)

Toujours la même question : combien cette mise en œuvre a-t-elle coûté de plus à votre entreprise ?

À mon avis, tout ce que vous écrivez ici n'est que votre plainte contre lui. S'il avait fait beaucoup de choses “terribles”, le système lui-même aurait fondu au cours de la première année, et il n'aurait pas pu rester aussi longtemps dans votre entreprise.

C'est simple, l'entreprise doit lui offrir une généreuse augmentation pour documenter l'état actuel des logiciels et toutes les connaissances qui ne sont pas documentées, puis elle le licencie. Ou alors, elle engage une société de conseil en technologie pour tout documenter et il verra l'écriture sur le mur et finira par partir.