{"id":53316,"date":"2019-11-29T00:00:00","date_gmt":"2019-11-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki"},"modified":"2020-02-18T14:01:12","modified_gmt":"2020-02-18T11:01:12","slug":"chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chemu-ne-uchat-v-shkole-kak-my-gotovim-inzhenerov-tehpodderzhki","title":{"rendered":"Cosa non insegnano a scuola: come prepariamo gli ingegneri di supporto tecnico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ecco la \"storia diversa\" promessa.<\/p>\n

\"Cosa
\n<\/p>\n

Sfida
\n<\/h3>\n

\nSe mi avessero chiesto quattro anni fa: \"Come si pu\u00f2 formare i nuovi arrivati nel dipartimento IT\/azienda?\" \u2014 avrei risposto senza esitazione: \"Con il metodo 'la scimmia vede \u2014 la scimmia imita', cio\u00e8 attaccate il nuovo arrivato a un dipendente pi\u00f9 esperto e lasciate che osservi come vengono risolti i compiti tipici.\" Questo approccio ha funzionato per me in passato, funziona ancora ora, e anche qualche tempo fa in Veeam, quando gli alberi erano grandi, i loghi verdi e il prodotto piccolo, si poteva insegnare in questo modo \u2014 e si faceva!<\/p>\n

Man mano che il prodotto diventava sempre pi\u00f9 grande e complesso, aumentava il numero di nuovi ingegneri, e l'approccio in stile RTFM (Read The Freaking Manual) funzionava sempre peggio \u2014 il fatto \u00e8 che cos\u00ec possono imparare solo quelli gi\u00e0 \"nel settore\", che capiscono le specifiche del lavoro e hanno bisogno di dettagli non cruciali.<\/p>\n

E come si fa con coloro che provengono da settori affini e vogliono crescere e svilupparsi, ma non sanno come procedere? Come si fa, ad esempio, con chi parla una lingua relativamente rara (per esempio, l'italiano che \u00e8 raro per la maggior parte degli informatici)? O come formare secondo questo schema un neolaureato promettente, che non ha molta esperienza lavorativa alle spalle?<\/p>\n

Facciamo un attimo una pausa nel nostro racconto e immaginiamo: voi, team leader del team di supporto, un tempo un buon e bravo ingegnere, con grande esperienza di amministrazione di sistemi e interazione con diverse persone. Il vostro compito \u00e8 trasmettere la vostra esperienza a un nuovo (potremmo dire \"alle prime armi\") ingegnere, un neolaureato, intelligente e perspicace. C'\u00e8 solo una piccola sfida \u2014 questa persona non ha esperienza nel supporto n\u00e9 nel banale help desk, e sar\u00e0 anche il primo ingegnere di lingua turca nella vostra azienda.<\/p>\n

<\/a><\/noindex>Come affronterete questo compito?<\/p>\n

E quando avrete risposto a questa domanda (e risponderete, io credo in voi), rendiamo la questione pi\u00f9 difficile \u2014 e se ci fossero dieci di questi ingegneri? E se fossero venti? E se questo sviluppo del dipartimento fosse costante, e in qualsiasi momento ci fosse un nuovo arrivato da formare, da cui mostrare il minimo standard di qualit\u00e0 del lavoro (e questo standard \u00e8 alto) e far s\u00ec che la persona non desideri scappare il prima possibile?<\/p>\n

(Per favore, riflettete su questa domanda prima di continuare a leggere.)<\/p>\n

\"Cosa
\n<\/p>\n

La nostra storia<\/h3>\n

\n\u00c8 proprio con una sfida\/compito del genere che ci siamo confrontati. <\/p>\n

Finch\u00e9 il reparto \u00e8 stato relativamente piccolo, ha funzionato bene la strategia di \"assegnare a un neofita un mentore, una lista di documenti e lasciarlo lavorare \u2014 nuota o affonda\". \u00c8 una buona strategia, universale, testata da anni e persino secoli di esperienza umana collettiva \u2014 ma a un certo punto ci siamo resi conto che eravamo stanchi delle ripetizioni. A ogni nuovo arrivato bisogna spiegare alcune cose \u2014 le stesse che possono tornargli utili nel lavoro. Nella strategia \"tradizionale\" questo compito spetta al mentore, ma cosa succede se i protetti di un certo mentore si presentano uno dopo l'altro? Ripetere le stesse cose stanca rapidamente, si rischia il burnout \u2014 e questo \u00e8 gi\u00e0 un rischio.<\/p>\n

E qui ricordiamo un'altra strategia, non meno tradizionale \u2014 raccogliere i neofiti in gruppi e tenere loro lezioni \u2014 cos\u00ec \u00e8 nata la nostra programma di formazione.<\/p>\n

\u2026 A volte i nostri ingegneri partecipano a conferenze \u2014 sia interne che esterne, organizzate da terzi o da noi stessi. Ed \u00e8 proprio da un nostro evento che \u00e8 iniziata la formazione nel supporto, come la conosciamo oggi.<\/p>\n

Uno dei nostri ingegneri ha presentato al VeeamOn di Las Vegas una brillante presentazione sui vari componenti di Veeam Backup & Replication, e con alcune piccole modifiche \u00e8 diventata la lezione \"Componenti\". A quel punto avevamo gi\u00e0 diverse lezioni sui vari aspetti delle funzionalit\u00e0, ma \u00e8 stata quella lezione a \"dare il tono\" a tutte quelle che sono venute prima e dopo. Proprio il modo in cui quella lezione \u00e8 stata strutturata, i materiali utilizzati e altro ancora, \u00e8 diventato il nostro standard.<\/p>\n

Abbiamo iniziato a parlare molto di virtualizzazione, tecnologie Microsoft, dei nostri stessi prodotti, e abbiamo introdotto corsi base per i neofiti senza esperienza nel settore IT, nei quali spieghiamo tutto quello che un ingegnere di supporto potrebbe aver bisogno \u2014 partendo dall'\"hardware\" e aumentando i livelli di astrazione: Disk API, Sistemi Operativi, Applicazioni, Networking, Virtualizzazione.<\/p>\n

Certo, sapevamo e sappiamo che cercare di coprire con le formazioni tutto lo spettro delle tecnologie che utilizziamo sarebbe impossibile o, almeno, poco sensato. Per insegnare tutte le funzionalit\u00e0 di un solo prodotto, oggi servono gi\u00e0 diversi mesi, e il prodotto non sta fermo, emergono continuamente novit\u00e0. Inoltre, solo le formazioni-lezioni, cos\u00ec come sono, non possono fornire tutto ci\u00f2 di cui ha bisogno un futuro ingegnere.<\/p>\n

E cosa c'\u00e8 oltre?<\/h3>\n

\nMi piace dire che seguiamo la regola di Pareto: con i nostri corsi offriamo circa il 20% di ci\u00f2 che \u00e8 necessario a un ingegnere di successo, e l'80% resta a carico suo: leggere manuali, lavorare in laboratorio, risolvere ticket di test e ticket di produzione, ecc.<\/p>\n

Il 20% - corsi - in realt\u00e0, \u00e8 quasi il 100% della base teorica, ma con la sola teoria non si va lontano: funziona lo schema classico Conoscenza-Abilit\u00e0-Competenze. Possiamo fornire la Conoscenza, ma sviluppare le Abilit\u00e0 e trasformarle in Competenze \u00e8 un compito completamente diverso.<\/p>\n

Ecco perch\u00e9 molto rapidamente le nostre prime lezioni teoriche si sono arricchite di altre cose, e ora lo schema complessivo appare cos\u00ec:<\/p>\n