Il cliente ideale

“Non aver paura della perfezione. Non la raggiungerai mai.”

Salvador Dalí

Quando ci troviamo dalla parte del cliente siamo abituati a ragionare per stereotipi a senso unico del tipo “il cliente ha sempre ragione” o “io pago e quindi scelgo” secondo cui chi commissiona il lavoro decide come e chi debba realizzarlo.

Se si considerano prodotti o servizi per i quali l’interazione tra cliente e venditore è limitata alla dinamica selezione/acquisto, la visione a senso unico in cui il cliente valuta le caratteristiche in relazione al prezzo richiesto è quasi sempre la migliore; se non altro per i vantaggi in termini di efficacia ed efficienza.

Quando si tratta di progetti software realizzati su commessa, è utile ricordare che il fornitore fa una valutazione della convenienza del progetto non solo in base al prezzo di vendita. Questo perché il rapporto che si instaura sarà più lungo e più intenso di quello generato dall’acquisto di qualcosa di preconfezionato.

Il fornitore deve infatti valutare il rischio connesso alle difficoltà derivanti dalle caratteristiche professionali e organizzative del cliente; sia considerando l’azienda nel suo complesso che in base alle persone aventi un ruolo nel progetto.

Di norma si ritiene che il fornitore possa proteggersi dai rischi derivanti dalle caratteristiche peculiari del cliente includendoli nel prezzo.

Questo è però vero solo in parte, infatti:

  • a parità di attività offerta, non è giustificabile una troppo ampia oscillazione del prezzo;
  • il danno d’immagine derivante da un progetto fallito può non essere compensabile in denaro;
  • il deterioramento dei rapporti con i dipendenti e i collaboratori che devono interagire con un cliente “difficile” può comportare la perdità di preziose competenze professionali.

Per quanto visto non è poi così inspiegabile il caso di un fornitore che decide di rinunciare a un profitto incarico.

Il cliente che volesse tentare la via della perfezione può considerare questi non esaustivi suggerimenti.

  • Preparare un documento preliminare in cui sono sommariamente descritti gli obiettivi e il contesto del progetto indicando non solo i vincoli  tecnici ma, soprattutto, quelli procedurali e temporali. Oltre all’ovvio vantaggio di semplificare l’avvio del progetto, il documento dimostra che il cliente ha obiettivi chiari, aspettative realistiche ed è orientato a collaborare col team di sviluppo.
  • Non avanzare richieste plausibili in altri contesti ma irrealistiche in quello dello sviluppo software:
    • il prodotto deve essere privo di difetti al 100%;
    • è un lavoro facile, quindi lo finirete in X giorni;
    • durante l’orario d’ufficio il vostro responsabile deve essere immediatamente disponibile.
  • Evitare di dimostrare poco rispetto per il team di sviluppo (gli informatici sono suscettibili circa la propria immagine professionale):
    • cerchiamo fornitori in grado di gestire qualsiasi nostra richiesta
      Superman non risponde al telefono?
    • cerchiamo fornitori capaci di lavorare in un ambiente stressante e in costante cambiamento
      …cioè disorganizzato;
    • il pagamento avverrà solo quando tutto il lavoro sarà completato e verificato
      Mai sentito parlare di sviluppo per fasi e relativo pagamento? Inoltre, in Italia, si tratterà solo dell’autorizzazione a emettere fattura; il vero pagamento ci sarà dopo un numero di mesi imprevedibile, non di rado a due cifre, e comunque sufficiente a verificare ampiamente la qualità di quanto acquistato.