Cerca di convincere il tuo manager o chiunque sia arrivato a tale compito che non è una buona idea scrivere la documentazione per l'utente finale per software che è in uno stato così squallido. Aumenterà persino il debito tecnico perché crei un altro documento che presenterà delle lacune e che contiene errori fin dall'inizio e che deve essere aggiornato con il software.
A lungo termine sarà più economico documentare prima i requisiti del software, definire i casi di test, implementare test automatici e refactoring laddove ha senso. Con requisiti ragionevoli e gestione delle modifiche, sarà molto più facile scrivere la documentazione per l'utente finale e mantenerla sincronizzata con il software.
Se questa non è un'opzione, parla con alcuni utenti chiave e scopri come stanno usando il software, documenta i loro casi d'uso, aggiungi alcuni diagrammi che mostrano i moduli principali del software per quanto è ovvio, incolla alcuni screenshot, spiega i file di input e di output nel miglior modo possibile. Finirai con un documento che sembra almeno una guida per l'utente e potrebbe anche essere utile per un periodo limitato di tempo. Ma assicurati di non essere la persona responsabile della gestione del documento.
In alcuni casi questa è davvero l'opzione migliore perché la documentazione per l'utente finale ha una priorità molto bassa dal punto di vista del business in molti progetti software. Questo perché tende ad avere poca influenza sul successo del progetto.