37signals basandosi sui principi descritti in Getting Real ha realizzato 5 applicazioni web (Basecamp, Campfire, Backpack, Writeboard, Ta-da List) che hanno riscosso un grande successo tra gli utenti (privati e aziende), attualmente oltre un milione. Va inoltre ricordato che 37signals con David Heinemeier Hansson ha dato vita al framework di sviluppo Ruby on Rails.

Il libro è disponibile in 3 formati:

1. Getting Real in pdf 19$
2. Getting Real in copia cartacea 25$
   
3. Getting Real online Gratis

I sedici capitoli del libro propongono idee interessanti per tutto il processo di progettazione-sviluppo-rilascio di un progetto, in particolare nel settore web restando tuttavia ad un livello piuttosto alto in modo da poter applicare i principi espressi anche il altri settori senza grossi problemi.

E così che si parte dall’idea (alla base di tutto chiaramente) focalizzando le proprie energie per definire il core dell’applicazione ignorando nelle prime fasi i dettagli ed evitando di fasciarsi la testa pensando ad un futuro che non potrebbe mai arrivare con problemi di scalabilità e gestione dei costi. Restare semplici per poter cambiare con maggiore facilità.

Per restare semplici al grido di less is more è importante capire quali feature sviluppare e come gestire le possibili richieste valutando i costi nascosti che esse comporterebbero. Dopotutto quello che si vuole è realizzare qualcosa che si possa gestire, gli sforzi sono concentrati verso la creazione di un progetto sano. Piuttosto è meglio cercare di scoprire cosa gli utenti non vogliano vedere nell’applicazione.

Si passa quindi ai primi passi dell’applicazione vera e propria, è importante avere qualcosa di funzionante in breve tempo. Partendo dal brainstorming, passando per delle simulazioni (prototipizzazione) in html per poi passare finalmente alla scrittura del codice vero e proprio. Per restare semplici è importante prendere alcune decisioni direttamente senza lasciarle agli utenti, alcune preferenze non sono di vitale importanza ecco quindi che basterà prendere una decisione una volta per tutte piuttosto che aver a che fare con la gestione di esse. Fondamentale è la fase di test durante la quale è bene dare l’applicazione in pasto agli utenti con delle sessioni di utilizzo reale, lo sviluppatore userebbe degli schemi ben precisi di utilizzo e questo non è ciò che avviene con un nuovo utente.

La parte centrale del libro si occupa della messa in pratica del progetto dall’organizzazione del lavoro e alla scelta dello staff necessario per la crescita del progetto. Utili consigli vengono trasmessi per cercare di ottenere il massimo dalla proprie capacità. Si passa quindi al design dell’applicazione in termini di interfaccia come punto fondamentale da definire prima di scrivere codice, vedere realmente come il progetto si presenterà agli utenti permette di capire molte cose e correggerne altre. Si chiude la parte tecnica con un capitolo dedicato interamente al codice: mantenerlo semplice per gestirlo meglio e poter cambiare più rapidamente, aprire le porte agli altri con rss e api, usare tool e linguaggi che piacciano agli sviluppatori. A happy programmer is a productive programmer. 

Si chiude quindi con quella che è la fase meno tecnica e più commerciale/promozionale parlando di preview e facilità di registrazione/cancellazione, passando al lancio vero e proprio dopo aver generato il giusto hype e cavalcando l’onda del buzz grazie al quale capire la direzione presa dal progetto in termini di immagine. Passato il lancio non è tutto finito, si continua a lavorare per migliorare il prodotto dando le giuste priorità ai problemi comparsi man mano che gli utenti utilizzano il servizio. Essere pronti al cambiamento è fondamentale.

Il mio consiglio? Leggetelo, leggetelo, leggetelo. Tutto, questo fine settimana. Non ci vorrà molto e di sicuro alla fine avrete una carica in più, se anche una sola delle idee lette vi farà dire “interessante!” non sarà stato tempo sprecato. Poi tornate su questo post e parliamone assieme!

Per chi avesse problemi con l’inglese c’è la traduzione in italiano (ma non avendola letta non posso garantire che tutto renda come in lingua originale).

Utente generico: questo è l’errore più grosso e dannoso in cui si può incappare quando si generano le user story. Considerare un utente troppo generico porta inevitabilmente a due problemi che rallentano il rilascio del sotware. Primo: le necessità dell’utente sono talmente tante che ci si perderebbe ipotizzando tutte le features realizzabili. Secondo: non si potrebbe raggiungere il livello di dettaglio sperato per l’implementazione. Quando si realizza una user story è bene avere in mente uno specifico utente. Quest’utente ha solo un limitato numero di requisiti e può rispondere in modo dettagliato a delle domande.

Utenti poco conosciuti / scenario non familiare: il design del software dà i risultati migliori quando si progetta software per sè stessi. Le user story sono facili da ottenere e molto accurate. Una buona fetta di software ben progettati è realizzata da chi lo fa per i propri bisogni. Quando invece ci si trova a creare software per user story che non si conoscono e per scenari/domini non conosciuti le cose si complicano. Intervistare gli utenti è il primo passo per raccogliere informazioni, sicuramente qualcosa verrà dimenticato e solo i primi test con il prototipo dell’applicazione potranno segnalare questi problemi. Due suggerimenti: il primo è quello di impersonare l’utente seguendo l’intero processo in prima persona, il secondo è quello di dividere gli utenti in modo da individuare quelli che analizzeranno le prime versioni del software (alpha e beta). I feedback ricevuti in questa fase daranno informazioni più importanti di quelle raccolte dalle interviste.

Feature specifiche o non-user feature: quando si lavora a feature che gli utenti non vedono il concetto di user story viene un po’ meno, si pensi per esempio ad architettura, amministrazione etc…basta ricordare due cose per rendere le user story più concrete. In primo luogo gli amministratori di sistema e gli sviluppatori sono anch’essi degli utenti. Secondo: realizzare ciò “che sta sotto”, parlando di infrastruttura, più tardi possibile in modo da rispondere prontamente agli utenti e risparmiando tempo prezioso nel caso in cui ci si accorgesse che l’infrastruttura pensata non corrisponde alle reali esigenze.

Storie testuali: è molto facile dilungarsi in diagrammi e descrizioni che alla fine sono difficili da leggere e per l’utente anche difficili da comprendere. La miglior soluzione è quella di realizzare immagini e storyboard al posto del testo. Una storyboard è una specie di flow chart in cui l’utente vede le componenti in gioco, schermate del sistema che userà e link che rappresentano le transizioni tra una schermate ed un’altra. In questo modo si può evitare di dover scrivere la maggior parte del testo e dei commenti posticipando il tutto ad un secondo momento.

Consiglio la lettura di Do’s and Don’ts for User Stories, Use Cases, Scenarios.