Prima rilascia o prima il documento?

Semplice: rilascia una versione beta! Al termine della documentazione, esegui il rilascio finale della nuova versione.

Se hai utenti disposti a provare le nuove cose, allora approfittane a tutti i costi. Riceverai segnalazioni di bug, probabilmente riceverai domande della comunità sui punti difficili per sapere dove concentrarti sulla documentazione, ecc. Potresti anche voler modificare alcune cose sulla base del feedback degli utenti, che potrebbe influire sulla documentazione.

In sostanza, vince tutti.

Un motivo per non rilasciare una versione anticipata è, se pensi che i tuoi utenti non siano recettivi di una "versione beta", allora dovresti pensarci due volte prima di farlo, ma passando da ciò che scrivi, sembra che sarebbero felici a riguardo.

Un altro motivo potrebbe essere, se ci sono difficoltà tecniche nel fare una versione beta usando qualsiasi canale di rilascio che usi. Quindi potrebbe essere più complicato di quanto valga la pena fare beta separate e versioni finali. Se ritieni che il tuo software sia completo, in questo caso mi piacerebbe affidarmi alla versione iniziale, aggiornando la documentazione al termine. Altrimenti c'è il rischio che la documentazione venga ritardata, e quindi l'intera release viene posticipata o si finisce comunque con il rilascio senza la documentazione finale, quindi fallo adesso.

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

Tuttavia, se vieni pagato, o ottieni qualche beneficio, per favore fai ciò che vogliono i tuoi utenti. Ciò significa che qualsiasi cosa sia migliore per i tuoi clienti o utenti , in tal caso, basta rilasciarlo e documentare il tuo tempo. Hai detto che avrebbero trovato la loro strada, 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 è indispensabile , soprattutto se lo sviluppo del software non è un lavoro a tempo pieno. Trascorro molto tempo su questo perché potrei avere grandi intervalli di 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 nella materia in discussione - nel tuo caso sembra che i tuoi clienti possano capire come funzionano le nuove funzionalità. C'è una scuola di pensiero là fuori che sostiene che una buona esperienza utente e una buona interfaccia utente richiedono una documentazione utente minima.

Inoltre, se il tuo tempo è limitato e hai davvero voglia di sviluppare la documentazione come suggerisci, puoi creare un paio di brevi video che introducono solo le nuove funzionalità. Questo ti farà guadagnare un po 'di tempo per scrivere la documentazione vera e poi puoi inserire i dettagli meno importanti.

Alcuni suggerimenti di marketing potrebbero consentirti di bilanciare le aspettative degli utenti e aumentare 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 alla tua nuova versione e all'interno dell'applicazione puoi mostrare i video fornendo link o riproducendo i video all'interno dell'app.

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

La documentazione potrebbe essere il tuo definition of done , ma la documentazione è la maggior parte delle volte al di là di un prodotto minimo vitale (MVP).

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

Il proprietario definisce il valore aziendale (che cosa pensi che sia), quindi cosa c'è di più prezioso come prodotto per i tuoi clienti?

Ci sono anche dei rischi nel rilasciare senza documentazione?

Ad esempio competizione ; Se la competizione rilascia questa super-funzione prima di te, potresti perdere alcuni utenti.

Chiedi 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 cosa hai più bisogno. Hai indicato che la base di utenti era in buona salute, quindi le nuove funzionalità possono attendere. Parlando come un vecchio utente, mi piace anche una buona documentazione. Bella cosa dell'open source: i vecchi utenti aggiungono le proprie caratteristiche.

Non hai chiarito nella tua domanda e probabilmente non ai tuoi utenti le conseguenze di queste scelte. Quanto tempo spendi per il supporto degli utenti? La documentazione aggiuntiva diminuirà la quantità di tempo che spendi per il supporto o per aumentare le vendite? Qual è il vantaggio per te di fare documentazione?

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

Se non mi sono preso la briga di leggere le istruzioni quando tutto ciò che devo fare è inviarti una email con la mia domanda, perché dovrei desiderare la documentazione su nuove funzionalità?

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