Come si determinano le funzionalità sufficienti per l'avvio? Dovremmo lanciare con la "nuda funzionalità" senza chicche? O dovremmo aggiungere "campane e fischietti"?Determinare quali funzionalità sono sufficienti per il lancio
Come si decide? È vero che possiamo "bruciare" l'esposizione improvvisa, o l'esposizione improvvisa è piuttosto un mito, e l'esposizione è lenta e graduale.
I vostri suggerimenti sono benvenuti.
Se siete abbastanza fortunati da avere una scelta, rilasciate non appena avete una routine di installazione e una singola funzione utile che funzioni.
Rilasciare in anticipo, rilasciare spesso, lasciare che i tuoi utenti ti dica quello che vogliono, guarda 37Signals il poster di ragazzi di piccole dimensioni è bellissimo.
Sono d'accordo, assicurati solo di essere TESTATO! Meglio piccolo con promesse che grandi con bug, e non rispettando la tua parte dell'accordo.
L'aggiunta di BETA al tuo logo non semplifica l'accettazione degli errori.
hai ragione, il test è importante ma solo per i bug del codice, in quanto sviluppatori spesso non abbiamo idea di ciò che gli utenti vogliono, come, hanno bisogno. – MrTelly
Nella mia esperienza, di solito è meglio rilasciare non appena si è lucidato la funzionalità di base. E se una caratteristica è molto importante per un cliente o il pubblico di destinazione, non appartiene più ai fischietti & e dovrebbe essere piuttosto considerata una caratteristica fondamentale, non importa quanto sia facile da implementare o quanto poco si aggiunge al prodotto.
Come la maggior parte le cose, la mia risposta è 'dipende' ...
Qual è lo scopo del vostro software? Se si tratta di un'applicazione rivolta a un gruppo specifico di utenti con esigenze specifiche, è necessario assicurarsi di soddisfare un numero sufficiente di tali esigenze per renderlo utile per le persone a utilizzare il sistema (ricorda, la maggior parte delle persone crede una volta morso, due volte timido non avrò una seconda possibilità). Compreresti una macchina che non girava a sinistra?
Se l'applicazione è più generale, e si sta puntando ad una particolare fetta di utenti da una base più ampia (di solito gli utenti techie) per aiutare a evolvere la vostra applicazione lungo le linee agili, quindi rilasciare presto e spesso. Molti di questi tipi di sistemi non pianificano versioni basate sul tempo, ma su funzionalità, ad esempio la versione 2.1 verrà rilasciata quando tutti i ticket assegnati a 2.1 verranno contrassegnati come completi o eliminati.
Direi anche che dipende dal mercato. Non vorrei rilasciare un prodotto senza una (anche semplice) caratteristica killer. Anche nelle prime versioni, devi creare una certa reputazione.
Ci sono due dogmi di tenersi alla larga:
non rilasciare fino a quando si è finito.
e
di uscita non appena hai qualcosa, non importa quanto piccolo.
Mi piace quest'ultimo approccio, ma deve essere preso con un senso del buon senso. C'è un sovraccarico per qualsiasi versione, a seconda dell'organizzazione e del prodotto.
Non fraintendetemi: rilasciando presto e spesso ha grande vantaggi, in particolare perché non abbiamo mai avuto i requisiti aziendali giusti, ma è necessario ponderare tali benefici rispetto ai costi reali di un rilascio. Questo è uno dei motivi per cui mi piacciono le pubblicazioni interne intervallate dalle versioni "reali": hanno costi inferiori (se non nulli), ma ti fanno progredire onestamente il tuo processo di sviluppo.
Alla fine, credo di finire con la classica risposta del consulente: "Dipende"!
È vero che possiamo "scottarci" di esposizione improvvisa, o l'esposizione improvvisa è piuttosto un mito?
Hai visto le notizie sulla stampa sul lancio di Cuil.com? I loro comunicati stampa lo hanno pubblicizzato come un motore di ricerca che ucciderebbe Google, ma le semplici ricerche hanno prodotto risultati incredibilmente pessimi. (Ad esempio, la ricerca di "COBOL" ti ha detto che non ci sono risultati per COBOL.) L'improvvisa esplosione di traffico dagli annunci ha anche travolto i loro server. Direi che sono stati bruciati dall'esposizione improvvisa che hanno vissuto al momento del lancio.
Alcuni lo chiamano "Hollywood Style" perché è simile al modo in cui vengono lanciati i film. Ci sono alcuni vantaggi in questo stile di lancio che non sempre ottieni da un graduale accumulo di utenti. Tuttavia, la maggior parte di questi benefici sono superati dal fatto che le prime impressioni sono molto importanti e la solita complessità di un prodotto rende molto facile l'insorgere di un bug e dare alla maggior parte dei potenziali utenti una brutta impressione.
La domanda è, lancio cosa?
Se si sta eseguendo software interno, si desidera coinvolgere gli utenti il prima possibile, quindi dare una rapida occhiata ad alcuni di essi è una buona idea.
Se stai facendo open source, rilascia presto e spesso, con una roadmap per lo sviluppo futuro.
Se stai facendo software shrinkwrap, devi dare agli utenti qualcosa di buono per i loro soldi. Non contare sulla possibilità di caricarli per l'aggiornamento che rende davvero utile il software, a meno che non siate una grande azienda consolidata che già lo fa. A meno che tu non sia conosciuta come la fonte principale di questo tipo di software, nessuno ti disturberà di pagarti due volte dopo essere stato bruciato una volta.
Se si stanno eseguendo servizi Web, è necessario avere qualcosa di utile quando si rilascia. Può essere piccolo, ma dovrebbe dare all'utente un motivo per tornare indietro. Altrimenti, è "Foo.com non ha nulla di buono su di esso, non andare lì" anche dopo aver implementato gli elefanti danzanti o qualsiasi altra cosa. Devi lasciare che l'utente si senta bene con il tuo sito e idealmente curioso di vedere cosa farai dopo. Se stai per rilasciare con una spruzzata, assicurati che un sacco di cose funzionino.
Se si sta eseguendo l'embedded, si rilascia quando il software è sufficientemente vicino alla perfezione, e tutti hanno firmato, e non un momento prima.
Sarebbe stata una domanda migliore per http://programmers.stackexchange.com in questi giorni. –