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

Wenn Sie als Auftragnehmer arbeiten, würde ich sagen, dass dies zu 100 % auf Ihrem Arbeitgeber liegt. Sagen Sie ihnen, dass das Erreichen der Ziele, die sie sich gesetzt haben, bedeutet, dass andere Dinge, von denen Sie denken, dass sie als Ziele betrachtet werden sollten, nicht getan werden; Fragen Sie sie, ob sie Ihre Ziele anpassen möchten. Sie können Ihnen sagen, dass Sie so weitermachen sollen, wie es ist, da Ihre Zeit teuer ist und sie das beste kurzfristige Preis-Leistungs-Verhältnis wollen.

Wenn Sie als Angestellter arbeiten, haben Sie möglicherweise mehr Spielraum, um die Nachfolge zu planen (oder möglicherweise wird erwartet, dass Sie dies bereits tun). Bringen Sie es dennoch mit Ihrem Teamleiter oder Manager zur Sprache, da er über das Problem Bescheid wissen muss und wie es Ihnen geht und wie Sie denken, dass Sie Ihre Zeit damit verbringen sollten.

Einige Dinge dazu würden bei der Planung der Nachfolge helfen:

• Alltägliche Prozesse sollten bis zu einem gewissen Grad dokumentiert werden, aber es ist wahrscheinlich, dass andere Personen in Ihrem Team denselben Prozessen folgen und sie einem Neuling beibringen könnten. Wenn Sie nicht alle ähnliche Prozesse verwenden, ist dies ein aktuelles Problem, das gelöst werden sollte; Treffen Sie sich, diskutieren Sie, welcher Weg der beste ist, kommen Sie zu einem Standard (einvernehmlich oder von oben erzwungen) und verwenden Sie den Standard. Herzlichen Glückwunsch, dieser Standard kann in Ihre Dokumentation für den Neuling aufgenommen werden.
• Wichtige Dinge, die per E-Mail, Meetings oder gelegentlichen Gesprächen kommuniziert werden, müssen in eine gemeinsame Ressource umgewandelt werden, 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 gesendet wird, dieses Team die Sache für immer wissen wird; Dabei wird nicht berücksichtigt, dass sich die Zusammensetzung des Teams ändert und dass bei Schulungen (falls sie überhaupt stattfinden) niemals das gesamte Wissen übertragen wird, sondern nur eine Teilmenge des häufig verwendeten Wissens.
• (Möglicherweise softwarespezifisch) Dokumentieren Sie eindeutig kontraintuitive Prozesse oder Entwurfsentscheidungen, es ist wichtig, zu identifizieren, dass der Prozess als kontraintuitiv erkannt wurde und unabhängig davon, warum dies so ist. Zum Beispiel, wenn Ihr Kunde Sie gebeten hat, etwas zu tun, das „falsch“ erscheint („Ich bin kein Domänenexperte, aber möchten Sie das wirklich tun?“), und Sie ihm erklärt haben, warum Sie es für falsch hielten bestätigt, dass es das war, was sie wollten (noch besser, wenn sie erklärten, warum), dann sollten die Gründe, warum Sie es für falsch hielten, und die Erklärung, warum es richtig 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.
• Dokumentieren Sie bei jedem Problem, auf das Sie stoßen und dessen Lösung viel Zeit/Recherche erfordert, das Problem, die Symptome, den verkürzten Weg zur Lösung (d. h.: Wenn Sie wissen, was Sie jetzt wissen, was der schnellste Weg von der Identifizierung der Symptome zu einer Lösung war ) und die Lösung. Symptome sind für Ihren Ersatz wirklich wichtig, weil sie ihn treffen, bevor er das Problem vollständig erfasst.
• Der vorherige Punkt ist noch wichtiger in Bezug auf Legacy-Systeme wie Bibliotheken oder Plattformen, wo neue Versionen veröffentlicht, aber nicht in Ihrem Produkt verwendet werden. Probleme, auf die Sie in Ihrer Version stoßen (oder noch schlimmer, bei Interaktionen zwischen mehreren Legacy-Systemen), können in zukünftigen Versionen behoben werden, sodass die bloße Existenz des Fehlers aus der Öffentlichkeit verschwindet, bis es fast unmöglich ist, Informationen darüber zu finden.

Dokumentation.

Ziemlich häufige Code-Commits.

Dokumentation.

Dokumentieren Sie Ihre Ideen, Ihre Designs und Ihren Code. Alle Fallstricke, die Ihnen bekannt sind.

Dokumentation.

Dokumentieren Sie Ihre Fehlerbehebungen und erklären Sie, was das Problem war und wie Sie es behoben haben und warum.

Und habe ich die Dokumentation erwähnt?

Wenn Sie in einer Umgebung arbeiten, in der die Richtlinien lasch sind (so dass Junior-Entwickler sich einfach nicht die Mühe machen können, Dokumentationsänderungen einzureichen – relevante Dokumentationsaktualisierungen sollten neben jeder Zweigzusammenführung vorgeschrieben werden), fehlt die Peer-Review (so dass Junior-/Senior-Entwickler während der Flut erwischt werden aus verständlicher Faulheit) 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. Andernfalls ist Ihre ganze Mühe beim Schreiben von Dokumentationen möglicherweise umsonst.

Allerdings würde ich nicht immer so weit gehen, es als persönliche Verantwortung zu bezeichnen: Wenn die Teams nicht richtig geführt und/oder organisiert werden, dann liegt das letztendlich nicht in Ihrer Verantwortung; bei einem Jobwechsel würde ich einfach meine fertige Dokumentation abgeben und denken „naja, wenn du das nicht richtig nutzen und pflegen kannst, dann bist du schuld… jetzt viel Glück“.

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

NICHTS anders machen. Arbeiten Sie so, als würden Sie morgen NICHT „von einem Bus angefahren“ werden.

Das Problem „Von einem Bus angefahren“ ist ein organisatorisches Problem und nicht etwas, das in Ihren eigenen Arbeitszielen explizit angesprochen werden muss.

Ihre Kollegen und das Management sollten darüber nachdenken, aber ich denke, es ist zu viel verlangt, dass einzelne Mitarbeiter so arbeiten, als ob sie morgen buchstäblich weg wären. Wenn das Management die potenziellen Probleme hier nicht wahrnimmt, bedeutet dies, dass es völlig außer Kontakt ist oder Sie vielleicht nicht so unverzichtbar sind, wie Sie dachten.

Wenn Sie großzügig sind, sollten Sie bestenfalls Schlüsselpersonen und Leads daran erinnern, im Notfall eine Verstärkung zu haben. Aber in einer Zeit, in der Unternehmen Karrieren nach Lust und Laune für kurzfristigen Profit "unter den Bus" werfen, wie viel sollte es Sie wirklich interessieren?

Sorgfältige Ingenieurspraktiken lösen viele der Probleme des „von einem Bus angefahren“-Dilemmas. Darüber hinaus bis zu dem Punkt zu gehen, an dem man bereit ist, sofort und dauerhaft zu verschwinden, wird für den einzelnen Mitwirkenden eine Menge Overhead bedeuten. Es hört sich so an, als könnte die vom OP beschriebene Umgebung von einfach besseren Praktiken und Personal profitieren, es besteht keine Notwendigkeit für ihn, so zu arbeiten, als ob er jeden Moment verdampfen könnte.

Urlaub ist ein gutes "Training", um sich auf solche Dinge vorzubereiten. Es hilft auch zu messen, wie gut Sie vorbereitet sind. Machen Sie sich nach 2-3 Wochen wieder an die Arbeit und zählen Sie die Tage und den Aufwand, die Sie für die Bereinigung Ihres "Rückstands" aufgewendet haben - dies könnte eine anständige Annäherung an das "Von-Bus-Szenario" darstellen.

Dies ist auch ein nützliches Werkzeug, wenn Sie sich verbessern möchten. Analysieren Sie zu lösende Backlog-Items und fragen Sie sich, was getan werden könnte, damit dies von jemand anderem erledigt werden könnte. Bei einem der vergangenen Jobs hat mir das geholfen, den „Urlaubsstau“ 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 gesamten Team zur Verfügung zu stellen.
  Verdammt, niemand außer mir kann diesen Fehler beheben, ich muss einen Ersatzmann finden und trainieren ...}

Beachten Sie , dass dies im Allgemeinen als Verantwortung Ihres Managements angesehen wird, sodass alles, was Sie über das Erforderliche hinaus tun, nach Belieben erfolgt. Fragen Sie sich, wie sehr Sie den Bus-Faktor bekämpfen möchten , und gehen Sie entsprechend vor.

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

• ... damit andere Leute, die meine Sachen aus dem Repository überprüfen , sich nicht bei mir melden müssen, um zu versuchen, nicht wartbaren Code zu verstehen
• ...damit andere Leute, die meine Aufzeichnungen im Issue-Tracker ansehen, nicht meine Hilfe brauchen, um herauszufinden , woran ich während der Arbeit gedacht habe
• ... damit andere Leute, die meine Wiki-Seiten lesen, mich nicht brauchen, um die dort dokumentierten Dinge zu erklären
• ...damit ich es genießen kann, zuzusehen, wie Dinge, die ich gemacht habe, wachsen und gedeihen und ihr eigenes Leben führen

...damit ich mich auf neue Dinge konzentrieren kann, ohne mich von Sorgen über das, was zurückbleibt, ablenken zu lassen.

Fragen Sie Ihr Team. Fragen Sie Ihren Vorgesetzten. Präsentieren Sie ihnen das Thema genau so, wie Sie es uns gegenüber haben.

Geben Sie ihnen Optionen. Dokumentation für einen zukünftigen Entwickler. Dokumentation für sie. Technische Schulden abbezahlen. Alles, was Sie sich vorstellen können. Geben Sie ihnen Zeitschätzungen. Geben Sie ihnen die Wahl. Lassen Sie es gegen Ihren normalen Arbeitsalltag abwägen.

Hey, sie könnten sogar entscheiden, dass es ein Risiko ist, das es wert ist, eingegangen zu werden. Aber wirklich, es liegt an ihnen zu entscheiden.

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

Ich wollte mich melden und diese Fragen beantworten...

Die schwerste 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 anders als eine gelernte Lektion!

Erläuterung

Grundsätzlich gibt es zwei verschiedene Szenarien, die den Single Point of Failure schaffen, den das OP anspricht.

Geschäft

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

Unabhängig vom Wie schafft das Unternehmen eine Situation, in der es eine extreme Abhängigkeit von einer einzelnen Person oder einer kleinen Gruppe von Personen hat, die den Kern ihrer Wissensdatenbank bilden. Viele Unternehmen gehen dies an, indem sie Mentoring-Programme, Cross-Training und sowohl formellen als auch informellen Wissensaustausch nutzen.

Aus meiner Erfahrung fördern diejenigen, die darin am erfolgreichsten sind, auch einen pädagogischen Ansatz. Damit meine ich, dass Sie selten eine "Antwort" auf eine Frage erhalten, sondern eher eine Diskussion und gezielte Fragen des/der Experten, die Sie auf einen Lernpfad führen und Ihr Wissen über das Produkt, den Prozess und die Technologie erweitern abspielen.

Dies bietet auch dem Experten in dieser Diskussion neue Einblicke und Perspektiven. Der Unterricht kann tatsächlich in beide Richtungen gehen.

Angestellter

Im Allgemeinen gibt es 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 nahezu jede Aufgabe oder jedes Projekt zuweisen können, ohne sich darum kümmern zu müssen. Dies sind die Leute, die sich ihre Nische im Unternehmen erarbeiten und zu den Ansprechpartnern werden und höchstwahrscheinlich zu denjenigen, die die Antworten haben.

„ Der Beschützer “ ist der Mitarbeiter, der die Entscheidung getroffen hat, sein Revier zu schützen. Sie haben das Gefühl, dass sie durch den Schutz ihres Wissens ihre Position, Bedeutung und Zukunft im Unternehmen sichern.

Beide schaffen unbeabsichtigt Single Points of Failure. " The Go To ", indem Sie immer die schnelle Antwort geben, und " The Protector ", indem Sie keine oder alle Informationen weitergeben.

Kurz gesagt, die gesamte Dokumentation der Welt wird das zugrunde liegende Problem eines Single Point of Failure nicht lösen. Ja, es ist wichtig und sollte Teil jedes BCP- und Katastrophenvorsorgeplans sein. Aber Dokumentation ist nicht wirklich Wissensaustausch 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; ermächtigen Sie sie, damit sie es für sich selbst beantworten können.

Das machen wir dort, wo ich arbeite:

a) Wir verwenden ein Wiki zur Dokumentation. Keine Microsoft Word-Dateien oder Textdateien. Ein Wiki, das durchsuchbar ist, Änderungen vollständig verfolgt usw. (Ich würde Confluence empfehlen , aber Confluence v4 ist so ein Hund, dass ich vorschlage, dass Sie sich woanders umsehen)

• Alle sich wiederholenden oder delegierbaren Prozesse sollten dokumentiert werden.
• Checklisten mit „So machen wir _____“ sollten geschrieben werden
• Checklisten sind für den Aufbau von Teams sehr wichtig, da sie es ermöglichen, dass Prozesse von jedem durchgeführt werden können, der der Liste folgen kann ...

b) Versionskontrolle, offensichtlich

c) Fall-/Problemverfolgungssystem, offensichtlich

d) Ihre Arbeit kommentieren. Dies ist die nuancierteste Sache, und es ist so schwer zu lehren, aber als Auftragnehmer/Unabhängiger können Sie dies vielleicht verstehen: Kommentare sollten Ihren Denkprozess und das Warum Ihrer Tätigkeit erläutern. Links zu Dokumentation, Stack Overflow etc. sind angebracht. Absätze und Kommentarseiten sind angemessen. Es ist angemessen, die Dinge zu erklären, die Sie versucht und NICHT getan haben. Eines der größten Probleme von Code ist, dass der Gedanke und der Schweiß, der dafür aufgewendet wird, etwas auf eine bestimmte Art und Weise (im Gegensatz zu einer anderen Art) zum Funktionieren zu bringen, verloren geht. Es gibt ein Buch, so etwas wie 'schöner Code' oder ähnliches, das einen Teil der Kommentarblöcke in einer Einheit in einem der großen offenen VCS -Systeme ( Subversion oder Git, Ich finde). Es ist schön, weil es die Geschichte erzählt. Hier ist, was dieser Code tut. So funktioniert es. So ist es aufgebaut. (Ich gebe zu, dass dieser Block, soweit ich mich erinnere, möglicherweise nicht groß in die „Warum“-Frage einfließt.)

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

Netflix hat ein System, das sie ChaosMonkey nennen . Es "bricht" oder emuliert im Wesentlichen das zufällige Brechen bestimmter Systeme.

Mitarbeiter können als Systeme betrachtet werden, und eine Möglichkeit, die Unterbrechung eines Mitarbeiters nachzuahmen, besteht darin, diesem Mitarbeiter unangekündigte, ungeplante Freizeit zu gewähren. Der ChaosMonkey hat dir gesagt, du sollst dir einen Film ansehen, ohne es deinen Kollegen zu sagen. Kurzfristig ist die Wirkung auf sie die gleiche, als ob Sie von einem Bus angefahren worden wären.

Dies testet die Robustheit ihrer Systeme und ermöglicht es ihnen, neue Fehler in ihren Systemen zu erkennen, die sonst möglicherweise unbemerkt geblieben wären.

Dies könnte den Wissenstransfer auf einfache Weise unterstützen, da ein robusteres System wahrscheinlich weniger kaputt geht und weniger große Fehler aufweist, die Aufmerksamkeit erfordern, sodass sich die betreffenden Personen besser darauf konzentrieren können, wie das System funktioniert und warum es funktioniert tut, was es tut, anstatt nur lästige Probleme zu jagen, 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 Banken für wichtige Bankangestellte obligatorische, bezahlte Ferien von mindestens zwei aufeinanderfolgenden Wochen auferlegen. Das Wohlbefinden der Mitarbeiter ist zweitrangig. Die Hauptüberlegung ist, dass dies die Banken zwingen wird, jemand anderen zu ernennen, der sich um die Aufgaben des frei werdenden Mitarbeiters kümmert. Wenn der scheidende Mitarbeiter unterschlägt, wird das System unter der Aufsicht des Ersatzes auseinanderfallen. Dies bedeutet auch, dass die Bank nicht anfällig für einen Busangriff ist.

Ich würde mit beginnen

1. Standardisierung

   Meine letzte Position vor meiner jetzigen war eine Wild-West-Methode. Jeder benutzte die Werkzeuge, die er wollte, womit er vertraut war. Wichtig war, dass die Projekte in einwandfreiem Zustand und pünktlich geliefert wurden. Es führte zu einer schrecklichen Codewartung, bei der ein Projekt mit GWT als Präsentationsschicht und JUnit ausschließlich für alle Arten von Komponententests entwickelt wurde und ein anderer Entwickler bei rohen JSPs blieb, während ein anderer JSF in die Mischung einbrachte. Jeder war an seine Projekte gefesselt und Urlaub war für viele undenkbar und läutete den Todesstoß für Code-Reviews und -Optimierungen.

   Ich schlug vor, dass wir eine Reihe von branchenüblichen Technologien und Tools standardisieren, die sicherstellen, dass wir alle in der gleichen Richtung des Bettes schlafen (SoapUI für WS-Tests, JSF für die Webschicht und mit mäßigem Erfolg, Spring für die Backend-Verarbeitung und a paar andere Sachen). Und wir lebten alle glücklich bis ans Ende. Entmutigen Sie jede Individualität, wenn es um Tools des Handels geht, die Dateien mit einer proprietären Erweiterung erstellen (oder zumindest versuchen, sie abzumildern); ich

   Wenn jemand ein Lieblingswerkzeug hat, dem er sein Leben anvertraut, lassen Sie ihn es zur Bewertung und möglicherweise teamweiten Übernahme vor Gericht bringen. Sie hätten es sich zur Aufgabe machen sollen, mit Ihren Werkzeugen Maßstäbe zu setzen. Die Vorteile liegen hier auf der Hand, jeder verwendete das gleiche Zeug mit akzeptablem Komfort, so dass mit einem anständigen Designdokument jeder das Bit eines anderen aufgreifen und weitermachen kann.

2. Regelmäßige und obligatorische Code-/Projekt-Reviews

   Das ist ein weiteres Feature von meinem letzten Gig. Wir trafen uns alle einmal pro Woche mit unserem Manager in einer Gruppensitzung und besprachen den Stand der Projekte des anderen und äußerten Bedenken und Herausforderungen. Wir alle hatten auf sehr hohem Niveau eine Vorstellung davon, woran der nächste Typ arbeitete, und manchmal halfen wir mit Ratschlägen und ein paar Codezeilen. Es gab keine totale Isolation

3. Teamgeist

   Ich weiß, es scheint irgendwie banal und möglicherweise ein Kinderspiel zu sein, aber ein gesunder Teamgeist (und möglicherweise ein wenig Wettbewerb) fördert den Informationsaustausch. Der Nachteil der Büroumgebung (insbesondere Teammitglieder in weit voneinander entfernten Büros) besteht darin, dass die Teammitglieder oft so weit vom Arbeitsleben der anderen entfernt sind, dass es zu leicht zu einem Kommunikationsausfall kommen kann. Es gibt eine bessere Kommunikation und einen besseren Informationsaustausch, wenn Teamkollegen nahe beieinander sitzen, vorzugsweise in einer offenen Büroumgebung mit wenig Wänden oder Trennwänden. Diskussionen und Meinungsverschiedenheiten werden freier stattfinden und fließen, mit dem Ziel, den Informationsaustausch zu fördern.

4. Offensichtlich Dokument . Es ist ein altes Lied. Ich werde es nicht noch einmal singen

Die Planung dafür ist Teil einer Geschäftskontinuitätsplanung , während es hier um die Planung größerer Katastrophen geht, als nur dass Sie von einem Bus angefahren werden, aber der Prozess setzt die Teile zusammen, um sich von kleinen Vorfällen wie einem abgeworbenen Schlüsselspieler bis hin zu größeren Problemen zu erholen wie eine Katastrophe, die Gebäude und die Menschen, die sie besetzen, zerstört.

Wiki-How hat einen mittelmäßigen Bericht darüber, wie man einen BCP erstellt, und obwohl ich nicht empfehlen würde, diese Methode tatsächlich für Ihr Unternehmen zu verwenden, bietet es 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, um die größten Risiken zu handhaben, sich zuerst auf wahrscheinlichere Szenarien vorzubereiten und danach Bedenken mit geringerem Risiko zu berücksichtigen. Aber jedes Unternehmen baut sein BCP im Allgemeinen nach seinen eigenen Bedürfnissen, sodass der genaue Prozess unterschiedlich ist.

Der Prozess umfasst im Allgemeinen:

• Risikobereiche identifizieren
• dokumentieren die beteiligten Prozesse
• angemessene Reaktionen auf verschiedene Szenarien bestimmen
• Enact plant, sich mit den Scenerios zu befassen

Was würde ich tun, wenn ich zwei Wochen im Voraus kündige?

Ich machte einen schnellen Überblick und begann mit der Videoaufzeichnung meines Bildschirms und meiner Stimme. Es umfasste:

1. Wo bewahre ich alles auf.
2. Beispiele für aktuelle Anfragen und wo ich mich dabei befinde.
3. Demonstrationen, wie einige der einzigartigeren oder komplexeren Aufgaben ausgeführt werden, nur für den Fall, dass eine weniger technisch versierte Person die Dinge kurzfristig verwalten muss.
4. So finden Sie Dinge in der Datenbank, die ich am ersten Tag erstellt habe, um all die kleinen Dinge zu verwalten (Wenn Sie zum ersten Mal einen Job beginnen, finden Sie wirklich heraus, was Sie nicht wissen.).

Mein Ziel ist es wie immer, einen Job besser zu verlassen, als ich ihn vorgefunden habe. Ich versuche, meine Standards nicht vom Management bestimmen zu lassen. Ihre Aufgabe ist es, sich um Endergebnisse zu kümmern, meine Aufgabe ist es, zu wissen, wie ich meine Arbeit besser machen kann als sie. Ich bin nicht nur ein zusätzliches Paar Hände.

Unsere Alltagsregeln gegen Menschen, die Wissen mit ins Grab nehmen:

• Wenn jemand ein Skript/eine Routine schreibt, muss jemand anderes der erste sein, der diese in der Produktion verwendet.
• Wenn jemand neue Systeme einsetzt, wird niemand diese verwenden oder unterstützen , bis er alle erforderlichen Zugangsdaten alleine nachts nachschlagen kann, ohne jemanden zu fragen.
• Es gibt auch "Configuration as Code" und automatisiertes Testen für Software. Es ermöglicht Ihrem Nachfolger, Ihre Arbeit zurückzuentwickeln.

Faktisch gilt: „Dinge, die noch nicht gelistet/geprüft sind, gibt es bei uns nicht“. Nur Dinge, die aufgelistet sind, sind zuverlässig.

Wir nennen es „ arkanes Wissen “ (das nur im Kopf von jemandem gespeichert ist), und jeder weigert sich, danach zu handeln.

Offensichtlich funktioniert das nicht zwischen Techie- und Nicht-Techie-Themen. Aber wir erwarten auch nicht, dass Techies Finanzkalkulationen von der Buchhaltung übernehmen können. Sogar unsere Buchhaltung könnte "Wissen mit ins Grab nehmen", wenn nur 1 Buchhalter jemals diese Berechnungen anstellen würde.

Denn es gibt eine Grenze. Wenn das Team zu klein ist, 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 wurde. Es ist ihre Verantwortung, dies an Ort und Stelle zu haben. Sie sind jedoch möglicherweise die einzige Person, die ü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 etablierten Standards abweichen und warum Sie dies getan haben
• Dokumentieren Sie, wie Sie für Ihre Organisation dokumentieren.
• Wenn Sie an der Spitze einer Systemverwaltungskette stehen und die Root-/Super-Benutzerkonten besitzen; Erstellen Sie ein Konto mit der höchstmöglichen Sicherheitsfreigabe. Generieren Sie dafür ein langes zufälliges Passwort. Drucken Sie es auf Papier aus. Unterschreib es. Verschließen Sie es in einem Umschlag und übergeben Sie es dem Vorstand, nicht dem CEO . Denn ein CEO kann sich unter schlechten Bedingungen vom Unternehmen trennen und immer noch dieses Passwort haben. Sagen Sie ihnen, dass sie es sicher außerhalb des Standorts aufbewahren und verwenden sollen (es kann Ihnen den Superuser-Status im Netzwerk geben, falls Sie abwesend sind oder aus anderen Gründen, die zutreffen können).