Share
Faccio parte del team che ha recentemente lanciato un'app Web chiamata Dunked. Dunked è un portfolio online gratuito e semplice da usare per i tipi di creatività. A partire da maggio 2013, siamo in beta pubblica; continuare a costruire funzionalità e apportare miglioramenti incrementali in base al feedback degli utenti.
In questo articolo, ho intenzione di discutere alcune delle ragioni per cui credo che un lancio beta sia importante per lo sviluppo del tuo prodotto. Discuterò anche su come noi, a Dunked, stiamo seguendo il processo di monitoraggio e raccolta dei feedback degli utenti. Infine, discuterò di come sono state implementate le modifiche in base al feedback degli utenti mentre continuiamo a sviluppare il prodotto.
Personalmente ritengo che avere un lancio beta sia davvero una grande idea. Naturalmente, è sconsigliabile rilasciare qualcosa che è pieno di bug. È anche una cattiva idea rilasciare un prodotto che non è pronto per il consumo pubblico. È molto meglio rilasciare il prodotto una volta che ha le funzionalità di base necessarie ed è privo di bug.
Google è probabilmente una delle aziende più conosciute che inizialmente offre prodotti in versione beta. Gmail è un grande esempio. Gmail era in beta privata da aprile 2004 a febbraio 2007, quando è stato reso disponibile al grande pubblico. Anche allora, aveva ancora l'etichetta "beta". Gmail non è stato ufficialmente eliminato dalla beta per altri due anni. Avendolo come prodotto beta, i tecnici di Google hanno potuto continuare a migliorare Gmail basandosi sui dati degli utenti e testare varie aggiunte.
Perfetto non esiste nello sviluppo del software
Riconosco che può essere difficile far vedere agli utenti un prodotto prima che tu creda che sia perfetto. Ma il perfetto non esiste nello sviluppo del software. Avrai sempre bisogno di iterare su un prodotto in uno sforzo costante per apportare miglioramenti. Credo che rilasciando una versione beta di un prodotto, ti metti in grado di offrire agli utenti ciò che vogliono. Potresti avere delle supposizioni semplicemente sbagliate. Operando in versione beta, puoi rapidamente orientarti per migliorare il tuo prodotto in base alle esigenze degli utenti.
Nel portare Dunked al varo, abbiamo ritenuto che fosse di fondamentale importanza identificare e stabilire le differenze tra le funzionalità indispensabili e le funzionalità carine. Le funzionalità indispensabili sono le funzionalità che modellano e, in sostanza, rendono il tuo prodotto. I must-have sono le caratteristiche su cui si dovrebbe focalizzare il tempo prima del lancio. Una volta completata la lista dei must have, avvia. Dopo il lancio, puoi affrontare i simpatizzanti, correggere eventuali bug che si presentano e apportare modifiche in base al feedback degli utenti.
Mentre continuiamo a costruire, il feedback degli utenti è come l'oro. Gli utenti ci dicono quando stiamo facendo grandi cose; quando stiamo facendo le cose sbagliate; e quando siamo semplicemente stupidi. Poiché il feedback degli utenti è così prezioso, è importante disporre di un sistema prima del lancio in modo da poter monitorare e raccogliere feedback. Devi anche stabilire un sistema per agire sul feedback che ricevi.
Monitorare e raccogliere feedback non è un compito facile. Gli utenti sono tutti diversi, con diverse preferenze nel modo in cui esprimono le loro opinioni. Pertanto, è necessario disporre di un sistema per monitorare attivamente una varietà di canali di feedback. Abbiamo scelto di utilizzare Desk. Serve da hub centrale per raccogliere tutti i tweet diretti al nostro handle Twitter @ DunkedHQ, i commenti sulla nostra pagina Facebook e le e-mail inviate tramite il nostro modulo di contatto per l'assistenza (questo modulo è collegato dall'app stessa). Mi consente di accedere a una singola sede, dove posso esaminare e rispondere al feedback nell'ordine in cui è stato inviato. Questo è un vantaggio per noi e per gli utenti. Gli utenti possono esprimere le loro opinioni, tuttavia si sentono più a loro agio e possiamo facilmente accedere a tutti i feedback in un'unica posizione.
Che gestisce gli utenti attuali, ma per quanto riguarda le persone che cancellano i loro account senza offrire alcun feedback. Sappi che gli account saranno chiusi e fai del tuo meglio per raccogliere informazioni dagli utenti che chiudono i loro account. A Dunked, indirizziamo l'utente a un rapido "exit" sondaggio una volta che hanno completato il processo di cancellazione dell'account. Il sondaggio è completamente opzionale e può essere completato in meno di cinque minuti. La maggior parte delle persone è stata disposta a completarlo, fornendoci ulteriori feedback sul motivo per cui ha cancellato il proprio account. Abbiamo usato Wufoo per gestire le nostre esigenze di sondaggio perché rendono davvero facile.
Ora che abbiamo un metodo per monitorare e raccogliere feedback, cosa dovremmo fare con esso? Per Dunked, abbiamo un approccio piuttosto semplice. Usiamo un elenco di cose da fare all'interno di Basecamp per ospitare il feedback che raccogliamo. Ogni volta che un utente scrive con un miglioramento suggerito o richiede una funzionalità mancante, lo aggiungiamo alla nostra lista di cose da fare nella Lista dei desideri / Suggerimenti. Questa lista contiene anche le nostre simpatiche funzionalità. Non tutti gli elementi aggiunti all'elenco verranno aggiunti a Dunked, ma ci aiutano a monitorare i suggerimenti. Le richieste di funzionalità comuni sono annotate, spostate in cima all'elenco e sono spesso incluse nei nostri sprint di codice, che discuterò più avanti.
Sfortunatamente, la piattaforma Dunked non è stata perfetta, quindi occasionalmente riceviamo segnalazioni di bug. Manteniamo una lista di bug separata anche all'interno di Basecamp. Qualsiasi elemento aggiunto all'elenco dei bug è considerato una priorità assoluta e viene risolto il più rapidamente possibile.
Come ho già detto, stiamo continuando a sviluppare funzionalità di base per Dunked, ma riteniamo che sia importante agire in base al feedback fornito dai primi utenti. Poiché gli utenti sono stati così bravi a fornirci feedback, vogliamo implementare i loro suggerimenti nel tempo. Lo facciamo attraverso gli sprint di codice giornalieri. Una o due volte alla settimana, esamineremo la nostra lista di suggerimenti / suggerimenti e selezioneremo alcuni elementi che possono essere completati in un solo giorno di codifica. Completiamo questi articoli, testiamo sul nostro server di sviluppo e poi passiamo al server di produzione una volta che siamo soddisfatti del codice.
Per illustrare come Dunked ha migliorato il feedback degli utenti, considera il seguente esempio. Per i caricamenti di immagini, abbiamo creato un semplice pulsante clic per caricare. Facendo clic sul pulsante è stato avviato il browser di file sul computer dell'utente, consentendo loro di cercare e caricare immagini per i loro progetti. Ha funzionato perfettamente per noi. Gli utenti, tuttavia, hanno avuto alcuni problemi.
Esistono due opzioni di base su come gestire i caricamenti di immagini: fare clic per caricare o trascinare per caricare. A quanto pare, noi (Team Dunked) preferiamo fare clic per caricare. Non immaginavamo che gli utenti volessero caricamenti con trascinamento della selezione. Nel raccogliere feedback, è diventato evidente che abbiamo avuto margini di miglioramento nei caricamenti di immagini. Abbiamo aggiunto "Caricamenti drag-and-drop" alla nostra lista Lista dei desideri / suggerimenti. Dopo varie richieste, i caricamenti con trascinamento della selezione sono stati aggiunti a uno dei nostri primi sprint di codice. Ora quando vuoi caricare le immagini su un progetto, puoi fare clic per caricare o trascinare la selezione.
Questo è un esempio piuttosto semplice di come gli utenti usavano Dunked in modo diverso da come immaginavamo. Non abbiamo mai pensato che gli utenti sarebbero stati scoraggiati dal nostro metodo tradizionale di upload di immagini. Nel monitorare, raccogliere e agire in base al feedback degli utenti, tuttavia, siamo stati in grado di migliorare Dunked per i nostri utenti.
Ora che ho spiegato un po 'del nostro approccio a una versione beta e perché penso che le versioni beta siano grandi, devo discutere alcuni degli errori e delle limitazioni che potrebbero affliggere una versione beta. L'errore più grande che si potrebbe fare in una versione beta è di rilasciare una beta prima che sia pronta. Se incontri dei bug nei tuoi test o se non hai eseguito una serie completa di test sulla tua applicazione, non hai alcun business in beta. Quando rilasci software che sai non è pronto per il rilascio, stai rischiando la fiducia dei tuoi utenti e la vita del tuo prodotto. Mentre la maggior parte degli utenti beta è disposta a perdonare bug minori che si presentano in versione beta, rilasciare un prodotto che si sa essere bacato è irresponsabile.
Quando rilasci software che sai non è pronto per il rilascio, stai rischiando la fiducia dei tuoi utenti e la vita del tuo prodotto.
Il secondo più grande errore che potresti fare in una versione beta è quello di far entrare gli utenti troppo velocemente. Mentre puoi eseguire stress test, non saprai al 100% cosa può gestire il tuo server fino a quando non viene sottoposto a un vero test. Se il server si arresta in modo anomalo, si desidera arrestarlo con 1.000 inviti beta e non 10.000 o 100.000 inviti beta in sospeso. Inoltre, sei in versione beta, quindi è possibile che ti imbatti in un bug o due. Con Dunked, ad esempio, abbiamo avuto un bug strano relativo a determinati slug di progetto. Tutto ha funzionato bene con l'amministratore, ma la pagina live ha provocato un errore 403. Si è rivelata una soluzione molto semplice. Ma poiché il problema riguardava gli URL, dovevamo correggere gli slug URL esistenti. È stato sicuramente più facile cercare e rimediare a centinaia di slug di progetti e pagine rispetto a centinaia di migliaia.
Uno dei maggiori limiti di una versione beta è legato al feedback. Concedere agli utenti l'accesso beta, non significa che ti forniranno un feedback. Gli utenti possono pienamente intendere nel fornire feedback, ma semplicemente non hanno il tempo di mettere il loro feedback in parole. Potrebbero anche sentirsi dire che stanno facendo qualcosa di sbagliato, quando l'applicazione non funziona come previsto, e quindi non ti scrivono con feedback. Inoltre, se devi eseguire un'iterazione su un determinato componente all'interno dell'applicazione, le probabilità sono che la qualità e la quantità del feedback stiano per diminuire.
Non credo che non sia saggio cercare di includere ogni singola funzione desiderata all'avvio di un prodotto. Penso che tu stia meglio lanciando una versione beta "completata", e poi continuando a scorrere il prodotto, aggiungendo funzionalità aggiuntive. In tal modo, sarai in grado di raccogliere e utilizzare il feedback degli utenti per migliorare il tuo prodotto.
Detto questo, devi avere un piano in atto su come monitorare, raccogliere e agire sul feedback che raccogli. Pertanto, sarai in grado di aggiungere funzionalità che creano valore reale per l'utente, migliorando le tue possibilità di successo.
Accentsconagua