Hoe kan ik me voorbereiden op een botsing met een bus?

Documentatie.

Redelijk frequente codecommitments.

Documentatie.

Documenteer uw ideeën, uw ontwerpen en uw code. Elke gotchas waar je je bewust van bent.

Documentation.

Document your bug fixes uitleggen wat het probleem was en hoe je het hebt opgelost, en waarom.

En heb ik documentatie genoemd?

Als u werkt in een omgeving waar het beleid laks is (zodat junior devs eenvoudigweg niet de moeite kunnen nemen om documentatiewijzigingen in te dienen - relevante documentatie-updates moeten mandated zijn naast elke branch merge), peer review ontbreekt (dus junior/senior devs worden betrapt tijdens vlagen van begrijpelijke luiheid), en/of documentatie wordt apart van code opgeslagen (zodat het gemakkelijk verloren kan gaan), dan is het ook belangrijk om te overwegen of de omgeving kan worden veranderd zodat deze problemen niet zo worden gemaakt. Anders kan al je moeite om documentatie te schrijven voor niets zijn.

Dat gezegd hebbende, zou ik niet altijd zo ver gaan dat ik het een persoonlijke verantwoordelijkheid zou noemen: uiteindelijk, als de teams verkeerd worden beheerd en/of georganiseerd, dan is dat niet jouw verantwoordelijkheid; in het geval dat je overgaat naar een nieuwe baan, zou ik gewoon mijn voltooide documentatie overhandigen en denken “nou ja, als je dit niet goed kunt gebruiken en onderhouden, dan is dat jouw fout… nu veel geluk”.

Die gedachtegang houdt niet echt stand in de “hit by a bus” zaak, waar je misschien wel bezig bent met het initiëren van dergelijk beleid, maar het nog niet helemaal voor elkaar hebt gekregen. Voor dit scenario zou ik simpelweg willen voorstellen dat u het management (en uw senior medewerkers) aanmoedigt om dit soort zaken serieus te nemen zo snel mogelijk.

Doe het anders. Werk alsof je morgen NIET door een bus wordt aangereden.

Het “hit-by-a-bus” probleem is een organisatorisch probleem en niet iets dat expliciet aan de orde moet komen in je eigen werkobjectieven.

Je collega’s en het management zouden erover moeten nadenken, maar ik denk dat het te veel gevraagd is van individuele medewerkers om te werken alsof ze morgen misschien letterlijk weg zijn. Als het management zich niet bewust is van de mogelijke problemen hier, betekent dit dat ze totaal buiten spel staan of misschien ben je niet zo onmisbaar als je dacht.

In het beste geval, als je vrijgevig bent, wil je misschien de belangrijkste mensen en leidinggevenden eraan herinneren dat je back-up nodig hebt in geval van nood. Maar in een tijdperk waar bedrijven carrières “onder de bus” gooien in een opwelling omwille van de korte termijn winst, hoeveel moet je er dan echt om geven?

Diligent engineering practices lossen veel van de problemen van het “hit by a bus” dilemma op. Als je daarbovenop komt en klaar bent voor onmiddellijke en permanente verdwijning, zal er veel overhead ontstaan voor de individuele bijdrager. Het klinkt alsof de omgeving die door het OP wordt beschreven, kan profiteren van simpelweg betere praktijken en een betere personeelsbezetting; hij hoeft niet te werken alsof hij elk moment kan verdampen.

Als je als aannemer werkt, zou ik zeggen dat dit 100% van je werkgever is. Vertel ze dat het bereiken van de doelen die ze voor je hebben gesteld betekent dat andere dingen waarvan je denkt dat ze moeten worden beschouwd als doelen niet worden gedaan; vraag ze of ze je doelen willen bijstellen. Ze kunnen je misschien vertellen dat je door moet gaan met as-is, omdat je tijd duur is en ze de beste korte termijn waarde voor je geld willen.

Als je als werknemer werkt, heb je misschien meer ruimte om te plannen voor de opvolging (of misschien is er een verwachting dat je het al doet). Toch, breng het ter sprake met je teamleider of manager, want zij moeten weten wat het probleem is en hoe je bent, en denken dat je je tijd moet besteden.

Enkele dingen die zouden helpen bij het plannen van opvolging:

• Dagelijkse processen moeten tot op zekere hoogte worden gedocumenteerd, maar het is waarschijnlijk dat andere mensen in je team dezelfde processen volgen en ze aan een nieuwkomer zouden kunnen onderwijzen. Als je niet allemaal dezelfde processen gebruikt, is dat een actueel probleem dat moet worden opgelost; samenkomen, debatteren welke manier het beste is, tot een bepaalde standaard komen (consensueel of geforceerd van bovenaf), en de standaard gebruiken, gefeliciteerd dat standaard kan gaan in je documentatie voor de nieuwkomer.
• Belangrijke dingen die worden gecommuniceerd via e-mail, vergaderingen, of toevallige gesprekken moeten worden omgezet in een gedeelde bron, alles van een map met documenten op een gedeelde schijf naar een wiki. Er is deze vreemde overtuiging (in ieder geval waar ik heb gewerkt) dat als iets via e-mail naar alle leden van een team wordt gestuurd, dat team het voor altijd zal weten; dit houdt geen rekening met het feit dat de samenstelling van het team verandert en dat elke training (als het zelfs maar gebeurt) nooit alle kennis zal overdragen, alleen een subset van veelgebruikte kennis.
• (Mogelijk software-specifiek) Documenteer duidelijk contra-intuïtieve processen of ontwerpbeslissingen, het is belangrijk om vast te stellen dat het proces wordt herkend als contra-intuïtief en waarom het zo is, ongeacht. Als uw klant u bijvoorbeeld vraagt om iets te doen wat “fout” lijkt (“Ik ben geen domeinexpert, maar weet u zeker dat u dat wilt doen?”), en u legt uit waarom u denkt dat het fout is en ze bevestigen dat het is wat ze willen (nog beter als ze uitleggen waarom), dan moeten de redenen waarom u denkt dat het fout is en de uitleg over waarom het correct is, worden gedocumenteerd. Dat de software naar specificaties functioneert zal niet genoeg zijn voor een vervanging, ze zullen dezelfde vraag hebben als jij.
• Voor elk probleem dat je tegenkomt en dat veel tijd/onderzoek vergt om op te lossen, het probleem te documenteren, de symptomen, het verkorte pad naar de oplossing (d.w.z.: weten wat je nu weet, wat het snelste pad was van het identificeren van de symptomen naar een oplossing), en de oplossing. Symptomen zijn echt belangrijk voor uw vervanger, want ze zullen hen raken voordat ze het probleem volledig begrijpen.
• Het vorige punt is nog belangrijker met betrekking tot legacy systemen, zoals bibliotheken of platforms, waar nieuwe versies worden uitgebracht, maar niet worden gebruikt in uw product. Problemen die u tegenkomt in uw versie (of erger nog, in interacties tussen verschillende legacy systemen) kunnen in toekomstige versies worden opgelost en dus zal het bestaan van de fout uit de publieke kennis verdwijnen, totdat het bijna onmogelijk is om er informatie over te vinden.

Vakantie is een goede “training” om je voor te bereiden op dat soort dingen. Het helpt ook om te meten hoe goed je voorbereid bent. Ga na 2-3 weken weer aan het werk en tel de dagen en inspanningen die je hebt besteed aan het schoonmaken van je “achterstand” - dit kan een goede benadering zijn van het “hit-by-bus scenario”.

Dit is ook een nuttig hulpmiddel als je wilt verbeteren. Analyseer backlog items die je moet oplossen en vraag jezelf af wat er gemaakt kan worden zodat dit door iemand anders gedaan kan worden. Bij een van de vorige klussen heeft dit me geholpen om de “vakantie-achterstand” in minder dan een jaar terug te brengen van ongeveer drie weken naar twee dagen.

• Oh mijn ik lijk de enige te zijn die deze informatie heeft, ik moet het documenteren om het beschikbaar te maken voor het hele team.
  Dammit niemand kan deze bug repareren behalve ik, ik moet een back-up man vinden en trainen…

Het ding dat de moeite waard is om in gedachten te houden is dat dit over het algemeen wordt beschouwd als een verantwoordelijkheid van uw management , dus alles wat je doet buiten de vereiste is naar eigen goeddunken. Vraag jezelf af hoeveel je wil vechten tegen busfactor en ga daarnaar toe.

• *

Ik wil enerzijds vervangbaar zijn…

• …zodat een andere kerel die mijn spullen van opslagplaats controleert, niet naar mij terug hoeft te komen om te proberen onhoudbare code
• … zodat die andere kerel die mijn gegevens in issue tracker bekijkt, mijn hulp niet nodig heeft om figuur waar ik aan dacht tijdens het werken aan
• … zodat die andere kerel die mijn wiki-pagina’s leest, mij niet nodig heeft om dingen uit te leggen die daar gedocumenteerd zijn - . …zodat ik kan genieten van het kijken hoe spullen die ik gemaakt heb groeit en bloeit, zodat ik een eigen leven kan leiden

…zodat ik me kan concentreren op het doen van nieuwe dingen zonder afgeleid te worden door zorgen over wat er achterblijft.

Vraag het aan je team. Vraag het aan je manager. Presenteer het probleem aan hen op precies dezelfde manier als u dat aan ons heeft.

Geef hen opties. Documentatie voor een toekomstige ontwikkelaar. Documentatie voor hen. Aflossen van technische schulden. Alles wat u kunt bedenken. Geef ze een schatting van de tijd. Geef ze de keuze. Laat ze het afwegen tegen je normale dagelijkse werk.

Hey, ze zouden zelfs kunnen beslissen dat het een risico waard is om te nemen. Maar, echt, het is aan hen om te beslissen.

En, als ze besloten hebben om het risico te nemen, dan moet je onsterfelijke geest stoppen met zich er schuldig over te voelen.

Ik wilde de hand reiken en die vragen beantwoorden…

De moeilijkste les die ik ooit heb geleerd was om die vragen niet te beantwoorden. Maar om de juiste vraag te stellen om hen, nietsvermoedend, naar het antwoord te leiden.

Een gegeven antwoord is anders dan een geleerde les!

Verklaren

Er zijn in principe twee verschillende scenario’s die het enige punt van mislukking creëren dat de OP aanpakt.

Business

Dit kan een bewuste beslissing zijn of een gevolg van een slechte planning, proces, of groei van het bedrijf. Het kan ook het resultaat zijn van inactiviteit of het niet herkennen en aanpakken van de groeiende kenniskloof.

Ongeacht de manier waarop, het bedrijf creëert de situatie waarin ze een superafhankelijkheid hebben van een enkel individu of een kleine groep van individuen die de kern van hun kennisbasis vormen. Veel bedrijven pakken dit aan door middel van mentorprogramma’s, cross-training en zowel formele als informele kennisdeling.

Vanuit mijn ervaring bevorderen degenen die hier het meest succesvol in zijn ook een onderwijsaanpak. Daarmee bedoel ik dat je zelden een ‘antwoord’ op een vraag krijgt, maar eerder een discussie en gerichte vragen van de expert(s) die je leiden op een pad van leren en het uitbreiden van je kennis over het product, het proces, de technologie in het spel.

Dit biedt ook een fris inzicht en perspectief aan de expert in dat de discussie. Het onderwijs kan inderdaad beide kanten op.

Werknemer

Over het algemeen heb je twee verschillende soorten medewerkers die in deze functie terechtkomen. Wat ik ‘The Go To’ en ‘The Protector’ noem.

‘The Go To’ is die werknemer waar de meeste managers van houden. Hij is degene die je zo'n beetje elke taak of project kan toewijzen en je hoeft je er geen zorgen over te maken. Dit zijn de mensen die hun niche in het bedrijf uitsnijden en de go to person worden en meer dan waarschijnlijk degene die de antwoorden heeft.

‘The Protector’ is die werknemer die een beslissing heeft genomen om hun grasmat te beschermen. Ze hebben het gevoel dat ze door hun kennis te bewaken hun positie, belang en toekomst in het bedrijf veilig stellen.

Beide creëren onbedoeld enkele faalpunten. The Go To‘ door altijd het snelle antwoord te geven en de ’The Protector‘ door geen enkele of alle informatie te delen.

Dus in een notendop zal alle documentatie in de wereld het onderliggende probleem van één enkel punt van mislukking niet oplossen. Ja, het is belangrijk en zou deel moeten uitmaken van elk BCP en rampenplan. Maar documentatie is niet echt kennisdeling in de zin dat iemand in staat zou moeten zijn om in te stappen en je taken uit te voeren zonder eerst een 200 pagina’s tellend document te moeten doorlopen.

Geef geen antwoord op de vraag; machtig ze zodat ze het zelf kunnen beantwoorden.

Hier is wat we doen waar ik werk:

a) We gebruiken een wiki voor documentatie. Geen Microsoft Word-bestanden, of tekstbestanden. Een wiki die doorzoekbaar is, volledig gevolgd kan worden door veranderingen, enz. (Ik zou Confluence aanbevelen, maar Confluence v4 is zo'n hond dat ik je aanraad om elders te kijken)

• Alle repetitieve of delegeerbare processen moeten worden gedocumenteerd.
• Checklists van “hier is hoe we het doen” moeten geschreven worden
• Checklists zijn erg belangrijk voor het samenstellen van teams, omdat ze het mogelijk maken dat processen worden uitgevoerd door iedereen die de lijst kan volgen…

b) Versiecontrole, uiteraard

c) Case/issue tracking systeem, uiteraard

d) Commentaar geven op uw werk. Dit is het meest genuanceerde ding, en het is zo moeilijk te leren, maar als aannemer/onafhankelijk, kun je dit misschien wel grommen: Commentaar moet je denkproces uitleggen en het waarom van wat je doet. Koppelingen naar documentatie, Stack Overflow, etc. zijn op hun plaats. Paragrafen en pagina’s met commentaar zijn geschikt. Het uitleggen van de dingen die u hebt geprobeerd en NIET hebt gedaan, zijn gepast. Een van de grootste problemen van code is dat de gedachte en het zweet die ervoor zorgen dat iets op een bepaalde manier werkt (in tegenstelling tot een andere manier) verloren gaat. Er is een boek, zoiets als ‘mooie code’ of zo, dat een brok heeft op de commentaarblokken in een eenheid in een van de grote open VCS systemen Subversion of Git , denk ik). Het is mooi omdat het het verhaal vertelt. Hier is wat deze code doet. Hier is hoe het werkt. Hier is hoe het is gestructureerd. (Ik geef toe dat dit blok, zoals ik me herinner, misschien niet groot is in de “waarom” vraag.)

Een uitvloeisel hiervan is: Hoeveel mensen gaan er terug en bewerken code om commentaar toe te voegen? We zouden allemaal… veel moeten doen. Maar in de praktijk doet bijna niemand dat.

Netflix heeft een systeem dat ze ChaosMonkey noemen. Het systeem ‘breekt’ of bootst het willekeurig breken van bepaalde systemen na.

Werknemers kunnen worden beschouwd als systemen en een manier om het breken van een werknemer na te bootsen is om die werknemer onaangekondigd en ongepland vrij te geven. De ChaosMonkey vertelde u om naar een film te gaan kijken zonder het uw collega’s te vertellen. Voor de korte termijn is het effect op hen hetzelfde als wanneer je door een bus zou zijn aangereden.

Dit test de robuustheid van hun systemen en stelt hen in staat om nieuwe gebreken in hun systemen te ontdekken die anders misschien onopgemerkt zouden zijn gebleven.

Dit zou kunnen helpen bij kennisoverdracht in een ronde en over manier als een robuuster systeem waarschijnlijk minder zal breken en minder grote bugs zal hebben die aandacht nodig hebben zodat de mensen in kwestie zich meer kunnen richten op hoe het systeem werkt en waarom het doet wat het doet in plaats van alleen maar vervelende zaken op te sporen die waardevolle kennisuitwisselingstijd opslokken.

Sinds het schrijven van dit antwoord ben ik me bewust geworden van https://www.fdic.gov/news/news/financial/1995/fil9552.html . In principe beveelt de FDIC aan dat banken verplichte, betaalde vacties van minstens 2 opeenvolgende weken opleggen aan belangrijke bankmedewerkers. Het welzijn van de werknemers is een secundaire overweging. De eerste overweging is dat dit de banken zal dwingen om iemand anders aan te wijzen die de verantwoordelijkheden van de vacante werknemer op zich neemt. Als de vertrekkende werknemer de regeling verduistert, valt deze onder het toezicht van de vervanger. Dit betekent ook dat de bank niet kwetsbaar is voor een busaanval.

Ik zou beginnen met

1. Standaardisering

2. 1. Reguliere en verplichte code/projectbeoordelingen

3. Teamgeest

4. Uiteraard Document. Het is een oud liedje. Ik zal het niet meer zingen

Het plannen hiervan maakt deel uit van een Business Continuity Planning , terwijl het hier gaat om het plannen van grotere rampen dan alleen maar door een bus worden aangereden, maar het proces plaatst de stukken om te herstellen van kleine incidenten zoals een belangrijke speler die wordt gepocheerd, tot grotere problemen zoals een ramp die gebouwen weghaalt, en de mensen die ze bemannen.

Wiki-How heeft een zo-zo-schrijf op hoe maak je een BCP en hoewel ik niet zou aanraden om deze methode daadwerkelijk te gebruiken voor uw bedrijf, het geeft een goed inzicht in de processen en het denken die nodig zijn voor het creëren van een. Over het algemeen worden BCP’s gedaan in een gefaseerde aanpak, waarbij de grootste risico’s worden aangepakt, en de voorbereiding op meer waarschijnlijke scenerios eerst en daarna de aanpak van lagere risico’s wordt gedaan. Maar elk bedrijf bouwt er over het algemeen BCP’s op volgens hun eigen behoeften, zodat het exacte proces varieert.

Het proces houdt over het algemeen in:

• Identificeren van risicogebieden
• documenteren van de betrokken processen
• bepalen van passende reacties op verschillende scenerios
• Enact plannen om met de scenerios om te gaan.

Onze dagelijkse regels tegen mensen die kennis ten grave dragen:

• Als iemand een script/routine schrijft, dan moet iemand anders als eerste dat gebruiken in de productie.
• Als iemand nieuwe systemen inzet, dan ** zal niemand die gebruiken of ondersteunen** totdat ze zelf alle benodigde toegangsgegevens kunnen opzoeken, alleen, ‘s nachts, zonder iemand anders te vragen.
• Er is ook “configuratie als code” en geautomatiseerd testen voor software. Het stelt uw opvolger in staat om uw werk te reverse-engineeren.

In feite, “dingen die nog niet vermeld/getest zijn bestaan niet voor ons”. Alleen dingen die wel vermeld staan zijn betrouwbaar.

We noemen het “ arcane kennis”. (alleen in iemands hoofd opgeslagen), en iedereen weigert er iets aan te doen.

Dat werkt natuurlijk niet tussen techneuten en niet-techneuten. Maar we verwachten ook niet dat techneuten de financiële berekeningen van de boekhouding kunnen overnemen. Dus zelfs onze boekhoudafdeling zou “kennis in het graf” kunnen nemen, als maar 1 boekhouder ooit die berekeningen zou doen.

Omdat er een limiet is. Als het team te klein is, dan zal er altijd iemand zijn die door een bus wordt aangereden.

De onderstaande punten dienen in uw werkbeschrijving te staan die u wordt overhandigd en die door de eigenaren van het bedrijf wordt vastgesteld. Het is hun verantwoordelijkheid om dit op zijn plaats te hebben. U kunt echter de enige zijn die de kennis heeft om hen te informeren dat dit nodig is.

• Werk binnen de vastgestelde normen voor uw vakgebied of organisatie.
• Documenteer wat u doet.
• Documenteer in detail als u afwijkt van de vastgestelde normen en waarom u dat deed
• Documenteer hoe u moet documenteren voor uw organisatie.
• Als u aan de top van een systeembeheersketen staat en de root/super gebruikersaccounts heeft; maak een account aan dat de hoogst mogelijke veiligheidsmachtiging heeft. Genereer er een lang, willekeurig wachtwoord voor. Print het op papier. Teken het. Verzegel het in een envelop en handig het aan de raad van bestuur en niet aan de CEO. Want een CEO kan op slechte voorwaarden afscheid nemen van het bedrijf en toch dat wachtwoord hebben. Vertel hen om het veilig op te slaan, off-site en het gebruik ervan (Het kan u super gebruiker status op het netwerk in het geval van uw afwezigheid of andere redenen die van toepassing kunnen zijn).