Wie kann man einen Mitarbeiter daran hindern, das Unternehmen als Geisel zu nehmen?

Was kann ich tun, um diese Situation zu beheben?

Nichts, Sie sind erst seit ein paar Monaten dort, es ist nicht Ihre Rolle und Sie haben nicht die Macht, etwas zu tun, außer darüber zu jammern.

Ihre Vorgesetzten haben viele Ressourcen, aber sie haben sie seit 7 Jahren nicht mehr genutzt, so dass Sie an diesem Punkt nur ihre Gründe hinterfragen und einen Kollegen analysieren, anstatt sich auf Ihre eigenen Verantwortlichkeiten und Aufgaben zu konzentrieren.

Stellen Sie zwei oder drei der klügsten Entwickler ein, die Sie finden können. Übergeben Sie ihnen den gesamten Code. Lassen Sie sie überprüfen, ob sie tatsächlich den gesamten Code haben, alles, was zur Ausführung der Software erforderlich ist. Lassen Sie sie lernen, was der Code tut, dokumentieren Sie ihn, überarbeiten Sie ihn, bis sie den Punkt erreicht haben, an dem sie Probleme schneller beheben können als Herr A. All dies natürlich ohne jegliche Kenntnis von A.

An diesem Punkt stellen Sie sicher, dass Sie Herrn A von allen Firmenressourcen vollständig abschalten, die Aufgabe an Ihre neuen Entwickler übertragen und Herrn A informieren. A, dass seine Anstellung beendet ist.

Ich würde denken, dass mit den Entwicklungsmethoden von Herrn A der Arbeitsaufwand, den sein Code verursacht, in Wirklichkeit viel weniger ist, als sieben Jahre Entwicklung normalerweise produzieren würden, und dass der Code zwar verschleiert, aber nicht wirklich schwierig ist, was die Arbeit der Neuen sehr viel einfacher macht.

PS. Aufgrund einiger Kommentare möchte ich dies noch einmal betonen: Das Problem ist nicht nur das Geld, das Problem ist, dass die Software viel weniger gut entwickelt ist, als sie sein könnte, denn A konzentriert sich darauf, die Entwicklung zu erschweren, nicht darauf, die Software zu verbessern.

Kurze Antwort: Ihre Organisation ist derzeit in großer Gefahr von The Bus Factor .

Aus diesem Grund lassen Sie nie eine Person das gesamte Wissen besitzen. Das ist ein enormes Risiko. Was würde passieren, wenn diese Person beschließen würde, auszusteigen, oder buchstäblich von einem Bus angefahren würde? Wenn die Situation so ist, wie Sie sie skizzieren, dann ist das ganze Unternehmen weg. Sie müssen dies Ihren Vorgesetzten gegenüber als organisatorisches Risiko und nicht als HR-Problem kennzeichnen.

Beginnen Sie damit, andere Personen über den Kodex zu informieren, mit oder ohne Herrn A. Vorzugsweise ohne, da Sie ihn bereits als das Problem identifiziert haben.

Denken Sie daran, wenn Herr A. nicht an dieser Risikominderung für Ihr Unternehmen mitwirken will, dann ist er selbst eine Gefahr für das Unternehmen und muss ausgeschaltet werden. Nehmen Sie ihm seine Macht, damit Sie, falls er wirklich von einem Bus überfahren wird, nicht alle am Ende keinen Ausweg haben.

Die anderen Antworten sind ziemlich gut, aber es gibt noch eine zusätzliche Sache, die ich in Betracht ziehen würde:

Mein persönlicher Ratschlag wäre, sich nach anderen Arbeitsorten umzusehen… wenn das Management in 7 Jahren nichts unternommen hat, bin ich mir nicht sicher, ob dies ein Ort ist, für den man langfristig arbeiten möchte. Für mich liest sich dies als ein Warnzeichen für andere Arten von Problemen im Unternehmen.

und er wiederholte, dass er absichtlich schlechte Entscheidungen trifft, um das Softwareprodukt instabil, schwer zu warten und Fehler zu beheben

Warum lässt Ihr Team also diese “schlechten Entscheidungen” über die Designprüfung oder die Codeprüfung hinausgehen? Wenn Sie keinen Code-Review-Prozess oder gar einen Design-Review-Prozess haben, setzen Sie sich langfristig dafür ein.

Aber bis dahin finden Sie alles, was Sie wissen müssen, im Blog-Artikel Joel auf Software: Getting Things Done When You’re Only a Grunt

Und er hat einen speziellen Aufruf für den Umgang mit Bozos: DATEI-BUGS. Per Spolsky:

Als Grunzer ist Ihr Ziel die Schadensminimierung, auch bekannt als Eindämmung. Irgendwann wird eines dieser Genies zwei Wochen damit verbringen, ein bisschen Code zu schreiben, der so unglaublich schlecht ist, dass er niemals funktionieren kann. Man ist versucht, die fünfzehn Minuten, die man braucht, um das Ding von Grund auf richtig umzuschreiben. Widerstehen Sie der Versuchung. Sie haben die perfekte Gelegenheit, diesen Schwachkopf für mehrere Monate zu neutralisieren. Melden Sie einfach weiterhin Bugs gegen ihren Code. Sie werden keine andere Wahl haben, als sich monatelang damit herumzuschlagen, bis Sie keine Fehler mehr finden können. Das sind Monate, in denen sie nirgendwo anders Schaden anrichten können.

Ansonsten sollte es Ihr Ziel als Neuzugang im Team sein, Ihren eigenen hervorragenden Ruf zu entwickeln.

Nur um es deutlicher zu sagen als die aktuellen Antworten…

Ihr Problem :

niemand wusste, wie man es beheben kann.

Ihre Lösung :

• Lernen Sie, wie Sie es selbst beheben können.

Hängen Sie dies an die Wand: (Sie werden einige der Namen und Orte ändern müssen).

Vor einigen Jahren habe ich eine Woche lang einen firmeninternen Kurs über Programmdesign in einer Produktionsfirma im mittleren Westen der Vereinigten Staaten gegeben. Am Freitagnachmittag war alles vorbei. Der DP-Manager, der den Kurs organisiert hatte und ihn aus seinem Budget bezahlte, bat mich in sein Büro. “Was denken Sie?”, fragte er. Er bat mich, ihm meine Eindrücke von seinem Betrieb und seinen Mitarbeitern mitzuteilen. “Ziemlich gut”, sagte ich. “Sie haben da ein paar gute Leute.” Kurse zur Programmgestaltung sind harte Arbeit; ich war sehr müde; und die Beratung zur Personalbeurteilung wird extra berechnet. Jedenfalls wusste ich, dass er mir wirklich seine eigenen Gedanken mitteilen wollte.

“Wie fandest du Fred?” fragte er. Wir alle finden Fred brillant.“ "Er ist sehr clever”, sagte ich. “Er ist nicht sehr begeistert von Methoden, aber er weiß eine Menge über Programmierung. "Ja”, sagte der DP-Manager. Er drehte sich in seinem Stuhl herum und sah ein riesiges Flussdiagramm vor sich, das an der Wand hing: etwa fünf große Blätter Papier für Zeilendrucker, vielleicht zweihundert Symbole, Hunderte von Verbindungslinien. “Das war Fred. Es ist der Aufbau des Bruttogehalts für unsere wöchentliche Gehaltsabrechnung. Niemand außer Fred versteht es.” Seine Stimme verstummte zu einem ehrfürchtigen Schweigen. “Fred sagt mir, dass er selbst nicht sicher ist, ob er es versteht.”

“Fantastisch”, murmelte ich respektvoll. Ich habe das Bild deutlich verstanden. Fred als Frankenstein, Fred, der brillante Schöpfer des unkontrollierbaren Monsterflussdiagramms. “Aber was ist mit Jane?” Ich sagte. “Ich fand Jane sehr gut. Sie hat die Ideen für das Programmdesign sehr schnell aufgegriffen.”

“Ja”, sagte der DP-Manager. “Jane kam mit einem ausgezeichneten Ruf zu uns. Wir dachten, sie würde genauso brillant sein wie Fred. Aber sie hat sich noch nicht wirklich bewiesen. Wir haben ihr ein paar Probleme gegeben, von denen wir dachten, dass sie wirklich schwierig werden würde, aber als sie fertig war, stellte sich heraus, dass sie überhaupt nicht wirklich schwierig waren. Die meisten davon waren ziemlich einfach. Sie hat sich noch nicht wirklich bewiesen — wenn Sie sehen, was ich meine?”

“Ich habe gesehen, was er meinte.”

• Auszug aus dem Buch Software Requirements & Specifications - Michel Jackson (Lesenswert).

Die Antwort ist einfach: Feuern Sie ihn. Vielleicht müssen Sie kurzfristig einen nicht unerheblichen Geldbetrag auszahlen, um das Durcheinander, das er angerichtet hat, zu beheben, aber Herr A. ist nicht klüger als irgendjemand anders auf der Welt - jemand anders wird in der Lage sein, die Software kurzfristig zu warten und sie langfristig besser zu machen.

Es gibt eine Perspektive zu berücksichtigen.

Dem Unternehmen gefällt es so. Wenn sie es nicht getan hätten, wären 7 Jahre eine lange Zeit, um es bestehen zu lassen.

Wir neigen dazu, als Entwickler zu vergessen, dass es nicht unsere Aufgabe ist, guten oder intelligenten Code zu schreiben. Es ist unsere Aufgabe, ein Produkt ins Leben zu rufen. Wenn man guten Code schreibt, wird dieser Prozess einfach besser, aber man kann ein absolut großartiges Produkt mit völlig beschissenem Code herstellen.

Das Unternehmen hat hinter seinen Entscheidungen gestanden und ihn sogar wieder eingestellt. Sie “mögen” ihn und seine Art, die Dinge zu tun. Daran werden Sie wahrscheinlich nichts ändern, auch wenn Sie es irgendwie geschafft haben, dass er gefeuert wurde. Was wahrscheinlich passieren wird, ist, dass sie eine neue Person als “den Kerl” auswählen und der Prozess von vorne beginnt.

Es ist nicht Ihre Aufgabe, das Unternehmen zu leiten. Das Unternehmen hat seine Wahl getroffen. Sie müssen Ihre treffen. Lernen Sie von dem Mann (er hat seit 7 Jahren den gleichen Job, er muss etwas richtig machen) oder machen Sie weiter.

Im Guten wie im Schlechten, weder nichts noch niemand ist unersetzlich. (einige sind vielleicht mehr als andere, aber dennoch) Wenn die Leute die Lösung kennen, können sie mit dem Reverse Engineering beginnen.

Ich war in der Vergangenheit mehr als ein paar Mal an Ihrer Stelle. In der ähnlichsten Situation wie in Ihrer war “Mr. A” schon lange nicht mehr da, aber ich hatte eine monolithische Lösung, die für das Backend eines Kabelunternehmens arbeitete, wo ich keinen Quellcode für die lokal entwickelten Bibliotheken hatte, und zu allem Überfluss war ich ein Neuling in dieser Branche.

Ich habe sie auf der Grundlage eines modularen Ansatzes angegriffen, indem ich einen Blick auf den vorhandenen Code warf, ein Reverse Engineering durchführte, wo es fehlte, und Module schrieb, die nach und nach durch bessere Funktionalität und schnellere Kernaufgaben ersetzt wurden. Ich perfektionierte jedes Modul, bevor ich zum nächsten überging. In ein paar Monaten hatte ich die frühere Anwendung abgeschafft.

Unersetzlich sein ist übertrieben.

Auch mit Altlasten umzugehen ist keine leichte Aufgabe, vielleicht macht es Ihr Mitarbeiter aus Trägheit oder weil er es nicht besser weiß.

Aus geschäftlicher Sicht gibt es grundsätzlich zwei Lösungen:

1. Inkrementeller Übergang, d.h. man nimmt einen kleinen Teil der Funktionalität, implementiert ihn auf einem hohen Standard neu und bringt ihn in Produktion, und setzt dies Stück für Stück fort, bis das alte System vollständig stillgelegt werden kann.
2. Bauen Sie ein neues System vollständig auf und gehen Sie dann auf dieses System über, entweder auf einmal oder schrittweise, z.B. indem Sie neue Kunden darauf starten und alte Kunden schrittweise darauf umstellen. Das neue System muss anfangs nicht so leistungsfähig sein wie das alte; sein Verkaufsargument kann ein niedrigerer Preis, schnellerer Support usw. sein.

Die Vorteile von Option 1 liegen darin, dass keine großen Vorabinvestitionen erforderlich sind, dass Ihr neuer Code nach und nach statt auf einmal in der Praxis erprobt wird und dass Sie die Vorteile schon früh erkennen (weil das Unternehmen weniger Zeit und Geld für die Wartung der nicht mehr aktiven Teile des alten Systems aufwendet).

Die Nachteile sind jedoch, dass die Struktur des neuen Systems stark von der Struktur des alten Systems beeinflusst werden kann, und in einigen Fällen ist es wirklich schwierig, Teile eines sehr unordentlichen Systems zu ersetzen. Manchmal ist ein bisschen Kreativität erforderlich - wenn alles andere versagt, kann Ihr neuer Code Tastendrücke und Tastenklicks auf dem alten System simulieren! Aber die Kopplung mit dem alten System kann so viel Arbeit erzeugen, dass es besser ist, einfach Option 2 zu wählen.

So oder so, es gibt etwas, das man tun kann. Die Frage ist, wie viel wird es kosten und wie viel wird es einsparen? Der Versuch, dies für jede der oben genannten Optionen abzuschätzen, wird dabei helfen, zu bestimmen, welche Option man wählen sollte (wenn überhaupt). Sie wird von den funktionalen Anforderungen, der Struktur des bestehenden Systems und der Bereitschaft des Unternehmens abhängen, Geld auszugeben bzw. Kredite im Voraus für künftige Einsparungen zu verwenden.

Als Mitglied des Software-Teams besteht Ihre Aufgabe nicht darin, das Unternehmen und seine Mitarbeiter zu leiten.

Ihre Aufgabe ist es_, gute Software zu schreiben. Kümmern Sie sich also um die Software, nicht um die Mitarbeiter.

Sie sehen die Probleme mit der Software, und aus Ihrer Frage geht hervor, dass Sie einige Ideen zur Behebung der Probleme haben. Bringen Sie diese Ideen zu Ihrem Manager und kämpfen Sie dafür.

“Manager, diese Software ist nicht getestet und ihre aktuelle Implementierung ist nicht testbar. Ich schlage vor, dass wir an einer Reimplementierung in einer Sprache arbeiten, die besser testbar ist, und zwar unter Verwendung von Entwurfsmustern, die ein einfacheres Testen ermöglichen.”

Nun ist es sehr wahrscheinlich, dass:

A. Dies ist ein großes Unternehmen, in das die Firma nicht zu investieren bereit ist, weil sie die Notwendigkeit nicht sehen

B. Herr A wird gegen dieses Zeug argumentieren und man wird ihm zuhören, da er älter ist

Wenn das passiert, dann haben Sie versucht, Ihre Arbeit gut zu machen und wurden erstickt. Zeit, sich nach einem neuen Job umzusehen

Wenn sich das auszahlt und man auf Sie hört, haben Sie sich für eine Menge Arbeit gemeldet.

Sie können keine Absicht hinter der Situation vermuten…

Absichtlich von modernen Softwareentwicklungs-Frameworks ferngehalten

Er könnte sich einfach am wohlsten fühlen mit dem, was er am besten weiß…

Ich habe bei großen Unternehmen gearbeitet, deren Pipeline ein Flickenteppich aus altem und brandneuem Code war und bei denen bestimmte Teile des Codes “einfach funktionierten” und nie angerührt wurden. Hinzu kam, dass die Programmierer, die ihn geschrieben hatten, schon lange weg waren und niemand wirklich verstand, wie sie arbeiteten, so dass sie einfach neue Funktionen hinzufügten, um den sich ändernden Anforderungen gerecht zu werden. Ihre Pipeline war immer in Betrieb, so dass jeder größere Rollout katastrophale Folgen haben konnte (d.h. sehr teure Arbeit und Lieferunterbrechung), so dass sie sich davor scheuten, den Code zu sehr anzufassen.

Es ist eine schlechte Angewohnheit und sorgt für eine nicht optimierte Infrastruktur, hat aber eigentlich seinen Wert

Was Sie tun könnten, besonders wenn Sie an einem großen Teil oder dem ganzen Code arbeiten müssen: Wenn es keine ordentliche Dokumentation gibt, schlagen Sie entweder vor, eine zu erstellen (wenn Sie wissen, dass Sie qualifiziert sind und Zeit haben) oder fragen Sie, ob eine erstellt werden soll, um die Arbeit zu beschleunigen.

Sie sollten (wie Sie es bereits tun) mit Ihrem Vorgesetzten über die Anpassung neuer Technologien oder Verbesserungen sprechen, aber erwarten, dass nichts dabei herauskommen könnte, selbst wenn er Ihnen zustimmt.

Die Chancen stehen gut, dass niemand weiter oben den Nutzen darin sieht, Ressourcen dafür auszugeben, und Ihr Versuch könnte so aussehen, als ob ah, das Denken des neuen Blutes die Welt verändern und uns über die Fehler unserer Wege belehren könnte.

Leider widersetzen sich die Unternehmensstrukturen plötzlichen Veränderungen, und bei Modernisierungen geht es darum, den Widerstand allmählich abzubauen oder sie nach und nach umzusetzen, es sei denn, Sie können zeigen, dass Ihre “revolutionären Veränderungen ein goldenes Zeitalter des finanziellen Gewinns ohne Risiken herbeiführen werden”.

Selbst wenn er dies böswillig tut, um seinen Job zu behalten, sehe ich es nicht als Ihre Verantwortung an, die Klappe aufzureißen, vor allem wenn Ihr unmittelbarer Vorgesetzter darüber informiert ist.

Was würden Sie tun? mit Ihrem Vorgesetzten oder ohne ihn mit der höheren Leitung oder mit dem betreffenden Kollegen sprechen?

Da sich Ihr Vorgesetzter entschieden hat, die Angelegenheit nicht weiterzuverfolgen, wird er wahrscheinlich nicht mit oder ohne Sie mit seinen Vorgesetzten sprechen wollen, oder er hat es bereits getan und ist dort auf eine Blockade gestoßen.

Wenn Sie ohne ihn mit seinen Vorgesetzten sprechen, riskieren Sie, ihn zu entfremden.

Wenn Sie mit dem Kollegen sprechen, wird er danach mit Sicherheit ein sehr schlechtes Arbeitsumfeld schaffen, und er wird sicherlich jede Anschuldigung abstreiten.

Die einzige Möglichkeit, dies zu beheben, ist, Herrn A. die Kontrolle zu entziehen.

Zuerst die Genehmigung der Geschäftsleitung einholen.

Einen nagelneuen Git machen.

1. eine Ware importieren, vereinbarter Startpunkt.

2. Beginnen Sie von dort aus und bringen Sie den Code vor.

3. Geben Sie Herrn A überhaupt keinen Zugang (sagen Sie ihm nicht einmal, dass er existiert)

4. Portieren Sie Herrn A. Änderungen an Ihrem eigenen Repo, oder schreiben Sie ihn um.

5. Lassen Sie Herrn A. mit seinem Repo machen, was immer er will, da Sie es nicht benutzen werden.

6. Nehmen Sie gefälschte Code-Änderungen vor, um ihn gegebenenfalls aktiv erscheinen zu lassen, um Ihr neues Repo vor ihm zu verstecken.

7. Irgendwann wird der Code weit genug abweichen, so dass er automatisch veraltet ist.

Sie müssen eine kritische Entscheidung treffen, um die Modulstrategie beizubehalten oder aufzugeben. Module sind nicht notwendigerweise schlecht, Sie müssen sie synchronisiert und funktionsfähig halten.

Dies wird eine Menge Arbeit sein, da Sie eine Menge bestehenden Code neu schreiben müssen.

Ein zusätzlicher Vorteil ist, dass der Code irgendwann so weit divergiert, dass er nicht mehr in der Lage sein wird, seinen Code zu beanspruchen. Es wird ihm völlig fremd sein.

Seien Sie sich bewusst, dass dies als Nicht-Führungskraft nicht Ihr Problem sein muss, das es zu lösen gilt (abgesehen davon, dass Sie Anweisungen befolgen müssen, Dinge zu tun, die als Teil einer Lösung beschlossen wurden).

Interpretieren Sie auch niemals blind “Wir wollen, dass Problem XY gelöst wird” in eine Aussage “…wegen Problem XY”.

Seien Sie sich auch bewusst, dass Sie, sobald Sie irgendeine Initiative zur Änderung der Situation ergreifen, selbst mit Zustimmung, sich in die Unternehmenspolitik einmischen. In der Unternehmenspolitik gibt es so etwas wie “einen unschuldigen Innovator ohne persönliche Agenda, den wir nicht für unbeabsichtigte Konsequenzen verantwortlich machen können” nicht.

Wenn Sie es tun, tun Sie es mit einer persönlichen Agenda, und seien Sie sich der Konsequenzen so oder so bewusst.

@MightyPizza - Sie verschwenden Ihre Zeit. Gehen Sie und arbeiten Sie für ein anderes Unternehmen, das eine bessere und bessere Zukunft hat. Sie sollten nur dann so viel Energie auf die Lösung dieses Problems verwenden, wenn dieses Unternehmen Ihre letzte Station ist.

Dies ist die absolut beste Antwort, die Sie bekommen werden. Bereiten Sie sich auf den Sprung vor.

“Ich möchte die Software modern, wartbar und stabil machen”

Am besten geht das am ersten Tag, in der ersten Zeile des Codes, und nicht mit dem heißen Haufen Müll eines anderen.

F […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […] […]

Warum wollen alle Herrn A. so sehr feuern? Ich glaube, er hat hier nichts falsch gemacht. Bei der Software-Entwicklung geht es nicht darum, neue Dinge mit coolen Tools oder einem Framework zu entwickeln. Es geht darum, eine stabile Sache zu machen, die einfach “funktioniert”. Ihr Unternehmen liebt Herrn A. und ist mit seiner Arbeit zufrieden.

Absichtlich von modernen Softwareentwicklungs-Frameworks ferngehalten

Ihr System befindet sich derzeit in einem stabilen Zustand, warum muss das Team also überhaupt moderne Softwareentwicklungs-Frameworks wie Scrum oder Agile verwenden?

Geschriebene Kerngeschäftslogik in Sprachen, die nicht getestet werden können

Gibt es die Anforderung, dass die Kerngeschäftslogik automatisch getestet werden muss?

Re-architected Software-Komponenten in 30 Module, um Komplexität und Versionszertifizierungsfragen hinzuzufügen

Wie viel mehr hat diese Implementierung Ihr Unternehmen gekostet?

Designed es in einer nicht skalierbaren Art und Weise, um sicherzustellen, dass es keine HA (Hochverfügbarkeit) Fähigkeiten gibt

Immer noch die gleiche Frage - wie viel mehr hat diese Implementierung Ihr Unternehmen gekostet?

Meiner Meinung nach sind all die Dinge, die Sie hier aufschreiben, nur Ihre Beschwerde gegen ihn. Wenn er viele “schreckliche” Dinge getan hätte, wäre das System selbst im ersten Jahr zusammengebrochen, und er hätte nicht so lange in Ihrem Unternehmen bleiben können.

Ganz einfach, das Unternehmen muss ihm eine großzügige Gehaltserhöhung anbieten, um den aktuellen Stand der Software und all das Wissen, das nicht dokumentiert wird, zu dokumentieren, und dann feuern sie ihn. Oder sie beauftragen eine technische Beratungsfirma damit, alles zu dokumentieren, und er sieht die Schrift an der Wand und geht schließlich.