cliente

Il filosofo greco Socrate affermava di essere come un'ostetrica, dato che cercava di portare alla luce le conoscenze che i suoi interlocutori portavano già dentro di sé, ma non avevano ancora chiare, non avevano ancora tirato fuori.

Lo faceva attraverso il dialogo, discutendo, come testimoniato dalle opere pubblicate dal suo allievo Platone. Facendo delle domande. Prima generali, poi via via più approfondite. Come deve fare chi vuole chiarire i requisiti per un sistema da sviluppare o fare evolvere.

Chiarire i requisiti è necessario, per chi li deve soddisfare. Li vogliamo precisi. Ma i requisiti non nascono già chiari, precisi, completi nella testa di qualcuno. Sono sempre il risultato di un dialogo, di un processo di interazione. Non potrebbe essere altrimenti.

Chi chiede il sistema, o la nuova versione del sistema (chiamiamolo “cliente”) ha un'esigenza e la manifesta. Ma non è, se non in casi particolari, un esperto di progettazione dei sistemi, non conosce tutti gli aspetti di cui è necessario tener conto per valutare fattibilità e impatto, non sa quanto possano costare le diverse soluzioni possibili per soddisfare la sua esigenza, non ha risorse infinite.

Il suo interlocutore (chiamiamolo “analista”) ha il compito di aiutarlo a chiarirsi le idee. Di aiutare il cliente a capire i costi e i benefici di ciò che sta chiedendo, i contro e i pro, i rischi e le opportunità. Dialogando.

Condurre il dialogo tra “analista” e “cliente” per chiarire i requisiti è un'arte, non una scienza. Un'arte che si apprende, con lo studio e con l'esperienza. Si tratta di fare le domande opportune, di usare un linguaggio comprensibile anche sugli aspetti meno intuitivi per chi non ha competenze tecniche, di stimolare la riflessione, di accompagnare i ragionamenti.

Per fortuna, alcuni decenni di esperienze nello sviluppo dei sistemi hanno messo a disposizione degli analisti delle tecniche valide, come i workshop sui requisiti, l'analisi degli scenari di operatività utente (casi d'uso), la quantificazione dei livelli di servizio sugli aspetti non funzionali (prestazioni, carichi, sicurezza, …), la valutazione di prototipi delle interfacce utente.

Queste tecniche possono aiutare l'analista a svolgere la propria attività maieutica, a guidare il chiarimento dei requisiti in modo non solo efficace, ma anche rapido ed efficiente, perché il tempo e le risorse che abbiamo a disposizione per chiarire i requisiti sono sempre più limitati.

E sono tutte tecniche basate sul dialogo, sulla formulazione di domande, sull'analisi delle risposte (feedback), sul fare emergere velocemente punti di attenzione e sull'aumento progressivo del livello di precisione e di chiarezza.

Molte aziende sono abituate a vedere il servizio di supporto post-vendita principalmente come un costo. E' un errore, secondo Gerry McGovern, esperto di content management.

"Il servizio è il nuovo modo di vendere. Il servizio è il nuovo marketing. Con il progredire dell'automazione, i prodotti diventano sempre più uguali. È il servizio che vi distinguerà sul mercato. È per il servizio che farete la prossima vendita."

Nei progetti di sviluppo software il ruolo di committente è essenziale.
È il ruolo che di solito esprime la richiesta da cui avrà origine il progetto, legata a precisi obiettivi di business. Decide i principali requisiti che guideranno lo sviluppo, e che dovranno essere coerenti con quegli obiettivi. Alla conclusione del progetto, è il committente che accetta il prodotto finale.

Anche durante il progetto è il committente che deve prendere le decisioni più rilevanti. Spetta infatti a lui (o lei) decidere quali funzionalità e quali caratteristiche rientrano nei confini del progetto, e quali no. E quali sono i limiti di costo sostenibili ed i vincoli temporali da rispettare.

Quando poi una delle tre variabili principali di progetto (cose da fare, tempi e costi) cambia in corso d'opera, per effetto di eventi non previsti all'inizio, diventa necessario valutare gli impatti del cambiamento. La decisione su cosa sia opportuno variare come conseguenza diventa cruciale, ed è nuovamente di competenza del committente.

Se ad esempio emerge durante il progetto la necessità di realizzare una funzionalità inizialmente non prevista, bisogna valutare se sia possibile aumentare i fondi necessari per svilupparla, se dilazionare i tempi di rilascio, se aggiungere la nuova funzione eliminando o rimandando altre funzioni previste inizialmente, ma meno urgenti.

Decisione che spetta di diritto al committente, perché riguarda considerazioni legate agli obiettivi di business che solo lui può valutare in modo completo, e che rientrano nelle sue responsabilità.

Analogamente spettano al committente le decisioni da prendere quando si verificano casi di ritardo nei tempi di sviluppo: conviene spostare in avanti la data di rilascio del prodotto o mantenere la data prevista inizialmente, riducendo le funzionalità del prodotto precedentemente concordate?

Dal momento che il committente è il ruolo che prende le decisioni più critiche per il progetto (compresa, se e quando è il caso, quella di interromperlo), si tratta di un ruolo indispensabile, e deve essere chiaro a tutti chi lo riveste per tutta la durata del progetto stesso.

Uno dei fattori di rischio più pericolosi in un progetto di sviluppo software è la situazione in cui non è chiaro chi abbia il ruolo di committente, o in cui la persona ufficialmente designata a svolgere tale ruolo non abbia la capacità, la volontà o l'autorità sufficienti a prendere le decisioni quando diventa necessario farlo.

Il problema, in casi simili, è che il committente è un ruolo difficilmente sostituibile. In situazioni progettuali in cui altri ruoli sono svolti in modo poco efficace, si può far fronte con degli interventi correttivi in corso d'opera, come affiancamenti o sostituzioni; è invece improbabile che si possa invece intervenire con correzioni quando ad essere debole è il committente.