Noi informatici non ci limitiamo ad adorare Dilbert: ci chiediamo perché Scott Adams non ci riconosca i diritti.

Se sei un informatico, questo è il tipo di vignetta che ti causa una risata a denti stretti:

Credit: Dilbert.com

Solo che a me non fa più ridere.

Perché? Ma perché la vignetta esemplifica non uno ma due errori tipici degli informatici.

Quel genere di errori, per dire, che non fanno fare carriera e lasciano con la discutibile soddisfazione di poter fare del sarcasmo.

Li sai individuare?

Sono errori legati a una certa forma professionale di arroganza, di cui torniamo a parlare con qualche esempio più approcciabile.

Errore uno: alla domanda “si può… ?” NON si risponde “sì/no”

In informatica “si può fare?” non è mai una domanda a risposta chiusa. Due semplici osservazioni:

  1. in linea di principio, in informatica tutto è possibile (è solo questione di tempo e risorse)
  2. quando un manager chiede “si può… ?” quello che vuole sapere è quanto tempo e risorse ci vogliono

Non vale sostenere che la risposta è formalmente corretta: se ti chiedono “sai che ore sono?”, “sì” è una risposta formalmente corretta, ma ti fa passare per deficiente. Il fatto di conoscere la logica formale non esenta l’informatico dal comunicare come  un essere umano: questa attenzione superficiale alla forma, come se invece che due persone parlassero due appliance, è una manifestazione di quella che chiamo “informatica autistica”, che combatto da vent’anni.

Non si discute che un tecnico possa capirne più del proprio manager riguardo ai problemi tecnici. Anzi, è esattamente quello il motivo per cui il manager si tiene quel tecnico e non ne prende un altro più capace.

Il compito di un informatico, però, non è quello di far calare dall’alto la propria scienza, ma di comprendere come contribuire a risolvere il problema del “cliente” .

E quando dico problema intendo non il problema proposto, ma il problema reale. La differenza fra il problema che il cliente pensa di avere e quello che il cliente ha può essere enorme. Gran parte della fatica del lavoro informatico, almeno quello che ha a che fare con i clienti, sta proprio nel risolvere il problema reale quando il cliente non sa di averlo.

L’effetto del primo errore? Visto da fuori, Dilbert è:

  • pedante
  • ostile
  • interessato al proprio status ma non ai risultati
  • non collaborativo

lui invece si sente:

  • non valorizzato
  • l’unico dotato di capacità e competenze
  • circondato da poveri incompetenti.

Proprio la situazione di molti informatici.

Errore due: ciò che riesci a vedere del lavoro del tuo capo, non è tutta la storia

Tradizionalmente, per l’informatico il capo è un idiota. Non solo tecnicamente incompetente, cioè, ma proprio ottuso, incapace di comprenderee le cose più ovvie, naturalmente privo della spina dorsale che gli permetterebbe di dire ai clienti le cose come stanno, e comunque sempre perso in mezzo alle quisquilie con cui quelli del pianeta Manager passano bellamente il tempo chiamandolo “lavorare”.

In realtà, le cose non sono così semplici. Sì, c’è una gran quantità di incompetenti in giro. Sì, spesso l’incompetenza è inversamente proporzionale alla progressione di carriera. Ma no, la regola “manager=idiota” non vale.

Aziendalmente parlando, all’informatico tocca la parte semplice del lavoro, ossia il livello tecnico dei problemi.  E il livello tecnico, per complicato che sia, è sempre il più semplice da gestire.

L’informatico pensa che trovare errori sparsi in qualche migliaio di linee di codice, interfacciare sistemi che non sono stati pensati per parlare fra di loro, districarsi nella selva di parametri di configurazione di un software a livello enterprise siano imprese da superuomo. E non ha torto.

Il capo, d’altro canto, pensa che siano cose tutto sommato semplici, perché macchine e software possono essere complessi ma hanno una struttura razionale, comprensibile, e non cambiano idea. Le persone invece sì, e di continuo. E a lui tocca avere a che fare con le persone ogni santo giorno.

Prova a convincere un cliente a firmare un contratto, a non cambiare i termini in corso d’opera, a pagare una fattura; prova a convincere un partner a collaborare a condizioni diverse dal tutto-e-subito: vedrai che quando puoi tornare ad occuparti “solo” del livello tecnico tiri un sospiro di sollievo. Quello che tu chiami “politica”, il tuo capo lo chiama lavoro.

Per esperienza so che molti manager sarebbero felici di potersi ancora permettere le reazioni dei loro sottoposti rispetto alle richieste dei clienti: opposizione, diniego, svalutazione, ridicolizzazione, ecc. ma, appunto, non possono. E non possono nemmeno dare l’impressione di condividerle, perché alla fine dei conti, l’azienda lavora perché c’è un cliente, sennò non lavora.

E non è finita qui, il manager deve anche tenere in conto

  • il budget
  • le risorse
  • i tempi
  • i target su cui verrà valutato
  • i carichi di lavoro
  • e le attitudini di ciascuno dei suoi sottoposti,

che di tutti questi vincoli vedranno solo il necessario per svolgere il loro lavoro, cioè il minimo indispensabile. Molto spesso un manager è il primo a considerare assurda la richiesta che deve fare a un suo uomo; ciononostante deve farla, perché è pagato per fare ciò che è necessario, non ciò che piace. Proprio come chiunque altro in azienda, con la differenza che lui ne è consapevole, ogni santo giorno.

Qual è l’effetto del secondo errore? Visto da fuori, Dilbert è:

  • indisponente
  • incapace di vedere il quadro generale, e comunque non interessato a comprenderlo
  • interessato solo al proprio particulare
  • individualista

mentre lui si sente

  • quello che deve sempre levare le castange dal fuoco
  • i cui sforzi non vengono riconosciuti
  • alla mercé di persone che non riescono a dire di no al cliente

Proprio come molti informatici.

Come uscirne? Prova questi cinque semplici passi:

  1. considera il problema che ti pongono come una tessera di un puzzle che non conosci
  2. prima di rispondere, chiedi: ricostruisci il contesto che ha generato quel problema
  3. il tuo primo obiettivo non è dare una risposta, ma scoprire il problema profondo
  4. illustra come la soluzione al problema “profondo” risolve il problema che ti hanno portato
  5. assicurati che anche l’altra persona ne sia convinta, a nessuno piace fidarsi alla cieca.

Molto spesso, per un informatico, la risposta giusta è quella a una domanda che non è stata (ancora) fatta.

Share This

Share This

Share this post with your friends!