37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real Italian Translation

Getting Real Italiano



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.

Come scrivere software vigoroso


La scrittura vigorosa è concisa. Una frase non dovrebbe contenere parole inutili ed un paragrafo nessuna frase inutile, per la stessa ragione per cui un disegno non dovrebbe avere linee superflue e una macchina parti inutili. Questo non significa che uno scrittore debba fare tutte le frasi concise o evitare i dettagli e trattare solo sommariamente i soggetti, ma significa che ogni parola deve dirci realmente qualcosa.

—Da “The Elements of Style” di William Strunk Jr.




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”

Consegnare Start.com di Microsoft


Le analisi dei processi e i meeting sono la norma nelle grandi aziende. Vengono impiegati molti mesi nel pianificare funzionalità e nel delineare dettagli con lo scopo comune di raggiungere un accordo su quale sia la cosa “migliore” per il cliente.

Questo potrebbe essere il giusto approccio per il software pacchettizzato, ma con il web abbiamo un vantaggio incredibile. Basta consegnarlo! Lasciare che l’utente ti dica se è la cosa giusta e se non lo è puoi sempre modificarlo e rimetterlo sul web il giorno stesso! Non c’è parere più importante di quello del cliente — resisti alla tentazione di intraprendere meeting e discussioni interminabili. Consegna il prodotto e dimostrane la validità.

Più facile a dirsi che a farsi — questo implica che:

Non sono necessari mesi di pianificazione.
Non sono necessari mesi passati scrivendo specifiche — le specifiche dovrebbero avere solide basi, mentre i dettagli dovrebbero essere ricavati e affinati durante la fase di sviluppo. Non cercare di risolvere tutti i problemi incontrati e di delineare ogni singolo particolare prima che lo sviluppo abbia inizio.

Consegna meno funzionalità, ma tutte di qualità.
Non hai bisogno di fare il debutto con un prodotto equipaggiato di infinite funzionalità. Dai ai tuoi utenti piccoli pezzi alla volta che può digerire facilmente.

Se ci sono piccoli errori, pubblicalo non appena hai perfezionato il cuore e successivamente fornisci le correzioni di ogni singolo bug trovato. Più velocemente ricevi il feedback dell’utente meglio è. Le idee possono sembrare stupende su carta, ma nella pratica potrebbero non essere tali. Prima riesci a scovare gli aspetti errati di un’idea, meglio è.

Dopo essere riuscito a interagire velocemente con le risposte del tuo cliente, stabilirai una connessione diretta con esso. Ricordati che l’obiettivo finale è quello di conquistare il cliente fornendogli quello che vuole.

—Sanaz Ahari, Program Manager di Start.com, Microsoft



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.

Risolvendo i tuoi stessi grattacapi

Il mondo Open Source abbraccia questo concetto da molto tempo — lo chiamano “scratching your own itch.” Questo per gli sviluppatori open source significa ottenere gli strumenti che vogliono, realizzati nel modo che vogliono. Ma il beneficio è ancora più profondo.

Come designer o sviluppatore di una nuova applicazione, ogni giorno ti rapporti con centinaia di micro decisioni: blu o verde? Una tabella o due? Statico o dinamico? Interrompere o recuperare? Come prendiamo queste decisioni? Se è qualcosa di importante lo possiamo chiedere. Il resto lo supponiamo. E tutte queste supposizioni creano lacune nelle nostre applicazioni — una rete interconnessa di assunzioni.

Io, come sviluppatore, detesto tutto ciò. La conoscenza di tutte queste piccole bombe a orologeria presenti nelle mie applicazioni contribuiscono ad aumentare il mio stress. Gli sviluppatori open source non soffrono di questo, dato che risolvono insieme i propri problemi. Perché sono loro stessi gli utilizzatori e sanno al 90% la risposta corretta alle decisioni che devono prendere. Penso che questa sia una delle ragioni per cui molti di loro quando tornano a casa dopo un duro giorno di lavoro si rilassano portando avanti un progetto open source.

—Dave Thomas, The Pragmatic Programmers

Nato per necessità


Campaign Monitor è nato davvero per necessità. Siamo stati frustrati per anni dalla qualità dei servizi disponibili per fare email marketing. Uno strumento aveva le funzionalità x e y, ma mai la z, un altro aveva y e z, ma non x. Non potevamo vincere.

Così decidemmo di abbandonare tutto e iniziare a realizzare un nostro strumento da sogno per l’email marketing. Decidemmo consciamente di non osservare quello che stavano facendo gli altri, ma di concentrarsi nella realizzazione di un software che rendesse la vita più facile a noi e ai nostri clienti.

Appena uscì ci rendemmo conto che non eravamo i soli a essere scontenti degli strumenti disponibili. Facemmo alcune modifiche al software in modo che qualsiasi web agency potesse usarlo e cominciammo a diffonderlo nel mondo. In meno di sei mesi migliaia di designer stavano usando Campaign Monitor per inviare newsletter per se stessi e per i propri clienti.

—David Greiner, fondatore di Campaign Monitor

Te ne devi prendere cura


Quando scrivi un libro, devi avere qualcosa in più di una storia interessante. Devi avere il desiderio di narrare la storia. Devi essere in qualche modo personalmente coinvolto. Se conviverai con qualcosa per due, tre anni o per il resto della tua vita, te ne dovrai prendere cura.

—Malcolm Gladwell, autore (da A Few Thin Slices of Malcolm Gladwell)



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.

Due percorsi

[Jake Walker ha fondato un’azienda con finanziamenti esterni (Disclive) e una senza (The Show). Vediamo le differenze tra i due percorsi.]

La fonte di tutti i problemi non fu il trovare i soldi in sé, ma tutto ciò che ne conseguì. Le aspettative erano semplicemente troppe. Le persone iniziavano a prendere uno stipendio, la motivazione divenne realizzarlo e venderlo o trovare vie alternative per rendere i soldi agli investitori. Nel caso della prima azienda abbiamo semplicemente iniziato più in grande di quello che eravamo — senza necessità...

[Con The Show] abbiamo capito che potevamo realizzare un prodotto migliore con meno spese impiegando solamente più tempo. Abbiamo scommesso un po’ dei nostri soldi sul fatto che le persone avrebbero preferito un prodotto di qualità piuttosto che uno finito velocemente. Ma l’azienda è rimasta (e ancora continua a esserlo) una piccola cosa. E fin da questo primo progetto ci siamo sempre autofinanziati. Con un po’ più di creatività non avremmo mai avuto la necessità di investire soldi nostri. L’aspettativa non è di crescere e vendere, ma di crescere con l’obiettivo di ingrandire e continuare a beneficiarne dal punto di vista economico.

—Un commento da Signal vs. Noise



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).

Uno, due, tre…

Come è possibile che il lancio di un progetto sia un anno in ritardo? Un giorno alla volta.

—Fred Brooks, ingegnere informatico



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 seguire il leader

Gli esperti di marketing (e gli esseri umani in generale) sono portati a seguire un leader. L’istinto naturale è quello di capire ciò che funziona per gli avversari e cercare di fare meglio — cercando di essere più economico se la competizione è sul prezzo, o più veloce se invece è sulla velocità. Il problema di questo approccio è che una volta che un utente ha comprato il prodotto di un avversario, persuaderlo a cambiare è come cercare di convincerlo che ha sbagliato. Ma le persone odiano ammettere di aver sbagliato.

Per evitare questo devi raccontargli una storia diversa, cercando di convincere coloro che ascoltano che la tua storia è più importante di quella a cui credono in quel momento. Se il tuo avversario è più veloce tu devi essere più economico. Se loro puntano sulla storia della salute, tu devi vendere la storia della convenienza. Non devi assumere la posizione dicendo che “noi siamo più economici”, ma devi raccontare una storia vera completamente differente da quella che hanno sentito precedentemente.

Seth Godin, autore/imprenditore (da Be a Better Liar)

Qual è la chiave del problema?

Uno dei modi più veloci per mettersi nei guai è quello di guardare quello che stanno facendo i tuoi avversari. Questo è vero specialmente per noi di BlinkList. Da quando abbiamo lanciato il servizio ne sono stati creati altri 10 di social bookmarking. Alcune persone hanno iniziato a generare fogli di calcolo che comparavano le caratteristiche tra i vari servizi.

Questo porta velocemente fuori strada. Dobbiamo concentrarsi sul concetto generale chiedendosi quale sia la chiave del problema che stiamo cercando di risolvere e come fare a risolverlo.

—Michael Reining, co-fondatore, MindValley e Blinklist



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.

La presenza della passione

Nel design, dove spesso il significato è soggettivo o difficile da interpretare, alcune cose sono più evidenti e chiare della presenza della passione. Questo è vero sia se il design di un prodotto ti colpisce sia se ti lascia indifferente; in entrambi i casi non è difficile trovare l’investimento emotivo delle mani che l’hanno creato.

L’entusiasmo si manifesta chiaramente da subito, ma anche l’indifferenza è ugualmente identificabile. Se il lavoro che stai facendo non ha una passione genuina, sarà una mancanza quasi impossibile da nascondere, indipendentemente da quanto il design sia elaborato o attraente.

—Khoi Vinh, Subtraction.com

Il fornaio

L’attuale business americano è quello di sviluppare un’idea, renderla remunerativa, venderla mentre rende ancora e poi abbandonare l’attività o iniziare a diversificarsi su più fronti. Questo è come gettare via tutto. La mia idea è: divertiti a fare il fornaio, vendi il tuo pane, le persone lo amano, allora vendine di più. Continua a fare il fornaio perché stai facendo del buon cibo e rendi le persone felici.

—Ian MacKaye, membro di Fugazi and co-proprietario di Dischord Records
(from Salon.com People | Ian MacKaye)



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”.

Emergere


Emergere è uno dei principi fondamentali dell’agilità ed è quello più vicino alla magia. Le proprietà che determinano l’emergere non sono precise o integrate, accadono semplicemente come un risultato dinamico rispetto a tutto il resto del sistema. “Emergere” deriva dal latino della metà del 17° secolo con il senso di “evento inaspettato.” Non lo puoi pianificare o programmare, ma puoi coltivare un ambiente che ne favorisca l’arrivo e da cui ne puoi beneficiare.

Un classico esempio di emergere si può trovare nella dinamica di uno stormo di uccelli. Una simulazione al computer può usare solamente tre semplici regole (secondo il principio “non si intersecano mai l’uno con l’altro”) e improvvisamente ottieni una dinamica molto complessa come il volo lento e gentile di uno stormo nel cielo, che si riforma dopo aver incontrato ostacoli e così via. Nessuna di queste dinamiche complesse (come ritrovare la stessa forma dopo aver incontrato un ostacolo) è descritta da regole; questa emerge dalle dinamiche del sistema.

Regole semplici, come la simulazione degli uccelli, portano a una dinamica complessa. Regole complesse, come le leggi sulle tasse di molti paesi, portano a dinamiche stupide.

Molte tecniche di sviluppo software hanno lo sfortunato effetto collaterale di eliminare la possibilità che si verifichi una dinamica che porta a emergere. La maggior parte dei tentativi di ottimizzazione — restringendo tutto molto esplicitamente — riducono l’ampiezza e l’obiettivo di interazioni e relazioni, le quali sono la vera sorgente che porta a emergere. Nell’esempio dello stormo in volo, come in un sistema ben disegnato, sono le interazioni e le relazioni che creano una dinamica interessante.

Più restringiamo, meno posto lasciamo a una soluzione creativa e che emerge. Otteniamo sempre lo stesso risultato, limitando i requisiti prima che siano capiti fino in fondo, ottimizzando troppo presto il codice, inventando una navigazione complessa o scenari di workflow, prima di aver fatto provare il sistema agli utenti: un sistema eccessivamente complicato e stupido invece di un sistema pulito ed elegante che porta a emergere.

Tienilo piccolo. Tienilo semplice. Lascia che accada.

—Andrew Hunt, Pragmatic Programmers



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.

La legge di Metcalfe e i team di progetto


Mantieni il team più piccolo possibile. La legge di Metcalfe dice che “il valore di un sistema di comunicazione cresce approssimativamente come il quadrato del numero degli utenti del sistema.” Questa legge ha un corollario quando si parla di team di progetto: l’efficienza di un team è approssimativamente l’inverso del quadrato del numero di componenti del team. Sto iniziando a pensare che tre persone sia il numero ottimale per la release 1.0… Inizia riducendo il numero di persone che pianifichi di aggiungere al team; fatto questo riduci ancora un po’.

—Marc Hedlund, imprenditore a O’Reilly Media

Il flusso della comunicazione

I canali di comunicazione sono più facili in piccoli team piuttosto che in quelli grandi. Se sei la sola persona che porta avanti il progetto, la comunicazione è semplice. L’unico canale di comunicazione è tra te e il cliente. Via via che il numero di persone aumenta lo stesso è per il numero dei canali di comunicazione che si vengono a creare. L’aumento non è lineare al numero di persone che si aggiungono, ma aumenta proporzionalmente al quadrato del numero di persone.

—Steve McConnell, Capo Ingegnere del Software a Construx Software Builders Inc.
(da Less is More: Jumpstarting Productivity with Small Teams)



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.

Combatti i funghi


Ciò che è stato descritto come “subdola eleganza” è probabilmente descritto in modo migliore come “caratteristica malata”, così come un fungo in una pianta che gradualmente elabora e confonde i veri contorni di un prodotto mentre assorbe la sua linfa. L’antidoto alla funzionalità malata è certamente dato dalla “limitazione temporale”. Questo porta a scartare le caratteristiche proporzionalmente al tempo che sarebbe necessario a realizzarle. E’ spesso il caso in cui le funzionalità più utili sono quelle più lunghe da implementare. Pertanto la combinazione del fungo e del vincolo temporale produce un software che conosciamo e amiamo, fatto di caratteristiche essenziali.

—Jef Raskin, autore (tratto da “Why Software Is the Way It Is”)



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.

Sii orgoglioso, totalmente sincero


Nonostante tu possa pensare che un cliente sia particolarmente attratto dall’esagerazione sul numero di persone che compongono la tua azienda o dall’ampiezza delle tue offerte, i più intelligenti, o quello che davvero vuoi, scopriranno la verità — o per intuizione o per deduzione. Con molto imbarazzo in passato ho preso parte a bugie innocenti e nessuna di quelle situazioni ha mai portato dei risultati che contano ai fini di un lavoro: relazioni sincere, durature e favorevoli con persone che hanno un bisogno vero dei servizi offerti. Il miglior modo è quello di essere orgogliosi e profondamente sinceri sull’esatta grandezza dell’azienda.

—Khoi Vinh, Subtraction.com

In qualsiasi momento


Un buon servizio clienti è la richiesta più grande che qualsiasi cliente ti farà, indipendentemente dal business che stai facendo. Noi stessi lo richiediamo per i servizi che utilizziamo, quindi perché dovremmo pensare che i nostri clienti ragionino in modo diverso? Fin dall’inizio abbiamo reso ai nostri clienti facile e trasparente la possibilità di contattarci per qualsiasi domanda avessero. Sul nostro sito abbiamo messo un numero gratuito che inoltra la chiamata ai nostri cellulari e su ognuno dei nostri biglietti da visita è presente il proprio numero di cellulare. Abbiamo fatto notare ai nostri clienti che ci possono contattare in qualsiasi momento indipendentemente dal problema che hanno. I nostri clienti apprezzano questo livello di fiducia e nessuno ha mai abusato di questo servizio.

—Edward Knittel, Responsabile Vendite e Marketing, KennelSource



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.

La filosofia della lavagna


Una volta Andy Hunt e io scrivemmo uno switch per transazioni di carte di debito. Il requisito principale era che l’utilizzatore della carta non pagasse mai due volte per la stessa transazione. In altre parole questo significava che a prescindere dal tipo di fallimento che potesse succedere, l’errore avrebbe dovuto portare all’interruzione della transazione piuttosto che a eseguirla due volte.

Così scrivemmo a grandi lettere sulla nostra lavagna comune: Errore in favore degli utilizzatori.

Questo si è unito a circa altra mezza dozzina di frasi. Insieme ci hanno guidato in tutte quelle piccole decisioni che prendi nella costruzione di un qualcosa di complesso. Ci hanno inoltre portato a ottenere un’applicazione con una forte coerenza interna e una grande consistenza esterna.

—Dave Thomas, The Pragmatic Programmers

Crea un Mantra


Le organizzazioni necessitano di principi guida. Hanno bisogno di un piano con i punti principali; ogni giorno quando gli impiegati svegliano hanno bisogno di sapere perché stanno andando a lavoro. Queste motivazioni dovrebbero essere corte e piacevoli e si dovrebbero riassumere così: Perché esisti? Cosa ti motiva? Io lo chiamo mantra — una descrizione di tre o quattro parole sul perché esisti.

Guy Kawasaki, autore (da Make Mantra)



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.

Il diavolo si cela nei dettagli


Mi è capitato di avere il comportamento di “preoccuparmi immediatamente dei dettagli” dopo aver disegnato qualche classe… Se cominci a disegnare i dettagli immediatamente puoi essere sicuro che questo disegno farà schifo. La verità è che stai completamente sbagliando approccio.

Dovresti iniziare cercando di capire le giuste proporzioni dell’intero progetto. In seguito devi disegnare prima gli oggetti più grandi, passando via via a quelli più piccoli. In questo punto della progettazione il disegno deve essere a grandi linee. Dopo puoi procedere con le sfumature, portando piano piano volume al progetto. Prima inizi con solo tre tonalità (chiaro, medio e scuro). Questo ti darà uno schizzo a toni. Poi per ogni porzione del disegno riconsideri tre ulteriori tonalità e le applichi alla porzione in esame. Fallo fino a che non ci sarà volume (richiede molteplici iterazioni)...

Procedi dal grande al piccolo. Sempre.

—Patrick Lafleur, Creation Objet Inc. (da Signal vs. Noise)



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.

La scelta migliore che abbiamo mai fatto


La decisione di direzionare Campaign Monitor esclusivamente al mercato dei web designer è stata la scelta migliore che potessimo fare. Ci ha permesso di identificare facilmente quali caratteristiche sarebbero state davvero utili, ma soprattutto quali tralasciare. Non solo abbiamo attratto più clienti concentrandoci su un gruppo più piccolo di persone, ma poiché tutti loro hanno bisogni simili abbiamo reso il nostro lavoro molto più facile. In Campaign Monitor ci sono moltissime funzionalità che sarebbero inutili per qualsiasi persona eccetto che per un web designer.

Inoltre concentrandosi sul cuore del mercato ci ha consentito di diffondere più facilmente il nostro software nel mondo. Ora che abbiamo un audience ristretto e ben definito, possiamo fare pubblicità dove i clienti vanno frequentemente online, pubblicare articoli che potrebbero trovare interessanti e in generale costruire una comunità intorno al prodotto stesso.

—David Greiner, fondatore, Campaign Monitor



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.

Avrai in ogni caso da ottimizzare


Il fatto è che ognuno ha problemi di scalabilità, nessuno può offrire un servizio che funzioni da zero ad alcuni milioni di utilizzatori senza rivedere quasi ogni aspetto del design e dell’architettura.

—Dare Obasanjo, Microsoft (da Scaling Up and Startups)



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.”

“Non vogliamo migliaia di funzionalità”


Steve Jobs fece una breve presentazione privata sull’iTunes Music Store ad alcune persone responsabili di etichette discografiche indipendenti. Il momento del giorno che preferisco è stato quando le persone hanno alzato le mani dicendo: “Fa [x]?”, “Pianificate di aggiungere [y]?”. Alla fine Jobs disse: “Aspettate aspettate — abbassate le vostre mani. Ascoltate: Lo so che avete migliaia di idee per tutte le caratteristiche cool che iTunes potrebbe avere. Lo stesso le abbiamo noi. Ma non vogliamo migliaia di funzionalità. Questo sarebbe orribile. Innovazione non significa dire di sì a tutto. Significa dire di NO a tutto eccetto che alle funzionalità cruciali.”

—-Derek Sivers, presidente e programmatore, CD Baby e HostBaby
(da Say NO by default)



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.


L’innovazione nasce dal dire No


[L’innovazione] nasce dicendo no a 1,000 cose in modo da essere sicuri di non prendere il percorso sbagliato o di cercare di fare troppo. Stiamo pensando sempre a nuovi mercati in cui poter entrare, ma è solo dicendo no che ti puoi concentrare sulle cose che sono davvero importanti.


—Steve Jobs, CEO, Apple (da The Seed of Apple’s Innovation)



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à.

La cosa concreta porta all’armonia


Quando un gruppo di persone cerca di capire ciò che è armonioso…le loro opinioni tendono a convergere se ragionano su un modello concreto. Non saranno certamente in accordo se fanno diagrammi ed elaborano idee. Ma se iniziano a realizzare una cosa concreta tenderanno a raggiungere l’armonia.

—Christopher Alexander, Professore di Architettura
(da Contrasting Concepts of Harmony in Architecture)

Cerca di farlo funzionare prima possibile


Non credo di aver mai preso parte a un progetto software — grande o piccolo — che ha avuto successo in termini di programmazione, costo e funzionalità, che è partito con un lungo periodo di pianificazione e discussione, senza uno sviluppo concorrente. E’ semplicemente troppo facile, e a volte divertente, perdere tempo prezioso inventando caratteristiche che si riveleranno superflue o non implementabili.

Questo è applicabile a tutti i livelli di sviluppo e “ottenere qualcosa di concreto e funzionante” è un must. Non è applicabile solamente al progetto nella sua totalità, ma è allo stesso tempo da applicare a ogni piccolo componente di cui l’applicazione è composta.

Quando è disponibile un’implementazione funzionante di un componente chiave, gli sviluppatori vogliono capire se funzionerà o meno con l’applicazione e in genere cercano di provarla prima possibile. Anche se in un primo momento l’implementazione non è perfetta o completa, questa collaborazione iniziale porta di solito a interfacce ben definite e a funzionalità che fanno esattamente quello di cui c’è bisogno.

—Matt Hamer, sviluppatore e product manager, Kinja



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.

Forse sei più intelligente di me


Forse sei molto più intelligente di me

E’ molto probabile. Questo è molto promettente. Comunque se sei come la maggior parte delle persone, quindi come me, avrai sicuramente dei problemi nell’immaginare qualcosa che non puoi sentire e toccare.

Gli esseri umani sono molto bravi nel reagire a cose presenti nell’ambiente. Sappiamo come allarmarci quando una tigre entra nella stanza o come pulire dopo una devastante inondazione. Sfortunatamente siamo estremamente incapaci nel pianificare in anticipo le nostre azioni e porre priorità alle cose che davvero contano.

Forse sei uno dei pochi individui che riesce a tenere tutto nella propria testa. Questo nella pratica conta poco.

Web 2.0, il modo in cui presupponiamo che sia utilizzata la rete, consente agli sviluppatori intelligenti di mettere qualche debolezza umana a lavorare per loro. Come? Consentendo agli utenti di dirti cosa pensano quando c’è ancora tempo per fare qualcosa su di esso.

E questa ultima frase ti dovrebbe spiegare perché dovresti sviluppare in questo modo e come potresti voler promuovere/lanciare il software.

Crea una storia diretta. Cerca di essere sicuro che i pezzi funzionino. Poi lancia e rivedi. Nessuno è più intelligente di tutti noi messi insieme.

Seth Godin, autore/imprenditore



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.

Le preferenze hanno un costo


E’ provato che le preferenze abbiano un costo. Certamente alcune portano dei benefici importanti — e possono anche essere caratteristiche cruciali nell’interfaccia. Ma ognuna ha un prezzo e devi considerare attentamente il suo valore. Questo non è capito da molti utenti e sviluppatori e finiscono per avere molti costi e preferenze che valgono pochi dollari…Mi sono reso conto che se una persona si impegna molto per ottenere dei buoni valori di default piuttosto che aggiungere delle pigre preferenze, si muove naturalmente verso la giusta direzione.

—Havoc Pennington, leader tecnico, Red Hat (da Free software and good user interfaces)



“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.

Devi essere un esecutore


E’ così divertente quando sento le persone proteggere le proprie idee. (Persone che mi vogliono far firmare un NDA per dirmi la più semplice delle idee.)

Per me le idee non valgono niente fino a che non sono messe in pratica. Sono solamente un moltiplicatore. L’esecuzione vale milioni.

Spiegazione:


  • Idea terribile = -1
  • Idea debole= 1
  • Idea così-così = 5
  • Idea buona = 10
  • Idea grande = 15
  • Idea brillante = 20
  • Nessuna esecuzione = $1
  • Esecuzione debole = $1000
  • Esecuzione così-così= $10,000
  • Esecuzione buona = $100,000
  • Esecuzione grande = $1,000,000
  • Esecuzione brillante = $10,000,000


Per fare un business hai bisogno di moltiplicarne due tra loro.

La miglior idea senza esecuzione vale $20. L’idea più brillante con una grande esecuzione vale $20,000,000.

Ecco perché non voglio ascoltare le idee delle persone. Non sono interessato fino a quando non vedo la loro esecuzione.

—Derek Sivers, presidente e programmatore, CD Baby e HostBaby



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.

Il Libro Beta


Se gli sviluppatori sono nervosi nel rilasciare codice, allora gli editori e gli autori sono terrificati nel far uscire i libri. Una volta che un libro è stato messo su carta, è visto come una cosa complicatissima da cambiare. (In realtà non è così, ma la percezione e i ricordi di problemi legati a vecchie tecnologie sono ancora presenti nell’industria della stampa.) Così gli editori affrontano molti problemi (e spendono molto) nel cercare di fare un libro “giusto” prima di farlo uscire.

Quando ho scritto il libro Agile Web Development With Rails, ci sono state molte richieste da parte degli sviluppatori: dacci il libro adesso — vogliamo imparare il Rails. Ma ero entrato nella mentalità dell’editore. “Non è ancora pronto,” dicevo. Ma la pressione della comunità e qualche incoraggiamento da parte di David Heinemeier Hansson hanno cambiato la mia mentalità. Abbiamo rilasciato il libro in formato pdf circa due mesi prima che fosse completo. I risultati sono stati spettacolari. Non solo abbiamo venduto moltissimi libri, ma abbiamo ottenuto dei feedback — tantissimi feedback. Ho configurato un sistema automatizzato per recuperare i commenti dei lettori e alla fine ho ottenuto quasi 850 feedback tra errori di scrittura, tecnici e suggerimenti di nuovi contenuti. Quasi tutti inseriti all’interno della versione finale del libro.

E’ stata una vittoria: Ho potuto far uscire un libro cartaceo migliore e la comunità ha avuto accesso a qualcosa che voleva anticipatamente. E in più se sei in competizione con qualcuno, rendere disponibile prima il libro consente alle persone di aiutare te piuttosto che la concorrenza.

—Dave Thomas, The Pragmatic Programmers

Fallo velocemente


  • 1. Decidi se ne vale la pena; se sì:
  • 2. Fallo velocemente — non importa che sia perfetto. Basta che tu lo faccia.
  • 3. Salvalo. Caricalo su. Pubblicalo.
  • 4. Guarda cosa ne pensano le persone.
    • Sebbene sia sempre riluttante ad aggiungere nuove funzionalità alle cose, il momento in cui dico “sì!” ne vale la pena, è di solito alcune ore dopo che ho lanciato il sito, con qualche imperfezione, ma lanciato; lascia che siano i feedback ad aiutarti nelle rifiniture future.

      —Derek Sivers, presidente e programmatore, CD Baby e HostBaby



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.

Compiti più piccoli e timeline più corte


Gli sviluppatori software sono una razza ottimista: quando si trovano davanti a un problema di programmazione pensano: “Questo sarà facile! Non mi dovrebbe prendere tempo.”

Infatti se dai a una programmatrice tre settimane per completare un grosso compito, lei lo posporrà per due settimane e mezzo e poi programmerà per una. Il risultato sarà probabilmente diverso dai requisiti iniziali poiché il problema si sarà rivelato più complesso di quello che sembrava. In più chi può ricordarsi quello che il team aveva concordato tre settimane fa?

Dai a una programmatrice un pomeriggio di tempo per implementare un modulo piccolo e specifico e lei lo realizzerà prontamente e sarà immediatamente disponibile per andare avanti con uno nuovo.

Compiti e timeline più piccoli sono più maneggevoli, riducono le possibilità di fraintendimento sulle richieste e in più costa molto meno cambiare modo di pensare sul progetto o a rifarne una parte. Timeline più brevi occupano gli sviluppatori e danno loro più opportunità di sentire un senso di successo e meno ragione di pensare, “Oh, ho moltissimo tempo per farlo. Per adesso finisco di votare le canzoni che ho nella mia libreria di iTunes.”

—Gina Trapani, sviluppatore web ed editore di Lifehacker, la guida alla produttività e al software

Fattori veri


La prossima volta che qualcuno ti fa definire la risposta esatta a una domanda che non puoi sapere — sia per una data precisa sulla fine del progetto, o per il costo finale o per quanto volume di latte starebbe all’interno del Grand Canyon — inizia a prendere aria fuori dalla finestra e rispondi con: “Non lo so.”

Non danneggia assolutamente la tua credibilità, ma dimostra l’attenzione che poni nel prendere le decisioni. Non stai dicendo delle parole solamente perché suonano intelligenti. Inoltre mette la domanda su una conversazione collaborativa. Imparando come devono essere esatte le tue stime (e perché), potete lavorare insieme per sviluppare una visione condivisa su veri fattori al di là dei numeri.

—Merlin Mann, creatore ed editore di 43folders.com

Risolvi il problema che ti si legge in faccia


La cosa che ho preferito in assoluto successa nel web è stata il rilascio e l’adozione dell’attributo “nofollow”. Nessuno ne aveva mai parlato precedentemente. Non c’erano state né conferenze né comitati dove un gruppo di geek avrebbe potuto discutere sulla sua natura semantica o grammaticale. Nessun documento rfc che potesse mutare una semplice idea in uno snippet di 20 linee di xml e ho dovuto studiare approfonditamente solamente per intuire come usarlo per poi capire che non lo potevo usare perché non ero sicuro se lo stavo formattando per la versione .3 o la 3.3b.

E’ semplice, è vincente, fornisce un’opzione per le persone che cercano un’opzione — e questa è di gran lunga la cosa più importante quando si tratta una popolazione come quella del web che non si preoccupa di identificarsi o di portare rispetto.

A volte risolvere gli altri venti problemi non è così utile o saggio come risolvere quello che ti tormenta e ti si legge in faccia. Non è stata solamente una piccola vittoria sullo spam (tutte le vittorie contro lo spam sono piccole), ma una vittoria per tutti gli sviluppatori web come noi a cui divertono risultati semplici e rapidi come questi.

—Andre Torrez, programmatore e Vice presidente del reparto ingegneristico a Federated Media Publishing



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.

Get Into the Groove


We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration…trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — especially interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble.

—Joel Spolsky, software developer, Fog Creek Software
(from Where do These People Get Their (Unoriginal) Ideas?)



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.

Have fewer meetings


There are too many meetings. Push back on meetings that do not make sense or are unproductive. Only book a meeting when you have an important business issue to discuss and you want or need input, approval, or agreement. Even then, resist the urge to invite everyone and their brother — don’t waste people’s time unnecessarily.

—Lisa Haneberg, author (from Don’t Let Meetings Rule!)

Break it Down


As projects grow, adding people has a diminishing return. One of the most interesting reasons is the increased number of communications channels. Two people can only talk to each other; there’s only a single comm path. Three workers have three communications paths; 4 have 6. In fact, the growth of links is exponential…Pretty soon memos and meetings eat up the entire work day.

The solution is clear: break teams into smaller, autonomous and independent units to reduce these communications links.

Similarly, cut programs into smaller units. Since a large part of the problem stems from dependencies (global variables, data passed between functions, shared hardware, etc.), find a way to partition the program to eliminate — or minimize — the dependencies between units.

The Ganssle Group (from Keep It Small)



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.

Brooks’ law

Adding people to a late software project makes it later.

—Fred Brooks

Programming and Mozart’s Requiem


A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time… The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.

—Joel Spolsky, software developer, Fog Creek Software (from Hitting the High Notes)



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.

Start small


Try a small test assignment to start. Don’t leap in with all of your work at once. Give your new [virtual assistant] a test project or two to work on and see how the chemistry develops. In the beginning, it’s too easy to gloss over potential problems with rose-colored glasses. Make it clear this is a test run.

—Suzanne Falter-Barns, author/creativity expert
(from How To Find And Keep The Perfect VA)



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.

Open Source Passion


What you want the most from a new hire is passion for what he does, and there’s no better way of showing it than a trace of commitment in open source projects.

—Jarkko Laine, software developer
(from Reduce the risk, hire from open source)



Get Well Rounded Individuals

Go for quick learning generalists over ingrained specialists

We’ll never hire someone who’s an information architect. It’s just too overly specific. With a small team like ours, it doesn’t make sense to hire people with such a narrowly defined skill-set.

Small teams need people who can wear different hats. You need designers who can write. You need programmers who understand design. Everyone should have an idea about how to architect information (whatever that may mean). Everyone needs to have an organized mind. Everyone needs to be able to communicate with customers.

And everyone needs to be willing and able to shift gears down the road. Keep in mind that small teams often need to change direction and do it quickly. You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.



You Can’t Fake Enthusiasm

Go for happy and average over frustrated and great

Enthusiasm. It’s one attribute you just can’t fake. When it comes time to hire, don’t think you need a guru or a tech-celebrity. Often, they’re just primadonnas anyway. A happy yet average employee is better than a disgruntled expert.

Find someone who’s enthusiastic. Someone you can trust to get things done when left alone. Someone who’s suffered at a bigger, slower company and longs for a new environment. Someone who’s excited to build what you’re building. Someone who hates the same things you hate. Someone who’s thrilled to climb aboard your train.

Extra points for asking questions


Observe whether a potential hire asks a lot of questions about your project. Passionate programmers want to understand a problem as well as possible and will quickly propose potential solutions and improvements, which leads to a lot of questions. Clarifying questions also reveal an understanding that your project could be implemented thousands of different ways and it’s essential to nail down as explicitly as possible exactly how you imagine your web app working. As you dig into the details, you’ll develop a sense of whether the person is a good cultural match.

—Eric Stephens, BuildV1.com



Wordsmiths

Hire good writers

If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn’t matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.

That’s because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly. And those are the qualities you need.

An Organized Mind


Good writing skills are an indicator of an organized mind which is capable of arranging information and argument in a systematic fashion and also helping (not making) other people understand things. It spills over into code, personal communications, instant messaging (for those long-distance collaborations), and even such esoteric concepts as professionalism and reliability.

—Dustin J. Mitchell, developer (from Signal vs. Noise)

Clear Writing Leads To Clear Thinking


Clear writing leads to clear thinking. You don’t know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what’s easy for you, do what’s easy for your reader.

—Michael A. Covington, Professor of Computer Science at The University of Georgia
(from How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)



Progettazione dell’interfaccia capitolo 9

L’importanza della progettazione

Progettare l’interfaccia prima di programmare

Molte applicazioni vengono create partendo subito con il codice del programma, ma questa non è una buona idea. Lo codifica, infatti, è la parte più complessa dell’applicazione e ciò vuol dire che è anche difficile e costosa da modificare. Parti quindi progettando l’interfaccia della tua applicazione.

Uno schizzo su un foglio di carta o un design html, infatti, sono più semplici ed economici da cambiare di un programma! Partire con la progettazione ti consente di essere più flessibile.

Un altro vantaggio è che potrai curare fin dall’inizio ciò che, per l’utente, sarà il tuo programma. Se aggiungerai l’interfaccia solo alla fine, commetterai un errore evidente.

Noi cominciamo con l’interfaccia per renderci subito conto di come sarà l’applicazione. Durante lo sviluppo il progetto verrà continuamente cambiato. Ha un senso così com’è? È facile da usare? Risolve effettivamente il problema? Queste domande possono avere una buona risposta solo quando avrete di fronte qualcosa da vedere. Partendo con l’interfaccia te le potrai porre da subito.

La penna arancione con cui cominciò Blinksale


Appena ho capito quanto fosse frustrante lavorare con il software gestionale acquistato, decisi di progettare come avrei voluto che lavorasse. Presi una penna arancione, la prima cosa che avessi a portata di mano, e fini il 75% del progetto in poche ore. L’ho mostrato a mia moglie, Rachel, chiedendogli cosa ne pensasse che gli chiesi “Cosa ne pensi?”. Lei mi rispose con un sorriso: “Devi realizzarlo. Davvero.”

Nelle due settimane successive ho perfezionato il progetto e creato delle semplici pagine html per la maggior parte della prima versione di quello che sarebbe diventato Blinksale. Non abbiamo fatto altri progetti dopo gli schizzi originali e anzi, convertirli in design html, ci ha aiutati a rimanere coinvolti ed eccitati, poiché ci siamo resi conto di come si stesse realizzando in pratica.

Quando le pagine html vennero completate, mettemmo a lavorare il nostro sviluppatore, Scott, su Blinksale. Avere la maggior parte dell’ interfaccia utente già pronta fu importantissimo per molti motivi. Innanzitutto fu per Scott uno stimolo e una guida per capire come sarebbe apparso il tutto. Non era solo un idea, era qualcosa di concreto. Inoltre ci ha aiutato a prevedere quanto avrebbe impiegato Scott a trasformare il design in un applicazione funzionante e quando devi finanziare un progetto, prima riesci a calcolare le risorse di cui necessita, meglio è. Il design divenne il nostro metodo di misurazione della portata del nostro progetto. Infine l’interfaccia utente ci ha ricordato durante tutto lo sviluppo lo scopo dell’applicazione. Ogni volta che volevamo aggiungere una funzione al nostro programma, dovevamo andare a controllare sul design se si poteva inserire : se non c’era posto, non potevamo aggiungerla.

—Josh Williams, foundatore di Blinksale



Epicenter Design

Pensare dal centro della pagina verso l’esterno

Un design “epicentrico” porta prima l’attenzione alla vera essenza della pagina, l’epicentro, e poi pensa a ciò che ci sta intorno. Questo vuol dire che all’inizio dovi ignorare le estremità della pagina : il menu, la testata, colori, barra laterale, logo, ecc. Pensa prima di tutto all’epicentro e progetta la parte più importante del contenuto.

In nessun caso la pagina può esistere senza il suo epicentro. Per esempio, se stai progettando di visualizzare il post di un blog, il post sarà l’epicentro. Non le categorie laterali, né la testata, nè i commenti, ma il post. Senza di questo, infatti, la pagina non avrà senso.

Quando questa parte sarà completa potrai cominciare a pensare al secondo elemento più importante, poi passerai al terzo e così via. Questo vuol dire epicenter design.

L’ epicenter design evita il tradizionale “fai il contenitore e poi infilaci il contenuto”. In questo processo viene disegnata la pagina, poi viene incluso il menu, i vari banner e infine il contenuto principale viene limitato allo spazio rimanente. È un processo che mette per primi i contenuti meno importanti e considera solamente alla fine quelli veramente importanti.

Un design “epicentrico” rovescia questo processo e ti permette di concentrarti su quello che conta realmente. Come risultato avrai un interfaccia più amichevole, facile da usare e centrata sulle funzioni importanti. Inoltre permetterà di cominciare subito in maniera positiva il dialogo tra programmatore e designer.



La soluzione in tre stati (Three State Solution)

Progettare per gli stati regolare, iniziale e d’errore

Per ogni pagina, devi considerare tre possibili stati:

  • Regolare

    Ciò che le persone vedono quando tutto funziona e vi sono dati.
  • Iniziale
    Cosa viene mostrato quando gli utenti entrano per la prima volta e devono inserire i dati.
  • Errore
    Quello che viene visualizzato quando si verifica qualche errore.

Il regolare è quello più “facile” e dove impiegherai più tempo, ma non dimenticarti di curare gli altri stati!



Lo stato di partenza

Soddisfa le aspettative con una buona prima esperienza

Ignorare la prima esperienza dell’utente,ossia quando non sono presenti i dati, è un errore enorme : l’utente riceverà un’impressione negativa e non vi concederà altre opportunità.

Il problema prende origine dal fatto che quando si progetta l’interfaccia utente sono presenti dei dati di prova. Anche i designer riempiono i template di dati. Ogni elenco, articolo, commento ha qualcosa dentro e questo significa che si vedrà tutto bene e funzionante.

Ma, ovviamente, lo stato di partenza dell’applicazione sarà senza dati. Quando qualcuno si iscrive, partirà con una pagina vuota. Rifacendoci all’esempio del blog, vi si dovranno inserire tutti i post – l’aspetto non prenderà forma fino a quando non sarà completato l’inserimento dei dati : post, appunto, oppure link, articoli, commenti e qualunque altra cosa.

Sfortunatamente, l’utente decide se un applicazione è buona in questa fase iniziale – quando ci sono meno informazioni, design e contenuti sui quali giudicare nel complesso l’utilità dell’applicazione. Se sbagliate a progettare un adeguato stato iniziale, le persone non sapranno cosa dovranno aspettarsi e avranno una cattiva impressione.

Molti designer e sviluppatori continuano a non considerare questa fase. Evitano di passare molto tempo sulla progettazione di questo stato perché quando sviluppano o usano l’applicazione, hanno all’interno dei dati già inseriti. Non incappano mai nello stato iniziale. Certo, possono connettersi come nuovo utente, ma la maggior parte del loro tempo lo passano sull’applicazione con inseriti i contenuti.

Cosa devi inserire nello stato iniziale perché sia utile ?

  • Approfittane per inserire una breve guida introduttiva e qualche consiglio.
  • Fornisci un esempio di pagina completa, con i dati inseriti, cosicché le persone sappiano cosa aspettarsi (e per cosa stanno lavorando).
  • Spiega come iniziare, cosa gli sarà richiesto, ecc.
  • Rispondi alle domande che gli utenti potrebbero porsi: A cosa serve questa pagina? Cosa devo fare adesso? Come succederà una volta completato di compilarla ?
  • Soddisfa le aspettative e cerca di ridurre la frustrazione, timidezza e soprattutto confusione.

La prima impressione è fondamentale. Se sbagli in questo, creerai un’impressione negativa (e falsa) nella tua applicazione o servizio.

Non avrai una seconda chance…

Un aspetto dell’interfaccia utente di MacOS X che io penso sia stato molto influenzato da [Steve] Jobs sono l’installazione e il wizard del primo avvio, poiché credo che lui sappia quanto è importante la prima impressione. Probabilmente, Jobs avrà pensato, ci sono solo un migliaio di persone alla prima esperienza, ma sono le più importanti perché non sanno ancora cosa aspettarsi e bisogna creare una buona impressione.

John Gruber, autore e sviluppatore web (da Interview with John Gruber)



Get Defensive

Progettare pensando che qualcosa non funzionerà

Ammettiamolo : C’è sempre qualcosa che va storto online. Non importa quanta attenzione metti nel progettare l’applicazione o quanto la testi, perché l’utente continuerà a scontrarsi con qualche errore. Quindi come potete gestire questi inevitabili contrattempi ? Con il defensive design.

Fare un defensive design è un come guidare. L’autista deve sempre controllare che non ci siano strade dissestate, autisti spericolati, o qualsiasi altro possibile pericolo, così chi fa il sito deve continuamente cercare punti deboli nell’applicazione, che potrebbero creare confusione e frustrazione negli utenti. Una buona progettazione in questo senso può fare la differenza nell’esperienza dell’utente.

Potremmo scrivere un’ libro con dentro tutto quello che concerne il defensive design. Infatti l’abbiamo fatto. Il titolo è “Defensive Design for the Web” ed è un ottima risorsa per tutti coloro che vogliono imparare come migliorare le schermate di errore e altri punti critici.

Ricordati : la tua applicazione può funzionare bene nel 90% delle occasioni. Ma se abbandoni l’utente nel momento del bisogno, questo non si dimenticherà facilmente della cosa.



Il Contesto prima della Coerenza

Quello che ha un senso qui potrebbe non avere senso li

Le azioni che un utente può compiere è meglio rappresentarle come pulsanti o link? Dipende dall’azione. Un calendario è meglio visualizzarlo come elenco di giorni o su griglia? Dipende da cosa si vuol far vedere e dalla lunghezza del periodo da considerare. Il menu di navigazione principale deve esserci in ogni pagina ? Serve ripetere il campo di ricerca in tutto il sito? Hai bisogno dello stesso piè di pagina ovunque? La risposta è sempre la stessa : “Dipende.”

Questo perché il contesto è più importante della coerenza, che può essere messa da parte in virtù di una migliore chiarezza nell’applicazione. Date agli utenti quello di cui hanno bisogno quando ne hanno bisogno ed eliminate ciò di cui non ha bisogno. E’ meglio procedere correttamente piuttosto che coerentemente.

Incoerenza Intelligente

La coerenza non è necessaria. Per anni si è sempre pensato che fosse uno dei punti cardine nella progettazione delle interfacce. Forse questo è vero nel software, ma sul Web non lo è. Quello che importa è invece se, su ogni singola pagina, l’utente possa facilmente e velocemente passare alla fase successiva del processo.

Alla Creative Good, noi la chiamiamo “intelligent inconsistency”: essere sicuri che su ogni pagina dia all’utente esattamente quello di cui ha bisogno in quella pagina. Aggiungere elementi in più, solo perché permetterebbero alla pagina di essere coerente col resto del sito, sarebbe ridicolo.

—Mark Hurst, fondatore della Creative Good e creatore di Goovite.com
(da The Page Paradigm)



Copywriting is Interface Design

Every letter matters

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you’re writing your interface, always put yourself in the shoes of the person who’s reading your interface. What do they need to know? How you can explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That’s copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

You need to speak the same language as your audience too. Just because you’re writing a web app doesn’t mean you can get away with technical jargon. Think about your customers and think about what those buttons and words mean to them. Don’t use acronyms or words that most people don’t understand. Don’t use internal lingo. Don’t sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Good writing is good design. It’s a rare exception where words don’t accompany design. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.



Interfaccia Unificata

Incorporare le funzioni di amministrazione nel sito

L’interfaccia di amministrazione, dove si gestiscono le preferenze, utenti e tante altre impostazione, tendono a essere brutte. Questo perché la maggior parte del tempo di sviluppo è impiegato sull’interfaccia per l’utenza generica.

Per evitare questo effetto, integra le funzioni di amministrazione (aggiunta,modifica,eliminazione) nell’applicazione.

Se devi mantenere due interfacce separate (per esempio una per gli utenti e una per gli amministratori), entrambe ne soffriranno. Sarai obbligato a ripeterti e questo vuol dire aumentare la probabilità di creare confusione. Meno schermate avrai di cui preoccuparvi, meglio le curerai.

Interfaccia Unificata

L’applicazione è tutto. Qualunque cosa può essere cambiata, aggiunta o adattata mediante l’area di gestione dell’applicazione. Questo ci consente di vedere esattamente cosa vedranno gli utenti per aiutarli su ogni problema o dubbio che possono avere. E i nostri utenti non devono temere di entrare in interfacce differenti per fare le diverse operazioni. Un istante stanno giostrandosi con gli appuntamenti e subito dopo possono aggiungere nuovi impiegati. Non si devono confondere con il saltare tra applicazioni differenti, ma avendo un’interfaccia coerente sono sempre in grado di adattarsi all’applicazione velocemente.


—Edward Knittel, Direttore Vendite e Marketing, KennelSource



Codice Capitolo 10

Meno software

Mantieni il tuo software quanto più semplice possibile

Dovresti pensare che codice sorgente due volte più grande, renderebbe la tua applicazione solamente due volte complessa. In realtà, ogni qualvolta aumentati la dimensione della tua applicazione, la complessità di quanto produci cresce in modo esponenziale. Ogni aggiunta minore, ogni cambiamento, ogni interdipendenza e ogni preferenza ha un effetto a cascata sul resto dell’applicazione. Continua ad aggiungere codice senza ritegno e prima che te ne renda conto avrai creato un’enorme e terrificante palla di fango (Big Ball of Mug).

Il modo per combattere questo genere di complessità è scrivere meno software. Meno software significa meno funzioni, meno codice, meno spreco.

Il segreto sta nel riformulare ogni problema complesso che richiede la scrittura di molto software, in un problema semplice che ne richiede molto meno. Può darsi che in questo modo tu non stia risolvendo esattamente lo stesso problema, ma va bene così. Risolvere l’80% del problema con il 20% dello sforzo è sicuramente una grande vittoria. Il problema originale non è quasi mai così importante da valere cinque volte lo sforzo della sua versione semplificata.

Meno software significa aver deciso di mettere da parte la sfera di cristallo. Invece di cercare di predire problematiche future, occupati solamente delle difficoltà di oggi. Perché? I timori circa quanto potrà accadere domani, spesso non conducono mai a un risultato certo. Non fissarti cercando di risolvere queste problematiche fantasma.

Fin dall’inizio in 37signals abbiamo pensato i nostri prodotti attorno al concetto di “meno software”. Ogniqualvolta è possibile, riduciamo problemi complessi in problemi più semplici. Abbiamo trovato soluzioni a problemi semplici, che non solo sono più facili da realizzare e gestire, ma anche più facili da comprendere e da utilizzare. Tutto ciò fa parte di come ci differenziamo dai competitor; invece di cercare di costruire prodotti che fanno di più, sviluppiamo prodotti che fanno meno.

  • Meno software è più facile da gestire.
  • Meno software riduce la mole del tuo codice sorgente e questo significa meno tempo speso nel lavoro di mantenimento (e quindi dei programmatori più felici).
  • Meno software abbassa i costi legati al cambiamento, consentendo un adattamento più rapido. Puoi cambiare idea senza dover incidere su un’enorme quantità di codice.
  • Meno codice conduce a meno bug.
  • Meno codice significa meno supporto.

Anche la scelta relativa a quali funzionalità includere e quali escludere ha ripercussioni dirette sulla dimensione del software. Non dispiacerti nel dire “No” a richieste funzionali complesse da realizzare. A meno che non siano assolutamente essenziali, risparmia tempo, energie e confusione escludendole dalla tua roadmap.

Rallenta. Lascia sedimentare le idee; lascia passare una settimana prima di agire e chiediti se, dopo l’entusiasmo iniziale, ti sembra ancora una grande trovata. Lasciar “marinare” ancora un po’ le idee, spesso aiuterà il tuo cervello a far emergere soluzioni più semplici.

Incoraggia i programmatori a proporre delle contro offerte.
Ciò che vuoi sentirti dire è :”Se procediamo come mi hai suggerito ci vorranno dodici ore. Ma esiste un modo per farlo solamente in un’ora. Non farò x ma farò y.” Lascia che il software torni sui suoi passi. Raccomanda ai programmatori di lottare per ciò che ritengono sia il modo migliore di procedere.

Inoltre, cerca alternative per non scrivere ulteriore software. Puoi cambiare il testo a video in modo tale che suggerisca un percorso alternativo ai clienti e non si renda quindi necessaria una variazione nel software? Per esempio, puoi suggerire alle persone di caricare immagini di una dimensione specifica invece di prenderti carico della manipolazione delle stesse sul server?

Per ogni funzionalità che implichi un cambiamento alla tua applicazione, interrogati: Esiste un modo per cui posso aggiungere quanto mi chiedono senza produrre molto codice? Scrivi solamente le righe di codice di cui hai realmente bisogno e nulla di più. La tua applicazione risulterà più snella e più sana.

Nessun codice è più flessibile dell’assenza di codice!

Il “segreto” di un buon progetto software non stava nel conoscere ciò che era necessario aggiungere; stava invece nel comprendere cosa escludere! Stava nel riconoscere dov’erano i punti di forza e quelli di debolezza e capire dove lasciare spazio piuttosto che tentare riempire con più struttura e progettazione.

—Brad Appleton, software engineer
(da There is No CODE that is more flexible than NO Code!)

La complessità non scala linearmente con la dimensione

La regola più importante dell’ingegneria del software è anche la meno nota: La complessità non scala linearmente con la dimensione… Un programma di 2000 linee di codice richiede più del doppio del tempo di sviluppo, rispetto a uno di metà ampiezza.

The Ganssle Group (from Keep It Small)



Ottimizza per essere felice

Scegli degli strumenti in grado di mantenere il tuo team entusiasta e motivato

Un programmatore felice è un programmatore produttivo. Ecco perché noi ottimizziamo mirando alla soddisfazione e anche tu dovresti. Non selezionare solamente strumenti e modalità operative basate su standard di mercato o metriche di performance. Guarda a ciò che è intangibile: C’è passione, orgoglio e competenza in ciò che stai scegliendo? Sarai veramente felice a lavorare per otto ore al giorno in questo modo?

Questo è particolarmente importate nella scelta del linguaggio di programmazione. Contrariamente a quanto si pensa, questi non sono stati creati tutti nello stesso modo. Mentre è possibile usare un qualsiasi linguaggio per creare un’applicazione, scegliere quello giusto non soltanto rende il lavoro possibile o tollerabile, ma piacevole e stimolante. Tutto sta nel rendere divertenti i piccoli dettagli di ogni giornata di lavoro.

La felicità è contagiosa. Dei programmatori soddisfatti fanno la cosa giusta. Scrivono codice semplice e facilmente accessibile. Scelgono un approccio chiaro, espressivo, comprensibile ed elegante. Si divertono.

Noi abbiamo trovato in Ruby il paradiso della programmazione e l’abbiamo trasmesso questa passione ad altri programmatori attraverso Rails. Entrambi condividono l’intento di ottimizzare per gli uomini e la loro felicità. Ti incoraggiamo a dare all’accoppiata Ruby e Rails un’accelerazione.

In definitiva, le tue persone necessitano di lavorare con strumenti che amano. In quest’ambito abbiamo affrontato l’argomento in termini di linguaggi di programmazione, ma quanto detto rimane ugualmente valido per le applicazioni, le piattaforme e ogni altro aspetto del lavoro quotidiano delle tue persone. Scegli la combinazione in grado di matenere alto l’entusiasmo del gruppo di lavoro. Otterrai in cambio un team motivato e come risultato un prodotto migliore.

Il tipo di professionisti che vorresti

La ragione principale per cui voglio realizzare applicazioni utilizzando Ruby on Rails è perché risulta essere elegante, consente una produttività elevata ed è ben progettato. Ruby on Rails tende ad attrarre gli ingegneri ai quali interessano questo tipo di cose… questi sono esattamente i professionisti che tu desidereresti avere nel tuo team, sono persone in grado di creare un prodotto elegante ed efficace con cui vincere sul mercato.

—Charles Jolley, Managing Director at Nisus Software (from Signal vs. Noise)



Il codice parla

Ascolta quando il codice ti induce a tornare sui tuoi passi

Ascolta il codice. Ti offrirà suggerimenti. Ti farà arretrare. Ti dirà dove si nascondono i trabocchetti. Ti suggerirà nuovi modi per procedere. Ti aiuterà a individuare un modello che conduce a produrre meno software.

La realizzazione di una nuova funzione richiede settimane di lavoro e migliaia di righe di programmazione? E’ il tuo codice che ti sta dicendo che probabilmente esiste un modo migliore per fare le cose. Esiste un modo semplice per realizzare qualcosa in un’ora invece di un approccio complicato che ne richiede dieci? Ancora, è il codice che ti sta guidando. Ascoltalo.

Il codice ti può indicare interventi che sono economici e leggeri. Presta attenzione quando si delinea un percorso diretto. Certo, una funzione facile da realizzare potrebbe non essere la medesima che inizialmente avevi ipotizzato. E con questo? Se funziona abbastanza bene e ti lascia più tempo da da poter spendere su altri fronti, va scelta come la via migliore.

Ascolta

Non preoccuparti del design, se ascolterai il codice ne nascerà un buon design… Ascolta i tecnici. Se si stanno lamentando delle difficoltà incontrate nell’apportare dei cambiamenti, prendili seriamente e dà loro il tempo di mettere a posto le cose.

—Martin Fowler, Chief Scientist, ThoughtWorks (from Is Design Dead?)

Se i programmatori venissero pagati per rimuovere codice…

Se i programmatori venissero pagati per rimuovere codice dal software e non per aggiungere codice, le applicazioni risulterebbero di gran lunga migliori.

Nicholas Negroponte, Professor of Media Technology at MIT
(from And, the rest of the (AIGA Conference) story)



Gestisci il debito

Ripaga il “conto” nei contronti del codice e del design

Solitamente pensiamo al debito in termni di denaro, ma esistono anche altre forme di debito. A facile costruire un debito di codice e di design.

Lavora con altri su del codice che che sia funzionante, ma con qualche problema e starai creando un debito. Metti in pista assieme ad altri un design che sia abbastanza buono, ma non veramente buono e lo avrai fatto ancora.

Agire iin questo modo di tanto in tanto va bene. E’ infatti spesso una tecnica necessaria per raggiungere il più in fretta possible lo stato di Get-Real. In ogni caso è necessario che tu riconosca di avere un debito nei confronti del codice o del design; è necessario che ad un certo punto il debito venga pagato ripulendo il codice imperfetto o riprogettando quella pagina mediocre.

Allo stesso modo in cui regolarmente accantoni un po’ dei tuoi guadagni per pagare le tasse, riservati regolarmente del tempo per ripagare il debito nei confronti del codice e del design. If you don’t, you’ll just be paying inter
est (fixing hacks) instead of paying down the principal (and moving forward).



Apri le porte

Fai in modo che i tuoi dati escano verso il mondo via RSS, API, ecc.

Non tentare di imprigionare i tuoi clienti. Lascia che possano accedere alle loro informazioni quando e come vogliono. Per far ciò, devi abbandonare l’idea di inscatolare ermeticamente i dati. Lascia invece che si muovano liberamente. Fornisci accesso ai dati via RSS feed. Offri delle API che consentano a sviluppatori di terze parti di costruire sui tuoi strumenti. Così facendo, renderai la vita dei tuoi clienti più agevole ed estenderai le potenzialità della tua applicazione.

La gente è abituata a pensare ai feed RSS semplicemente come un buon modo per tenere traccia dei blog o dei siti di news. I feed hanno un potenziale molto maggiore. Forniscono infatti un canale perfetto attraverso il quale i clienti possono mantenersi aggiornati circa le variazione in atto all’interno di un’applicazione senza doversi connettere continuamente. Con i feed di Basecamp, i clienti possono mantenere un occhio ai messaggi di progetto, alle todo list e alle milestone, senza doversi costantemente connettere alla web site.

Le API permettono agli sviluppatori di realizzare degli add-on al prodotto amplificandone il potenziale senza limiti. Per esempio, Backpack fornisce una API che Chipt Productions ha utilizzato per costruire un oggetto per la dashboard di Mac OS X. Il widget consente di aggiungere e modificare reminder, elementi di todo list e altro ancora, direttamente dal proprio desktop. I clienti si sono dimostrati assolutamente entusiasti di questo widget e per alcuni è stata una caratteristica determinante nella scelta di Backpack.

Altri buoni esempi di aziende che lasciano che i dati siano sempre disponibili ai loro proprietari, per ottenere un effetto boomerang:

  • Le API di Google Maps hanno generato dei “mash up” che consentono alle persone di raccogliere informazioni da altre sorgenti (es. liste di appartamenti) ed evidenziare tali dati su una mappa.
  • Linkrolls offre un modo alle persone per visualizzare i propri bookmark del.icio.us all’interno di proprie web site.
  • Flickr consente ad altre realtà di business di accedere ad API commerciali per far sì che i clienti possano acquistare album fotografici, poster, back up su DVD e francobolli. “L’obiettivo è di aprirsi completamente e fornirti la maggior scelta possibile quando si tratta di fare qualcosa con le tue foto,” afferma Stewart Butterfield di Flickr.

Un Widget Fa la Differenza

Quando 37signals rilasciò Backpack tempo addietro, la mia prima impressione fu… eh.

Così tempo dopo Chipt Productions rilasciò un widget di Backpack per Tiger — che era troppo forte per non essere scaricato e provato — tanto che diedi a Backpack una seconda occhiata. Il risultato? Abbastanza diverso.

Ora ogni qualvolta mi viene un’idea, apro il widget, scrivo e invio — fatto. Arriva un’email contenente qualcosa che voglio controllare? Apro il widget, scrivo e invio — fatto. Il widget è un “brain dump” immediatamente disponibile da ogni Mac che utilizzo. E dato che ogni cosa è web based, non esiste il controllo di versione o la sincronizzazione — soltanto il fluido input di contenuto senza doversi preoccupare dove stia andando o come lo accederò in seguito.

—Todd Dominey, fondatore, Dominey Design
(from Trying on Backpack)



Parole chapter 11

Non c'è nulla di funzionale in una Specifica Funzionale

Non scrivere un documento di specifica funzionale

Questi documenti di riferimento in definitiva non hanno quasi nulla a che fare con il prodotto finito. Ecco il perché:

Le specifiche funzionali sono fantasie

Non riflettono la realtà. Un'applicazione non è reale fino a quando i costruttori non la costruiscono, i designer non la disegnano e la gente non la utilizza. Le specifiche funzionali sono solamente parole su fogli di carta.

Le specifiche funzionali sanno rendere tutti felici

Le specifiche riguardano il fatto che ognuno si senta coinvolto e felice e ciò, pur essendo una bella cosa, non è molto utile. Le specifiche non riguardano mai prendere decisioni difficili e scoprire costi, tutte cose che è necessario avvengano per costruire una grande applicazione.

Functional specs only lead to an illusion of agreement

A bunch of people agreeing on paragraphs of text isn’t a true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on: “Wait, that’s not what I had in mind.” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.

Functional specs force you to make the most important decisions when you have the least information

You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That’s when you should be making decisions — when you have more information, not less.

Functional specs lead to feature overload

There’s no pushback during spec phase. There’s no cost to writing something down and adding another bullet point. You can please someone who’s a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that’s how you wind up with an overloaded site that’s got 30 tabs across the top of the screen.

Functional specs don’t let you evolve, change,and reassess

A feature is signed off and agreed on. Even if you realize during development that it’s a bad idea, you’re stuck with it. Specs don’t deal with the reality that once you start building something, everything changes.

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it’s too complex. This process shouldn’t take more than one day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and “feeling” before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.

Useless Specs

A “spec” is close to useless. I have never seen a spec that was both big enough to be useful and accurate.

And I have seen lots of total crap work that was based on specs. It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)

Fight the blockers

I found the people insisting on extensive requirements documents before starting any design were really ‘blockers’ just trying to slow the process down (and usually people with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good result.

—Mark Gallagher, corporate intranet developer (from Signal vs. Noise)



Don’t Do Dead Documents

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don’t stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don’t produce it.

Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Here’s an example: If a wireframe document is destined to stop and never directly become the actual design, don’t bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

Documents that live separately from your application are worthless. They don’t get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it’s dead.

No One’s Going to Read It


I can’t even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user
testing as we went. I’ve even worked with developers who’ve spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don’t move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don’t waste your time typing up that long visionary tome; no one’s going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won’t resemble anything you wrote about anyway.

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide



Tell Me a Quick Story

Write stories, not details

If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don’t get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn’t need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.



Use Real Words

Insert actual text instead of lorem ipsum

Lorem ipsum dolor is a trusted friend of designers. Dummy text helps people get what the design will look like once it’s fleshed out. But dummy text can be dangerous too.

Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element — a shape of text — instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won’t see the inevitable variations that show up once real information is entered. It means you won’t know what it’s like to fill out forms on your site. Dummy text is a veil between you and reality.

You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

As soon as you can, use real and relevant words. If your site or application requires data input, enter the real deal. And actually type in the text — don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.

Sure, it’s easier to just run down the forms and fill the fields with garbage (“asdsadklja” “123usadfjasld” “snaxn2q9e7”) in order to plow through them quickly. But that’s not real. That’s not what your customers are going to do. Is it really smart to take a shortcut when customers are forced to take the long road? When you just enter fake copy in rapid-fire fashion, you don’t know what it really feels like to fill out that form.

Do as your customers do and you’ll understand them better. When you understand them better, and feel what they feel, you’ll build a better interface.

Lorem Ipsum Garbage

By not having the imagination to imagine what the content “might” be, a design consideration is lost. Meaning becomes obfuscated because “it’s just text”, understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn’t suggest opportunities. The text then gets made really small, because, it’s not meant to be used, we might as well create loads of that lovely white space.

—Tom Smith, designer and developer (from I hate Lorem Ipsum and Lorem Ipsum Users)



Personify Your Product

What is your product’s personality type?

Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trusting? As a know-it-all? Or modest and likable?

Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app’s personality.

Your product has a voice — and it’s talking to your customers 24 hours a day.



Pricing and Signup chapter 12

Free Samples

Give something away for free

It’s a noisy world out there. In order to get people to notice you amid the din, give something away for free.

Smart companies know giving away freebies is a great way to lure in customers. Look at Apple. They offer iTunes software for free in order to build demand for the iPod and the iTunes music store. In the offline world, retail outlets do the same. Starbucks says a new purchase is stimulated for every five beverage samples they give away to customers. Not too shabby.

For us, Writeboard and Ta-da list are completely free apps that we use to get people on the path to using our other products. Also, we always offer some sort of free version of all our apps.

We want people to experience the product, the interface, the usefulness of what we’ve built. Once they’re hooked, they’re much more likely to upgrade to one of the paying plans (which allow more projects or pages and gives people access to additional features like file uploading and ssl data encryption).

Bite-size chunks

Make bite-size chunks: Devise specialized, smaller offerings to get customers to bite. Resolve to sub-divide at least one product or service into bite-size chunks that are inexpensive, easy or fun.

—Ben McConnell and Jackie Huba, authors of Church of the Customer Blog

(from What is customer evangelism?)

Give Away Your Hit Single

Consider giving one of your songs (per-album) as a free promotional download to the world — to be like the movie trailer — like the hit single sent to radio — the song that makes people want to go buy your music.

Don’t worry about piracy for this song. Let people play it, copy it, share it, give it away. Have the confidence that if the world heard it, they will pay for more.

—Derek Sivers, president and programmer, CD Baby and HostBaby (from Free Promo Track)



Easy On, Easy Off

Make signup and cancellation a painless process

Make it as easy as possible to get in — and get out — of your app.

If I’m a customer that wants to use your app, it should be a painless, no-brainer process. Provide a big, clear, signup button that pops and put it on each page of your marketing site. Tell folks how easy it is: “From sign-up to login in just 1 minute!”

There should always be a free option so customers can demo the app without entering credit card information. Some of our competitors require a call back, an appointment, or a special password in order to try their product. What’s the deal with that? We let anyone try our apps for free at any time.

Keep the signup form as short as possible. Don’t ask for stuff you don’t need and don’t throw a long daunting form at people.

The same principles hold true for the cancellation process. You never want to “trap” people inside your product. While we’re sorry when people decide to cancel their Basecamp account, we never make that process intimidating or confusing. “Cancel my account” is a link that’s clear as day on a person’s account page. There shouldn’t be any email to send, special form to fill out, or questions to answer.

Also, make sure people can get their data out if they decide to leave. We make sure customers can easily export all messages and comments in xml format at any time. It’s their data and they should be able to do with it what they want.

This is crucial because giving people control over their information builds trust. You’re giving them a bridge to their data island. You’re allowing them to leave without penalty if they find a better offer. It’s the right thing to do and it builds goodwill.

Exit with Ease

Don’t hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave…for free… You have to let the barn door open and focus on keeping your customers fed, so they want to come back, instead of coming back because they’re stuck.

—Charlie O’Donnell, analyst, Union Square Ventures
(from 10 Steps to a Hugely Successful Web 2.0 Company)



Silly Rabbit, Tricks are for Kids

Avoid long-term contracts, sign-up fees, etc.

No one likes long term contracts, early termination fees, or one
time set-up fees. So avoid them. Our products bill on a month
to-month basis. There’s no contract to sign and you can cancel at any time without penalty. And there are never any set-up fees.

Don’t try to find “tricky” ways to get more cash. Earn it.



A Softer Bullet

Soften the blow of bad news with advance notice and grandfather clauses

Need to deliver bad news like a price increase? Make it as painless as possible by giving folks plenty of advance notice. Also, consider a grandfather period that exempts existing customers for a certain period of time. These folks are your bread and butter and you want to make them feel valued, not gouged.



Promotion chapter 13

Hollywood Launch

Go from teaser to preview to launch

If an app launches in a forest and there’s no one there to use it, does it make a noise? The point here is that if you launch your app without any pre-hype, people aren’t going to know about it.

To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.

Teaser

A few months ahead of time, start dropping hints. Let people know what you’re working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.

At this stage, you should also start seducing mavens and insiders. These are the folks on the cutting edge. They’re the tastemakers. Appeal to their vanity and status as ahead-of-the-curvers. Tell them they’re getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you’ll get loads of traffic and followers. Plus, your page rank at Google will go up too.

Preview

A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product. For Basecamp, we posted screenshots and highlighted reminders, milestones, and other features.

Also, tell people about the ideas and principles behind the app. For Backpack, we posted our manifesto before launch. This got people thinking and talking about the app.

You can also offer some special “golden tickets” to a few people so they can start using the app early. You’ll get the benefit of having some beta testers while they’ll feel that special glow that people get from being early adopters.

And again, encourage people to sign up so you’ve got a foundation of emails to blitz once you launch. By the time we launch our apps, we have thousands of emails to ping which is a big help in gaining traction.

Launch


It’s release time. Now people can actually go to the “theater” and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.

The Road to Launch Day

As soon as we knew Blinksale was really going to happen, we began floating some teasers to our mailing list. These are people who have asked to receive information from us about our projects. These are our fans, if you will. If you already have permission to talk to a group of people, they are the best place to start.

The second thing we did is get permission to talk to more people about our product. About six weeks before the Blinksale launch we put up a teaser page at our website that proclaimed the coming of an easier way to send invoices online. The page gave just enough information to build excitement and suspense, without giving away sensitive details that needed to remain confidential. Prominently displayed on the page was a newsletter subscription form, requiring nothing but an email (keep it simple) so that those interested could be notified when the product launched.

We spread the word to a dozen or so friends and colleagues that we felt would be interested in the product as well, and they began to spread the word about the teaser page through their blogs and websites. Within a few days, we had thousands on our mailing list. These were extremely important people — people who are asking to learn more about our product and who wanted to know when we launched.

Finally, about two weeks before we launched, we invited a handful of friends, colleagues, and industry mavens to help us beta test Blinksale. This allowed us to get the product in front of people we felt could benefit from its use and who could help us spread the word about the product when we launched. It’s important to note that we didn’t force anyone to use or write about the product. We simply wanted it to be seen and wanted people to talk about it when it launched. In the end, if you’re going to build buzz this way, you better be sure your product can deliver. Otherwise, it’s like clouds without rain.

When launch day arrived, we sent an email to our mailing list, notified our blogging friends, and encouraged our beta testers to speak their minds. And to our great delight, the effort paid big dividends. Shortly after launch tens of thousands had visited our site and thousands of those had signed up to use the product.

—Josh Williams, founder, Blinksale



A Powerful Promo Site

Go from teaser to preview to launch

The best promotional tool is a great product. Word will get out if you’ve got an app that people find really useful.

Still, you need an ace promotional site too. What should you include on this site? Some ideas:

  • Overview: Explain your app and its benefits.
  • Tour: Guide people through various features.
  • Screen captures and videos: Show people what the app actually looks like and how to use it.
  • Manifesto: Explain the philosophy and ideas behind it.
  • Case Studies: Provide real life examples that show what’s possible.
  • Buzz: Testimonial quotes from customers, reviews, press, etc.
  • Forum: Offer a place for members of the community to help one another.
  • Pricing & Sign-up: Get people into your app as quickly as possible.
  • Weblog: Blogs keep your site fresh with news, tips, etc.



Ride the Blog Wave

Blogging can be more effective than advertising (and it’s a hell of a lot cheaper)

Advertising is expensive. And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself. When you don’t have the time or money to go the traditional advertising route, consider the promote-via-blog route instead.

Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc. Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

So when it came time to promote our first product, Basecamp, we started there. We got the word out on SvN and it started to spread. Folks like Jason Kottke, the BoingBoingers, Jim Coudal, and a variety of other people with popular blogs helped raise the visibility and things took off.

Ta-da Lists is another great example of the power of blog-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it had been mentioned on over 200 blogs and over 12,000 people had signed up for their own Ta-da account. Word about Backpack spread even faster. Within 24 hours of launch, more than than 10,000 signed up.



Solicit Early

Get advance buzz and signups going ASAP

We’ve already touched on it but it bears repeating: Get some sort of site up and start collecting emails as soon as possible. Pick your domain name and put up a logo and maybe a sentence or two that describes, or at least hints at, what your app will do. Then let people give you their email address. Now you’re on your way to having a foundation of folks ready and waiting to be notified of your launch.



Promote Through Education

Share your knowledge with the world

When a teacher appears as a contestant on Jeopardy, Alex Trebek often comments that it’s a “noble profession.” He’s right. There’s definitely something wonderful and rewarding about sharing your knowledge with others. And when the subject you’re teaching is your app, it serves a dual purpose: You can give something back to the community that supports you and score some nice promotional exposure at the same time.

As a promotional technique, education is a soft way to get your name — and your product’s name — in front of more people. And instead of a hard sell “buy this product” approach, you’re getting attention by providing a valuable service. That creates positive buzz that traditional marketing tactics can’t match. People who you educate will become your evangelists.

Education can come in many forms. Post tips and tricks at your site that people will want to share with others. Speak at con- ferences and stay afterwards to meet and greet with attendees. Conduct workshops so curious fans can learn more and talk to you in the flesh. Give interviews to publications. Write articles that share helpful information. And write books. ;)

An example from our own history is the Yellow Fade Technique, a method we invented to subtly spotlight a recently changed area on a page. We wrote a post about it on Signal vs. Noise. That post made the rounds and got thousands and thousands of page views (to this day it’s doing huge traffic).

The post worked on both an educational and a promotional level. A lesson was learned and a lot of people who never would have known about our products were exposed to them. Another example: During our development of Ruby on Rails, we decided to make the infrastructure open source. It turned out to be a wise move. We gave something back to the com- munity, built up goodwill, garnered recognition for our team, received useful feedback, and began receiving patches and con- tributions from programmers all over the world.

Teaching is all about good karma. You’re paying it forward. You’re helping others. You get some healthy promotion. And you can even bask in a bit of nobility. So what do you know that the world wants to hear about?

Pay It Forward

The articles and tips section of our blog is one of the most popular sections of our site. Passing on our knowledge about email marketing ensures our customers get the most out of our software. If they can provide a better service to their customers, then they’re likely to get more business, which in turn creates more business for us — everyone wins.

Freely sharing our knowledge has also helped position us as experts in the industry and strengthened our relationship with existing customers. They know we care about the quality of their work. Finally, we get loads of targeted inbound traffic from search engines and bloggers who share our articles with their readers. These are people that would never have heard of our software had we not written that article.

—David Greiner, founder, Campaign Monitor



Feature Food

They’re hungry for it so serve it up

New or interesting features are a great way to generate buzz for your application. Special interest groups love to chew up “feature food” and spit it back out to the community. Alright, that’s kind of an unpleasant analogy but you get the point.

For example, by using Ruby on Rails, a new development platform, we generated a ton of attention for Basecamp within the developer community.

The Ajax elements we used in our applications got lots of buzz and even led to Business 2.0 magazine naming 37signals a “key player in Ajax” alongside big names like Google, Yahoo, Microsoft, and Amazon.

Another example: Bloggers took notice of Basecamp’s RSS support since it was one of the first business examples of RSS.

iCal integration, a seemingly minor feature, got us press on a ton of Mac-related sites which probably never would have mentioned the app otherwise.

Small teams have a leg up on integrating new ideas into software. While bigger companies have to deal with bureaucratic bottlenecks, you can rapidly implement new ideas and get attention for using them.

Riding the hype coattails of the technology du jour is an effective and cheap way to build your buzz. That said, don’t go adding the latest obscure technology just to gain some notice. But if you are using something new or noteworthy, go ahead and spotlight it for special interest groups.



Track Your Logs

Study your logs to track buzz

You need to know who’s talking about you. Check your logs and find out where the buzz is coming from. Who’s linking to you? Who’s bitching about you? Which blogs listed at Technorati, Blogdex, Feedster, Del.icio.us, and Daypop are hot on your trail?

Find out and then make your presence felt. Leave comments at those blogs. Thank people for posting links. Ask them if they want to be included on your special advance list so they’ll be among the first to know about future releases, updates, etc. Collect positive praise and create a “buzz” page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

If the comments are negative, still pay attention. Show you’re listening. Respond to critiques thoughtfully. Something like: “We appreciate the feedback but we did it this way because…” Or “You raise a good point and we’re working on it.” You’ll soften up your critics and put a human face on your product. It’s amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.



Inline Upsell

Promote upgrade opportunities inside the app

Everyone knows to pitch at the marketing site. But the sell shouldn’t stop there. If you have a tiered pricing plan (or a free version of your app), don’t forget to call out upgrade opportuni
ties from within the product.

Tell folks that you’ll remove barriers if they upgrade. For example, in Basecamp you can’t upload files if you have a free account. When someone tries to upload a file, we don’t just turn them away. We explain why file uploading isn’t available and encourage them to upgrade to the paid version and explain why that’s a good idea. The same approach is used to encourage ex
isting customers to upgrade to a higher level account when they max out their current plan.

Existing customers are your best bet for sales. Don’t be shy about trying to get repeat business from people who already know and use your product.



Name Hook

Give your app a name that’s easy to remember

A big mistake a lot of people make is thinking their app’s name needs to be ultradescriptive. Don’t worry about picking a name that vividly describes your tool’s purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress. Writeboard is better than CollaborEdit.

Also, don’t focus group or committee-ize the naming process too much. Pick a name that’s short, catchy, and memorable and then run with it.

And don’t sweat it if you can’t get the exact domain name you want. You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).

Easy Does It

Doesn’t the tech industry realize that thinking up catchy, self-explanatory names would ultimately benefit it in the same way? They’d sell more of whatever it was, because they wouldn’t scare off consumers who think they’re being kept out of the high-tech club by a bunch of arrogant engineers. The technology would catch on quicker, too. The new product would be easier to describe, easier to use and easier to buy — which, for the companies, means easier to sell.

—David Pogue, columnist, New York Times (from What’s in a Product Name?)



Assistenza capitolo 14

Comprendi il problema

Abbatti i muri fra assistenza e sviluppo

Nell’industria della ristorazione c’è una enorme differenza fra chi lavora in cucina e chi è fuori a gestire la clientela. È importante per entrambe le parti conoscere e comprendere le ragioni l’una dell’altra. Per questo le scuole di cucina ed i ristoranti spesso fanno lavorare gli chef di cucina come camerieri, in maniera che interagiscano con i clienti e vedano come vanno realmente le cose in prima linea.

Molti sviluppatori di software soffrono di una simile separazione. I progettisti e i programmatori lavorano in “cucina”, mentre il servizio di assistenza deve occuparsi dei clienti. Sfortunatamente, questo significa che molti chef del software non hanno mai occasione di ascoltare che cosa i clienti dicono veramente. E questo è un problema, perché ascoltare i clienti è il modo migliore per sintonizzarsi con i punti di forza e le debolezze del vostro prodotto.

La soluzione? Evitate di costruire muri fra i vostri clienti e il team di sviluppo/progettazione. Non affidate l’assistenza a un call center o a terzi. Fatelo da soli. Voi, ed il vostro intero team, dovreste sapere che cosa i clienti stanno dicendo. Quando i vostri clienti sono infastiditi, avete bisogno di saperlo. Avete bisogno di ascoltare le loro lamentele. Dovete essere infastiditi anche voi.

In 37signals, tutte le richieste di assistenza sono sbrigate personalmente dalle persone che hanno effettivamente costruito il prodotto. Perché? Per prima cosa, questo garantisce una assistenza migliore per i clienti. La risposta viene dritta dalla testa di chi ha costruito l’applicazione. Inoltre, ci manteniamo in contatto con le persone che usano il nostro prodotto e con i problemi che incontrano. Quando loro sono frustrati, noi siamo frustrati. Possiamo dire “Comprendo il problema” e capirlo veramente.

Può essere una vera tentazione affidarsi alle analisi statistiche per rilevare i problemi. Ma le statistiche non parlano come le voci. Dovete eliminare più filtri possibile fra voi e le voci dei vostri clienti.

La prima linea è dove si trova l’azione. Fatevi trovare là. Fate lavorare i vostri chef come camerieri. Leggete le email dei clienti, ascoltate le loro frustrazioni, ascoltate i loro suggerimenti e imparate da loro.

Togliete di mezzo gli intermediari

Quasi tutti i processi di sviluppo, assistenza e marketing di Campaign Monitor sono gestiti da due persone. Anche se siamo stati costretti ad ampliare la squadra, non separeremo mai l’assistenza dallo sviluppo. Rispondendo personalmente a ogni richiesta, ci costringiamo a metterci nei panni dei clienti e a vedere le cose dalla loro prospettiva.

È importante capire il perché i vostri clienti hanno bisogno di qualcosa, non solo che ne hanno bisogno. La comprensione del contesto ha spesso un effetto diretto su come progettiamo le cose. Togliete di mezzo gli intermediari. E più facile dare ai vostri clienti ciò di cui hanno bisogno, se ascoltate il terreno con attenzione.

Ho avuto modo di discutere questo argomento con una quantità di persone, e spesso mi sento dire: “incaricheresti un apprendista se dovesse gestire la tua assistenza?” Mettetevi nei panni del cliente. Se volete la bistecca cotta esattamente come vi piace, fareste meglio a dirlo all’aiuto cameriere oppure al cuoco che la sta cuocendo in questo stesso momento?

—David Greiner, fondatore, Campaign Monitor



Zero Training

Use inline help and FAQs so your product doesn’t require a manual or training

You don’t need a manual to use Yahoo or Google or Amazon. So why can’t you build a product that doesn’t require a manual? Strive to build a tool that requires zero training.

How do you do this? Well, as we’ve mentioned before, you start by keeping everything simple. The less complex your app is, the less you’ll need to help people out of the weeds. After that, a great way to preempt support is by using inline help and faqs at potential points of confusion.

For example, we offer preemptive support on the screen that allows people to upload their logo to Basecamp. Some people experienced a problem where they would keep seeing an old logo due to a browser-caching issue. So next to the “submit your logo” area, we added a link to an faq that instructed customers to force-reload their browsers in order to see the new logo. Before we did this, we would get 5 emails a day about this problem. Now we get none.



Answer Quick

Quick turnaround time on support queries should be a top priority

Customers light up when you answer their questions quickly. They’re so used to canned responses that show up days later (if at all) that you can really differentiate yourself from competitors by offering a thoughtful response right away. During business hours, we answer 90% of all email support requests within 90 minutes — and often within a half-hour. And people love it.

Even if you don’t have a perfect answer, say something. You can buy goodwill with a response that is delivered quickly in an open, honest way. If someone is complaining about an issue that can’t be fixed immediately, tell them something like, “We hear what you’re saying and we’ll be working on it in the future.” It’s a great way to diffuse a potentially negative situation.

Customers appreciate directness and will often shift from angry to polite if you respond quickly and in a straight-shooting manner.

An Army of Many

How can a small team of just three developers create an innovative product and successfully compete with the big guys? The answer is to enlist an army of many.

Remember from your first day that your customers are your most important asset and that they are absolutely vital to your long-term success so treat your community of users like royalty. The way to compete with the big guys is by starting small and paying attention to every one of your customers.

It is your customers that will be the first to alert you of bugs, that will be the first to alert you of needs that have not been met and it is your first customers that will carry the flag and spread your message.

This does not mean that your product has to be perfect when you launch. Quite to the contrary, release early and often. However, when your customers encounter bugs, make sure to send a reply to them quickly thanking them for their input.

Customers don’t expect your product to be perfect and they don’t expect that all of their features will be implemented. However, customers do expect that you are listening and acknowledging that you care, so show that you care. This is one area where most large companies show a huge deficit so develop a sense of community early.

At Blinklist, every single customer email is answered, usually within the first hour (unless we happen to be asleep). We also have an online forum and we make sure that every single post and comment gets acknowledged.

Equally important, all of our developers receive our customer feedback and they are active participants in the online discussion forums. This way, we are slowly but surely building an active and loyal BlinkList community.

—Michael Reining, co-founder, MindValley & Blinklist



Tough Love

Be willing to say no to your customers

When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.

If we obeyed every whim of our customers, Basecamp would have: comprehensive time tracking, comprehensive billing, comprehensive meeting scheduling, comprehensive calendaring, comprehensive dependency task systems, comprehensive instant message chatting, comprehensive wiki functionality, and comprehensive whatever-else-you-can-imagine.

Yet, the #1 request we get on customer surveys is to keep Basecamp simple.

Here’s another example: Despite some complaints, we decided not to support ie5 with our products. That was 7% of the market we were writing off. But we decided it was more important to worry about the other 93%. Fixing bugs and testing for ie5 just isn’t worth the time. We’d rather make a better product for everyone else.

As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C’est la vie.

Related to this, it’s critical that you as a development company love your product. And you won’t love your product if it’s filled with a bunch of stuff you don’t agree with. That’s yet another justification for vetoing customer requests that you don’t believe are necessary.



In Fine Forum

Use forums or chat to let customers help each other

Forums and web-based group chat are a great way to let customers ask questions and help one another out. By eliminating the middleman — that’s you — you provide an open stream of communication and save yourself time in the process.

At our product forums, customers post tips and tricks, feature requests, stories, and more. We pop in from time to time to offer some assistance but the forums are mainly a place for the community to help each other and share their experiences with the product.

You’ll be surprised how much people want to help one another.



Publicize Your Screwups

Get bad news out there and out of the way

If something goes wrong, tell people. Even if they never saw it in the first place.

For example, Basecamp was down once for a few hours in the middle of the night. 99% of our customers never knew, but we still posted an “unexpected downtime” notice to our Everything Basecamp blog. We thought our customers deserved to know.

Here’s a sample of what we post when something goes wrong: “We apologize for the downtime this morning — we had some database issues which caused major slowdowns and downtimes for some people. We’ve fixed the problem and are taking steps to make sure this doesn’t happen again…Thanks for your patience and, once again, we’re sorry for the downtime.”

Be as open, honest, and transparent as possible. Don’t keep secrets or hide behind spin. An informed customer is your best customer. Plus, you’ll realize that most of your screwups aren’t even that bad in the minds of your customers. Customers are usually happy to give you a little bit of breathing room as long as they know you’re being honest with them.

A side note about delivering news, bad and good: When bad news comes, get it all out in the open at once. Good news, on the other hand, should be trickled out slowly. If you can prolong the good vibes, do it.

Be Swift, Direct, and Honest

It may sound strange, but the best-case scenario is when the company itself reports the bad news. This is proactive and prevents your company from being put in a weakened, defensive position.

—Greg Sherwin, Vice President of Application Technology, CNET, and Emily Avila, Principal, Calypso Communications (from A Primer for Crisis PR)



Post-Lancio chapter 15

Un mese di messa a punto

Rilascia una major update 30 giorni dopo il lancio

Un aggiornamento rapido indica movimento. Mostra che sei all’ascolto. Indica che hai ancora assi nella manica. Ti consente di avere una seconda ondata di entusiasmo. Riconferma le sensazioni positive iniziali. Fornisce a te un argomento del quale parlare e agli altri un spunto per i propri blog.

Sapere che un aggiornamento verrà presto rilasciato ti consente inoltre di mantenere il focus sulle componenti critiche ancora presenti dopo il lancio. Invece di inserire rapidamente nuove funzionalità puoi cominciare a perfezionarne solo il nucleo principale. In seguito puoi far “prendere aria” al tuo prodotto nel mondo reale. Quando è stato rilasciato puoi cominciare ad acquisire feedback dai clienti e scoprire quali sono le aree che richiederanno maggiore attenzione in futuro.

Questo approccio a piccoli passi ha funzionato bene con Backpack. Noi abbiamo lanciato prima il prodotto base e in seguito, alcune settimane più tardi, abbiamo aggiunto funzionalità come il Backpack Mobile per i palmari e il tagging, perché queste erano le cose che i nostri clienti ci chiedevano maggiormente.



Continua a postare sul blog

Fai vedere che il tuo prodotto è vivo mantenendo aggiornato un blog relativo allo sviluppo del prodotto seguente al lancio

Non smettere di bloggare dopo il lancio. Mostra che il tuo prodotto è una creatura viva mantenendo un blog dedicato, aggiornato frequentemente (almeno una volta a settimana, anche di più se ti è possibile).

Cose da inserire:


  • Faq
  • Istruzioni
  • Suggerimenti
  • Nuove funzionalità, aggiornamenti, & problemi risolti
  • Notizie e cose interessanti

Un blog non dimostra solo che la tua applicazione è ancora viva, ma rende anche la tua azienda più umana. Ancora, non preoccuparti di mantenere un tono informale e amichevole. I piccoli team ogni tanto si sentono come se dovessero sempre apparire grandi e ultra professionali. E’ un po’ come una versione lavorativa del complesso di Napoleone. Non preoccuparti di sembrare piccolo. Goditi il piacere di poter parlare ai tuoi clienti come se fossero tuoi amici.

E’ ancora vivo

Un blog di prodotto aggiornato frequentemente è il migliore indicatore del fatto che l’applicazione web è in una fase di sviluppo attivo, che è amata e che a casa c’è una luce accesa. Un blog abbandonato è segno di un prodotto abbandonato, e ci dice che le persone sul progetto stanno battendo la fiacca.

Mantieni la conversazione attiva con i tuoi utenti sul blog del tuo prodotto, sii trasparente e generoso nelle informazioni che condividi. Fai risplendere la filosofia della tua azienda. Inserisci apertamente link e discussioni suoi tuoi concorrenti. Avvisa dell’uscita di nuove funzionalità e mantieni aperti i commenti per avere feedback.

Un prodotto vivo è quello che parla e ascolta i suoi utenti. Un blog di prodotto sempre aggiornato promuove un senso di trasparenza, un senso di community e di fedeltà al proprio marchio. In più, la pubblicità gratuita è un bene.

Come editore di Lifehacker, controllo regolarmente i blog di prodotto che più amo — come i blog di Google, Flicker, Yahoo, del.icio.us, e 37Signals. Preferisco menzionare questi blog piuttosto che applicazioni che rilasciano dal nulla comunicati stampa di una pagina e poi non mantengono una conversazione aperta con i loro utenti e fan.

—Gina Trapani, sviluppatore web ed editore di Lifehacker, la guida del software e della produttività



Migliore, non Migliorabile

Non utilizzare la “beta” come un capro espiatorio

Al giorno d’oggi pare che tutto debba restare alla fase di beta per sempre. Questo significa chiamarsi fuori. Una fase di beta senza fine dice ai clienti che non sei portato a spenderti per il rilascio di un prodotto finito. Fa pensare, “Usalo, ma se non lo trovi perfetto, non è un nostro problema.”

Beta significa scaricare il barile sui tuoi clienti. Se tu stesso non sei convinto di ciò che rilasci, come puoi aspettarti che lo sia il pubblico? Le beta interne vanno bene, le beta pubbliche non hanno senso. Se il prodotto non è sufficientemente buono per essere consumato dal pubblico, non farlo consumare al pubblico.

Non aspettare che il tuo prodotto raggiunga la perfezione. Non succederà. Prenditi la responsabilità di ciò che stai rilasciando. Mettilo online e chiamalo “release”. In caso contrario, stai solo prendendo scuse.

Beta non ha significato

Rimprovera Google, e altri, per aver causato problemi di questo tipo. Al momento gli utenti sono stati educati da tutti gli sviluppatori a pensare che in realtà “beta” non ha alcun significato.

—Mary Hodder, information architect e interaction designer (da The Definition of Beta)

Tutto il tempo

Mi sbaglio, o siamo tutti in beta, tutto il tempo?

—Jim Coudal, fondatore, Coudal Partners



I bug non sono stati creati tutti uguali

Assegna una priorità ai tuoi bug (e ignorane qualcuno)

Non è il caso di farsi prendere dal panico solo perché hai scoperto un bug nel tuo prodotto. Tutti i software hanno bug — fa semplicemente parte della vita.

Non devi sistemare ogni bug immediatamente. La maggior parte dei bug sono fastidiosi, ma non distruttivi. I fastidi possono essere rimandati per un attimo. Anomalie che si traducono in “non si vede come dovrebbe” errori o altri peccati veniali possono tranquillamente essere lasciati da parte per un poco. Se un bug distrugge il database, invece, devi ovviamente risolverlo al più presto.

Assegna una priorità ai bug. Quanti utenti sono coinvolti? Quanto è grave il problema? Il bug necessità di un intervento immediato o può aspettare? Cosa puoi fare adesso per ottenere il beneficio maggiore del maggior numero di persone? Spesso aggiungere una funzionalità può essere più importante per la tua applicazione che risolvere un’anomalia esistente.

Inoltre, non creare un clima di terrore attorno ai bug. I bug succedono. Non cercare costantemente qualcuno da rimproverare. L’ultima cosa che puoi volere è un ambiente nel quale i bug sono nascosti sotto il tappeto invece di essere discussi apertamente.

E ricorda cosa abbiamo detto prima riguardo all’importanza dell’onestà. Se i clienti si lamentano di un’anomalia, sii sincero con loro. Di loro che hai preso nota e te ne farai carico. Se non sarà preso in considerazione subito, riferisci il perché e spiega che sei concentrato su aree del prodotto che coinvolgono un maggior numero di persone. L’onestà è la politica migliore.



Esci dalla bufera

Di fronte a un cambiamento aspetta che le reazioni istintive siano esaurite prima di intraprendere un’iniziativa.

Quando “scuoti la barca”, si alzeranno le onde. Dopo aver introdotto una nuova funzionalità, aver cambiato una regola o aver rimosso qualcosa, si genereranno rapidamente reazioni istintive, spesso negative.

Non farti prendere dal panico, resisti alla tentazione di cambiare rapidamente le cose. Le passioni divampano all’inizio. Ma se uscirai da questo iniziale periodo di 24-48 ore, di solito le cose si sistemeranno. Molte persone intervengono prima di aver realmente approfondito e sperimentato ciò che di nuovo hai inserito (o prima di aver apprezzato ciò che hai eliminato). Quindi mettiti comodo, cerca di capire bene, e non fare una mossa prima che sia passato un po’ di tempo. Solo allora sarai in grado di offrire una risposta più ragionata.

Inoltre, ricorda che quasi sempre le reazioni negative sono più forti e appassionate rispetto a quelle positive. Infatti, ti capiterà di sentire voci negative anche quando la maggioranza della tua base utenti è contenta di un cambiamento. Fai in modo di non retrocedere stupidamente su una decisione necessaria, ma controversa.



Non voler essere da meno dei vicini di casa

Abbonati alle news dei tuoi concorrenti

Abbonati sia alle news del tuo prodotto che ha quelle dei tuoi concorrenti (è sempre importante studiare le mosse del nemico). Utilizza servizi come PupSub, Technorati, Feedster, o altri per essere aggiornato (utilizza come parole chiave i nomi dei prodotti e delle aziende). Con gli RSS queste informazioni in costante cambiamento ti verranno recapitate in modo tale che tu sia sempre pronto all’azione.



Stai in guardia dal gigante gonfiato

Più maturo non significa per forza più complicato

Mentre le cose procedono, cerca di resistere a gonfiarti. La tentazione sarà quella di scalare. Ma questo non dovrà accadere gonfiandoti. Solo perché una cosa cresce e diventa più matura non significa che abbia bisogno di diventare più complicata.

Non devi diventare come una penna spaziale che scrive al contrario. Spesso è sufficiente restare una matita. Non è necessario che tu sia un coltellino svizzero. Puoi rimanere un cacciavite. Non hai bisogno di inventarti un orologio subacqueo che arriva a 5.000 metri di profondità se i tuoi clienti amano stare sulla terra ferma è vogliono solo sapere che ore sono.

Non espanderti solo con l’interesse di espanderti. Questo è il modo in cui le applicazioni alla fine esplodono.

Nuovo non significa sempre migliorato. Qualche volta si raggiunge un punto nel quale dovresti lasciare il tuo prodotto così com’è.

Questo è uno degli elementi vantaggiosi dello sviluppare software web-based rispetto al tradizionale software desktop-based. I costruttori di software per desktop come Adobe, Intuit, e Microsoft hanno la necessità di vendere una nuova versione ogni anno. E poiché non possono semplicemente venderti la stessa versione, devono giustificare la spesa aggiungendo nuove funzionalità. Questo è il momento in cui il software comincia a gonfiarsi.

Con il software web-based basato sulla logica dell’abbonamento, le persone pagano una quota mensile per usare il servizio. Non hai bisogno di fare upselling sugli utenti aggiungendo sempre nuove funzioni, devi semplicemente garantire un servizio di valore nel tempo.



Fatti trasportare dalla corrente

Stai pronto a imboccare nuove strade e ad affrontare cambiamenti di direzione

Parte della bellezza di una applicazione web risiede nella sua fluidità. Non sei costretto a chiuderla in una scatola, a spedirla, e ad aspettare anni per una nuova release. Puoi sistemarla rapidamente e cambiarla nel corso del tempo. Stai pronto ad accettare che la tua idea iniziale possa non essere stata la migliore.

Guarda Flickr. Ha iniziato come game multiplayer online, si chiamava The Game Neverending (Il Gioco Infinito). I suoi creatori hanno presto capito che le funzionalità di photo-sharing del gioco erano in realtà un prodotto molto più attraente del gioco stesso (che fu alla fine abbandonato). Sii felice di ammettere i tuoi errori e di cambiare direzione.

Fai come il surfer. Osserva l’oceano. Cerca di prevedere dove si infrangeranno le grandi onde e comportati di conseguenza.



Conclusioni capitolo 16

Avvia i motori

Fatto!

Molto bene, ce l’hai fatta! Spero tu abbia intenzione di utilizzare Getting Real per sviluppare la tua prossima applicazione. Non c’è veramente momento migliore di oggi per iniziare a produrre dell’ottimo software con poche risorse. Con l’idea giusta, la passione, il tempo, e le capacità, il solo limite per te sarà il cielo.

Alcuni pensieri in chiusura:

Realizzazione

Tutti sono in grado di leggere un libro. Tutti possono avere un’idea. Tutti hanno un cugino che fa il web designer. Tutti possono scrivere un blog. Tutti possono reclutare qualcuno per scrivere insieme del buon codice

Ciò che farà la differenza tra te e qualsiasi altra persona sarà la cura che avrai posto nella fase di realizzazione. Il successo risiede tutto in una grande realizzazione.

Nel caso del software, questo significa fare tante cose nel modo corretto. Non è sufficiente che tu sappia scrivere bene, se poi deludi le aspettative contenute nei tuoi testi. Un design pulito non risolverà i tuoi problemi se il tuo codice è troppo complesso. Una grande applicazione è inutile se con una pubblicità inefficace nessuno ne viene a conoscenza. Per fare centro, devi combinare insieme tutti questi elementi.

La chiave è l’equilibrio. Se eccedi in una certa direzione, sei sulla via del fallimento. Ricerca costantemente i tuoi punti di debolezza e concentrati su di essi finché non li hai riportati allo standard abituale.

Persone

E’ importante sottolineare l’aspetto che secondo noi è l’ingrediente principale quando si tratta di costruire un’applicazione di successo: le persone coinvolte. Il mantra, il design epicentrico, meno software, e tutte queste altre magnifiche idee non sono veramente indispensabili se non ci sono a bordo le persone giuste in grado di realizzarle.

Sono necessarie persone appassionate del loro lavoro. Persone che tengono alla propria barca — e veramente considerano la propria attività come se fosse una barca. Persone che sono orgogliose del proprio lavoro, indipendentemente dal ritorno economico. Persone che curano con precisione i dettagli anche se il 95% della gente non si accorge della differenza. Persone che desiderano costruire qualcosa di grande e non si fermano prima di averlo ottenuto. Persone che hanno bisogno di altre persone. Ok, l’ultima non è indispensabile, ma non abbiamo resistito a non citare anche la Streisand. A ogni modo, quando trovi quel tipo di persone, non fartele sfuggire. Alla fine, le persone nel tuo team costruiranno o distruggeranno il tuo progetto — e la tua azienda.

Più di solo software

Non importa che i concetti espressi in Getting Real non siano applicabili solo allo sviluppo di applicazioni web. Quando comincerai a masticare queste idee, le troverai applicate in ogni contesto. Alcuni esempi:

  • I corpi speciali, come i Berretti Verdi o i Seal della marina, usano piccoli team e un dispiegamento veloce per compiere missioni che altre unità, troppo grandi o troppo lente, non sono in grado di svolgere.
  • I White Stripes si basano su questa semplice formula: due persone, canzoni lineari, percussioni elementari, e tempo dedicato allo studio ridotto al minimo, etc.
  • L’iPod di Apple si differenzia dalla concorrenza nel non offrire funzionalità come una radio FM integrata o un registratore vocale.
  • Gli attacchi “Hurry up” nel football conquistano parecchie yard eliminando la “burocrazia” degli ostacoli e delle chiamate di gioco.
  • Rachael Ray basa il successo dei propri libri di cucina e dei propri show televisivi sul concetto di “Consuma Pasti Veri” in 30 minuti.
  • Ernest Hemingway e Raymond Carver utilizzarono un linguaggio semplice e chiaro, eppure ottennero un messaggio di grande impatto.
  • Shakespeare si rivelò nella limitazione dei sonetti, poemi lirici di quaranta linee in pentametro giambico.
  • E ancora e ancora…

Certo, Getting Real riguarda lo sviluppo di grande software. Ma non esiste motivo per cui debba fermarsi qui. Cogli queste idee e cerca di applicarle a diversi aspetti della tua vita. Scoprirai di certo straordinari risultati.

Teniamoci in contatto

Facci sapere come Getting Real è stato utile anche a te. Invia un’email a gettingreal [at] 37signals [dot] com.

Inoltre, rimani aggiornato con le ultime offerte di 37Signals visitando Signal vs. Noise, il nostro blog relativo a Getting Real, usabilità, design, e un mucchio di altre cose.

Grazie di aver letto e buona fortuna!



37signals Resources



Translation

Thanks to the following translators: Matteo Alessani (Extendi Media).

Luca Cremonini and Massimo Sgrelli (Rails on Wave).

Leonardo (Suonerie.it).