Startup: UX vs. Implementazioni rapide
Una startup, per definizione, è un'entità con risorse limitate. Queste risorse potrebbero essere budget, tempo, talento o qualsiasi cosa relativa, ma ciò che è certo è che esiste effettivamente una qualche forma di limitazione delle risorse - altrimenti non sarebbe una start-up.
È per questo che molti stili di gestione sono stati provati e testati in battaglia per affrontare la sfida che sta lanciando e correndo una di queste bestie di tempo ed energia. E nel corso degli anni sembrano esserci due scuole di pensiero indipendenti che sono emerse nel mercato: il lancio snello e il grande accumulo.
Il lancio snello coinvolge aspetti come processi di sviluppo agili, test degli utenti, convalida di idee, programmazione mirata, sviluppo guidato dal comportamento e molti altri. Poi, d'altra parte, hai la grande build prima del lancio: in questo modello si sprecano tonnellate di tempo e gli sviluppatori in un progetto per assicurarsi che sia completo prima che un singolo cliente lo veda una volta.
Queste due scuole di pensiero hanno ciascuno i loro vantaggi e svantaggi come si potrebbe immaginare, e ognuna di esse ha dirigenti che credono in esse in misura quasi cruda. Attraverso questo articolo, potremmo scoprire quali non sono testardi e quali sono. Oppure potremmo trovare qualcosa di sorprendente. Tuffiamoci dentro
Avere un'esperienza utente raffinata
Ammettiamolo, il design è molto importante. In effetti, il design è così importante che ha quasi completamente superato alcuni processi delle startup. Focalizzano tutto il loro tempo e le loro energie sull'esperienza utente, e arrivando a una funzionalità completa dichiarano di avere poco tempo per qualsiasi altra cosa - e forse giustamente. Ora, l'altra parte non direbbe che è la strada giusta, ma lasceremo questa discussione per dopo. Per ora, stiamo parlando del mondo di un UX lucido e di un set di funzionalità prima del lancio.
Il lato positivo di un UX raffinato
Sfruttando la marca completa
Il branding è un argomento enorme, ed è proprio per questo motivo che sembra che le persone sentano il bisogno di lavorare in questo modo. Sentono che se stanno per lanciarsi dovrebbero lanciare con tutto ciò che il loro marchio rappresenta, essendo stati integrati nel sito fin dal primo giorno. Il classico, "v1 dovrebbe essere completo di funzionalità" è qualcosa che ho sentito spesso dai manager. E dietro c'è un buon ragionamento. Non vogliono che il loro sito web rifletta ciò che non sono, e qui sta la parodia. Otterremo di più in questa sezione dei contro, ma questo può portare a un serio insinuarsi delle funzionalità. Il mio motto è, se stai camminando in uno spazio in cui ci sono concorrenti che sono marchiati forse più pesantemente di qualsiasi altro spazio online (pensi: Dropbox o Apple), allora potresti prendere seriamente in considerazione questo, perché in quel caso il marchio sarà molto importante. Tuttavia, si può sposare un lancio snello con una tecnologia favolosa e un bel marchio, tutto in uno - di cui parleremo più avanti.
Ricevere un interesse immediato
Un altro aspetto positivo del lancio raffinato e raffinato è che può attrarre più utenti in anticipo grazie al design fantastico e all'assistenza completa fornita all'intero prodotto. Almeno, questo è ciò che amiamo assumere. Realisticamente, però, può anche essere una barriera per entrare. Ho visto utenti che ritengono che un prodotto sia troppo grande o che abbia troppe funzionalità per ottenere una sensazione di "bisogno" quando si tratta di usarlo, e rimbalzeranno dal sito in meno di un minuto. Accade tutto il tempo, ed è fin troppo triste onestamente. Detesto vedere le idee di un imprenditore o anche di un manager essere risucchiato dai tubi a causa della caratteristica di strisciamento troppo frequente. Sebbene accada, non impedisce agli imprenditori di sentire che l'interesse aumenterà di dieci volte se completano il loro prodotto interamente prima del lancio. Questo è un grande.
Essere feature complete
Se lo fai in questa fase e stai vivendo in questo campo, allora a questo punto sei più che probabile che la funzione sia completa. Ne abbiamo parlato un po 'finora nelle sezioni precedenti, ma qui è dove diventa interessante. Molto, e intendo che molte start-up sentono di dover essere complete di funzionalità prima di poter caricare o avere un impatto per quella materia. Non sto dicendo che non vi sia alcun merito a tale argomento, ma penso che sia stato esagerato nel corso degli anni. Dal mio punto di vista e da quello che ho visto nel corso degli anni, puoi semplicemente chiedere se gli utenti paghino per un prodotto prima di arricchire l'intera faccenda. Ora, diciamo che eri gung-ho dell'essere una funzione completa, e in effetti volevi tutto. Bene, potresti lanciare una versione molto minimale di ogni funzione. Qualcosa che rappresenta le caratteristiche in questione, o forse anche i video di quelli mancanti. Tieni presente che ci sono modi per essere completi di funzionalità senza essere effettivamente lì.
Lo svantaggio di un UX raffinato
Caratteristica creep
Questo è un errore comune quando si tratta della UX levigata e l'approccio completo all'avvio di una start-up. E questo è ciò che chiamiamo una situazione chiamata spirale mortale della caratteristica creep. I gestori o i proprietari sentiranno la necessità di aggiungere sempre più funzionalità al prodotto mentre completate gli altri, finché non ci sarà letteralmente nulla da fare se non aggiungere ulteriori funzionalità. In alcuni casi è un ciclo senza fine e, in particolare, nei casi in cui non sono state stabilite linee guida o specifiche rigide .
Sviluppo delle cascate
Lo sviluppo delle cascate è una truffa a sé stante, e non senza polemiche. Un tipico flusso di lavoro a cascata si presenta così: idea, progettazione, sviluppo, test, manutenzione. Ci sono alcune persone che prosperano in un tale ambiente, ma almeno un numero uguale lo trova assolutamente dannoso. O è un processo abbastanza standard che sembra molto normale per molti di noi, e tuttavia per idee che presto diventeranno evidenti può spesso essere dannoso per la spedizione di un prodotto.
La ragione non è necessariamente nel modello di sistema stesso, è nel fatto che ci sono team separati che svolgono un lavoro, ognuno dei quali è gestito da singoli gestori. Ad esempio, un flusso tipico può assomigliare a questo: un'idea del fondatore / imprenditore; assume un team di progettazione e sviluppo e forse manager o direttori creativi per ogni squadra; l'idea viene passata al design, per creare prototipi, quei prototipi diventano documenti di Photoshop che vanno avanti e indietro con il proprietario e il direttore creativo fino a quando non sono perfetti; quindi, senza alcun consenso su ciò che è persino possibile, viene trasmesso allo sviluppo per essere creato; e dopo aver fatto avanti e indietro con il responsabile del team di sviluppo, il proprietario e forse anche il direttore creativo, trovano un punto d'incontro e terminano il prodotto.
Ciò che non ho menzionato, però, è che ognuno di questi passaggi implicava probabilmente 50-100 e-mail individualmente, e questa è una stima prudente (molto conservativa). Come puoi vedere, non è molto efficiente, perché in qualsiasi momento il proprietario e il fondatore potrebbero aggiungere ulteriori lavori che non erano nel piano o cambiare le cose. Il micromanaging spesso non è l'opzione migliore quando si tratta di sviluppo di software, eppure il sistema a cascata sembra prosperare in uno stile di gestione del genere.
Tenetelo sempre a mente, e se non si lavora bene con la microgestione, allora fai sapere al tuo capo. Ricorda, è sempre meglio essere onesti e onesti riguardo a un possibile futuro improduttivo piuttosto che scendere su quella strada essendo in realtà improduttivo. E ricorda anche che ci sono più tipici problemi di micro-gestione tutti in cantiere per questo sistema; dalla mia esperienza personale non è l'ideale.
Allora, qual è l'ideale? Beh, questo è soggettivo, ma posso dirvi che, nella mia esperienza, la capacità di lanciare rapidamente e iterare i tempi del ciclo ha dato a me e ai miei team la possibilità di spedire una quantità maggiore di prodotti di quanto potremmo mai avere con Waterfall. Allora, qual è questo misterioso sistema magico di prodotto di spedizione?
Implementazioni rapide e avvio magro
L'avvio snello è qualcosa che, secondo me, ha rivoluzionato la nostra comunità. Questo è principalmente dovuto al fatto che si basa su qualcosa chiamato ciclo di feedback delle misurazioni di apprendimento-costruzione.
L'arte del lancio rapido - spesso può essere una semplice pagina che chiede se gli utenti dovrebbero pagare per questo, o può essere un prodotto nudo - è qualcosa che le persone hanno perfezionato nel corso degli anni, e come mi sento più radicato nel nostro mondo della tecnologia, sento che è sempre più importante.
La cosa importante qui è l'accettazione e la convalida del mercato. Una domanda chiave: chi dice che il codice che stai scrivendo è significativo? Viviamo in un giorno ed età in cui le persone davvero non possono sprecare una sola oncia del loro tempo prezioso. È un momento in cui si fa o si rompono gli atteggiamenti, si va alla grande o si torna a casa mentalità. È un momento in cui la realtà ci colpisce ogni giorno in faccia quando non possiamo comprare cibo o permetterci un affitto, ed è per questo che è tanto più importante accertarsi che non si stia perdendo codice per qualcosa che nessuno userà.
Non devi essere un genio del marketing, ma devi capire uno stato d'animo sperimentale. Lo stato costante di beta è una metafora brillante a questo. Non dovremmo mai essere coinvolti nel nostro orgoglio così tanto che non possiamo nemmeno cambiare un elemento in un progetto. Dobbiamo ricordare che la vita è sperimentale, e prima lo capisci meglio è e non c'è modo migliore che con l'avvio snello.
Il lato positivo della start-up snella
Feedback degli utenti
Usare un metodo come questo è qualcosa di simile a essere raccontato su un titolo prima che si sviluppi. Questo è un ottimo modo per ottenere informazioni sul tuo target demografico principale e per ottenere la convalida prima di perdere tempo.
Ecco come lo fai. Ottieni una pagina di destinazione e mostra ciò che il tuo prodotto o servizio fa in un modo molto bello ed esplicativo. Spendi un po 'di soldi su questa parte se vuoi, perché è il più importante. Quindi metti una semplice registrazione con il tuo indirizzo email se ti interessa. Fatto. Ora, potrebbe non sembrare che tu stia facendo molto, ma stai facendo molto nella realtà. Stai convalidando un intero mercato del prodotto o mercato dei servizi con una pagina. Non stai spendendo mesi e migliaia di dollari per costruire qualcosa di inutile che nessuno userà, stai semplicemente creando una cosa per scoprire se ne vale la pena.
Ci sono state persone che lanciano 5 pagine di servizio simili a quello che ho appena detto, e quelle su cui ottengono il maggior numero di feedback, sono quelle con cui vanno avanti. È un atto brillante e può essere visto come un investimento in molti modi. Stai ricevendo utili sul tuo investimento e, in caso contrario, stai uscendo dal mercato prima di perdere molti potenziali guadagni. Penso che Warren Buffet lo amerebbe.
Cicli di iterazione più rapidi
Una delle cose migliori di fare lo sviluppo del prodotto in modo snello è che spesso scopri che i tuoi cicli di iterazione sono molto più veloci e in alcune aziende spediscono il codice più di 20 volte al giorno. C'è molta filosofia dietro questo, per esempio come su Facebook quando un nuovo ingegnere viene portato a bordo vengono dati 5 bug fix nella loro e-mail di benvenuto il primo giorno. Un sacco di ragionamenti dietro a cose come questa è che se hai il tuo sistema configurato in modo tale da rompersi ogni volta che un nuovo dipendente viene a bordo, allora non sono loro che il tuo sistema è rotto.
Sviluppo agile
In sostanza, lo sviluppo agile passa da una piccola cosa all'altra il più rapidamente possibile. Quindi ti sposti da ogni sprint allo sprint successivo, che viene spesso definito da una User story e che è semplicemente un utente sul tuo sito che desidera un po 'di funzionalità. È molto simile al testing in Rails o in altri framework, dato che stai facendo tutto il necessario e niente di più. Si può risparmiare un sacco di tempo facendo lo sviluppo in questo modo.
Il rovescio della medaglia di start-up
Un piccolo inconveniente che può accadere quando si è utenti dello sviluppo agile e del sistema di avvio snello è che il sito potrebbe cambiare nel corso del tempo. Ora, idealmente ciò potrebbe accadere a causa della richiesta di un utente, ma potrebbe comunque essere sconveniente per alcuni utenti.
Quindi, farlo con classe ed eleganza è importante. Soprattutto se si tratta di un prodotto a cui tengo. Non sradicare la base di utenti di base del prodotto come ha fatto Digg v4, ma invece fornire dettagli su ciò che si sta facendo e perché, e se tutto il resto fallisce il rollback.
Assicurati sempre di usare qualcosa come git o subversion per salvare le versioni del tuo prodotto. In effetti, lo faccio come rami, in modo che possiamo sempre tornare indietro se necessario.
In conclusione
Se la tua startup è così tecnologicamente avanzata che non ha importanza, vai con il lancio rapido. Alla gente interesseranno i cambiamenti tecnologici che stanno vedendo. Tuttavia, se si gareggia in uno spazio con una forte competizione, forse una combinazione di entrambi è la migliore. In breve, fai sempre il meglio che puoi con UX raffinato, ma fallo in brevi scatti.