Getting Real Italiano

• capitolo 1 Introduzione
• capitolo 2 La linea di partenza
• capitolo 3 Meno massa
• capitolo 4 Priorità
• capitolo 5 Scelta delle Funzionalità
• capitolo 6 Processo
• chapter 7 L’Organizzazione
• chapter 8 Staffing
• chapter 9 L’importanza della progettazione
• capitolo 10 Codice
• chapter 11 Parole
• chapter 12 Pricing and Signup
• chapter 13 Promotion
• capitolo 14 Assistenza
• capitolo 15 Post-Lancio
• capitolo 16 Conclusioni

---

Introduzione capitolo 1

Cosa significa Getting Real?

Vuoi costruire un’applicazione web di successo? Allora è tempo di “Getting Real”. Getting Real è il modo più semplice, veloce e migliore per sviluppare software.

• Getting Real significa evitare tutto ciò che viene utilizzato per rappresentare la realtà (diagrammi, grafici, box, frecce, schemi, wireframe, etc.) costruendola veramente fin da subito.
• Getting Real è sinonimo di meno. Meno materiale, meno software, meno funzionalità, meno lavoro su carta, meno di tutto ciò che non è essenziale (e ricorda che la
  maggior parte di quello che pensi sia essenziale, in realtà, non lo è).
• Getting Real significa rimanere piccoli ed essere agili.
• Getting Real vuol dire iniziare lo sviluppo dall’interfaccia, la parte rivolta agli utenti. Significa cominciare da subito a far testare il sistema al cliente e continuare lo sviluppo basandosi sui feedback che esso ci fornisce. Questo consente di creare un’interfaccia corretta evitando di realizzare un software erroneo.
• Getting Real significa procedere per iterazioni e tenere bassi i costi dei cambiamenti. Getting real vuol dire lanciare l’applicazione, aggiustarla ed ottimizzarla costantemente; questo approccio è perfetto per il software sviluppato per il web.
• Getting Real significa creare esattamente ciò di cui i tuoi clienti hanno bisogno, eliminando tutto ciò che non è strettamente necessario.

I benefici di Getting Real

Con Getting Real si ottengono risultati migliori perché ti obbliga a rapportarti ai problemi piuttosto che alle tue congetture su di essi. Ti insegna ad affrontare la realtà.

Getting Real ti fa mettere da parte le specifiche funzionali ed altre documentazioni transitorie in favore della realizzazione dell’interfaccia. Una specifica funzionale è un’imitazione della realtà, un’illusione, mentre una vera pagina web è realtà. Infatti tale pagina sarà proprio quella vista ed usata dai tuoi clienti. Questo è quello che conta. Getting Real ti fa arrivare al cuore del progetto più velocemente. Questo significa che per sviluppare il software stai prendendo decisioni basate sulla realtà piuttosto che su nozioni astratte.

In conclusione, Getting Real è un approccio specifico allo sviluppo di software per il web. La vecchia scuola, che consisteva nel consegnare il software confezionato e aspettare uno o due anni per distribuire un aggiornamento, sta scomparendo. A differenza del software installato, le applicazioni web possono evolvere ogni giorno. Getting Real, con i suoi utili e preziosi consigli, consente di aumentare questo vantaggio.

Basta con i divoratori di risorse

La vecchia scuola: un modo di operare infinito e farraginoso che serve per pararsi il culo. Il risultato è: un software mediocre e da dimenticare che divora sempre più risorse.

Getting Real si libera di…

• Timeline che occupano mesi o anche anni
• Irrealizzabili specifiche funzionali
• Dibattiti sulla scalabilità
• Interminabili incontri con lo staff
• Il bisogno di assumere dozzine di impiegati
• Numeri di versioni senza senso
• Roadmap che predicono il futuro perfettamente
• Una lista di preferenze senza fine
• Supporto clienti gestito esternamente
• Test irreali
• Inutili lavori su carta
• Un approccio top-down

Non hai bisogno di una quantità esagerata di soldi, di un enorme team o di un ciclo di sviluppo lungo per produrre ottimo software. Questi sono gli ingredienti per realizzare applicazioni lente, confuse e statiche. Getting Real adotta l’approccio opposto.

In questo libro ti mostreremo…

• L’importanza di avere una filosofia
• Perché rimanere piccoli è una bella cosa
• Come costruire meno
• Come passare velocemente da un’idea alla realtà
• Come addestrare il tuo team
• Perché dovresti disegnare dall’interno all’esterno
• Perché scrivere è così decisivo
• Perché dovresti sottostimare i tuoi avversari
• Come promuovere la tua applicazione e diffonderla
• I segreti per un supporto clienti di successo
• I trucchi per mantenere il successo dopo il debutto
• ...e molto altro

L’attenzione è rivolta alle idee di alto livello. Non ti stancheremo con trucchi di codice o di css. Ci concentreremo sulle idee e sulle filosofie principali che guidano l’approccio Getting Real.

E’ per te questo libro?

Sei un imprenditore, un grafico, un programmatore o un esperto di marketing che lavora su una grande idea.

Ti rendi conto che le vecchie regole non sono più valide. Ogni anno distribuisci il tuo software su CD-ROM? Versione 2002. Usi ancora i numeri di versione? Getta tutto fuori dalla finestra. Hai bisogno di creare, lanciare ed aggiustare successivamente l’applicazione. Così sarà sempre aggiornata e potrai ripetere questo ciclo più e più volte.

O forse non sei ancora stato conquistato dallo sviluppo agile, ma sei interessato ad approfondire l’argomento.

Se questo ti suona familiare, allora questo libro è per te.

Nota: anche se questo libro rivolge la propria attenzione allo sviluppo di applicazioni web, molte di queste idee sono applicabili anche ad attività al di là dello sviluppo di software. I suggerimenti riguardo a piccoli team, progetti veloci, iterazioni continue e molti altri concetti presentati in questo libro possono servire come guida nel caso in cui tu stia per iniziare un’attività, scrivere un libro, disegnare un sito, registrare un album o intraprendere molti altri lavori. Una volta applicata la filosofia Getting Real a un’area della tua vita, vedrai come questi concetti saranno utilizzabili in molte altre tue attività.

---

Chi è 37signals

Cosa facciamo

37signals è un piccolo team che crea software semplice e specifico. I nostri prodotti aiutano la collaborazione e l’organizzazione dei team. Più di 350.000 persone e piccole imprese usano le nostre applicazioni web per organizzarsi. Jeremy Wagstaff, del Wall Street Journal, ha scritto: “I prodotti di 37signals sono strumenti talmente semplici, eleganti ed intuitivi che in confronto Outlook sembra una camera di tortura.” Le nostre applicazioni non ti stresseranno mai.

Il nostro modus operandi

Noi crediamo che il software sia troppo complesso. Moltissime funzionalità, troppi bottoni, troppo da imparare. I nostri prodotti fanno meno di quelli dei nostri competitori — volutamente. Realizziamo prodotti che lavorano più intelligentemente, ti fanno stare meglio, ti consentono di svolgere i tuoi lavori come più ti piace e sono più facili da usare.

I nostri prodotti

Alla data di pubblicazione di questo libro abbiamo 5 prodotti ed un framework open source per lo sviluppo di applicazioni web.

Basecamp rivoluziona il project management. Invece di diagrammi di Gantt, grafici elaborati, pesanti statistiche su fogli di calcolo, Basecamp offre messaggistica, liste delle cose da fare, un semplice strumento di pianificazione, condivisione di documenti di testo e di file. Lo rivoluziona a tal punto che centinaia di migliaia di utilizzatori concordano che sia la soluzione migliore. Farhad Manjoo di Salon.com ha detto: “Basecamp rappresenta il futuro del software sul Web”.

Campfire una chat di gruppo per l’azienda. Le aziende sanno quanto possa essere importante una discussione di gruppo in chat. La messaggistica istantanea convenzionale è perfetta per veloci chat tra due persone, ma è inusabile per 3 o più persone alla volta. Campfire risolve questo e molti altri problemi.

Backpack uno strumento per gestire le informazioni personali, un’alternativa a tutti i software confusionari, complessi e “che promettono di organizzare la tua vita in 25 semplici passi”. Backpack si basa semplicemente su pagine, note, liste di cose da fare, e avvisi basati su email o cellulare; un’idea innovativa per una tipologia di prodotti che non ha un proprio punto di riferimento. Thomas Weber del Wall Street Journal ha detto che è il miglior prodotto della sua classe e David Pogue del New York Times ha chiamato Backpack uno strumento di organizzazione veramente “cool”.

Writeboard consente di scrivere, condividere, revisionare e confrontare il testo o da soli o con più persone. E’ una fresca alternativa ai word processor troppo pesanti che ti offrono il 95% in più del necessario per quello che devi scrivere. John Gruber di Daring Fireball ha detto: “Writeboard è l’applicazione web più chiara e più semplice che abbia mai visto.”. Il guru del Web Jeffrey Zeldman ha detto: “Le brillanti menti di 37signals hanno colpito ancora.”

Ta-da List organizza online tutte le liste delle cose da fare. Puoi tenere le liste per te o condividerle con altri per una più semplice collaborazione. Non c’è modo più veloce per fare le cose. Sono state create più di 100,000 liste con quasi 1,000,000 di elementi.

Ruby on Rails, per sviluppatori, è un framework full-stack ed open source realizzato in Ruby per scrivere velocemente e semplicemente applicazioni web. Rails si preoccupa di gran parte del lavoro lasciandoti concentrare sulla tua idea. Nathan Torkington di O’Reilly ha detto: “Ruby on Rails è impressionante. Usandolo è come guardare un film di kung-fu, dove una dozzina di aggressivi framework si preparano a battere il nuovo arrivato solo per vedersi malamente sconfitti in più modi”. Amiamo questa citazione.

Potete trovare più informazioni sui nostri prodotti e sulla nostra azienda visitando il nostro sito web all’indirizzo www.37signals.com.

---

Caveats, avvisi, e altri avvertimenti preventivi

Ecco elencate le nostre risposte ad alcune lamentele che sentiamo continuamente:

“Queste tecniche non funzioneranno per me.”

Getting Real è un approccio che per noi ha funzionato in modo eccellente. Ciò non significa che le idee contenute in questo libro siano applicabili a tutti i progetti esistenti. Se stai costruendo un’arma, una centrale nucleare, un sistema bancario per milioni di clienti o qualche altro sistema finanziario critico dovrai abbandonare la nostra attitudine “laissez-faire”. In questo caso dovrai prendere ulteriori precauzioni.

Inoltre non deve essere un approccio “o tutto o niente”. Infatti, anche se non puoi abbracciare completamente la filosofia Getting Real, ci saranno sicuramente alcune idee da cui potrai prendere spunto.

“L’idea non è vostra.”

Non stiamo cercando di affermare di aver inventato queste tecniche. Molti di questi concetti esistono in una forma o in un’altra da molto tempo. Non t’irritare se leggi qualche nostro consiglio e ti ricordi di aver già trovato qualcosa di simile su un blog o su qualche altro libro pubblicato più di 20 anni fa. Vedrai che accadrà di sicuro. Queste tecniche non sono esclusive di 37signals, ma ti stiamo semplicemente dicendo come funzionano e ciò che per noi è stato un successo.

“Vedete tutto bianco o tutto nero.”

Se dalle nostre parole ti sembra che sappiamo tutto, sii paziente. Pensiamo che sia meglio presentare le idee schiettamente piuttosto che in modo insicuro e debole. Se tutto ciò ti risulta concitato e arrogante, così sia. Preferiamo provocare piuttosto che introdurre ogni concetto con “dipende…”. A volte queste regole dovranno essere adattate o ripensate e alcune di queste tattiche potrebbero non applicarsi alla tua situazione. Assicurati di usare il tuo giudizio e la tua immaginazione.

“Questo non funzionerà all’interno della mia azienda.”

Pensi d’essere troppo grande per applicare la filosofia Getting Real? Anche Microsoft la sta utilizzando (e non crediamo che la tua azienda sia più grande).

Anche se di solito la tua azienda si organizza a lungo termine con grandi team, c’è sempre un modo per applicare Getting Real. Il primo passo è quello di suddividere i processi in moduli più piccoli. Quando ci sono troppe persone coinvolte non viene concluso niente. Più piccolo sei, più velocemente — e in modo migliore — vengono conclusi i lavori.

E’ vero che puoi assumere qualche commerciale. Introduci la tua azienda alla filosofia Getting Real. Mostrale questo libro e i risultati che si possono raggiungere in meno tempo e con team più snelli.

Spiega che Getting Real è un modo per testare nuovi concetti con un basso rischio e con un piccolo investimento iniziale. Controlla se puoi provare questo concetto estraendo un piccolo progetto da quello iniziale. Dimostra, quindi, i risultati.

Oppure, se vuoi essere davvero coraggioso, muoviti alla luce del sole dimostrando i risultati reali. Questo è l’approccio che ha usato il team di Start.com di Microsoft adottando Getting Real. “Ho osservato il team di Start.com durante il lavoro. Non chiedono mai permessi,” dice Robert Scoble, Tecnico esperto di Microsoft. “Hanno un solo responsabile di progetto a cui riferirsi e avanzano un passo alla volta basandosi sui risultati che ottengono dai feedback”

---

La linea di partenza capitolo 2

Costruire Meno

Fai meno dei tuoi competitori

La conoscenza tradizionale spiega come per battere la concorrenza sia necessario fare meglio. Se gli avversari hanno 4 caratteristiche, tu ne devi avere cinque (oppure 15 o 25). Se spendono x, tu devi spendere xx. Se hanno 20, tu devi avere 30.

Questo tipo di mentalità, una Guerra Fredda che porta a fare sempre meglio, è morta. E’ un modo costoso, ansioso e paranoico per realizzare prodotti. Le aziende ansiose e paranoiche non riescono a guardare avanti, possono solo rimanere indietro. Non possono essere dei leader, ma solo degli inseguitori.

Se vuoi realizzare un’azienda che segue la massa, posa immediatamente questo libro.

Allora cosa dobbiamo fare? La risposta è meno. Fai meno della concorrenza per batterla. Risolvi problemi semplici e lascia a qualcun altro quelli complessi, difficili e disgustosi. Invece di fare sempre di più, cerca di fare meno. Invece di fare più di tutti, cerca di fare meno.

Ritorneremo sul concetto di costruire meno nel corso di questo libro, ma per coloro che sono agli inizi, meno significa:

• Meno caratteristiche
• Meno opzioni/preferenze
• Meno persone e meno struttura aziendale
• Meno meeting e astrazioni
• Meno promesse

---

Qual è il tuo problema?

Realizza software per te stesso

Uno dei migliori modi per realizzare software è quello di cominciare risolvendo i propri problemi. Così facendo sarai tu il potenziale utilizzatore e saprai subito ciò che è importante e ciò che invece non lo è. Questo ti dà un bel vantaggio iniziale nel lanciare un prodotto di successo.

Il trucco è capire che non sei solo. Se tu stai avendo questo problema, è come se centinaia di migliaia di persone fossero sulla tua stessa barca. Questo è il tuo mercato. Non era facile capirlo?

Basecamp è nato da un problema: essendo una web agency necessitavamo di un modo semplice per comunicare con i nostri clienti riguardo ai progetti. Iniziammo col farlo con delle extranet che aggiornavamo manualmente. Ma cambiare manualmente l’html ogni volta che un progetto lo richiedeva non poteva funzionare. I progetti sembravano diventare sempre più vecchi e alla fine venivano abbandonati. Questo era frustrante, ci lasciava disorganizzati e lasciava all’oscuro i nostri clienti.

Così abbiamo iniziato a vedere se erano disponibili altre soluzioni. Ogni strumento che trovavamo o 1) non faceva quello di cui avevamo bisogno o 2) era sovraccaricato di funzionalità che non ci occorrevano — come fatturazione, controlli di accesso, diagrammi, grafici, etc. Sapevamo che ci doveva essere un modo migliore, così decidemmo di realizzare il software da soli.

Quando risolvi un tuo problema, crei uno strumento di cui ti appassioni. La passione è la chiave di tutto. Passione significa che lo userai veramente e te ne prenderai cura. Questa è la via migliore per far si che altri utilizzatori si sentano anche loro appassionati a esso.

---

Finanziati da solo

La ricerca dei fondi è il piano B

La priorità di molti processi di startup è l’acquisizione di fondi dagli investitori. Ricordati però che quando ricorri a finanziatori esterni, dovrai anche rispondere alle loro domande. Le aspettative aumenteranno. Gli investitori rivorranno indietro i propri investimenti, velocemente. La triste realtà è che spesso i soldi prevalgono sulla qualità del prodotto.

Non ci vuole molto per iniziare. L’hardware è economico e una miriade di infrastrutture software sono open source e gratuite. La passione poi non ha costo.

Allora fai quello che puoi con i soldi che hai. Concentrati bene e determina ciò che è davvero essenziale e ciò di cui puoi fare a meno. Cosa puoi fare con tre persone invece che con 10? Cosa puoi fare con 20.000 € invece di 100.000 €? Cosa puoi fare in tre mesi piuttosto che in sei? Cosa puoi fare se lavori tutto il giorno e sviluppi la tua applicazione nel tempo libero?

I vincoli ti forzano a essere creativo

Lavorare con risorse limitate ti porta a combattere presto con i vincoli e in modo più intenso. Questa è una cosa buona. I vincoli portano all’innovazione.

I vincoli inoltre ti forzano a sviscerare la tua idea nelle fasi iniziali piuttosto che dopo — un altro punto a favore. Un mese o due dal debutto dovresti avere un’idea abbastanza precisa sul fatto che possa funzionare o meno. Se funzionerà, sarai capace di autofinanziarti e non avrai bisogno di investimenti esterni. Se la tua idea è un bluff allora è tempo di tornare a progettare. Almeno lo sai subito piuttosto che mesi (o anni) dopo. Inoltre puoi tornare indietro facilmente. Con gli investitori i piani di uscita sono molto più difficili da attuare.

Stai creando software solo per fare velocemente molti soldi? Si vedrà. La verità è che fare velocemente soldi è abbastanza improbabile. Allora è meglio se ti concentri nel realizzare uno strumento di qualità che tu e i tuoi clienti utilizzerete per molto tempo.

---

Stabilisci tempo e budget, lascia flessibile l’obiettivo

Fai il debutto rispettando tempo e budget

Ecco un modo facile per lanciare un’applicazione rispettando tempo e budget: mantienili fissi. Se si presenta un problema non chiedere più tempo o soldi ma riduci l’obiettivo.

Un mito recita: siamo in grado di fare il debutto rispettando tempo, budget e obiettivo. Questo non succede quasi mai e se si verifica la qualità ne risente

Se non puoi realizzare tutto ciò che era stato previsto con le tempistiche e il budget a disposizione non incrementarli. Preoccupati invece di ridurre le funzionalità. C’è sempre tempo per aggiungerle in seguito — il futuro è eterno mentre il presente scorre veloce.

Lanciare un progetto favoloso ma più piccolo rispetto a ciò che era stato pianificato è meglio che lanciare qualcosa di mediocre e pieno di falle solamente perché si dovevano rispettare tempistiche, budget e obiettivi iniziali. Lascia le magie a Houdini. Devi iniziare un vero business realizzando un vero prodotto.

Ecco i benefici nel fissare tempo e budget, mantenendo flessibile l’obiettivo:

• Priorità

  Devi capire ciò che è davvero importante. Cosa includerai nella release iniziale? Questi vincoli ti costringeranno a prendere decisioni sicure piuttosto che a esitare.

• Realtà

  La chiave è presentare delle aspettative. Se tu cerchi di fissare tempo, budget e obiettivo non sarai capace di lanciare un prodotto di alto livello. Sicuramente riuscirai a lanciare qualcosa ma è davvero “qualcosa” quello con cui vuoi debuttare?

• Flessibilità

  La chiave sta nella capacità di cambiare. Fissare tutto rende difficili i cambiamenti. Introdurre flessibilità significa implementare ulteriori opzioni basate su esperienza reale. La flessibilità è tua amica.

La nostra raccomandazione: riduci l’obiettivo. E’ meglio fare metà prodotto che farne uno male a metà (qualcosa in più la leggerai dopo).

---

Trovati un avversario

Ingaggia una battaglia

Spesso il modo migliore per capire come dovrebbe essere la tua applicazione è di comprendere ciò che non dovrebbe essere. Esamina l’applicazione del tuo avversario e ti si schiariranno le idee sulle mosse da fare.

Quando decidemmo di creare un software per il project management sapevamo che Microsoft Project era il re del mercato. Invece di essere intimoriti lo abbiamo usato per motivarci. Abbiamo deciso che Basecamp sarebbe stato completamente differente, un anti-progetto.

Abbiamo capito che project management non significa diagrammi, grafici, report e statiche — ma è comunicazione. Inoltre non deve esserci un project manager seduto in cattedra che mostra a tutti come realizzare il progetto. Si tratta di collaborazione, ognuno deve prendersi delle responsabilità per far sì che il progetto funzioni.

I nostri nemici erano il dittatore “Project Management” e i suoi strumenti di dominio. Volevamo rendere democratico il project management — creando qualcosa a cui tutti avrebbero preso parte (compreso il cliente). I progetti risultano migliori quando tutti prendono parte all’intero processo.

Quando facemmo Writeboard, sapevamo di avere avversari con prodotti dalle caratteristiche sensazionali. Così decidemmo di enfatizzare il lato dell’essenzialità. Creammo un’applicazione che consentiva agli utilizzatori di condividere le idee e collaborare semplicemente, senza sovraccaricarli di funzionalità superflue. Se una caratteristica non era essenziale non la includevamo. Dopo soli tre mesi dal debutto, sono state create più di 100,000 Writeboard.

Quando iniziammo Backpack i nostri avversari erano la struttura e le regole rigide. Dovrebbe essere data agli utenti la possibilità di organizzare le proprie informazioni a modo loro — Evitando di costringerli a utilizzare una serie di passi predefiniti o una pletora di campi obbligatori.

Il vantaggio che hai nell’avere un avversario è il chiaro messaggio di marketing che puoi attuare. Le persone sono attratte dalle controversie. In più capiscono le differenze tra i prodotti comparandoli tra loro. Presentando loro l’applicazione avversaria, racconti proprio la storia che vogliono sentire. Non solo capiranno meglio e più velocemente il tuo prodotto, ma si schiereranno dalla tua parte. Questo è inoltre un modo sicuro per attirare attenzione e accendere in loro la passione.

Detto ciò è importante non farsi ossessionare dagli avversari. Non analizzare troppo i prodotti degli altri, altrimenti inizierai a limitare il modo in cui pensi. Dai solamente uno sguardo e vai avanti per la tua strada e le tue idee.

---

Non dovrebbe essere un obbligo

La tua passione — o la mancanza di essa — brillerà ovunque

Meno la tua applicazione è un compito obbligato da realizzare, meglio sarà. Mantienila piccola e facilmente gestibile in modo da divertirti lavorandoci.

Se l’applicazione non ti esalta, c’è qualcosa di sbagliato. Se ci stai lavorando solamente per prendere soldi, si vedrà. Invece, se ne sarai appassionato, trasparirà ovunque nel prodotto finale. Le persone riescono a leggere tra le righe.

---

Meno Massa capitolo 3

Meno Massa

Più piccolo sei, più facile è cambiare

Più un oggetto è massivo, più energia è necessaria per cambiare l’obiettivo preposto. Questo è vero nel mondo del lavoro quanto è vero nel mondo reale.

Quando si tratta di tecnologie web i cambiamenti devono essere facili ed economici. Se non puoi cambiare istantaneamente perderai terreno rispetto a chi può farlo. Ecco perché devi optare per avere meno massa.

La Massa aumenta a causa di…

• Contratti a lungo termine


• Staff superfluo


• Decisioni inderogabili


• Riunioni su riunioni


• Un processo pesante


• Inventari (fisici o mentali)


• Hardware, software e tecnologie prefissate


• Formati proprietari dei dati


• Il passato che regola il futuro


• Roadmap a lungo termine


• Politiche di ufficio

La Massa è ridotta da…

• Un modo di pensare “just-in-time”


• Membri del team multi-tasking


• Accettare i vincoli, evitando di rimuoverli


• Meno software, meno codice


• Meno funzionalità


• Un team di piccole dimensioni


• Semplicità


• Interfacce ridotte


• Prodotti open source


• Formati aperti dei dati


• Una mentalità aperta che consenta facilmente di ammettere di aver compiuto errori

Con meno massa riesci a cambiare strada velocemente. Puoi reagire ed evolverti. Ti puoi concentrare sulle idee buone lasciando perdere quelle cattive. Puoi ascoltare e rispondere ai tuoi clienti. Puoi integrare da subito nuove tecnologie piuttosto che dopo. Invece di una portaerei, pilota un motoscafo da corsa. Devi godere di tutto ciò.

Immagina, per esempio, un’azienda piccola che ha realizzato un prodotto con poco codice e poche funzionalità. Dall’altra parte c’è un’azienda molto grande che ha un prodotto con molto più codice e funzionalità. Poi immagina che arrivi sul mercato una tecnologia nuova tipo Ajax o un concetto nuovo tipo il tagging. Chi sarà capace di adattare più velocemente il proprio prodotto? Il team con un software mastodontico, con più funzionalità e con una roadmap di 12 mesi o il team con il software più piccolo, con meno funzionalità e con un processo basato su: “concentriamoci su ciò di cui abbiamo bisogno adesso”.

Ovviamente l’azienda con meno massa è in una posizione più favorevole per rispondere alle reali domande del mercato. L’azienda con più massa sarà ancora a discutere sui cambiamenti o li starà esaminando nel suo processo lungo e burocratico, mentre l’azienda più snella avrà già cambiato. L’azienda con meno massa sarà due passi avanti, mentre l’altra starà ancora decidendo come procedere.

Le aziende scattanti, agili e piccole possono cambiare velocemente il proprio business model, il prodotto, le caratteristiche e il messaggio di marketing. Possono fare errori e rimediare a essi velocemente. Possono cambiare le proprie priorità, unire prodotti e specializzarli concentrandosi su particolari aspetti. Ma la cosa più importante è che possono cambiare le proprie menti.

---

Abbassa il costo dei cambiamenti

Rimani flessibile riducendo gli ostacoli al cambiamento

Il cambiamento è il tuo migliore amico. Quanto più è costoso attuare un cambiamento, meno volentieri lo farai. Inoltre hai un notevole svantaggio se il tuo avversario è in grado di effettuare il cambiamento prima di te. Sei morto se il cambiamento diventa troppo oneroso.

Ecco perché rimanere piccoli ti aiuta davvero. L’abilità di cambiare rapidamente è una cosa che i piccoli team hanno di default, cosa che quelli grandi non avranno mai. I grandi invidiano i piccoli in questo. Un cambiamento che può richiedere settimane di massiccia organizzazione in un grande team, può richiedere solamente un giorno in una azienda piccola e agile. Cambiamenti economici e veloci diventano l’arma segreta dei piccoli.

Inoltre ricordati che: Tutti i soldi, tutte le operazione di marketing e tutte le persone del mondo non riusciranno mai a comprare l’agilità che ottieni dall’essere un piccolo.

Quando si parla di web technology i cambiamenti devono essere facili ed economici. Se non puoi cambiare al volo, perderai terreno rispetto a qualcuno che può. Questo è il motivo per cui hai bisogno di “meno massa”.

---

I Tre Moschettieri

Usa un team di tre persone per la versione 1.0

Inizia solamente con tre persone per realizzare la prima versione della tua applicazione. Tre è il numero magico che ti darà abbastanza forza lavoro, permettendoti di rimanere efficiente e agile. Inizia con uno sviluppatore, un grafico e qualcuno che possa muoversi facilmente tra i due mondi.

E’ certamente una sfida realizzare un’applicazione con tre sole persone. Me se riesci a mettere insieme il giusto team sarà sufficiente. Le persone con talento non necessitano di risorse infinite. Esse prosperano se sono messe davanti a un lavoro con vincoli e dove possono usare la loro creatività per risolvere i problemi. La mancanza di forza lavoro ti porterà prima a dei compromessi durante il progetto — e questa è una cosa buona. Ti permetterà di capire prima le tue priorità e sarai capace di comunicare senza preoccuparti continuamente di lasciare qualcuno fuori dal discorso.

Se non puoi realizzare la prima versione con tre persone o hai bisogno di persone differenti o devi ridurre la versione iniziale. Ricordati che è giusto tenere piccola e compatta la prima versione. Vedrai velocemente se la tua idea ha le ali per decollare e se non le ha avrai una base semplice e chiara da cui ripartire.

---

Abbraccia i vincoli

Lascia che le limitazioni ti portino verso soluzioni creative

Non c’è mai abbastanza tempo, soldi o persone per andare in giro.

Questo è un bene.

Invece che diventare pazzo per questi vincoli, accoglili. Lasciati guidare da essi. I vincoli portano innovazione e ti costringono a specializzarti. Invece di cercare di rimuoverli, usali a tuo vantaggio.

Quando 37signals stava realizzando Basecamp, eravamo carichi di limitazioni. Avevamo:

• Una web agency da mandare avanti


• Lavori in corso di clienti già acquisiti


• 7 ore di fuso orario (David programmava in Danimarca, mentre tutti noi eravamo negli Stati Uniti)


• Un piccolo team


• Nessun finanziamento esterno

Sentivamo il ritornello “non abbastanza”. Così tenevamo basso l’obiettivo. Ecco perché non potevamo metterci troppo all’inizio. Prendemmo le funzionalità più grandi e le dividemmo in piccole parti che portammo avanti una alla volta. Ci muovemmo passo dopo passo, scegliendo lungo il cammino a quale parte dare priorità.

Questo ci portò a realizzare soluzioni creative. Abbassammo il nostro costo di cambiamento realizzando meno software. Abbiamo dato alle persone solamente quelle funzionalità che le consentivano di risolvere da soli i propri problemi — e facemmo il debutto. La differenza nell’orario e la distanza tra noi hanno reso più efficiente la nostra comunicazione. Invece di fare meeting dal vivo, comunicammo quasi esclusivamente via chat o per email, cosa che ci ha costretto ad arrivare al punto della questione velocemente.

I vincoli sono spesso dei vantaggi nascosti. Dimentica capitali da investire, release con lunghi cicli e assunzioni veloci. Piuttosto lavora con ciò che hai.

---

Sii te stesso

Differenziati dalle grandi aziende rapportandoti in modo diretto e amichevole

Molte aziende piccole fanno l’errore di voler apparire grandi. E’ come se percepissero la propria dimensione come una debolezza che necessita di essere nascosta. Questo è sbagliato. Essere piccoli può davvero essere un immenso vantaggio, soprattutto dal punto di vista della comunicazione.

Le piccole aziende hanno poche formalità, meno burocrazia e più libertà. Le aziende più piccole sono automaticamente più vicine al cliente. Questo significa che possono comunicare in modo più diretto e personale con i clienti. Inoltre se sei piccolo puoi utilizzare un linguaggio più familiare piuttosto che uno complesso. Il tuo prodotto o il tuo sito possono avere una voce umana invece di sembrare un suono monotono e formale. Essere piccolo significa che puoi essere sullo stesso piano del tuo cliente piuttosto che rivolgersi a esso dall’alto verso il basso.

Nelle piccole aziende ci sono anche vantaggi dal punto di vista delle comunicazioni interne. Puoi fare a meno delle formalità. Non c’è bisogno di processi difficoltosi e molteplici comunicazioni su tutto. All’interno del processo ognuno può parlare apertamente e onestamente. Questo flusso libero di idee è uno dei maggiori vantaggi del rimanere piccoli.

---

Priorità capitolo 4

Qual è la Grande Idea

Diversificati dalle aziende più grandi, cercando di essere diretto e amichevole

Definisci esplicitamente un’immagine unica per la tua applicazione, rispondendo alle domande: che cosa rappresenta la tua applicazione? E’ davvero tutto ciò? Prima di iniziare a progettarla o a scrivere codice devi conoscere l’obiettivo del tuo prodotto — la visione generale. Pensa in grande. Perché esiste? Che cosa la differenzia da altri prodotti similari?

Questa visione guiderà le tue decisioni e ti manterrà su un cammino consistente. Quando incontrerai un ostacolo ti dovrai chiedere, “Siamo ancora coerenti con la visione?”

Inoltre la tua visione dovrebbe essere breve. Una sola frase dovrebbe riassumere l’idea generale. Ecco la visione per ognuno dei nostri prodotti:

• Basecamp: Project management è comunicazione
• Backpack: Viviamo alla giornata insieme
• Campfire: Una chat di gruppo fatta con messaggistica istantanea fa pena


• Ta-da List: Competere con una nota su post-it
• Writeboard: Word è eccessivo

Con Basecamp, per esempio, la visione era “Project management è comunicazione.” Sentivamo fortemente che una comunicazione reale in un progetto portava a una conoscenza, a una relazione e a una forza collettiva. Mettere tutti nella stessa pagina a lavorare con un obiettivo comune. Sapevamo che se Basecamp fosse riuscito in questo, tutto il resto sarebbe venuto di conseguenza.

Questa visione ci ha portato a mantenere Basecamp più aperto e trasparente possibile. Invece di limitare la comunicazione all’interno dell’agenzia, abbiamo dato l’accesso anche ai clienti. Ci siamo preoccupati meno della parte di diritti e permessi, cercando di incoraggiare tutti i partecipanti a prendere parte al progetto. L’idea ci ha portato a togliere diagrammi, grafici, report, statistiche e fogli di calcolo, facendoci concentrare sugli aspetti comunicativi come messaggi, commenti, liste delle cose da fare e condivisione di file. Prima di tutto forma la visione sull’approccio generale dopo di che tutte le piccole decisioni diventeranno più facili da gestire.

---

All’inizio ignora i dettagli

Inizia dal generico e procedi fino al dettaglio

Diventiamo pazzi per i dettagli.

• Lo spazio tra gli oggetti


• L’interlinea perfetta


• Il colore perfetto


• Le parole perfette


• Quattro linee di codice piuttosto che sette


• 90% contro 89%


• 760px contro 750px


• $39/mese contro $49/mese

Il successo e la soddisfazione derivano dai dettagli.

Comunque non si ottiene solo successo con i dettagli. Ci troverai anche stasi, dissenso, meeting e ritardi. Questi possono uccidere l’entusiasmo e abbassare le possibilità di successo.

Quante volte sei stato un’ intera giornata a sistemare un solo dettaglio o un singolo elemento del codice? Quante volte hai trovato che i progressi fatti durante il giorno in realtà non lo erano? Questo succede quando durante l’intero processo ti focalizzi troppo presto sui dettagli. Hai tutto il tempo che vuoi per essere perfezionista. Basta che tu lo faccia in seguito.

Durante la prima settimana non ti preoccupare della dimensione del carattere dell’intestazione. Durante la seconda settimana non devi trovare proprio quella tonalità perfetta di verde. Nella terza non hai bisogno di muovere il bottone “submit” di soli tre pixel sulla destra. Per ora metti tutti gli elementi nella pagina. Poi usali. Assicurati che funzionino correttamente. Dopo puoi aggiustare e perfezionare il tutto.

I dettagli stessi rivelano come usi ciò che costruisci. Ti accorgerai di ciò che necessita di più attenzione. Sentirai ciò che manca. Conoscerai quali sono le falle da riparare perché le noterai continuamente. Questo è il momento in cui devi porre attenzione, non troppo presto.

---

C’è un problema quando c’è un problema

Non perdere tempo su problemi che ancora non hai

Hai davvero bisogno di preoccuparti di scalare l’applicazione per 100.000 utenti oggi quando saranno necessari due anni per arrivare a quel punto?

Hai davvero bisogno di assumere 8 programmatori se oggi te ne servono solo tre?

Hai davvero bisogno oggi di 12 server al top della gamma se puoi utilizzarne 2 per un anno?

Improvvisa

Spesso le persone perdono la maggior parte del tempo cercando di risolvere problemi che ancora non hanno. Non lo fare. Ecco, noi abbiamo lanciato Basecamp senza la possibilità di addebitare i pagamenti ai clienti! Dato che i pagamenti del prodotto sono fatti su base mensile, sapevamo di avere 30 giorni per implementarlo. Abbiamo usato quel tempo per risolvere problemi più urgenti, poi dopo il debutto, ci siamo confrontati con il sistema di pagamento. E’ stato risolto con successo (e il tempo limitato ci ha costretto ad adottare una soluzione semplice senza troppi fronzoli ed effetti speciali).

Non ti sforzare sulle cose fin quando non sei costretto. Non sovra costruire. Aumenta hardware e software in base alle necessità. Se sei lento per una o due settimane non è la fine del mondo. Devi essere solamente onesto: spiega ai tuoi clienti che stai avendo dei problemi a causa del numero crescente di utilizzatori. Non saranno entusiasti, ma apprezzeranno il tuo candore.

Il bilancio finale: Prendi le decisioni in tempo, cioè quando hai accesso alle informazioni di cui hai bisogno. Nel frattempo sarai capace di porre attenzione sulle cose che richiedono cura.

---

Assumi i Clienti Giusti

Cerca il cuore del mercato per la tua applicazione e concentrati solamente su quello

Il cliente non è sempre quello giusto. La verità è che tu devi capire chi è e chi non è giusto per la tua applicazione. La buona notizia è che internet ti permette di trovare le persone giuste più facilmente.

Se cercherai di accontentare qualcuno, non accontenterai qualcun altro

Quando costruimmo Basecamp concentrammo il nostro marketing sulle web agency. Limitando il nostro mercato, abbiamo realizzato il prodotto in modo da attrarre clienti appassionati che, a turno, lo avrebbero evangelizzato. Cerca di capire quali saranno gli utilizzatori della tua applicazione, per poi concentrarti nell’accontentarli.

---

Rendi scalabile l’applicazione dopo

Ancora non hai un problema di scalabilità

“La mia applicazione sarà scalabile quando milioni di persone inizieranno a utilizzarla?”

La sai una cosa? Aspetta fino quando non accadrà veramente. Se avrai un massiccio numero di persone che sovraccaricano il tuo sistema allora devi gioire! Questo è un bel problema da avere. La verità è che la maggior parte delle applicazioni web non raggiungerà mai quella fase. Inoltre, anche se comincerai a ottenere un sovraccarico, non sarà mai un problema istantaneo da niente a tutto. Avrai tempo per risolvere il problema. In più avrai più dati e benchmark reali che potrai utilizzare per scoprire le aree dell’applicazione che necessitano di ottimizzazione.

Per esempio abbiamo lanciato Basecamp su di un singolo server per il primo anno. Dato che è stato un setup semplice, ci abbiamo impiegato solamente una settimana per implementarlo. Non abbiamo iniziato con un cluster composto da 15 macchine o speso mesi preoccupandoci sulla scalabilità

Abbiamo avuto qualche problema? Alcuni. Ma abbiamo anche capito che la maggior parte dei problemi di cui avevamo paura, come una piccola lentezza, in realtà non erano grossi problemi per i nostri clienti. Per tutto il tempo che riesci a tenere le persone nel giro e sarai onesto con loro sulla situazione, ti capiranno. Riesaminando l’esperienza, siamo totalmente contenti di non aver posticipato il debutto di alcuni mesi per creare “il setup perfetto.”

Come priorità crea all’inizio un prodotto con una base solida piuttosto che ossessionarti su problemi di scalabilità e server farm. Crea una grande applicazione e in seguito preoccupati su cosa fare una volta che ha avuto un successo travolgente. Altrimenti potresti buttare via energie, tempo e soldi per risolvere qualcosa che non succederà mai.

Che tu ci creda o no, il problema più grande non è la scalabilità, ma arrivare al punto di aver bisogno di scalare. Senza il primo problema non avrai mai il secondo.

---

Crea Software con personalità

La tua applicazione deve schierarsi

Alcune persone affermano che il software dovrebbe essere agnostico. Dicono sia arrogante da parte degli sviluppatori limitare caratteristiche o ignorare richieste di funzionalità. Dicono che il software dovrebbe sempre essere il più flessibile possibile.

Noi pensiamo che tutto ciò sia una cavolata. Il miglior software ha una visione. Il miglior software è schierato. Quando qualcuno usa un software non sta solo cercando delle funzionalità, ma un approccio. Sta cercando una visione. Definisci la tua visione e procedi con essa.

E ricordati, se a loro non piace la tua visione ce ne sono tante altre disponibili là fuori. Non inseguire persone che non renderai mai felici.

Un esempio perfetto è l’idea originale del wiki. Ward Cunningham e colleghi hanno volutamente tolto dal wiki molte caratteristiche precedentemente considerate fondamentali nella scrittura collaborativa di documenti. Invece di attribuire ogni modifica del documento a una data persona, hanno rimosso ogni riferimento di appartenenza. Hanno reso il contenuto impersonale e senza riferimenti di tempo. Hanno deciso che non era importante chi scriveva il contenuto o quando veniva modificato. Questo ha fatto la differenza. Questa decisione ha incoraggiato e promosso il senso di comunità ed è stata fra le chiavi del successo della Wikipedia.

Le nostre applicazioni hanno percorso un cammino simile. Non cercano di andar bene per tutte le persone. Hanno personalità. Cercano clienti che in realtà sono partner. Parlano a persone che condividono la nostra visione. O sei dentro o sei fuori.

---

Scelta delle Funzionalità capitolo 5

Mezzo, non fatto a metà

Costruire mezzo prodotto, non un prodotto fatto a metà

Siate molti cauti con l’approccio “fa anche il caffè” sviluppando applicazioni web. Buttate dentro ogni idea che sembra buona e vi troverete con qualcosa di fatto a metà e non finito. Quello che vi serve è un mezzo prodotto che spacchi tutto!

Concentratevi sulle funzioni essenziali. Le buone idee possono sempre essere incorporate in seguito!Prendete ciò che vi prefiggete per il vostro prodotto e dividetelo a metà. Ripulite funzionalità finché non avete ciò che vi sembra veramente essenziale. Poi fatelo ancora!

Con Basecamp, noi abbiamo iniziato dal sistema di messaggistica. Sapevamo che quello era il cuore dell’applicazione, per cui abbiamo lasciato da parte per il primo momento la gestione delle scadenze, le liste delle cose da fare e altro ancora. Questo ci ha consentito di basare le nuove decisioni sull’uso reale invece che su previsioni infondate.

Iniziate con una applicazione snella e ben fatta, e lasciate che prenda piede. A quel punto potrete aggiungere funzioni costruendo sulle fondazioni ormai consolidate

---

Semplicemente non è importante!

Solo le parti essenziali

La nostra risposta preferita alla domanda “perché non hai fatto questo o quello?” è semplicemente “Non è importante!”. Tale frase incorpora ciò che rende grande un prodotto. Scoprire cosa conta e lasciare fuori il resto!.

Al lancio di Campfire ricevevamo spesso dai primi utilizzatori alcune delle domande seguenti :

“Perché segnare il tempo ogni 5 minuti? Perché non dare un tempo a ogni riga della conversazione?” Risposta: non è importante. Quanto spesso avete realmente bisogno di tracciare ogni frase di una conversazione al minuto o addirittura al secondo? Sicuramente non il 95% del tempo. Assegnare l’ora di 5 minuti in 5 minuti è sufficiente e semplice.

“Perché non consentite colori, grassetto, corsivo o formattazione nelle conversazioni?” Risposta: non è importante. Se necessitate di enfasi su una parola o una frase avete sempre il fidato tasto CAPS LOCK, oppure potete aggiungere qualche *. Quelle soluzioni non richiedono supporto, nè risorse tecniche, nè potenza di calcolo nè ancora devono essere apprese. In ogni caso, la formattazione precisa in una chat semplicemente non è importante!.

“Perché non mostrate il numero di utenti in ciascuna stanza?” Risposta: non è importante. Il nome di tutti è elencato, ma per voi che differenza fa se ci sono 12 o 16 persone nella conversazione? Se non altera il vostro comportamento, semplicemente non è importante!

Sarebbe bello avere queste funzioni? Forse. Ma sono essenziali? Contano davvero? No e ancora no. Ed ecco il motivo per cui sono state lasciate fuori. I migliori designer e programmatori non sono quelli che hanno le migliori nozioni, o le dita più agili, e neanche quelli che fanno volare Photoshop o il loro programma preferito, ma quelli che sanno determinare cosa importa e cosa no. Lì si ottengono reali miglioramenti.

La maggior parte del vostro tempo è sprecata facendo cose non importanti. Imparando a tagliare fuori pensieri e funzionalità non essenziali, potrete raggiungere la produttività che avete sempre sognato.

---

Inizia con un No

Rendi le funzionalità difficili da implementare

Il segreto per costruire metà prodotto invece di un prodotto a metà è dicendo no.

Ogni volta che dici sì a una caratteristica, stai adottando un figlio. Devi portare il tuo pargolo per tutta la catena di eventi (nel design, nell’implementazione, nel testing, etc.). Inoltre una volta che la funzionalità è uscita devi continuare a supportarla. Almeno prova a rilasciare la funzionalità lontano dai tuoi clienti e guarda come si annoieranno.

Non essere l’uomo dei sì

Rendi ogni funzionalità difficile da implementare. Fai in modo che ognuna di esse difenda se stessa e si dimostri una superstite. E’ come “Fight Club.” Dovresti considerare solo quelle funzionalità che riescono a stare tre giorni nell’anticamera in attesa di entrare dentro.

Ecco perché devi iniziare dicendo no. Ogni nuova caratteristica aggiuntiva che ci arriva — o viene dall’interno — incontra un no. Ascoltiamo, ma non prendiamo decisioni. La risposta iniziale è “non ora.” Se successivamente una richiesta continua a tornare, allora significa che è tempo di dedicargli uno sguardo più approfondito. Dopo, e solamente dopo, iniziamo a considerarla veramente sul serio.

E cosa dite alle persone che si lamentano quando non adotterai una loro caratteristica suggerita? Ricorda loro come mai adorano la tua applicazione. “Ti piace perché diciamo no. Ti piace perché non fa altre 100 cose. Ti piace perché non cerca di accontentare tutti per tutto il tempo.”

---

Costi nascosti

Mostra apertamente il prezzo di nuove funzionalità

Anche se una funzionalità oltrepassa la fase “no”, hai sempre bisogno di mostrare i suoi costi nascosti.

Per esempio, stai attento a funzionalità correlate (come caratteristiche che portano a ulteriori funzionalità). Abbiamo avuto una richiesta di aggiungere a Basecamp un tab per i meeting. Sembra abbastanza semplice fino a che non lo esamini più attentamente. Pensa a tutti gli oggetti di cui un tab per gli incontri potrebbe avere bisogno: luogo, ora, stanza, persone, inviti via email, integrazione con il calendario, documentazione di supporto, etc. Questo per non parlare che avremmo dovuto cambiare gli screenshot promozionali, le pagine del tour, le pagine delle faq e della guida, i termini di utilizzo e molto altro. Tieni presente che una semplice idea può aumentare rapidamente di dimensione trasformandosi in un grosso problema.

Per ogni nuova caratteristica hai bisogno di…

• 1. Dire no.


• 2. Obbliga la caratteristica a dimostrare il suo valore.


• 3. Se è ancora “no”, fermati qui. Se è un “sì,” vai avanti…


• 4. Progetta le videate e l’interfaccia utente.


• 5. Disegna le videate e l’interfaccia utente.


• 6. Programmala.


• 7-15. Testa, aggiusta, testa, aggiusta, testa, aggiusta, testa, aggiusta…


• 16. Controlla se gli aiuti testuali hanno bisogno di essere modificati.


• 17. Aggiorna il tour del prodotto (se necessario).


• 18. Aggiorna la pubblicità (se necessario).


• 19. Aggiorna le condizioni di vendita (se necessario).


• 20. Controlla se qualche promessa è stata infranta.


• 21. Controlla se la struttura dei prezzi è stata influenzata.


• 22. Lancia.


• 23. Trattieni il respiro.

---

Riesci a gestirlo?

Realizza qualcosa che puoi gestire

Se lanci un programma di affiliazioni hai successivamente i sistemi pronti per gestire la fatturazione e i pagamenti? Forse dovresti solamente consentire alle persone di guadagnare crediti con la loro registrazione piuttosto che scrivere, firmare e inviargli via email un assegno ogni mese.

Puoi permetterti di dare 1GB di spazio gratuitamente solamente perché lo fa Google? Forse dovresti iniziare con una quantità inferiore, tipo 100MB, o fornire spazio solamente a coloro che pagano.

In conclusione: Costruisci prodotti e offri servizi che puoi gestire. E’ facile fare delle promesse. E’ molto più difficile mantenerle. Devi essere sicuro se quello che stai facendo è un qualcosa che puoi davvero sostenere — dal punto di vista organizzativo, strategico e finanziario.

---

Soluzioni umane

Costruisci un software generale incoraggiando le persone a crearsi le proprie soluzioni

Non mettere dei vincoli agli utilizzatori. Piuttosto rendi generico il tuo software in modo che ognuno possa trovare la propria soluzione. Dai alle persone solamente ciò che è necessario per consentire loro di risolvere i problemi come preferiscono. Dopo togliti di mezzo.

Quando abbiamo realizzato Ta-da List abbiamo omesso svariate funzionalità intenzionalmente. Non c’è modo per assegnare un cosa da fare a qualcuno, non c’è modo per segnare una data di scadenza, non c’è modo per categorizzare gli elementi, etc.

Abbiamo lasciato lo strumento pulito e semplice permettendo alle persone di essere creative. Gli utilizzatori hanno scoperto come risolvere da soli i propri problemi. Se volevano aggiungere una data a un elemento della lista potevano semplicemente aggiungere (scadenza: 7 Aprile 2006) davanti a esso. Se volevano aggiungere una categoria potevano anteporre [Libri] davanti all’oggetto. Ideale? No. Infinitamente flessibile? Sì.

Se avessimo cercato di creare un software specifico per gestire questi scenari, lo avremmo reso meno utile a tutti quei casi dove gli scenari non si sarebbero potuti applicare

Fai del tuo meglio con le fondamenta del problema poi mettiti da parte. Gli utilizzatori troveranno le proprie soluzioni e convenzioni all’interno del tuo framework generico.

---

Dimenticati le richieste di funzionalità

Lascia che siano i tuoi clienti a ricordarti ciò che è importante

I clienti vogliono che tutto sia alla luce del sole. Ti sommergeranno con richieste di funzionalità. Basta controllare i forum dei nostri prodotti; la categoria della richiesta di funzionalità sorpassa sempre le altre di un ampio margine.

Sentiamo cose del tipo “questa piccola funzionalità aggiuntiva” o “questa non può essere complicata” o “non sarebbe facile aggiungere questa” o “dovrebbero occorrere pochi secondi per inserire questa” o “se aggiungete questa potrei pagare il doppio” e così via.

Certo non critichiamo le persone per le richieste che fanno. Anzi li incoraggiamo e vogliamo sentire ciò che hanno da dire. La maggior parte delle cose che aggiungiamo ai nostri prodotti deriva proprio dalle richieste dei clienti. Ma come abbiamo detto precedentemente dovresti rispondere di no la prima volta. Allora che cosa dovrai fare con tutte queste richieste? Dove memorizzarle? Come dovrai gestirle? Non devi gestirle. Leggile solamente e poi gettale via.

Proprio così, leggile, buttale via e scordatele. Potrebbe sembrare blasfemo, ma quelle che sono importanti torneranno ugualmente a galla. Quelle sono le sole di cui avrai bisogno di ricordarti. Quelle sono veramente le sole essenziali. Non ti preoccupare ti tracciare e salvare ogni richiesta che arriva. Lascia che i tuoi clienti siano la tua memoria. Se davvero vale la pena di ricordarsi una richiesta, allora te la rammenteranno fino a che non potrai più scordatela.

Come siamo arrivati a questa conclusione? Quando all’inizio abbiamo lanciato Basecamp tenevamo traccia delle principali richieste in una lista apposita. Quando una richiesta veniva ripetuta da qualcun altro aggiornavamo la lista con un marcatore in più (II o III o IIII, etc). Pensavamo che un giorno ci saremmo messi a rivedere la lista iniziando a lavorare dalle richieste più frequenti.

La verità è che non l’abbiamo mai guardata. Sapevamo già cosa fare perché i nostri clienti ce lo ricordavano costantemente, facendo le stesse richieste continuamente. Non c’era necessitò di una lista o di complesse analisi, dato che tutto succedeva in tempo reale. Non ti puoi scordare ciò che è importante quando ti viene ricordato ogni giorno.

Ancora una precisazione: Non significa che dovrai includere una funzionalità solamente perché x persone te l’hanno richiesta. Talvolta è meglio dire no e mantenere la propria visione del prodotto.

---

Tieni la maionese

Chiedi alle persone quello che non vogliono

La maggior parte dei sondaggi e delle domande sono incentrate su ciò che le persone vogliono in un prodotto. “Quale funzionalità pensi che sia mancante?” “Se potessi aggiungere una cosa, quale sarebbe?” “Che cosa renderebbe questo prodotto più utile per te?”

E l’altra faccia della medaglia? Perché non chiedere alle persone ciò che non vogliono? “Se potessi rimuovere una funzionalità, quale sarebbe?” “Che cosa non usi?” “Che cosa ti piace di più?”

Aggiungere non è la risposta. Alcune volte il favore più grosso che puoi fare ai tuoi clienti è togliendo loro qualcosa.

---

Processo capitolo 6

Gareggia con un Software Funzionante

Crea velocemente qualcosa di concreto e funzionante

Il software funzionante è il modo migliore per creare momentum, metti insieme il tuo team e getta via le idee che non funzionano. Questa dovrebbe essere la priorità numero uno fin dal primo giorno.

Ok fare meno, saltare dettagli e prendere scorciatoie all’interno del processo se questo ti porterà a un software funzionante più velocemente. Una volta che ci sei, sarai ricompensato da una prospettiva molto più definita su come procedere. Sia storie, sia wireframe che prove in html sono solamente approssimazioni della realtà. Un software funzionante è qualcosa di concreto.

Con il lancio di un software concreto e funzionante si ottengono un accordo e una interpretazione veritieri. Eviti argomenti caldi e argomentazioni che si riveleranno non essere importanti. Ti rendi conto che parti che pensavi ininfluenti sono invece cruciali.

Le cose concrete portano a reazioni reali. E questa è la via per arrivare alla verità.

---

Ripulisci e Ripeti

Lavora per iterazioni

Non aspettarti di ottenere tutto perfettamente funzionante al primo colpo. Lascia che l’applicazione cresca e ti parli. Lasciala cambiare ed evolvere. Con un software web-based non è necessario iniziare con un prodotto perfetto. Realizza schermate, usale, analizzale e riparti di nuovo.

Invece di concentrarti in un primo momento nel realizzare tutto in modo perfetto, il processo iterativo ti consente di prendere decisioni ponderate via via che procedi. In più hai un’applicazione attiva e più veloce in quanto non devi raggiungere subito la perfezione. Il risultato è un feedback concreto e linee guida reali su cui porre la propria attenzione.

Le iterazioni portano alla liberazione

Non hai bisogno di raggiungere la perfezione al primo tentativo se sai che potrai farlo ugualmente in un secondo momento. Sapendo questo procederai mettendo in pratica le idee per vedere se potranno decollare.

---

Dall’Idea all’Implementazione

Vai dal brainstorming agli schizzi all’HTML al coding

Ecco il processo che usiamo per essere Getting Real:

Brainstorming

Inizia con le idee. Cosa farà questo prodotto? Per Basecamp abbiamo cercato di capire le nostre esigenze. Volevamo postare gli aggiornamenti ai progetti. Volevamo che i nostri clienti partecipassero. Sapevamo che questi progetti avevano delle milestone. Volevamo centralizzare gli archivi in modo che le persone potessero ritrovare facilmente le vecchie cose. Volevamo avere un occhio puntato su tutti i nostri progetti. Tutte queste assunzioni e alcune altre insieme sono servite per creare le fondamenta.

Questa fase non tratta i dettagli principali. E’ incentrata sulle grandi domande. Che cosa dovrebbe fare l’applicazione? Come sapremo quando sarà utile? Che cosa andremo a fare esattamente? E’ una fase dedicata a idee ad alto livello, non su discussioni a livello di pixel. A questa fase, i dettagli sono senza significato.

Schizzi su carta

Gli schizzi sono veloci, rudi ed economici ed è esattamente il punto da cui devi partire. Disegna oggetti. Scrivi quello che ti viene in mente. Box, cerchi, linee. Metti le tue idee direttamente su carta. In questa fase l’obiettivo dovrebbe essere quello di convertire concetti in interfacce approssimative. Si tratta di esperimenti. Non ci sono risposte errate.

Crea le schermate HTML

Realizza una versione html di quella funzionalità (o una sezione o un diagramma di flusso se è più appropriato). Fai in modo che qualcosa di concreto sia disponibile in modo che ognuno possa vedere come appare sullo schermo.

Per Basecamp all’inizio facemmo la schermate “scrivi un messaggio”, poi quella “modifica un messaggio” e tutto iniziò da lì.

Non scrivere ancora righe di codice. Realizza solamente un modello in html e css. L’implementazione viene in un secondo momento.

Programma

Quando il modello sembra buono e dimostra sufficienti funzionalità, vai avanti e inizia a programmare.

Durante l’intero processo ricordati di rimanere flessibile e di aspettarti molteplici iterazioni. Ti dovresti sentire libero di poter gettare via le parti fatte di ogni iterazione e di ricominciare dall’inizio se capisci che qualcosa non va. E’ naturale ripetere questo ciclo innumerevoli volte.

---

Evita le preferenze

Decidi i piccoli dettagli in modo che non lo debba fare il tuo cliente

Ti trovi davanti a una decisione difficile: quanti messaggi dobbiamo includere in ogni pagina? La prima propensione potrebbe essere quella di dire: “Lasciamo che sia una preferenza in modo che le persone possano scegliere 25, 50 o 100 messaggi.” C’è comunque un modo più facile. Prendi una decisione.

Le preferenze sono un modo per evitare di prendere decisioni difficili.

Invece di usare la tua esperienza per scegliere la miglior soluzione, la stai lasciando nelle mani dei clienti. Potrebbe sembrarti di fare loro un favore, ma in realtà non stai che aumentando loro il lavoro (e in genere sono indaffarati abbastanza). Schermate di preferenze con opzioni senza fine fanno venire il mal di testa ai clienti, non sono una benedizione. I clienti non dovrebbero pensare a ogni dettaglio importante — non mettere su di loro un peso che dovrebbe essere di tua responsabilità.

Le preferenze sono diaboliche anche perché portano a creare più software. Maggiori sono le opzioni, più codice è necessario. E in più è richiesto maggiore testing e progettazione. Inoltre sono da tenere presenti le permutazioni delle preferenze e le schermate che non siamo riusciti a immaginare. Questo significa bug che non avevamo previsto: layout non validi, tabelle corrotte, problemi strani di paginazione, etc.

Prendi una decisione

Prendi decisioni semplici nell’interesse dei tuoi clienti. Questo è quello che abbiamo fatto per Basecamp. Il numero di messaggi per pagina è di 25. Nella pagina di apertura sono mostrati gli ultimi 25 oggetti. I messaggi sono ordinati cronologicamente partendo dal più recente. I 5 progetti più recenti sono mostrati nella dashboard. Non ci sono opzioni. Questo è l’unico modo in cui appare.

Certo, potresti fare una scelta sbagliata. Nel caso in cui succeda, gli utenti si lamenteranno e te ne parleranno. Come sempre puoi fare la modifica. Getting Real significa poter cambiare tutto al volo.

---

“Fatto!”

Le decisioni sono temporanee quindi decidi e vai avanti

Fatto. Inizia a pensarla come la parola magica. Quando arrivi ad aver fatto significa che qualcosa è terminato. Una decisione e stata presa e puoi andare avanti. Fatto significa che stai creando momentum.

Ma aspetta, cosa succede se sbagli completamente e prendi la decisione errata? Va bene lo stesso. Questa non è un’operazione al cervello, è un’applicazione web. Inoltre continuiamo a dirti che in ogni caso dovrai rivedere molte volte funzionalità e idee durante l’intero processo. Quindi non ti paralizzare con l’analisi dell’applicazione. Questo contribuisce solo a rallentare il progresso e a buttar giù il morale.

Considera invece l’importanza di muoverti veloce e in avanti. Acquisisci il ritmo di prendere decisioni. Prendi una decisione veloce e semplice e poi torna indietro e cambia quella decisione che non funziona.

Accetta che le decisioni siano temporanee. Accetta che possano accadere errori e realizza che non è un grosso problema fintanto che puoi correggerli velocemente. Esegui, crea momentum e vai avanti.

---

Testa sul campo

Testa la tua applicazione utilizzandola nel mondo reale

Non c’è un sostituto migliore delle persone vere che utilizzino la tua applicazione in modo concreto. Ottieni dati reali. Ottieni feedback veri. In seguito migliora l’applicazione basandoti su queste informazioni.

I test formali di usabilità sono troppo rigidi. Le impostazioni del laboratorio non riflettono la realtà. Se stai dietro alle spalle di qualcuno avrai qualche idea su quello che funziona o no, ma generalmente le persone non agiscono bene quando sono sotto i riflettori. Quando qualcun altro sta guardando, le persone sono molto più attente a non commettere errori — tuttavia gli errori sono proprio le cose che stai cercando.

Piuttosto rilascia delle funzionalità beta solamente a poche persone all’interno dell’applicazione stessa. Lascia che provino queste funzionalità beta insieme a quelle della versione standard. Questo esporrà le funzionalità a veri dati e flussi di lavoro di quelle persone. E questo è proprio dove otterrai risultati reali.

Inoltre non devi avere una versione release e una beta. Dovrebbero sempre essere la stessa cosa. Con una versione beta separata otterrai solamente dati superficiali. La versione reale, con qualche caratteristica beta all’interno, sarà quella che funzionerà davvero.

---

Restringi il tuo tempo

Suddividilo in parti

Stime che si protraggono per settimane o addirittura mesi sono solamente delle fantasie. La verità è che non saprai quello che succederà in futuro.

Per questo restringi il tuo tempo. Scomponi le tempistiche in parti più piccole. Invece di un progetto di 12 settimane, ragiona come se fossero 12 progetti di una settimana ciascuno. Invece di stimare compiti di oltre 30 ore, scomponili in parti da 6-10 ore realistiche. Poi procedi un passo alla volta.

La stessa teoria si applica anche ad altri problemi. Sei davanti a un problema troppo grande per affrontarlo mentalmente tutto insieme? Scomponilo. Abituati a suddividere i problemi in parti sempre più piccole fino a che non sei capace di digerirle.

---

L’Organizzazione capitolo 7

Unità

Non dividere in silos

Troppe aziende dividono design, sviluppo, copywriting, supporto e marketing in diversi silos. Mentre la specializzazione ha i suoi vantaggi, essa crea anche una situazione in cui i componenti dello staff vedono solo il loro proprio piccolo mondo invece dell’intero contesto dell’applicazione web.

Per quanto possibile, integra il tuo team in modo che ci sia un sano dialogo avanti-e-indietro attraverso i processi. Costruisci un sistema di controlli ed equilibri. Non fare in modo che le cose vengano perse durante la traduzione. Fai in modo che i copywriter lavorino coi designer. Fai in modo che le domande al supporto vengano viste dagli sviluppatori.

Ancora meglio, assumi gente con talenti multipli che possa indossare panni differenti durante lo sviluppo. Il risultato finale sarà un prodotto più armonioso.

---

Alone Time

People need uninterrupted time to get things done

37signals is spread out over four cities and eight time zones. From Provo, Utah to Copenhagen, Denmark, the five of us are eight hours apart. One positive side effect of this eight hour difference is alone time.

There are only about 4-5 hours during the day that we’re all up and working together. At other times, the us team is sleeping while David, who’s in Denmark, is working. The rest of the time, we’re working while David is sleeping. This gives us about half of the day together and the other half alone.

Guess which part of the day we get the most work done? The alone part. It’s not that surprising really. Many people prefer to work either early in the morning or late at night — times when they’re not being bothered.

When you have a long stretch when you aren’t bothered, you can get in the zone. The zone is when you are most productive. It’s when you don’t have to mindshift between various tasks. It’s when you aren’t interrupted to answer a question or look up something or send an email or answer an im. The alone zone is where real progress is made.

Getting in the zone takes time. And that’s why interruption is your enemy. It’s like rem sleep — you don’t just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens.

Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.

A successful alone time period means letting go of communication addiction. During alone time, give up instant messenging, phone calls, and meetings. Avoid any email thread that’s going to require an immediate response. Just shut up and get to work.

---

Meetings Are Toxic

Don’t have meetings

Do you really need a meeting? Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire. The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead.

There’s nothing more toxic to productivity than a meeting. Here’s a few reasons why:

• They break your work day into small, incoherent pieces that disrupt your natural workflow
• They’re usually about words and abstract concepts, not real things (like a piece of code or some interface design)
• They usually convey an abysmally small amount of information per minute
• They often contain at least one moron that inevitably gets his turn to waste everyone’s time with nonsense
• They drift off-subject easier than a Chicago cab in heavy snow
• They frequently have agendas so vague nobody is really sure what they are about
• They require thorough preparation that people rarely do anyway

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

• Set a 30 minute timer. When it rings, meeting’s over. Period.
• Invite as few people as possible.
• Never have a meeting without a clear agenda.

---

Seek and Celebrate Small Victories

Release something today

The most important thing in software development is motivation. Motivation is local — if you aren’t motivated by what you are working on right now, then chances are it won’t be as good as it should be. In fact, it’s probably going to suck.

Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.

So, if you’re in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself “What can we do and release in 4 hours?” And then do it. It could be…

• A new simple feature
• A small enhancement to an existing feature
• Rewriting some help text to reduce the support burden
• Removing some form fields that you really don’t need

When you find those 4-hour quick wins, you’ll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.

---

Staffing chapter 8

Hire Less and Hire Later

Add slow to go fast

There’s no need to get big early — or later. Even if you have access to 100 of the very best people, it’s still a bad idea to try and hire them all at once. There’s no way that you can immediately assimilate that many people into a coherent culture. You’ll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

So don’t hire. Really. Don’t hire people. Look for another way. Is the work that’s burdening you really necessary? What if you just don’t do it? Can you solve the problem with a slice of software or a change of practice instead?

Whenever Jack Welch, former ceo of ge, used to fire someone, he didn’t immediately hire a replacement. He wanted to see how long ge could get along without that person and that position. We’re certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don’t need as many people as you think.

If there’s no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.

---

Kick the Tires

Work with prospective employees on a test-basis first

It’s one thing to look at a portfolio, resume, code example, or previous work. It’s another thing to actually work with someone. Whenever possible, take potential new team members out for a “test drive.”

Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You’ll learn pretty quickly whether or not the right vibe is there.

Scheduling can be tough for this sort of thing but even if it’s for just 20 or 40 hours, it’s better than nothing. If it’s a good or bad fit, it will be obvious. And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.

---

Actions, Not Words

Judge potential tech hires on open source contributions

The typical method of hiring for technical positions — based on degrees, resumés, etc. — is silly in a lot of ways. Does it really matter where someone’s degree is from or their gpa? Can you really trust a resumé or a reference?

Open source is a gift to those who need to hire technical people. With open source, you can track someone’s work and contributions — good and bad — over a lengthy period of time.

That means you can judge people by their actions instead of just their words. You can make a decision based on the things that really matter:

• Quality of work
  
  Many programmers can talk the talk but trip when it comes time to walk the walk. With open source, you get the nitty
  gritty specifics of a person’s programming skills and practices.


• Cultural perspective
  
  Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you’ve got a cultural match. If there’s no fit here, each decision will be a struggle.


• Level of passion
  By definition, involvement in open source requires at least some passion. Otherwise why would this person spend free time sitting in front of a screen? The amount of open source involvement often shows how much a candidate truly cares about programming.


• Completion percentage
  All the smarts, proper cultural leanings, and passion don’t amount to valuable software if a person can’t get stuff done. Unfortunately, lots of programmers can’t. So look for that zeal to ship. Hire someone who needs to get it out the door and is willing to make the pragmatic trade-offs this may require.


• Social match
  Working with someone over a long period of time, during both stress/relaxation and highs/lows, will show you their real personality. If someone’s lacking in manners or social skills, filter them out.

When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible. We hired Jamis because we followed his releases and participation in the Ruby community. He excelled in all the areas mentioned above. It wasn’t necessary to rely on secondary factors since we could judge him based on what really matters: the quality of his work.

And don’t worry that extra-curricular activities will take focus and passion away from a staffer’s day job. It’s like the old cliché says: If you want something done, ask the busiest person you know. Jamis and David are two of the heaviest contributors to Rails and still manage to drive 37signals technically. People who love to program and get things done are exactly the kind of people you want on your team.