martedì 30 ottobre 2012

La Qualità è un Processo: un esempio (seconda parte)


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:
  1. 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;
  2. la Qualità di un documento non attiene esclusivamente alle suddette attività, ma può dipendere da molti altri fattori che vanno presi in considerazione.
Per ciò che concerne il punto 1, è un concetto che sostengo da tempo, semplicemente sulla base della mia esperienza professionale.

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)


Leggi questo articolo...

sabato 20 ottobre 2012

La Qualità è un Processo: un esempio (prima parte)

In un recente Webinar ho sostenuto che l'attività fondamentale di un Tech Communicator consista nell'abbattere quell'elemento strutturale della comunicazione che nel Teorema di Shannon-Weaver viene identificato con il concetto di Rumore (Noise).


Il Rumore è tutto ciò che tende a "distruggere il messaggio", cioè a rendere di fatto vano il processo di comunicazione dal Source al Receiver.

Il Tech Communicator opera attraverso una serie di strumenti, tecniche, metodologie di varia natura al fine di abbattere quanto più possibile il Rumore.

Ma a questo punto dovremmo chiederci che rapporto c'è tra la Qualità di un documento tecnico, di cui mi sono occupato in più occasioni, e il Rumore che può essere sempre presente nel processo di comunicazione.

Una prima buona approssimazione, mi spinge a dire che esiste un rapporto di proporzionalità inversa:

Qualità = 1/Rumore

Quanto più basso è il livello di Rumore, tanto più alta sarà la Qualità percepita e viceversa:


Se siamo ragionevolmente concordi su questa analisi di base, arriviamo alla conclusione che ricerca della Qualità e abbattimento del Rumore sono concetti duali, in cui l'uno implica l'altro.

Ma ora dobbiamo chiederci COME otteniamo il nostro scopo, cioè la minimizzazione del Rumore e il suo duale conseguente, cioè la massimizzazione della Qualità.

La risposta più logica da dare è che dobbiamo sempre affidarci ad un Processo, capace di integrare ed utilizzare le suddette tecniche, gli strumenti, le metodologie e ogni altro elemento disponibile.

Quando si cerca di generalizzare un concetto, si rischia a volte di essere un po' troppo vaghi, ma nel prossimo post vi proporrò un esempio concreto, peraltro tratto da fonte autorevole.

A presto. Leggi questo articolo...