2016-11-01 17:47:53 +0000 2016-11-01 17:47:53 +0000
203
203

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

Ich habe einen Mitarbeiter, der in erster Linie Programme für den internen Gebrauch in der Firma entwickelt. Er gestaltet seine Programme so, dass sie nach und nach ihre Position innerhalb des Unternehmens festigen, so dass sie nach und nach schwieriger zu ersetzen sind. Einige Beispiele:

  • Sie checken ihren Code nicht in die firmeninterne Versionskontrolle ein, sondern verteilen nur kompilierte Binärdateien.
  • Sie entwerfen ihre Programme unter Verwendung einer Client-Server-Architektur, so dass die Programme, die sie verteilen, Thin-Clients sind, die Anfragen an einen Server senden, den sie auf ihrem Rechner laufen lassen; niemand weiß, wie dieser Server funktioniert oder was er tut (abgesehen von einer Beschreibung auf hoher Ebene).
  • Wenn irgendetwas im Zusammenhang mit ihren Programmen kaputt geht, ist die einzige Person, die es beheben kann, sie selbst, alle anderen haben keinen Zugang zu seinem Code und es fehlt ihnen das erforderliche Wissen, um die Funktionalität seines Servers zu replizieren.
  • Niemand hat die Zeit, einen parallelen Satz von Programmen zu schreiben oder den geheimen Server zurückzuentwickeln, so dass wir mit dem, was wir von dieser Person bekommen, feststecken.

Da sie ein riesiges Stück von Programmen 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 immer weiter entwickelt, um ihre Position im Unternehmen zu stärken.

Wie kann man aus diesem Teufelskreis ausbrechen? Wie kann man das Management diesbezüglich ansprechen?

Antworten (16)

179
179
179
2016-11-01 17:55:26 +0000

Dies ist ein Managementproblem.

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

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

Jeder dieser Entwickler könnte bösartigen Code in die Firma einbringen, entweder aus Versehen oder aus eigenen Gründen. Im schlimmsten Fall könnten sie unter Ausnutzung ihrer selbst geschaffenen Situation aktiv ruchlose Handlungen begehen (Erpressung, Sabotage, Industriespionage usw.). Im besten Fall setzen sie durch ihre Undurchsichtigkeit jedermann Sicherheitsbedenken aus und hinterlassen immer ein Fragezeichen bei allen Audits oder bei der Rechenschaftslegung. Wenn etwas schief geht, wer kann dann sagen, dass sie nicht irgendwie involviert waren?

129
129
129
2016-11-01 18:09:44 +0000

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

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

Fügen Sie auch eine Liste von Möglichkeiten bei, wie der Ansatz dieses Mannes Ihre eigene Arbeit sowie die Arbeit Ihrer Mitarbeiter beeinträchtigt.

Nicht zuletzt stellen Sie sicher, dass Sie eine Liste von Empfehlungen aufstellen, die sofort umgesetzt werden müssen, wie z.B. den Code zur Versionskontrolle hinzuzufügen, damit alle ihn sehen können, und den Server auf einer VM laufen zu lassen, auf die jeder Zugriff hat. Skizzieren Sie, wie diese Maßnahmen die Arbeit dieser Person in keiner Weise beeinträchtigen sollten, und fügen Sie einfach Sicherheit und Transparenz in den gesamten Prozess ein - deutlich machen, 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 überreichen, und geben Sie mündlich genau die Befürchtungen wieder, die Sie hier geschrieben haben: dass dieser Kerl sich in der Infrastruktur des Unternehmens ein Imperium aufbaut und dass er letztlich … potenziell gefährlich ist. Wenn Ihre Vorgesetzten das Gefühl haben, dass diese Person unvernünftig werden könnte, dann sollten Sie dem Rat von @BillLeeper folgen und die Kontrolle über seine Maschine an sich reißen, damit er Ihrem Unternehmen keinen Schaden zufügen kann. Dies wird natürlich ihre Entscheidung sein.

84
84
84
2016-11-01 23:46:24 +0000

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

Ich war selbst “dieser” Kerl.

In meinem vorherigen Job hatte ich manchmal verschiedene Nebenaufgaben, um “dieses kleine Werkzeug zu machen” oder etwas einfach zu machen. Es stellte sich heraus, dass es nie Ressourcen für interne Software gibt… Gewöhnlich lief es ungefähr so:

– Kann sich jemand die Lösungen, die ich gewählt habe, ansehen und sagen, ob sie angemessen sind? – Kommt schon, wir brauchen nur ein einfaches Werkzeug, das diese einfache Operation einfach ausführt, macht es und alles wird gut.

– Kann ich für diese Sache einen virtuellen Server auf unserem Server erstellen? – Mann, das ist nur für den internen Gebrauch. Setzen Sie ihn einfach zusammen mit anderen Sachen auf dieser kaputten physischen Box ein. Oder legen Sie ihn auf diese Box, die “wir-nicht-was-funktioniert”. Oder legen Sie es auf Ihre eigene Workstation.

Natürlich gab es nie Zeitressourcen, um Dokumente zu schreiben. Es sei denn, ich entschied mich dafür, es in meiner Freizeit zu tun. Natürlich war alles, was ich sagen konnte, wenn einige Tools Probleme hatten, “daran zu arbeiten”.

Und dann beschloss ich, aufzuhören. Das war der erste Moment, in dem jemand um mich herum erkannte, dass die “kleinen internen” Tools tatsächlich wichtig waren und “einfache” Sachen nicht so einfach sind. Ich verbrachte ein paar Wochenenden damit, Dokumente zu schreiben, um meine Kollegen weniger zu bescheißen. Es ist fast ein Jahr vergangen, und immer noch erhalte ich jeden Monat mehrere Anrufe, wie ich etwas mit meinen internen Tools machen könnte.

Bearbeiten

Einige Kommentare haben darauf hingewiesen, dass ich ihnen nicht umsonst helfen sollte. Dies ist im Allgemeinen richtig. Ich wollte klarstellen, dass ich nicht Stunden meiner Zeit in die Lösung ihrer Probleme investiere, sondern nur eine Minute für die Beantwortung einer Frage verwende. Technisch gesehen ist es immer noch richtig, dass ich auf diese Weise die bestehenden Praktiken ermögliche und fördere. Übrigens hat mir die Firma eine Teilzeit- oder Stundenlohnposition angeboten, um Probleme wie zuvor zu lösen, und ich habe dies abgelehnt.

Die Sache ist die, dass ich nicht bereit bin, meine Ex-Kollegen zu zwingen, “besser zu recherchieren”, anstatt mich einfach zu fragen: “Auf welcher Maschine läuft der Veeam?”, wenn ich einfach den Namen oder die IP-Adresse sagen kann, ohne nachzudenken, oder sagen kann: “Es sollte in […] geschrieben werden”. Abgesehen davon ist ein 2-minütiges Telefonat mit einem Ex-Kollegen in der Regel eine ebenso positive und entspannende Ablenkung wie ein Besuch bei Stackexchange.

Ende bearbeiten

Was kann ich also vorschlagen? Ihr Kollege scheint recht fähig zu sein, nicht wahr? Besprechen Sie dies mit dem Management. Sagen Sie nicht “er wird unersetzlich”. Fragen Sie sie einfach - was ist, wenn er geht? Was ist, wenn er für längere Zeit krank wird? Überzeugen Sie sie davon, dass das Problem real ist. Sie sollten es selbst mit diesem Mann besprechen, um Lösungen zu finden. Vielleicht fehlt es ihm einfach an Ressourcen? Vielleicht braucht er eine weitere Person im “internen Software”-Team, um alles schön und gut zu machen?

57
57
57
2016-11-02 00:09:57 +0000

Die meisten dieser Antworten sind WAY OVERBOARD auf Annahme böswilliger Absicht seitens des fraglichen Entwicklers.

Bevor man ein Schleichbild des Servers erstellt und dann den Mann aus dem Büro begleitet, warum nicht einfach mal durchatmen und versuchen, zu verstehen, was vor sich geht?

Es könnte sehr gut sein, dass die fragliche Person überlastet ist, nicht genügend Ressourcen hat und mehr als bereit ist, Wissen zu teilen. Oder vielleicht macht er das schon lange so und hat nie einen Hinweis erhalten, dass er etwas anderes tun müsste. Zumindest verdient er eine Chance, Bedenken auszuräumen und mit seinen Mitarbeitern zusammenzuarbeiten, vor allem, wenn seine Sachen WERKEN.

Ich sehe keine Hinweise darauf, dass in der Frage des OP irgendetwas davon versucht wurde. Bevor Sie drakonische Optionen in Betracht ziehen, versuchen Sie es zuerst mit Kommunikation. Wenn die Person nicht die Absicht hatte, Schaden anzurichten, können Sie von ihr Kooperation erwarten.

14
14
14
2016-11-02 11:29:22 +0000

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

Beginnen Sie ganz beiläufig mit der Suche nach einer neuen Arbeitsstelle

Dies basiert natürlich auf der Annahme, dass Sie bereits mit Ihrem Vorgesetzten darüber gesprochen haben. In anderen Antworten wurden die Gründe dafür genannt, 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 sollten.

Ich sehe mir jetzt die Situation an, in der Sie mit Ihrem Vorgesetzten darüber gesprochen haben und dann, nachdem eine angemessene Zeitspanne verstrichen ist, nichts darüber geschehen ist. Sie haben das Gefühl, dass Ihr Vorgesetzter das Problem nicht so sehr als Problem ansieht, wie Sie es kennen.

Da sollten Sie vielleicht mit der Suche nach einer neuen Stelle beginnen. Egal, ob Ihr Vorgesetzter dies einfach nicht für ein Problem hält oder ob er es einfach nicht gut genug versteht, um das Problem zu erkennen, hier stimmt etwas nicht. (Und ich spreche nicht von dem “privaten” Code, sondern von dem Problem, dass der Manager nichts dagegen unternimmt)

Ein solches Problem ist etwas, das Sie wahrscheinlich nicht von der Position eines Entwicklers aus ändern können. Es gibt jedoch andere Firmen, die nicht die gleichen Probleme haben, so dass Sie sich vielleicht nach einem anderen Arbeitgeber umsehen sollten.

Betrachtet man es von der positiven Seite, so steht man im Moment nicht allzu sehr unter Druck. Sie haben einen Job und Sie rechnen nicht damit, diesen Job zu verlieren. Sie werden keine Kompromisse eingehen müssen, um weiterhin Miete/Hypothek/Wohnkosten bezahlen zu können. Sie können sich einfach beiläufig umsehen und Ihren derzeitigen Job nicht aufgeben, bis Sie den Job gefunden haben, der Ihnen wirklich gefällt.

12
12
12
2016-11-01 19:26:26 +0000

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

  1. Sichern Sie den Computer. Entweder lassen Sie das Management und einen IT-Experten hinübergehen, wenn der Computer entsperrt und unbeaufsichtigt ist, oder Sie gehen hin und verlangen, dass er den Rechner entsperrt und den Zugriff gewährt. Dann schaffen Sie dieses Monster aus dem Netz. Machen Sie sofort ein Bild von der HD, falls er einen Totmannschalter hat.

  2. Feuern Sie diese Person sofort. Bringen Sie ihn zur Tür hinaus. Machen Sie sich keine Sorgen über die Ursache, auf seinem Computer wird es genug Beweise geben. Wenn die Firma besorgt ist, lassen Sie ihren Anwalt seinen Zauber wirken, dafür werden sie bezahlt.

  3. Stellen Sie das Team zusammen. Erklären Sie, was passiert ist. Diese Person hat sich rücksichtslos und unprofessionell verhalten. Er hat das Unternehmen in Gefahr gebracht und wurde dafür entlassen. Wir werden alle uns zur Verfügung stehenden Mittel einsetzen, um dieses Schlamassel zu bereinigen.

  4. Setzen Sie das Team ein, um diese Arbeit wieder aufzubauen und auf gesicherten Maschinen usw. ordnungsgemäß zu verrichten. Das Team wird App für App durchgehen und die Dinge in den Griff bekommen müssen. Kümmern Sie sich nicht sofort um das Neuschreiben, sondern stellen Sie nur sicher, dass es keine Hintertüren usw. gibt, und stellen Sie dann die Dienste auf frischer, kontrollierter Hardware bereit.

  5. Holen Sie einen Sicherheitsexperten herein. Dieser wird wahrscheinlich nicht leise gehen und versuchen, sich wieder “einzuhacken”, um sein System zu sabotieren oder anderweitig Zugang zu erhalten. Möglicherweise verfügt er auch über globale Passwörter für Systeme, mit denen er interagiert hat, oder hat im Laufe der Zeit Passwörter von Einzelpersonen erhalten. Die IT-Abteilung sollte bei allen Benutzern eine erzwungene Passwortzurücksetzung auslösen und jeden Zugriff von außen für eine gewisse Zeit blockieren (wie VPN).

12
12
12
2016-11-01 23:06:35 +0000

Alle aktuellen Antworten und die meisten aktuellen Kommentare geben nur die aktuelle Situation wieder oder enthalten Vorschläge für extreme Schritte.

Nur zusammenfassen: 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 die potenziellen und tatsächlichen Probleme und Gefahren, die sie verursachen, einfach nicht, 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 potentiellen Schaden zu minimieren, den diese MitarbeiterInnen tun können, wenn sie böswillig sind, und 2) versuchen Sie, sie im Unternehmen zu halten (damit sie sich in Zukunft zu kooperativen MitarbeiterInnen entwickeln können), wenn sie freundlich sind:

(nebenbei bemerkt: Ich weiß, Sie sind nicht der Chef, aber mit den Informationen, die andere zur Verfügung gestellt haben, werden Sie wohl alles in der Hand haben, um Ihren Chef davon zu überzeugen, diesen Thread sehr ernst zu nehmen, daher befasst sich dieser Fahrplan mit dem, was Ihr Chef tun könnte, und nicht mit dem, was Sie tun würden. Das Einzige, was Sie tun können, ist, die Aufmerksamkeit auf Ihren Chef zu lenken. btw2: Wenn Ihr Chef immer noch nicht zuhört, suchen Sie sich einen neuen Job und kündigen Sie, sobald Sie einen neuen gefunden haben. Denn dass Mitarbeiter tickende Zeitbomben sind, egal ob freundlich oder bösartig - das spielt überhaupt keine Rolle).

1.) Machen Sie stillschweigend Sicherungskopien von allem, worauf Sie zugreifen können. Fahren Sie dabei keine Systeme herunter, denn das Herunterfahren von Systemen könnte möglicherweise einige Arten von Sprengfallen auslösen.

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

3.) Extrahieren Sie die Festplatten, erstellen Sie ein vollständiges Image und legen Sie sie wieder ein. Machen Sie das über ein Wochenende oder so

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

Diese Mitarbeiter erstellen Werkzeuge für interne Dinge, richtig? Sie brauchen also keinen Zugang zu Kundensystemen und dergleichen?

5.) Wenn sie Zugang zu Systemen haben, die sie nicht brauchen, ä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 erlauben. Prüfen Sie cron/at-Jobs, prüfen Sie inetd, prüfen Sie alles, was derzeit läuft. Für jede einzelne pid muss man in der Lage sein zu beantworten, warum dieser Prozess überhaupt läuft.

6.) Besorgen 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. Man kann nicht einfach irgendeinen beliebigen graduierten Studenten (nicht einmal einen mit der höchsten Note) nehmen, man braucht ein paar von diesen Typen, die noch nie eine Universität besucht haben, aber trotzdem alles wissen) und ihn in dieses Team einsetzen, um sie zu unterstützen. Vor allem da sie bei den anderen Arbeitern Blockaden verursachen, lässt sich das leicht rechtfertigen. Seine offizielle Aufgabe ist es, sie zu unterstützen, seine eigentliche Aufgabe ist es, zu lernen, wie sie arbeiten.

Schritt 6 ist besonders wichtig, weil man auf diese Weise die Chance hat, tatsächlich herauszufinden, ob diese Mitarbeiter überhaupt bösartig sind.

Wenn der Neue gut in das Team integriert wird, dann kann man davon ausgehen, dass er freundlich ist, dass der Neue in der Lage sein sollte, die notwendigen Änderungen durchzuführen, ohne dass man den Mitarbeitern sagen muss, 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, es cool finden, was sie tun, und so weiter. Zahlen Sie ihm doppelt so viel Geld, denn er muss zweimal arbeiten, denn sobald er nach Hause kommt, muss er alles, was er gelernt hat, aufschreiben und an ein neu gebildetes Team schicken, das die Arbeit übernehmen sollte, sobald genug Wissen übertragen wurde.

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

Ich hoffe, dieser Fahrplan 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, so dass Sie noch darüber nachdenken und den Plan vielleicht anpassen müssen.

4
4
4
2016-11-02 02:48:00 +0000

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, der/die die korrekten Verfahren zur Quellenkontrolle und Peer-Review befolgen muss (ggf. Neueinstellungen). Der betreffende Programmierer kann mit der Behebung von Mängeln oder der “Brandbekämpfung” seiner vorhandenen Altlasten beschäftigt werden. Es müssen Ressourcen für das Reverse-Engineering des vorhandenen Altbestands und die Neuimplementierung durch geeignete Prozesse bereitgestellt werden. Die Kosten dafür müssen durch das bestehende Risiko gerechtfertigt sein - was wird es das Unternehmen kosten, wenn alles, was dieser Programmierer getan hat, plötzlich verloren geht? Oder schlimmer noch, welche proprietären (Firmen-)Daten sind anfällig für Wettbewerbsverluste?

Es könnte sich lohnen, diesen Mitarbeiter zu fragen: “Was passiert mit uns, wenn Sie von einem Bus überfahren werden oder sich zu einer einmonatigen Weltreise entschließen?” und die Antwort abzuwägen, um zu entscheiden, ob er seinen Code bereitwillig abgibt. Wenn er kooperativ ist, braucht die Situation nicht kontradiktorisch zu werden; wenn es keine Anzeichen von Besorgnis seinerseits für das Unternehmen gibt, hat er Zeit, sich um die Sicherung aller Dinge zu kümmern, die er berührt hat.

3
3
3
2016-11-02 16:37:26 +0000

**

Sagen Sie, dass es die beste Praxis ist, dies aus vielen Gründen nicht zuzulassen.

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

Die Gründe sind hoffentlich so bekannt, dass ich sie Ihnen nicht nennen muss. Sie beinhalten “Datensicherung”, d.h. Sie sind in Schwierigkeiten, wenn Sie den Programmierer verlieren (oder wenn ihnen etwas anderes zugewiesen wird), oder wenn der Programmierer seine Maschine verliert.

Zumindest haben Sie eine “firmeneigene Versionskontrolle”, so dass Sie diesen Kampf nicht kämpfen müssen; machen Sie es einfach zu einer Job/Prozess-Anforderung, dass sie tatsächlich benutzt wird.

Sie sollten wahrscheinlich keine Produktionssoftware auf der Maschine des Entwicklers laufen lassen. Ein erster Schritt könnte darin bestehen, darauf zu bestehen, dass:

  • Benutzer keine Netzwerkverbindungen zum Rechner des Entwicklers herstellen
  • Software auf/von einem Produktionsserver läuft
  • Software, die auf dem Produktionsserver läuft, muss von jemand anderem (oder von einem Build-Rechner) von der Quellcodekontrolle aus gebaut werden können

Eine Implementierung, die das Einchecken des Quellcodes und die Veröffentlichung der Bauanleitung erfordert. Ich würde vorschlagen, dass Sie das als Halb-Notfall machen. Erlauben Sie dem Entwickler keinen Schreibzugriff auf den Produktionsserver oder die Baumaschine (um zu verifizieren, dass der Produktionscode aus der Versionskontrolle heraus gebaut werden kann).

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

Beachten Sie, dass * Unentbehrlicher Programmierer so schnell wie möglich loswerden ** von Gerald Weinberg in 1971 veröffentlicht wurde (also sollte das eigentlich mittlerweile jeder wissen). Das Originalzitat des IIRC lautet:

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

2
2
2
2016-11-02 02:10:12 +0000

Das ist nicht Ihr Problem, das ist die Verantwortung und Rolle des Managers, Sie sind nur ein Mitarbeiter und haben möglicherweise nicht alle notwendigen Informationen. Ich würde mich mehr um meine eigenen Aufgaben kümmern, als mich in meine Kollegen einzumischen. Ich kann mir nicht vorstellen, wie etwas Positives dabei herauskommen könnte, wenn Sie sich um Ihren Kollegen Sorgen machen.

Sie machen ihn zum Feind, 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 zu werden oder dazu befugt zu sein.

1
1
1
2016-11-01 20:41:20 +0000

Die Frage ist, wie sehr Sie aus diesem Teufelskreis ausbrechen wollen. Denn seien wir nicht pfiffig, das wird die Firma teuer zu stehen kommen.

  1. Die Firma wird Geld ausgeben müssen, um jemanden einzustellen, der Code schreibt, den die Firma kontrolliert.
  2. Die Firma muss den Code von dem Codierer verlangen und diese Forderung gegebenenfalls mit juristischer Hilfe unterstützen. Ich weise darauf hin, dass der Code von der Firma in Auftrag gegeben wurde, dass der Codierer beim Schreiben des Codes einen Gehaltsscheck von der Firma bezogen hat, so dass der Code der der Firma gehört. Ein Versäumnis des Codierers, den Code zu erstellen, würde schlimmstenfalls als Diebstahl angesehen, was eine Straftat wäre.

Freiheit ist nicht frei. Wenn die Firma nicht bereit ist, Ressourcen aufzuwenden, um von diesem Individuum frei zu sein, dann ist alles, was Sie tun, nur Zahnfleisch flattern. Sie alle werden sich mit der Situation auseinandersetzen müssen, denn wenn der Codierer sich entfernt oder von einem Lastwagen überfahren wird, ist das Unternehmen SOL.

1
1
1
2016-11-02 10:55:10 +0000

Überlegen Sie, warum sie dies tun. Es ist durchaus möglich, dass die Ecken gekürzt werden, um Zeitbeschränkungen, Leistungsziele und ständig steigende Anforderungen zu erfüllen. Das führt oft zu technischer Verschuldung und zu einem sehr gestressten Coder, der keine andere Wahl hat, als jedes Problem aus dem Stand zu beheben.

Diese Person schreibt möglicherweise Dinge auf eine Weise, die nur sie selbst beheben kann, weil sie nicht die Zeit hat, den Code rechtzeitig zu dokumentieren, zu versionieren und zu pflegen. Glauben Sie mir, wenn ich sage, dass sich dies auf jeden, der sich in dieser Lage befindet, durch und durch negativ auswirkt. Es ist keine bequeme Rolle, in der sich jemand zurücklehnen und entspannen kann.

Wenn sie, wie Ihr Titel andeutet, Probleme nicht lösen, gäbe es kein Problem. Sie würden einfach den Coder mit all ihrem Code wegwerfen, weil er nutzlos ist.

0
0
0
2016-11-04 16:54:31 +0000

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 kompetent ist, ist sich nicht bewusst.

Leider ist es eine schwierige Managementaufgabe, Situationen wie diese zu entwirren. Da die für diesen Entwickler verantwortlichen Manager nicht einmal in der Lage waren, die Situation zu verhindern, sollten Sie nicht darauf zählen, dass sie in der Lage sind, die Situation zu lösen.

*Der einzige Weg, dies zu lösen, ist die Eskalation auf eine höhere Managementebene. * Wenn sie daran 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 Probleme mit ihnen konzentrieren, anstatt auf den Programmierer.

Sie sollten wissen, dass dies eine hohes Risiko - niedrige Belohnung Option 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 daraus ziehen, ist, dass Sie (möglicherweise) Ihren eigenen Ethik- und Ehrenkodex befolgen, aber Sie könnten deswegen Ihren Job verlieren. Deshalb empfehlen einige der anderen Antworten, es sein zu lassen oder sich einfach nach einem besseren Job umzusehen, was das Klügste ist.


*Der andere Weg, dies zu beheben, besteht darin, selbst zum Management zu werden und dies zu beheben, aber es gibt dabei eine ganze Reihe von Fallstricken.

0
0
0
2016-11-06 19:42:53 +0000

Nach seiner eigenen Selbsteinschätzung hat er sowohl entschieden, dass er keine Chance auf eine Beförderung hat, als auch der einzige Grund, warum die Firma ihn behalten müsste, ist, dass er ihnen den Kodex vorenthält.

Ich weiß nicht, ob Sie damit einverstanden sind, aber wenn Sie es sind, könnte der Kodex wahrscheinlich von jemand besserem gemacht werden. Oder wenn Sie nicht erklären, warum dieses Verhalten sicherstellt, dass er niemals befördert werden kann.

Ich denke, es kommt darauf an, ob es sich lohnt, diese Situation so sehr zu beheben, wie darauf, wie man sie behebt.

-1
-1
-1
2016-11-03 19:39:47 +0000

Dies ist eine Aufgabe für das Management. Das erste Management sollte versuchen, herauszufinden, ob dies beabsichtigt ist. Falls ja, sollte ein Plan zur Entlassung der beleidigenden Personen erstellt werden. Wenn es nicht absichtlich geschieht, sollte ein Plan zur Schulung der beleidigenden Personen erstellt werden.

-3
-3
-3
2016-11-06 13:44:49 +0000

Sie gestalten ihre Programme … so, dass sie allmählich schwieriger zu ersetzen sind.

Nicht, wenn ich der Chef wäre!

Hier gibt es zwei Probleme:

  1. Schlechter Programmierer.

  2. Inkompetentes Management.

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 lösen 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 fehlschlagen, weil der Chef bereits über das Problem Bescheid weiß und nicht kompetent ist, es anzugehen, oder weil er so wenig über Software und leitende Softwareingenieure weiß, dass er nicht einmal kompetent ist, das Problem zu verstehen.

Die einzige wirkliche Lösung ist, damit zu beginnen, Problem Nr. 2 zu beheben, bei dem Sie bestenfalls eine kleine Rolle spielen können. Der inkompetente Manager muss ersetzt werden.

Der neue Manager setzt sich dann mit diesem Programmierer zusammen, lässt sich von ihm die Architektur erklären und weist ihn an, jede neue Entwicklung zu stoppen und alle Protokolle zu dokumentieren. In der Zwischenzeit holt er einen neuen Ingenieur, der dem ersten Ingenieur “hilft”, die Protokolle zu dokumentieren, die Software in die Quellenkontrolle zu bringen und sicherzustellen, dass der Code selbst gut dokumentiert ist. Dieser neue Ingenieur macht jede neue Entwicklung und hoffentlich auch Fehlerbehebungen und kleinere Verbesserungen der bestehenden Software.

Das wird dem ersten Ingenieur nicht gefallen. Er könnte kündigen, einen Wutanfall bekommen, laute Objekte einbauen oder schlimmer noch, Dinge sabotieren. Deshalb ist das Erstellen eines Backups der erste Schritt. Es wäre schön, einen reibungslosen Übergang vom ersten zum zweiten Ingenieur zu haben, aber erwarten Sie nicht, dass das passiert. Der Plan ist, den ersten Ingenieur schließlich zu feuern, wenn er nicht kündigt oder sich (noch mehr) zuerst gegen die Firma richtet.

Sie können diesen Unsinn einfach nicht weitergehen lassen. Je länger Sie das tun, desto schmerzhafter ist es, ihn schließlich zu beheben. Es nicht in Ordnung zu bringen, weil es bereits schmerzhaft sein wird, ist der absolut falsche Weg, darüber nachzudenken.

In diesem Fall habe ich das rhetorische “Sie” benutzt. Um die Frage zu beantworten, was Sie persönlich tun können, beginnen Sie damit, dass Sie, wie ich oben sagte, Ihre Bedenken dem Chef vortragen. Auch hier ist es unwahrscheinlich, dass sich daraus etwas Nützliches ergibt.

Der nächste Schritt hängt von Dingen ab, die Sie uns nicht erzählt haben. Es kann sehr gefährlich sein, sich über den Kopf Ihres Chefs hinwegzusetzen. Wenn dem so ist, dann können Sie kaum etwas anderes tun, als zu beurteilen, ob Sie dort wirklich weiterarbeiten wollen. Wenn es sich um ein Unternehmen handelt, das klein genug ist und in dem Sie bequem mit dem höheren Management sprechen können, dann machen Sie weiter. Es ist gut möglich, dass das höhere Management bereits das Gefühl hat, dass der Software-Manager auf der unteren Ebene inkompetent ist, aber das wird man Ihnen natürlich nicht sagen. Dies könnte die zusätzliche Information für sie sein, entschlossener zu handeln.

Eine andere entfernte Möglichkeit, wenn Ihr Hauptziel darin besteht, dieses Durcheinander in Ordnung zu bringen, und Sie sich an diesem Ort für einen Langzeitexperten halten, ist das Angebot, selbst einen Teil der internen Werkzeugentwicklung zu übernehmen. Das sollte Ihnen einen legitimen Grund geben, mit dem ersten Ingenieur zu sprechen, zu verstehen, wie die Dinge funktionieren, wo der Code lebt usw. Letztendlich 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 wieder zu dem übergehen können, was Sie tun wollen. Nochmals, das ist nicht etwas, was ich ernsthaft vorschlage, aber es ist eine Alternative, wenn Sie es wirklich wollen und bereit sind.