Molti programmatori hanno difficoltà nel gestire la comunicazione. Non intendo quella di rete, ma quella interpersonale. E’ forse per questo che gran parte di loro preferisce lavorare in proprio. Ciò gli consente di non dover comunicare o perlomeno di farlo il meno possibile.
Luogo comune vuole che i programmatori siano persone chiuse, a volte timide, oppure scontrose e irascibili; più interessate al codice che non alle relazioni interpersonali. E’ pur vero che il nostro lavoro richiede concentrazione. Molti sostengono che programmare è una forma d’arte e la gran parte degli artisti (pittori, scultori, disegnatori) non lavora forse in silenzio?
Tuttavia anche i più abili nell’eludere ogni forma di contatto prima o poi si vedranno costretti a comunicare con una persona importante: il cliente. Di tutte le forme di comunicazione professionale, quella col cliente è senz’altro la più delicata. Ne va del nostro lavoro e purtroppo in questo caso ci troviamo spesso ad affrontare un problema importante, quello che Chris Eidhof definisce la “perdita di segnale”.
Ogni volta che comunichiamo c’è un rumore di fondo. Se le parti hanno competenze diverse, frammenti del messaggio andranno perduti. In linea generale, più le esperienze sono vicine (due programmatori che parlano tra di loro), minore è la perdita di segnale.
Quando le aree di competenza sono divergenti (come capita tra programmatore e cliente) è necessario adottare, a volte forgiare, un linguaggio comprensibile per entrambi. Quasi sempre questo è più vicino al cliente che non al programmatore, per il quale l’impegno è notevole. Il rischio da evitare sono le incomprensioni e i conseguenti, inevitabili, ritardi nel lavoro.
A differenza dei linguaggi di programmazione, che una volta acquisiti entrano definitivamente nel bagaglio del programmatore, i linguaggi da adottare coi clienti tendono a cambiare di volta in volta a causa delle variabili in gioco, prime tra tutte il grado di alfabetizzazione informatica e l’area di competenza (ambito professionale) della controparte.
Qualche esempio può essere utile. Godetevi le mie tre gaffes più recenti, non tutte avvenute sul lavoro. D’altronde questa faccenda della scelta del linguaggio giusto non è certo confinata al solo ambito professionale. La prima riguarda la mia non proprio brillante comunicazione su Facebook:
Il secondo incidente è avvenuto proprio su questo sito:
In quest’ultimo caso si potrebbe obiettare che l’errore è del visitatore che è capitato nel posto sbagliato. Non è così perché l’avevo indotto io alla visita, pubblicando il link su Facebook. E veniamo al caso più interessante perché ha coinvolto un mio cliente la settimana scorsa:
Qui il nostro servizio di assistenza si era espresso chiaramente. Il fatto è che la parola ‘immagine’ ha un significato ben diverso a seconda che venga intesa da un tecnico informatico o da un commerciante di liquori. Pur avendo compreso perfettamente la richiesta, evidentemente non avrebbe avuto idea di come soddisfarla. Direi che in questo caso ha saputo arrangiarsi brillantemente. In effetti il supporto tecnico è uno dei campi nei quali il conflitto tra competenze e linguaggi diversi tende a generare i risultati più disastrosi.
Descrivere il problema col giusto linguaggio è il primo passo, forse il più importante, per trovarne la soluzione. Apprendere il dizionario del cliente è determinante per attivare una comunicazione efficace. Temo che nella gran parte dei progetti software non ci si provi nemmeno, e forse per questa ragione tanti programmi risultano difficili da utilizzare.