Ci sono molti corsi su come formare le persone, alcuni online, altri da istituti di apprendimento del mondo reale. Non credo che tu abbia tempo per questo.

Quindi, iniziamo con un corso accelerato di 10 minuti.

1. Documenta i processi : Il punto di partenza sarà la documentazione del prodotto. Ogni passaggio dettagliato, ogni riferimento, ogni tecnologia aggiuntiva da cui si blocca. Prendilo su carta.
2. Stabilisci una linea di base : stabilisci un livello minimo di abilità che deve essere soddisfatto per comprendere i tuoi documenti. Ad esempio, la consegna del supporto app può richiedere conoscenze C #, abilità SQL, Cobol ... Stabilire una linea di base elencando il livello di abilità di base per ciascuna tecnologia. Non dimenticare Windows, alcune persone sono idiote.
3. Sviluppa un piano : una volta che hai la tua linea di base, inizia a inserire la tua documentazione in un piano di formazione. Ci vorrà tempo. Inizia con i concetti più semplici e costruisci su di essi. Ricorda, stai scrivendo questo partendo dal presupposto che un imprenditore potrebbe entrare e mettersi a correre dopo l'incidente del tuo autobus.
4. Provalo : verifica la tua formazione su qualcuno. Troveranno i buchi che hai trascurato. Correggi i buchi, risciacqua, ripeti.

Come per tutto, ogni passaggio può essere suddiviso in passaggi più dettagliati. Avere un google / bing per scrivere documentazione tecnica, creare pacchetti di formazione, ecc.

In quanto specialista dei dati, sarei estremamente infastidito se qualcuno volesse provare a trasformarmi in uno sviluppatore di applicazioni per il fattore bus. Questo è solo miope da parte della tua direzione. È come chiedere a un contabile di formarsi per fare risorse umane. Ne parlo solo perché è probabile che tu debba affrontare la resistenza di queste persone. Ne parlo anche perché non sono inesperti, hanno una professione completamente diversa e se li tratti come inesperti e stupidi, si imbatterà nella tua formazione e creerà problemi.

Credo che il primo il passo è identificare le cose che molto probabilmente avranno bisogno di essere in grado di fare e documentarle in un Wiki. È improbabile che vogliano che queste persone creino cose da zero, ma che risolvano i problemi e mantengano le cose insieme fino al tuo ritorno o assumono un nuovo sviluppatore di applicazioni. Se questo è vero, valuta ciò che vuoi dire loro fino alle cose più importanti. Fai un elenco dei problemi di produzione più comuni e quindi crea un foglio di riferimento per ogni problema su cosa fare per risolverlo.

Insegna loro cose come come interpretare i messaggi di errore e come trovare informazioni in qualunque registrazione stia facendo il tuo sistema e quando riavviare il server e cosa sarà influenzato se lo fai. Insegna loro i tuoi standard di codifica. Insegna loro dove è memorizzato il codice nel controllo del codice sorgente e come usarlo (mentre penso che la maggior parte del lavoro sul database dovrebbe essere nel controllo del codice sorgente, non è in molti posti, quindi potrebbero non sapere come usarlo). Fornisci loro un elenco. di qualsiasi nome di server e password applicabili e assicurati che dispongano dei diritti appropriati per lavorare su quei server.

Trova un contatto locale per un luogo in cui sono disponibili sviluppatori freelance. Assicurati che la tua azienda sappia che possono ottenere supporto da queste persone se il problema è al di là delle capacità del personale addetto ai dati. Tu, le persone che si occupano dei dati e, in ultima analisi, i tuoi dirigenti saranno più felici se esiste un piano di riserva. Le possibilità che tu possa trasformare queste persone in sviluppatori di applicazioni in breve tempo sono basse. Il meglio che puoi sperare è che possano risolvere problemi semplici e sanno dove si trova tutto e possono spiegare l'attività a un libero professionista per cose complicate.

Documenta tutto ciò che puoi. L'obiettivo è che le persone possano trovare ciò di cui hanno bisogno per svolgere il lavoro se non ci sei tu.

Suggerirei anche di avviare un processo di revisione del codice con queste persone. In questo caso, non si tratta tanto di trovare problemi di codice, quanto di familiarizzare con il tuo codice più recente e le sue esigenze, il tuo stile di codifica ei tuoi processi di pensiero sul tuo design. Lungo la strada per spiegare loro le cose, probabilmente noterai alcuni bug che non avevi notato.

Quando hai un problema di produzione comune da affrontare dopo aver esaminato i problemi più comuni in un corso di formazione sessione, chiedi loro di seguirti e documentare ogni passo che fai. Assicurati di chiarire loro che incoraggi le domande. Se fanno la documentazione, saranno più propensi a scriverla nel modo che è meglio per loro capire. Persone diverse hanno stili di apprendimento diversi e in pratica stai creando un Wiki che sarà loro più utile di te. Quindi lascia che siano loro a decidere come organizzarlo.

Se i loro compiti impediscono loro di seguirti, allora fai tutto il wiki da solo mentre lavori sui problemi mentre sono freschi nella tua mente.

Per alcuni semplici problemi, dopo che ti hanno seguito e che i passaggi sono stati documentati, fai in modo che eseguano i passaggi mentre li ombreggi. Ciò darà loro più fiducia che possono effettivamente svolgere il compito. Questo è quello che abbiamo fatto quando di recente abbiamo convertito alcuni sviluppatori di applicazioni in specialisti di dati.

La filosofia di insegnamento di base dovrebbe essere

• Identificare ciò che deve essere formato concentrandosi sui problemi più comuni
• Assicurarsi che abbiano accesso alle cose hanno bisogno di accedere per risolvere i problemi
• Crea documentazione
• Segui i passaggi per eseguire l'attività
• Chiedi loro di seguirti e di creare documentazione supplementare che soddisfi le loro esigenze
• Shadow mentre eseguono l'attività utilizzando la documentazione mentre sei disponibile per aiutarli a uscire dai guai, se necessario.

Un paio di anni fa mi trovavo in una posizione molto simile: autodidatta, unico proprietario di decine di servizi utilizzati da centinaia di persone, alto fattore bus. La tua domanda descrive esattamente la mia situazione nel 2014.

Molte di queste risposte sembrano suggerire la documentazione, ma questo non era un buon piano per me: i miei servizi sono cambiati rapidamente , poiché velocemente perché le riorganizzazioni o i cambiamenti delle politiche potrebbero avvenire. La documentazione è nota per essere lenta da realizzare e quasi immediatamente obsoleta. Non è stato un inizio per me provare a mettere insieme retroattivamente le pagine delle specifiche che spiegavano il verbale. E le uniche persone a leggerlo sarebbero le persone sottoqualificate che venivano ad aiutarmi, che finivano sempre per chiedermi di chiarire quello che avevo scritto comunque.

Ho affrontato questo problema in un paio di modi.

1. Non provare a mettere insieme una serie di masterclass: sei impegnato. Sei l'unico che può fare il tuo lavoro, quindi il tuo tempo è prezioso. Invita le tue nuove persone a seguirti / accoppiarti mentre esegui il debug di un problema o implementa una funzionalità minore. Non aspettare che arrivi "l'insetto giusto", prendi semplicemente uno dei tuoi e mettili a sedere mentre racconti quello che stai facendo. Ti rallenterà, ma non tanto quanto il tentativo di mettere insieme presentazioni - e dà loro un'esperienza diretta. L'accoppiamento è stato (per me) l'uso più prezioso del tempo per la formazione: mette in piedi nuove persone molto rapidamente rispetto ai documenti wiki.

2. Capisci che non in grado di insegnare loro tutto. È meno importante che capiscano riga per riga ogni lezione che hai fatto e più importante che capiscano la geografia del codice: se capiscono a quale file di codice andare per scoprire come funziona qualcosa, questo li aiuterà molto più di una presentazione approfondita che approfondisce una cosa specifica.

   Soprattutto se i tuoi dipendenti sono DBA di mestiere, probabilmente capiranno prima la logica in termini di schemi e funzionalità secondo. Prova a identificare alcuni percorsi di dati principali. La maggior parte delle applicazioni prende i dati da una o due fonti principali e li modifica su richiesta dell'utente. Se riesci a identificarlo, spiega quanto più possibile di questo datapath ai tuoi sviluppatori. Esamina fisicamente (in un adebugger) cosa succede quando un utente fa una richiesta, da dove provengono i dati, quali classi sono responsabili del caricamento / salvataggio, se hai delle cache, mostra dove vivono e quale dovrebbe essere la loro freschezza.

3. Suddividi la conoscenza. Non insegnare loro le stesse identiche cose: se non è una parte importante dei tuoi servizi, non aver paura di distribuirlo a persone diverse. Questo sfrutta il fatto che avranno bisogno di tempo per assorbire ciò che imparano, ma puoi insegnare molto più velocemente di quel tempo di assorbimento. Inoltre, consente loro di concentrarsi su un pezzo più piccolo dell'immagine, anche se è ancora un pezzo grande. Non devi metterli in silo, ma dividere e conquistare lo spazio problematico è utile.

4. Probabilmente hai alcuni refactiani che avresti voluto fare per un po ' - qualche servizio scadente che è davvero difficile anche per te da eseguire il debug. Falli. E come sempre, prendi uno dei tuoi collaboratori verso la fine per mostrare loro come funziona il sistema refactoring.

5. Parla con loro , non lasciare ti danno la gentilezza che stanno seguendo. Saranno persi e confusi. Butta via alcune frasi come "So che era molto da comprendere, è piuttosto complicato. Qualcuno di questo non aveva senso?" e cerca di invitarli a fare domande il più possibile: non puoi insegnare loro se non sai cosa stanno assorbendo.

   Inoltre, se passano e ti fanno una domanda, questa è la tua massima priorità , anche se li guarda e dice "Sto andando a una riunione in questo momento, probabilmente durerà 30 minuti, ti troverò dopo".

6. Dopo aver passato un po 'di tempo a mostrare loro le corde, trova qualcosa da consegnare loro. Alcuni compiti non urgenti che stai bene con loro che richiedono una settimana o più per essere completati. Pianifica gli accoppiamenti con loro per vedere cosa hanno e dove stanno andando con esso - ovviamente correggili e dai loro indicazioni su come programmare mentre ci sei (cose come "potresti usare un foreach qui").

7. Revisioni del codice. Chiedi loro di inviarti le differenze (o di utilizzare un sistema di revisione del codice) e di esaminarle. Non "valutare" le recensioni, ma solo notare dove si trovano gli errori o descrivere come migliorare. Se non ci sono bug, non impedire loro di contribuire con il codice (non farli sentire esclusi da te), ma assicurati che ci sia un elemento da controllare e pulire immediatamente.

Ancora più importante, poiché il tuo team sta ovviamente crescendo e non hai menzionato l'intenzione di smettere, ora è il momento di iniziare a fare sul serio sulla qualità del codice. Da qui in poi peggiorerà solo, quindi ogni classe e metodo che tu (e loro) modificherai d'ora in poi dovrebbero ricevere un commento autodoc. Se non lo hai già fatto, inizia a modulare il tuo codice e prova a suddividere i metodi che funzionano per centinaia di righe e districare le classi nidificate.

Crea la documentazione per iniziare, procedure passo passo di ciò che vuoi insegnare con spiegazioni di dettagli dove necessario.

Questo crea un riferimento di base su cui puoi costruire e rispondere a domande ed è probabilmente l'aspetto più importante. Ha anche il grande vantaggio di concentrare le tue conoscenze in un modo che potresti non aver provato prima. Sicuramente lo trovo utile anche per me stesso, perché molte cose che faccio sono piuttosto complesse e mi evita di ripensare a una serie di passaggi se l'ho fatto prima.

Il resto è fondamentalmente elaborare questo materiale di riferimento aggiungendolo o modificandolo mentre procedi. Senza di esso salterai qua e là senza gettare le basi adeguate. Metà di ciò che hai insegnato verrà dimenticato rapidamente e potresti perdere molti passaggi supponendo che capiscano quando in realtà si sono persi mezz'ora prima e non hanno idea di cosa stai parlando.

Sembra che i tuoi colleghi abbiano conoscenze tecniche generali ma non siano esperti nelle tecnologie specifiche di cui hai bisogno. Questa sembra una grande opportunità per corsi online come Plurarsight o Egghead.

La verità è che la maggior parte di noi non è un grande insegnante perché essere un insegnante è un insieme di abilità diverso da quello con cui siamo normalmente formati. Perché invece creare piani di lezione per le basi della tecnologia quando ce ne sono molti che sono già disponibili?

Hai detto che la direzione vuole vederti preparare un piano, quindi che ne dici di chiedere alla direzione un abbonamento a Pluralsight e poche ore ogni settimana durante uno dei corsi? In questo modo hai

1. un programma di lezioni di alta qualità su cui non hai dovuto dedicare tempo.
2. È completamente esterno, quindi non c'è alcun fattore di bus per l'insegnamento .
3. Un ambiente aperto in cui le persone possono porre domande e collaborare.
4. Un'opportunità per i tuoi colleghi di apprendere autonomamente nel proprio tempo.
5. Un'opportunità per rispolverare le nozioni di base che potresti aver perso o su cui sei stato leggero.

Se quello che sto leggendo è vero - che sei l'unico sopravvissuto della conoscenza - la tua sicurezza sul lavoro potrebbe essere in gioco, nel senso che potresti essere arginato se lo fai e arginato se non lo fai posizionare il trasferimento delle conoscenze.

So che l'azienda per cui ho camminato ha riconosciuto una situazione in cui tutte le loro uova erano in un unico paniere (abilità tecnica) e ha deciso di terminare un progetto e tagliare un'unità / divisione aziendale piuttosto che cercate di tirarvi fuori da un buco in cui non sarebbero mai dovuti entrare. Il talentuoso sviluppatore principale è stato licenziato quando è diventato chiaro che le tecnologie impiegate erano state sostituite e il rapporto costi-benefici del mantenimento di una capacità non valeva la pena.

La vera domanda è ... (indipendentemente da qualsiasi problemi di controllo della qualità - dal momento che sembra che l'azienda abbia poco da perdere in questo momento al momento) - può l'azienda imbrogliare tutti voi - portandovi tutto off-shore utilizzando più personale che costa una piccola frazione del presente?

Se "sì", allora il tempo stringe per te, potrebbe essere ogni uomo / donna per se stesso, quindi sarei più interessato alla tua riqualificazione.Reskilling come lead knowledge management HR / trainer (se puoi convincere l'azienda a pagare per questo) può essere una buona rete di sicurezza.

Se la risposta a questa domanda è stata "no", allora ti auguro buona fortuna con il timone, perché se il la gestione strategica della tua azienda è spietata quanto uno dei miei ex datori di lavoro: potresti averne bisogno.

Supponendo che vogliano imparare, portali a un corso introduttivo alle tecnologie / linguaggi / ecc. che stai utilizzando. Non deve essere fantasia, solo qualcosa per farli iniziare. Il denaro dell'azienda è molto meglio speso per convincere qualcuno che è un insegnante professionista a insegnare professionalmente piuttosto che ad ingaggiarti nel ruolo.

Personalmente imparo molto meglio facendo che chiedendomi a qualcuno. La programmazione è un mestiere e un'abilità, non una questione di memoria meccanica. Dovresti farlo anche con loro. Non entrare in una sala riunioni con loro e parlare per ore. Tira fuori i computer e fai una vera programmazione.

Inizia in piccolo, davvero in piccolo. "Scrivi questa piccola app", "modifica questo piccolo script". Modifiche semplici con un inizio e una fine definiti che dovrebbero richiedere solo poche ore. Le prime volte siediti con loro e segui il processo. Potresti anche prendere in considerazione la programmazione in coppia o simili. Chiedi loro di seguirti per un giorno e di iniziare a fare il lavoro, ma ogni volta che lo segui chiedi loro di farlo sempre di più mentre dai consigli e alla fine guarda.

Nient'altro che l'esperienza sta andando per dare loro esperienza. Quindi la cosa migliore che puoi fare è dare loro questa opportunità fornendo allo stesso tempo una guida e proteggendo l'azienda da eventuali errori.

In quanto persona in una posizione leggermente simile, non posso enfatizzare abbastanza per documentare sia i processi che il codice e mantenerli aggiornati. Anche se esiste già la documentazione, non fa male riscriverla ed evidenziare passaggi che potrebbero non essere chiari o che sono cambiati nel tempo. Dovresti farlo indipendentemente dal fatto che tu sia responsabile dell'allenamento, nel caso in cui vieni investito da un autobus.

Inizia documentando i tuoi processi regolari. Scrivi uno schema e inserisci i dettagli.

Se è coinvolta una codifica, assicurati che ci sia almeno una serie di standard di base che tutti capiscano e seguano.

Assicurati di condividere i documenti con i tuoi colleghi prima di programmare la formazione, in modo che possano rivedere e porre domande.

Per quanto riguarda la formazione stessa, una cosa che ho fatto in passato è stata di sedermi e di seguire i miei colleghi mentre svolgono il lavoro.

L'insegnamento è un insieme di abilità completamente diverso: ci vorrà molto tempo e molta pratica per diventare bravo. Penso che la soluzione migliore sia ridurre il lavoro per te stesso.

Hai detto che la direzione vuole principalmente che tu dimostri che ci stai provando, il che è positivo. Tuttavia, sono certo che a te e ai tuoi colleghi non piaccia sprecare il loro tempo, quindi probabilmente dovresti cercare di rendere gli sforzi che spendi proficui.

Se fossi nei tuoi panni, la prima cosa che ho farebbe è incontrare i tuoi colleghi e chiedere loro cosa sono interessati a imparare. Ciò ridurrà di molto la quantità di cose che potresti insegnargli. Avrai anche un'idea di quali pensano siano i loro punti di forza e di debolezza e come questo si accorda con la tua percezione. Questo ti darà ciò di cui hai bisogno per progettare il primo "corso". Considera l'idea di incontrarti uno a uno, se possibile, poiché le persone saranno più oneste.

Per il tuo primo corso, non arrivare troppo in alto. Usando ciò che hai imparato dai tuoi primi discorsi, metti insieme un elenco dei 1-3 concetti o abilità più importanti che dovrai insegnare loro. Se sono brevi, vai con 3, altrimenti rimani con uno. Quindi, pensa di dedicare circa un'ora a insegnare loro queste cose. Immagina di sapere tutto quello che sanno sull'argomento. Di quali informazioni avresti bisogno per apprendere l'abilità o il concetto? Quali esercizi ti aiuterebbero a metterli in pratica? Crea una breve lezione e un esercizio di esempio per ogni argomento. Crea anche un breve compito di "compiti a casa" per fare pratica.

Per fare tutto questo ci vorranno un paio di giorni, così puoi capire perché è importante limitare il più possibile il tuo ambito. Dopo il tuo primo "corso", avrai una migliore comprensione di quali sono i tuoi punti di forza e di debolezza in termini di insegnamento. Ora la tua missione è lavorare sui punti deboli continuando a progettare e insegnare corsi brevi modellati su ciò che ha funzionato nel primo.

Mentre segui questi corsi, mantieni gli appunti organizzati. Questi diventeranno la tua documentazione. Man mano che migliorerai nell'organizzazione e nella comunicazione delle informazioni, la documentazione migliorerà e renderà anche più facile l'insegnamento.

Sarà difficile insegnare a te stesso come insegnare, ma in realtà hai un vantaggio nell'essere te stesso sviluppatore imparato - sai di cosa hai bisogno per imparare a essere bravo nel tuo lavoro. Molte persone che hanno avuto solo buoni insegnanti non imparano mai a capirlo da sole. Lo svantaggio è che anche tu non conosci molte delle tecniche di insegnamento standard o dei modi per strutturare la formazione, quindi dovrai imparare quella parte mentre procedi. Cercherò i libri di testo standard in qualsiasi lingua o area in cui lavori. Questo ti darà esempi di come strutturare la conoscenza.

Buona fortuna!

La maggior parte delle risposte sembra presupporre che i soggetti vogliano imparare (ad esempio Tim B). Vorrei fare un passo indietro e confermare questa ipotesi, prima di capire il "come". Quando gli studenti sono disimpegnati e demotivati, la formazione non sarà efficace, non importa quanto sia buona, specialmente in una disciplina pratica in cui la pratica è assolutamente essenziale per l'acquisizione di conoscenze e un uso efficace.

Presumo che l'obiettivo sia che questi sviluppatori di db diventino abili al punto da riempire le tue scarpe, se necessario. È stato chiesto loro se questo suona come un ottimo piano o hanno sollecitato in modo proattivo una formazione in queste aree? La consapevolezza di un'esigenza aziendale e l'atteggiamento proattivo verso la realizzazione sono cose diverse, che richiedono un diverso mix di condizioni per sostenerle. Quindi, sebbene questi sviluppatori possano annuire quando l'argomento viene affrontato dalla direzione durante le riunioni, possono essere passivi nella migliore delle ipotesi, o anche apertamente resistenti quando si tratta di apprendimento effettivo e cambiamento di comportamento (come obiettivo).

Ecco sono alcuni vantaggi significativi nel fare un passo indietro e nel confermare la motivazione ad apprendere prima di iniziare effettivamente con le soluzioni:

1. Adattare le aspettative e l'approccio: se gli sviluppatori sono demotivati ​​ed è probabile che lo siano discenti passivi, richiederà un approccio formativo, mentre se sono proattivi al riguardo l'approccio sarebbe diverso (ad esempio, meno supervisione / tenuta di mano richiesta, diversa struttura di incentivi / monitoraggio dei progressi, più o meno autonomia data agli studenti, più o minore flessibilità richiesta in termini di scelta degli argomenti, ordine degli argomenti, modalità di presentazione, ecc.).

2. Risparmiare tempo / fatica assicurando che la strategia di formazione adottata corrisponda alle esigenze e agli obiettivi degli studenti per la formazione (ad esempio, evitando di spendere tempo / denaro per creare sussidi per il lavoro o iscriverli a corsi online, solo per vedere un uso minimo /progresso). Quando le persone non vogliono fare qualcosa, tendono ad eccellere nel trovare scuse creative e giustificazioni per non farlo (ad esempio carico di lavoro, diversi stili di apprendimento). Può essere difficile se non impossibile discernere quali di queste scuse sono valide e quali no.

3. Partire con il piede giusto. Un ottimo modo per garantire che la formazione fallisca è richiederla (forzarla) ai partecipanti. D'altro canto, un ottimo modo per massimizzare il ROI sulla formazione è creare una struttura di incentivi tale che i partecipanti siano intrinsecamente motivati ​​a coinvolgere il materiale (cioè auto-guidati ad apprendere per il bene dell'apprendimento, come quando sono sinceramente interessati a il soggetto). In quest'ultimo caso, i partecipanti adatteranno da soli il contenuto al loro stile di apprendimento, lo inseriranno nei loro programmi, stimoleranno l'apprendimento in modo appropriato, ecc. Il miglior tipo di studente è colui che prende tutte queste decisioni individualizzate per se stesso, con forse qualche consiglio / consiglio dall'esterno (quando ne hanno bisogno). Pensa solo a quanto mal di testa questo può farti risparmiare e quanto credito puoi prenderti per convincere queste persone a imparare da sole - se riesci a ottenere un apprendimento così auto-motivato da parte loro (che può essere o meno possibile).

Spero che questi pensieri ti aiutino a pensare in modo più ampio a ciò che sta (o non sta succedendo) in termini di modo in cui la formazione viene presentata e strutturata, a apportare alcune modifiche che aiuteranno a massimizzare la sua efficacia a lungo termine. Buona fortuna!

Molte buone idee. Finora, non ho visto alcun consiglio sullo sviluppo di alcuni piccoli video utilizzando strumenti di cattura dello schermo. Documenta i processi utilizzando PSR.exe, molte persone non conoscono questo strumento ma è integrato in Microsoft O / S. È un tutorial sullo schermo che puoi annotare.

Non dare per scontato nulla sulla loro conoscenza. Convalidalo. Invece di dire che non sono qualificati, lascia che sia un'autorità rispettata a spiegarglielo. Microsoft, Brainbench, sono sicuro che ci sono più fornitori di test in giro. Brainbench mostrava le aree deboli e forti, così come il punteggio del test e dove ti trovi: tutto questo può essere utilizzato. Fare un test standardizzato è importante in quanto elimina il fattore soggettivo.

Una volta presa la linea di base, non allenare le abilità di base. Lascia che gli altri lo facciano per te. I corsi online, come Udemy, Pluralsight e altri, possono aiutare tutti a raggiungere la linea di base. Questo è molto più economico di qualsiasi altra alternativa. E potrebbero fare un lavoro migliore per due motivi:

• Potresti essere obsoleto di un paio d'anni. Quando ti sarai allenato tutti, il divario sarà maggiore. Per rimanere all'avanguardia della tecnologia, devi smettere di fare affari, la maggior parte delle persone non può permetterselo.

• Sanno come addestrarsi. E sì, c'è la scienza dietro l'insegnamento. Non puoi semplicemente trasferire la conoscenza nel cervello di qualcun altro tramite USB. Né puoi parlarne e sperare che il tuo studente ricordi qualcosa. È coinvolta molta psicologia.

Se vuoi aumentare le possibilità di successo, cerca e scegli i corsi per loro. C'è molta spazzatura disponibile online, sfortunatamente.

Passaggio successivo (o puoi farlo in parallelo) - Documenta ciò che sai sulle applicazioni che hai costruito ad alto livello. Supponi di dover spiegare a un altro sviluppatore come te che conosce lo stack, molta esperienza, inclusi i trucchi più recenti, ma che è appena entrato in azienda e non sa nulla del tuo codice.

Inizia a sondare le persone se la tua documentazione ha senso. Lascia che facciano domande. Aggregato, vedi quale area solleva le maggiori preoccupazioni. Entra nei dettagli lì. Risciacquare, ripetere.

C'è una risposta diversa al problema del "fattore bus". Se succede qualcosa (preferirei pensare a te che vinci alla lotteria e decidere di smettere sul posto, non a un incontro con un vero autobus), certo, la compagnia è in una brutta situazione. Ma le cose andranno avanti per un po 'senza di te, e questa è la situazione in cui ottieni un appaltatore per una soluzione a breve termine e successivamente assumi un nuovo sviluppatore con l'esperienza appropriata.

Certo, dovranno pagare un bel po 'di soldi per un buon imprenditore che può subentrare al tuo lavoro. Ma qualcuno che è davvero bravo in questo non avrà problemi a sostituirti. E dopo alcuni mesi lascia le cose in buone condizioni per uno sviluppatore medio a subentrare. Riqualificare i tuoi colleghi per essere in grado di svolgere un lavoro che molto probabilmente non faranno mai sarà costoso e non molto utile.

Assicurati solo che non ci sia nulla nella tua mente e da nessun'altra parte. Procedure che devono essere seguite per far funzionare le cose. Password necessarie (e che non dovresti scrivere). E invece di documentare le cose, quando fai cose in cui le procedure devono essere seguite, chiedi al tuo capo di darti una segretaria per alcune ore che annoti esattamente tutto ciò che fai, e che è rigorosamente istruita a non tralasciare dettagli.

Invitali a svolgere il tuo lavoro per un po '.

Ad esempio, se il tuo lavoro come sviluppatore di applicazioni è sviluppare un'applicazione, assegna loro i prossimi compiti di sviluppo dell'applicazione. p>

Di 'loro che:

• Vuoi che facciano il lavoro
• Sei disponibile a rispondere alle loro domande
• Ti aspetti si assumano la responsabilità di farti domande

Perché:

• Non sai cosa non sanno (che devi dire loro); quindi, invece di indovinare cosa dire loro, è più efficace se ti dicono ciò che non sanno e vogliono sapere (facendo domande).
• Richiede loro di voler fare il lavorare e impegnarsi a capire come.
• Garantisce che tutta la formazione sia pertinente all'attività da svolgere: che sia necessaria e sufficiente.

Dato che tu sei in grado di svolgere il lavoro, presumibilmente sei in grado (se richiesto) di spiegare qualsiasi aspetto specifico di esso in ogni dettaglio.

Aspettati che questa (formazione) richieda del tempo. Si spera che la direzione se lo aspetti e che sia d'accordo. Quando ho aiutato (formato) i nuovi assunti in questo modo, ho approssimato che mi ci sarebbe voluto tanto tempo per spiegare un compito in dettaglio quanto avrei dovuto completarlo effettivamente da solo; ci è voluto anche più tempo che per il nuovo assunto. Ad esempio, un lavoro (ad es. Una nuova funzionalità) che potrebbe richiedere tre giorni per essere svolto da solo mi richiederebbe tre giorni per spiegare in dettaglio e richiedere al tirocinante un paio di settimane.

, o tempo risparmiato), quindi, non è immediato: il guadagno è mesi dopo, quando il nuovo assunto è pronto ed è in grado di lavorare più o meno in modo indipendente.

Oh sì, oltre a convincerli a fare domande ad hoc , dovresti fare revisioni / ispezioni del codice di tutto ciò che finiscono. Quando dicono che sono pronti per una revisione del codice, la tua prima domanda potrebbe essere "L'hai testato?" Nella tua revisione del codice cerchi bug evidenti. La chiarezza ideale a cui mirare è che il codice è completo non quando "non ha bug evidenti" ma quando "ovviamente non ha bug".

Le tue critiche alla revisione del codice dovrebbero essere:

• Deve essere risolto immediatamente, prima del check-in (ad esempio un bug, non soddisfa i requisiti o non può essere mantenuto)
• Opzionale (ad esempio "Vedo cosa hai fatto e non è un bug, ma FYI l'avrei fatto in questo modo ")

Impara a insegnare

Sei un programmatore di computer, non un insegnante, tuttavia, c'è stato un tempo in cui non eri un programmatore di computer. Proprio come hai imparato a fare il primo, puoi imparare a fare il secondo.

Parla con la tua azienda di fornirti istruzione su come istruire gli altri.