Abstract
La stesura di questo elaborato ha origine dal tentativo di dare risposta ad un problema tipico
di tutte quelle aziende di produzione di beni strumentali: la creazione di un manuale
istruzioni valido che risponda da un lato alle esigenze degli utilizzatori finali e dall’altro alle
esigenze di coloro che, all’interno delle aziende, si occupano di documentazione tecnica e
che sono spinti a farlo senza essere guidati da modelli teorici o da strumenti di supporto.
Il presente lavoro ha come scopo l’analisi di un modello specifico che, incorporando alcune
delle tecniche e delle teorie che governano la stesura dei manuali istruzioni, possa essere
usato come linea guida per la creazione della documentazione tecnica.
Si analizzano i principali studi presenti in letteratura sui contenuti e sulla forma che questo
prodotto deve avere per soddisfare insieme le normative vigenti e i bisogni degli utilizzatori.
Viene inoltre presentato il caso di SACMI IMOLA, azienda di produzione di macchine
automatiche per il settore ceramico e per il settore packaging, in cui, dopo un’attenta analisi
del processo attualmente seguito per la stesura della documentazione tecnica con
conseguente valutazione di tempi e metodi, si propone una reingegnerizzazione del processo
stesso e un modello formale da seguire nella fase operativa.
Si propone inoltre un nuovo modus operandi per la creazione dei manuali istruzioni che
prevede l’organizzazione del manuale in moduli di informazione (Templates) e l’utilizzo di
un sistema informatico di supporto per la compilazione basato sui principi del Content
Management System.
6
Introduzione
In tempi caratterizzati da continui mutamenti e dall’insicurezza economica, la flessibilità e
l’efficienza sono fattori determinanti e addirittura di vitale importanza per il successo di
un’azienda. La documentazione tecnica può fungere da propulsore.
La quantità di informazioni riguardanti i prodotti è in una fase di crescita repentina in virtù
dell’incremento delle varietà degli stessi, dei software e dei servizi, in sostanza di tutti
quegli assets che necessitano di spiegazioni.
Le tecnologie sono sempre più sofisticate e di conseguenza sembra piuttosto evidente che
anche la documentazione tecnica deve riflettere lo stato sofisticato di questa tecnologia, e
che può avere un'influenza significativa sulla decisione di acquistare un prodotto. Tuttavia,
ad oggi, molti utenti sono scettici sui manuali d'uso.
Se si vuole mantenere la competitività sul mercato è necessario guardare con più attenzione
alla documentazione tecnica, considerarla come un vero e proprio prodotto e migliorarne la
qualità e dei contenuti e del processo di creazione.
Il problema della documentazione tecnica è attuale nel panorama aziendale e tecnologico
odierno in quanto le aziende produttrici di macchine sono da un lato obbligate dalla direttiva
macchine a fornire la documentazione tecnica insieme con i suoi prodotti e dall’altro
individuano la necessità di mantenere elevata la customer satisfaction e di fornire quindi
una documentazione che sia di elevata qualità e che soddisfi i bisogni dei clienti.
È sembrato interessante quindi porre l’attenzione su quest’ambito dal punto di vista dei
contenuti e della gestione pratica del processo alla base della sua creazione, tralasciandone
la componente relativa al design in quanto lontana dall’obiettivo, proprio di questo
elaborato, di analizzare la documentazione da un punto di vista tecnico-pratico e focalizzare
l’attenzione sulle modalità di azione.
I principali contributi teorici in merito vengono dalla ricerca svolta da STC (Society for
Technical Communication) ad oggi la più grande organizzazione mondiale per i
professionisti nell’ambito della comunicazione tecnica.
Dopo aver analizzato quindi quanto la ricerca offre sull’argomento, è riportato un caso
aziendale, in particolare il caso della documentazione tecnica in SACMI IMOLA, in cui è
7
stato analizzato il processo seguito ad oggi per la creazione del manuale istruzioni
evidenziandone le principali criticità.
In linea con la necessità di analizzare i bisogni degli utilizzatori, fortemente raccomandata
dalla letteratura internazionale, sono state condotte una serie di interviste presso gli
stabilimenti dei principali clienti dalle quali è nata poi l’esigenza di rivedere non solo il
processo, per anticipare i tempi di consegna del manuale, ma anche i contenuti dei manuali
stessi.
Con il supporto teorico dato dai sistemi di CMS (Content Management System) si
presenteranno degli esempi pratici di creazione dei manuali istruzioni che hanno l’obiettivo
di agire insieme sul processo e sui contenuti.
8
Capitolo 1:
1 La manualistica all’interno di un azienda
Questo capitolo ha lo scopo di comprendere il contesto all’interno del quale si colloca la
documentazione tecnica in una azienda di produzione. Si definiscono inoltre il technical
writing e gli obiettivi che questa disciplina ha nella stesura di manuali istruzioni, le
tipologie di manuali esistenti e le caratteristiche principali dell’input e dell’output dei
manuali rispettivamente lo scrittore e il lettore degli stessi. Un breve accenno sarà fatto
sulle indicazioni generali da seguire nella scrittura di un manuale.
1.1 Breve tassonomia sui manuali
1.1.1 Il Technical Writing
La letteratura internazionale indica con il termine Technical Writing (che verrà abbreviato
per comodità come TW) quella disciplina o appunto tecnica che riguarda la scrittura di
manuali e testi di istruzioni: dal libretto che insegna ad usare la lavatrice o il telefonino fino
ai poderosi volumi che illustrano complesse procedure in ambito industriale
1
.
A differenza di altre forme di scrittura professionale, che concentrano l’autore in un vero e
proprio corpo a corpo con il puro testo, il TW è una scrittura complessa e ibrida. Il
rapporto tra testo, immagini (schemi e figure) e impaginazione è spesso vincolante. Vi si
mescolano, inoltre, componenti e competenze decisamente variegate: tecnologiche (molto
spesso ingegneristiche), psicologiche, linguistiche, editoriali. Per quanto lo si possa
immaginare come una scrittura asettica, in realtà il TW è una forma di comunicazione ricca
1
Il presente capitolo è tratto dal testo: ”T come Technical writing”di Fabrizio
Comolli. Omonimo Capitolo AA.VV., a cura di A. Lucchini, La magia della scrittura, Sperling & Kupfer, 2005.
9
di implicazioni e sfumature, esattamente come altre scritture considerate per definizione più
“creative”.
Tutti noi nel vivere quotidiano siamo lettori di manuali di istruzioni. Alcuni di noi i manuali
li scrivono. Pagine in cui un essere umano illustra a un altro essere umano come utilizzare
una macchina.
Nella pratica professionale, il concetto di TW può essere inteso in un’accezione più ampia o
in una più ristretta. In senso ampio, può rientrare nella definizione di TW ogni tipo di
documentazione scritta che illustra le caratteristiche e spiega il funzionamento di un
prodotto o di una procedura: dal libretto di istruzioni fino al libro vero e proprio. In questa
prima accezione, l'aggettivo "technical" può assumere contorni sempre più sfumati, fino a
includere la comunicazione di carattere editoriale, meno formalizzata e più creativa. Se si
prende il caso dell’editoria informatica si nota come libri e intere collane di informatica si
presentano sostanzialmente come sostituti delle guide utente, ossia dei manuali forniti nelle
confezioni del software. In breve, il TW e l’editoria tecnico-scientifica hanno ampie zone di
intersezione.
In senso più specifico e ristretto, invece, il TW identifica l'area di progettazione e
produzione della documentazione tecnica escludendo l'ambito editoriale: non libri ma
manuali in senso stretto, destinati a un uso interno all’azienda o a essere allegati alle
confezioni dei prodotti.
Non che la creatività tipica dell’approccio editoriale sia abolita o sconsigliabile, anzi, ma si
tratta in questo caso di un'area disciplinare più formalizzata e specialistica. In questo senso
esistono normative e associazioni di TW.
1.2 Tipologie di manuali
I testi di istruzioni possono essere classificati in base ad alcune caratteristiche.
Si distingue innanzitutto un modello tutorial da un modello reference. Un manuale di tipo
tutorial è relativamente semplificato, rivolto all’utente finale, di solito al principiante: le
istruzioni sono costruite intorno a esempi pratici illustrati passo per passo, limitando al
minimo gli approfondimenti e le specifiche tecniche. Un tutorial asseconda il processo di
10
apprendimento ed esecuzione dei compiti tipico dell’utente, e da questo punto di vista
rappresenta in molti casi l’approccio ideale. Viceversa, un manuale di tipo reference
costituisce una guida di riferimento per lo specialista o l’utente esperto: si tratta
generalmente di un volume corposo, che passa in rassegna in modo esaustivo le funzioni
della macchina, ordinandole secondo una gerarchia logica piuttosto che in base al
comportamento operativo dell’utente. Questo genere di testo è destinato alla consultazione,
come un’enciclopedia o un dizionario.
Entrambi i modelli hanno la loro ragione d’essere. Possono verificarsi problemi quando
vengono applicati nel contesto sbagliato. Pensiamo a un libretto di istruzioni di un prodotto
di massa, come un telefonino o un lettore dvd. Se i paragrafi seguono l’ordine in cui i
comandi appaiono nei menu dell’apparecchio, e non l’ordine logico delle operazioni che
l’utente vorrebbe effettuare, ecco che siamo in presenza di un approccio reference, alquanto
scomodo e inappropriato. L’utente qui deve leggere sequenzialmente tutto il manuale per
apprendere quel solo paio di procedure che gli interessano tanto per cominciare. Trova
magari ripetute in due parti diverse del manuale due procedure con un nome praticamente
identico (le voci dei menu degli apparecchi purtroppo non sono sempre ben tradotte e
differenziate) e, essendo le istruzioni de-contestualizzate e semplicemente elencate, fa fatica
a gestire queste informazioni. Nel caso ad esempio di un telefono cellulare l’utente scopre
solo alla fine che poteva impostare in lingua italiana i menu dei comandi anziché tenerseli in
inglese (questo perché le istruzioni sulla personalizzazione dell’interfaccia, in un modello
reference, vengono spesso riportate in appendice).
Un’altra classificazione dei manuali può essere dettata dal tipo di utilizzo e di destinatari: si
possono distinguere:
manuali d’uso (per l’utente finale);
manuali di installazione;
manuali di manutenzione o di servizio(per il personale tecnico e il customer care).
A volte queste tipologie sono aggregate e condensate: è il caso del classico “libretto di uso e
manutenzione” dell’automobile. Per i prodotti digitali e l’elettronica di consumo è ormai
frequente trovare nella confezione sia un manuale di discrete dimensioni (il vero e proprio
manuale utente) sia un documento più breve, schematico, di solito particolarmente attraente
11
e ben illustrato, che spiega in un batter d’occhio le istruzioni essenziali per essere subito
operativi (una “quickstart guide”, guida rapida).
Ulteriore distinzione non trascurabile: la documentazione può essere fornita in formato
cartaceo oppure in formato digitale (di solito un file Pdf nel cd-rom di installazione):
differenza non da poco sia per l’utente sia per il technical writer. La “fisicità” del manuale
non è un elemento neutrale, bensì condiziona tanto la lettura quanto la scrittura. La scrittura
dovrebbe essere ottimizzata per l’una o l’altra destinazione. Nei due casi cambiano
sensibilmente la facilità di lettura, il tipo di ricerca degli argomenti, lo stile di
apprendimento e memorizzazione delle informazioni.
Dal punto di vista del technical writer, tutti questi scenari e queste classificazioni pongono
vincoli differenti caso per caso, ma resta costante il cuore dell’attività: scrivere istruzioni.
1.3 Un modello di analisi del TW
I manuali di istruzioni non sono semplici “oggetti”, sono atti comunicativi, e come tali sono
animati da regole e immersi in un contesto. Come per ogni comunicazione, possiamo
adottare qui il semplice modello E-M-R: Emittente – Messaggio – Ricevente. Ogni
comunicazione, ogni testo scritto, quindi anche un manuale, è un Messaggio che un
Emittente trasmette a un Ricevente. Lo schema non è poi così banale se ci poniamo alcune
domande:
- Chi è “E”, l’Emittente: chi scrive i manuali? Qual è il profilo del technical writer, quali
sono le sue competenze, quale il suo metodo? Con chi interagisce quando progetta e scrive
un manuale? Quanto e come tutto ciò incide sulla scrittura stessa?
- Cos’è “M”, il Messaggio: come sono fatti (come devono essere fatti) i manuali? Si
possono formalizzare e generalizzare regole o linee-guida per impostare e scrivere i
manuali? Quali sono le caratteristiche linguistiche, comunicative, persino percettive, di un
buon testo di istruzioni?
- Chi è “R”, il Ricevente: chi è l’utente, il lettore, il destinatario delle istruzioni? Qual è il
suo ruolo e di cosa ha bisogno? Quali vincoli e indicazioni ne derivano per il technical
12
writer? Non basta: cosa accade tra E, M e R? Sono tre poli di una relazione, non tre atomi
sospesi nel vuoto. Negli spazi “interstiziali” tra questi tre elementi c’è un fermento di
interazioni, interferenze, rumore di fondo. Il technical writer (E) mentre scrive il manuale
(M) ha in mente un modello di utente (R). Per certi versi, anche (R) quando legge (M) pensa
a (E).
In altre parole, oltre al contenuto (semantica), oltre alla forma (sintassi), bisogna tenere
conto della terza dimensione, quella "pragmatica", cioè il tipo di relazione tra un certo
autore e un certo destinatario.
Sullo sfondo c’è anche un quarto elemento: la macchina, l’oggetto, l’argomento del
manuale. La macchina sembrerebbe un elemento oggettivo, fisso, chiaro: eppure la sua
immagine che il technical writer ha in mente può essere molto diversa da quella che si
forma nella mente dell’utente. Il modo di descriverla nel manuale risente di questi differenti
modelli mentali (terminologia e stili linguistici, presupposizioni, nozioni date per scontate o
viceversa sviscerate a fondo, eccetera).
1.4 Lo scrittore del manuale
Il TW è una professione. Ci sono technical writer specialisti e agenzie che offrono servizi di
TW alle aziende. Tuttavia il TW è anche una prassi, in senso più generale, che viene svolta
da persone con le qualifiche più svariate. Di fatto, nella realtà industriale spesso sono tecnici
(ingegneri) a scrivere i manuali delle macchine o dei software: membri del gruppo di lavoro
che li ha progettati. Il che rassicura circa la competenza tecnica sui contenuti, ma possono
nascere dei dubbi circa la qualità finale dei manuali.
Chi progetta una macchina o sviluppa un programma non è la persona più adatta a spiegarne
il funzionamento a un principiante. Senza nulla togliere alla sua competenza, un bravo
informatico o un bravo ingegnere di solito non è un bravo istruttore, scrittore o traduttore di
manuali. Paradossalmente, più un professionista tecnico è bravo e calato nel suo lavoro, cioè
più è un vero specialista, più gli riesce difficile raggiungere quel distacco che è essenziale,
da un punto di vista psicologico, per tracciare una visione d'insieme dell'argomento e per
13
immedesimarsi nel principiante, comprenderne e anticiparne le domande, i dubbi, le
difficoltà, il percorso di apprendimento.
Uno specialista dà troppe cose per scontate (deve farlo), senza rendersene conto. La vera
expertise si consolida quando le nozioni vengono dimenticate, metabolizzate, interiorizzate
e automatizzate. È difficile e faticoso fare il percorso inverso, ossia rendere di nuovo
esplicite le nozioni che ormai si padroneggiano, per trasformarle in istruzioni al servizio di
un principiante. Inoltre, chi sa programmare o progettare non per questo sa scrivere o
tradurre altrettanto bene: anzi, è molto difficile che questi due tipi di abilità, quella tecnica e
quella linguistica o umanistica, convivano in una stessa persona. Ed è più che
comprensibile.
Un ottimo manuale, idealmente, nasce dalla interazione tra un tecnico e uno specialista della
scrittura, tra il progettista e il technical writer. Lo scrittore deve fare un lavoro "maieutico":
affiancare il tecnico, osservarlo, intervistarlo. Questo lavoro ha anche un nome: elicitazione
delle competenze, analisi dell'expertise, knowledge acquisition e via dicendo. In ogni caso
un buon lavoro di TW nasce da un’interazione complessa e più o meno strutturata tra
technical writer e progettisti: interazione che prevede passaggio di documentazione di
progetto e specifiche tecniche, riunioni, interviste, prove e revisioni reciproche. Di più:
come sostiene un po’ provocatoriamente Donald Norman, guru dell’usabilità e della
Human- Computer Interaction, il technical writer dovrebbe essere coinvolto precocemente,
già nella fase di progettazione del prodotto. Paradossalmente, bisognerebbe prima di tutto
scrivere il manuale (il manuale perfetto), e poi sviluppare la macchina ispirandosi al
manuale… Tra le due discipline del TW e dell’usabilità ci sono molti punti di contatto.
1.5 Il lettore del manuale
Quando il technical writer progetta e scrive un manuale, non ha in mente solo l’oggetto
delle istruzioni, la macchina o la procedura da spiegare. Si scrive sempre “per qualcuno”, si
spiega sempre “a qualcuno”. Secondo i massmediologi, in ogni testo (e i manuali non fanno
eccezione) vengono incorporate implicitamente due immagini: da un lato, un'immagine
dell'emittente (“enunciatore”), dall'altro un'immagine o proiezione del destinatario
14
(“enunciatario”). Ogni testo è condizionato a monte da stile, aspettative, intenzioni
dell'autore, e a valle da una proiezione dell'utente ipotetico.
La progettazione di un manuale deve essere centrata su un modello di utente
sufficientemente determinato. A prescindere dall'argomento, ogni testo deve essere rivolto a
un certo target piuttosto che a un altro. Pur riferendosi a uno stesso software, un manuale
destinato all'utente finale (operatore, più o meno principiante) sarà ben diverso da un
manuale destinato al programmatore o all'amministratore di una rete aziendale. Un manuale
destinato a un utente europeo sarà diverso da un manuale destinato a un utente giapponese o
africano: diverse le formulazioni linguistiche, diversi i simboli e le icone, diverse persino le
illustrazioni (basti pensare allo stile “fumettistico” di certi manuali giapponesi). E così via.
È una banalizzazione, ma aiuta a rendere l'idea. Si evita in questo contesto di approfondire
le implicazioni di ordine culturale, che d’altronde riguardano più la traduzione delle
istruzioni che la loro scrittura originale.
Dal punto di vista cognitivo, costruire un manuale "user-centered" significa tenere come
riferimento il piano d'uso dell'utente nei confronti dello strumento (macchina, software o
quant’altro). Il piano d'uso è una gerarchia di azioni e sotto-azioni finalizzate al
conseguimento di un certo obiettivo.
Nell'attuare il proprio piano d'uso, l'utente segue un circuito a feedback: il cosiddetto ciclo
T.O.T.E. (Test – Operate – Test – Exit), secondo una definizione che viene dalla psicologia
cognitivista e dalla cibernetica. L'utente si prefigge una meta, effettua di conseguenza una
serie di operazioni, verifica il risultato e, se non soddisfatto, riprende a operare. Quando il
controllo dei risultati restituisce un feedback positivo, l’obiettivo è raggiunto e il ciclo si
interrompe.
15
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
