Wie geht man mit einem Kollegen um, der Software schreibt, um ihm Jobsicherheit zu geben, anstatt Probleme zu lösen?

Ich habe einen Kollegen, der hauptsächlich Programme für den internen Gebrauch im Unternehmen entwickelt. Sie gestalten ihre Programme so, dass sie ihre Position im Unternehmen nach und nach festigen, sodass sie nach und nach schwerer zu ersetzen sind. Einige Beispiele:

  • Checken Sie ihren Code nicht in die Versionskontrolle des Unternehmens ein, verteilen Sie nur kompilierte Binärdateien.
  • Entwerfen Sie ihre Programme unter Verwendung einer Client-Server-Architektur, sodass die von ihnen verteilten Programme Thin Clients sind, die Anforderungen an einen Server senden, den sie auf ihrem Computer ausführen. niemand weiß, wie dieser Server funktioniert oder was er tut (außer einer allgemeinen Beschreibung).
  • Wenn irgendetwas im Zusammenhang mit ihren Programmen kaputt geht, ist die einzige Person, die es reparieren kann, sie selbst, alle anderen haben keinen Zugriff auf seinen Code und es fehlt das erforderliche Wissen, um die Funktionalität seines Servers zu replizieren.
  • Niemand hat die Zeit, parallele Programme zu schreiben oder den geheimen Server zurückzuentwickeln, also bleiben wir bei dem, was wir von dieser Person bekommen.

Da sie einen großen Teil der Programme entwickelt haben, die wir intern verwenden, können sie nicht ersetzt werden, und da sie nicht ersetzt werden, kommen wir aus dieser Situation nicht heraus. Und wir werden immer abhängiger von dieser Person, da sie ihren Code ständig so gestaltet, dass sie ihre Position im Unternehmen stärkt.

Wie kann man aus diesem Teufelskreis ausbrechen? Wie kann man das Management darauf ansprechen?

Wenn Sie ein Kollege sind, können Sie wahrscheinlich nichts tun; Es ist eine Sache des Managements, einige Standards festzulegen und deren Anwendung im gesamten Unternehmen zu erzwingen
Sind Sie der Vorgesetzte dieser Person?
Nein, wir sind komplett in verschiedenen Teams.
Ist das Management mit dieser Situation einverstanden? Beeinflusst es Ihre eigene Arbeit?
Anstatt gegnerisch zu sein und Look! Er verschanzt sich! Unfair! Sie sollten sich beim Management dafür einsetzen, dass Sie darauf vorbereitet sind, dass Ihr Kollege von einem Bus angefahren wird
Inwiefern ist das speziell ein Problem für Sie persönlich? Sie sagen immer „wir“, aber Sie sind nicht das Unternehmen. Wenn Sie fragen „Wie geht man damit um…?“, welche konkreten Probleme hat es Ihnen in den letzten Monaten bereitet? Vielleicht misstrauen sie dem Management, aber wenn Sie sie bitten, Ihnen etwas zu erklären (verbal, durch Beispiele, was auch immer), tun sie es oder nicht?
@bobglausl: Zitieren Sie Bus Factor an Ihr Management. -- en.wikipedia.org/wiki/Bus_factor
Wer weiß, was die Verteidigung des beleidigenden Entwicklers ist? Es kann sein, dass der beleidigende Entwickler die Dinge so macht, wie es das Management erwartet, und es ist wirklich das OP, das missversteht. Es ist wirklich schwer zu sagen, was hier objektiv passiert.
@bobglausl wären die Teamkollegen in der Lage oder bereit, diesen Kodex zu unterstützen? Das würde sofort etwas von dem Risiko nehmen. Vielleicht können Sie sie davon überzeugen, die Quellcodeverwaltung dieser Anwendungen zu übernehmen. Abgesehen davon klingt es so, als ob es vielleicht eine organisatorische Politik gibt, die die wahre Ursache ist
Wenn Sie nicht im Team des Typen sind, warum kümmert es Sie überhaupt, und woher wissen Sie, dass die Teamkollegen dieses Teams nichts getan haben? Alles, was Sie wirklich tun müssen, ist, sie darüber zu informieren, dann werden sie sich Gedanken darüber machen, wie es weitergehen soll. Du bist nicht in ihrem Team, es liegt nicht in deiner Verantwortung.
@cst1992 Das liegt daran, dass es meine Arbeit direkt beeinflusst.
Nur eine Anmerkung: Schreiben Sie nicht der Bosheit zu, was leicht als Dummheit erklärt werden kann. Ich hatte einen Kollegen, der etwas Ähnliches gemacht hat - der exotische Code, das No-Check-in, die Client-Server-Programme ... am Ende wollte er nur nervös sein und "neue" Technologien wie Webservices und dergleichen ohne verwenden echte Notwendigkeit dafür.
Schreiben Sie ein Skript mit XCopy, das seinen Code jede Nacht auf einen Netzwerkserver kopiert und Änderungen in die Quellcodeverwaltung eincheckt.
Stellen Sie einen Entwickler oder Auftragnehmer ein, der gut genug ist, um die benötigten Informationen zu erhalten. Sein Computer ist im Netzwerk, richtig? Wenn ja, ist es zugänglich. Sein Code ist irgendwo auf einer Festplatte, richtig? Wenn ja, ist es zugänglich. Es gibt bessere Möglichkeiten, mit diesem Problem umzugehen - aber wenn diese Maßnahmen nicht funktionieren, ist es am Ende des Tages immer noch ein Firmencomputer, ein Firmennetzwerk und ein Firmencode.
Anfänger-Entwickler versuchen immer, das Neueste und Beste zu verwenden, auch wenn sie nichts darüber wissen.
Was codiert er ein? Wir hatten einen Entwickler, der das mit .Net-Projekten gemacht hat. Wir dekompilierten alle seine „geheimen“ DLLs, stellten sicher, dass wir den Stack mit dem dekompilierten Code zum Laufen bringen konnten, und feuerten ihn. Wenn Sie nicht können, dann beenden Sie, wie von @Jasper vorgeschlagen
@MarkRogers, die Sache ist die, dass jeder seine Erfahrungen sammeln möchte, und in diesem Bereich sind viele Leute leidenschaftlich daran interessiert, auf dem Laufenden zu bleiben. Dies kann sowohl in ganzen Gruppen als auch bei Einzelpersonen geschehen. Manchmal stürzen sich Leute auf Dinge, für die sie noch nicht bereit oder mit denen sie nicht vertraut sind, um weiterzukommen. Das ist nicht unbedingt eine schlechte Sache, es zeigt die Bereitschaft, sich weiterzuentwickeln. IMHO ist es viel schlimmer, mit Anfängern umzugehen, die nicht bereit sind, neue Sachen auszuprobieren.
Ich stimme zu, dass Sie keine Leute wollen, die niemals neue Dinge ausprobieren, aber wie bei allen Dingen ist ein Gleichgewicht zwischen pragmatischen Lösungen und Experimenten erforderlich. Es ist gut, neue Dinge auszuprobieren und zu experimentieren, aber die dafür aufgewendete Zeit steht normalerweise im Widerspruch zu strengen Fristen und geschäftlichen Anforderungen.
Kopieren Sie ihn! Reduzieren Sie Ihre Arbeitsbelastung und erhöhen Sie Ihre Arbeitsplatzsicherheit!
Warum sagen Sie, dass sein Code keine Probleme löst? Es klingt auf jeden Fall so, als würde es sein Problem mit der Arbeitsplatzsicherheit lösen.
Ich sehe hier kein Problem. Warum ist er dein Problem?
Guy ist ein Genie, um ehrlich zu sein. +1 Stimme @CarlWitthoft zu
Ich frage mich, wie diese Geschichte ausgegangen ist...
Ich kann aber sehen, woher er kommt. In den meisten Verträgen heißt es paraphrasiert: „Jeder Code, der während der Arbeitszeit geschrieben wird, gehört dem Unternehmen“. Indem er also einen Thin Client in den tatsächlich verwendeten Code schreibt, schützt er seine Implementierung und kann den externen Code an anderer Stelle wiederverwenden.

Antworten (17)

Sie müssen einen Bericht für das Management erstellen.

Schreiben Sie ein kurzes Dokument, in dem Sie genau darlegen, warum der aktuelle Ansatz das Unternehmen auf einen gefährlichen Weg führt (z. B. von einem Bus angefahren zu werden). Skizzieren Sie Sicherheitsrisiken, zitieren Sie vielleicht sogar warnende Geschichten aus Ihrer Branche, mit Verweisen auf Artikel usw.

Fügen Sie auch eine Liste von Wegen bei, in denen die Herangehensweise dieses Typen Ihre eigene Arbeit sowie die Ihrer Kollegen beeinträchtigt.

Stellen Sie zu guter Letzt sicher, dass Sie eine Liste mit Empfehlungen erstellen, die sofort umgesetzt werden sollen, z. B. das Hinzufügen des Codes zur Versionskontrolle, damit alle ihn sehen können, und das Ausführen des Servers auf einer VM, auf die jeder Zugriff hat. Erläutern Sie, dass diese Maßnahmen die Arbeit dieser Person in keiner Weise beeinträchtigen sollten und dem gesamten Prozess lediglich mehr Sicherheit und Transparenz verleihen – machen Sie deutlich, dass es keine vernünftigen Einwände gegen diese Maßnahmen gibt.

Setzen Sie sich vielleicht mit Ihrem Chef zusammen, wenn Sie ihm diesen Bericht aushändigen, und äußern Sie mündlich genau die Befürchtungen, die Sie hier geschrieben haben: dass dieser Typ sich in der Infrastruktur des Unternehmens ein Imperium aufbaut und dass er letztendlich potenziell gefährlich ist . Wenn Ihre Vorgesetzten der Meinung sind, dass diese Person unvernünftig werden könnte, sollten Sie vielleicht dem Rat von @BillLeeper folgen und die Kontrolle über seine Maschine übernehmen, damit er Ihrer Organisation keinen Schaden zufügen kann. Dies wird natürlich ihre Entscheidung sein.

Die Manager sind sich der Situation bewusst (dass die Arbeit mit dieser Person schwierig ist), aber ich bin mir nicht sicher, ob sie die Art und Weise vollständig verstehen, in der dies gefährlich ist, da es irgendwie subtil ist – schließlich haben wir die Werkzeuge, die wir brauchen unsere Arbeitsplätze. Es ist nur so, dass dies langfristig eine Katastrophe sein könnte, aber meistens interessieren sich die Leute nur dafür, was direkt vor ihren Augen ist ...
@bobglausl - als Person, die das Ausmaß des Problems wirklich erfasst, ist es Ihre Pflicht, die Manager lückenlos über das Loch zu informieren, in das sie sich graben. Es ist nicht Ihre Aufgabe, mit Ihrem Kollegen darüber zu sprechen oder ihn in irgendeiner Weise zu belästigen. Es liegt in Ihrer Verantwortung, die Situation dem Management mitzuteilen. Dann können sie mit der Situation umgehen oder weiter ihr Loch graben.
Recherchieren Sie die Risikoanalyse, um ein gutes Format für dieses Dokument zu finden. Sie müssen die Risiken für das Unternehmen für das Management klar spezifizieren. Wenn Sie die Risiken in irgendeiner Weise quantifizieren können, sollten Sie dies tun. Sehen Sie sich auch die Entscheidungsmatrix-Vorlage an, um zu erfahren, wie Sie Dinge basierend auf ihrer relativen Wichtigkeit quantifizieren können.
@bobglausl - Darüber hinaus würde ich vorschlagen, die Zeit zu dokumentieren, die aufgrund von Problemen mit diesen Tools verloren geht. Geben Sie ihnen die Zahlen: Wir verlieren X Stunden pro Woche aufgrund von Fehlern in den Tools, die wir möglicherweise schneller beheben könnten, wenn wir Zugriff auf den Code hätten.
Der einzige Teil, dem ich nicht zustimme, ist, dass dieser Typ sich in der Infrastruktur des Unternehmens ein Imperium aufbaut . Dass das vorsätzlich ist, kann der OP nicht nachweisen. Diese Anschuldigung ist nicht notwendig und lässt es wahrscheinlich klingen, als wäre das Ganze saure Trauben. (Wenn ich mich verlesen habe und dies nicht nur eine Neuformulierung der ursprünglichen Annahme des OP war, dass der Mitarbeiter Arbeitsplatzsicherheit schafft, können Sie dies gerne ignorieren.)
@BSMP Der Typ hat das Imperium bereits aufgebaut. Selbst wenn er so naiv ist, dass er diese Tatsache nicht erkennt, oder so altruistisch, dass er damit keinen Schaden anrichten will, wird früher oder später jemand, der nicht so naiv oder altruistisch ist, in sie eindringen. Das ist kein „Vorwurf“, sondern eine „Risikoeinschätzung“ der aktuellen Lage.
"auf die jeder Zugriff hat" ... ich glaube, Sie meinen "auf die mehrere Personen Zugriff haben".
Dies ist möglicherweise ein schrecklicher Ratschlag, bis wir mehr über die politischen Verhältnisse wissen. Mit dem Typen in Konflikt geraten. Ein gütlicher und informeller Umgang damit auf OP-Gruppenebene ist viel weniger riskant. Beginnen Sie keinen Krieg, wenn ein Gespräch ausreicht. Sie haben keine Ahnung, dass mgmt Sie unterstützen wird, und selbst wenn, ist es möglicherweise nicht der beste Weg, um Dinge zu erreichen.

Dies ist ein Managementproblem .

Bevor kritischer Code bereitgestellt wird, sollte er versioniert, der Code überprüft und zumindest die Verwendung dokumentiert werden. Wenn es um Sicherheit geht, wählen Sie die richtigen Prüfer aus und schützen Sie das Repository und die Dokumente. Es gibt keinen Grund, warum dies nicht sofort gestartet werden kann.

Es gibt ein größeres Problem als die Arbeitsplatzsicherheit .

Jeder dieser Entwickler könnte aus Versehen oder aus eigenen Gründen bösartigen Code in das Unternehmen einschleusen. Schlimmstenfalls könnten sie aktiv schändliche Taten begehen, indem sie ihre selbst geschaffene Situation nutzen (Erpressung, Sabotage, Industriespionage usw.). Im besten Fall setzt ihre Undurchsichtigkeit jeden Sicherheitsbedenken aus und hinterlässt immer ein Fragezeichen über Audits oder Verantwortlichkeiten. Wenn etwas schief geht, wer sagt dann, dass sie nicht irgendwie beteiligt waren?

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Anständige Antwort, aber noch nicht vollständig. Wenn die Geschäftsleitung den Mitarbeiter für ausreichend fehlerlos hält, wird sie sich davon nicht beeindrucken lassen. -- Wenn Sie das Risiko der Nichtverfügbarkeit (Krankheit/Urlaub, von einem Bus angefahren) einbeziehen würden, wäre das großartig.
Deinem Worst-Case-Szenario stimme ich nicht zu. Sabotage ist weniger wahrscheinlich, könnte aber für eine viel größere Gruppe von Menschen ruinös sein. Der unerwartete Verlust eines großen Prozentsatzes intern entwickelter Tools könnte für ein kleines bis mittelgroßes Unternehmen der Todesstoß sein, der alle arbeitslos macht.
@Myles Das wurde in einem der Kommentare diskutiert, die entfernt wurden.
@ jimm101 Da Sie in den entfernten Kommentaren zustimmen, dass dies ein Schwachpunkt in der Antwort ist, werde ich eine Bearbeitungsanfrage stellen.
Ich möchte hinzufügen, dass Schwachstellen einer Software in ziemlich vielen Fällen tatsächlich Hintertüren sind, die von den Entwicklern der besagten Software installiert wurden. Das ist wirklich üblich. Manchmal ist es nur für die Entwickler, damit er etwas zum Testen umgehen kann, aber wenn jemand anderes es entdeckt ...

Leider haben Sie nicht wirklich gesagt, ob jemand mit dem Kollegen oder der Geschäftsleitung über diese Bedenken gesprochen hat. Ist es wirklich bösartig? Oder ist Ihr Kollege einfach nur blind? Oder ist das Management vielleicht blind?

Ich war selbst "dieser" Typ.

Bei meinem vorherigen Job hatte ich manchmal verschiedene Nebenaufgaben, um "dieses kleine Werkzeug zu machen" oder etwas Einfaches zu machen. Es stellt sich heraus, dass es nie Ressourcen für interne Software gibt ... Das ging normalerweise so:

- Kann sich jemand die Lösungen ansehen, die ich ausgewählt habe, um zu sagen, ob sie angemessen sind? -- Komm schon, wir brauchen nur ein einfaches Werkzeug, das einfach diese einfache Operation ausführt, mach es und es wird gut.

-- Kann ich für dieses Ding einen virtuellen Server auf unserem Server erstellen? -- Mann, das ist nur für den internen Gebrauch. Legen Sie es einfach zusammen mit anderen Sachen auf diese kaputte physische Kiste. Oder legen Sie es auf die Kiste, die wir-weiß-nicht-was-funktioniert. Oder stellen Sie es auf Ihre eigene Workstation.

Natürlich gab es nie Zeitressourcen, um Dokumente zu schreiben. Es sei denn, ich mache das in meiner Freizeit. Natürlich war alles, was ich sagen konnte, wenn einige Tools Probleme hatten, "daran arbeiten".

Und dann habe ich beschlossen aufzuhören. Das war der erste Moment, in dem jemandem in meinem Umfeld klar wurde, dass die „kleinen internen“ Tools tatsächlich wichtig sind und „einfache“ Dinge nicht so einfach sind. Ich habe ein paar Wochenenden damit verbracht, Dokumente zu schreiben, um meine Kollegen weniger zu verarschen. Fast ein Jahr ist vergangen und ich erhalte immer noch jeden Monat mehrere Anrufe, wie ich etwas mit meinen internen Tools machen soll.

Bearbeiten

Einige Kommentare haben darauf hingewiesen, dass ich ihnen nicht kostenlos helfen sollte. Dies ist im Allgemeinen richtig. Ich wollte klarstellen, dass ich nicht Stunden meiner Zeit in die Lösung ihrer Probleme stecke, sondern nur eine Minute damit verbringe, eine Frage zu beantworten. Technisch gesehen ist es immer noch so, dass ich damit die bestehenden Praktiken ermögliche und ermutige. Übrigens hat mir das Unternehmen eine Teilzeit- oder Stundenlohnstelle angeboten, um Probleme wie zuvor zu lösen, und ich habe es abgelehnt.

Die Sache ist die, ich bin nicht bereit, meine Ex-Kollegen dazu zu zwingen, „besser zu recherchieren“, anstatt mich einfach zu fragen: „Auf welcher Maschine läuft Veeam?“ wenn ich einfach den Namen oder die IP-Adresse sagen kann, ohne nachzudenken oder zu sagen "Es sollte in [..] geschrieben werden". Außerdem ist ein 2-Minuten-Telefonat mit einem Ex-Kollegen normalerweise eine ebenso positive und entspannende Ablenkung wie der Besuch einer Stapelbörse.

Ende bearbeiten

Was kann ich also vorschlagen? Ihr Kollege scheint ziemlich fähig zu sein, nicht wahr? Besprechen Sie dies mit der Geschäftsführung. Sagen Sie nicht "er wird unersetzlich". Frag sie einfach - was ist, wenn er geht? Was ist, wenn er längere Zeit krank wird? Überzeugen Sie sie, dass das Problem real ist. Sie sollten es mit diesem Typen selbst besprechen, um Lösungen zu finden. Vielleicht fehlen ihm einfach die Ressourcen? Vielleicht braucht er eine andere Person im "internen Software"-Team, um alles schön und hübsch zu machen?

"Almost a year has passed and I still receive multiple calls every month"- und Sie werden für immer Anrufe erhalten, solange Sie weiterhin kostenlosen Support und Dokumentation anbieten (ich nehme an, dass die Wochenenden, an denen Dokumente geschrieben wurden, unbezahlt waren). Sie arbeiten dort nicht mehr - wenn sie Sie so dringend brauchen, können sie Sie für die Supportanrufe bezahlen oder die von Ihnen gelieferten Projekte dokumentieren/pflegen. Sie denken, Sie helfen Ihren ehemaligen Kollegen, aber in Wirklichkeit ermöglichen Sie dem Management nur, schlechte Praktiken fortzusetzen, und bringen die verbleibenden Entwickler in die gleiche Situation.
@brichins dort schuldig. Aber ich kann es nicht ablehnen, ihnen zu helfen, und es ist nicht schlimm, sich gebraucht und wichtig zu fühlen :D Um fair zu sein, das Unternehmen hat versucht, mich für Teilzeit oder Stundenlohn wieder einzustellen, was ich abgelehnt habe und dies auch weiterhin tun werde .
Warum können Sie sich nicht weigern, ihnen zu "helfen"? Selbst wenn die Entwickler persönliche Freunde außerhalb der Arbeit sind (ganz anders als „Arbeitsfreunde“), werden sie dafür bezahlt, dort zu arbeiten, und Sie nicht. Sich im Austausch für unbezahlte Arbeit „benötigt und wichtig“ zu fühlen, ist eine (indirekte) missbräuchliche Beziehung zum Unternehmen. Die Bereitstellung kostenloser Hilfe senkt den (wahrgenommenen) Wert der Mitarbeiter, setzt unrealistische Erwartungen in Bezug auf Projektkosten/-anforderungen und ermutigt Manager, Entwickler weiterhin schlecht zu behandeln. Akzeptieren Sie entweder eine gerechte Bezahlung direkt vom Unternehmen oder hören Sie auf, unentgeltlich zu arbeiten und die Zukunft Ihrer Freunde zu untergraben.
@brichins ist völlig richtig. Da kostenloser Support bereitgestellt wird, hat das „Management“ keinen Anreiz, das Problem zu beheben und Ressourcen (z. B. ehemalige Mitarbeiter) für die Lösung des Problems bereitzustellen.
@Juris, du wirst dich gebraucht und wichtiger fühlen, wenn sie dich stundenweise für deine Zeit bezahlen. Sagen Sie ihnen, dass Sie ihnen x weitere Stunden Freizeit geben, und danach muss der Zähler laufen, weil Sie andere Aufgaben haben, für die die Leute Sie bezahlen. Erstaunlich, wie viel besser die Leute ihre Fragen recherchieren, wenn sie dem Beantworter 80 Dollar pro Stunde oder was auch immer zahlen. Sie tun ihnen also wirklich einen Gefallen, wenn Sie sie anklagen. Indem Sie sie dazu bringen, Ihrer Zeit mehr Wert beizumessen, bringen Sie sie dazu, auch ihrer Zeit mehr Wert beizumessen.
@BobRodes vielleicht hast du mich falsch verstanden. Ich investiere keine Zeit in die Lösung von Problemen, sondern beantworte nur Fragen darüber, was und wie ich getan habe.
Ich denke, dass einige Kommentatoren hier in sehr strukturierten Umgebungen arbeiten, in denen die SW-Entwicklung die "Kernaufgabe" der Organisation ist. Aber es gibt viele Nicht-Software-Unternehmen, die immer noch "Softwareentwicklung" nur für interne Bedürfnisse oder als Nebenprojekte betreiben. Solche Orte haben ein Management, das die Natur der SW-Entwicklung völlig missversteht, sodass Sie mit Ad-hoc-Projekten, schlechter Planung und keinem Gedanken an die Wartung enden. Es ist nicht optimal, aber es ist ein Weg, mit dem VIELE Menschen anfangen. Die Veränderung einer solchen Organisation ist für eine Person wie das Kochen des Ozeans.
@Juris Nein, ich glaube nicht, dass ich das tatsächlich getan habe, obwohl unsere Meinungen unterschiedlich sein können und das vollkommen in Ordnung ist. Meiner Meinung nach, wenn Sie überhaupt Zeit investieren, ihnen zu helfen, müssen Sie irgendwann aufhören, es kostenlos zu tun. Bis dahin wird dort die vorherrschende Meinung sein, dass es einfacher ist, Sie anzurufen und nach Antworten auf triviale Fragen zu fragen, als selbst Antworten zu finden. Menschen suchen im Allgemeinen nach der einfachsten Lösung für ihre Probleme. Wenn Sie sich selbst die einfachste Lösung machen, indem Sie kostenlosen Support anbieten, werden Sie so lange angerufen, bis Sie mit dem Aufladen beginnen.
@teego1967 Ich kann mit diesem Kommentar sympathisieren, weil ich diese Person war. Nicht in dem Maße wie in OPs Frage, aber ich habe mehrere Tools und Datenbanken erstellt, die unternehmensweit verwendet werden können (für ein kleines Produktionsunternehmen). Zum Teil, weil ich das Problem aus erster Hand kannte, aber vor allem, weil es nie fertig werden würde, wenn ich darauf warten würde, dass die Unternehmens-IT es erledigt. Es war jedoch immer mit der Absicht "Lasst es uns versuchen, und wenn es gut genug funktioniert, kann es sich die IT nicht leisten, es nicht zu unterstützen"

Die meisten dieser Antworten sind VIEL ÜBERBORD, wenn sie böswillige Absichten seitens des betreffenden Entwicklers annehmen.

Bevor Sie ein heimliches Bild des Servers machen und den Typen dann aus dem Büro führen, warum atmen Sie nicht einfach durch und versuchen zu verstehen, was los ist?

Es könnte sehr gut sein, dass die betreffende Person überarbeitet ist, nicht über genügend Ressourcen verfügt und mehr als bereit wäre, Wissen zu teilen. Oder vielleicht macht er es schon lange so und hat nie einen Hinweis erhalten, dass er es anders machen muss. Zumindest wenn seine Sachen FUNKTIONIEREN, verdient er zumindest eine Chance, Bedenken auszuräumen und mit Kollegen zusammenzuarbeiten.

Ich sehe keine Beweise dafür, dass dies in der Frage des OP versucht wurde. Bevor Sie drakonische Optionen in Betracht ziehen, versuchen Sie zuerst die Kommunikation. Wenn die Person keine Absicht hatte, Schaden anzurichten, können Sie von ihr Kooperation erwarten.

Sie haben die Ressourcen und die Zeit, ihre Programme richtig zu entwickeln, sie sind nur nicht kooperativ und leiden unter dem gleichen Syndrom wie die Gnome-3-Entwickler, das heißt, sie glauben, sie wüssten besser als die Benutzer, was die Benutzer wollen. Ihre Programme funktionieren die meiste Zeit, außer wenn sie es nicht tun - dann bleibt Ihnen nichts übrig, denn was Sie auf Ihrem Computer ausführen, ist ein Thin Client, und Sie haben keinen Zugriff auf den Server, also können Sie es nicht einmal sagen, was genau schief gelaufen ist. War es etwas, was du getan hast? Probleme mit der Netzwerkverbindung? Server ausgefallen? Kann ich nicht sagen, da Fehler auch überhaupt nicht beschreibend sind.
@bobglausl: Dann lass sie als erste Aufgabe ihre Fehlermeldungen verbessern.
Ja. Ich rieche überarbeitet. Wahrscheinlich war der Typ etwas zu lange dem rohen Druck für die kritischen internen Apps ausgesetzt (die jetzt nur noch "Werkzeuge" sind, da sie jetzt funktionieren) und er beschloss, seine mickrigen Manager ihre Verantwortung vollständig selbst übernehmen zu lassen. Git-Server wurde nicht priorisiert - gut, es gibt keinen. Admin nicht zugewiesen - gut, es gibt keinen. Ich habe keine Zeit eingeplant, um genau diese Probleme zu kommunizieren - gut, also werden Sie diese nicht lernen. Und schließlich wurde er in diese Routine gedrängt und wiederholt sie jetzt unbewusst, auch wenn er jetzt mehr Zeit hat. Ausgebrannt. Nur meine wilde Vermutung.
@bobglausl in der ursprünglichen Frage sagst du 'ein Kollege' Singular, aber dann sagst du im Kommentar hier 'sie'. Welches ist es? Ich vermute, Sie sagen, dass das Unternehmen (jetzt?) groß genug ist, um sich die Ressourcen leisten zu können (aber nicht), und dass der Kollege als Handlanger für diesen „sorgsamen Umgang mit Ressourcen“ geendet ist. Der Kollege war vielleicht schon da, als die Ressourcen wirklich knapp waren . In vielerlei Hinsicht ist es normal. Niemandem die Schuld geben, allen helfen. Wir alle brauchen von Zeit zu Zeit Hilfe.
@PhilipOakley 'They' kann verwendet werden, um sich auf eine einzelne Person zu beziehen. Siehe en.wikipedia.org/wiki/Singular_they
@ user985366 nur in einigen Dialekten des Englischen, die von einer winzigen Gruppe von Menschen verstanden werden.
Singular sind sie nicht ungewöhnlich @Shautieh und werden immer häufiger.
@MarkBooth wirft irgendwie die Frage auf, ob die Benutzer von ihnen auch in Richtung Singular voranschreiten (rhetorisch / lächelt). Es ist sowohl die Stärke als auch die Schwäche des Englischen, dass es sich ständig in Gebrauch und Redewendung und Missverständnissen verändert; Wie sie sagen, Amerika und Großbritannien, zwei Nationen, die durch eine gemeinsame Sprache getrennt sind.
Historisch (bis ins mittlere Englisch des 14. Jahrhunderts zurück) war die Singularform von they viel häufiger, das Englische verlagerte sich im 19. Jahrhundert zu männlichen Pronomen und wir beginnen erst jetzt, dies umzukehren.
@MarkBooth ist in einigen parteiischen amerikanischen Foren und Websites üblich, wie eine schnelle Google-Suche zeigen kann, aber weder in einem formellen Kurs noch in einem gemeinsamen Gespräch im größten Teil der übrigen Welt. Als Ausländer ziehe ich es vor, richtiges Englisch zu lernen und zu sprechen und keinen grammatikalisch beeinträchtigten Slang.
Wenn die Königin „wir“ sein kann, kann der Rest von uns „sie“ sein @Shautieh. Wenn Sie von der viktorianischen Frauenfeindlichkeit eingeschränkt werden möchten, fühlen Sie sich frei, aber Ihr "richtiges Englisch" ist weder so verbreitet, wie Sie zu denken scheinen, noch ist es in einer offenen, egalitären Gesellschaft des 21. Jahrhunderts angemessen. Weitere Diskussionen sollten jedoch im The Workplace Chat geführt werden .
@Shautieh Der Begriff "sie" wird überall als Singularpronomen verwendet. Es ist kein obskurer Dialekt. Ich habe es aus allen Lebensbereichen gehört, überall, überall im Internet. Ich glaube du missverstehst einfach die Sprache.
Diese Semantikdebatte gehört woanders hin.
Bei dieser Antwort spielte es keine Rolle, ob böswillige Absicht oder nicht (solche unprofessionellen Dinge sollten auf jeden Fall aus dem Bericht ausgeschlossen werden); das risiko ist das gleiche.
@DoritoStyle, absolut nicht, die Absicht des Kollegen ist das Wichtigste, was bei der Entscheidung, wie man reagiert, zu berücksichtigen ist. Jemand, der keine böswilligen Absichten hat, wird bereit sein, sich zu ändern oder zu kooperieren und die Dinge in Ordnung zu bringen.
@teego1967 Ich bin völlig anderer Meinung. In dieser Situation muss OP dem Management einen emotionslosen und nicht anmaßenden Bericht erstatten und das Risiko berücksichtigen. Guter Vorsatz verhindert den Schaden nicht, wenn die betreffende Person plötzlich arbeitsunfähig wird.
Ich stimme dir nicht zu. Diese Person handelt in einer Weise, die ihre eigenen Interessen über die Unternehmen stellt und zweifellos den Zugang zum Quellcode usw. blockieren würde, wenn sie damit konfrontiert würde.

Es gibt etwas, das ich in den anderen Antworten noch nicht gesehen habe:

Beginnen Sie beiläufig mit der Suche nach einem neuen Job

Dies setzt natürlich voraus, dass Sie bereits mit Ihrem Vorgesetzten darüber gesprochen haben. Andere Antworten haben Gründe angegeben, warum dies nicht Ihr Problem ist, sondern das Ihres Vorgesetzten, und sie haben auch Hinweise gegeben, wie Sie dieses Gespräch mit Ihrem Vorgesetzten angehen können.

Jetzt sehe ich mir die Situation an, in der Sie mit Ihrem Vorgesetzten darüber gesprochen haben und dann, nachdem eine angemessene Zeit verstrichen ist, nichts diesbezüglich passiert ist. Sie haben das Gefühl, dass Ihr Vorgesetzter dies nicht so sehr für ein Problem hält, wie Sie wissen.

Vielleicht möchten Sie dort anfangen, sich nach einem neuen Job umzusehen. Egal, ob Ihr Manager dies einfach nicht für ein Problem hält oder dass er es einfach nicht gut genug versteht, um das Problem zu sehen, hier stimmt etwas nicht. (Und ich spreche nicht vom "privaten" Code, sondern von dem Problem, dass der Manager nichts dagegen unternimmt.)

Ein solches Problem ist etwas, das Sie als Entwickler wahrscheinlich nicht ändern können. Es gibt jedoch andere Unternehmen, die nicht die gleichen Probleme haben, sodass Sie sich vielleicht nach einem anderen Arbeitgeber umsehen sollten.

Von der positiven Seite gesehen lastet im Moment aber nicht allzu viel Druck auf dir. Sie haben einen Job und erwarten nicht, diesen Job zu verlieren. Sie müssen keine Kompromisse eingehen, um weiterhin Miete/Hypothek/Lebenshaltungskosten bezahlen zu können. Sie können sich einfach beiläufig umsehen und Ihren aktuellen Job nicht kündigen, bis Sie den Job gefunden haben, der Ihnen wirklich gefällt.

Das Fehlverhalten eines anderen Mitarbeiters sollte nicht der Grund für Sie sein, Ihren Job zu kündigen. Wenn ich ein anderer Entwickler bei dieser Firma wäre, würde ich es als Chance sehen: Wenn der betreffende Typ etwas wirklich Dummes tut, habe ich seinen Job, mit all der damit verbundenen Arbeitsplatzsicherheit (bis ich das Chaos behoben habe, natürlich). .
@gnasher729 Es ist nicht das Fehlverhalten des anderen Mitarbeiters, das der Grund ist, zu gehen. Es ist das Versagen des Unternehmens, mit dieser Situation umzugehen, und damit das Versäumnis, ein gutes Arbeitsumfeld zu schaffen.
@Jasper ... und damit das Scheitern der Firma, Punkt. Die Suche nach einem neuen Job als sicheres Netz ist keine schlechte Idee.
Ich kann nicht glauben, dass dies nicht die am besten bewertete Antwort ist. Ich war in genau dieser Situation. Entweder (A) das Kartenhaus wird herunterfallen und es liegt jetzt an Ihnen, es zu reparieren, weil der böse Entwickler gegangen ist, ob mgmt erkennt oder sich überhaupt darum kümmert, dass er böse war und Sie Recht hatten (B) mgmt wird es weiterhin tun schlechte Entscheidungen treffen und irgendwann Leute entlassen müssen, und raten Sie mal ... sie brauchen Sie nicht, aber der andere Typ ist verschanzt, also sind Sie draußen. Im Ernst, ich war dort und es ist eine kulturelle Sache, die man nicht mehr ändern kann, als man die Deutschen dazu bringen kann, auf dem Oktoberfest kein Bier zu trinken!
Sie haben einen ausgezeichneten Punkt in Bezug auf die Sache mit der Unternehmenskultur, aber ich glaube immer noch nicht, dass die beste Lösung darin besteht, sofort nach einem anderen Job zu suchen. Viele kleine oder neue Unternehmen finden immer noch heraus, wie sie ihre Geschäfte am besten führen können. Nur weil ein kleines Entwicklerteam eine „einfache“ Aufsicht hat (nach den Maßstäben eines Managers, der es möglicherweise nicht vollständig versteht), ist damit nicht das gesamte Unternehmen gemeint ist kaputt. Natürlich könnten Sie genau richtig sein, aber basierend auf den Informationen, die wir haben, ist das schwer zu sagen.
Sehen Sie nicht, wie das bedeutet, das Unternehmen zu verlassen ... es ist kein Problem, bis es ein Problem ist, in dem es im Moment kein Problem ist; es ist ein Risiko.
@AcumenSimulator, und genau deshalb schlage ich nicht vor, dass Sie das Unternehmen verlassen. Stattdessen schlage ich vor, beiläufig mit der Suche nach einem anderen Job zu beginnen. Wenn Sie einen Job finden, der Ihnen mehr gefällt als dieser, ist ein Jobwechsel ein guter Schritt, egal ob dieses Problem groß genug ist oder nicht. Wenn nicht, kannst du bleiben. Wenn sich die Situation verbessert, können Sie jederzeit aufhören zu suchen.

Alle aktuellen Antworten und die meisten aktuellen Kommentare stellen nur die aktuelle Situation dar oder geben Anregungen für extreme Schritte.

Um es kurz zusammenzufassen: Es gibt zwei mögliche Situationen: Die Mitarbeiter tun dies absichtlich, in diesem Fall sind sie auf die eine oder andere Weise böswillig, und dann ist äußerste Vorsicht geboten. Oder die Mitarbeiter sehen einfach nicht die potenziellen und tatsächlichen Probleme und Gefahren, die sie verursachen, dann sind sie "freundlich", sollten aber dazu angehalten werden, es besser zu machen.

Die folgende Roadmap versucht also zwei Dinge gleichzeitig: 1) Versuchen Sie, den potenziellen Schaden zu minimieren, den diese Mitarbeiter anrichten können, wenn sie böswillig sind, und 2) versuchen Sie, sie im Unternehmen zu halten (damit sie sich kooperativ entwickeln können Kollegen in Zukunft), wenn sie freundlich sind:

(Übrigens: Ich weiß, Sie sind nicht der Chef, aber mit den Informationen, die andere bereitgestellt haben, werden Sie wohl alles in der Hand haben, um Ihren Chef davon zu überzeugen, diesen Thread sehr ernst zu nehmen, also spricht diese Roadmap das an, was Sie Chef sind könntest, nicht was du tun würdest. Das Einzige, was du tun kannst, ist, deinen Chef darauf aufmerksam zu machen. btw2: Wenn dein Chef immer noch nicht zuhört, such dir einen neuen Job und kündige, sobald du einen neuen gefunden hast. Weil dass Kollegen tickende Zeitbomben sind, egal ob freundlich oder bösartig - das spielt überhaupt keine Rolle).

1.) Machen Sie stillschweigend Backups von allem, auf das Sie zugreifen können. Fahren Sie während des Prozesses keine Systeme herunter, da das Herunterfahren von Systemen möglicherweise einige Arten von Sprengfallen auslösen könnte.

2.) Konstruieren Sie einen Grund, warum die Arbeitsstationen heruntergefahren werden müssen. Wenn Sie eine Idee brauchen, kontaktieren Sie mich privat.

3.) Entnehmen Sie die Festplatten, erstellen Sie ein vollständiges Image und legen Sie sie wieder ein. Tun Sie dies über ein Wochenende oder so

4.) Wenn die Systeme über Intrusion Detection-Zeug auf BIOS-Ebene verfügen und Sie diese nicht umgehen können, konstruieren Sie einen anderen Grund, warum diese Intrusion Detection-Systeme ausgelöst haben.

Diese Kollegen erstellen Tools für interne Dinge, richtig? Sie benötigen also keinen Zugriff auf Kundensysteme und dergleichen?

5.) Wenn sie Zugriff auf Systeme haben, die sie nicht benötigen, ändern Sie Passwörter, stellen Sie sicher, dass es keine Art von Anmeldung mit öffentlichen Schlüsseln gibt, überprüfen Sie Ports auf Prozesse, die eine nicht standardmäßige Anmeldung zulassen. Überprüfen Sie cron/at-Jobs, überprüfen Sie inetd, überprüfen Sie alles, was gerade läuft. Für jede einzelne PID muss man beantworten können, warum dieser Prozess überhaupt läuft.

6.) Holen Sie sich einen neuen Mitarbeiter (wirklich neu, völlig unbekannt. Er muss ein wirklich guter Experte sein, denn er muss in der Lage sein, ihren Job für einige Monate alleine zu übernehmen, wenn es nötig sein sollte. Sie können nicht einfach welche nehmen zufälliger graduierter Student (nicht einmal einer mit der besten Note), Sie brauchen einige dieser Typen, die nie eine Universität besucht haben, aber immer noch alles wissen) und ihn in dieses Team einbauen, um sie zu unterstützen. Zumal sie bei den anderen Arbeitern Blockaden verursachen, lässt sich das leicht rechtfertigen. Seine offizielle Aufgabe ist es, sie zu unterstützen, seine wirkliche Aufgabe ist es, zu lernen, wie sie funktionieren.

Schritt 6 ist besonders wichtig, denn auf diese Weise haben Sie die Möglichkeit, tatsächlich herauszufinden, ob diese Kollegen überhaupt böswillig sind.

Wenn der Neue gut in das Team integriert ist, dann kann man davon ausgehen, dass er freundlich ist, dass der Neue in der Lage sein sollte, notwendige Änderungen umzusetzen, ohne diesen Leuten sagen zu müssen, dass überhaupt ein Verdacht gegen sie besteht.

Wenn der Neue herausfindet, dass sie bösartig sind, ihn aber integrieren, dann ist es seine Aufgabe, mitzuspielen. Alles lernen, cool finden, was sie machen, und so weiter. Zahlen Sie ihm das doppelte Geld, weil er zweimal arbeiten muss, denn wenn er nach Hause kommt, muss er alles aufschreiben, was er gelernt hat, und es an irgendein neu gebildetes Team schicken, das die Arbeit übernehmen soll, sobald genug Wissen übertragen ist.

Wenn die böswilligen Typen ihn nicht integrieren, besteht Ihre einzige Chance darin zu hoffen, dass Sie genügend Daten gesichert haben (nur für den Fall) und dieses Team feuern. Dann benötigen Sie möglicherweise zwei oder mehr zusätzliche dieser Superexperten, von denen ich oben gesprochen habe, um ein neues Team sehr schnell in diesen Code zu bringen.

Ich hoffe, diese Roadmap hilft - zumindest als Inspirationsquelle, wie man damit umgeht. Vielleicht haben Sie in Ihrem Unternehmen einige Optionen, die ich nicht berücksichtigen kann, vielleicht gibt es einige kulturelle Unterschiede, also müssen Sie noch darüber nachdenken und den Plan vielleicht anpassen.

Ausgezeichnete Antwort - obwohl einige dieser Schritte unnötig wären, da beispielsweise unsere Computer ziemlich streng vom IT-Team kontrolliert werden, was bedeutet, dass eine Änderung des BIOS nicht in Frage kommt, werde ich dem Management auf jeden Fall eine ähnliche Vorgehensweise vorschlagen. Ich kann immer noch nicht akzeptieren, dass diese Person zu irgendwelchen böswilligen Handlungen fähig wäre, aber die Antworten hier haben mich wirklich überzeugt, ihre Motive in Frage zu stellen.
Ich dachte an diese Standard-Intrusion-Detection-Systeme, die Sie heute auf vielen Standard-PCs bekommen, etwas, das diese Kollegen nicht selbst hätten bauen können.
Und bitte beachten Sie auch die Antwort von @Juris. Er würde immer noch in die Kategorie der freundlichen Spieler fallen, muss ihm aber möglicherweise nicht einmal etwas beibringen, sondern wird nur von zusätzlichen Entwicklern unterstützt.
Ich glaube, das Problem hier ist, dass EIN Mitarbeiter potenziell böswillig ist, nicht das gesamte Team. Trotzdem eine gute Antwort.
Zuerst sagte der OP "ein Kollege", dann sagte er "Sie". Es ist also nicht wirklich klar, ob es einer oder viele sind. Aber im Rest seines Beitrags schrieb er die meiste Zeit im Plural, also schätze ich, es ist ein ganzes Team.
@bobo-thiesen du hast den Kontext dort falsch gelesen. Das Pronomen bezieht sich auf das Subjekt „mein Kollege“, das eindeutig im Singular steht.
"Wenn Sie eine Idee brauchen, kontaktieren Sie mich privat." Eine solche Aussage gehört nicht wirklich zu SE. (Wenn ja, glauben Sie nicht, dass SE ein privates Nachrichtensystem gehabt hätte?)
@Jasper: Wenn dir meine Antwort nicht gefällt, verbessere sie (um zu sehen, ob deine Verbesserungen entweder von mir oder Krähen akzeptiert werden) oder schreibe deine eigene.
Den Autor über ein Problem in seiner Antwort zu informieren, ist eine vollkommen vernünftige Verwendung von Kommentaren . Da es Ihnen anscheinend lieber ist, wenn ich eine Bearbeitung vornehme, werde ich das tun. Ich weiß nicht, was Sie ausgelassen haben, daher wird Ihre Antwort ein "Loch" hinterlassen, aber es ist eine Verbesserung gegenüber der aktuellen Situation. Außerdem habe ich meine eigene Antwort geschrieben. Nichts davon ändert die Tatsache, dass "kontaktiere mich privat" nicht in einer Antwort stehen sollte.

Es scheint, dass es hier einige gute Mittel gibt, um dies in Zukunft zu verhindern, aber nicht, was jetzt dagegen zu tun ist.

  1. Sichern Sie den Computer. Lassen Sie entweder das Management und einen IT-Experten vorbeikommen, wenn es entsperrt und unbeaufsichtigt ist, oder gehen Sie und verlangen Sie, dass er die Maschine entsperrt und Zugang gewährt. Dann nimm dieses Monster aus dem Netz. Machen Sie sofort ein Bild des HD, falls er einen Totmannschalter hat.

  2. Feuern Sie diese Person sofort. Geh mit ihm aus der Tür. Machen Sie sich keine Sorgen wegen der Ursache, es wird jede Menge Beweise auf seinem Computer geben. Wenn die Firma besorgt ist, lassen Sie ihren Anwalt zaubern, dafür werden sie bezahlt.

  3. Bringen Sie das Team zusammen. Erklären Sie, was passiert ist. Diese Person handelte rücksichtslos und unprofessionell. Er gefährdete das Unternehmen und wurde dafür gekündigt. Es wird alle Ressourcen in Anspruch nehmen, die wir haben, um dieses Chaos zu beseitigen.

  4. Setzen Sie das Team ein, um diese Arbeit in geeigneter Weise auf gesicherten Computern usw. neu zu erstellen und bereitzustellen. Das Team muss App für App durchgehen und die Dinge in den Griff bekommen. Machen Sie sich nicht sofort Gedanken über das Umschreiben, stellen Sie einfach sicher, dass es keine Hintertüren usw. gibt, und bringen Sie die Dienste dann auf neue, kontrollierte Hardware.

  5. Holen Sie einen Sicherheitsexperten hinzu. Dieser Typ wird wahrscheinlich nicht ruhig bleiben und versuchen, sich wieder einzuhacken, um zu sabotieren oder sich anderweitig Zugang zu seinem System zu verschaffen. Er kann auch globale Passwörter für Systeme haben, mit denen er interagiert hat, oder im Laufe der Zeit Passwörter von Einzelpersonen erlangt haben. Die IT sollte bei allen Benutzern ein erzwungenes Zurücksetzen des Passworts auslösen und jeglichen externen Zugriff für eine gewisse Zeit blockieren (wie VPN).

Dies ist eine gute Antwort, aber es würde von Vorteil sein, klarzustellen, dass das OP das Management dazu bringen muss, dies zu tun. @emory Diese Antwort ist extrem und kann Annahmen über die Person treffen, die nicht wahr sind. Aber irgendetwas ohne ein vollständiges Backup der Maschine dieser Person zu tun, ist extrem riskant. Wenn Sie den Zugriff von dem Moment an, in dem Sie diesen Mitarbeiter darüber informieren, dass er ein Backup erstellt, bis zu dem Zeitpunkt, zu dem das Backup abgeschlossen ist, nicht einschränken, riskieren Sie, dass der Mitarbeiter wütend wird und Maßnahmen ergreift, die dem Unternehmen schaden.
Eine "moderatere" Antwort wäre, sicherzustellen, dass ein Backup-Image von seinem Computer erstellt wird, und ihm dann zu sagen, dass er alles in die Versionskontrolle bringen muss usw. Geben Sie ihm im Grunde die Chance, "das Richtige zu tun", bevor er nuklear wird aber schützen Sie sich vor den Folgen, wenn er es nicht tut.
@ jpmc26 Ich stimme zu, dass dies eine an das Management gerichtete Antwort ist (nicht OP). Für die Verwaltung empfehle ich text.sourcegraph.com/… gegenüber diesem Ansatz.
Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Du klingst lustig (NICHT!)
Das wirkt unglaublich hart. Was ist der Typ ist nur inkompetent?
@TheGreatDuck, das ist eine sehr gefährliche Situation für das Unternehmen. Wenn der Computer dieser Person einen Festplattenausfall erleiden würde, könnte der Verlust katastrophal sein. Selbst wenn er inkompetent ist, ist dies eine faire Reaktion und ein noch wichtigerer Grund, ihn/sie aus dem Team zu streichen.
@BillLeeper „Sichern Sie den Computer. Lassen Sie entweder das Management und einen IT-Experten vorbeikommen, wenn er entsperrt und unbeaufsichtigt ist, oder gehen Sie und verlangen Sie, dass er die Maschine entsperrt und Zugang gewährt. Dann entfernen Sie dieses Monster aus dem Netzwerk. Machen Sie sofort ein Bild davon HD, falls er einen Totmannschalter hat." Ich denke, es ist ziemlich extrem, den privaten Heimcomputer der Person zu beschlagnahmen und ihn im Wesentlichen zum Eigentum der Firma zu machen. Es scheint viel vernünftiger zu sein, den Typen einfach nach dem Quellcode zu fragen und das Problem zu erklären. Diese Antwort geht automatisch davon aus, dass der Entwickler böswillig ist, was offensichtlich unhöflich ist.
Wenn es mir schlecht ginge, würde dich keiner dieser Schritte retten. Vielmehr würden sie die Katastrophe sofort über eure Köpfe bringen.

Der betreffende Programmierer darf keine neue Arbeit erhalten, bis die Situation auf die eine oder andere Weise gelöst ist. Alle neuen Anforderungen müssen an einen anderen Entwickler/ein anderes Team gehen, das die ordnungsgemäße Quellcodeverwaltung und Peer-Review-Verfahren befolgen muss (ggf. neue Mitarbeiter). Der betreffende Programmierer kann damit beschäftigt sein, Fehler zu beheben oder sein vorhandenes Erbe zu „löschen“. Es müssen Ressourcen zugewiesen werden, um das vorhandene Erbe zurückzuentwickeln und durch geeignete Prozesse neu zu implementieren. Die Kosten dafür müssen durch das bestehende Risiko gerechtfertigt sein – was kostet es das Unternehmen, wenn alles, was dieser Programmierer getan hat, plötzlich verloren geht? Oder noch schlimmer, welche proprietären (Unternehmens-)Daten sind anfällig für Konkurrenzverluste?

Es könnte sich lohnen, diesen Mitarbeiter zu fragen: "Was passiert mit uns, wenn Sie von einem Bus angefahren werden oder sich entscheiden, eine einmonatige Kreuzfahrt um die Welt zu unternehmen?" und die Antwort abschätzen, um zu entscheiden, ob er seinen Code bereitwillig preisgibt. Wenn kooperativ, besteht keine Notwendigkeit, dass die Situation kontrovers wird; Wenn es seinerseits keine Anzeichen von Sorge um das Unternehmen gibt, ist es an der Zeit, sich damit zu beschäftigen, alles zu sichern, was er berührt.

Obligatorischer Urlaub - text.sourcegraph.com/… - Sie können diese einmonatige Kreuzfahrt Wirklichkeit werden lassen
OP nimmt wegen eines Kollegen . Es ist nicht seine Aufgabe, darauf zu reagieren, außer dem Management ein rotes Tuch zu zeigen.

Dies ist nicht Ihr Problem, dies ist die Verantwortung und Rolle des Managers, Sie sind nur ein Mitarbeiter und verfügen möglicherweise nicht über alle erforderlichen Informationen. Ich würde mich mehr um meine eigenen Aufgaben kümmern, als mich bei meinen Kollegen einmischen zu wollen. Ich kann mir nicht vorstellen, wie etwas Positives daraus entstehen würde, Aufhebens um Ihren Kollegen zu machen.

Sie machen sich einen Feind aus ihm, Sie zeigen Ihren Vorgesetzten als inkompetent an und erwecken den Eindruck, dass Sie so wenig Arbeit haben, dass Sie Zeit haben, interne Untersuchungen einzuleiten, ohne dazu aufgefordert oder befugt zu sein.

Das Problem ist, dass die Ergebnisse meiner eigenen Aufgaben von der Software abhängen, die von dieser Person entwickelt wird, und da diese Software von nicht sehr hoher Qualität und fehleranfällig ist, bremst sie mich aus.
Gehen Sie damit um, wenn es sich auf Ihre Aufgaben auswirkt, nicht als Ganzes. Dies ist die normale Art, mit Problemen auf niedrigerer Ebene umzugehen. Angenommen, Sie haben ein Fix-Request-System, verwenden Sie es. Aber springen Sie nicht auf und ab und versuchen Sie, den Kerl zu feuern, weil er Sie „bremst“.
Der Mitarbeiter wird zum @bobglausl-Problem, sobald die Firma stirbt. Es IST also sein Problem.
@BodoThiesen ja, und der Manager ist inkompetent, also ist das auch sein Problem, und der CEO hat seine Augen nicht auf dem Boden, also ist das sein Problem, und die Putzfrau hat das Gas nicht abgestellt, also ist das sein Problem, und der Kunde weiß nicht, was gut für ihn ist, und der Taxifahrer des Chefs ist ein Betrunkener ... usw. Irgendwann musst du realistisch und pragmatisch sein und dich um dich kümmern, nicht um alle anderen.
Wenn es um die Entscheidung geht, zu bleiben oder zu gehen, wird das seine Sache.
@bobglausl: Also lass den Typen ein bisschen mehr testen und seine Fehlermeldungen verbessern. Oder legen Sie zumindest einen Testplan fest, stellen Sie einen Junior-Tester/QA/SET ein, der die miese Arbeit erledigt, und lassen Sie ihn von dem Typen unterrichten. Scheint ein herzlicherer Ansatz zu sein. Sehr wahrscheinlich wird die Zusammenarbeit mit einem Tester seinen Code verbessern.
@Kilisi Jeder im Softwareteam besitzt die Software und ist dafür verantwortlich, dass sie schrecklich ist. Verbesserungen an der resultierenden Softwarefähigkeit liegen in der Verantwortung aller.
@Gusdor nein, ich bin für meine Aufgaben verantwortlich, der Manager ist gesamtverantwortlich und sollte eine klare Aufsicht haben, sein Chef ist für ihn und andere verantwortlich und sollte eine klare Aufsicht über ihre Arbeit haben ... schon mal von einer Hierarchie gehört? Ich bin nicht verantwortlich für meine Kollegen und ich werde meiner Managerrolle nicht vorgreifen. Ich habe weder seinen Lohn, noch habe ich Zugang zu seinen Informationen.
@Kilisi Wenn Sie einen schwerwiegenden Fehler in einer Arbeit finden, mit der Sie nicht beauftragt wurden, werden Sie das Produkt scheitern lassen und Ihren Kollegen leiden lassen, weil es Ihnen nicht zugewiesen wurde? Klingt nach einer wirklich lustigen Teamkultur.

Wie kann man das Management darauf ansprechen?

Sagen Sie, dass es aus vielen Gründen am besten ist, dies nicht zuzulassen.

Professionelle Programmierer sollten wissen, dass dies keine Art ist, ein Geschäft zu führen; und wenn Manager nichts anderes wissen, sollten sie das zumindest wissen (Programmierer sollten es Managern sagen und/oder Manager sollten es Programmierern sagen).

Die Gründe sind hoffentlich so bekannt, dass ich sie Ihnen nicht zu sagen brauche. Dazu gehört "Backup", dh Sie sind in Schwierigkeiten, wenn Sie den Programmierer verlieren (oder wenn sie etwas anderem zugewiesen werden) oder wenn der Programmierer seinen Computer verliert.

Wenigstens haben Sie eine „Unternehmensversionskontrolle“, sodass Sie diesen Kampf nicht führen müssen; Machen Sie es einfach zu einer Job-/Prozessanforderung, dass es tatsächlich verwendet wird.

Sie sollten wahrscheinlich keine Produktionssoftware auf dem Computer des Entwicklers ausführen. Ein erster Schritt könnte darin bestehen, darauf zu bestehen:

  • Benutzer stellen keine Netzwerkverbindungen zum Computer des Entwicklers her
  • Software wird auf/von einem Produktionsserver ausgeführt
  • Software, die auf dem Produktionsserver ausgeführt wird, muss von einer anderen Person (oder einem Buildcomputer) aus der Quellcodeverwaltung erstellt werden können

Für die Implementierung muss der Quellcode eingecheckt und die Build-Anweisungen veröffentlicht werden. Ich würde vorschlagen, dass Sie das als Halbnotfall tun. Gewähren Sie dem Entwickler keinen Schreibzugriff auf den Produktionsserver oder die Build-Maschine (um zu überprüfen, ob der Produktionscode von der Versionskontrolle erstellt werden kann).

Nachdem Sie das getan haben (nachdem Sie wissen, dass der Quellcode in der Versionskontrolle ist und die Build-Anweisungen veröffentlicht wurden), können andere Entwickler darüber nachdenken, den Quellcode zu inspizieren und bei der Wartung zu helfen.

Beachten Sie, dass Get Rid Of Indispensable Programmer As Quickly As Possible 1971 von Gerald Weinberg veröffentlicht wurde (also eigentlich sollte das inzwischen jeder wissen). IIRC das ursprüngliche Zitat ist,

"Wenn ein Programmierer unentbehrlich ist, werde ihn so schnell wie möglich los."

Ich weiß nicht, ob es nur Sie oder andere im Unternehmen sind, aber jeder kann ersetzt werden. Es kann Verzögerungen geben, aber es kann und sollte getan werden, wenn die Leute ihre Arbeit nicht machen. Ihre Manager tun ihre nicht.

Diese Entwickler brechen so ziemlich jeden grundlegenden Codierungsstandard. Das Management muss eine Ahnung haben, dass etwas nicht stimmt, aber es tut nichts dagegen. Ich sehe sie nicht als Lösung für dein Problem.

Sie müssen auch eine Arbeitsplatzsicherheit haben. Wenn es einen bestimmten Fehler gibt, den Sie beheben müssen, holen Sie sich den Quellcode. Wenn es sich auf ihrem Computer befindet, sagen Sie ihnen, dass sie es woanders kopieren sollen. Wenn sie Rechte an Produktionsservern haben, nehmen Sie sie weg. Sie können gehen und sich beim Management beschweren, wenn sie wollen. Sie werden dir einen Gefallen tun und ihre Inkompetenz aufdecken.

Hoffentlich erkennt jemand, dass der gesamte Code zentral gespeichert und gesichert werden muss. Dies ist das Eigentum des Unternehmens und alle Beteiligten sollten es gesichert haben wollen. Lass sie nicht mit diesem Schlamassel davonkommen. Sie besitzen nichts und haben nicht einmal die geringste Fähigkeit gezeigt, das geistige Eigentum des Unternehmens zu überwachen.

Die Frage ist, wie sehr wollen Sie aus diesem Teufelskreis ausbrechen? Seien wir nicht süß darüber, es wird die Firma kosten.

  1. Die Firma muss Geld ausgeben, um jemanden einzustellen, der Code schreibt, den die Firma kontrolliert.
  2. Die Firma muss den Code vom Programmierer verlangen und diese Forderung gegebenenfalls mit rechtlicher Hilfe unterstützen. Ich möchte darauf hinweisen, dass der Code von der Firma in Auftrag gegeben wurde, dass der Programmierer beim Schreiben des Codes einen Gehaltsscheck von der Firma gezogen hat, also ist der Code der Firma. Ein Versäumnis des Codierers, den Code herzustellen, würde im schlimmsten Fall als Diebstahl angesehen, was eine Straftat wäre.

Freiheit ist nicht frei. Wenn die Firma nicht bereit ist, Ressourcen aufzuwenden, um sich von dieser Person zu befreien, müssen Sie nur mit dem Zahnfleisch flattern. Sie alle müssen sich der Situation stellen, denn wenn der Programmierer wegzieht oder von einem Lastwagen überfahren wird, ist die Firma SOL.

Betrachten Sie den Grund, warum sie dies tun. Es ist durchaus möglich, dass Abstriche gemacht werden, um Zeitbeschränkungen, Leistungsziele und ständig steigende Anforderungen zu erfüllen. Dies führt oft zu technischen Schulden und einem sehr gestressten Programmierer, der keine andere Wahl hat, als jedes Problem auf Anhieb zu beheben.

Diese Person schreibt möglicherweise Dinge auf eine Weise, die nur sie selbst beheben kann, weil sie nicht die Zeit hat, Code rechtzeitig zu dokumentieren, zu versionieren und zu warten. Vertrauen Sie mir, wenn ich sage, dass dies eine durch und durch negative Wirkung auf jeden hat, der sich in dieser Position befindet. Es ist keine gemütliche Rolle, in der sich jemand zurücklehnen und entspannen kann.

Wenn sie, wie Ihr Titel andeutet, keine Probleme lösen, gäbe es kein Problem. Sie würden den Programmierer mit all seinem Code einfach rauswerfen, weil er nutzlos ist.

"Nicht in die Versionskontrolle einchecken" ist hier jedoch die rote Fahne. Es gibt keinen triftigen Grund, dies zu tun, wenn überhaupt möglich (offensichtlich kann es bürokratische Hindernisse geben, Ihre eigenen Sachen zu Unternehmens-VC hinzuzufügen, in diesem Fall ist es nicht absichtlich)
@ pjc50 Das ist so ziemlich das, was ich hier gedacht habe. Wenn es Einschränkungen beim Schreiben von Code gibt, der öffentlich verfügbar ist, aber Hürden zu überwinden sind, bevor ein neues privates Repository eröffnet wird. Es gibt nur eine Möglichkeit, Software in unzumutbarer Eile zu liefern.

Situationen wie diese zu verhindern, ist eine äußerst grundlegende Managementaufgabe. Daraus folgt, dass das Management, das sich des Problems bewusst ist, nicht kompetent ist, und das Management, das sich des Problems bewusst ist, nicht bewusst ist.

Leider ist das Entwirren solcher Situationen eine schwierige Managementaufgabe. Da die für diesen Entwickler verantwortlichen Manager nicht einmal in der Lage waren, die Situation zu verhindern, verlassen Sie sich nicht darauf, dass sie die Situation beheben können.

Die einzige* Möglichkeit, dies zu beheben, besteht darin, es zu einer höheren Managementebene zu eskalieren. Wenn sie interessiert und in der Lage sind, dies zu beheben, müssen Sie nicht einmal mehr erklären, als Sie uns erklärt haben - machen Sie es einfach weniger persönlich, indem Sie sich auf die Programme und die damit verbundenen Probleme konzentrieren, anstatt auf den Programmierer.

Sie sollten wissen, dass dies eine Option mit hohem Risiko und geringer Belohnung ist. Wenn Sie dies tun, selbst wenn es funktioniert, werden der Entwickler und sein Manager (der wahrscheinlich auch Ihr Manager ist) darunter leiden und wissen, dass Sie verantwortlich sind. Der einzige Vorteil, den Sie davon haben, ist, dass Sie (möglicherweise) Ihrem eigenen Ethik- und Ehrenkodex folgen, aber Sie könnten Ihren Job deswegen verlieren. Deshalb empfehlen einige der anderen Antworten, es sein zu lassen oder sich einfach einen besseren Job zu suchen, was klug ist.


*Die andere Möglichkeit, dies zu beheben, besteht darin, selbst zum Management zu werden und dies zu beheben, aber es gibt einige Fallstricke.

Nach seiner eigenen Selbsteinschätzung hat er entschieden, dass er keine Chance hat, befördert zu werden, und dass das Unternehmen ihn nur deshalb behalten müsste, weil er ihnen Code vorenthält.

Ich weiß nicht, ob Sie damit einverstanden sind, aber wenn ja, könnte der Code wahrscheinlich von jemandem besser gemacht werden. Oder wenn Sie nicht erklären, warum dieses Verhalten dafür sorgt, dass er niemals befördert werden kann.

Ich denke, es kommt darauf an, ob es sich lohnt, diese Situation zu beheben, und wie sie behoben werden kann.

Dies ist eine Aufgabe des Managements. Zuerst sollte das Management versuchen herauszufinden, ob dies beabsichtigt ist. Wenn dies der Fall ist, sollte ein Plan erstellt werden, um die beleidigenden Personen zu entlassen. Wenn es nicht beabsichtigt ist, sollte ein Plan erstellt werden, um die beleidigenden Personen zu schulen.

Sie gestalten ihre Programme ... so, dass sie nach und nach schwerer zu ersetzen sind.

Nicht wenn ich der Boss wäre!

Hier gibt es zwei Probleme:

  1. Schlechter Programmierer.

  2. Inkompetente Geschäftsführung.

Dies setzt natürlich voraus, dass Sie die Situation richtig darstellen.

Sie können Problem Nr. 1 nicht beheben. Es besteht eine geringe Chance, dass Sie Problem Nr. 2 angehen können. Diese geringe Chance besteht, wenn der Chef aus irgendwelchen Gründen einfach nicht weiß, was vor sich geht. Gehen Sie zum Chef und erzählen Sie ihm von den Problemen, die Sie sehen, und warum sie schlecht für das Unternehmen sind. Das wird wahrscheinlich scheitern, weil der Chef das Problem bereits kennt und nicht in der Lage ist, es anzugehen, oder so wenig über Software und die Verwaltung von Softwareentwicklern weiß, dass er nicht einmal in der Lage ist, das Problem zu verstehen.

Die einzige wirkliche Lösung besteht darin, mit der Behebung von Problem Nr. 2 zu beginnen, bei dem Sie bestenfalls eine untergeordnete Rolle spielen können. Der inkompetente Manager muss ersetzt werden.

Der neue Manager setzt sich dann mit diesem Programmierer zusammen, lässt ihn die Architektur erklären und sagt ihm, dass er jede neue Entwicklung stoppen und alle Protokolle dokumentieren soll. In der Zwischenzeit holt er einen neuen Ingenieur, der dem ersten Ingenieur beim Dokumentieren der Protokolle, beim Überführen der Software in die Quellcodeverwaltung und beim Sicherstellen, dass der Code selbst gut dokumentiert ist, "hilft". Dieser neue Ingenieur führt alle neuen Entwicklungen und hoffentlich Fehlerbehebungen und kleinere Verbesserungen bestehender Software durch.

Dem ersten Ingenieur wird das nicht gefallen. Er kann aufhören, einen Wutanfall bekommen, lautstark Einwände erheben oder, schlimmer noch, Dinge sabotieren. Aus diesem Grund ist das Erstellen eines Backups die erste Aufgabe. Es wäre schön, einen reibungslosen Übergang vom ersten zum zweiten Ingenieur zu haben, aber erwarten Sie das nicht. Der Plan ist, den ersten Ingenieur irgendwann zu feuern, wenn er nicht kündigt oder zuerst (noch mehr) destruktiv gegen das Unternehmen vorgeht.

Diesen Unsinn darf man einfach nicht zulassen. Je länger Sie dies tun, desto schmerzhafter ist es, es schließlich zu beheben. Es nicht zu reparieren, weil es schon schmerzhaft sein wird, ist absolut der falsche Weg, darüber nachzudenken.

In diesem Fall habe ich das rhetorische „Du“ verwendet. Um die Frage zu beantworten, was Sie persönlich tun können, beginnen Sie, wie oben gesagt, damit, Ihr Anliegen dem Chef vorzutragen. Wiederum ist es unwahrscheinlich, dass dies zu etwas Nützlichem führt.

Der nächste Schritt hängt von Dingen ab, die Sie uns nicht mitgeteilt haben. Es kann sehr gefährlich sein, über den Kopf Ihres Chefs hinwegzugehen. Dann bleibt Ihnen nichts anderes übrig, als abzuwägen, ob Sie dort wirklich weiterarbeiten wollen. Wenn dies ein Unternehmen ist, das klein genug ist, wo Sie bequem mit dem höheren Management sprechen können, dann machen Sie weiter. Es ist durchaus möglich, dass das höhere Management bereits das Gefühl hat, dass der Low-Level-Software-Manager inkompetent ist, aber das werden sie Ihnen natürlich nicht sagen. Dies könnte die zusätzliche Information für sie sein, um entschiedenere Maßnahmen zu ergreifen.

Eine andere entfernte Möglichkeit, wenn Ihr Hauptziel darin besteht, dieses Chaos zu beheben, und Sie sich als Langzeitbeschäftigter an diesem Ort sehen, besteht darin, anzubieten, einen Teil der internen Toolentwicklung selbst zu übernehmen. Das sollte Ihnen einen legitimen Grund geben, mit dem ersten Ingenieur zu sprechen, zu verstehen, wie die Dinge funktionieren, wo sich der Code befindet usw. Schließlich wären Sie der Werkzeugtyp, und das Management kann den ersten Ingenieur loswerden. Dann können Sie sie bitten, jemanden für diese Rolle einzustellen, damit Sie zu dem zurückkehren können, was Sie tun möchten. Auch dies ist nicht etwas, was ich ernsthaft vorschlage, aber es ist eine Alternative, wenn Sie es wirklich wollen und dazu bereit sind.