5 cose da non dire mai ad un cliente

Consigli per il Customer Service e per chi in generale è a contatto con i clienti:

1. Una bugia. Sembra ovvio, ma è una bugia anche cercare di vendere a tutti i costi i propri prodotti / servizi quando non sono la scelta migliore per il cliente: è molto meglio ammetterlo esplicitamente e consigliarli un concorrente.
2. E' colpa di un altro ufficio. Al cliente non interessano i problemi organizzativi interni, soprattutto se servono per fare scaricabarile.
3. Non sono d'accordo. Discutere con un cliente, frustrato o arrabbiato, non porta da nessuna parte: è meglio mostrare comprensione e cercare di pilotare la conversazione verso una soluzione accettabile per entrambe le parti.
4. Non so che cosa fare. Chi rappresenta l'azienda non può non conoscerne i prodotti: se necessario, è meglio fare escalation verso un superiore o un esperto.
5. E' colpa tua. Non è giusto rinfacciare al cliente di non sapere come funziona il prodotto: non gli è stato spiegato prima, bisogna farlo adesso.

Tratto da Fast Company Expert Blogs: Valeria Maltoni, 5 Things you should NEVER tell a Customer .

I computer del futuro (molto vicino)

Le console per i videogiochi sono dei computer. Sono specializzati nell'effettuare alcune operazioni, grafiche in particolare, ed hanno sistemi operativi diversi dai normali PC ma comunque sono dei computer; anzi, sono molto più potenti e veloci dei normali PC.
La nuova Playstation 3, disponibile in Europa da questa settimana, è equivalente ad un server di medie dimensioni, di quelli che si trovano unicamente nelle grandi aziende.
Oltre ai giochi, qualcuno comincia ad usare questi "mostri" anche a scopo scientifico.
Un ricercatore canadese, ad esempio, ha utilizzato proprio la Playstation 3 per realizzare un esempio di un nuovo sistema di programmazione multi-threaded, cioè un sistema in cui diversi eventi vengono gestiti parallelamente ed indipendentemente dai processori presenti nella macchina. La demo rappresenta migliaia di polli gestiti ciascuno autonomamente dall'altro dai processori della Playstation: http://www.csclub.uwaterloo.ca/media/Riding%20The%20Multi-core%20Revolution.html.

Chi lavora e chi no ...

Il Corriere della Sera di oggi pubblico un articolo di Francesco Giavazzi in cui si spiega come negli ultimi anni la Spagna abbia creato un numero di posti di lavoro tre volte maggiore dell'Italia (7 milioni contro 2,5 milioni) a beneficio soprattutto di ultra-sessantenni, donne e giovani.
Uno dei molti aspetti che colpiscono è la differenza di partecipazione dei giovani alla forza lavoro nei vari paesi, con l'Italia in buon ultima posizione e le cause da ricercarsi essenzialmente nella scarsa qualità del sistema scolastico.
Giavazzi conclude, giustamente, facendo notare come un investimento sull'istruzione porterebbe risultati positivi in termini di crescita economica in quanto si tradurrebbe in una maggiore partecipazione dei giovani alla forza lavoro e in un maggior numero di posti di lavoro.
A differenza dei soliti incentivi richiesti dalle aziende per aumentare la produttività mediante l'utilizzo di tecnologie che invece hanno fino ad oggi avuto pochissime ricadute positive.
Mi viene da pensare, allora, che l'effetto positivo di un investimento sul sistema della formazione sarebbe addirittura duplice: la propensione all'innovazione e all'utilizzo della tecnologia da parte dei giovani è sicuramente maggiore e quindi alla fine potrebbe anche aumentare la produttività per addetto e non solo il numero degli addetti.

Progettazione del software: niente di nuovo sotto il sole

Ormai più di venti anni fa ho iniziato ad occuparmi di software, ed in particolare mi ha sempre interessato la sua progettazione.
Nonostante i cambiamenti radicali e la rapidissima evoluzione tecnologica, mi sembra che poco sia cambiato in questa attività, soprattutto nella sua prima fase: la definizione dei requisiti.
L'analisi dei requisiti è il momento cruciale in cui viene definito che cosa deve fare un sistema e come: tutte le attività che seguono (progettazione, realizzazione, test, avviamento, ...) non sono che una conseguenza; se i requisiti sono errati, ammesso e non concesso che il sistema li rispetti, farà comunque qualcosa che non va bene.
Questa riflessione sull'importanza e la criticità dell'analisi iniziale e sulla scarsa evoluzione è stimolata dalla lettura di un articolo di Esther Schindler pubblicato oggi su CIO: "Getting Clueful: Five Things CIOs Should Know About Software Requirements" (http://www.cio.com/advice_opinion/development/five_things_it_managers_should_know_about_software_requirements.html?CID=29903).

Le 5 cose da sapere identificate dall'autrice sono, purtroppo, le stesse di 20 anni fa (e anche 30) e tutt'altro che facili da risolvere in pratica (i commenti di fianco ad ogni voce sono miei):

1. L'identificazione dei requisiti ha diversi ruoli (stipulare il contratto, definire le funzionalità del software) che non necessariamente richiedono lo stesso livello di dettaglio e precisione.
2. L'utente finale deve essere coinvolto nel processo di definizione iniziale. Sembra banale ma, a parte che non è sempre facile a farsi, non necessariamente porta ad un risultato di qualità: l'utente è bravo ad usare un sistema per svolgere una determinata attività, normalmente non nel concettualizzare queste funzionalità ed immaginarsele sulla carta.
3. I requisiti devono avere il giusto livello di dettaglio. Nella maggior parte dei casi, cioè nel mondo del software gestionale, ciò è totalmente soggettivo e dipendente dal contesto e dalle persone coinvolte nelle diverse fasi del progetto.
4. I requisiti sono destinati a cambiare. E' una certezza della vita, il saperlo però non ci aiuta molto nella gestione del cambiamento in corso d'opera.
5. E' necessario ascoltare chi realizza il progetto ed agire di conseguenza. Non c'entra molto con l'identificazione dei requisiti (sulla carta le applicazioni software sono tutte perfette) ma vale sempre...

La sindrome del programmatore

Nei progetti di sviluppo software, semplificando, sono impegnate due figure: i tecnici e i funzionali.
I tecnici realizzano il software sulla base delle specifiche funzionali, lo fanno funzionare e si occupano di tutti quegli aspetti di dettaglio molto complicati senza i quali niente funzionerebbe.
I funzionali devono avere il quadro complessivo del progetto e fare da interpreti tra le esigenze concrete degli utenti, per cui il prodotto è una scatola nera, e gli aspetti tecnici di progettazione e produzione.
Sul mercato stanno arrivando alcuni strumenti di progettazione e sviluppo software che permettono anche ai funzionali di produrre applicazioni, o una parte di esse, in modo grafico e senza scrivere codice.
I vantaggi in termini di produttività ed efficienza sono evidenti, anche se l'apprendimento è tutt'altro che immediato; l'utilizzo ha però determinato anche un curioso ed imprevisto effetto: il funzionale si ammala con la sindrome del programmatore.
Anche lui, cioè, è tutto preso dal dettaglio realizzativo e rischia di perdere di vista il quadro d'insieme.
La morale: non basta lo strumento, ma deve cambiare anche il processo: il modello di relazione tradizionale e testato tra funzionali e tecnici deve modificarsi per fare in modo che entrambi possano sfruttare i benefici di questi strumenti ma senze perdere le specificità dei propri ruoli, entrambi indispensabili per arrivare al risultato.

Corretto utilizzo della tecnologia: produttività e sicurezza

Quanto è successo in un ospedale di Firenze questa settimana è raccapricciante: per un errore di trascrizione a tre persone sono stati trapiantati organi sieropositivi.
Se cerco di analizzare questo episodio dal lato organizzativo, tralasciando per quanto possibile gli impatti umani, sono ancora più preoccupato dal vedere l'ennesima manifestazione di uno dei maggiori problemi italiani.
Nel nostro paese, infatti, la tecnologia non si inserisce in un processo per modificarlo, ma gli si aggiunge duplicandolo. Sia nel contesto aziendale (l'email non sostituisce la carta o il fax ma raddoppia la comunicazione e la complicazione) sia in quello della pubblica amministrazione (dove timbri e marche da bollo regnano sovrani e nel caso sia possibile effettuare operazioni via internet è poi quasi sempre necessario stampare, firmare e spedire).
Fino ad oggi eravamo convinti che questo fenomeno fosse unicamente responsabile del deficit di produttività tra Italia e paesi sviluppati. Purtroppo abbiamo scoperto che le conseguenze possono essere ben più gravi sul piano individuale di salute e sicurezza: la macchina fa le analisi, ma l'uomo deve ricopiare i risultati; come se ricopiare non fosse un'attività fatta meglio da una macchina che da un uomo.
Non intendo assolutamente dire che il processo dovrebbe essere completamente automatico, ma forse l'uomo sarebbe meglio impiegato per un controllo, l'eventuale interpretazione di valori dubbi e una firma di approvazione.
Penso di non sbagliarmi dicendo che qualità del lavoro, produttività e sicurezza ci potrebbero solo guadagnare.

Sistemi Informativi ombra

Oltre a quelli ufficiali, gestiti dalla direzione o funzione ufficiale, le aziende hanno anche dei sistemi informativi ombra, cioè utilizzati per lavorare ma fuori dal controllo aziendale.
Qualche esempio:

• gmail: posta elettronica accessibile ovunque, in cui è facile trovare un documento e senza i limiti di spazio normalmente imposti alla casella aziendale;
• instant messenger: strumento collaborativo per interagire con colleghi e collaboratori;
• skype: telefono via computer;
• siti di condivisione di documenti e collaborazione: per aumentare la produttività dei rapporti con colleghi fornitori e clienti.

Sicuramente la direzione IT non dorme sonni tranquilli (e neanche il top management se e quando se ne rende conto): l'utilizzo di questi strumenti espone a rischi non direttamente controllabili dati ed informazioni riservati o potenzialmente tali.

D'altro canto i vantaggi sono innegabili e il trend sembra inarrestabile.

In parte è una storia già vista: quando il personal computer è entrato nelle aziende lo ha fatto a partire dalle scrivanie degli utenti, fuori dal controllo dell'IT; solo successivamente quest'ultimo se ne è appropriato per mettere un po' di ordine e di controllo (e di burocrazia) quando il fenomeno è esploso. Di conseguenza, è probabile che di nuovo accadrà qualcosa di simile.