Come posso prepararmi a essere investito da un autobus?

Documentazione.

Documentazione.

Documentazione.

Documentazione.

Documentare le vostre idee, i vostri progetti e il vostro codice. Documentazione.

Documentazione.

Documentate le vostre correzioni di bug spiegando quale fosse il problema e come lo avete risolto e perché.

E ho menzionato la documentazione?

Se si lavora in un ambiente in cui la politica è lassista (per cui gli sviluppatori junior non possono semplicemente preoccuparsi di presentare modifiche alla documentazione - gli aggiornamenti della documentazione rilevante dovrebbero essere mandate insieme ad ogni fusione di ramo), manca la revisione tra pari (per cui gli sviluppatori junior/senior vengono sorpresi durante periodi di comprensibile pigrizia), e/o la documentazione è memorizzata separatamente dal codice (per cui può essere facilmente persa), allora è anche importante considerare se l'ambiente può essere modificato in modo che questi problemi non siano resi tali. Altrimenti, tutto il vostro sforzo per scrivere la documentazione potrebbe essere inutile.

Detto questo, non mi spingerei sempre a definirla una responsabilità personale: in definitiva, se i team sono gestiti e/o organizzati in modo improprio, allora non è una vostra responsabilità; nel caso in cui passaste a un nuovo lavoro, mi limiterei a consegnare la mia documentazione completa e penserei “beh, se non potete usarla e mantenerla correttamente, allora è la vostra colpa… ora buona fortuna”.

Questa linea di pensiero non regge però nel caso “colpito da un autobus”, in cui potreste essere in procinto di istigare tali politiche, ma non l'avete ancora fatto. Per questo scenario, vi suggerirei semplicemente di incoraggiare il management (e i vostri dirigenti) a iniziare a prendere sul serio queste cose al più presto possibile.

Non fare nulla di diverso. Lavorate come se NON sarete “investiti da un autobus” domani.

Il problema “investiti da un autobus” è un problema organizzativo e non qualcosa che deve essere esplicitamente affrontato nei vostri obiettivi di lavoro.

I vostri collaboratori e la direzione dovrebbero pensarci, ma penso che sia troppo aspettarsi che i singoli collaboratori lavorino come se domani potessero letteralmente andarsene. Se il management non si rende conto dei potenziali problemi, significa che sono totalmente estranei o che forse non siete così indispensabili come pensavate.

Nella migliore delle ipotesi, se siete generosi, potreste voler ricordare alle persone chiave e portare a termine il compito di avere un supporto in caso di emergenza. Ma in un'epoca in cui le aziende gettano le carriere “sotto l'autobus” per un capriccio in nome del profitto a breve termine, quanto dovrebbe importarvi veramente?

Diligenti pratiche ingegneristiche risolvono molti dei problemi del dilemma “colpito da un autobus”. Andare al di là di questo al punto di essere pronti per la scomparsa immediata e permanente creerà molte spese generali per il singolo contribuente. Sembra che l'ambiente descritto dall'OP potrebbe trarre beneficio da pratiche e personale semplicemente migliori, non c'è bisogno che lavori come se potesse vaporizzarsi da un momento all'altro.

Se lavorate come appaltatori, direi che questo è al 100% sul vostro datore di lavoro. Dite loro che realizzare gli obiettivi che si sono prefissati per voi significa che altre cose che secondo voi dovrebbero essere considerate obiettivi non vengono realizzate; chiedete loro se vogliono modificare i vostri obiettivi. Potrebbero anche dirvi di continuare così com'è, dato che il vostro tempo è costoso e vogliono il miglior rapporto qualità-prezzo a breve termine.

Se lavorate come dipendenti, potreste avere più margine di manovra per pianificare la successione (o forse c'è l'aspettativa che lo stiate già facendo). Tuttavia, parlatene con il vostro capo o il vostro manager del team, perché hanno bisogno di conoscere il problema e di sapere come siete e come pensate di dover essere, spendendo il vostro tempo.

Alcune cose a ciò aiuterebbero nella pianificazione della successione:

• I processi quotidiani dovrebbero essere documentati in una certa misura, ma è probabile che altre persone nel vostro team seguano gli stessi processi e possano insegnarli a un nuovo arrivato. Se non tutti usano processi simili, questo è un problema attuale che dovrebbe essere risolto; riunitevi, discutete su quale sia il modo migliore, arrivate a qualche standard (consensuale o forzato dall'alto), e usate lo standard, complimenti che lo standard può andare nella vostra documentazione per il nuovo arrivato.
• Le cose importanti che vengono comunicate via email, riunioni, o conversazioni casuali devono diventare una risorsa condivisa, qualsiasi cosa, da una cartella di documenti su un disco condiviso a un wiki. C'è questa strana convinzione (almeno dove ho lavorato) che se qualcosa viene inviato via email a tutti i membri di un team, allora per sempre quel team saprà la cosa; questo non tiene in considerazione che i cambiamenti di trucco del team e che qualsiasi formazione (anche se avviene) non trasferirà mai tutte le conoscenze, solo un sottoinsieme di conoscenze usate di frequente.
• (Possibilmente specifico del software) Documento chiaramente controintuitivo processi o decisioni di progettazione, è importante identificare che il processo è riconosciuto come controintuitivo e perché è così, a prescindere. Ad esempio, se il vostro cliente vi ha chiesto di fare qualcosa che sembra “scorretto” (“Non sono un esperto di dominio, ma siete sicuri di volerlo fare?”), e voi avete spiegato perché lo ritenete scorretto e hanno confermato che è quello che volevano (meglio ancora se vi hanno spiegato il perché), allora le ragioni per cui lo ritenete scorretto e la spiegazione del perché è corretto dovrebbero essere documentate. Che le funzioni del software secondo le specifiche non saranno sufficienti per una sostituzione, avranno la stessa domanda che avete posto voi.
• Per qualsiasi problema che incontrate e che richiede molto tempo/ricerca per essere risolto, documentate il problema, i sintomi, il percorso più breve verso la soluzione (cioè: sapere quello che sapete ora, qual è stato il percorso più rapido dall'identificazione dei sintomi alla soluzione), e la soluzione. I sintomi sono davvero importanti per il vostro sostituto, perché li colpiranno prima che comprendano appieno il problema.
• Il punto precedente è ancora più importante per quanto riguarda i sistemi legacy, come le biblioteche o le piattaforme, dove vengono rilasciate nuove versioni ma non vengono utilizzate nel vostro prodotto. I problemi che si incontrano nella propria versione (o peggio ancora, nelle interazioni tra diversi sistemi legacy) possono essere risolti nelle versioni future e quindi l'esistenza stessa del difetto svanirà dalla conoscenza del pubblico, fino a quando sarà quasi impossibile trovare informazioni al riguardo.

La vacanza è un buon “allenamento” per prepararsi a cose del genere. Aiuta anche a misurare quanto bene si è preparati. Tornate al lavoro dopo 2-3 settimane e contate i giorni e gli sforzi spesi per ripulire il vostro “arretrato” - questo potrebbe essere un'approssimazione decente per “scenario hit-by-bus”.

Questo è anche uno strumento utile se volete migliorare. Analizza gli arretrati che devi risolvere e chiediti cosa potrebbe essere fatto in modo che questo possa essere fatto da qualcun altro. In uno dei lavori precedenti, questo mi ha aiutato a ridurre gli sforzi per le “ferie arretrate” da circa tre settimane a due giorni in meno di un anno.

• Oh mio Dio, mi sembra di essere l'unico ad avere queste informazioni, devo documentarle per renderle disponibili a tutto il team.
  Dannazione nessuno può risolvere questo bug tranne me, devo trovare e addestrare un ragazzo di riserva…

La cosa che vale la pena di tenere a mente è che generalmente questa è considerata una responsabilità del vostro management , quindi tutto ciò che fate oltre il necessario è a vostro piacimento. Chiedetevi quanto volete combattere fattore bus e procedere di conseguenza.

Io per esempio voglio essere sostituibile…

• …così che l'altro tizio che controlla la mia roba dal repository non debba tornare da me cercando di capire codice non conservabile
• … in modo che l'altro tizio che controlla i miei dati nel issue tracker non abbia bisogno del mio aiuto per figurare a cosa stavo pensando mentre ci lavoravo
• …in modo che l'altro tizio che legge le mie pagine wiki non abbia bisogno di me per spiegare le cose documentate lì
• . …così che io possa divertirmi a guardare come roba che ho fatto cresce e fiorisce, vivendo la propria vita

…così che io possa concentrarmi sul fare cose nuove senza essere distratto dalle preoccupazioni per ciò che è rimasto.

Chiedete alla vostra squadra. Chiedi al tuo manager. Presentate loro il problema esattamente come avete fatto con noi.

Date loro delle opzioni. Documentazione per un futuro sviluppatore. Documentazione per loro. Pagare il debito tecnico. Qualsiasi cosa vi venga in mente. Date loro delle stime di tempo. Date loro la possibilità di scegliere. Lasciategliela soppesare rispetto al vostro normale lavoro quotidiano.

Ehi, potrebbero anche decidere che è un rischio che vale la pena correre. Ma, in realtà, spetta a loro decidere.

E, se hanno deciso di correre il rischio, allora il tuo spirito immortale dovrebbe smettere di sentirsi in colpa.

Volevo raggiungere e rispondere a quelle domande…

La lezione più difficile che ho imparato è stata quella di non rispondere a quelle domande. Ma porre la domanda giusta per condurli, ignari, a trovare da soli la risposta.

Una risposta data è diversa da una lezione imparata!

Spiegazione

Esistono fondamentalmente due diversi scenari che creano l'unico punto di fallimento che l'OP sta affrontando.

Impresa

Questa può essere una decisione consapevole o il risultato di una cattiva pianificazione, di un processo o di una crescita dell'impresa. Può anche essere il risultato dell'inazione o dell'incapacità di riconoscere e affrontare il crescente divario di conoscenza.

Indipendentemente dal come, l'azienda crea la situazione in cui ha una super dipendenza da un singolo individuo o da un piccolo gruppo di individui che costituiscono il nucleo della sua base di conoscenza. Molte aziende affrontano questo problema utilizzando programmi di mentoring, formazione trasversale e condivisione di conoscenze sia formali che informali.

Dalla mia esperienza, le aziende che hanno avuto più successo in questo campo favoriscono anche un approccio didattico. Con questo intendo dire che raramente vi viene data una “risposta” a una domanda, ma piuttosto una discussione e domande puntuali da parte dell'esperto o degli esperti che vi conducono lungo un percorso di apprendimento e di espansione delle vostre conoscenze sul prodotto, sul processo, sulla tecnologia in gioco.

Questo offre anche una nuova visione e una nuova prospettiva all'esperto in quanto la discussione. L'insegnamento può infatti andare in entrambi i sensi.

Impiegato

In generale si hanno due diversi tipi di dipendenti che finiscono in questa posizione. Quello che io chiamo ‘The Go To’ e ‘The Protector’.

‘The Go To’ è quel dipendente che la maggior parte dei manager ama. È quello a cui si può assegnare praticamente qualsiasi compito o progetto senza doversi preoccupare di questo. Queste sono le persone che si ritagliano la loro nicchia all'interno dell'azienda e diventano il “Go to person” e, molto probabilmente, quello che ha le risposte.

‘The Protector’ è quel dipendente che ha preso la decisione di proteggere il proprio territorio. Sentono che, custodendo le loro conoscenze, stanno assicurando la loro posizione, la loro importanza e il loro futuro nell'azienda.

Entrambi creano inavvertitamente singoli punti di fallimento. Il “Vai a” fornendo sempre la risposta rapida e il “Protettore” non condividendo nessuna o tutte le informazioni.

Quindi, in poche parole, tutta la documentazione del mondo non risolverà il problema di fondo di un singolo punto di fallimento. Sì, è importante e dovrebbe far parte di ogni piano di BCP e di preparazione alle catastrofi. Ma la documentazione non è una vera e propria condivisione di conoscenze nel senso che qualcuno dovrebbe essere in grado di intervenire ed eseguire i vostri compiti di lavoro senza dover passare attraverso un documento di 200 pagine in anticipo.

Non rispondete alla domanda; date loro la possibilità di farlo in modo che possano rispondere da soli.

Ecco cosa facciamo dove lavoro:

a) Usiamo un wiki per la documentazione. Non file Microsoft Word o file di testo. Un wiki che sia ricercabile, completamente tracciabile, ecc. (raccomanderei Confluence , ma Confluence v4 è un tale cane che vi suggerisco di guardare altrove)

• Ogni processo ripetitivo o delegabile deve essere documentato.
• Le liste di controllo di “ecco come facciamo __________” dovrebbero essere scritte
• Le liste di controllo sono molto importanti per la costruzione di team, in quanto permettono che i processi siano fatti da chiunque possa seguire la lista…

b) Controllo delle versioni, ovviamente

c) Sistema di tracciamento dei casi e delle emissioni, ovviamente

d) Commentare il vostro lavoro. Questa è la cosa più sfumata, ed è così difficile da insegnare, ma come appaltatore/indipendente, potreste essere in grado di strimpellare questo: I commenti dovrebbero spiegare il vostro processo di pensiero e il perché di quello che state facendo. I link alla documentazione, Stack Overflow, ecc. sono appropriati. Paragrafi e pagine di commenti sono appropriati. Spiegare le cose che avete provato e che NON avete fatto è appropriato. Uno dei maggiori problemi del codice è che si perde il pensiero e il sudore che si spende per far funzionare qualcosa in un modo (invece che in un altro). C'è un libro, qualcosa come “bel codice” o qualcosa del genere, che ha un pezzo sui blocchi dei commenti in una unità in uno dei grandi sistemi aperti VCS Subversion o Git , credo). È bello perché racconta la storia. Ecco cosa fa questo codice. Ecco come funziona. Ecco come è strutturato. (Confesso che questo blocco, se ricordo bene, potrebbe non andare a fondo nella questione del “perché”.)

Un corollario di questo è: Quante persone tornano indietro e modificano il codice solo per aggiungere commenti? Tutti noi dovremmo… molto. Ma in pratica quasi nessuno lo fa.

Netflix ha un sistema che chiamano ChaosMonkey . Esso essenzialmente ‘rompe’ o emula la rottura di certi sistemi a caso.

I dipendenti possono essere considerati come sistemi e un modo per emulare la rottura di un dipendente è quello di dare a quel dipendente un tempo libero non annunciato e non programmato. Il ChaosMonkey vi ha detto di andare a vedere un film senza dirlo ai vostri colleghi. Per il breve periodo, l'effetto su di loro è lo stesso che avrebbe avuto se fossi stato investito da un autobus.

Questo mette alla prova la robustezza dei loro sistemi e permette loro di individuare nuovi difetti nei loro sistemi che altrimenti sarebbero potuti passare inosservati.

Questo potrebbe aiutare il trasferimento di conoscenze in un modo o nell'altro, in quanto un sistema più robusto rischia di rompersi meno e avrà meno bug di grandi dimensioni che necessitano di attenzione, permettendo alle persone in questione di concentrarsi maggiormente su come il sistema funziona e perché fa quello che fa, piuttosto che limitarsi a inseguire questioni fastidiose che consumano tempo prezioso per lo scambio di conoscenze.

Da quando ho scritto questa risposta, sono venuto a conoscenza di https://www.fdic.gov/news/news/financial/1995/fil9552.html . Fondamentalmente la FDIC raccomanda alle banche di imporre agli impiegati delle banche chiave di imporre ferie obbligatorie e retribuite di almeno 2 settimane consecutive. Il benessere degli impiegati è una considerazione secondaria. La considerazione primaria è che ciò costringerà le banche a nominare qualcun altro che si occupi delle responsabilità dell'impiegato vacante. In caso di appropriazione indebita da parte dell'impiegato che lascia l'istituto, il sistema cadrà a pezzi sotto la sorveglianza del sostituto. Ciò significa anche che la banca non sarà vulnerabile all'attacco di un autobus.

Inizierei con

1. 1. Standardizzazione

2. 1. Codice regolare e obbligatorio/revisione del progetto

3. 3. Spirito di squadra

4. Ovviamente Documento. È una vecchia canzone. Non la canterò più

La pianificazione di questo fa parte di un Business Continuity Planning mentre si tratta di pianificare per disastri più grandi che non solo di essere colpiti da un autobus, ma il processo mette in atto i pezzi per recuperare da piccoli incidenti come un giocatore chiave che è stato rubato, a problemi più grandi come un disastro che distrugge gli edifici, e le persone che lo staff.

Wiki-How ha una scrittura così così così su come creare un BCP e anche se non raccomanderei di usare effettivamente questo metodo per il vostro business, esso fornisce una buona visione dei processi e del pensiero necessari per crearne uno. Generalmente i BCP sono fatti in approcci scaglionati che gestiscono i rischi maggiori, e si preparano per scenari più probabili prima e affrontano i problemi di rischio più bassi dopo. Ma in genere ogni azienda costruisce i BCP in base alle proprie esigenze, quindi il processo esatto varia.

Il processo generalmente prevede:

• Identificare le aree di rischio
• documentare i processi coinvolti
• determinare le risposte appropriate ai vari scenari
• Attuare piani per affrontare gli scenari

Le nostre regole quotidiane contro chi si porta la conoscenza nella tomba:

• Se qualcuno scrive uno script/routine, allora qualcuno deve essere il primo a usare quello in produzione.
• Se qualcuno implementa nuovi sistemi, allora nessuno li userà o li supporterà fino a quando non potrà cercare tutte le credenziali di accesso necessarie da solo, da solo, di notte, senza chiedere a qualcun altro.
• C'è anche “configurazione come codice” e test automatici per il software. Permette al vostro successore di reingegnerizzare il vostro lavoro.

In effetti, “le cose che non sono ancora elencate/testate non esistono per noi”. Solo le cose che sono elencate sono affidabili.

Lo chiamiamo “conoscenza dell'arcano”. (memorizzato solo nella testa di qualcuno), e tutti si rifiutano di agire su di esso.

Ovviamente questo non funziona tra argomenti tecnici e non tecnici. Ma non ci aspettiamo che i tecnici siano in grado di prendere in mano i calcoli finanziari neanche dal reparto contabilità. Quindi anche il nostro reparto contabilità potrebbe portare “la conoscenza nella tomba”, se solo 1 contabile facesse questi calcoli.

Perché c'è un limite. Se il team è troppo piccolo, ci sarà sempre qualcuno che verrà investito da un autobus.

I punti seguenti dovrebbero essere nella descrizione del vostro lavoro consegnata a voi e stabilita dai proprietari dell'azienda. E’ loro responsabilità avere tutto ciò. Tuttavia, potreste essere gli unici a sapere che ciò è necessario.

• Lavorare secondo gli standard stabiliti per il vostro settore o la vostra organizzazione.
• Documentare ciò che fate.
• Documentare in dettaglio se vi discostate dagli standard stabiliti e perché lo avete fatto.
• Documentare come documentare per la vostra organizzazione.
• Se siete in cima alla catena di amministrazione di un sistema e possedete gli account root/super user; create un account che abbia la più alta autorizzazione di sicurezza possibile. Generare una password lunga e casuale. Stampatela su carta. Firmatela. Sigillatelo in una busta e consegnatelo al consiglio di amministrazione e non al CEO. Perché un CEO può separarsi dall'azienda in cattive condizioni e avere ancora quella password. Dite loro di conservarla in modo sicuro, fuori sede e di utilizzarla (può darvi lo status di super utente in rete in caso di vostra assenza o per altri motivi che possono essere applicati).