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:
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?
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.
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?
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.
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.
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.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.
Es gibt etwas, das ich in den anderen Antworten noch nicht gesehen habe:
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.
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.
Es scheint, dass es hier einige gute Mittel gibt, um dies in Zukunft zu verhindern, aber nicht, was jetzt dagegen zu tun ist.
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.
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.
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.
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.
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).
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.
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.
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:
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.
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.
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:
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.
Benutzer34102
BSMP
bob glasl
BSMP
Rat
smci
Knossos
Markus Rogers
Neil P
cst1992
bob glasl
T. Sar
Benutzer44634
Mittagsfleisch317
Markus Rogers
StartupGuy
teego1967
Markus Rogers
Karl Witthöft
HoffnungslosN00b
esh
bobo2000
Sascha
Juha Untinen