Archivi categoria: cliente

L’importanza del supporto utente

Mettere al centro il cliente, uno slogan che è di moda da anni, ormai un classico. Ma per passare dalle parole ai fatti bisogna fornire un ottimo supporto utente.

In molte aziende, invece, l’attenzione è centrata sul marketing e sulla vendita, e il supporto viene considerato un male necessario, se possibile da esternalizzare a terze parti. Grave errore, come spiega Gerry McGovern in If the customer really was king.

Smettiamola di chiamarli “utenti”

Chi visita il nostro sito, chi usa i nostri sistemi non è un “utente”,  non è un ruolo, è una persona reale.

Il termine “utente” implica una presa di distanza, tipica, secondo Gerry Mc Govern, del mondo IT: da un lato ci siamo noi specialisti, che progettiamo e realizziamo, dall’altro ci raffiguriamo il ruolo astratto dell'”utente”. Ma sono persone concrete, in carne ed ossa, ed è ora che iniziamo a pensare a chi accede ai nostri sistemi come un cliente da servire con cura, non come un’astrazione.

People are people, not users, di Gerry McGovern.

Processi di business: interazioni con i clienti

Modellare le interazioni con i clienti – utenti, e soprattutto le attività che clienti e utenti devono svolgere per interagire con la nostra organizzazione: è un passo fondamentale per migliorare le attività di customer service.

Lo si può fare usando in modo appropriato i diagrammi dei processi BPMN, come spiega Paul Harmon in questo articolo.

Requisiti e maieutica

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.

Il servizio fa vendere

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.”

Il ruolo di committente

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.

Tecno austerità

“Meno è meglio”.

“I tecnologi si stanno risvegliando ai vantaggi del minimalismo, per due motivi: il fastidio per l’eccessivo numero di funzionalità dei prodotti da parte dei clienti che vogliono solo che le cose funzionino, e una forte richiesta da parte di clienti meno ricchi provenienti dai paesi in via di sviluppo.”

The Economist, 12 giugno 2010.

Al prezzo più basso

Nelle gare d’appalto, spesso vince il fornitore che offre il prezzo più basso. E cominciano i guai, dato che “offerte e stime troppo basse sono spesso indicative di una scarsa competenza”.

How to avoid selecting bids based on overoptimistic cost estimates“, è un articolo di Magne Jorgensen, pubblicato su IEEE Software May/June 2009.
L’articolo riporta i risultati di una serie di studi e sondaggi, e offre una serie di raccomandazioni utili per il processo di selezione.

Product Owner

Il Product Owner è uno dei ruoli principali di Scrum, uno dei processi agili più diffusi.
In italiano, lo si può tradurre come “proprietario del prodotto”, o “responsabile del prodotto”.

Dal punto di vista di chi sviluppa software, corrisponde in linea di massima al ruolo di “committente”, cioè di chi ha la responsabilità di decidere i requisiti da soddisfare, le priorità di realizzazione, l’accettabilità dei risultati forniti dagli sviluppatori.

Certamente è il ruolo più importante per il successo di un prodotto, di un sistema. Ma è arduo da svolgere, perché non esiste un percorso formativo per diventare Product Owner, e può capitare che il ruolo non sia riconosciuto in termini di autorità e responsabilità all’interno delle organizzazioni.

Sul ruolo di Product Owner, uno scritto interessante di Jeff Patton.