Cosa non insegnano a scuola: come prepariamo gli ingegneri del supporto tecnico

Ecco la tanto attesa “altra storia”.

Sfida

Se quattro anni fa mi avessero chiesto: “Come si possono formare i neofiti nel dipartimento IT/azienda?” — avrei risposto senza pensarci: “Con il metodo dell'“unisce osserva e imita”, cioè accompagna il neofita a un dipendente più esperto e lascia che osservi come vengono svolti i compiti tipici”. Questo approccio ha funzionato per me in passato, funziona ancora oggi, e anche un po' di tempo fa in Veeam, quando gli alberi erano alti, i loghi verdi e il prodotto piccolo, si poteva formare in questo modo — e così hanno fatto!

Col passare del tempo, però, il prodotto stava diventando sempre più grande e complesso, aumentando il numero di nuovi ingegneri, e l'approccio RTFM (Read The Freaking Manual) funzionava sempre meno — il problema è che così possono imparare solo coloro che sono già “dentro”, che comprendono le specificità del lavoro e necessitano di alcuni dettagli non critici.

E come fare con coloro che provengono da settori affini e desiderano crescere e svilupparsi, ma non sanno come procedere? Come affrontare, ad esempio, chi parla una lingua relativamente rara (come l'italiano, raro per un comune informatico)? O come formare un promettente neolaureato che non ha alle spalle un’ampia esperienza lavorativa?

Prendiamo un attimo una pausa dalla nostra narrazione e immaginiamo: tu, team leader di un team di supporto, passato un buon e affermato ingegnere con una vasta esperienza in amministrazione di sistemi e comunicazione con diverse persone. Il tuo compito è trasmettere la tua esperienza a un nuovo ingegnere “green”, un neolaureato, intelligente e promettente. C'è solo un dettaglio — questa persona non ha esperienza nel supporto e neanche nel più semplice help desk, e sarà il primo ingegnere di lingua turca nella tua azienda.

Come affronterai questa sfida?

E quando avrai risposto a questa domanda (e tu risponderai, io ho fiducia in te), rendiamo la situazione più complessa — e se questi ingegneri fossero dieci? E se fossero venti? E se questo fosse un continuo sviluppo del dipartimento, e ci fosse sempre un neofita da formare, da mostrare il minimo standard di qualità lavorativa (che è alto) e fare in modo che la persona non desideri scappare il prima possibile?

(Si prega di riflettere su questa domanda prima di continuare a leggere.)

La Nostra Storia

È proprio con questa sfida/problematiche che ci siamo confrontati.

Finché il dipartimento fosse stato, in modo approssimativo, piccolo, il sistema “dare un mentore al neofita, una lista di documenti e lasciarlo lavorare — navighi o affondi” ha funzionato bene. Il sistema è buono, universale, collaudato da anni e persino secoli di esperienza umana — ma a un certo punto ci siamo resi conto di essere stanchi delle ripetizioni. Ogni neofita ha bisogno di essere informato su alcune cose — le stesse che potrebbero essergli utili nel lavoro. Nello schema “tradizionale” si occupa il mentore, ma cosa succede se un certo mentore ha i suoi pupilli che arrivano uno dopo l’altro? Ripetere le stesse cose diventa rapidamente noioso, portando a un esaurimento — e questo è già un rischio.

E qui ricordiamo un altro, non meno tradizionale schema — riunire i neofiti in gruppi e tenere loro lezioni — così è nata la nostra programma formativa.

… A volte i nostri ingegneri partecipano a conferenze — sia interne che esterne, organizzate da terzi e da noi stessi. È proprio da un nostro evento che è cominciata la formazione nel supporto, così come è adesso.

Uno dei nostri ingegneri ha presentato a VeeamOn a Las Vegas un'ottima presentazione su quali pezzi costituiscono Veeam Backup & Replication, e con alcune modifiche è diventata la lezione “Componenti”. A quel tempo avevamo già alcune lezioni su diverse parti della funzionalità, ma quella lezione “ha dato il tono” a tutte le altre che sono venute prima e dopo. È stato proprio il modo in cui è stata strutturata quella lezione, i materiali utilizzati e altro, che è diventato il nostro standard.

Abbiamo cominciato a parlare molto di virtualizzazione, delle tecnologie Microsoft, dei nostri prodotti, introducendo corsi di base per i nostri neofiti senza esperienza in IT, dove raccontiamo tutto ciò che può essere necessario a un ingegnere di supporto — iniziando dall'hardware e aumentando i livelli di astrazione: Disk API, Sistemi Operativi, Applicazioni, Networking, Virtualizzazione.

Certo, sapevamo e sappiamo che cercare di coprire con i corsi di formazione tutta la gamma di tecnologie che utilizziamo non sarà possibile, o almeno non sarà saggio. Per formare su tutte le funzionalità di un prodotto, sono già necessari diversi mesi, e il prodotto non resta fermo, e tutto il tempo emergono cose nuove. Inoltre, solo i corsi di formazione-lezioni, come sono ora, non possono fornire tutto ciò di cui ha bisogno un futuro ingegnere.

E cos'altro oltre a questo?

Mi piace dire che abbiamo una regola di Pareto: attraverso i nostri corsi forniamo circa il 20% di ciò che è necessario a un ingegnere di successo, mentre l'80% rimane di sua responsabilità — leggere manuali, lavorare in laboratorio, risolvere richieste di test e congiunte, e così via.

Il 20% — i corsi — è in realtà quasi il 100% della base teorica, ma con solo la teoria non si ottiene nulla — funziona lo schema classico Conoscenze-Abilità-Competenze. Possiamo fornire le Conoscenze, ma sviluppare le Abilità e trasformarle in Competenze è un compito completamente diverso.

Ecco perché rapidamente le nostre prime lezioni teoriche sono state integrate con altre parti, e ora lo schema complessivo appare così:

• Lezioni/corsi;
• Lavoro autonomo;
• Mentorship.

Per il primo punto è tutto chiaro: prendiamo un gruppo di principianti, presentiamo loro la teoria e passiamo gradualmente al secondo punto, assegnando alla fine della lezione un "compito a casa" — un certo compito pratico che il principiante deve "sperimentare" in laboratorio e fornire un rapporto in qualche forma (di solito in forma libera, ma ci sono eccezioni).

Formuliamo i compiti in modo abbastanza generale, evitando istruzioni precise come “vai lì, fai questo, scrivi cosa vedi”. Invece, poniamo solo il compito (ad esempio: avvia una macchina virtuale con questo elenco di componenti) e chiediamo di condurre una certa "ricerca" sul risultato ottenuto, senza entrare in come farlo o come verificare il risultato. Con questo vogliamo insegnare ai principianti (soprattutto a coloro che all'inizio del loro percorso si trovano lontani dal mondo IT e da come pensa la comunità ingegneristica) l'autonomia nel pensiero, la capacità di leggere documentazione e analizzare i problemi emergenti e, cosa molto importante, comprendere i propri limiti.

Sappiamo tutti che a volte risolvere un problema porta a un vicolo cieco, come se davanti a noi si erigesse un muro che non possiamo perforare. Comprendere quando vale la pena continuare a picchiare la testa contro il muro e quando è il momento di trovare qualcuno che possa aiutare è un'abilità molto importante per un ingegnere che lavora in un team.

Il nostro "aiutante" per il principiante è il mentore.

Non si può sottovalutare il mentore. Giudicate voi stessi, è il primo "punto di contatto" per il principiante a lui assegnato, colui che può rispondere alla maggior parte delle domande e aiutare nella maggior parte delle situazioni — e correggere quei cattivi schemi (nella parte tecnica, nell'etica aziendale, nella cultura dell'azienda) che possono sfuggire sia al formatore che persino al team leader.

E questo è tutto su di lui?

Lezioni-corsi, mentorship, lavoro autonomo — questi sono i tre principali mattoni che costituiscono il nostro programma di formazione. Ma è tutto qui da raccontare? Certo che no!
Anche avendo uno schema decente, quattro programmi formativi completi (il quinto è in arrivo), non smettiamo di raccogliere i nostri "to-rags pluds". La formazione è viva tanto quanto è vivo il nostro prodotto, quindi emergono costantemente nuove informazioni e nuovi modi per trasmetterle.

Ad esempio, una pietra miliare importante per noi è stata comprendere che stiamo effettivamente ripetendo l'istruzione scolastica/universitaria quasi completamente, e non sempre funziona. Insegniamo a persone adulte, con esperienza, paure e preferenze proprie. E un tale sistema "scolastico" può spaventare leggermente le persone (chiamiamo le cose con il loro nome — nel 95% dei casi, qualsiasi frustrazione legata al modello scolastico deriva dalla paura): tutti noi siamo passati attraverso la scuola e l'università e, nella maggior parte dei casi, è stata un'esperienza traumatizzante, quindi non si ha voglia di ripeterla.

Da qui iniziamo (sì, solo iniziamo, ma "un viaggio di mille miglia..." e così via) a rivedere i nostri approcci. Abbiamo ricordato/riconosciuto l'andragogia (l'istruzione per adulti — in contrapposizione alla pedagogia, che è essenzialmente l'istruzione per bambini) con la sua attenzione sull'esperienza, sul comprendere gli obiettivi, con sfumature su come assimilare le informazioni e il comfort degli studenti, importanza della componente emotiva (per i bambini è addirittura più importante), necessità di una componente pratica e così via. Abbiamo imparato riguardo al ciclo di Kolb e ora giriamo i nostri corsi, pensando a come portare anche una persona absolutamente "non nel tema" al corso con già un'esperienza, che aiutiamo ad attualizzare e ampliare, approfondire e rifinire, e, cosa molto importante, non solo fornire pura teoria, ma anche conoscenze pratiche che possono essere trasformate in competenze con l'aiuto di un mentore o autonomamente.

Abbiamo invitato degli esperti di business che hanno lavorato intensamente con i nostri relatori sulle abilità di presentazione, condividendo emozioni, praticando l'assertività, fornendo strumenti per la gestione della dinamica di gruppo e, naturalmente, aiutandoci a rispondere a domande come “cosa vogliamo dall'apprendimento?” e “qual è il nostro obiettivo finale?”. I risultati sono già evidenti: alcuni corsi, che ricevevano il maggior numero di feedback del tipo “noioso e poco chiaro”, ora sono considerati tra i più interessanti e coinvolgenti — e il relatore è rimasto lo stesso!

Inoltre, di recente, sono arrivati da noi un paio di ragazzi molto motivati e capaci, che parlano di Knowledge Centered Support e di come costruire corsi video — e abbiamo tratto da loro molte buone idee su come riprogettare questi ultimi ed evitare il “stile registrazione webinar” in corsi chiari e semplici, che spiegano in modo accessibile tutto ciò che desideriamo e non permettono di perdersi nella varietà di metodi di fornitura delle informazioni.

Inoltre, ora ci occupiamo non solo degli aspetti tecnici dell'apprendimento, ovvero delle cosiddette hard skills, ma lavoriamo anche sulle soft skills, non solo per i relatori o il management, ma anche per gli ingegneri. Facciamo questo affinché il nostro Ignat, entrando in azienda, possa esercitare quelle competenze che gli saranno utili al 100% nel lavoro, sappia gestire le proprie emozioni e sappia che in qualsiasi situazione complessa e senza speranza, non sarà solo: perché il Supporto parla di persone, e “non abbandoniamo mai i nostri in difficoltà”. Prima delle prime chiamate in entrata, faremo alcune simulazioni di ruolo con il novellino, aiutandolo a inserirsi nel processo e trovare il proprio stile di risposta; prima dei primi casi, spiegheremo come affrontarli al meglio e su cosa prestare attenzione, e durante tutto il processo, monitoreremo e assisteremo.
Noi siamo supporto. E chi dobbiamo sostenere prima di tutto, se non i nostri?

E per concludere, alcune parole...

Riconosco che la mia narrazione suona elogiativa. E non sto vantandomi — questa è la nostra storia, il nostro presente e solo una piccola parte dei progetti futuri.

La nostra formazione non è mai perfetta. Abbiamo molti difetti e abbiamo commesso errori — mamma mia! Riceviamo un sacco di feedback, e spesso non sono elogiativi; ci segnalano problemi, difetti, miglioramenti desiderati — e poiché formiamo a livello mondiale, riceviamo un feedback molto variegato, e considerando anche le differenze culturali...

Abbiamo margini di crescita, e grazie al cielo abbiamo persone pronte a lavorare, criticare, discutere e proporre novità. Questa è una grande risorsa e un grande supporto.

E il Supporto parla di persone — sono proprio le persone a rendere l'apprendimento reale, l'apprendimento aiuta i nuovi dipendenti a iniziare a portare valore prima e a crescere come bravi ingegneri più velocemente, e i bravi ingegneri migliorano il mondo.

… e con questo, permettetemi di concludere i discorsi concessi.

Fonte: habr.com