Quali azioni intraprendere quando le persone lasciano la squadra? [duplicare]

Gli chiedo di interrompere completamente la codifica e dedicare il suo tempo:

• coaching di altri
• rivedere i suoi commenti in codice (per adattarli alla situazione)
• e scrivi un documento che avrebbe scritto se sapesse che se ne sarebbe andato in una settimana.

Cerco di mettere la priorità nei moduli che possiede per far funzionare altri sviluppatori con loro.

Ricorda che dopo che se n'è andato, è troppo tardi per fare coaching o fargli delle domande (in buone condizioni).

Quando esce, cogli l'occasione per chiedergli come pensa che potresti migliorare la tua organizzazione. Gli ex dipendenti non hanno nulla da perdere e il loro feedback è onesto e quindi sempre prezioso.

Sembravi aver coperto i punti chiave:

• Aggiorna / crea documentazione importante sul componente / sistema che hai rimandato.
• Annota insidie comuni, trucchi , ecc. che potrebbero conoscere, ma il team non lo fa
• Migliora i test per le sezioni difficili / complesse che li mancano.

Altre cose possono essere utili:

• Avere qualcuno partner con loro per fare un "brain dump" durante la fine. Questo è molto più veloce, ma meno preciso, quindi la documentazione quando sei fuori dal tempo.
• Cerca di essere in buoni rapporti con il dipendente uscente, potrebbe essere necessario assumerli per alcune ore in un ruolo di consulenza al di fuori delle ore (se sei davvero bloccato).

Almeno, questo è quello che ho imparato dopo aver visto i miei ex datori di lavoro perdere 3 dei 4 dipendenti tecnici chiave nei miei primi 2 anni là ...

Come appaltatore da 30 anni, ho lasciato le squadre decine di volte.

A volte vengo richiamato. A volte no.

Le persone che dovevano richiamarmi non - in qualche modo - capivano che ero un appaltatore e me ne andavo. Questo, BTW, si manifestava generalmente all'inizio del progetto. Alcune organizzazioni hanno un basso turnover - le persone hanno lavorato insieme per anni e hanno post-it gialli con informazioni di sistema critiche pubblicate nei cubicoli e non c'è documentazione scritta che sia corretta.

Le persone che non mi hanno richiamato erano, forse, infelici e hanno cancellato tutto il mio codice. Chi lo sa?

Tuttavia, le organizzazioni che hanno preso l'abitudine di seguire sono felici.

1. Monitoraggio dei bug. Questo è fondamentale. Non ci dovrebbero essere commenti "TODO:" nel codice. Queste sono richieste di funzionalità o potenziali bug che dovrebbero essere tracciati formalmente. Tutto il nastro adesivo e i cerotti devono essere formalmente e completamente documentati come correzioni di bug o miglioramenti futuri.

2. Test. Anche critico. Se la build è interrotta, nessuno torna a casa.

3. Mantenimento dei requisiti, documentazione di progettazione e distribuzione attuale. Ciò richiede revisioni e procedure dettagliate attive e costanti. Richiede un'organizzazione che si aspetta e gestisce il fatturato. Nessuno dovrebbe avere lo stesso lavoro per più di qualche anno. Mescola, rimpiazza e ri-rimescola finché la documentazione non rende indolore.

4. Monitoraggio di obiettivi e risultati. Se non stai gestendo attivamente il codice prodotto, non sai a cosa stanno lavorando le persone e non sai cosa è finito a metà o cosa è a metà rotta. ("FOB" Flat On Back, cioè "OOT", sul tavolo operatorio, anche in corso di chirurgia: eravamo soliti dire "tette", ma dovevo fermarci quando alcuni ingegneri si sono opposti a questo: troppo colorati. giusto, è inappropriato.)

   Ciò ti consentirà di impedirgli di scrivere un nuovo codice poco prima di andarsene.

La linea di fondo è che hai bisogno di una visione a 360 gradi di ciò che il team ha in (requisiti) ciò che il team ha rilasciato (testato, codice documentato) e ciò che il team ha in corso (nuovo codice, correzioni ).

Se hai questa vista, una singola persona nel team può essere sostituita.

Altri suggerimenti oltre a quanto già detto:

1. Lascialo scrivere un riepilogo dello stato su tutto ciò su cui ha lavorato. Ciò che è definitivamente fatto, ciò che "dovrebbe" funzionare, ciò che è a metà, ciò che è intatto.
2. Consentitegli di documentare tutti i compiti collaterali di cui potrebbe essere (informalmente) responsabile; come controllare i file di registro del server di un cliente una volta al mese. In un mondo perfetto, tutti quei compiti sarebbero già stati documentati, ma nella vita reale qualcosa potrebbe essersi insinuato.
3. È fondamentale scoprire se questo è l'inizio di un esodo di massa. Forse qualcosa sta andando storto nel progetto e altri probabilmente seguiranno presto. Se è così, vuoi contrastare il più possibile.
4. Se l'ingegnere ha un contatto diretto con il cliente, gli permetta di documentare chi sono le sue persone di contatto e qual è la loro posizione. I tuoi record esistenti potrebbero non essere accurati a tale riguardo, e non conoscere queste persone potrebbe portare a situazioni imbarazzanti.
5. Se l'ingegnere ha accesso VPN ai server dei tuoi clienti, assicurati di sapere chi sono; assicurati che il suo account sia sospeso e un nuovo account per la sostituzione sia creato in tempo.

Quando ho cambiato posizione nella prima azienda per cui ho lavorato, ho creato un foglio di lavoro che conteneva un elenco di tutto il lavoro svolto nelle righe e le colonne per:

• il progetto / prodotto che era per
• l'area specifica del progetto
• il business / project manager
• la complessità del lavoro
• a chi è stato consegnato
• se è stato consegnato, da consegnare o non ha bisogno di essere
• la data in cui è stata consegnata
• il nome di tutti i documenti per esso (che sono stati memorizzati in un article.zip di accompagnamento)
• qualsiasi commento su di esso

Questo è stato aggiornato nel corso del passaggio di consegne (e filtrato e ordinato per priorità) e alla fine è diventato una leggenda e un archivio di tutto il mio lavoro e un elenco TODO per qualsiasi documentazione / discussioni necessarie e le persone per essere sicuro felice con i passaggi di consegne.

Ho dato al mio vecchio manager in modo che loro (o chiunque altro) possano ottenere il mio lavoro / i miei documenti senza dovermi chiedere.

Mi è stato chiesto parecchie copie in bianco e sono diventato il documento informale di passaggio di fatto per qualsiasi passaggio.

Anche se, quando sono uscito come sviluppatore, ero ancora programmato per programmare fino alla mia ultima ora (ed ero in ritardo per la mia partenza per farlo), quindi sono assolutamente d'accordo con Pierre sul fermare qualsiasi nuovo lavoro per assicurarsi che il passaggio vada bene.

Considera di fare tutte quelle cose su qualsiasi grande progetto in futuro. È quello che fa la mia compagnia dopo aver imparato la lezione nel modo più duro.

Ci sono sempre almeno due paia di occhi su qualsiasi progetto di codice. In questo modo l'effetto di lasciare qualcuno è sempre limitato.

E mantenere sempre aggiornati i tuoi test / la documentazione è molto importante.