Come assicurarsi che la tua azienda non diventi sott'acqua se i tuoi programmatori vincono la lotteria [chiusa]

How to put it to the old programmers in such they would agree

Presentare apertamente il problema a loro, ovviamente in modo tale da non considerarlo una minaccia, piuttosto un'opportunità per far funzionare meglio la squadra e il progetto. Per esempio. "Mi piacerebbe che altre persone sappiano cosa sai in caso di licenziamento" è ovviamente un approccio sbagliato :-) "Mi piacerebbe garantire il buon funzionamento del progetto anche se alcuni di voi vanno in vacanza o si ammalano " è molto meglio.

Di solito gli sviluppatori si verificano personalmente i problemi ogni volta che alcuni di loro sono in vacanza e hanno bisogno di coprirsi per lui / lei. Inoltre, i buoni sviluppatori si sentono responsabili per il progetto a cui stanno lavorando, quindi probabilmente saranno d'accordo con questa idea. Tuttavia, date loro il tempo di discutere e (si spera) di impegnarsi per l'idea. Inoltre, permetti loro di dire la loro su come e con chi condividere le loro conoscenze all'interno del team. Può darsi che Joe ritenga OK di lavorare (e condividere le sue conoscenze) con Jim, ma non con Jack ecc.

What are systems that you use, in order to facilitate this kind of "backup"? I can understand that you can do code review, but is there a simple way to conduct this? I think we are not ready for a full blown, check-in by check-in code review.

Nel nostro team, a parte le 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 ogni tanto eseguiamo compiti in un'area meglio conosciuta da un altro membro del team)
• Le sessioni di trasferimento delle conoscenze faccia a faccia (di solito quando richiedono le attività di cui sopra, ma anche prima che qualcuno lasci il team)
• Squadra / progetto wiki

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

Un modo per motivarli a condividere le loro conoscenze sarebbe quello di chiedere loro di fare una breve presentazione sul loro lavoro ad altre persone. Normalmente i programmatori sono molto orgogliosi del loro lavoro e questa sarebbe la possibilità di dimostrarlo. Una presentazione è una buona opportunità per farli mostrare alcuni dei capricci raramente conosciuti dagli estranei.

Inoltre, perché non essere aperti a riguardo e dire a tutti che tutti voi avete bisogno di elaborare uno schema di condivisione della conoscenza nel caso qualcuno venga investito da un autobus. Non lo considero irragionevole. Sta accadendo nella mia azienda in questo momento, e anche se alcuni sono difensivi, sanno che è necessario farlo.

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

Ottenere la documentazione interna del software aggiornato 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 Office e UML invece dell'IDE, ma penso che ne valga la pena in ogni caso.

Una volta che hai una documentazione corrente, puoi consentire ai tuoi programmatori di verificarla per assicurarsi che tutti capiscano cosa hanno scritto gli altri. Ancora nessun bisogno di nuove persone.

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

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

Credo che il linguaggio HR corretto per questo sia Pianificazione della successione . La tua azienda potrebbe avere già policy e framework per gestire questo.

Un posto in cui lavoravo aveva lo stesso problema. Quello che hanno fatto è stato assumere uno sviluppatore junior per lavorare con ogni sviluppatore senior. Hanno creato piccole squadre di 2 persone che hanno lavorato insieme ai progetti. Ogni pochi mesi o progetti avrebbero fatto ruotare gli sviluppatori junior tra le squadre. In questo modo gli sviluppatori senior rimasero gli esperti in materia, ma gli sviluppatori junior iniziarono a capire bene tutti i sistemi e come lavoravano insieme. Inoltre, i progetti di raddoppiamento della squadra sono stati fatti più velocemente.

Per progetti più grandi che si presentavano A volte, a sviluppatori senior veniva chiesto di agire come sviluppatore 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 rispettare le conoscenze e l'anzianità degli sviluppatori esistenti mentre si espandeva e si espandeva la squadra. È stato un processo lento ma nel tempo ha funzionato bene.

Una delle cose che rende di successo i progetti open source di successo è la mancanza di "proprietà" del codice. Con ciò intendo che nessuno è il solo manutentore di un'area dell'applicazione - chiunque può ed è incoraggiato a fornire contributi a qualsiasi parte dell'applicazione. È qualcosa in cui credo strongmente.

Quello che vuoi fare è spiegare che il modo in cui stanno le cose in realtà sta danneggiando la squadra che hai ora. Ecco i punti che vuoi attraversare e preferibilmente in questo ordine:

• Non posso liberarti di lavorare su altre cose interessanti che arrivano giù dal luccio se sei l'unico che sa come funziona.
• Noi vogliamo che tu possa essere in grado di 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 dall'area in cui lavori.

Su una nota personale, ho avuto a che fare con un collega che moriva. Mentre non c'erano silos di informazioni, la perdita colpiva ancora duramente. Le probabilità che ciò accada sono molto inferiori rispetto al terzo punto in alto.

Una volta che hai messo il caso là fuori, arruola il loro aiuto per idee su come risolvere il problema. Vieni con il tuo, naturalmente. Le loro idee li aiuteranno a capire che fanno parte di una squadra e sono necessari per qualcosa di più della semplice area di competenza. Potrebbe essere che Jane possa avere un interesse in quello che Joe sta facendo, ma si sente un po 'intimidito da ciò. Sapere che può contribuire a rendere più divertente il trasferimento delle conoscenze. Alcune delle cose che vorrai fare sono:

• Incrocia la 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. Fai in modo che Jane e Joe lavorino insieme per un po 'sul progetto dell'altro.
• Promuovere una cultura della condivisione della conoscenza. Una società per la quale ho lavorato ha avuto un programma "Brown bag tech talk". Chiunque può presentarsi su qualsiasi argomento approvato (di solito introducendo tecnologia o processi software). L'azienda approvvigionò il pranzo e il presentatore ottenne un paio di centinaia di dollari per il loro impegno.
• Il mentoring dovrebbe essere uno stile di vita. Lo scopo di tutorare altre persone è di liberarti di fare cose nuove e ti rende ancora più prezioso per l'azienda.
• Trova i modi per attraversare i confini del silos di informazioni senza tirare il grado. Più divertente lo fai, meno sarà minaccioso. Se le persone della tua squadra sono brave come dici tu, probabilmente non sono completamente contenti di come stanno le cose. Dovrai essere il giudice del fatto che la squadra possa gestirlo, ma puoi avere una settimana "prendi la scelta dei così-e-così". Inizia sempre da solo qui. L'idea è di avere gli occhi di tutti su quali sono le responsabilità del "così-e-così" e come possono risolvere i problemi che stanno avendo. Finché inizi con il collo in prima linea, avranno l'idea che nessuno è fuori a fare il loro lavoro

In generale, cerca di fare colpo su di loro per rendere il lavoro più piacevole e hai bisogno del loro aiuto per farlo.

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

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

Penso che potrebbe funzionare.

In genere, quando un manager inizia improvvisamente a occuparsi della documentazione e della pianificazione della successione, è un strong segnale di avvertimento che i programmatori stanno per essere licenziati o licenziati. È una tale deviazione dal tipico comportamento manageriale e preoccupazioni che scatena tutti i tipi di segnali di allarme nei programmatori.

Everyone is told to document all their procedures and processes

Livello 3 di " Segnali di pericolo per la distruzione aziendale ".

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

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 in modo che i tuoi sviluppatori comprendano che un dipendente che fornisce completa trasparenza del proprio lavoro ha più valore di uno che tiene segreto e nascosto tutto il proprio lavoro. Se lo 'sviluppatore' segreto 'fosse morto oggi, sarebbe una grossa responsabilità di costo per l'azienda recuperare quella conoscenza perduta. Se l'impiegato della "piena divulgazione" fosse morto oggi, la compagnia sarebbe ancora in perdita, ma sarebbe meno devastante. Pertanto, il dipendente "full-disclosure" ha più valore.

Qualsiasi dipendente che cerca di mantenere la conoscenza nascosta per rendersi immune al licenziamento si rende immune a una promozione. Non è possibile spostare uno sviluppatore in una posizione più stimolante e gratificante se non c'è nessuno per completare i compiti banali di cui sono gravati oggi. Se i compiti banali sono completamente documentati e pienamente divulgati di quanto puoi assumere un nuovo junior-sviluppatore da 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 tu è morto oggi, uno di questi potrebbe completarlo finché non viene trovato un sostituto a tempo pieno.

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

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

O se vuoi una documentazione veramente dettagliata e completa, assumi uno scrittore tecnico, intervista ogni programmatore e poi crea una documentazione di tutto, lo fanno tutti, ogni giorno, ogni settimana, ogni mese, ogni anno.

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

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

Inoltre, onestamente non è saggio avere programmatori semplicemente bloccati in un'area centrale, in realtà paga per attraversare il treno, attraversare il lavoro principale.

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

Ogni volta che uno dei tuoi programmatori non si ammala, telefonalo ripetutamente con domande e problemi.

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

Presto si renderanno conto che è meglio per loro così come per la società non avere singoli responsabili per le aree principali.

Nessuno vuole essere colpito dal bus, ma non vuole nemmeno prendere in consegna il progetto di qualcun altro con breve preavviso e mantenere il proprio progetto. Quindi tutti corrono il rischio di andare fuori mercato.

Se stai sviluppando in silos, devi iniziare a spostare le persone da un progetto a un altro. Inizia con la documentazione, la revisione del codice o la correzione di un bug semplice. Ogni piccolo atto di protezione del codice / territorialità dovrebbe essere affrontato prima che questo diventi troppo fuori controllo.

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

Chiunque vuole andare in vacanza?

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