Vorrei costruire una casa fatta esattamente in questo modo. Quanto ci metti a costruirmela? Quanto mi costerebbe?

Il costruttore stoicamente risponde

Tre mesi e 100.000 euro

L’uomo, guarda il costruttore con uno sguardo diretto… semplice… come se stesse parlando delle condizioni metereologiche

Ti do una settimana e 5.000 euro

Il costruttore rimane sbigottito… non sa se lo stanno prendendo per il culo o se fanno sul serio: se lo stanno prendendo per il culo è il momento d’incazzarsi, se fanno sul serio è il momento di mettersi a piangere; decide in buona fede di cercare di capire meglio

Scusami, ammesso e non concesso che umanamente sia possibile farlo in una settimana, significherebbe utilizzare molte più risorse di quelle spese per farcela in tre mesi… quindi al limite ti costerà di più di 100.000 euro, perchè dovrebbero bastarne 5.000???

L’uomo, sempre con la stessa faccia risponde

Accidenti, ma quanto vorresti guadagnare in una settimana?!?!?!

… Ve lo dico io, non c’è dubbio, ci stanno prendendo per il culo

A questo proposito faccio un appello a chiunque può essere interessato, secondo me c’è (e crescerà sempre di più) un oceano blu, ovvero un mercato di opportunità non ancora esplorato, che è quello del “Procuratore per sviluppatori”

Il procuratore dovrebbe trovare il cliente (anche se non è necessario, potrebbe trovarlo direttamente lo sviluppatore) e trattare gli aspetti economici e burocratici del progetto per conto dello sviluppatore, in cambio il procuratore si becca il 20% del fatturato, gli aspetti tecnici vengono gestiti direttamente dallo sviluppatore, esattamente come succede per i calciatori/sportivi (anche se ammetto di non saperne molto ;-P)

Ci sono molti dettagli che devono essere definiti, ma potrebbe funzionare, da gennaio/febbraio sto lavorando in questo modo e sono abbastanza soddisfatto, se qualcuno è interessato, mi contatti direttamente :-)

Il desiderio di controllo nasce dalla paura di non averlo

Da cui una metrica molto semplice da misurare per colui che si definisce professionista

Tutte le volte che un cliente ti chiede a che punto sei in merito ad un lavoro che stai facendo per lui, hai perso 10 punti. Se non rispondi in tempo reale, hai perso 1000 punti

Inutile dire che perdere punti è molto più semplice che guadagnarli… Quello che penso è che il “command & control” non lo voglia spontaneamente nessuno, neanche il cliente, ci si arriva quando costretti, sopratutto per la mentalità italiana dove il 90% della popolazione vorrebbe fare “l’intermediario” nullafacente

Analizziamo il processo mentale del cliente

• Gli ho chiesto di fare questa “piccola” cosa due giorni fa e non ho più saputo niente, cosa starà facendo? Starà lavorando? E’ una cosa importante, deve essere pronta per questa sera… Forse è meglio lasciarlo lavorare, fra poco si farà sentire…
• Sono le 16:00 e non si è ancora sentito nessuno… eh no, adesso basta, gli faccio il culo, non è possibile, aveva detto che avrebbe consegnato prima di sera e sono due giorni che non si fa sentire, gli mando una e-mail
• Non risponde neanche alle e-mail!!! Lo sapevo, non ha fatto niente!!! Per questa sera non sarà pronto niente e sarò nella merda!!! La prossima volta non ci casco più!!!

Ora, poco importa se il nostro “professionista” era in meditazione per riuscire a finire in tempo, poco importa se effettivamente la consegna è avvenuta in tempo, l’ansia e il dubbio sono comunque entrati nella mente del cliente che vorrà avere sempre più “controllo”, anche se la sua forma di “controllo” sarà letale per il progetto :-)

Ogni volta che un vostro cliente vi chiede informazioni su qualcosa, lo fa perchè si sente obbligato a farlo, se potesse eviterebbe, confrontatevi immediatamente con lui per capire come fornigli in anticipo le risposte ai suoi dubbi, siate veri professionisti, non ve ne pentirete

L’atmosfera e il clima sono stati perfetti per un barcamp: bel posto (tra l’altro ero in poltrona in prima fila, l’unica cosa difficile è stata mantenere la lucidità dopo pranzo), bella gente, Luca è stato un ottimo padrone di casa e sopratutto le competenze dei presenti erano molto eterogenee (programmatori, designer e product manager/owner)

Personalmente mi sono giocato la presentazione sui kata della programmazione

La stessa che ho portato al javaday

Se siete interessati al tema vi consiglio di iscrivervi alla ml del milano-xpug e/o a quella del milano-codingdojo, stiamo organizzando alcune attività anche non strettamente legate all’area di Milano :-)

P.S. Alla fine del talk dico di aver seguito la scuola di Martin Fowler del Clean Code, imperdonabile errore, ovviamente stavo parlando di Robert C. Martin :-)

Maggior conoscenza acquisiamo sui nostri utenti, maggiori saranno le probabilità che la prossima funzionalità pensata/implementata sarà apprezzata (aumentando il valore dell’applicazione). Minore sarà il tempo/costo d’implementazione di una nuova funzionalità, maggiori saranno le funzionalità che potremmo utilizzare per acquisire conoscenza sui nostri utenti

Cosa possiamo fare per minimizzare i tempi/costi d’implementazione? Chiaramente possiamo intervenire da un punto di vista tecnico migliorando la nostra capacità di produrre software, mantenendo sempre pulita la nostra base di codice, migliorando costantemente gli aspetti di project automation e di autonomation, ecc… insomma avete capito

L’altra cosa che possiamo fare è splittare in maniera creativa ed aggressiva le user story esistenti del prodotto. Prima possiamo iniziare a selezionere un minimo set di user story in grado di dare dignità di prodotto al nostro progetto, poi possiamo iniziare a considerarle singolarmente e a capire cosa possiamo togliere da ogni user story conservando la possibilità di poter utilizzare il risultato come MVP

Un esempio? Avevo 10 giorni (nessuna domanda please sul perchè di questo numero magico…) di tempo per realizzare un’applicativo piuttosto complesso, ovviamente c’era di mezzo uno storage, ovviamente il cliente aveva richiesto un’interfaccia di amministrazione/gestione di questo storage e ovviamente non aveva tralasciato nessun “goodies”: utenti, gruppi, ruoli, permessi, editing, viste configurabili sui dati, ecc… praticamente mi sarebbero serviti molti più giorni di quelli a disposizione solo per questa parte accessoria del sistema. Volevo iniziare dal vero prodotto, ma volevo anche che il cliente lo potesse utilizzare da subito, così ho installato phpMyAdmin e ho fatto vedere al cliente come utilizzarlo: ho creato utenti, viste, maschere, ecc… alla fine il cliente mi ha detto che è esattamente quello che voleva :-D Ok, sono stato fortunato, ma è stata una vera epifania

Un’altro esempio un po’ più creativo? Kent Beck qualche hanno fa ha tenuto un workshop sullo split delle user story usando un esempio alquanto “ardito”: il gioco del tetris… qual’è secondo voi la prima user story per Beck? Una colonna, un quadratino 1×1 che scende a velocià costante, quando un quadratino tocca il fondo parte un altro quadratino, il nuovo fondo è il quadratino precedente, quando il fondo arriva in cima alla colonna “game over” :-D

Ancora una volta una conferma del fatto che il business (il problem team come lo chiama Ries) e la tecnologia (solution team) non si possono/devono ignorare a vicenda

• Pianificazione: identificare le User Story tenendole ad una granularità/indipendenza sufficiente da poter realizzare prima quelle con il più alto valore di business. Inutile dire che la valutazione del valore di business di ogni singola user story è fondamentale
• Esecuzione: migliorare costantemente la velocità di realizzazione delle suddette User Story

L’obiettivo supremo è sempre quello di massimizzare la quantità di valore consegnato nell’unità di tempo e in subordine la capacità di produrne in futuro, il resto sono chiacchere

E’ un concetto estremamente semplice, ma estremamente efficace se dovete introdurre a qualcuno le pratiche proprie delle metodologie Agili. Detto questo però se avete poco tempo a disposizione per catturare l’attenzione di qualcuno, se dovete fare un elevator pitch, vi serve qualcosa di molto immediato, vi servono delle metafore

Negli ultimi due anni ne ho raffinata una per spiegare come funziona la pianificazione e visto che è risultata essere particolarmente efficace la condivido con tutti, la scrivo come la racconto di solito

Supponiamo che dall’altro lato di quella porta (nda. di solito c’è una porta nelle vicinanze :-)) ci sia un team di programmatori che deve iniziare un progetto per il quale sono necessarie determinate conoscenze, queste conoscenze possono essere acquisite attraverso lo studio di alcuni libri, il vostro compito è quello di fornirglieli

Il materiale che vi viene dato consiste in 15m^3 di libri e di uno scatolone di 10m^3, se vi state chiedendo “esiste una metodologia in grado di far entrare 15m^3 di libri in uno scatolone di 10m^3?” la risposta è no! Anche le metodologie Agili non fanno eccezione :-)

Quindi cosa facciamo? Se seguissimo alla lettera i vincoli che ci sono stati dati e se non fossimo abbastanza svegli da misurare i volumi che abbiamo a disposizione, probabilmente spenderemo la maggior parte del nostro tempo a tentare di organizzare i libri per riuscire a farceli stare tutti nello scatolone. Una volta arrivati in prossimità della scadenza ficcheremo il maggior numero possibile di libri all’interno dello scatolone per poi spingerlo finalmente al di là della porta dove ci sono i programmatori che lo aspettano

Evidentemente non è una strategia molto furba… come possiamo migliorarla? Ci chiediamo: “qual’è il reale obiettivo di questo lavoro?” Massimizzare al quantità di conoscenza da passare al team di programmatori che sta al di là della porta, “la quantità di conoscenza erogata è indipendente dal libro?” Ovviamente no, quindi una cosa che possiamo fare è scegliere i 10m^3 di libri in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che la scelta delle user story da implementare è il primo passo verso la massimizzazione del flusso di valore)

Bene, possiamo migliorare? Ci chiediamo “ogni capitolo all’interno di un libro eroga la stessa quantità di conoscenza?” Nella maggior parte dei casi no, sicuramente non erogano conoscenza le copertine cartonate, le prefazioni, i ringraziamenti, ecc… Quindi possiamo procedere con un approcio creativo e stracciare ogni libro tenendo solo i capitoli migliori e quindi scegliere i 10m^3 di materiale in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che splittando le user story possiamo prendere la maggior parte del valore minimizzando il costo)

Ottimo! Possiamo ancora migliorare? Ci chiediamo “chi è che decide la quantità di conoscenza erogata da un testo?” Fino a questo momento siamo stati noi ma effettivamente è un assunto grave, cosa succederebbe se avessimo torto? La nostra strategia sarebbe ancora valida, ma le nostre misurazioni sarebbero pura speculazione, non possiamo essere sicuri di aver realmente erogato la maggior quantità di conoscenza possibile. “chi potrebbe valutare con maggiore accuratezza?” Sicuramente il team di programmatori che sta dietro alla porta

Quindi possiamo essere ancora più creativi e possiamo chiedere di barattare lo scatolone da 10m^3 con 10 scatoloni da 1m^3, nel primo scatolone ci mettiamo quello che noi riteniamo essere il miglior metro cubo di materiale possibile e lo spingiamo fuori dalla porta chiedendo ai programmatori di chiamarci una volta letto tutto. Quando i programmatori ci chiameranno chiederemo il loro feedback sul materiale, sulla base di queste informazioni sceglieremo cosa mettere nel prossimo scatolone. In questo modo non solo avremo una corretta valutazione del valore consegnato, ma abbiamo anche la possibilità di adattarci al contesto del progetto (nda. in questo caso stiamo dicendo che le funzionalità individuate all’inizio del progetto e la stima di valore che ne viene fatta è nella maggior parte dei casi errata e che quindi serve un reale strumento di feedback)

Secondo me funziona bene perchè

• All’inizio non ti aspetti di poter migliorare molto, quando capisci che puoi farlo è una bella sensazione :-)
• I 15m^3 in 10m^3 danno quella sensazione di claustrofobia che tutti hanno provato nei progetti “fixed *” (leggi: dove tutto è prefissato)
• Si capisce chiaramente che il modo per migliorare dipende poco dalla capacità di fare stime “corrette” quando dall’organizzazione del flusso di lavoro e di feedback

Cosa ne pensate? Possiamo ancora migliorare? :-)

• The customer is the most important thing in your business
• The best business plan is to sell people the things they want
• Your business is successfull if your earnings are higher than your spendings

Troppo spesso le startup vengono fondate su una vision di progetto che esiste solo nelle menti degli stessi fondatori, Eric Ries dice sempre nelle sue presentazioni “vision not delusion”, che potrebbe anche essere “vision not illusion”. Il compito principale di una startup è quello di validare/raffinare nel più breve tempo possibile la propria vision di progetto confrontandosi con l’unica fonte di verità: gli utenti

VC: “Interessante la vostra idea, potete mostrarci il vostro business plan?”
Startup: “Inizialmente avevamo questo set di funzionalità, poi abbiamo eliminato queste funzionalità ed abbiamo aggiunto queste altre e siamo passati da X utenti a 3X utenti, a partire da questa informazione abbiamo modificato il nostro posizionamento nel mercato, abbiamo validato queste informazioni passando da 3X utenti a 10X utenti aggiungendo queste altre funzionalità in accordo con quanto avevamo scoperto. Ora ci aspettiamo di raggiungere i 100X utenti, quindi una revenue di Y, togliendo queste funzionalità e aggiungedo queste altre nei prossimi 2 mesi”

Questo è un business plan nel quale metterei dei soldi…

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. [...] Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. [...] Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Estratto da l’ultimo articolo di Tom DeMarco. Consideriamo anche che DeMarco non è proprio uno di quei “giovani rivoluzionari delle metodologie Agili che non hanno ancora capito niente e che vogliono reinventare la ruota”, è uno dei padri fondatori che si è sparato un po’ tutte le ere geologiche dell’informatica. Il problema è che di solito passa qualche lustro prima che il pensiero degli illuminati diventi di comune dominio… speriamo di esserci quando avverrà :-)

Il succo del discorso è che fare scelte è molto impegnativo, la situazione peggiora se:

• gli obiettivi non sono chiari
• non è chiaro come una scelta potrebbe influenzare il raggiungimento dell’obiettivo
• le scelte sono molte

Provate a pensare al nostro lavoro, o in generale al lavoro creativo dove le possibili scelte sono infinite, dove l’obiettivo è soddisfare un’utente che nella maggior parte dei casi non conosciamo, ecc… capite che non siamo messi molto bene :-)

La tecnica del pomodoro per lo meno ti consente di separare i momenti in cui devi effettuare una scelta (cosa fare e quando farla) e i momenti in cui devi eseguire. La possibilità offerta è quella di eliminare lo stress continuo della scelta, ovvero di eliminare quella vocina che continuamente si chiede “sto facendo la cosa giusta? Potrei fare anche quall’altra cosa! Ah e poi devo fare anche quell’altra! Non sarebbe meglio se quell’altra cosa la facessi subito? Caxxo quante cose ho da fare! Riuscirò a farle tutte in tempo? Ecc…”, ovvero un context switch mentale continuo, uno stress altissimo che non porta sicuramente a nessun risultato

Nei 25 minuti del pomodoro non sei autorizzato a pensare ad altro oltre a quello che stai facendo, quando hai finito hai la possibilità di utilizzare il risultato del tuo lavoro per poter operare delle scelte informate, limitando le speculazioni mentali e diminuendo notevolmente l’ansia

Sostanzialmente è quello che fanno le metodologie iterative ed incrementali a livello di progetto, la tecnica del pomodoro ti consente di applicare lo stesso principio e di ottenere gli stessi vantaggi ad una granularità più fine e direi più umana

I talk m’interessano relativamente, è raro assistere ad un talk che parla di un’argomento di mio interesse all’interno del quale si dicano cose che non ho già letto e/o sentito, chiaramente questo non dipende dalla preparazione dell’oratore ma dal fatto che non può dar per scontato che tutti i presenti conoscano già determinati argomenti. Alcuni tipi di talk però fanno eccezione, per esempio gli experience report mi piacciono molto

Giovedì 07/05/2009, la giornata inizia subito bene, parto con il treno delle 6:30 da Milano con l’iphone pieno di conferenze (quale cosa migliore di andare ad una conferenza guardandosi altre conferenze), direzione: Firenze, scopo: partecipare a bettersoftware. Arrivati a Firenze sto per scendere dal treno e becco Simone Genini, grazie al suo aiuto riesco a raggiungere appena in tempo l’albergo della conferenza (io ho una capacità di perdermi incredibile, talmente incredibile che neanche iphone + google maps mi salvano)

Primo talk (mannaggia a chi ha deciso di far iniziare la conferenza così presto) è stato quello di Antonio Cangiano sul mondo delle startup, lui stesso ne sta facendo partire una e ha condiviso con la platea i suoi pensieri. Sabato (durante pycon3) ho avuto modo di parlare con Antonio, è una persona molto simpatica e socievole, mi ha spiegato le idee che stanno alla base di thinkcode (la sua startup) e devo dire che sarò sicuramente uno dei loro primi clienti (se siete appassionati di programmazione vi consiglio di iscrivervi alla loro ml, se non siete appassionati di programmazione avete sbagliato blog :-))

La giornata è proseguita con i talk di Matteo Vaccari, Francesco Cirillo e Simone Casciaroli (Simone perchè non hai un blog?), tre experience report degni di nota.

Scena madre della giornata: Francesco Cirillo sale sul palco e attacca con la campagna anti-if, dice che ha delle magliette da regalare, ma le regalerà solo a chi dirà qualcosa in grado di colpirlo, al che Jacopo Romei che era seduto di fianco a me si alza e urla “Sei Bellissimoooo!!!”, scoppiano tutti a ridere e lui si becca la maglietta, grande Jacopo, uno ottimo esempio di pensiero creativo :-)

Starting now, I’m reorienting my business to focus on people who want to be great. I hope there’s enough of you still out there. Agile continues to be the best way I know to get to greatness, so that’s what I’m using, but I’m no longer interested in helping people find the lowest-impact way to slap an Agile sticker on their door.

I want to work with people who want to be great. People who aren’t satisfied just fitting in. People who are willing to take risks, rock the boat, and change their environment to maximize their productivity, throughput, and value. If that’s you–particularly if you’re in a product-focused, entrepreneurial environment–I want to hear from you. We can do great things together.

Esattamente quello che ho iniziato a fare da un po’ di tempo a questa parte, ovviamente per ragioni diverse da quelle di Shore :-) e purtroppo il mercato italiano non è così vasto e vario, quindi stanco di sentirmi dire cose come “bello, ma da noi non può funzionare”, “si, ma noi siamo diversi”, ecc… ho deciso d’intraprendere la strada delle startup, ovvero aziende orientate al prodotto, ambienti dove la politica e la burocrazia non contano, ambienti dove solo i fatti contano :-)

Certo che se tutto quello che ho sempre predicato fosse fuffa, fra un po’ mi troverete a pelare le patate nei sottomarini cinesi… stay tuned