Modo migliore per addestrare nuovi assunti [chiuso]

Il team al momento faccio parte di un fatturato abbastanza elevato, con membri che generalmente si spostano su progetti diversi all'interno della stessa azienda. Attualmente la nostra "formazione" per i nuovi membri consiste nell'associarli a un contatto principale (di solito la persona più recente per completare la loro formazione) che fornirà loro esperienze pratiche e chiederà a sviluppatori senior se il nuovo assunto chiede qualcosa al mentore non lo so. Offre la possibilità al nuovo assunto di essere coinvolto rapidamente e sfida il mentore a migliorare anche la sua comprensione del sistema.

Tuttavia, come puoi immaginare, questo stile di allenamento richiede molto tempo e non fornisce un ottimo trasferimento di conoscenze (le idee sbagliate si propagano, le lacune si espandono).

Mi è stato affidato il compito di generare documentazione e materiale di formazione per i nostri nuovi assunti futuri. Di tanto in tanto scrivo anche di scrittura tecnica, ma è per l'utente finale ed è altamente specifico con molti screenshot e richiede molto tempo per il completamento.

La creazione della nuova documentazione per i nuovi assunti è considerata a bassa priorità e al momento ho solo ~ 40 ore per lavorarci. Documentare il sistema nel modo in cui scrivo la documentazione tecnica graffierebbe appena la superficie in 40 ore. Soprattutto considerando che devo documentare non solo la base di codice, ma anche le distribuzioni e il supporto.

Come posso scrivere rapidamente la documentazione per aggiornare i nuovi assunti il ​​più rapidamente possibile senza investire tempo significativo nella stesura della documentazione?

Informazioni aggiuntive: al
momento disponiamo sia di un wiki, sia di documentazione sull'addestramento, tuttavia entrambi sono piuttosto radi.

Buona domanda. La formazione sul posto di lavoro dei programmatori è molto raramente presa sul serio, né viene spesso discussa.

Alcune idee che ho visto funzionano bene:

• Nella tua wiki, disponi di un documento rampup di nuova assunzione (quello che stai scrivendo). In quel documento, descrivi le attività che il nuovo assunto eseguirà per le prime 1-2 settimane. Dove lavoro, c'è molto da sapere fin dall'inizio, da software / strumenti interni, processi, posizioni di tipi specifici di informazioni. modifica> abbiamo istruzioni come "installa x, y, z in ordine" con schermate per la configurazione ecc. Quindi, configurando un sistema o una farm (VM) con Win Server, SQL Server, SharePoint, BizTalk, il nostro software non è così semplice come suoni. Questo vale per le altre versioni di quelle applicazioni che supportiamo.
• Problemi di pratica. Dove sono, abbiamo un prodotto che espone un'API di grandi dimensioni. Quindi è sempre utile per noi esaminare la documentazione dei nostri prodotti per scrivere estensioni (predeterminate) proprio come farebbero i nostri clienti / clienti. Quindi, se avevi una libreria matematica come parte dell'API del tuo prodotto, hai un problema pratico che è "scrivere una calcolatrice usando la nostra API" o qualcosa del genere.
• I mentori sono bravi. Conservali. Lo facciamo anche qui, e non solo è un buon modo per incontrare persone / fare amicizia, ma sono preziose come fonte di apprendimento. Consiglio di non avere la persona più recente a terminare la formazione in quanto non hanno la storia delle conoscenze aziendali di qualcun altro. Chiedi a tutti di farlo su una rotazione.
• Facciamo (approssimativamente) presentazioni settimanali / conferenze tecnologiche. Chiedi ai nuovi assunti di scegliere qualcosa dal tuo prodotto (o assegnarlo) e fare una presentazione dopo la loro terza settimana. Assicurati di sapere che c'è spazio per loro di essere sbagliati e che il team può correggerli se infastidiscono qualcosa nella presentazione.
• Chiedi ai nuovi assunti di lavorare sulla documentazione all'avvio. Li costringe a leggerlo.

Come osserva Dan McGrath, è una buona idea incoraggiare nuovi assunti per migliorare il wiki anche per loro.

In primo luogo, suggerirei che non devi rendere il tuo nuovo documento di formazione per il noleggio accurato come qualcosa che scriveresti per un cliente. Deve essere abbastanza tecnico da poter essere utilizzato come guida da un nuovo sviluppatore, ma non così dettagliato da delineare ogni piccola cosa. Saranno in grado di parlare con il team se hanno domande dopo tutto.

Quali sono le 10 cose principali che un nuovo assunto deve sapere per essere utile alla tua squadra? Concentrati su queste cose. Rendili il tuo elenco di articoli di successo in modo che un nuovo sviluppatore abbia abbastanza da fare e abbastanza informazioni per farli andare avanti. Se hai troppe cose nell'elenco, chiediti se lo faranno nelle loro prime due o tre settimane. Se non faranno qualcosa in questo momento, forse non dovrebbe essere nella guida di imbarco.

Per ogni sezione della guida, assicurati che ci sia una persona di riferimento evidenziata proprio in alto. In questo modo, se il nuovo assunto ha delle domande, sa a chi rivolgersi per chiedere aiuto. Inoltre, assicurati che un membro del team non sia la persona di riferimento per troppe sezioni. Non vuoi perdere tempo con una persona con nuove domande di assunzione se non sono il mentore.

Non passare l'intera settimana su questo documento. Lasciati un po 'di tempo per aggiustarlo dopo aver lasciato passare almeno un nuovo noleggio. Guarda cosa funziona bene, cosa no e correggi.

Di recente ho iniziato con un documento simile nel mio luogo di lavoro, con vincoli temporali simili. Immagino che sia facile volerlo scrivere a un livello molto dettagliato, come ho fatto anche all'inizio, ma potrebbe essere controproducente.

Se qualcuno di nuovo inizia un ruolo, è probabile che sia inondato di informazioni per le prime settimane. Avere la loro formazione iniziale come una scarica di cervello di uno sviluppatore che è stato in una società per un certo numero di anni, nella mia mente molto di più complicherà ciò che qualcuno deve sapere per i loro primi mesi o addirittura l'anno in quella posizione. Mantenerlo ad alto livello, provare a utilizzare il gergo e i concetti standard, quindi espanderli con le specifiche all'interno dei processi dell'azienda.

Per me, la prima iterazione di questo documento è semplicemente uno schema dell'SDLC che utilizziamo nel mio luogo di lavoro, con un elenco di ruoli associati all'interno di ogni passaggio, alcuni esempi di persone che ricoprono tali ruoli e liste di controllo specifiche associate a anche ogni fase del ciclo di vita. Personalmente trovo che le liste di controllo siano indispensabili ai fini della formazione, ma anche per qualsiasi altra cosa che faccio al lavoro. Per esempio:

• Il Project Manager (Joe) ti assegna un'attività in Jira.
• Impostare un tempo di completamento stimato sull'attività in base alla formula x.
• Imposta il ticket come "in corso" quando inizi a lavorarci.
• Crea ramo da Git, fai clic sul collegamento per visualizzare un video di 30 secondi su questo progresso.
• Scrivere unit test basati sui vincoli nel documento di progettazione, vedere pagina y per le convenzioni di denominazione dei test unitari.
• Imposta il biglietto per la revisione e invia il codice per rivedere il sistema ...

Spero che il tuo nuovo dipendente abbia familiarità con la maggior parte dei concetti e che ora abbia una guida passo passo su come i processi vengono applicati in azienda. Faccio anche una breve demo del processo dall'inizio alla fine usando documenti reali di progetti che ritengo siano stati ben eseguiti.

Come accennato, è anche un documento vivente, quindi le sezioni possono essere espanse poiché viene identificato che hanno bisogno di più informazioni. L'intero team dovrebbe essere coinvolto nel mantenerlo aggiornato. Può essere un wiki, un documento OneNote, qualunque cosa, ma qualcosa che tutte le persone possono modificare e rivedere, quindi iniziare a coinvolgere altre persone nel miglioramento quando hanno un'ora di riserva qua e là. In questo modo una persona non lo sta facendo e non sta propagando il proprio giro sul processo a tutti i nuovi assunti.

Dopo aver esaminato il processo, invitali a seguire una piccola funzione / correzione di bug in un progetto non mission-critical e chiedi loro di porre domande che il documento non tratta. Registra quali sono queste domande, perché probabilmente dovrebbero essere le prime cose che aggiungi al documento la prossima volta che ci lavori.

Non puoi combinare facendo qualcosa del genere senza perdere tempo. Almeno, se vuoi farlo da solo. Dovresti chiederti se è davvero necessario documentarlo con la precisione che stai provando?

L'unica alternativa sarebbe quella di lasciare che i nuovi assunti svolgessero il lavoro principale. Lascia che scrivano alcune parti. Il tempo impiegato per correggerli (sotto forma di feedback) sarà inferiore rispetto alle situazioni attuali. Fornisci alcuni buoni modelli e non devi preoccuparti del layout.

Credo che tu sappia già che ti hanno assegnato una missione impossibile. Come scrittore probabilmente hai già familiarità con la citazione di Mark Twain:

Se avessi avuto più tempo, avrei scritto meno.

Dato praticamente nessuna risorsa, probabilmente il meglio che puoi fare è ottenere un file cabinet e chiedere a tutti di fare una copia di ciò che già hanno e metterne la copia nel file cabinet. In questo modo puoi almeno dire al nuovo assunto "Se vuoi cercare qualcosa sul sistema, il punto da cui iniziare è nel file cabinet".

La buona scrittura richiede tempo, punto. Inoltre, deve essere adattato al pubblico di destinazione. Ciò che funziona per gli utenti finali non sarà ciò di cui un programmatore ha bisogno.

Per non parlare del fatto che una buona formazione non si limita al materiale scritto, includerebbe il pieno gioco di risorse educative tra cui online, aula, multimedia ecc.

Come si suol dire, "Se pensi che l'istruzione sia costosa, prova il costo dell'ignoranza".

Inoltre, è ovvio che vedere la documentazione come qualcosa da fare dopo il fatto piuttosto che renderla parte integrante del processo sin dal primo giorno è indicativo di un problema organizzativo sistemico.