It's not the client's job to know what he needs – It's our job to find out

Jeffry Palermo, qualche giorno fa, scritto un interessante post relativo al nostro lavoro. Il titolo, anche se visto nell’ottica del cliente, potrebbe apparire “forte”, ma, in fin dei conti, è la verità: non è compito del cliente sapere cosa vuole; è nostro compito capirlo.

Come esempio, viene citato il mitico David Platt (visto a Barcellona e rivisto con piacere ad Orlando). David, con l’estrema semplicità che lo caratterizza, dice:

We go to a doctor because we think we have a medical need and we need an expert to consult with and a provide a solution to what is ailing us. The doctor listens and asks questions by which to formulate some possible solutions to the problem we present. The doctor doesn’t expect us to even be able to talk in the language of medicine. In software, we can’t expect our clients to know what they need.

E’ una cosa che noi, che lavoriamo nel settore IT sappiamo benissimo, ma personalmente non avevo mai trovato un esempio così semplice e lampante per spiegarlo.

Ma allora, cosa sanno i nostri clienti? Esattamente quello che sappiamo noi quando andiamo dal nostro medico e che David, ancora una volta, sintetizza in modo eccezionale:

Much like the depth of a patient may be “I need to get rid of this infection” or “Give me some pills. I’m in pain”. Our clients know what is causing them pain, in the business sense, so the problem is from that experience perspective.

Quindi, qual’è il nostro lavoro?

Some clients might go so far as to ask for some “pills”, that is, they might ask for a specific software system that is assumed to solve the problem. It is the our job to listen and ask pointed questions to determine need. Being software experts, we must also know how to ask the right questions to flesh out the need. If the clients asks for something specifically, and we deliver, but that delivery doesn’t solve the pain, it’s our fault. If I ask my doctor for a specific pill, he prescribes it, then I’m still in pain, it’s the doctor’s fault for allowing me to drive diagnosis.

Ho volutamente evidenziato due passaggi che ritengo fondamentali. Passaggi che evidenziano un problema che si verifica abbastanza spesso. Molte volte, un po’ per pigrizia, ma spesso per inesperienza e per paura di perdere il cliente, ci lasciamo guidare da lui, correndo il grosso rischio di non soddisfare le sue reali esigenze, con tutte le conseguenze del caso.

Come professionisti (o aspiranti tali), il nostro lavoro DEVE essere:

We, as software professionals, are on the hook for responsible analysis that ensures any solution we provide adequately addresses the root of the problem at hand. The client can’t tell us what he wants. It our job to find out. A required skill of any consultant at Headspring is analysis. Analysis is something underrated, but analysis ensures we build the right thing. The risk of building the wrong thing is so great that we can not afford it.

Il rischio di non far bene il nostro lavoro è:

Building (prescribing) the wrong thing would be disaster for our reputation. Analysis is what ensures we build the right thing.

Per esperienza vissuta, direttamente e non, ritengo che la comprensione di questi punti da parte nostra sia fondamentale. Il rischio di perdere il cliente c’è. Capita sempre il cliente che è fermamente convinto di sapere cosa vuole. Se non siamo in grado di fargli capire i concetti espressi in questo post, possiamo trovarci in queste 3 situazioni:

  1. perdere il cliente
  2. sforare con il progetto (tempi/budget) al fine di adeguarlo ai nuovi requisiti
  3. perdere la reputazione

Ad oggi mi sono capitate le prime 2 (per la terza, non mi risulta … ma nella vita non si può mai sapere). E, sinceramente, tra le 3 “opzioni”, preferisco senza alcun dubbio la prima!

Fonte: It’s not the client’s job to know what he needs – It’s our job to find out : Jeffrey Palermo (MVP)

Technorati Tags: ,,