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.