SE hai intenzione di sostenere la formazione, non chiedere tempo per leggere libri o lavorare su piccoli progetti. Quelle sono in effetti cose che puoi fare sul lavoro. Quando hai bisogno di scrivere del codice per fare X in un grande progetto, puoi leggere di X in un libro (o online) e fare una piccola dimostrazione di concetto (o spike, se preferisci) che fa X per familiarizzare con prima di integrarlo nel grande progetto.

Ciò che devi sostenere è una formazione effettiva. Partecipare a corsi (online, video o di persona), partecipare a conferenze, quel genere di cose. Imparare cose che non sapevi nemmeno esistessero. Essere guidati attraverso un percorso dal "mai sentito parlare" al "so come posso usarlo al lavoro" e poi farlo. La componente più costosa di questo è il tempo - giorni interi o addirittura settimane sottratti alla fatturazione - e questo è anche il più prezioso.

Prometto a tutti i miei dipendenti due settimane all'anno di formazione, ma deve essere pezzi grossi segnalabili e tracciabili. Non mezza giornata qui e due ore là. Se gli sviluppatori vogliono utilizzare la formazione online al proprio ritmo come Pluralsight (disclaimer: per chi scrivo corsi), allora dovrebbe essere abbastanza intenso. Ad esempio, completare un corso di 7 ore in meno di una settimana. Quel livello di concentrazione è la chiave per imparare davvero piuttosto che stare seduti a metà ascoltando.

Perché spendo questo tipo di denaro (due settimane di fatturazione all'anno, più le spese?) Perché il mio personale migliora, molto meglio, come risultato. Diventano anche più felici e meno propensi a passare a un altro datore di lavoro. La parte più difficile per me è stata ricordare di fare lo stesso per me stesso, ma nel 2013 ho frequentato sia ACCU ad aprile che GoingNative a settembre usando lo stesso ragionamento che applico a tutti gli altri e sono così felice di averlo fatto. Ho imparato che le cose che pensavo di poter ignorare erano effettivamente rilevanti e importanti (e come farle). Ho rafforzato le relazioni e ne ho create di nuove. Sono meglio nel mio ruolo per quelle due settimane di distanza e lo farò di nuovo l'anno prossimo.

Il carico di lavoro attuale purtroppo sarà sempre la priorità. L'ideale potrebbe sembrare che l'allenamento avvenga quando non c'è niente da fare, ma questo presenta ovvi problemi. I programmatori che non sono impegnati si allenano mentre quelli che hanno la neve per il lavoro lo perdono.

Considera anche se un programmatore inattivo che si allena da solo è addirittura desiderabile. È preferibile che l'addestramento avvenga tenendo conto di un progetto piuttosto che di una sorta di approccio sparatutto in cui stai provando varie tecnologie senza sapere quali potrebbero essere utili in futuro.

È una vendita difficile: la direzione vuole sapere quali vantaggi tangibili ci sono per i progetti che non sono ancora stati realizzati! Un'idea migliore potrebbe essere quella di esaminare i progetti e i problemi passati e poi dare un'occhiata a come le nuove tecnologie potrebbero aver aiutato.

Esistono diversi tipi di formazione e diversi modi per offrirla.

Se hai bisogno di formazione per uno strumento specifico che il tuo team sta utilizzando o vorresti utilizzare, dovrai dimostrare che:

1. Questo strumento / la tecnologia renderà l'intero team più efficiente e meno costoso e porterà vantaggi all'intera azienda in modo diretto o indiretto.
2. Imparare lo strumento / la tecnologia non è banale.
3. Gli sviluppatori ne trarrebbero vantaggio dalla formazione formale in quanto ridurrebbe gli errori introdotti durante l'apprendimento sul lavoro.

Ciò potrebbe non essere applicabile a tutti i nuovi strumenti o tecnologie, ma se la formazione formale riduce la curva di apprendimento e i possibili errori che potrebbero essere introdotto dall'approccio per tentativi ed errori spesso trovato quando qualcuno impara solo bit e pezzi quando ne ha bisogno, questo potrebbe essere un argomento forte.

Se desideri una formazione più generale, come "best practice per le applicazioni web JavaEE" o "test di unità efficaci", potresti avere più difficoltà con questo. Potresti provare un approccio meno formale, come organizzare seminari "pranza e impara" in cui gli sviluppatori ascoltano un discorso / dimostrazione durante l'ora di pranzo tenuto da uno dei loro coetanei esperto (o almeno più di chiunque altro) in il soggetto.

Questo approccio potrebbe non insegnare tanto, ma la natura informale rende più facile l'organizzazione e se la direzione è disposta a comprare la pizza e lasciare che gli sviluppatori organizzino i propri colloqui di formazione, può comunque essere efficace. Anche la direzione potrebbe apprezzare questo approccio poiché viene eseguito durante il pranzo, quindi non perdono davvero tempo di lavoro, anche se dovrebbero essere gentili e primavera per il pranzo. Inoltre, direi che è importante non rendere obbligatorie queste sessioni, ma cercare di convincere le persone a partecipare volontariamente. Offri incentivi come un quiz con premi (pizza extra o qualcosa del genere - non deve essere troppo affascinante, ma dovrebbe essere divertente).

Infine, c'è la formazione per argomenti legati al business che potrebbero essere utili ai programmatori. Ad esempio, una compagnia di assicurazioni o una banca potrebbe volere che i suoi programmatori seguano alcune sessioni di formazione di base sul lato aziendale di ciò che fa la compagnia. Questo di solito viene fatto per rendere più facile per il programmatore comprendere i requisiti aziendali e interagire con altre persone (analisti aziendali, tester, utenti finali) quando si discutono aspetti non tecnici del sistema. Di solito questo sarebbe fatto se ci si aspetta che i programmatori comprendano più delle basi assolute dell'area tematica in cui stanno programmando.

Non è una prova ma:

Dovresti chiedere alla direzione se pensano che falegnami / idraulici / elettricisti dovrebbero "imparare sul lavoro" mentre costruiscono la loro casa, o se gli ingegneri aerospaziali dovrebbero provare una nuova tecnica quando costruiscono il loro aereo.

Oppure potresti chiedere come dovrebbero innovare i programmatori quando sono in media X anni indietro rispetto allo stato dell'arte. "Voglio dire X anni fa, non c'erano iPhone / Facebook / Internet!" "Guarda il concorrente Y, pensi che abbiano imparato a realizzare il [nuovo prodotto Z] sul lavoro?"

Diffido dei programmatori che affermano di aver bisogno di essere "addestrati" per fare qualcosa - dovresti essere in grado di ricercare e risolvere praticamente qualsiasi problema - questo è il tuo lavoro.

Inoltre, sono ancora PIÙ diffidente nei confronti del management che non riconosce il fatto che esporre gli ingegneri a concetti, linguaggi, biblioteche, modelli e comunità li mantiene freschi, curiosi, felici e produttivi.

Se la gestione davvero ha bisogno di un motivo di lavoro, potrebbero guardare alcune grandi aziende di successo (Google, Microsoft, Amazon, ...) e considerare quanto spendono per questo tipo di attività e perché.