Wie kann ich mich darauf vorbereiten, von einem Bus überfahren zu werden?

Dokumentation.

Angemessen häufige Code-Commits.

Dokumentation.

Dokumentieren Sie Ihre Ideen, Ihre Designs und Ihren Code. Dokumentieren Sie Ihre Fehlerbehebungen erläutern Sie, was das Problem war und wie Sie es behoben haben und warum.

Und habe ich Dokumentation erwähnt?

Wenn Sie in einer Umgebung arbeiten, in der die Richtlinien lax sind (so dass Junior-Entwickler sich einfach nicht die Mühe machen können, Änderungen an der Dokumentation einzureichen - relevante Dokumentationsaktualisierungen sollten bei jedem Zweigzusammenschluß _mandatiert werden), das Peer-Review fehlt (so dass Junior-/Senior-Entwickler während einer Flut von verständlicher Faulheit erwischt werden), und/oder die Dokumentation getrennt vom Code gespeichert wird (so dass sie leicht verloren gehen kann), dann ist es auch wichtig, zu überlegen, ob die Umgebung geändert werden kann, damit diese Probleme nicht so gemacht werden. Anderenfalls könnte all Ihre Mühe, Dokumentation zu schreiben, umsonst gewesen sein.

Abgesehen davon würde ich nicht immer so weit gehen, es eine persönliche Verantwortung zu nennen: Wenn die Teams letztlich unsachgemäß verwaltet und/oder organisiert sind, dann liegt das nicht in Ihrer Verantwortung; für den Fall, dass Sie zu einer neuen Aufgabe übergehen, würde ich Ihnen einfach meine fertige Dokumentation übergeben und denken: “Nun, wenn Sie diese nicht richtig benutzen und pflegen können, dann ist das Ihre Schuld… jetzt viel Glück”.

Diese Denkweise gilt jedoch nicht wirklich für den Fall “von einem Bus überfahren”, wo Sie vielleicht gerade dabei sind, eine solche Politik einzuleiten, es aber noch nicht ganz geschafft haben. Für dieses Szenario würde ich einfach vorschlagen, dass Sie das Management (und Ihre hochrangigen Entwickler) dazu ermutigen, diese Dinge so bald wie möglich ernst zu nehmen.

Machen Sie NICHTS anders. Arbeiten Sie so, als würden Sie morgen NICHT “von einem Bus überfahren”.

Das Problem der “Überfahrenen” ist ein organisatorisches Problem und nicht etwas, das in Ihren eigenen Arbeitszielen explizit angesprochen werden muss.

Ihre Mitarbeiter und das Management sollten darüber nachdenken, aber ich denke, es ist zu viel verlangt, von einzelnen Beitragszahlern zu erwarten, dass sie so arbeiten, als wären sie morgen buchstäblich weg. Wenn das Management die potenziellen Probleme hier nicht erkennt, bedeutet das, dass sie nicht auf dem Laufenden sind oder dass Sie vielleicht nicht so unentbehrlich sind, wie Sie dachten…

Wenn Sie großzügig sind, sollten Sie bestenfalls die Schlüsselpersonen und Führungskräfte daran erinnern, dass sie im Notfall Unterstützung brauchen. Aber in einer Ära, in der Unternehmen Karrieren aus einer Laune heraus um des kurzfristigen Profits willen “unter den Bus werfen”, wie sehr sollte Sie das wirklich interessieren?

Sorgfältige Ingenieurpraktiken lösen viele der Probleme des Dilemmas “von einem Bus überfahren”. Wenn man darüber hinaus so weit geht, dass man für ein sofortiges und dauerhaftes Verschwinden bereit ist, verursacht das für den einzelnen Beitragszahler eine Menge Aufwand. Es klingt so, als ob das vom OP beschriebene Umfeld einfach durch bessere Praktiken und Personalausstattung profitieren könnte, es besteht keine Notwendigkeit für ihn, so zu arbeiten, als ob er jeden Moment verdampfen könnte.

Wenn Sie als Auftragnehmer arbeiten, würde ich sagen, dass dies zu 100 % von Ihrem Arbeitgeber getragen wird. Sagen Sie ihm, dass das Erreichen der Ziele, die er Ihnen gesetzt hat, bedeutet, dass andere Dinge, die Ihrer Meinung nach als Ziele betrachtet werden sollten, nicht getan werden; fragen Sie ihn, ob er Ihre Ziele anpassen möchte. Möglicherweise wird man Ihnen sagen, dass Sie so weitermachen sollen, wie Sie sind, da Ihre Zeit teuer ist und sie kurzfristig das beste Preis-Leistungs-Verhältnis wollen.

Wenn Sie als Arbeitnehmer arbeiten, haben Sie vielleicht mehr Spielraum, um Ihre Nachfolge zu planen (oder es besteht möglicherweise die Erwartung, dass Sie dies bereits tun). Bringen Sie es trotzdem mit Ihrem Teamleiter oder Manager zur Sprache, denn er muss über das Problem Bescheid wissen und wissen, wie Sie sind und was Sie denken, wie Sie Ihre Zeit verbringen sollten.

Einige Dinge dazu würden bei der Nachfolgeplanung helfen:

• Alltägliche Prozesse sollten bis zu einem gewissen Grad dokumentiert werden, aber es ist wahrscheinlich, dass andere Personen in Ihrem Team die gleichen Prozesse befolgen und sie einem Neuankömmling beibringen könnten. Wenn Sie nicht alle ähnliche Prozesse verwenden, ist das ein aktuelles Problem, das gelöst werden sollte; kommen Sie zusammen, diskutieren Sie, welcher Weg der beste ist, kommen Sie zu einem Standard (einvernehmlich oder von oben erzwungen), und verwenden Sie den Standard, Glückwunsch, dieser Standard kann in Ihre Dokumentation für den Neuankömmling aufgenommen werden.
• Wichtige Dinge, die per E-Mail, in Besprechungen oder in zwanglosen Gesprächen kommuniziert werden, müssen es in eine gemeinsame Ressource schaffen, alles von einem Ordner mit Dokumenten auf einem gemeinsamen Laufwerk bis hin zu einem Wiki. Es gibt diesen seltsamen Glauben (zumindest dort, wo ich gearbeitet habe), dass, wenn etwas per E-Mail an alle Mitglieder eines Teams verschickt wird, dieses Team das Ding für immer kennen wird; dabei wird nicht berücksichtigt, dass sich die Zusammensetzung des Teams ändert und dass jedes Training (wenn es überhaupt stattfindet) niemals das gesamte Wissen, sondern nur eine Teilmenge häufig verwendeten Wissens übertragen wird.
• (Möglicherweise software-spezifisch) Dokument eindeutig kontraintuitive Prozesse oder Design-Entscheidungen, es ist wichtig zu erkennen, dass der Prozess als kontraintuitiv erkannt wird und warum er so ist, unabhängig davon. Wenn Sie zum Beispiel von Ihrem Kunden gebeten wurden, etwas zu tun, das “inkorrekt” erscheint (“Ich bin kein Domänenexperte, aber sind Sie sicher, dass Sie das tun wollen?”), und Sie erklärten, warum Sie dachten, es sei inkorrekt und sie bestätigten, dass es das war, was sie wollten (noch besser, wenn sie erklärten, warum), dann sollten die Gründe, warum Sie dachten, es sei inkorrekt und die Erklärung, warum es korrekt war, dokumentiert werden. Dass die Software gemäß den Spezifikationen funktioniert, wird für einen Ersatz nicht ausreichen, sie werden die gleiche Frage haben wie Sie.
• Bei jedem Problem, auf das Sie stoßen und das viel Zeit/Forschung erfordert, sollten Sie das Problem, die Symptome, den verkürzten Weg zur Lösung (d.h.: wissen, was Sie jetzt wissen, was der schnellste Weg von der Identifizierung der Symptome zur Lösung war) und die Lösung dokumentieren. Symptome sind für Ihren Ersatz wirklich wichtig, denn sie werden sie treffen, bevor sie das Problem vollständig erfassen.
• Der vorige Punkt ist noch wichtiger im Hinblick auf Altsysteme, wie Bibliotheken oder Plattformen, wo neue Versionen veröffentlicht, aber nicht in Ihrem Produkt verwendet werden. Probleme, auf die Sie in Ihrer Version (oder noch schlimmer, bei der Interaktion zwischen mehreren Altsystemen) stoßen, können in zukünftigen Versionen gelöst werden, und so wird die Existenz des Fehlers aus dem öffentlichen Bewusstsein verschwinden, bis es fast unmöglich ist, Informationen darüber zu finden.

Urlaub ist eine gute “Ausbildung”, um sich auf solche Dinge vorzubereiten. Sie hilft auch zu messen, wie gut man vorbereitet ist. Gehen Sie nach 2-3 Wochen wieder an die Arbeit und zählen Sie die Tage und den Aufwand, den Sie für die Bereinigung Ihres “Rückstands” aufgewendet haben - dies könnte eine gute Annäherung an ein “Hit-by-Bus-Szenario” sein.

Dies ist auch ein nützliches Werkzeug, wenn Sie sich verbessern wollen. Analysieren Sie die Rückstände, die Sie auflösen müssen, und fragen Sie sich, was getan werden könnte, damit dies von jemand anderem durchgeführt werden kann. Bei einem der vergangenen Jobs hat mir das geholfen, den “Urlaubsrückstand” in weniger als einem Jahr von etwa drei Wochen auf zwei Tage zu reduzieren.

• Oh mein Gott, ich scheine der einzige zu sein, der diese Informationen hat, ich muss sie dokumentieren, um sie dem ganzen Team zur Verfügung zu stellen.
  Verdammt, niemand außer mir kann diesen Fehler beheben, ich muss einen Ersatzmann finden und ausbilden…

Was man im Auge behalten sollte, ist, dass dies im Allgemeinen als eine Verantwortung Ihres Managements betrachtet wird, so dass alles, was Sie über das Erforderliche hinaus tun, nach Belieben geschieht. Fragen Sie sich, wie sehr Sie gegen Busfaktor ankämpfen wollen, und gehen Sie entsprechend vor.

Ich für meinen Teil möchte ersetzbar sein…

• … damit der andere, der meine Sachen aus repository überprüft, nicht auf mich zurückkommen muss, um zu versuchen, unmaintainable code
• … zu verstehen. …damit dieser andere Typ, der sich meine Unterlagen in issue tracker ansieht, meine Hilfe nicht braucht, um herauszufinden woran ich bei der Arbeit daran gedacht habe
• …damit dieser andere Typ, der meine Wiki-Seiten liest, mich nicht braucht, um dort dokumentierte Sachen zu erklären
• …damit dieser andere Typ, der meine Wiki-Seiten liest, mich nicht braucht, um dort dokumentierte Sachen zu erklären
• . …so dass ich mich daran erfreuen kann, wie [ Zeug, das ich gemacht habe ]&003 wächst und gedeiht und sein eigenes Leben lebt

…so dass ich mich darauf konzentrieren kann, neue Sachen zu machen, ohne von den Sorgen darüber abgelenkt zu werden, was zurückbleibt.

Fragen Sie Ihr Team. Fragen Sie Ihren Manager. Präsentieren Sie ihnen das Thema genau so, wie Sie es uns vorgelegt haben.

Geben Sie ihnen Optionen. Dokumentation für einen zukünftigen Entwickler. Dokumentation für sie. Technische Schulden abbezahlen. Alles, was Ihnen einfällt. Geben Sie ihnen Zeitschätzungen. Geben Sie ihnen die Wahl. Lassen Sie sie abwägen gegen Ihren normalen Arbeitsalltag.

Hey, vielleicht entscheiden sie sogar, dass es ein Risiko ist, das es wert ist, eingegangen zu werden. Aber eigentlich liegt es an ihnen, zu entscheiden.

Und wenn sie sich entschieden haben, das Risiko einzugehen, dann sollte Ihr unsterblicher Geist aufhören, sich deswegen schuldig zu fühlen.

Ich wollte die Hand ausstrecken und diese Fragen beantworten…

Die härteste Lektion, die ich je gelernt habe, war, diese Fragen nicht zu beantworten. Aber die richtige Frage zu stellen, um sie ahnungslos dazu zu bringen, die Antwort für sich selbst zu finden.

Eine gegebene Antwort ist etwas anderes als eine gelernte Lektion!

Erklärung

Es gibt grundsätzlich zwei verschiedene Szenarien, die den einzigen Punkt des Scheiterns schaffen, den das OP anspricht.

Geschäft

Dies kann eine bewusste Entscheidung sein oder das Ergebnis einer schlechten Planung, eines schlechten Prozesses oder des Wachstums des Unternehmens. Es kann auch das Ergebnis von Untätigkeit oder des Versäumnisses sein, die wachsende Wissenslücke zu erkennen und anzugehen.

Unabhängig vom Wie schafft das Unternehmen eine Situation, in der es eine starke Abhängigkeit von einer einzelnen Person oder einer kleinen Gruppe von Personen hat, die den Kern seiner Wissensbasis bilden. Viele Unternehmen reagieren darauf mit Mentoring-Programmen, Cross-Training und sowohl formeller als auch informeller Wissensvermittlung.

Meiner Erfahrung nach fördern diejenigen, die dabei am erfolgreichsten sind, auch einen Lehransatz. Damit meine ich, dass man selten eine ‘Antwort’ auf eine Frage erhält, sondern eher eine Diskussion und gezielte Fragen von dem/den Experten, die einen auf einen Lernweg führen und das Wissen über das Produkt, den Prozess, die Technologie im Spiel erweitern.

Dies bietet dem Experten in der Diskussion auch neue Einsichten und Perspektiven. Der Unterricht kann in der Tat in beide Richtungen gehen.

Mitarbeiter

Im Allgemeinen haben Sie zwei verschiedene Arten von Mitarbeitern, die in dieser Position landen. Was ich ‘The Go To’ und ‘The Protector’ nenne.

‘The Go To’ ist der Mitarbeiter, den die meisten Manager lieben. Er ist derjenige, dem Sie so gut wie jede Aufgabe oder jedes Projekt zuweisen können und sich nicht darum kümmern müssen. Dies sind die Menschen, die sich ihre Nische im Unternehmen herausarbeiten und die “go to”-Person werden und höchstwahrscheinlich diejenige, die die Antworten hat.

‘Der Beschützer’ ist der Mitarbeiter, der eine Entscheidung getroffen hat, um seinen Rasen zu schützen. Sie haben das Gefühl, dass sie durch den Schutz ihres Wissens ihre Position, ihre Bedeutung und ihre Zukunft im Unternehmen sichern.

Beide schaffen unbeabsichtigt einzelne Punkte des Scheiterns.

Also, kurz gesagt, wird die gesamte Dokumentation der Welt das zugrundeliegende Problem eines einzigen Versagenspunktes nicht lösen, da sie immer die schnelle Antwort liefert, und der ‘Schützer’ gibt keine oder keine Informationen weiter. Ja, sie ist wichtig und sollte Teil jedes BCP und jedes Katastrophenschutzplans sein. Aber Dokumentation ist nicht wirklich Wissensvermittlung in dem Sinne, dass jemand in der Lage sein sollte, einzuspringen und Ihre Arbeitsaufgaben zu erledigen, ohne sich vorher durch ein 200-seitiges Dokument wühlen zu müssen.

Beantworten Sie die Frage nicht; befähigen Sie sie, so dass sie sie selbst beantworten können.

Hier ist, was wir dort tun, wo ich arbeite:

a) Wir benutzen ein Wiki zur Dokumentation. Keine Microsoft Word-Dateien oder Textdateien. Ein Wiki, das durchsuchbar ist, in dem Änderungen vollständig verfolgt werden können usw. (Ich würde Confluence empfehlen, aber Confluence v4 ist so ein Hund, dass ich Ihnen empfehle, woanders nachzusehen)

• Alle sich wiederholenden oder delegierbaren Prozesse sollten dokumentiert werden.
• Checklisten von “hier ist, wie wir vorgehen _______” sollten geschrieben werden
• Checklisten sind sehr wichtig für die Bildung von Teams, da sie es ermöglichen, dass Prozesse von jedem durchgeführt werden können, der der Liste folgen kann…

b) Versionskontrolle, natürlich

c) Fall/Problemverfolgungssystem, natürlich

d) Kommentieren Sie Ihre Arbeit. Das ist das Nuancierteste, und es ist so schwer zu lehren, aber als Auftragnehmer/Unabhängiger können Sie das vielleicht begreifen: Kommentare sollten Ihren Denkprozess und das Warum Ihrer Arbeit erklären. Links zur Dokumentation, Stack Overflow, etc. sind angebracht. Absätze und Seiten mit Kommentaren sind angemessen. Erklären Sie die Dinge, die Sie versucht und NICHT getan haben, sind angemessen. Eines der größten Probleme von Code ist, dass der Gedanke und der Schweiß, die dazu führen, dass etwas auf die eine Art funktioniert (im Gegensatz zu einer anderen Art), verloren geht. Es gibt ein Buch, so etwas wie ‘schöner Code’ oder ähnliches, das in einem der großen offenen VCS -Systeme Subversion oder Git , glaube ich) einen Brocken auf den Kommentarblöcken in einer Unit hat. Es ist schön, weil es die Geschichte erzählt. Hier ist, was dieser Code macht. Hier ist, wie er funktioniert. So ist er strukturiert. (Ich gestehe, dass dieser Block, wie ich mich erinnere, vielleicht nicht sehr viel mit der “Warum”-Frage zu tun hat).

Eine logische Folge davon ist: Wie viele Leute gehen zurück und bearbeiten Code, nur um Kommentare hinzuzufügen? Wir alle sollten… eine Menge. Aber in der Praxis tut das fast niemand.

Netflix hat ein System, das sie ChaosMonkey nennen. Es ‘zerbricht’ oder emuliert das zufällige Zerbrechen bestimmter Systeme.

Man kann sich Mitarbeiter als Systeme vorstellen, und eine Möglichkeit, das Zerbrechen eines Mitarbeiters zu emulieren, besteht darin, diesem Mitarbeiter unangekündigte, ungeplante Freizeit zu geben. Der ChaosMonkey sagte Ihnen, Sie sollten sich einen Film ansehen, ohne es Ihren Kollegen zu sagen. Kurzfristig gesehen ist die Wirkung auf sie die gleiche, als ob Sie von einem Bus überfahren worden wären.

Dadurch wird die Robustheit ihrer Systeme getestet und ihnen ermöglicht, neue Fehler in ihren Systemen zu erkennen, die sonst vielleicht unbemerkt geblieben wären.

Dies könnte beim Wissenstransfer in einer Art und Weise helfen, die den Wissenstransfer erleichtert, da ein robusteres System wahrscheinlich weniger kaputt geht und weniger große Fehler hat, die Aufmerksamkeit erfordern, so dass sich die betreffenden Personen mehr darauf konzentrieren können, wie das System funktioniert und warum es tut, was es tut, anstatt nur lästigen Problemen nachzugehen, die wertvolle Zeit für den Wissensaustausch verschlingen.

Seit ich diese Antwort geschrieben habe, bin ich auf https://www.fdic.gov/news/news/financial/1995/fil9552.html aufmerksam geworden. Grundsätzlich empfiehlt die FDIC, dass die Banken den wichtigsten Bankmitarbeitern obligatorische, bezahlte Tätigkeiten von mindestens 2 aufeinander folgenden Wochen auferlegen. Das Wohlergehen der Mitarbeiter ist zweitrangig. Die primäre Überlegung ist, dass die Banken dadurch gezwungen werden, eine andere Person zu ernennen, die sich um die Verantwortung des ausscheidenden Mitarbeiters kümmert. Wenn der ausscheidende Mitarbeiter Geld veruntreut, fällt das System unter der Aufsicht des Vertreters auseinander. Dies bedeutet auch, dass die Bank nicht für einen Busangriff anfällig ist.

Ich würde mit

1 beginnen. Standardisierung

1. Regularer und obligatorischer Code/Projektüberprüfungen

2. Teamgeist

3. Offensichtlich Dokument. Es ist ein altes Lied. Ich werde es nicht mehr singen.

Die Planung dafür ist Teil einer Business Continuity Planning , während es hier um die Planung für größere Katastrophen geht, als nur für den Fall, dass man von einem Bus überfahren wird, aber der Prozess bringt die Teile an ihren Platz, um sich von kleinen Zwischenfällen wie dem Abwerben eines Schlüsselspielers bis hin zu größeren Problemen wie einer Katastrophe, die Gebäude und die Menschen, die sie besetzen, zu erholen.

Wiki-Wie hat einen so genannten Aufsatz über wie man einen BCP erstellt und obwohl ich nicht empfehlen würde, diese Methode tatsächlich für Ihr Unternehmen zu verwenden, bietet sie einen guten Einblick in die Prozesse und Denkweisen, die für die Erstellung eines BCP erforderlich sind. Im Allgemeinen werden BCPs in abgestuften Ansätzen durchgeführt, die die größten Risiken handhaben und sich zunächst auf wahrscheinlichere Szenarien vorbereiten und danach auf Bedenken hinsichtlich geringerer Risiken eingehen. Aber jedes Unternehmen baut seine BCPs im Allgemeinen nach seinen eigenen Bedürfnissen auf, so dass der genaue Prozess variiert.

Der Prozess umfasst im Allgemeinen:

• Risikobereiche identifizieren
• die beteiligten Prozesse dokumentieren
• angemessene Reaktionen auf verschiedene Szenarien festlegen
• Pläne für den Umgang mit den Szenarien erstellen

Unsere alltäglichen Regeln verbieten es, Wissen mit ins Grab zu nehmen:

• Wenn jemand ein Skript/eine Routine schreibt, dann muß jemand anders das als erster in der Produktion verwenden.
• Wenn jemand neue Systeme einsetzt, dann wird niemand diese benutzen oder unterstützen, bis er alle notwendigen Zugangsdaten selbst nachschlagen kann, allein, nachts, ohne jemand anderen zu fragen.
• Es gibt auch “Konfiguration als Code” und automatisiertes Testen für Software. Es erlaubt Ihrem Nachfolger, Ihre Arbeit zurückzuentwickeln.

In der Tat “Dinge, die noch nicht aufgelistet/getestet sind, existieren für uns nicht”. Nur Dinge, die aufgelistet sind, sind zuverlässig.

Wir nennen es “ Arkanes Wissen”. (nur im Kopf von jemandem gespeichert), und jeder weigert sich, darauf zu reagieren.

Offensichtlich funktioniert das nicht zwischen Techie- und Nicht-Techie-Themen. Aber wir erwarten auch nicht, dass Techies in der Lage sind, finanzielle Berechnungen aus der Buchhaltung zu übernehmen. Also könnte sogar unsere Buchhaltungsabteilung “Wissen mit ins Grab nehmen”, wenn nur 1 Buchhalter jemals diese Berechnungen durchführen würde.

Weil es eine Grenze gibt. Wenn das Team zu klein ist, dann wird es immer jemanden geben, der von einem Bus überfahren wird.

Die folgenden Punkte sollten in Ihrer Arbeitsbeschreibung enthalten sein, die Ihnen ausgehändigt und von den Eigentümern des Unternehmens festgelegt wird. Es liegt in ihrer Verantwortung, dies zu veranlassen. Möglicherweise sind Sie jedoch der Einzige, der über das Wissen verfügt, um sie darüber zu informieren, dass dies erforderlich ist.

• Arbeiten Sie innerhalb gut etablierter Standards, die für Ihren Bereich oder Ihre Organisation festgelegt wurden.
• Dokumentieren Sie, was Sie tun.
• Dokumentieren Sie sehr detailliert, wenn Sie von gut etablierten Standards abweichen und warum Sie dies getan haben.
• Dokumentieren Sie, wie Sie für Ihre Organisation dokumentieren.
• Wenn Sie an der Spitze einer Systemadministrationskette stehen und die Root-/Super-Benutzerkonten besitzen; erstellen Sie ein Konto, das die höchstmögliche Sicherheitsfreigabe hat. Generieren Sie dafür ein langes Zufallspasswort. Drucken Sie es auf Papier aus. Unterschreiben Sie es. Versiegeln Sie es in einem Umschlag und überreichen Sie es dem Vorstand, nicht dem CEO. Denn ein CEO kann sich unter schlechten Bedingungen von der Firma trennen und trotzdem dieses Passwort haben. Sagen Sie ihm, er soll es sicher aufbewahren, außerhalb des Unternehmens aufbewahren und benutzen (es kann Ihnen im Falle Ihrer Abwesenheit oder aus anderen Gründen, die möglicherweise zutreffen, den Superuser-Status im Netzwerk verleihen).