Come assicurarsi che la tua azienda non vada sott'acqua se i tuoi programmatori vincono alla lotteria [chiuso]

Ho alcuni programmatori sotto di me, stanno tutti andando molto bene e ovviamente sono molto intelligenti. Grazie mille.

Ma il problema è che ognuno di loro è responsabile di un'area centrale, che nessun altro membro del team ha la più pallida idea di cosa sia. Ciò significa che se qualcuno di loro viene rimosso, la mia azienda come azienda è morta perché non è sostituibile.

Sto pensando di coinvolgere nuovi programmatori per coprirli, nel caso in cui vengano colpiti da un autobus o si dimettano o altro. Ma temo che

1. I vecchi programmatori potevano resistere attivamente all'idea del trasferimento delle conoscenze, temendo che un backup potesse ridurre il loro valore.
2. Non ho un sistema per facilitare il trasferimento di tecnologia tra diversi sviluppatori, quindi anche se chiedo loro di farlo, non ho la certezza che lo faranno correttamente.

La mia domanda è,

1. Come metterlo ai vecchi programmatori in modo che sarebbero d'accordo
2. Quali sono i sistemi che usi per facilitare questo tipo di "backup"? Posso capire che puoi fare la revisione del codice, ma c'è un modo semplice per farlo? Penso che non siamo pronti per un vero e proprio check-in tramite revisione del codice del check-in.

Come metterlo ai vecchi programmatori in modo che sarebbero d'accordo

Presenta il problema apertamente a loro, ovviamente in modo tale da non vederlo come una minaccia, ma piuttosto un'opportunità per far funzionare meglio il team e il progetto. Ad esempio "Vorrei che altre persone sapessero quello che sai in caso di licenziamento" è ovviamente un approccio sbagliato :-) "Vorrei garantire il buon funzionamento del progetto anche se alcuni di voi vanno in vacanza o si ammalano " è molto meglio.

Di solito gli sviluppatori stessi sperimentano i problemi stessi ogni volta che alcuni di loro sono in vacanza e devono coprirlo. Inoltre, i buoni sviluppatori sentono la responsabilità del progetto a cui stanno lavorando, quindi probabilmente saranno d'accordo con questa idea. Tuttavia, dai loro il tempo di discutere e (si spera) impegnarsi nell'idea. Inoltre, permetti loro di dire la loro su come e con chi condividere le loro conoscenze all'interno del team. Può sembrare che Joe si senta bene a lavorare (e condividere le sue conoscenze) con Jim, ma non con Jack ecc.

Quali sono i sistemi che usi per facilitare questo tipo di "backup"? Posso capire che puoi fare la revisione del codice, ma c'è un modo semplice per farlo? Penso che non siamo pronti per un vero e proprio check-in tramite revisione del codice del check-in.

Nel nostro team, oltre alle revisioni di codice / design, utilizziamo

• Rotazione di compiti e aree di responsabilità tra i membri del team (ognuno di noi ha le sue principali aree di responsabilità, ma di tanto in tanto svolgiamo attività in un'area meglio conosciuta da un altro membro del team)
• Sessioni di trasferimento delle conoscenze faccia a faccia (di solito quando le attività sopra indicate richiedono, ma anche prima che qualcuno lasci la squadra)
• Wiki team / progetti

La revisione del codice in sé potrebbe non essere sufficiente in quanto in molte aree in genere c'è molto di più da sapere per uno sviluppatore rispetto a ciò che è direttamente leggibile dal codice. In altre parole, esiste anche il modello di dominio . Puoi leggere cosa fa effettivamente il codice, ma senza il modello non capirai perché .

Un modo per motivarli a condividere le loro conoscenze sarebbe quello di chiedere loro di fare una breve presentazione del loro lavoro ad altre persone. I programmatori normalmente sono molto orgogliosi del loro lavoro, e questa sarebbe una possibilità per mostrarlo. Una presentazione è una buona opportunità per far loro mostrare alcune delle stranezze raramente conosciute dagli estranei.

Inoltre, perché non essere semplicemente aperto e dire a tutti che tutti hanno bisogno di elaborare uno schema di condivisione delle conoscenze nel caso qualcuno venga investito da un autobus. Non lo vedo come irragionevole. Sta succedendo nella mia compagnia in questo momento, e anche se alcuni sono difensivi, sanno che deve essere fatto.

Forse potrebbero lavorare in coppia su alcune cose, se sono di natura curiosa, non dovrebbero esserci problemi.

Ottenere la documentazione interna del software aggiornata dovrebbe essere il primo passo, prima di iniziare ad assumere nuove persone. Certo, significa che i tuoi preziosi programmatori passeranno un po 'di tempo con gli strumenti di Office e UML invece dell'IDE, ma penso che ne valga la pena in ogni caso.

Una volta che hai una documentazione corrente, puoi fare in modo che i tuoi programmatori effettuino un controllo incrociato per assicurarsi che tutti capiscano cosa hanno scritto gli altri. Non c'è ancora bisogno di nuove persone.

Quindi puoi prendere in considerazione l'assunzione di nuove persone. O no, a seconda del carico di lavoro nella tua azienda.

Se sei in una grande azienda puoi chiamare le risorse umane e parlare di questo problema. Credetemi, i ragazzi della contabilità hanno lo stesso problema se il personale chiave viene investito da un autobus. Gli addetti al marketing avranno anche molti problemi se un venditore chiave diventa uno zombi nel mezzo di importanti trattative - succede spesso, o almeno così mi è stato detto.

Credo che il linguaggio corretto delle risorse umane per questo sia la pianificazione della successione . La tua azienda potrebbe avere già delle politiche e dei quadri per gestirlo.

Un posto in cui ho lavorato ha avuto lo stesso problema. Ciò che fecero fu assumere uno sviluppatore junior per lavorare con ogni sviluppatore Senior. Hanno creato piccoli team di 2 che hanno lavorato insieme a progetti. Ogni pochi mesi o progetti ruotavano gli sviluppatori junior tra i team. In questo modo gli sviluppatori senior sono rimasti gli esperti in materia, ma gli sviluppatori junior hanno iniziato a comprendere bene tutti i sistemi e il modo in cui hanno lavorato insieme. Inoltre, con la dimensione del team, i progetti di raddoppio sono stati realizzati più rapidamente.

Per i progetti più grandi che venivano fuori, a volte veniva chiesto agli sviluppatori senior di agire come sviluppatori Junior su un'altra parte del sistema per la durata di un progetto in modo che potessero iniziare a imparare gli altri sistemi.

La chiave era quella di rispettare la conoscenza e l'anzianità degli sviluppatori esistenti, pur espandendo e facendo crescere il team. È stato un processo lento ma nel tempo ha funzionato bene.

Una delle cose che rende tanto efficaci i progetti open source di successo è la mancanza di "proprietà" del codice. Con ciò intendo che nessuno è il solo manutentore di un'area della domanda - chiunque può ed è incoraggiato a dare un contributo a qualsiasi parte della domanda. È qualcosa in cui credo fortemente.

Quello che vuoi fare è spiegare che il modo in cui le cose stanno realmente facendo del male alla squadra che hai adesso. Ecco i punti che vuoi superare, e preferibilmente in questo ordine:

• Non posso liberarti di lavorare su altre cose interessanti che scendono dal luccio se sei l'unico a sapere come funziona.
• Vogliamo che tu possa fare una buona vacanza, ma non puoi permetterti perché nessun altro può fare quello che fai.
• È un fatto spiacevole che le persone cambino lavoro perché non sono soddisfatte della loro posizione attuale, non vogliamo perderti perché ti senti intrappolato nell'area in cui lavori.

Su una nota personale, ho dovuto fare i conti con un collega che moriva. Sebbene non esistessero silos informativi, la perdita ha colpito ancora duramente. Le possibilità che ciò accada sono molto inferiori al terzo punto elenco sopra.

Una volta che hai messo il tuo caso là fuori, chiedi il loro aiuto per avere idee su come correggere il problema. Vieni con il tuo ovviamente. Le loro idee li aiuteranno a rendersi conto che fanno parte di una squadra e sono necessari per qualcosa di più della loro area di competenza. È possibile che Jane sia interessata a ciò che fa Joe, ma se ne sente un po 'intimidita. Sapere che può aiutare a rendere il trasferimento delle conoscenze più divertente. Alcune delle cose che vorrai fare sono:

• Cross-training della squadra attuale. Potresti perdere un po 'di efficienza a breve termine, ma potrebbero esserci alcune lezioni apprese in un angolo dell'app che possono essere applicate ad altre parti dell'app. Chiedi a Jane e Joe di lavorare insieme sul progetto dell'altro per un po '.
• Promuovere una cultura della condivisione della conoscenza. Una società per la quale lavoravo aveva un programma "brown bag tech talk". Chiunque potrebbe presentare qualsiasi argomento approvato (di solito introducendo processi tecnologici o software). La compagnia ha servito il pranzo e il presentatore ha ricevuto un paio di centinaia di dollari per i loro sforzi.
• Il mentoring dovrebbe essere un modo di vivere. Lo scopo del tutoraggio di altre persone è di liberarti di fare cose nuove e di renderti ancora più prezioso per l'azienda.
• Trova i modi per attraversare i confini del silo di informazioni senza tirare il grado. Più divertente lo fai, meno sarà minaccioso. Se le persone della tua squadra sono brave come dici, probabilmente non sono completamente contente di come stanno le cose. Dovrai essere il giudice del fatto che la squadra sia in grado di gestirlo, ma puoi avere una settimana "andiamo avanti così e così". Inizia sempre con te stesso qui. L'idea è di mettere gli occhi di tutti su quali siano le responsabilità "così-e-così" e su come possono risolvere i problemi che stanno affrontando. Finché inizi prima con il collo sulla linea, avranno l'idea che nessuno è fuori a prendere il loro lavoro

In generale, prova a impressionare su di loro che vuoi rendere il lavoro più piacevole e hai bisogno del loro aiuto per farlo.

Gli stagisti potrebbero essere una buona idea, saranno subordinati diretti agli attuali sviluppatori, quindi non si sentiranno minacciati.

Man mano che l'azienda cresce, avrai bisogno sia dei vecchi sviluppatori, sia di quelli che lo hanno fatto dopo il loro internato.

Penso che potrebbe funzionare.

Generalmente, quando alcuni manager iniziano improvvisamente a preoccuparsi della documentazione e della pianificazione della successione, è un forte segnale di avvertimento che i programmatori stanno per essere licenziati o licenziati. È una tale deviazione dal tipico comportamento manageriale e preoccupazioni che fa scattare tutti i tipi di segnali di avvertimento nei programmatori.

A tutti viene detto di documentare tutte le loro procedure e processi

Livello 3 di " Segnali di pericolo di sventura aziendale ".

In alternativa, un saggio suggerisce che vorremmo incoraggiare una cultura di " Up or Out " anche se il contro-argomento è che pochissime aziende hanno una scala di carriera tecnica che ricorda in qualche modo lo spettro finanziario e di potere che la (mis) scala di carriera manageriale contiene.

Basandosi sul concetto di documentazione completa che @ammoQ ha iniziato nella sua risposta ...

Un buon manager lavora per sviluppare le competenze dei propri report diretti in modo che uno qualsiasi dei report possa sostituirli. Fai capire ai tuoi sviluppatori che un dipendente che fornisce la completa trasparenza del proprio lavoro è più prezioso di uno che mantiene tutto il suo lavoro segreto e nascosto. Se lo sviluppatore "segreto" morisse oggi, sarebbe una grande responsabilità per i costi recuperare la perdita di conoscenza. Se l'impiegato della "divulgazione integrale" morisse oggi, la società sarebbe ancora in perdita, ma sarebbe meno devastante. Pertanto, l'impiegato della "divulgazione integrale" ha più valore.

Qualsiasi dipendente che tenti di mantenere le conoscenze nascoste al fine di rendersi immune al licenziamento si rende anche immune da una promozione. Non puoi spostare uno sviluppatore in una posizione più stimolante e gratificante se non c'è nessuno che completi i banali compiti con cui è gravato oggi. Se le attività banali sono completamente documentate e divulgate, è possibile assumere un nuovo sviluppatore junior per compilare e promuovere lo sviluppatore precedente in una posizione più senior.

Ciò significa che anche tu devi documentare ciò che fai e fornire formazione a ciascuno dei tuoi rapporti diretti. In questo modo, se si è morto oggi, uno di loro potrebbe riempire per voi fino a quando è stato trovato un sostituto a tempo pieno.

Prima di iniziare a introdurre nuovi programmatori, chiederei a ciascuno di loro di aiutare a creare il proprio patrimonio documentato.

O con una wiki o una bibbia a 3 anelli di documenti su ogni aspetto del loro lavoro.

O se vuoi una documentazione davvero dettagliata e completa, assumi uno scrittore tecnico, intervista ogni programmatore e poi crea una documentazione di tutto ciò che fanno tutti, tutti i giorni, settimanalmente, mensilmente, annualmente.

Quindi creane una versione wiki, su cui il tuo programmatore può aggiornare / modificare / partecipare / commentare.

Quindi hai un sistema che crescerà nel tempo, e sarà la curva di apprendimento migliorata per ogni nuovo programmatore.

Inoltre, onestamente, non è saggio che il programmatore sia semplicemente bloccato in un'area centrale, ma è davvero importante incrociare, svolgere attività trasversali.

Quindi è possibile utilizzare il personale esistente, quando 1 persona prende una vacanza o qualcosa del genere.

Ogni volta che uno dei tuoi programmatori è malato, chiamalo ripetutamente per domande e problemi.

Ogni volta che uno dei tuoi programmatori è in vacanza, chiamalo ripetutamente per domande e problemi.

Presto si renderanno conto che è meglio per loro e per l'azienda non avere singoli responsabili delle aree chiave.

Nessuno vuole essere colpito dall'autobus, ma anche loro non vogliono prendere il progetto di qualcun altro in breve tempo e mantenere anche il loro progetto. Quindi tutti corrono il rischio di uscire dal mercato.

Se stai sviluppando in silos, devi iniziare a spostare le persone da un progetto all'altro. Inizia con la documentazione, la revisione del codice o la correzione di un semplice bug. Eventuali piccoli atti di protezione / territorialità del codice devono essere affrontati prima che ciò sfugga di mano.

Avere uno specialista solitario su un pezzo del tuo codice è un'illusione di efficienza.

Qualcuno ha mai voluto andare in vacanza?

Ho avuto molte più aziende a causa di stupidi errori da parte della direzione. Non andrai in crash e brucerai se uno o due ingegneri se ne andranno, dovrai solo lavorare un po 'più duramente per un po'. Sheesh, gestisco una squadra offshore che perde qualcuno ogni trimestre. Inizia a spostare i compiti. Oggi.