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

Ecco la "storia diversa" promessa.

Sfida

Se mi avessero chiesto quattro anni fa: "Come si può formare i nuovi arrivati nel dipartimento IT/azienda?" — avrei risposto senza esitazione: "Con il metodo 'la scimmia vede — la scimmia imita', cioè attaccate il nuovo arrivato a un dipendente più 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 — e si faceva!

Man mano che il prodotto diventava sempre più grande e complesso, aumentava il numero di nuovi ingegneri, e l'approccio in stile RTFM (Read The Freaking Manual) funzionava sempre peggio — il fatto è che così possono imparare solo quelli già "nel settore", che capiscono le specifiche del lavoro e hanno bisogno di dettagli non cruciali.

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 è raro per la maggior parte degli informatici)? O come formare secondo questo schema un neolaureato promettente, che non ha molta esperienza lavorativa alle spalle?

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 è trasmettere la vostra esperienza a un nuovo (potremmo dire "alle prime armi") ingegnere, un neolaureato, intelligente e perspicace. C'è solo una piccola sfida — questa persona non ha esperienza nel supporto né nel banale help desk, e sarà anche il primo ingegnere di lingua turca nella vostra azienda.

Come affronterete questo compito?

E quando avrete risposto a questa domanda (e risponderete, io credo in voi), rendiamo la questione più difficile — 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à del lavoro (e questo standard è alto) e far sì che la persona non desideri scappare il prima possibile?

(Per favore, riflettete su questa domanda prima di continuare a leggere.)

La nostra storia

È proprio con una sfida/compito del genere che ci siamo confrontati.

Finché il reparto è stato relativamente piccolo, ha funzionato bene la strategia di "assegnare a un neofita un mentore, una lista di documenti e lasciarlo lavorare — nuota o affonda". È una buona strategia, universale, testata da anni e persino secoli di esperienza umana collettiva — ma a un certo punto ci siamo resi conto che eravamo stanchi delle ripetizioni. A ogni nuovo arrivato bisogna spiegare alcune cose — 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 — e questo è già un rischio.

E qui ricordiamo un'altra strategia, non meno tradizionale — raccogliere i neofiti in gruppi e tenere loro lezioni — così è nata la nostra programma di formazione.

… A volte i nostri ingegneri partecipano a conferenze — sia interne che esterne, organizzate da terzi o da noi stessi. Ed è proprio da un nostro evento che è iniziata la formazione nel supporto, come la conosciamo oggi.

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 è diventata la lezione "Componenti". A quel punto avevamo già diverse lezioni sui vari aspetti delle funzionalità, ma è stata quella lezione a "dare il tono" a tutte quelle che sono venute prima e dopo. Proprio il modo in cui quella lezione è stata strutturata, i materiali utilizzati e altro ancora, è diventato il nostro standard.

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 — partendo dall'"hardware" e aumentando i livelli di astrazione: Disk API, Sistemi Operativi, Applicazioni, Networking, Virtualizzazione.

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à di un solo prodotto, oggi servono già diversi mesi, e il prodotto non sta fermo, emergono continuamente novità. Inoltre, solo le formazioni-lezioni, così come sono, non possono fornire tutto ciò di cui ha bisogno un futuro ingegnere.

E cosa c'è oltre?

Mi piace dire che seguiamo la regola di Pareto: con i nostri corsi offriamo circa il 20% di ciò che è 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.

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

Ecco perché molto rapidamente le nostre prime lezioni teoriche si sono arricchite di altre cose, e ora lo schema complessivo appare così:

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

Con il primo punto è tutto chiaro: prendiamo un gruppo di nuovi arrivati, spieghiamo loro la teoria e passiamo dolcemente al secondo punto, assegnando alla fine della lezione un “compito a casa” - un certo compito pratico che il nuovo arrivato deve “svolgere” in laboratorio e presentare un rapporto in una certa forma (di solito una forma libera, ma ci sono alcune eccezioni).

Formuliamo gli incarichi intenzionalmente in modo piuttosto generale, evitando istruzioni precise come “vai lì, fai questo, annota cosa vedi”. Invece, poniamo solo il compito (ad esempio: imposta una macchina virtuale con questa lista di componenti) e chiediamo di effettuare una certa “ricerca” sul risultato ottenuto, senza entrare nel modo in cui farlo o nel modo di verificare il risultato. Con questo vogliamo insegnare ai nuovi arrivati (soprattutto a coloro che sono lontani all'inizio del loro percorso nel mondo IT e dal modo di pensare della comunità ingegneristica) l'autonomia di pensiero, la capacità di leggere la documentazione e di analizzare i problemi che sorgono, e, cosa molto importante, la comprensione dei propri limiti.

Sappiamo tutti che a volte risolvere un problema porta a un vicolo cieco, come se davanti si erigesse un muro che non si riesce a sfondare. È anche un'abilità molto importante per un ingegnere che lavora in team capire in quali situazioni vale la pena continuare ad affrontare il muro e quando è il momento di trovare qualcuno che possa aiutare.

Per noi, questo “aiutante” per il nuovo arrivato è il mentore.

Rivalutare un mentore è semplicemente impossibile. Giudicate voi stessi, è il primo "punto di contatto" per il neofita a lui assegnato, colui che può rispondere alla maggior parte delle domande e aiutare nella maggior parte delle situazioni — e correggere quei cattivi modelli (nella parte tecnica, nell'etica aziendale, nella cultura della compagnia) che possono sfuggire sia al trainer che persino al team leader.

E questo è tutto su di lui?

Lezioni-workshop, mentoring, lavoro autonomo — questi sono tre mattoni fondamentali che compongono il nostro programma di formazione. Ma è tutto qui, quello che possiamo raccontare? Certo che no!
Anche con uno schema ragionevole, quattro programmi di formazione completi (un quinto è in arrivo), non ci fermiamo mai nel raccogliere i nostri “triodi pludov”. La formazione è viva tanto quanto è vivo il nostro prodotto, e quindi nuove informazioni e nuovi modi per comunicarle emergono continuamente.

Ad esempio, un importante traguardo per noi è stato comprendere che stiamo realmente ripetendo l'istruzione scolastica/universitaria in modo quasi totale, e non sempre funziona. Insegniamo ad adulti, con esperienza, con le proprie paure e preferenze. E una tale sistematica "scolastica" un po’ spaventa le persone (chiamiamo le cose con il loro nome — nel 95% dei casi qualsiasi frustrazione legata al modello scolastico deriva dalla paura): tutti noi abbiamo in un certo modo attraversato la scuola e l'università, e spesso è stata un'esperienza traumatizzante, quindi non abbiamo proprio voglia di riviverla.

Da qui iniziamo (sì, solo iniziamo, ma "un viaggio di mille miglia..." e così via) a rivedere i nostri approcci. Abbiamo ricordato / scoperto l'andragogia (l'insegnamento agli adulti — in contrapposizione alla pedagogia, che riguarda fondamentalmente l'insegnamento ai bambini) con la sua orientazione all'esperienza, comprensione degli obiettivi, con sfumature riguardanti l'acquisizione delle informazioni e il comfort degli studenti, l'importanza della componente emotiva (per i bambini è ancora più importante), la necessità di una componente pratica e così via. Abbiamo scoperto ciclo di Kolb E ora stiamo svolgendo i nostri corsi, pensando a come portare anche una persona completamente "fuori tema" a partecipare a un training con un certo livello di esperienza, che noi aiuteremo ad attualizzare, arricchire, approfondire e, cosa importante, fornire non solo pura teoria, ma anche conoscenze pratiche che possono essere trasformate in abilità con l'aiuto di un mentore o in modo autonomo.

Abbiamo invitato formatori professionisti che hanno lavorato a lungo con i nostri relatori sulle presentazioni pubbliche, parlando di emozioni, allenando l'assertività, fornendo strumenti per la gestione della dinamica di gruppo e, naturalmente, aiutandoci a rispondere alle domande “cosa vogliamo dall'apprendimento?” e “qual è il nostro obiettivo finale?”. I risultati ci sono già: alcuni corsi, che raccolgono più feedback nel senso “noioso e poco chiaro”, ora sono considerati tra i più interessanti e coinvolgenti — eppure il relatori è rimasto lo stesso!

Inoltre, di recente ci ha raggiunta una coppia di ragazzi davvero fantastici e motivati, che parlavano del Knowledge Centered Support e di come costruire corsi video — e abbiamo tratto molte buone idee da loro su come rifare gli ultimi e allontanarci dallo stile “registrazione webinar” verso corsi belli e semplici che spiegano tutto in modo chiaro e non permettono di affogare nella varietà dei metodi di fornire informazioni.

Inoltre, ora ci occupiamo non solo della parte tecnica dell'apprendimento, ovvero le cosiddette hard skills, ma stiamo lavorando anche sulle soft skills, non solo per i relatori o la gestione, ma anche per gli ingegneri. Lo facciamo affinché il nostro Ignat, entrando in azienda, possa allenare le abilità che gli saranno fondamentali al 100% nel lavoro, sappia gestire le proprie emozioni e sia consapevole che, in qualsiasi situazione, anche la più complessa e senza speranza, non sarà solo: perché il Supporto riguarda le persone, e “non abbandoniamo i nostri nei momenti difficili”. Prima delle prime chiamate in entrata, faremo delle simulazioni con il neoassunto, aiutandolo a immergersi nel processo e trovare il proprio stile di risposta; prima dei primi casi, spiegheremo come lavorare meglio con essi e a cosa prestare attenzione, e durante tutto il processo seguiamo e supportiamo.
Noi siamo il supporto. E chi dobbiamo sostenere prima di tutto, se non i nostri?

E in conclusione, qualche parola...

Mi rendo conto che il mio racconto suona come una lode. E non mi sto vantando: è la nostra storia, il nostro presente e solo una piccola parte dei piani per il futuro.

Il nostro apprendimento non è mai perfetto. Abbiamo molte lacune e abbiamo fatto molti errori — mamma mia! Riceviamo molti feedback, e spesso non sono positivi; ci scrivono riguardo a problemi, difetti, miglioramenti desiderati — e poiché ci alleniamo a livello mondiale, ci sono tantissimi feedback diversi, e se consideriamo anche le differenze culturali…

Abbiamo ancora molta strada da fare, e grazie a Dio, abbiamo quelli che sono pronti a lavorare, criticare, discutere e proporre nuove idee. Questa è una grande risorsa e un valido supporto.

E il supporto riguarda le persone: sono proprio le persone a rendere possibile l'apprendimento, e l'apprendimento aiuta i nuovi dipendenti a iniziare a dare valore più velocemente e a diventare ottimi ingegneri prima, mentre i buoni ingegneri rendono il mondo migliore.

… e su questo, permettetemi di concludere i discorsi consentiti.

Fonte: habr.com