Oggi vi segnalo un ottimo articolo di TCWorld in cui viene schematizzato un processo per la verifica della qualità di un Manuale d'Installazione (Quality Assurance (QA) process).
Nell'articolo viene posto l'accento su diversi aspetti che concorrono ad elevare la Qualità di un documento, ed emergono due concetti principali:
- le attività di editing e proofreading di un documento non possono essere marginalmente relegate al termine della scrittura del medesimo, ma devono essere integrate all'interno del processo di sviluppo dello stesso;
- la Qualità di un documento non attiene esclusivamente alle suddette attività, ma può dipendere da molti altri fattori che vanno presi in considerazione.
Giorno dopo giorno, dovendo realizzare documenti spesso molto complessi e voluminosi (da 100-150 fino anche a 300-400 pagine), lo schema classico "prima scrivo poi faccio editing", semplicemente NON FUNZIONA.
E' probabile che molti di voi, seguendo dei corsi di scrittura, abbiano acquisito l'idea che "la fase di editing va separata nettamente dalla fase di scrittura di un testo". Verissimo. Quando si tratta di un articolo di 800 parole, di una relazione di 15-20 pagine, di un qualsiasi scritto che si presenti come un oggetto di "dimensioni limitate" e con una struttura "lineare", cioè un documento sostanzialmente SOLO TESTO, non arricchito da grafici, tabelle, navigabilità interna, note redazionali specializzate ed altro ancora.
Un documento tecnico non è mai (e se lo è, probabilmente è un ben povero documento) un documento solo testo e difficilmente è un oggetto di dimensioni ridotte.
Quindi, le attività di editing e proofreading, essenziali per ottenere un livello di qualità adeguato, devono essere messe in opera DURANTE lo sviluppo del testo, fin dall'inizio.
L'autore dell'articolo Markus Nickl (che scrive anche su questo blog) mette in particolare evidenza due elementi.
Il primo riguarda l'uso di una checklist per definire le fasi cruciali di un processo di editing.
Nella sua checklist vengono individuate 7 aree e per ognuna di esse vengono esplicitati alcuni requesiti che devono essere soddisfatti.
Questo tipo di checklist possono essere utilizzate durante l'intero sviluppo del documento. Ad esempio, al termine di ogni capitolo, si possono verificare i requisiti (Test questions) limitatamente a quel singolo capitolo.
Quando sarete arrivati al termine del manuale, dovrete ri-applicare la checklist all'intero documento, ma molto probabilmente almeno l'80% dei problemi di editing li avrete già risolti nelle revisoni precedenti sui singoli capitoli e quindi la revisione finale sarà particolarmente rapida.
Il secondo elemento riguarda la possibilità di "parallelizzare" il lavoro di editing.
Se sono capace di individuare delle aree specifiche, posso decidere che mentre io mi occupo, ad esempio, dell'area Structure and Organization, il mio collega grafico si occupa delle Pictures mentre il tecnico che ha sviluppato il prodotto porrà maggior attenzione all'area Contents.
In questa modalità di "editing cooperativo" si riducono drasticamente i tempi di realizzazione del processo in esame; anche in questo caso, inoltre, l'editing cooperativo potrebbe essere messo in atto durante lo sviluppo del documento, in diversi stati d'avanzamento, o solo al termine.
L'attività di proofreading, necessaria, sacrosanta e tradizionalmente effettuata al termine della fase di editing, può anch'essa essere applicata "in corso d'opera", in special modo se dobbiamo operare su documenti molto voluminosi, di 400-500 o più pagine.
Tenete poi sempre presente che il proofreading è un'attività che non esaurisce il processo di QA, come si tende invece a pensare sulla base delle regole tradizionali di scrittura.
Un esempio? Una volta che avete completato il vostro lavoro di editing e proofreading e siete riusciti a sfornare il vostro documento tecnico, siete sicuri di aver rispettato tutte le regole di conformità che bisogna rispettare per il Manuale d'Installazione DI UN CERTO DISPOSITIVO, rispetto alle regole stabilite DALLA LEGGE DEL PAESE in cui quel dispositivo verrà commercializzato?
La conformità alle normative di settore è uno degli aspetti della QA di un documento tecnico che spesso non viene sufficentemente considerato.
Per chi volesse approfondire, ecco una selezione dei post che ho scritto su questo argomento:
Una check-list per l'analisi di un testo
Revisione di un testo: attenti al Diavolo!... o ai particolari...
La Qualità non è un pranzo di gala
La Qualità della documentazione tecnica: la Leggibilità
La Qualità nella documentazione tecnica: lo scalpello di Michelangelo...
La Qualità è un Processo: un esempio (prima parte)
2 commenti:
Grazie mille per questo utilissimo ed interessantissimo post Alessandro.
Mi piacerebbe venisse approfondita la parte sulla conformità alle normative di settore. Posso confermare che anche nel mio caso questo aspetto potrebbe viene approfondito maggiormente.
Sul sito della keanet (http://www.keanet.it/direttiva-macchine-2006-42-CE.htm) ci sono alcuni spunti che mi sembrano interessanti. Che ne pensi?
Ciao e grazie
Andrea
Ciao Andrea. Io non sono un esperto della Direttiva Macchine, perchè mi occupo da anni della gestione e della produzione di documentazione per prodotti software. Farò il possibile per fornirvi altri spunti, magari prelevati da altri siti. La mia massima aspirazione sarebbe quella di ospitare in questo blog qualche esperto che volesse "regalarci" alcuni articoli sull'argomento. Il sito che hai segnalato è il sito di un'azienda italiana molto all'avanguardia nel campo dei prodotti di content-reuse e mette a disposizione più di un contenuto interessante per chi si interessa di comunicazione tecnica.
Posta un commento