Modo migliore per formare nuovi assunti [chiuso]

Buona domanda. L'addestramento sul posto di lavoro del programmatore viene preso molto sul serio, né si parla spesso.

Alcune idee che ho visto funzionano bene:

• Nella tua wiki, hai un nuovo documento di recupero (quello che stai scrivendo). In quel documento, descrivi i compiti che il nuovo noleggio eseguirà per le prime 1-2 settimane. Dove lavoro, c'è molto da sapere dall'inizio, dai software / strumenti interni, ai processi, alle posizioni di specifici tipi 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 sembra. 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 passare attraverso la documentazione dei nostri prodotti per la redazione di estensioni (predeterminate) esattamente come farebbero i nostri clienti / clienti. Quindi se hai una libreria matematica come parte dell'API del tuo prodotto, hai un problema di pratica che è "scrivi una calcolatrice usando la nostra API" o qualcosa del genere.
• I mentori sono bravi. Tienili. Lo facciamo anche qui, e non solo è un buon modo per incontrare persone / fare amicizia, ma sono inestimabili come fonte di apprendimento. Raccomando non che sia la persona più recente a terminare la formazione in quanto non hanno la storia della conoscenza aziendale che potrebbe essere qualcun altro. Chiedi a tutti di farlo a rotazione.
• Facciamo (approssimativamente) presentazioni settimanali / talk tecnici. Chiedi ai nuovi assunti di scegliere qualcosa dal tuo prodotto (o assegnarlo) e di fare una presentazione dopo la terza settimana. Assicurati che sappiano che c'è spazio per sbagliare e che il team può correggerli se inculano qualcosa nella presentazione.
• I nuovi assunti lavorano sulla documentazione quando iniziano. Li costringe a leggerlo.

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

Per prima cosa, ti suggerisco di non dover rendere il tuo nuovo documento di formazione per il noleggio più completo di quello che scrivi per un cliente. Deve essere abbastanza tecnico per consentire a un nuovo dev di essere in grado di utilizzare come guida, ma non così dettagliato da delineare ogni piccola cosa. Dopo tutto, potranno parlare con il team se hanno domande.

Quali sono le 10 cose principali che un nuovo noleggio deve sapere essere utile alla tua squadra? Concentrati su queste cose. Rendili la tua lista di elementi in modo che un nuovo dev abbia abbastanza da fare e abbastanza informazioni per mantenerli in vita. Se hai troppe cose nella lista, chiediti se lo faranno nelle prime due o tre settimane. Se non faranno qualcosa in questo momento, allora forse non dovrebbe essere nella guida di bordo.

Per ogni sezione della tua guida, assicurati che ci sia una persona giusta in alto. In questo modo, se la nuova assunzione ha qualche domanda, sanno a chi rivolgersi per chiedere aiuto. Inoltre, assicurati che un membro del team non sia la persona giusta per troppe sezioni. Non si vuole prendere tempo con una persona con nuove domande di noleggio, se non sono il mentore.

Non trascorrere la tua intera settimana su questo documento. Lasciare un po 'di tempo per regolarlo dopo aver lasciato passare almeno un nuovo noleggio. Guarda cosa funziona bene, cosa no e cosa aggiusta.

Recentemente ho iniziato a lavorare su un documento simile sul mio posto di lavoro, con limiti di tempo simili. Mi rendo conto che è facile volerlo scrivere ad un livello molto dettagliato, come ho fatto anche io all'inizio, ma potrebbe essere controproducente.

Se qualcuno di nuovo sta iniziando in un ruolo, è probabile che sia inondato di informazioni per le prime diverse settimane. Avere la loro formazione iniziale essere una discarica cerebrale di uno sviluppatore che è stato in una compagnia per un certo numero di anni, nella mia mente è molto più complicato di quello che qualcuno ha bisogno di sapere per i loro primi mesi o addirittura anni in quella posizione. Mantieni il livello più alto, prova a utilizzare termini e concetti standard e quindi espandi le informazioni con le specifiche dei processi aziendali.

Per me, la prima iterazione di questo documento è semplicemente una descrizione dell'SDLC che utilizziamo nella mia sede di lavoro, con un elenco di ruoli associati a ciascun passaggio, alcuni esempi di persone che soddisfano tali ruoli e specifici liste di controllo associate a ogni fase del ciclo di vita pure. Personalmente trovo che le liste di controllo siano indispensabili ai fini della formazione, ma anche di qualsiasi altra cosa che faccio al lavoro. Ad esempio:

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

Il tuo nuovo dipendente dovrebbe possibilmente avere familiarità con la maggior parte dei concetti e ora ha una guida passo passo su come i processi vengono applicati all'azienda. Inoltre faccio una rapida 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 ampliate in quanto viene identificato che hanno bisogno di maggiori informazioni. L'intero team dovrebbe essere coinvolto nel tenerlo 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 migliorarlo quando hanno un'ora di ricambio qua e là. In questo modo una persona non lo sta facendo e propagando la propria rotazione sul processo a tutti i nuovi assunti.

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

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

L'unica alternativa sarebbe lasciare che i nuovi assunti facciano il lavoro principale. Lascia che scrivano alcune parti. Il tempo che impieghi per correggere questi (sotto forma di feedback), sarà inferiore rispetto alle tue attuali situazioni. Fornisci alcuni buoni modelli e non ti devi preoccupare del lay-out.

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

If I had more time, I would have written less.

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

Una 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 ai materiali scritti, ma includerebbe il pieno gioco di risorse educative tra cui on-line, aula, multimedia ecc.

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

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