Rilasciare prima o documentare prima?

Lavoro a un progetto da un paio d'anni e sto iniziando a raccogliere una base di utenti decente. Ho creato una pagina di progetto con alcuni documenti di base, ma a questo punto in realtà non è molto più di una FAQ. So che devo migliorarlo in modo che sia più informativo sia per i nuovi utenti che per gli utenti esperti, e questo è il prossimo nella mia lista di cose da fare per la prossima versione.

Tuttavia, la prossima versione ha caratteristiche che la base di utenti è ansiosa di ottenere. Sono pronto a rilasciarlo in questo momento, è confezionato e pronto per l'uso. Devo solo distribuirlo ai servizi di distribuzione appropriati.

Al punto. Le funzionalità sono importanti per i miei utenti, ma la documentazione è importante per me. Devo attendere il rilascio fino a dopo aver riscritto la documentazione? La mia attuale base di utenti è abbastanza esperta da capire come utilizzare le nuove funzionalità, quindi non è questo che mi preoccupa. Potrebbero volerci un paio di settimane per finire i documenti, dato che ho poco tempo libero per lavorare a questo progetto, ma la comunità mi arrostirebbe allo spiedo se li facessi aspettare ancora.

Il cliente ha ragione in questo scenario? Una funzionalità fantastica e diretta per gli utenti esistenti dovrebbe avere la priorità su una solida documentazione per i nuovi utenti?

Aggiornamento: Wow, tante risposte fantastiche e di alta qualità! Mi hai davvero aiutato a capire meglio come dovrei interagire e supportare sia il progetto che i suoi utenti. Grazie mille!

Semplice: rilascia una versione beta! Quindi, al termine della documentazione, eseguire la versione finale della nuova versione.

Se hai utenti disposti a provare le nuove cose, allora approfittane. Riceverai segnalazioni di bug, probabilmente riceverai domande della community sui punti difficili in modo da sapere dove concentrarti sulla documentazione, ecc. Potresti anche voler modificare alcune cose in base al feedback degli utenti, che potrebbe influire sulla documentazione.

Fondamentalmente, vincono tutti.

Un motivo per non fare la versione anticipata è, se pensi che i tuoi utenti non saranno ricettivi a una "versione beta", allora dovresti pensarci due volte su come farlo, ma seguendo ciò che scrivi, sembra che ne sarebbero contenti.

Un altro motivo sarebbe, se ci sono difficoltà tecniche nel fare una versione beta usando qualsiasi canale di rilascio che usi. Quindi potrebbe essere più seccante di quanto valga la pena fare versioni beta e finali separate. Se ritieni che il tuo software sia completo, in questo caso mi affiderei alla versione anticipata, al termine aggiornerò la documentazione. Altrimenti c'è il rischio che la documentazione venga ritardata, e quindi l'intera versione venga ritardata o alla fine rilasci senza documentazione finale, quindi fallo ora.

Se ti ho capito bene, stai facendo questo progetto nel tuo tempo libero e senza soldi . In questo caso, per favore, fai ciò che ti fa sentire meglio (gli utenti attendono, documenta il tuo tempo). Non dovresti sentire la pressione dei tuoi "utenti". Molte persone hanno scritto di questo su Internet (autori e collaboratori di FLOSS di grandi dimensioni che hanno sentito la pressione).

Ma, se vieni pagato o ricevi dei benefici, ti preghiamo di fare quello che vogliono i tuoi utenti. Questo significa fare tutto ciò che è meglio per i tuoi clienti o utenti , in tal caso, basta rilasciarlo e documentare sul tuo tempo. Hai detto che si sarebbero orientati, quindi non dovrebbe essere un grosso problema.

In generale ci sono due tipi di documentazione: la tecnica che documenta il tuo codice (classi, unità, ecc.) E come le nuove funzionalità possono funzionare e essere implementate nel codice e nella documentazione dell'utente. IMO, la documentazione tecnica è un must soprattutto se lo sviluppo del software non è il tuo lavoro a tempo pieno. Trascorro molto tempo su questo in quanto potrei avere grandi lacune nella scrittura del codice a causa di impegni di vita.

La documentazione per l'utente è buona da avere ma non essenziale credo. Naturalmente dipende dalla complessità dell'applicazione, dalla familiarità della base di utenti con l'uso di computer e sistemi nell'area tematica in discussione - nel tuo caso sembra che i tuoi clienti possano avere la comprensione di come funzionano le nuove funzionalità. Esiste una scuola di pensiero che sostiene che una buona esperienza utente e una buona interfaccia utente richiedono una documentazione minima per l'utente.

Inoltre, se il tuo tempo è limitato e senti davvero la pressione di sviluppare la documentazione come suggerisci, puoi realizzare un paio di brevi video che introducono solo le nuove funzionalità. Questo ti richiederà del tempo per scrivere la documentazione effettiva e quindi puoi compilare i dettagli meno importanti.

Alcuni suggerimenti di marketing possono consentire di bilanciare le aspettative degli utenti e migliorare ancora il tuo marchio. Dipende molto dal tipo di applicazione e dal flusso di lavoro che hai creato finora, ma potresti avere una schermata di benvenuto nella tua nuova versione e all'interno dell'applicazione puoi mostrare i video fornendo collegamenti o riproducendo i video all'interno dell'app.

Solo per aggiungere qualcosa non solo per questo esempio specifico ma per il flusso di lavoro generale:

La documentazione potrebbe essere tua definition of done, ma la documentazione è per lo più al di là di un prodotto minimo sostenibile (MVP).

Non solo il cliente ha sempre ragione. Se si tratta di un prodotto commerciale, il rilascio potrebbe essere un valore molto business ed è una priorità assoluta.

Il proprietario definisce il valore commerciale (che secondo te), quindi cosa ha più valore come prodotto per i tuoi clienti?

Inoltre ci sono dei rischi nel rilascio senza documentazione?

Ad esempio la concorrenza ; Se la competizione rilascia questa super funzionalità prima di te, potresti perdere alcuni utenti.

Poni a te stesso o al proprietario del prodotto queste domande e la tua risposta sarà chiara.

Le nuove funzionalità rendono felici i vecchi utenti. Una buona documentazione invita i nuovi utenti. Su cosa dovresti concentrarti dipende da quale hai più bisogno. Hai indicato che la base utenti era integra, quindi le nuove funzionalità possono attendere. Parlando da vecchio utente, mi piace anche una buona documentazione. Cosa bella dell'open source: i vecchi utenti aggiungono le proprie funzionalità.

Non hai chiarito la tua domanda e probabilmente non ai tuoi utenti le conseguenze di queste scelte. Quanto tempo dedichi al supporto degli utenti? La documentazione aggiuntiva ridurrà il tempo che dedichi all'assistenza o aumenterà le vendite? Qual è il vantaggio per te di fare documentazione?

I tuoi utenti desiderano nuove funzionalità rispetto alla documentazione, ma si rendono conto che potrebbe esserci una diminuzione della tua disponibilità per fornire supporto, correggere bug, rilasciare patch, ecc.?

Se non mi preoccupassi di leggere le istruzioni quando tutto ciò che devo fare è inviarti un'e-mail con la mia domanda, perché dovrei mai desiderare la documentazione sulle nuove funzionalità?

Se il pacchetto è pronto per il rilascio, rilasciare al cliente / client e iniziare a lavorare sulla documentazione. È bene comunicare al client, quando condividerai la documentazione che li aiuta a comprendere le funzionalità distribuite.