sabato 8 giugno 2013

I limiti della logica e le potenzialità della creatività

Nel post "Partire dal problema" ti avevo parlato di un primo fondamentale accorgimento per generare nuove idee ovvero il fatto di iniziare con il trovare innanzitutto un problema da risolvere.
Nel post "Nascita o eclisse di un problema" abbiamo visto come lo stesso processo di emersione di un problema non sia una cosa comune e richieda una buona apertura mentale.

Sono quindi due le situazioni in cui potremo trovarci:
  • abbiamo trovato un problema che non ha ancora avuto una soluzione ovvero lo abbiamo fatto emergere
  • vogliamo trovare una soluzione migliore ad un problema che è già stato risolto 
Nel primo caso possiamo parlare di invenzione.
Se dovessi rendere graficamente questa situazione la rappresenterei con un punto in mezzo ad un foglio che rappresenta il problema che siamo riusciti a far emergere, un 'altro punto che rappresenta la soluzione ed una freccia che li collega. Ovvero tra noi e il problema c'è una enorme distesa di neve fresca e le nostre orme saranno le prime a tracciare una via.

Per trovare la soluzione posso ricorrere alla logica procedendo a piccoli passi verso il traguardo verificando costantemente che tutto il ragionamento regga.

Nel secondo caso possiamo parlare invece di innovazione.
Ovvero il problema era già stato risolto da altri ma noi vogliamo cercare una soluzione più efficiente. In questo caso troviamo davanti a noi un sentiero già tracciato ed abbiamo la necessità di inventare un nuovo percorso per arrivare alla meta con un vantaggio competitivo rispetto alla soluzione precedente.


E' stato dimostrato che utilizzare la logica per ideare nuove soluzioni è un processo estremamente inefficiente.
Se questa affermazione ti ha spiazzato allora prosegui leggendo il mio prossimo post in cui ti parlerò di uno scrittore che ha dedicato la propria vita allo studio della mente umana ed a come utilizzarla al meglio per essere più creativi.


sabato 18 maggio 2013

Nascita o eclisse di un problema


Nel post precedente ti ho raccontato la strana ed incredibile storia di come è nata l'idea del Post-It. Questo aneddoto mi è servito per ricordarti che, nel concepire una nuova idea, il problema da risolvere riveste un ruolo fondamentale.

Il concepimento

Se, della storia del Post-It ti chiedessi di evidenziare l'evento più rilevante probabilmente il tuo pensiero correrebbe al momento in cui Fry ebbe l'idea di utilizzare la colla di Silver per fissare i pezzi di carta nel libro dei canti.
In realtà, ci sono altri due momenti altrettanto importanti: il momento in cui Fry prende coscienza del problema ed il momento in cui decide di risolverlo.

Proprio come l'idea che servirà per risolverli anche i problemi devono innanzitutto essere "concepiti".
Un problema nasce quando:
  1. ti accorgi della sua esistenza
  2. ti poni l'obiettivo di trovare una soluzione

L'eclisse

Abbiamo individuato i due ingredienti fondamentali per la nascita di un problema ovvero il fatto di accorgersi di subirlo e il porsi l'obiettivo di risolverlo.
Se manca uno dei due ingredienti il processo di elaborazione di una nuova idea semplicemente non può partire.

Immagina ora che sia notte e tu stia dormendo. Una nuova idea bussa alla porta. Innanzitutto devi risvegliarti e subito dopo devi decidere di andarle ad aprire. Molte persone o non si svegliano o si svegliano ma si rimettono a dormire.

Mi spiego meglio.
Fry non è certo stato l'unico ad aver avuto il problema di mantenere il segno nelle pagine, sicuramente altri prima di lui avevano riscontrato questo problema, dunque che cosa ne è stato di loro?

Quando nel nostro cammino verso un obiettivo ci troviamo la strada sbarrata da un ostacolo la soluzione meno dispendiosa potrebbe essere quella di aggirarlo o di rinunciare a raggiungere l'obiettivo.
In entrambi i casi smetteremo di avere a che fare con il problema, o ne accetteremo la sua esistenza per convivere "pacificamente" con esso.

Possiamo immaginare che le persone che prima di Fry avevano avuto il suo stesso problema semplicemente o non lo hanno considerato un problema accettando il fatto che ogni tanto era possibile perdere i contrassegni posizionati nelle pagine dei canti prescelti o hanno accettato di rovinare le pagine del libro ripiegandone gli angoli per contrassegnarle. Per tutte queste persone il problema è così scomparso. O hanno accettato il problema in quanto tale o hanno accettato i difetti della soluzione "angoli ripiegati".

Io definisco questo processo come l'eclisse del problema.
E' un aspetto fisiologico della nostra esistenza: dobbiamo concentrarci su obiettivi importanti e dedichiamo una attenzione via via inferiore a tutti i problemi che classifichiamo di entità minore o sui quali non abbiamo voglia di cimentarci nell'elaborazione di una soluzione.

Benedetto Croce era bravissimo a non considerare problemi quelli che non sapeva risolvere
(Umberto Eco)

L'invenzione del carter

Prendiamo un'altro esempio: la bicicletta prima dell'invenzione del carter.
La bicicletta a pedali con trasmissione a catena fu inventata nel 1884 da John Starley. Per chi indossava i pantaloni l'utilizzo delle ghette era imprescindibile mentre chiunque si avventurasse a pedalare con gonne lunghe sapeva  che con buona probabilità avrebbe ridotto i propri abiti peggio della tuta di un meccanico.
Fu solo 9 anni dopo, nel 1893, che Harrison Carter inventò il suo sistema "Little Oil Bath", poi ribattezzato "cater".
Cosa è successo in questi 9 lunghi anni?
Gli uomini hanno accettato di doversi infilare e sfilare le ghette ogni volta che montavano in sella mentre le donne probabilmente hanno rinunciato ad utilizzare bicicletta e gonna insieme.
In questo modo, e succede molte volte, il problema si è eclissato: viene accettato e metabolizzato dal nostro cervello che smette di vederlo o di considerarlo tale.
Ed è proprio questo il momento cruciale: l'incontro del problema con una persona per cui anziché scomparire, il problema diventa rilevante, talmente rilevante da tentare di immaginare una soluzione per risolverlo.
Stai attento perchè sono proprio queste occasioni che generano nuove idee di business.
John Starley ha usato le ghette per 8 anni fino a quando ha deciso che le ghette non erano la soluzione adatta a lui e tantomeno a sua moglie. Ha inventato il carter, lo ha brevettato e poi lo ha venduto alla Sunbeam.

Riassunto

E' sorprendente quante opportunità ci circondino e stiano solo attendendo la persona giusta che sappia coglierle.
Anche le persone che ti circondano, i tuoi collaboratori, i tuoi clienti, i tuoi fornitori, possono essere obiettivo di osservazione e fonte di ispirazione per questa ricerca ma non aspettarti che siano loro a mettere in luce il problema. Come ti ho detto, non tutte le persone hanno "voglia" di far emergere i problemi, piuttosto sembra essere molto diffusa la capacità di aggirarli e di eclissarli.
Alcuni studi hanno messo in evidenza che la capacità di trovare un problema (problem finding) richiede essa stesa doti di creatività, apertura mentale e intuizione quindi non è raro che persone che sono in grado di cogliere un problema saranno poi in grado anche di risolverlo.
Trovare un problema da risolvere può quindi rappresentare un problema. Sembra paradossale ma è proprio cosi. Infatti, Getzels, un grande studioso di creatività e intelligenza ha scritto un libro intitolato: "Il problema del problema" che parla proprio di questo argomento.

venerdì 5 aprile 2013

L'invenzione del Post-It

Siamo in Texas. Nel 1962 Spencer Silver si laurea in chimica e nel 1966 viene assunto come ricercatore della 3M. La 3M è all'epoca già una ditta di fama mondiale con all'attivo molti brevetti come ad esempio quello dello scotch. Il desiderio di Spencer è quello di lasciare il segno nella azienda.
Nel 1968 Spencer sta cercando un nuovo adesivo ma sperimentando e modificando i componenti chimici ottiene qualche cosa di completamente nuovo: un adesivo poco potente ma che può essere attaccato e staccato molteplici volte.
Spencer sa di aver inventato qualche cosa di nuovo ma non riesce a trovare nessun uso pratico. Per convincere il management ed i colleghi della bontà della sua scoperta tiene dei seminari in azienda ma ottiene scarsi risultati.
Ad uno di questi seminari partecipa Arthur Fry.
Arthur si occupa delle applicazioni e della vendita dei prodotti inventati nella 3M ma anche per lui l'invenzione di Spencer non sembra avere nessuna applicazione.
La documentazione viene quindi messa nel cassetto e ci rimarrà per 6 anni.
Nel 1974 Arthur canta nel coro della sua chiesa. Per tenere traccia dei brani utilizza dei foglietti come segnalibri.
Il problema è che questi foglietti continuano a spostarsi e a cadergli per terra. Durante la celebrazione di un matrimonio quando proprio a lui tocca intonare la melodia perde il segno e nell'imbarazzo generale impiega diverso tempo per ritrovarlo.
Decide a quel punto che ha un problema da risolvere.
Ha bisogno che quei segnalibri rimangano incollati alle pagine ma che allo stesso tempo sia possibile staccarli e riposizionarli senza rovinare le pagine.
E' in quel momento che gli viene in mente il seminario tenuto dal suo collega Spencer alla 3M: la colla "che si attacca e si stacca" è perfetta per quello che ha in mente.
I primi prototipi furono disponibili nel 1977, e nel 1980–1981, dopo una poderosa campagna, il prodotto fu posto in vendita in tutto il mondo.

Sensazionale vero? Ti ricorda qualche cosa?
Spencer ha inventato la colla ma non ha idea di come utilizzarla.
Arthur ha un problema, si pone l'obiettivo di risolverlo ed utilizza l'invenzione di Silver
Questo episodio dovrebbe averti convinto di quanto detto in precedenza: se vuoi inventare qualche cosa parti dalla ricerca di un problema da risolvere e tutto sarà più facile.

Nel prossimo post divideremo i problemi in due categorie: quelli che non hanno ancora avuto una soluzione e quelli già risolti.

domenica 10 marzo 2013

Partire dal problema




Come programmatore ti viene richiesta una buona preparazione tecnica ovvero la capacità di far funzionare nel mondo reale l'idea della committenza nel modo più efficiente. Tradurre un "materiale" davvero incredibile come le idee in algoritmi e interfacce è il tuo lavoro, il tuo pane quotidiano: devi preoccuparti di aspetti come usabilità, sicurezza, scalabilità... insomma di tutto quello che sta tra l'idea e la sua implementazione. Sappiamo molte cose perché siamo personaggi curiosi e geniali, per questo ogni tanto (penso che sarà capitato anche a te), quando ti trovi a realizzare una idea "che funziona" ti chiedi come abbia fatto a pensarci il tuo cliente?


Da dove arrivano le idee? Qual'è il processo che porta alla loro genesi?

Inizialmente pensavo ingenuamente che bastasse "spremersi le meningi", concentrarsi, ovvero che bastasse mettere in campo lo stesso processo che si utilizza per risolvere problemi di implementazione: ovvero applicare un metodo analitico per arrivare velocemente all'obiettivo.
Purtroppo questi tentativi si sono rivelati infruttuosi e questo per un semplice ed ovvio motivo: manca un obiettivo.

Se dovessi rendere "graficamente" questo tentativo lo disegnerei cosi:
Ovvero un punto centrale che rappresenta il punto di partenza dal quale viene dispersa una grande quantità di energia tutto attorno.

I motivi della mia "mancanza di idee" erano quindi riconducibili all'utilizzo di  un approccio totalmente inadatto allo scopo. L'approccio più produttivo (che è anche  radicalmente diverso se non addirittura l'inverso di quello sperimentato in precedenza) è molto semplice: partire dal problema.



Questo approccio è molto più efficace perché non brancoliamo nel buio,  ed efficiente perché ci garantisce anche che l'idea avrà implicitamente una sua applicazione.


Spirito di osservazione

Per "trovare una idea" devi "cercare un problema". La tua fonte di ispirazione è già sotto ai tuoi occhi devi solo imparare a farci caso. Sembra banale ma è così: tutto quello che ci serve è già sotto i nostri occhi, dobbiamo solamente osservare e mettere in relazione.

Nel prossimo post ti parlerò della incredibile storia dell'invenzione del Post-IT.

Michel Joli, un ingegnere francese scrisse: "la creatività è l'arte di definire i problemi e suggerire soluzioni".

domenica 27 gennaio 2013

Modelli di business


L'idea giusta non basta: modelli e strategie di business

Ci sono persone a questo mondo che sprecano energie immani su idee che semplicemente sono sbagliate. Analizzare questi casi è utile e divertente ma in questo post darò per scontato che quando parliamo di "idea" intendiamo perlomeno "qualche cosa che sia utile a qualcuno".

Idee che non fanno soldi

Sei convinto che per realizzare una impresa basti una buona idea?

Prendiamo ad esempio l'ecommerce.
L'idea fu davvero rivoluzionaria: usare internet per far acquistare i propri prodotti a clienti di tutto il mondo comodamente seduti a casa loro! Fu incredibile:  d'un tratto molti imprenditori che non avevano nemmeno una email si misero a pensare a come portare la loro attività su internet.  Oggi l'ecommerce muove capitali di milioni di euro... ma che fine ha fatto l'inventore dell'ecommerce? Purtroppo per lui, possiamo presumere che non guadagni un solo centesimo di tutta questa massa di denaro.
La stessa sorte è toccata all'inventore dei forum.
Idea fantastica: consentire agli utenti di scambiarsi opinioni in una serie di botta e risposta etc etc... una specie di anticamera  del social network... ma anche in questo caso possiamo immaginare che il suo inventore oggi sia ben lungi dal guadagnare anche solo  lo 0,000001% dei guadagni di Mark Zukeberg e sicuramente non realizza questo introito grazie ai forum.

Non basta una idea geniale/rivoluzionaria per fare soldi.

Il modello di business

Il primo passo è estendere la nostra visione ad un modello più ampio che comprende e completa la nostra idea: il modello di business.
L'essenza  del modello di business è definire la maniera in cui:
- l'impresa da un servizio all'utente
- l'utente paga per questo servizio
- l'azienda converte questo denaro in profitti
Molti fallimenti di piccole aziende informatiche sono dovuti proprio al fatto che il management si è fermato al primo punto di questa lista e preso dall'entusiasmo ha dato il via alle danze ("...iniziate a scrivere codice!") senza conoscere gli altri 2/3 del problema.
Per arrivare ad un modello di business quindi devi:
- conoscere cosa vogliono i tuoi clienti
- come lo vogliono
- come organizzarti in modo da fornigli un servizio che incontri al meglio le loro esigenze
- come farti pagare per farlo
- e come ricavare da ciò un margine di profitto

Se hai una buona idea hai un grosso problema 

Nemmeno sviluppare un modello di business di successo sarà sufficiente a metterti al sicuro:  se funziona altri si metteranno all'opera per replicarlo e "farti le scarpe".
Ad aggravare questo problema, per le aziende che offrono servizi tramite internet, è  il fatto che solitamente il modello di business utilizzato traspare chiaramente almeno nei suoi aspetti principali. Il modello di business viene cosi offerto ai concorrenti su un piatto d'argento pronto per essere replicato.
Nonostante questo grande svantaggio, un modello di business potrebbe comunque essere progettato per risultare di difficile replicazione.

Strategie di business

La soluzione del problema della replicabilità di un modello di business è la chiave di volta del suo successo. Per questo motivo il modello di business deve includere una vera e prorpia strategia di business atta a difenderlo dalla concorrenza.
Mentre, come dicevamo, il modello di business è trasparente, la strategia lavora come un vero e proprio scudo invisibile. E' forse l'aspetto più affascinante di tutta la vicenda.

Nei prossimi post ti illustrerò alcune strategie utilizzate da piccole e grandi softwarehouse.

martedì 15 gennaio 2013

23:30 - 24:00



Se è vero che il valore di ogni risorsa è inversamente proporzionale alla sua disponibilità, il tempo per me è diventato come acqua nel deserto! Tolto quello da dedicare al lavoro, al figlio, alla moglie alla casa e ad un minimo di vita sociale non ne rimane molto. Finalmente, ora, dopo venti mesi infernali il mio cucciolo ha deciso di non crocefiggerci più con pianti insopportabili dalle 10 alle 2 di notte: ora verso le 11 mi infilo nel letto con lui e magicamente nel giro di qualche minuto crolla. Alcuni amici mi raccontano che i loro figli regolarmente alle 9:30 sono già sotto le coperte che ronfano. Un paio di volte è capitato anche a noi ed io e mia moglie eravamo quasi schizzati dall'euforia. Purtroppo sono state autentiche "botte di culo" alle quali non eravamo psicologicamente preparati. Quello che ora ho con certezza è una mezzo'ora: tra le 23:30 e le 24:00. Andare a letto più tardi mi ridurrebbe uno zombie strafatto di caffeina il giorno dopo... Quindi mi si è posto il "problema" di come usare questa mezz'ora.
Ho molti progetti nel cassetto delle idee ma... a colpi di trenta minuti impiegherei 2 anni per realizzare anche solo il più piccolo di essi: mi fa venire il mal di pancia solo a pensarci.
Ci vuole qualche cosa di piccolo, che dia risultati "immediati" un po' come le uniche diete che riesce a seguire mia moglie: dieta dei 17 giorni, dei 15 giorni... chi mai ci arriverebbe alla fine di una dieta che ti prospetta risultati dopo mesi? E' chiaro che molli!
Lasciamo chiuso il cassetto delle grandi/medie idee, almeno per ora, ed apriamo dunque quello delle idee piccole e piccolissime.
Oltre a porsi tanti obiettivi che siano raggiungibili nel breve termine è importante che tutti questi piccoli sforzi abbiano un filo conduttore che mi spinga passo dopo passo. Un po' come un modello di business che funziona: una macchina in cui, metto energie ma che restituisca anche benefici ed entusiasmo per autoalimentarsi.

L'idea piccola che ho avuto, dopo averne letti a centinaia e centinaia, è quella di aprire questo blog.
L'obiettivo è quello di riuscire a scrivere almeno un paio di post al mese.
La finalità di questo blog, ovvero il filo conduttore di tutti i post, è sia quello di poter aiutare altri programmatori scrivendo cose interessanti e utili, sia quello di presentarmi meglio sotto il profilo professionale che personale. Scrivere, inoltre, aiuterà anche me: spiegando ad altri alcuni concetti rende poi più facile ricordarli.

Come regola di rispetto nei tuoi confronti ho preso la granitica decisione che non pubblicherò mai ciò che a me farebbe girare le scatole.

Al rogo quindi post de tipo "Oggi la Microsoft mi ha rinnovato come MVP!"... e chi se ne frega! "Oggi ho cambiato posto di lavoro dalla ditta x alla ditta y"... aridaje! Ti eri iscritto sperando di leggere cose utili. Che ne dici? Ma questi messaggi sarebbero solo spam. Esistono strumenti appositi per gestire questo tipo di informazioni (come linkedin, come una pagina curriculum sul blog). Voglio quindi evitare di fare anche io un errore del genere. (e questo sassolino me lo sono tolto!)

Al rogo post del tipo "Copio qui il post di tizio perchè lo condivido" ... che sforzo! Condividere non costa nulla ma non aggiunge nulla! Quindi mi impegno a non condividere soltanto facendo un copia e incolla da altri siti! Promesso.

Dunque al lavoro... mentre il pupo dorme!


domenica 6 gennaio 2013

Non vivere con le finestre rotte ovvero la teoria delle finestre rotte



Nel capitolo "Software Entropy" di "Pragmatic Programmer" ("Entropia del software") Andrew Hunt e David Thomas, citano questa interessante teoria che a mio avviso è perfettamente applicabile anche al mondo del software. In breve la teoria dice che:

"Piccoli segni di incuria in un quartiere tendono ad instillare negli abitanti un senso di degrado che a sua volta porta via via a fenomeni di emulazione o peggio. Una semplice finestra rotta, se non viene riparata, verrà notata dagli altri abitanti ed alcuni di loro potrebbero lasciarsi prendere dallo sconforto e tollerare a loro volta incurie nelle loro abitazioni che normalmente avrebbero provveduto a riparare. In un tempo più o meno lungo quindi una semplice finestra rotta che non viene riparata è capace di creare problemi ben più gossi." 
Se entrassi in una casa tipo queste (case da incubo) sicuramente nessuno noterebbe che non ti sei pulito le scarpe prima di entrare. Addirittura potrebbe venirti spontaneo e "in linea" appiccicare la tua gomma da masticare sotto la sedia prima di andartene.
Così come esistono "case da incubo" e "quartieri da incubo", esistono anche "software da incubo" che sono lentamente ma inesorabilmente scivolati nel degrado a causa di questo "contagio".

Ma non fare confusione: la teoria parla di "finestre rotte" e non di situazioni ormai fuori controllo.
Ripara la finestra prima che sia troppo tardi e che i problemi siano diventati ben più gravi
In progetti piccoli e di breve durata una finestra rotta, qualche copia incolla, qualche query scritta con i piedi etc... difficilmente condurranno il progetto alla degenerazione.
Il progetto molto lunghi (anni) invece dovrai convivere con queste oscenità per molto tempo e se non provvederai a riparale esse cominceranno a diffondersi fino a generare metastasi.

Un messaggio anche ai manager: in un progetto importante è fondamentale che i vostri programmatori scrivano codice di buona qualità scordatevi il "basta che funzioni".