Als Mitglied kleiner Teams hatte ich große Verantwortung. Ob ich den Fortschritt vorantreibe, indem ich Meetings organisiere oder einen großen Prozentsatz spezifischer technischer Informationen pflege/erstelle/verstehe, ich hatte oft solche Verantwortungen. Manchmal war ich die einzige Person, die an technischen Aspekten des Projekts arbeitete.
Dies geschah bei einer Vielzahl von Arten von Arbeiten. Manchmal war es das Programmieren von Projekten als alleiniger Programmierer mit mehreren nicht-technischen Personen, manchmal das Analysieren oder Zusammenstellen von technischen Informationen und manchmal das Bereitstellen von technischen Daten und Präsentationen. Teilweise war ich Projektleiter und sozusagen der Vermittler zwischen allen Beteiligten.
Ich war wirklich gut in meinen Verantwortlichkeiten und bekam sie weiterhin auf mich übertragen. Ich habe ein Nischen-Fähigkeiten-Set entwickelt und genoss die Arbeit. Das Leben war großartig.
Dann... wurde ich von einem Bus angefahren . So eine Tragödie! Es war zu früh, um von dieser Welt genommen zu werden...
Als ich später durch die Flure meines alten Arbeitsplatzes schwebte, stellte ich fest, dass ich mein Team nicht gut auf meine vorzeitige Abreise vorbereitet hatte.
Niemand sonst im Team war mit den Tools, die ich verwendete, so vertraut wie ich. Niemand sonst verstand die technischen Informationen auch nur oberflächlich. Ich wollte die Hand ausstrecken und diese Fragen beantworten – so einfache Fragen! Aber leider. Mein körperloser Geist war dazu verdammt, stimmlos zu schweben.
Ich fragte mich... was hätte ich tun können? Was habe ich verpasst? Wie hätte ich die Dinge für diese armen Seelen ändern können?
Im Ernst, das oben Gesagte ist ein großes Problem bei der Arbeit im Ingenieurwesen. Wenn Sie in funktionsübergreifenden Teams arbeiten, ist es schwierig, den Rest über die Details Ihrer Arbeit auf dem Laufenden zu halten. Es ist leicht, für das Team eine „Blackbox“ der Magie zu sein. Schlimmer noch, Sie entwickeln/besitzen oft spezifische Fähigkeiten, die nicht leicht zu dokumentieren sind (und Stunden um Stunden an Schulungen oder Lernsystemen erfordern können).
Meine Frage ist:
Hinweis: Ich sollte hinzufügen, dass dies nichts über meine Zukunftspläne impliziert ... sondern eine Möglichkeit, eine ansonsten normale Frage möglicherweise unterhaltsamer zu gestalten. Sie könnten von einem Bus angefahren werden, einen plötzlichen Familiennotfall haben oder realistischer einen neuen Job/eine neue Beförderung annehmen, zu einem anderen und dringenderen Projekt berufen werden, eine Woche Urlaub nehmen und nicht arbeiten (verrücktes Konzept) usw.
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:
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.
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 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)
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
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.
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
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.
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:
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:
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:
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.
unoder
Paul D. Waite
Mücke
BryanH
svidgen
Elijah Lynn
Pac0
Angehender Mathematiker