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

• 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…

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

YouRank, tecnicamente parlando, è un motore di ricerca distribuito che non si basa solamente sugli aspetti strutturali del web (link, tags, microformats, ecc…), ma anche e sopratutto sull’attvità dell’utente. Se sto cercando un termine, i motori di ricerca attuali mi porteranno su pagine che contengono (sintatticamente) quel termine, magari è quello che stavo effettivamente cercando, magari no e allora proseguirò nella ricerca sfruttando i link della pagina in cui mi trovo. Attraverso l’uso del link sto implicitamente dicendo che quel link è semanticamente collegato alla ricerca che stavo facendo e di questo YouRank ne tiene conto.

Non ho mai creduto nelle soluzioni dove la semantica (il significato delle cose) viene dedotta da un sistema artificiale, la mia opinione è che i computer esistono per semplificarci la vita e per sostituirci in tutti quei compiti in cui noi non eccelliamo, non il contrario :-). L’originalità di YouRank sta nel cercare di capire cosa è veramente importante deducendolo dal comportamento dell’utente: all’utente gli aspetti semantici (questo link è importante, questo no), e a YouRank gli automatismi collegati (mi ricorderò del fatto che per te questo link è importante)

La sfida tecnologica è stata quella (e lo è tuttora) di realizzare un prodotto sotto molti aspetti innovativo in un ambiente di sviluppo (mozilla/xul/xpcom) non particolarmente “friendly”. L’estensione è composta da alcuni oggetti xpcom realizzati in c++ (compreso lo storage sqlite opportunamente modificato/ottimizzato) mentre tutto il resto è in javascript

L’ambiente non lo considero amichevole perchè:

• Non esiste nessuna libreria di unit testing: esistono molte librerie di unit testing in javascript, ma nessuna che sia stata pensata per essere utilizzata in un contesto diverso da quello di una pagina web, io avevo bisogno di qualcosa che potesse essere eseguito da linea di comando e che desse un feedback interpretabile in maniera automatica. La soluzione è stata quella di realizzare una libreria di unit testing ad hoc
• Non esiste un sistema di build: certo, esiste l’ambiente di build di mozilla/firefox, ma provate ad automatizzarlo in modo che funzioni su tutte le piattaforme che supportiamo (win, linux, mac), in modo che non ci vogliano giorni per ricostruirlo e in modo che una build da ambiente pulito non ci metta delle ore. Alla fine ho scelto ant e make come tools e una serie di file di build non propriamente semplici ma che rispettano tutti i requisiti di cui sopra
• Non esiste nessun ambiente di sviluppo: komodo forse è la cosa che si avvicina di più, ma niente di paragonabile alla “developer experience” che puoi avere con eclipse per lo sviluppo di un’applicazione java. Nota: io sono un utente vim e non mi stanno molto simpatici gli IDE (sopratutto quelli che pretendono di essere più furbi di me), quindi per me non è stato un grande problema, ma trovare un ambiente di sviluppo condiviso è stato (lo è tuttora) un problema
• Mi ero dimenticato dell’incubo della portabilità del codice senza avere una virtual machine :-)

Attualmente il ciclo di sviluppo è settimanale, lo sviluppo di una release inizia il giovedì mattina e termina il mercoledì sera, parallelamente giovedì mattina inizia la fase di test esplorativo della nuova release che viene condotto internamente e che dura due giorni, il rilascio al pubblico avviene di lunedì. Questo lunedì verrà rilasciato il prossimo update che introdurrà la compatibilità con Firefox 3

Nei prossimi giorni mi occuperò di scrivere alcuni post tecnici sul blog di YouRank, quindi se siete interessati all’idea, installatelo, provatelo, ditemi cosa ne pensate e tenete d’occhio il blog :-)

Anyway, volevo segnalarvi, come splendido esempio di Agilità, l’intervento di DHH alla Startup School Conference che si è tenuta ieri alla Stanford University

In una conferenza dove il focus è stato: come fare a ricevere finanziamenti multimilionari per le proprie startup, come fare per essere comprati per cifre multimilionarie, come fare per cambiare il mondo, è arrivato lui e ha detto una cosa del tipo: “Ehi ragazzi, perchè non provate a fare un’applicazione realmente utile per il business di qualcuno e farvi pagare per il suo utilizzo? Non servono milioni di utenti, con qualche migiaio di utenti potete iniziare a guadagnare cifre a 6 zeri, un milione di dollari vi sembra poco? Non servono molti soldi per partire, anzi è meglio se ne avete pochi e se avete poco tempo, poche risorse = necessità di focalizzarsi sugli aspetti realmente importanti”

Guarda caso è la stessa conclusione alla quale sono arrivato leggendo Founders at Work, decine di fondatori di startup intervistati in maniera indipendente da uno stesso giornalista, alla domanda “Qual’è stato l’ingrediente fondamentale del vostro successo”, fondamentalmente tutti rispondono “La mancanza di risorse iniziali ci ha dato la possibilità di concentrarci sulle cose realmente importanti”, abbastanza convincente come prova empirica…

Quando i 37signals, di cui DHH fa parte, hanno pubblicato il loro libro l’ho comprato, l’ho letto, e ho provato una sensazione di freschezza, di semplicità e di chiarezza, la stessa sensazione che ho provato quando ho studiato RoR, la stessa sensazione che ho provato quando ho ascoltato l’intervento di cui sopra, ve lo consiglio veramente :-)