Arrivederci

Tra poche settimane uno dei nostri collaboratori lascerà l'azienda per intraprendere una nuova attività professionale.
Mi si intrecciano tre sentimenti parzialmente contrastanti.
Da una parte c'è il problema di trovare un sostituto, mandare avanti i progetti, fare il passaggio di consegne, non far percepire impatti negativi o ritardi ai clienti ...
E' l'aspetto razionale: la perdita di un collega valido e di esperienza crea scompensi ma esistono i meccanismi e gli strumenti per porvi rimedio; una cosa che fin dall'inizio ho imparato è che nel nostro lavoro nessuno è insostituibile, ci sarà per un po' da stringere i denti e fare qualche sforzo in più, fino a trovare un nuovo punto di equilibrio.

Poi c'è un po' di egoismo e sconforto: dopo due anni e mezzo di lavoro insieme, fatiche, insegnamenti, ecc., questa persona se ne va.
Ma veramente avrà un lavoro migliore? Vale la pena che io ricominci da capo per ottenere di nuovo tra un po' lo stesso risultato? O sarebbe meglio "chi fa da sè fa per tre".

Infine c'è anche l'orgoglio: una persona che, neolaureata, ha iniziato a lavorare con noi adesso ha raggiunto risultati e una maturità che le permettono di continuare per la sua strada.

Mentre riflettevo, mi si è affacciato un pensiero. Credo che egoismo ed orgoglio siano i sentimenti che provano i genitori quando i figli se ne vanno per la loro strada: i miei sono ancora troppo piccoli per cui non lo so ancora, ma sicuramente i colleghi li sento un po' figli. E purtroppo c'è quasi anche la differenza di età...
In ogni caso (figli veri e figli lavorativi) spero prevalga l'orgoglio sull'egoismo.

Un programmatore nello spazio o meno spazio ai programmatori

Da ieri Charles Simonyi è nello spazio come passeggero della Soyuz russa diretta alla stazione spaziale internazionale: http://www.charlesinspace.com .
Charles Simonyi è un programmatore d'eccezione: dal 1981 al 2002 ha lavorato in Microsoft, fino ad essere Direttore dello Sviluppo Applicativo, e grazie alla progettazione e realizzazione di molte versioni di Office (in particolare Word ed Excel) ha fatto la fortuna dell'azienda e sua, fino a potersi permettere di fare il turista spaziale (uno sfizio da 20 milioni di dollari).
E' meno noto che Charles Simonyi nel 2002 ha lasciato Microsoft per poter continuare le proprie ricerche nel campo della programmazione intenzionale, fondando una nuova azienda dal nome Intentional Software .
Intentional Software si propone l'ambizioso obiettivo di trasferire all'interno del software l'enorme sforzo di conoscenza che oggi resta confinato alle fasi di analisi e realizzazione ma che poi si disperde in quanto scarsamente documentato al di fuori dei sorgenti. Questo valore latente ed irrealizzato è normalmente conosciuto come software intent, cioè l'obiettivo che il sistema si propone di ottenere: da qui il nome dell'azienda.
Intentional Software sposta il focus dell'attività progettuale alla descrizione del dominio applicativo e degli obiettivi che con il sistema si intendono raggiungere, fase in cui più che i programmatori sono coinvolti gli utenti e gli esperti del settore; una volta definito il design, il codice potrà essere generato in automatico. Il processo, tra l'altro, può essere ripetuto iterativamente evitando che il codice diverga dal design iniziale facendolo diventare obsoleto.
Ad oggi Simonyi non ha ancora rilasciato un prodotto nè si sa quanto questo sia ancora lontano nel tempo, ma - oltre che dall'indubbia statura del personaggio - la bontà dell'approccio è dimostrata dal fatto che tra i (pochi) clienti della sua azienda vi siano nomi del calibro di Capgemini e Thoughtworks.

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.