Mi sono sempre chiesto se la mia personale ed istintiva via al management avesse un razionale difendibile dinanzi ai “grandi esperti” tipici delle società di consulenza o delle aziende tradizionali. Adesso ho un riferimento preciso: Vittorio Viarengo, VP Product development niente meno che di Oracle, che dice esattamente le cose che professo sul campo da anni. Ma Vittorio non è certo venuto in Italia solo per darmi ragione (eh eh), di cose ne ha dette tante e -persino- qualcuna su cui NON ho potuto non intervenire sostenendo che “per quella strada” si finiva tutti male.

Vabbhuo, oggi va così, una volta tanto faccio il blogger (arghhhhh) un poco autoreferenziale, ma il succo c’è, quindi cliccate pure avanti fiduciosi.

I capitoli della storia di oggi, si potrebbero intitolare così:

• Tutte le storie (di successo) portano in CA, ovvero: “Come diventare VP di Oracle partendo da Genova”
• Il management che ci rende tutti mini-imprenditori
• Il buono del metodo Scrum
• Il cattivo del metodo Scrum
• Il sistema Torinese per l’innovazione ed i nuovi amici de La Storia del Futuro

Tutte le storie (di successo) portano in CA

La storia di Vittorio è una storia esemplare. Due amici con la passione per il software che partono dall’università di Genova e -tassello dopo tassello- compiono il mosaico necessario per diventare azienda. Senza incubatori. Senza Venture Capital. Solo con il supporto della loro stessa forza lavoro, della loro testardaggine e -al più- il supporto più morale che economico della mamma.

In tempi difficili come i nostri -certamente più complessi di ieri- sembra impossibile che due ragazzi possano fare altrettanto, ma anche 15anni fa -quando Vittorio ha cominciato la sua scalata- non era una passeggiata.

Innanzitutto alla base c’era una idea innovativa -piccola a piacere- capace di rendere la microazienda genovese utile a qualcuno di grosso. Una attenzione spasmodica al cliente finale, ed un buon time to market, hanno fatto sì che si potesse arrivare a vendere l’azienda genovese (non scalabile più di tanto e ceduta sulla base del mantra: vendi, guadagna e pentiti) ad un player statunitense (Boston, MA), nel quale -da buon italiano intelligente e lavoratore- ha potuto far rapidamente carriera (sono bastati un paio di anni) e finire prima in BEA (quindi California) e poi in Oracle (sempre in California).

Non posso che essere estremamente lieto dell’esito della storia professionale di Vittorio, e non posso non notare che si tratta dell’ennesima storia a lieto fine che non riesce a fare a meno della Silicon Valley.

Certo esistono infinite storie a lieto fine che NON hanno a che fare con la California, ma la quantità di storie di successo che -invece- termina sulle rive del Pacifico è numericamente impressionante.

Il management che ci rende tutti mini-imprenditori
La Storia di Vittorio di successo raccontata da Vittorio si basa su alcuni approcci forti. Non necessariamente nuovi, ma certamente tali da richiedere coerenza sul campo. Quella coerenza che -troppo spesso- viene derogata per ragioni del tutto distanti dal business o dal bene della company. Vediamo quali sono queste regole:

- Assumere gente che aiuti a costruire la cultura aziendale che vuoi dare alla tua startup. Il DNA è qualcosa che rimane sempre! Non cambia nonostante gli anni! Quindi va costruito bene!

- Assumere sempre i migliori! I grandi leader non hanno paura ad assumere gente più in gamba di loro. A+ assume A+, B assume C.

- Cercate il talento NON la conoscenza. Il talento è l’arte di imparare, la conoscenza -da sola- è sempre limitata.

- Tenete a mente le motivazioni necessarie per sedurre e trattenere e persone di talento!
1. cambiare il mondo. 2. parlare direttamente con il boss. 3. soldi

- Hire Freaks! Avete mai visto una cosa pazzesca realizzata da uno normale?

Ma le regolette non bastano. E’ necessario guardare con onestà alle necessità di vita delle persone che vuoi prendere con te, tenendo conto che -spesso- una startup significa mettere famiglia, socialità, sesso in seconda (o terza) fila. Non sempre la persona giusta è nella fase giusta.
Infine, serve tenere conto di una regola che vale sempre: Non puoi cambiare le persone

D’altro canto, se hai una buona idea e buone persone, la tua company ha una possibilità (su un milione). Se non hai delle buone persone, hai già perso.

.
E qui arriviamo al fatto che un certo approcio di management -a partire dalla selezione dei tuoi compagni di avventura- finisce per trasformarci tutti in mini-imprenditori di se stessi.
Infatti, persone così in gamba abilitano metodi di lavoro drasticamente innovatici -come lo Scrum di cui parleremo tra pochissimo- e questo finisce per appiattire le gerarchie complessive e svuotare di middle-management le società. Con persone e metodi nuovi, chi dirige può scordarsi di “gestire le persone” e deve concentrarsi su recruitiment, retaining, motivazione, rimozione degli ostacoli, strategia. Per dirla con le parole di Vittorio -che condivido così tanto che potrei averle dette io stesso- chi “gestisce” badare solo a: Manage the Vision, MENTOR People, get out of the way.

MAI INTERROMPERE IL PROCESSO DI SCRITTURA DEL CODICE (o il fluire del talento in generale)
una cosa che costa troppo è il manager che cambia le priorità, perchè ha una demo, etc.

Semmai serve un metodo che dia al lavoro la giusta granularità e focus. Per questo però c’è lo Scrum.

.

Il buono del metodo Scrum
Lo Scrum ricorda tantissimo l’approccio progettuale chiamato Agile che -estremizzando- si potrebbe definire come:”spezza il tuo prodotto in cose che si possono realizzare in pochissimo tempo e sottoponile sempre al tuo cliente/utente“.

Questo approccio nasce da alcune considerazioni di base -magari non condivisibili- però spesso molto vere o quantomeno efficaci:

1) Dato che moltissimi progetti software finiscono per non rientrare nei tempi o nel budget previsto, e alla fine bisogna correre scompostamente ai ripari… Allora meglio approcciare sin dall’inizio tutto il processo, lavorando sempre come se si fosse a due settimane dal Go Live. Ovvero, con cicli di produzione e delivery di sole due settimane. Aggiungendo un tassello alla volta. Essendo sempre disponibili a buttare via l’architettura di base e rifarla.

2) Con deliverable così definiti e limitati nel tempo, bisogna approcciare il coding come farebbe Yoda: “Do or not to do. There is no try”. Se un ingegnere si prende la responsabilità di un pezzo piccolo a piacere, poi deve portarlo a termine senza possibilità di errore. Il vocabolario stesso del team si riduce, rendendo anacronistici frasi e termini come “spero di“, “vorrei“, “forse…“, “non sarebbe bello se…”

3) Un team strettissimo 5/7 persone che comunica molto mentre NON scrive il codice, ma che si da responsabilità personali e verticali (ognuno per la sua competenza) molto precise: clear decision owner, one ass to kick. Che poi altro non è che un pezzo del mantra per cui -quando si mette male- bisogna tagliare presto, tagliare profondo: “cut deep, cut early”.

4) Poco spazio alle chiacchiere. Se un meeting dura troppo significa che si sta ragionando su cose non fondamentali. Estremizzando: i meeting si fanno in piedi

Ecco che -con queste logiche alla base- il manager deve solo spezzettare adeguatamente il lavoro, mentre sono poi i singoli ingegneri a prendersi carico delle parti che intendono sviluppare. Così, a salti di una o due settimane alla volta, il progetto procede e finisce sul monitor del cliente.

.
Il cattivo del metodo Scrum
Per un approccio che adoro, ovvero quello del management di scrum-team:”Manage the Vision, MENTOR People, get out of the way”, c’è parecchio altro che -personalmente- non condivido.

Innanzitutto va detto che questo metodo è davvero roba che funziona solo con sw engineers e coders di ogni ordine e grado. Ovvero gente che -per lavorare bene- ad un certo punto deve isolarsi con la macchina e condurla a far ciò che lui desidera a suon di codice. E’ evidente che esistono ambiti più creativi o -semplicemente progettuali- dove tutto ciò non ha senso.

Inoltre, ho la CERTEZZA (e ne ho poche) che Scrum possa al massimo condurre una azienda a realizzare lo stato dell’arte di una qualsivoglia realizzazione software, mentre è quasi sempre inadatto a realizzare innovazione radicale o -semplicemente- qualcosa di davvero fico.

Faccio un esempio: Google usa un approccio molto vicino a Scrum. Micro-team, delivery ogni 15gg, tutto subito sul banco di prova del’utente finale. Ma estetica e innovatività sono del tutto assenti nei prodotti Google. Si tratta di mero muscolo del codice. Di forza bruta. L’eleganza -e penso a Flickr preYahoo- non è prevista.

Certo, anche la mia può sembrare una generalizzazione eccessiva, ed allora vi voglio sottoporre la questione nodale: la composizione del team ed il suo costo.

Detto brutalmente, i team di 5/7 persone servono ad avere il controllo -da parte del management- di progetti complessi e RISPARMIARE un sacco di soldi nel making, mentre si comincia da subito la raccolta. Solo per questo si pone immediatamente il prodotto agli utenti.

D’altro canto, lo stesso Vittorio di Oracle dice: I clienti vanno ascoltati e coccolati, ma attenzione a non ascoltarli TROPPO se no si finisce a fare il prodotto per l’anno prima.

Ma se la voglia di risparmiare delle aziende si riflette in una composizione del team dove TUTTI SONO CODER (o anche coder, o all’occorrenza coder), si finisce in un imbuto scarta qualità per cui non progetta più nessuno di compentente.

Non progetta il management.
Non progetta il team.
Non progetta il cliente.

Quindi si possono buttare via anni di skill in HCI o UCD, insieme a tutte le tecniche e l’esperienza nella produzione di una user experience eccellente e COMINCIARE A PROGRAMMARE e poi vedere come va.

Questa scuola di pensiero -in fin dei conti nata in Microsoft- è oggi applicata in tantissime aziende e -io credo- è il motivo per cui il software di Google, Oracle, Yahoo, Microsoft e -in casi più limitati- persino quello della Apple, fa abbastanza schifo.

Adesso non vorrei sembrare esagerato, ma essendo un designer nonché un tecnologo dall’approccio umanista, non posso non vedere conseguenze ancora più diffuse e gravi di un cattivo uso dello Scrum, ovvero: Ogni era ha i suoi protagonisti e modelli. Un’era dove il protagonista tipico è il software engineer ed il modello è lo Scrum, rischia di indebolire l’intera capacità di produzione di qualità in vaste parti del tessuto sociale. Un pò come la catena di montaggio e l’operaio dal ruolo super-specialistico e ripetitivo, è stato preso a modello della conoscenza generata nella prima era industriale, c’è adesso il rischio che una versione estremizzata dello Scrum comporti dei modelli mentali che -a mio parere- distorcono il senso di questa era, ovvero: l’era nel neo-umanesimo, degli ibridi, della socialità.

Lo capisco, è una critica dura fatta ad un approccio progettuale estremamente redditizio ed efficace. Il mio mestiere prevede però che io tenti di vedere anche due passi avanti e -sinceramente- in questa politica del recruting ingegnere centrico, ci vedo l’inizio della fine della superiorità statunitense nell’industria del software.

…ovviamente, sempre che Italia, Svezia, Spagna, Francia, India, Giappone, Cina e le altre mille società ricche di tradizione e cultura, sappiano cogliere l’occasione, senza soffrire delle crisi di inferiorità nei confronti dei giganti californiani. Anzi, magari mixando le diverse culture ed andando ad aprire delle sedi accanto alle Oracle di questa terra.

.
Il sistema Torinese per l’innovazione
Riparto adesso dalla socialità -vera e principale connotazione di quest’era di Internet- per evidenziare quello che -da un paio di anni- succede a Torino.

Dal mio personale punto di vista, la Città di Torino e le sue Istituzioni, stanno reagendo con vigore al lassismo generale diffuso in Italia. Politecnico, Regione, enti “esterni” come il Top-ix, insieme a numerosi altri attori fanno spesso e volentieri SISTEMA, dando a potenziali startupeers un supporto notevole su molti ambiti:

- supporto culturale innanzi tutto (con i tantissimi eventi centrati sull’innovazione)
- infrastrutturale (una buona idea può ricevere banda e server gratis per 18 mesi)
- ambientale, ovvero legato al coaching e l’incubazione di aziende

Al Politecnico di Torino, dal 2000 ad oggi, sono partite 93 imprese. 40 di queste sono ancora dentro l’incubatore. 6 hanno chiuso. Le altre vivono indipendenti sul mercato!
Tutto questo è -senza nulla togliere ad altre città che si danno da fare- grandioso. Un risultato che si va da incastonare poi in un territorio dove ci sono manifestazioni come Torino Scienza, dove quest’anno si celebra Torino come Capitale Mondiale del Design, dove è in calendario la Conferenza Mondiale di Architettura, dove ci sono eventi come il Virtuality/View8 e lo Share Festival. Non è poco.

.
..
E qui concludo, svelando però anche da dove è partita la storia che vi ho raccontato oggi. Qualche mese fa ho cominciato a scrivermi delle email con Paolo Marenco. Paolo è direttore di Aizoon (sponsor dell’evento che vi ho raccontato), ma è soprattutto l’ideatore de “La Storia nel Futuro” e del social netword “Silicon Valley Study Tour“. Le sue esperienze come manager di centri di eccellenza nell’innovazione, ne fanno un alfiere assoluto del networking e la sua appartenenza allo SVIEC ne amplifica il network sin oltre oceano, esattamente laddove germogliano molte delle storie di successo dell’ICT mondiale. E’ stato Paolo a segnalarmi l’evento Torinese (lui che è di Genova) ed è a lui cha va il mio ringraziamento per essere stato partecipe di qualcosa di così interessante. Incontrare persone come Paolo o come Vittorio (il VP Oracle al centro di questo post) rende possibile rimettere in movimento le idee: reintegra con il presente.

Grazie dunque ragazzi.
Vittorio, ti ringrazio ancora per lo speech appassionante e intelligente, e spero che leggendo questo post, troverai anche il tempo di commentarlo brevemente.

Tags: Agile, Aizoon, California, Marenco, Scrum, Silicon Valley STudy Tour, SVIEC, Torino, Turin, Vittorio Viarengo