Ruoli nell'IT: produttività e disponibilità

Come manager IT ci troviamo a dover gestire due tipi molto diversi di professionisti tecnici. Questi due tipi di professionisti si distinguono non per il loro tipo di personalità o per il loro stile di lavoro, ma per la natura stessa del loro ruolo lavorativo. Comprendere le esigenze peculiari di questi due tipi di lavoro è fondamentale per gestire efficacemente i lavoratori tecnici, ma pochi reparti IT si prendono davvero il tempo di comprendere e apprezzare le sfumature insite in questi due diversi ruoli lavorativi.

Il primo tipo, e di gran lunga il meglio compreso, lo chiamerò l'«ingegnere». Questo ruolo ingegneristico racchiude un'enorme varietà di funzioni lavorative che spaziano dagli sviluppatori e progettisti software, agli architetti, ai system engineer, ai network engineer o a chiunque la cui funzione primaria sia progettare o implementare in modo creativo nuovi sistemi di qualsiasi tipo. Il termine ingegnere è generico, ma relativamente significativo.

Il secondo tipo di ruolo del lavoratore tecnologico può essere genericamente definito ruolo di «supporto». Le professioni di supporto possono comprendere l'helpdesk, l'amministrazione di sistema, il supporto desktop, il monitoraggio della rete, il centro di controllo e così via. Ciò che distingue i professionisti del supporto da quelli dell'ingegneria è che non sono incaricati di processi creativi che comportano nuove progettazioni o implementazioni, ma lavorano invece con sistemi esistenti, assicurandosi che funzionino correttamente e che vengano riparati rapidamente quando qualcosa non va.

Va da sé che nessun essere umano reale rientrerà mai con tutta probabilità completamente in una sola delle due categorie, ma quasi tutte le funzioni lavorative nell'IT si concentrano in modo molto marcato sull'una o sull'altra. È piuttosto sicuro presumere che quasi ogni ruolo penderà eccezionalmente verso l'uno o l'altro. È molto raro che una singola posizione sia suddivisa equamente tra questi ruoli.

Là dove questa identificazione dei ruoli entra in gioco è nel sapere come misurare e gestire il personale tecnico. Misurare e gestire gli ingegneri, a un livello molto generale, è cosa abbastanza ben compresa. Il concetto di produttività è molto semplice e significativo per i ruoli ingegneristici. L'obiettivo nel gestire una persona o un team di ingegneria è consentire e incoraggiare quel ruolo a produrre quanta più progettazione o implementazione creativa possibile. Esiste naturalmente anche il concetto di qualità, ma possiamo comunque pensare ai ruoli ingegneristici in termini relativamente concreti, come il numero di funzioni scritte, il numero di pacchetti di distribuzione prodotti, le dimensioni della rete progettata e così via. Le metriche sono cosa sfumata, ma abbiamo perlomeno una buona idea di cosa significhi efficienza per un ingegnere, anche se non possiamo necessariamente misurarla con precisione.

I ruoli di supporto non hanno questo stesso concetto. Certo, si potrebbe usare una metrica artificiale come i «ticket chiusi» per misurare la produttività in un ruolo di supporto, ma sarebbe molto fuorviante. Un ticket potrebbe essere banale e il successivo una grande sfida di ricerca. In molti casi potrebbe non esserci alcun ticket disponibile per molto tempo, per poi vederne arrivare diversi tutti insieme che non possono essere gestiti contemporaneamente. La produttività sarà probabilmente sporadica e non sostenibile e, in ultima analisi, non affatto significativa da misurare.

Le posizioni ingegneristiche guadagnano il proprio sostentamento producendo risultati in modo efficace per un arco di tempo piuttosto lungo, che spesso si estende persino a mesi e anni per i grandi progetti. L'obiettivo, pertanto, con le posizioni ingegneristiche è fornire un ambiente che incoraggi una produttività sostenibile. È ben noto che gli ingegneri guadagnano spesso in produttività lavorando orari ridotti o alternativi, prendendo ferie regolari e così via. Questo non solo accresce spesso la produttività, ma incrementa anche notevolmente la qualità dei risultati.

Le posizioni di supporto si guadagnano il pane «essendoci» quando serve. Se una persona di supporto cerca di lavorare alla massima efficienza, c'è l'implicazione naturale che esista un arretrato continuo di problemi di supporto in attesa dell'attenzione del team e che ci siano molte persone bisognose di supporto costrette ad aspettarlo, così da formare una coda. Avere sempre una coda in essere significa anche che il personale di supporto preleva continuamente lavoro dalla pila invece di risolvere elementi in tempo reale, ignorando elementi ad alta priorità oppure venendo interrotto regolarmente, il che provoca un continuo cambio di contesto che riduce in modo significativo la capacità di gestire efficientemente la coda, la cui intera ragion d'essere era proprio quella di creare in primo luogo l'apparenza di una produttività artificiale.

I ruoli di supporto sono «guidati dagli eventi». Mi piace questa terminologia perché ritengo che descriva nel modo più accurato la modalità in cui lavora quasi ogni professionista del supporto. Che un evento sia generato da una telefonata, da un messaggio istantaneo, da un'e-mail o da un ticket, si tratta di un «evento» che innesca il passaggio del professionista del supporto dall'inattività all'azione o, in alcuni casi, da un elemento a bassa priorità a uno ad alta priorità. In un modo o nell'altro, un evento rappresenta un «cambio di contesto» per il professionista del supporto. Senza un evento non c'è nulla che un professionista del supporto debba fare. Anche se l'«evento» è rappresentato da una coda di ticket o da un arretrato di e-mail, si tratta comunque di una forma di evento.

Avere un supporto davvero efficiente richiede una gestione attenta del processo degli eventi. Avere una coda infinita di problemi di supporto è estenuante per i professionisti del supporto e significa anche che nessuna quantità di personale è mai in uno stato «inattivo» in attesa di elementi ad alta priorità. Per questo motivo, gli elementi ad alta priorità o non vengono affrontati con la rapidità che dovrebbero, oppure gli elementi in corso di lavorazione vengono trascurati.

Comprendere la natura guidata dagli eventi del personale di supporto è fondamentale per capire come affrontare la gestione di questi team. Non ci sono risposte semplici, e le metriche del personale di supporto sono spesso ancora più prive di significato di quelle del personale di ingegneria, quindi vanno usate con estrema cautela; ma immedesimandoci nel ruolo di supporto possiamo iniziare a vedere dove il nostro ruolo di manager del supporto si inserisce nel quadro più ampio del sostenere e valorizzare i membri del team di supporto.

Il concetto più importante, dalla mia esperienza, è garantire un buon flusso delle interruzioni dirette al team di supporto. Spesso i team di supporto gestiscono diversi canali per il supporto, come l'e-mail e il telefono. Limitare e incanalare gli eventi verso i canali appropriati è fondamentale.

Il problema dei telefoni è che sono aggressivi e impongono un cambio di contesto immediato, sia che il destinatario sia inattivo, sia che stia attualmente gestendo l'interruzione di produzione più critica nella storia dell'azienda. La persona che chiama parte dal presupposto che la propria necessità immediata superi le necessità correnti di chiunque la persona di supporto stia attualmente assistendo. I telefoni causano questo problema ovunque vengano utilizzati.

Pensate all'ultima volta che eravate in una pizzeria a ordinare al bancone. Avete aspettato pazientemente in fila mentre ogni persona veniva servita. Avete fatto la cosa giusta. Arrivate in testa alla coda. Cominciate a fare la vostra ordinazione quando, il telefono squilla. La persona che prende la vostra ordinazione vi mette «in attesa» anche se siete proprio lì davanti, alza la cornetta, prende l'ordine, riaggancia e torna da voi. Ciò che questo dice è che la persona che chiama, essendo la «ruota che cigola», è più importante per il ristorante delle persone effettivamente presenti nel ristorante. Questo stesso effetto si verifica in molti reparti di supporto: il lavoro in corso viene interrotto da chiamate dirette a una linea di gruppo o direttamente alla persona di supporto. Questo è, nel migliore dei casi, inefficiente e, nel peggiore, può interrompere processi di supporto critici per questioni estremamente critiche.

Quindi, quando riflettete su come gestire i professionisti IT, pensate allo scopo del loro ruolo. L'obiettivo di un ingegnere è la produttività. L'obiettivo di un professionista del supporto è la disponibilità.