Se hai un prodotto che è sul mercato da molto tempo, ma è ancora in sviluppo attivo ogni giorno - quanto spesso dovrebbero essere aggiornati i manuali? Se i tuoi utenti sono costantemente aggiornati alla versione sanguinante, perché la tua organizzazione ritiene opportuno che le correzioni di bug più recenti siano sempre nella versione spedita. Significa che potresti correggere un errore un giorno e il giorno successivo sta colpendo la produzione.
Vorrei aggiornare il manuale:
aggiornare il manuale (PDF) ogni volta che un cambiamento di codice altererebbe le istruzioni del manuale - basta aggiornare la parte manuale del processo di rilascio
se gli utenti si affidano al manuale per dire loro come utilizzare il prodotto e il prodotto cambia, allora è solo un buonsenso che anche le sezioni pertinenti del manuale cambino
Nel 2010 ci riferiamo ancora alla documentazione stampata? Perché? ;)
In tutta serietà, la documentazione (guida in linea "F1", PDF o documentazione online) dovrebbe far parte di ogni singola release. Zero scuse. È così semplice "pubblicare". In realtà, IMO, non ci sono scuse per non aggiornare la documentazione su base regolare (online e PDF), anche tra una release e l'altra, non appena i problemi sono noti e corretti. Non ha bisogno dello stesso livello di QA - nemmeno vicino.
Suppongo che tu stia parlando della documentazione per l'utente finale. Scrivere documenti è un dolore per @ $$ e mentre ho sviluppato alcune tecniche per convincermi dell'inverso, ho ancora problemi con questo. Ecco come cerco di gestirlo:
Integrate the update of the documentation in your DoD (Definition of done)
Ciò garantirà che la tua documentazione sia aggiornata alla fine di ogni completamento della storia utente.
Ecco la definizione di fatto che abbiamo scritto. Ho provato a mantenere le formattazioni originali, quindi ti viene l'idea. È una pagina A4 sulla lavagna.
---------- 8 < ------------ Taglia qui ------------ 8 < ----------
Il non negoziabile
Codice con copertura del test dell'unità dell'80%, commesso nel repository
Schermate applicabili (1024x728, 395x281, 170x121 e 729x329)
Descrizioni delle funzioni, se applicabile (50 caratteri, 100 caratteri)
Documentazione per l'utente finale
Il nuovo file aggiornato correttamente
---------- 8 < ------------ Taglia qui ------------ 8 < ----------
Naturalmente puoi aggiungere un processo di revisione nella documentazione. Abbiamo questo dato che nessuno di noi è madrelingua inglese.
Uno dei vantaggi della definizione di Fatto in questo modo è che il tuo prodotto è potenzialmente spedibile alla fine di ogni completamento della storia utente.
Utilizza questa tecnica in combinazione con questo .
Nella mia organizzazione, di solito abbiamo 3 tipi di versioni:
Per definizione, Major Release deve avere la documentazione pertinente sia online che offline. Il nostro sistema di tracciamento garantisce che la documentazione faccia parte della lista di controllo.
Le versioni minori necessitano di documentazione solo su qualsiasi cosa nuova che sia stata aggiunta al livello di percezione dell'utente. Quindi, se hai incluso un'altra euristica che potrebbe ridurre la complessità del tempo in alcuni scenari specifici, potrebbe essere o non essere una chiamata significativa per inserirlo nel pdf.
Le versioni di ingegneria potrebbero fare a meno della documentazione. Alcune note di utilizzo informale dovrebbero essere sufficienti per iniziare.
La documentazione deve essere sincronizzata con qualsiasi software che si sta spedendo a un cliente. Qualunque altra corrispondenza errata ti darà problemi. E se non hai uno scrittore sul personale, prova gli appaltatori. Una volta trovato quello che ti piace, tienilo fermo.
Leggi altre domande sui tag production manuals