La dott.ssa Michela Barbero (SSLiMIT - Università di Bologna) ha scritto una interessantissima tesi sul technical writing e la linguistica (analisi terminologica), sotto la guida del prof Franco Bertaccini e del prof. Paolo Scampa. Ha discusso la tesi il 5/12/2001.

Nel corso della sua ricerca abbiamo avuto uno scambio di riflessioni sotto forma di intervista (settembre-novembre 2001), che pubblico qui con il suo consenso. Con un ringraziamento per la sua grande gentilezza e per gli stimoli alla riflessione che mi ha fornito. E con i complimenti per la sua bravura, sia nello studio che nel lavoro (è anche traduttrice free lance).

N.B. - Rispetto all'intervista dell'anno scorso, questa rappresenta un aggiornamento. Molti contenuti ritornano, altri sono nuovi o rimeditati. Il focus del discorso è un po' più centrato su tematiche di carattere psicologico. Ci sono inoltre alcune precisazioni sul rapporto tra technical writing in senso stretto ed editoria informatica. Alcuni nuovi esempi e riferimenti.

E-mail: fabrizio@comolli.it
© 1998-2005 - Fabrizio Comolli

Scrivere e tradurre manuali di informatica:
incontro tra psicologia e tecnologia
(novembre 2001)

Torna a: Le mie attività

Indice dell'intervista:

1. La mia formazione accademica e professionale
2. Cosa c'entra la psicologia con il technical writing
3. Umanisti, informatici e manuali di istruzioni
4. Comprendere (o immaginarsi) l'utente
5. Technical writing negli USA e in Europa
6. Manuali "all'americana" e manuali "all'italiana"
7. Ruoli e team
8. Il tecnico e lo scrittore
9. Stili formali e linguistici
10. Calarsi nei panni dell'utente/cliente
11. Il processo di scrittura di un manuale
12. Tradurre è un po' tradire...
13. Terminologia, glossari, software di traduzione
14. Standard e norme

1) Qual è la sua formazione accademica e professionale?

Ho 37 anni, sono laureato in filosofia (alla Cattolica di Milano, nel 1988) e in psicologia (a Torino, nel 1998). La mia formazione quindi è iniziata in ambito prettamente umanistico, con un originario interesse per la psicologia clinica (approccio sistemico), ma nel corso degli anni si è progressivamente focalizzata sul rapporto tra fattori umani e nuove tecnologie.

Ho concluso i miei studi concentrandomi sull'ergonomia psicologica, ossia sulle problematiche della "usabilità" del software e del Web. Da alcuni anni mi sono dedicato quasi del tutto a questo ambito, sia sul piano teorico (collaborando dal 1998 con la cattedra di ergonomia della facoltà di psicologia di Torino, prof. Alessandra Re) sia su quello professionale.

Dal 1996-1997 ho iniziato a svolgere l'attività di formatore (corsi in aula, e in seguito via Web) e, soprattutto, autore multimediale free lance. Ho scritto una ventina di manuali e libri di informatica, ho tradotto alcuni libri di informatica, new economy e "cultura digitale", ho realizzato guide in linea (help) per enciclopedie su CD-ROM, come Omnia De Agostini, e per siti Web, come Poste.it.

Per quanto riguarda i manuali e i libri di informatica, in particolare, ho collaborato con alcuni dei principali editori italiani del settore: da quelli più "nazionalpopolari" come Jackson Libri a quelli più solidi e tradizionalisti, come Tecniche Nuove, o dinamici e raffinati, come Apogeo.

Ho avuto negli ultimi anni esperienze occasionali in campi più o meno contigui a quello editoriale. Nel 1999 ho partecipato a una ricerca per rinnovare i libretti di istruzioni di un noto produttore di elettrodomestici. Nel 2000 ho seguito come communication/web manager la fase di start-up di PRESSToday, una Net-company dedicata a un servizio gratuito di rassegne stampa online, curandone il design del sito Web e dell'interazione, la comunicazione con gli utenti, alcune iniziative di marketing/promozione commerciale dei servizi.

Dal gennaio 2001 sono rientrato a tempo pieno nell'ambito dell'editoria off- e online: collaboro ora stabilmente con Apogeo per il coordinamento di progetti sia cartacei che sul Web, e proseguo la mia attività di autore.

2) Quanto ha contato o conta la sua formazione accademica-culturale nella sua attuale attività? Come si collega la psicologia al technical writing?

È doveroso fare una premessa. Nella pratica professionale, il concetto di "technical writing" (da qui in poi lo abbrevio in 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 che illustra le caratteristiche e spiega il funzionamento di un prodotto o di una procedura: dal libretto di istruzioni al manuale aziendale, fino al libro vero e proprio. In questa prima accezione, direi che l'aggettivo "technical" può assumere contorni sempre più sfumati, fino a una zona di confine con la comunicazione di carattere editoriale/creativo.

In senso più specifico e ristretto, invece, il TW identifica l'area di progettazione e produzione della documentazione tecnica, escludendo l'ambito editoriale: non che la creatività sia 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.

Personalmente, le mie esperienze mi collocano più vicino alla prima accezione di TW che non alla seconda. Ho avuto occasione di rasentare, e a volte esplorare, il mondo del TW propriamente detto. Tuttavia, in generale, appartengo più al mondo editoriale che alla comunità degli addetti ai lavori del TW. Questa premessa incide sensibilmente sulla mia prospettiva e sul tipo di risposte che darò alle prossime domande.

La mia prospettiva, in breve, è quella di chi scrive "di" o "sulle" nuove tecnologie a scopo didattico-divulgativo: a volte si tratta di manuali, a volte di libri. L'approccio editoriale può comportare questioni abbastanza diverse da quelle del TW "ristretto" o specialistico. Parlerò prevalentemente di editoria informatica, piuttosto che di TW di matrice aziendale.

In rapporto alla mia formazione, la mia collocazione professionale può indubbiamente apparire ibrida, bizzarra (forse oggi meno che qualche anno fa). Io stesso ho a volte la sensazione di muovermi in una terra di confine con pochi punti fermi. Ma è un'esagerazione. Non mancano riferimenti ormai consolidati, sia come teorie e metodologie, sia come personaggi e "capi-scuola". Un esempio per tutti: Donald Norman, già brillante psicologo cognitivista e docente universitario, poi manager alla Apple, e ora consulente aziendale e autorità indiscussa a livello mondiale, insieme al suo amico e socio Jakob Nielsen, per quanto riguarda il tema della "usabilità" e il rapporto uomo/computer. Ecco, il rapporto uomo/computer (o HCI: Human-Computer Interaction) è la chiave per descrivere il mio ambito di attività e, a mio avviso, ne derivano molte interessanti implicazioni per l'editoria informatica.

Mi spiego meglio. I computer e i relativi programmi sono tutt'altro che facili da utilizzare. Nonostante incessanti ricerche e sensibili progressi, ad esempio nella progettazione delle interfacce, resta il fatto che tuttora un principiante si trova in difficoltà al suo primo approccio con un PC o con una nuova applicazione, così come un utente esperto a volte fa fatica a sfruttare in profondità tutte le (sovrabbondanti) risorse/opzioni che gli odierni strumenti gli mettono a disposizione.

Questo è il primo problema: gli strumenti (hardware e software), nonostante tutto, non sono ancora né semplici né propriamente amichevoli (user friendly). Lo strumento ideale, dice Norman, dovrebbe essere "invisibile" e consentire all'utente di pensare solo al suo scopo, al suo lavoro, a quello che vuole ottenere. Siamo ancora lontani da questo obiettivo. L'interazione tra macchina e utente è troppo complessa. E infatti, puntualmente, c'è bisogno di consultare il manuale del PC o del programma. Qui nasce il secondo problema: la qualità della manualistica, della documentazione, ossia della comunicazione con l'utente.

3) - Cosa vuol dire occuparsi di comunicazione tecnica o di technical writing e, in particolare, di manualistica? Nell'ambito della manualistica, operano diverse figure professionali e redattori con formazioni culturali divergenti. Questo fenomeno dimostra quanto sia complicato scrivere documentazione tecnica istruzionale. Secondo Lei, quanto è importante la formazione umanistica o tecnica nella redazione dei manuali d'istruzioni?

I manuali istituzionali, quelli forniti dai produttori, troppo spesso non sono soddisfacenti. A volte non sono nemmeno disponibili, o magari (per ragioni di costi) vengono forniti soltanto in versione elettronica sul cd del programma, e non in versione cartacea. Così alcuni utenti ne ignorano del tutto l'esistenza; altri non riescono a sfruttarli a dovere.

Spesso, inoltre, questi manuali standard sono mal realizzati, insufficienti, trascurati, per una serie di motivi. Ad esempio, perché vengono realizzati in fretta e furia, come ultima incombenza prima della commercializzazione dei prodotti, e tirati via alla svelta dalla stessa équipe di informatici che ha progettato e sviluppato quel certo software. Una pessima soluzione. Chi sviluppa un programma non è la persona più adatta a spiegarne il funzionamento a un principiante.

Senza nulla togliere alla sua competenza, un bravo informatico di solito non è un bravo istruttore, scrittore o traduttore di manuali. Paradossalmente, più un programmatore è 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 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. Inoltre, chi sa programmare 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.

Qui si apre lo spazio per l'editoria informatica: con l'accento sulla parola "editoria". I libri di informatica non sono un semplice surrogato dei manuali d'uso, sono qualcosa di diverso e di più. I manuali d'uso, quelli istituzionali, quelli cioè forniti dai produttori, sono quasi sempre di tipo "reference": rassegne di funzioni descritte e commentate con maggiore o minore abilità (vedi sopra), ma quasi sempre secondo una logica che è quella della macchina, non quella dell'utente.

Un buon libro di informatica, in linea del tutto generale, dovrebbe riuscire a combinare l'approccio di tipo "reference" con quello di tipo "tutorial": dovrebbe cioè esporre con completezza le funzioni di un programma, certo, ma seguire un percorso che rispecchi e faciliti lo stile di apprendimento di un tipico operatore umano che parte da zero. In parole povere, un buon libro di informatica deve rispondere non alla domanda "cosa può fare questo software?" ma alla domanda "che cosa vuole fare l'utente?": seguire quindi un percorso che rispetta la psicologia umana, non la celebrazione della tecnologia in sé.

Quando si parla di stile di apprendimento, entrano in gioco svariati fattori: il piano mentale che un utente si costruisce per operare con quel programma (quindi una "scaletta" di aspettative, obiettivi, sotto-obiettivi e operazioni per conseguirli); le prerogative e i limiti della percezione (leggibilità dei testi e delle illustrazioni); le prerogative e i limiti della memoria (quanti punti di un elenco, ad esempio quanti passaggi di un'operazione, può tenere a mente in media un soggetto?); i problemi di linguaggio (chiarezza, rischio di equivoci, gergo tecnico), e così via.

In breve, ecco che ci siamo spostati sul terreno della psicologia. In questo senso, per quello che riguarda la mia esperienza, una formazione umanistica può essere un grande vantaggio e una fonte di risorse.

Oltre all'utilità di competenze di ordine psicologico, una formazione umanistica in genere si accompagna a una certa familiarità con la scrittura. Il che non guasta, anche nel mondo dell'editoria informatica e specializzata. Il resto viene con l'esperienza sul campo: interesse (al limite, passione) per l'argomento, conoscenza ed esercizio, apprendimento grazie a esempi, tentativi, errori.

Aggiungo un'ultima osservazione. Quando si tratta non di scrivere ma di tradurre, sia che si tratti di un libro di informatica che di un romanzo, i fattori in gioco non sono più solo di tipo tecnico e di tipo psicologico ma anche di tipo culturale. Un buon libro di informatica americano può essere molto diverso da un buon libro di informatica italiano. Penso che ne riparleremo nel corso dell'intervista.

4) A tale proposito, può affermare che i suoi studi di psicologia si siano rivelati importanti al momento dell'ideazione e stesura dei manuali? Cosa significa l'espressione che alcuni utilizzano: "capire l'utente prefigurato"?

Rispondo prendendola un po' alla lontana. In ogni "testo" (documento scritto tradizionale, lineare, oppure ipertestuale, oppure multimediale) vengono incorporate implicitamente due immagini: da un lato, un'immagine dell'emittente (enunciatore), dall'altro un'immagine o proiezione del destinatario (enunciatario). Questa almeno è la visione di alcune scuole di massmediologia, come quella di Gianfranco Bettetini - da cui provengono alcuni professionisti oggi arcinoti, come Aldo Grasso e Fausto Colombo.

In altre parole, ogni testo (che sia un libro, un manuale, un video eccetera) non è un atto di comunicazione che si manifesta in astratto, allo stato puro. Ogni testo è condizionato a monte da stile, aspettative, intenzioni dell'autore, e a valle da una proiezione dell'utente ipotetico.

Dal punto di vista comunicativo, un testo è la risultante di vari vettori o di varie dimensioni: 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.

Parafrasando un certo proverbio latino sulla procreazione: l'autore è sempre noto, il destinatario un po' meno. Chi scrive si rivolge a un utente fittizio, immaginato. Un utente "medio"? Questo riferimento è ingannevole.

Proviamo a riformulare la questione da un altro punto di vista ancora. L'ergonomia è la disciplina che "sorveglia" la progettazione di prodotti e strumenti per garantirne il carattere "user-centered". Un prodotto (un prodotto materiale, un software, un sito Web, o un manuale) è ergonomico se risponde alle esigenze e alle caratteristiche dell'utente.

Ma quale utente? L'utente medio non esiste. È una finzione astratta e, per giunta, nociva. Già a partire dai livelli più "bassi" (ambito antropometrico e fisiologico) la progettazione non può basarsi su un modello di utente "medio". Figuriamoci se consideriamo le dimensioni più sofisticate, come quelle percettive e cognitive.

Dal punto di vista cognitivo, costruire un manuale "user-centered" significa tenere come riferimento il piano d'uso dell'utente nei confronti dello strumento (software, sito Web e via dicendo). Il piano d'uso è, come accennavo in precedenza, 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 la definizione dei "padri" del cognitivismo Miller, Galanter e Pribram). In parole povere l'utente si prefigge una meta, effettua di conseguenza una serie di operazioni, verifica il risultato e, se non soddisfatto, riprende a operare. Riguardo a queste tematiche, rimando al fondamentale testo di Alessandra Re, Ergonomia per psicologi (Cortina, 1995).

Non è il caso sicuramente di scendere troppo nei dettagli, ma in breve si può dire che la psicologia ha molto da insegnarci sul modo in cui le persone agiscono, interagiscono con i loro strumenti, leggono, apprendono e così via.

Scendiamo ora su un piano un po' più concreto. Il punto è che la progettazione di un oggetto, incluso un meta-oggetto (un oggetto che descrive altri oggetti) come appunto 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 cinese o africano. E così via. È una banalizzazione, una tremenda semplificazione, ma aiuta a rendere l'idea.

Non solo. In termini cognitivi, come dicevamo, ogni utente è qualificato essenzialmente dal suo piano d'uso: dalle sue aspettative, competenze e obiettivi. Cosa devo spiegare, e cosa posso trascurare? Quali sono le priorità? Da cosa comincio? Come devo articolare il testo, come devo calibrare il peso relativo degli argomenti? Dove posso generalizzare, e dove invece devo formulare esempi concreti?
Ecco alcuni spunti di carattere squisitamente psicologico-cognitivo che entrano in gioco se si riflette sulla progettazione di un manuale. Naturalmente, non sempre c'è il tempo per riflettere in modo tanto sistematico. A volte non si può (e si azzarda, si procede per approssimazione). A volte invece si dispone di una base dati sufficiente per procedere in modo davvero mirato (se il target è ben identificato, come in ambito aziendale - ma non sempre).

Di sicuro, comunque, chi scrive istruzioni (che sia un manuale in senso stretto oppure un libro) si prefigura un certo interlocutore, o un certo segmento di utenza: che ne sia consapevole o no. Non si scrive mai nel vuoto. Si scrive sempre "per qualcuno". Mi fermo qui, anche se abbiamo appena sfiorato tematiche molto interessanti.

5) - Nel nostro paese, è recente lo sviluppo della manualistica e della comunicazione tecnica. Anche i testi teorici sul technical writing sono pochi, mentre abbondano i testi di produzione americana. Secondo Lei, perché il technical writing è meno "valorizzato" in Italia o in Europa rispetto al continente americano? Negli Stati Uniti, esistono diversi corsi di specializzazione di technical writing, mentre in Italia la scrittura tecnica è tendenzialmente considerata "non accademica". Cosa pensa in proposito? Quale sono le ragioni principali delle diverse evoluzioni della manualistica nei due continenti (europeo ed americano)?

Non saprei dare una spiegazione approfondita, tuttavia posso segnalare a questo riguardo un paio di siti Web molto interessanti. Uno è il sito di Luisa Carrada "Il mestiere di scrivere" (www.mestierediscrivere.com): una miniera di informazioni, riflessioni e risorse su technical writing, business writing e web writing. L'altro è il sito della Society for Technical Communication (www.stc.org), un riferimento ufficiale per i technical writer italiani e internazionali.

6) - Data la leadership degli americani nel settore del technical writing, si parla comunemente di "approccio italiano" e di "approccio americano". Esistono differenze notevoli tra i manuali prodotti nelle due diverse realtà culturali?

L'approccio, lo stile dei manuali (o libri) è strettamente vincolato al contesto sociolinguistico in cui essi vengono ideati e realizzati: ciò che influisce, ovviamente, sono le caratteristiche tanto degli autori quanto dei destinatari. Nel caso dei manuali in senso stretto, ad esempio dei libretti di istruzioni, questi fattori potrebbero essere considerati meno influenti, o almeno così si potrebbe ipotizzare dato il più elevato coefficiente di formalizzazione delle "istruzioni per l'uso" in ambito tecnologico (e non solo). Tuttavia anche in questo caso si possono notare differenze di approccio: basterebbe osservare i differenti stili di illustrazione tra libretti di istruzioni italiani, tedeschi, americani o giapponesi. Oltre all'iconografia, a volte anche l'impostazione concettuale/procedurale può variare, entro certi limiti. Ad ogni modo, la differenza appare ancora più marcata se focalizziamo l'attenzione sui libri di informatica.

Per una serie di ragioni, non è facile capire esattamente le caratteristiche, le aspettative e le reazioni del pubblico reale, cioè degli effettivi lettori di un libro. Almeno qui da noi: negli USA, dove l'alfabetizzazione informatica è molto più radicata, è più facile vedere forme di interazione tra editori, autori e lettori. Ad esempio nelle librerie virtuali su Internet, come Amazon, è abbastanza comune leggere all'interno della scheda di un libro, tra tutte le informazioni utili per orientare all'acquisto, anche le recensioni di lettori qualunque.

In linea di massima si dà per scontato che l'approccio made in USA sia caratterizzato da un tono più leggero e sdrammatizzante, denso di battute, metafore, toni colloquiali e via dicendo. In effetti la lingua inglese si presta bene: è la lingua "tecnologica" per eccellenza, la koiné o l'esperanto dell'informatica, e in più offre innumerevoli occasioni per divertirsi con le assonanze e i giochi di parole. È anche una lingua molto sintetica, che consente una certa libertà d'azione. Di fatto, è facile trovare questi toni un po' sopra le righe persino nei manuali più voluminosi e complessi. Addirittura, ci sono intere collane dedicate (letteralmente) agli "imbranati", agli "idioti totali" eccetera. I lettori americani devono solo scegliere in quale categoria riconoscersi, e si divertono.

Altrettanto scontato, per molti, è che il pubblico italiano ed europeo sia molto diverso: più serio (o serioso), forse anche meno spiritoso. In effetti, a volte è vero. Mi viene in mente un caso concreto.
Mi è capitato di partecipare a un progetto per l'innovazione dei libretti di istruzioni di una nota marca italiana di elettrodomestici. La documentazione che avevamo a disposizione includeva un'indagine di mercato svolta in precedenza mediante focus group (gruppi di discussione) di consumatori. Erano state preparate e presentate tre bozze del nuovo prototipo di manualetto: una serissima e tecnologica, una semplice e divulgativa e una molto creativa. Quest'ultima bozza era basata su un progetto grafico in stile fumetto, secondo l'ipotesi che occorreva sdrammatizzare un argomento così serio e noioso come l'utilizzo di una lavatrice, e che inoltre il destinatario del messaggio era una casalinga senza competenze o propensioni tecnologiche. Le istruzioni erano perciò presentate da un personaggio da cartoon, una lavatrice "umanizzata", con un tratto grafico e linguistico simpatico e spiritoso. In partenza, quasi tutti scommettevano che questo sarebbe risultato il progetto vincente. Invece, il responso dei focus group fu esattamente l'opposto: le casalinghe e gli altri intervistati manifestavano una certa insofferenza per questo approccio. "Mi trattano come un/una deficiente", "Non sono mica un/una bambino/a", "Voglio imparare a usare questo aggeggio, non voglio leggere un fumetto": queste erano state le reazioni prevalenti.

Dunque è legittimo sostenere che le americanate non pagano. Eppure, non è un dogma, non è sempre così. Facendo per anni formazione in aula, ho potuto constatare che moltissimi principianti, nel loro approccio al computer e a Internet, in realtà apprezzano davvero i toni rilassanti e sdrammatizzanti.
Probabilmente il computer è un oggetto tecnologico particolare, che viene vissuto in modo differente rispetto ai comuni elettrodomestici. Gli elettrodomestici sono ormai acquisiti come compagni quotidiani, restano (devono restare) invisibili e limitarsi a fare bene il loro lavoro. Il computer invece è ancora, per molti, un totem tecnologico: incute soggezione, diffidenza o senso di inferiorità (almeno in certe fasce generazionali).

In questo caso, perciò, il principiante apprezza le strizzatine d'occhio e le battute "liberatorie". Forse è il lettore esperto ad avere gusti più difficili: quando legge un manuale complesso vuole andare al sodo. Ha obiettivi precisi e poco tempo da perdere. Le battute non sono da escludere, ma devono essere assolutamente ben scelte, ben dosate, appropriate e non invadenti.

In breve, direi (ma è un'ipotesi) che la differenza va fatta non tanto tra i lettori USA e quelli italiani, presi in blocco, ma tra i target distinti per competenza e obiettivi. Per il principiante, il libro/manuale deve essere un compagno di avventura (l'avventura dell'apprendimento) e dunque non deve essere avaro di commenti, incoraggiamenti, persino distrazioni. Viceversa, per l'esperto il libro/manuale è sostanzialmente uno strumento di lavoro: una battuta ogni tanto va benissimo; basta non esagerare.

7) Quali sono le figure professionali presenti in un ipotetico gruppo di lavoro?

In altre parole, qual è l'équipe ideale per scrivere o tradurre un libro di informatica? Darò una risposta semplice (che sembra provocatoria, ma non lo è): non esiste. Nel senso che questo lavoro, nel 99% dei casi, non viene fatto in équipe. Meglio parlare di una one-man-band: l'autore (o il traduttore) opera quasi sempre da solo.

Nel settore informatico, molti editori si limitano a distribuire il lavoro, raccogliere il prodotto finito e appiccicargli la copertina. Forse sto esagerando un po', ma questa è davvero una prassi quasi generalizzata. Solo in rari casi si crea un vero rapporto "maieutico" e creativo tra editore e autore.

Teoricamente, queste sono le figure coinvolte: l'editore (direttore editoriale e/o redazione) che pianifica le opere e compie una revisione del lavoro prima della stampa definitiva; l'autore (o traduttore) che si occupa dei testi; l'illustratore che realizza le figure; l'impaginatore che assembla il tutto e genera le pellicole o i file digitali da fornire allo stampatore.

Molto frequentemente, però, l'autore stesso realizza sia i testi che le illustrazioni; non è raro che si occupi in prima persona anche dell'impaginazione del libro. Questa concentrazione di funzioni nella stessa persona (se ne ha le competenze), lungi dall'essere un cortocircuito o un'interferenza, è un grande vantaggio. La qualità di un testo trae notevoli benefici dalla coerenza interna e dall'equilibrio che deriva da un'unica paternità di tutte le varie componenti. La competenza cruciale resta sempre e comunque quella dell'autore o traduttore.

8) Come avviene la collaborazione tra il tecnico e lo scritore?

Come dicevo all'inizio, in genere è preferibile un'ottima competenza nella progettazione concettuale e nella stesura linguistica del testo, rispetto alla conoscenza minuziosa dei singoli argomenti. Come è ovvio, questa conoscenza è necessaria: bisogna avere la pazienza e l'umiltà di documentarsi e imparare ogni volta. Ma il punto, a mio modo di vedere, è che la conoscenza degli argomenti tecnologici può essere sviluppata in tempi ragionevolmente brevi e in modo mirato, caso per caso, una volta che si sono raggiunte solide basi. Al contrario, le competenze culturali-linguistiche non possono essere improvvisate, richiedono anni di preparazione e un incessante lavoro di messa a punto ed esercizio.

Direi comunque che, in caso di manuali poderosi o argomenti particolarmente complessi, può risultare molto utile aggiungere alla (ipotetica) équipe la figura di un consulente tecnologico esterno, un esperto dello specifico dominio che affianca l'autore, offre spunti e chiarimenti, verifica i passaggi più delicati.

Le modalità di collaborazione tra lo scrittore e il tecnico, sul piano pratico, possono essere le più disparate. Si va da una vera scrittura a quattro mani (che probabilmente richiederà allo scrittore un pizzico di impegno in più per rivedere e omogeneizzare anche le parti altrui), a uno scambio costante di opinioni e revisioni via e-mail, alla semplice fornitura di documentazione e riferimenti da parte del tecnico, eccetera.

In casi più complessi, e da un certo punto di vista appassionanti, 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. Ecco che torneremmo una volta di più nel campo della psicologia (v. ad esempio Alessandra Re, Psicologia e soggetto esperto, Tirrenia Stampatori, Torino 1990). Ma nel nostro caso non c'è niente di così formalizzato: potrei parlare di una prassi informale, irrituale, empirica. Molto dipende anche dalle circostanze concrete.

9) - I manuali d'istruzioni si suddividono in diverse tipologie testuali. Lei si occupa di editoria informatica. Quali sono le caratteristiche fondamentali che distinguono i testi che Lei redige comunemente?

Lo stile formale e linguistico di un libro di informatica dipende in parte dalla personalità dell'autore o del traduttore, ma ovviamente deve rispondere a determinati requisiti. Alcuni requisiti vengono dalla natura stessa del testo istruzionale ("usabilità" del manuale in base a varie dimensioni: struttura, esposizione, grafica, impaginazione e così via). Ci sono alcune regole di fondo che non possono essere ignorate. Altri requisiti potrebbero essere dettati dall'editore.

Ci sono editori esigenti e altri meno. Ci sono editori con una spiccata personalità e altri più anonimi. Infine, ci sono editori più organizzati e altri più lassisti. Il compito dell'autore e del traduttore cambia molto da caso a caso. A volte un editore fornisce in partenza una serie di specifiche molto dettagliate, relative a scelte redazionali (come i criteri per la formattazione dei termini tecnici) e linguistiche (forma impersonale o discorso diretto). In questo caso chi scrive è più vincolato ma anche più "appoggiato". Quando così non è, l'autore (o il traduttore) ha maggiore libertà ma nello stesso tempo deve mantenere costantemente un più alto livello di controllo e auto-disciplina per garantire la coerenza del proprio testo.

Per approfondire la trattazione teorica e metodologica dei testi istruzionali in senso stretto/formale, consiglierei senza dubbio la lettura di due splendidi saggi: Testi e macchine, a cura di Carlo Serra Borneto (Franco Angeli, 1992), e La traduzione specializzata, di Federica Scarpa (Hoepli, 2001).

Abbiamo già toccato, poi, la controversa questione dell'ipotetico "approccio americano" rispetto a un "approccio italiano". Posta questa premessa, direi che la qualità di una traduzione dipende largamente dalla sensibilità del traduttore e dalle scelte dell'editore.

Alcuni editori hanno una politica linguistica abbastanza precisa: prediligono cioè uno stile impersonale, senza discorso diretto (nessun soggetto in prima persona, né singolare né plurale, e indicazioni in forma indiretta: "aprire il menu…" oppure "si deve fare clic…", "si faccia attenzione…" eccetera).
Altri editori lasciano libertà di scelta al traduttore e restano abbastanza aperti o indifferenti a questi aspetti. Alcuni, ma è raro, preferiscono esplicitamente un approccio diretto e colloquiale. Anche nei confronti delle battute e delle espressioni gergali l'atteggiamento degli editori varia da caso a caso.

In generale, se il traduttore non riceve direttive in proposito, deve scegliere da solo la sua strategia. L'importante, secondo me, è che non si senta schiavo del testo originale e non si appiattisca su una traduzione letterale.

10) Cosa vuol dire calarsi nei panni dell'utente?

Poco fa abbiamo parlato del "modello di utente" implicito in ogni progettazione (di oggetti, servizi o manuali). Ora, per non ripetere considerazioni già abbozzate, sposterei il discorso su un altro piano: quello dell'editoria informatica e del relativo marketing. Parliamo quindi di utente nel senso di destinatario, target, cliente.

Di solito un editore informatico non si sobbarca i costi di specifiche indagini di mercato, salvo casi molto particolari. Il motivo è che, oltre a esigenze di risparmio (l'editoria è un campo in cui i margini di guadagno sono risicatissimi), i ritmi frenetici del mercato informatico scoraggiano simili imprese: i tempi sono strettissimi, e le indagini di marketing, se ben fatte, richiedono un impegno di qualche mese. In breve, ma questa è una mia semplificazione, un'indagine di marketing scatterebbe una fotografia (dei potenziali acquirenti/lettori) che sarebbe già vecchia prima ancora di essere sviluppata… E' difficile, quindi, che il target di un libro o di una collana sia raffigurabile come un preciso segmento di consumatori, identificabile per fascia di età, cultura eccetera.

Piuttosto, tutti gli editori tendono a differenziare libri e collane in base a una ipotetica e generica tripartizione dei lettori, sulla base del loro grado di competenza informatica: ci sono libri (o collane intere) dedicati ai principianti assoluti, altri dedicati a chi ha una discreta esperienza e altri ancora dedicati agli utenti espertissimi. Di solito il target di ogni libro viene evidenziato sulla copertina con apposite diciture, bollini o altri accorgimenti grafici. L'autore o il traduttore devono tenere conto innanzitutto di questa tipologia di destinatari, calibrando il più possibile l'approccio concettuale e linguistico.

11) - Qual è il percorso da seguire durante la stesura di un manuale?

Sinceramente non mi sento in grado di dare "ricette" in proposito. La creazione di un manuale è un processo complesso, come ogni altra forma di progettazione. Troppi fattori dipendono dal contesto: argomento, destinatari, vincoli di vario genere. Difficile quindi generalizzare, se non a prezzo di una certa astrattezza. Tuttavia posso raccontare, a titolo di esempio vissuto, ma senza alcuna pretesa di "esemplarità", la mia esperienza in ambito editoriale: come scrivo un libro di informatica.

Ogni libro nasce da un embrione: un'idea, una scaletta. Cioè una bozza di indice che rispecchia il progetto editoriale nel suo complesso. La scaletta richiede già una certa percezione globale dell'argomento, anche se all'inizio non è indispensabile avere chiari tutti i dettagli.

Con questo riferimento di massima, inizio una fase di esplorazione dell'argomento (supponiamo: un certo software). Se non lo conosco ancora, lo installo, lo provo, approfondisco le funzioni e le opzioni principali. Contemporaneamente ritocco la scaletta e preparo uno schema via via più preciso del libro, calibrando la segmentazione degli argomenti in capitoli e paragrafi.

In questa fase esplorativa cerco di mettermi nei panni del principiante e mi chiedo in quale ordine io stesso vorrei trovare esposte le spiegazioni. C'è anche un immediato risvolto operativo: comincio subito a catturare alcune schermate (immagini) del programma, alcune perché in seguito sarebbero impossibili da ricatturare (quelle dell'installazione), altre perché mi aiutano a farmi un'idea degli ingombri o sono un promemoria per le descrizioni da sviluppare in seguito sotto forma testuale.

A questo punto passo a imbastire lo scheletro del libro: un file per ogni capitolo, in cui inizio a scrivere soltanto i titoli della gerarchia di paragrafi e sottoparagrafi. Già così è possibile iniziare a valutare le dimensioni relative di ogni capitolo; inoltre, diventa molto più facile scrivere il testo, procedendo in modo non sequenziale ma a spirale, per accumulazione progressiva.

In altre parole, dopo aver preparato la struttura (dettagliata) dei capitoli, inizio a scrivere qua e là i paragrafi su cui mi sento più pronto, poi torno indietro a colmare i vuoti, salto avanti per aggiunte o proseguimenti, e così via. Un po' come tessere una ragnatela.

Nel frattempo realizzo man mano tutte le altre illustrazioni: schermate del programma ma anche, quando necessario, schemi e diagrammi per illustrare aspetti concettuali o di metodo. Gli schemi in forma grafica per me sono molto importanti (li uso io stesso quando devo memorizzare qualcosa): vanno studiati bene, e di solito li realizzo a metà del lavoro, quando ho raggiunto una buona visione d'insieme dell'argomento. Nel mio caso, poi, il rapporto tra testo e illustrazioni è dinamico, flessibile, non preordinato: a volte mi viene spontaneo prima scrivere e poi illustrare, a volte faccio il contrario (prima realizzo le illustrazioni e poi ne traggo ispirazione per stendere le relative spiegazioni).

In tutto questo processo, il tempo scorre in modo non omogeneo. La prima fase, quella dell'esplorazione e della sperimentazione, porta via un 50% della durata complessiva (dall'accettazione dell'incarico alla consegna dell'opera finita).

Poi stendo la struttura del libro, preparando lo scheletro dei singoli capitoli: una serie di titoli con semplici segnaposto (delle belle file di "xxxxxxxx"!) dove dovrò inserire i testi. Anche questa fase di strutturazione analitica va pensata e richiede un 10-20% del tempo globale.

Fatto questo, per me tutto è risolto. Resta il tempo materiale per la stesura: meno della metà del tempo globale. Di solito, infatti, inizio a scrivere piuttosto tardi: solo quando ho le idee chiare. Partendo da una valida struttura, e avendo già metabolizzato gran parte dei contenuti, il lavoro della scrittura in sé mi porta via poco tempo, e procede in accelerazione. All'inizio riesco a scrivere al massimo cinque pagine al giorno, mentre nelle fasi avanzate arrivo a dieci-quindici pagine. Aggiungendo le immagini (che realizzo in parallelo), il numero di pagine aumenta, a volte si raddoppia.

In genere riesco a realizzare un libro nel giro di un mese, un mese e mezzo. Questo è il quadro d'insieme, quando scrivo un testo originale. Quando invece traduco, lo schema e i tempi di lavoro sono molto diversi.

12) - Lei si è occupato anche di traduzione. La traduzione dei testi viene spesso fatta frettolosamente. Quanto è importante la presenza di traduttori tecnici specializzati? Secondo Lei, un buon traduttore tecnico ha le competenze necessarie per diventare redattore tecnico? Oltre alla formazione linguistica, quali sono le altre competenze richieste ad un redattore che non lavora in équipe?

Anche qui: non mi sento di formulare o richiamare regole generali, ma posso semplicemente raccontare qualche spunto personale. Un punto di vista parziale e discutibilissimo, ne sono certo.

Ho avuto esperienze di traduzione polarizzate verso i due estremi di un'ipotetica scala di argomenti. Infatti ho tradotto sia manuali estremamente tecnici (sui protocolli di rete) sia libri più discorsivi, creativi, divulgativi (sulla new economy e sulle implicazioni culturali-filosofiche delle nuove tecnologie).

Cominciamo dal primo caso, quello dei manuali iper-tecnici. Sinceramente è un'impresa che non mi sentirei di ripetere a cuor leggero. Volumi imponenti, dedicati ad argomenti specialistici: poco testo descrittivo, infinite sequenze di istruzioni, un'elevatissima densità di termini tecnici da rendere con assoluta accuratezza. In breve, ecco quei casi a cui accennavo, in cui la competenza tecnica deve plausibilmente prevalere su quella linguistica. Anche se è difficile scinderle: infatti sarebbe inutile ottenere un'accuratezza totale sul piano lessicale (i singoli termini tecnici), se poi la trama delle spiegazioni e i costrutti linguistici fossero inaccurati o addirittura fuorvianti (e a volte succede). Comunque non mi dilungo: è stata una gran fatica.

Diverso è il caso delle traduzioni più sostanziose e di qualità. Tradurre un bel testo, che richiede una comprensione di contenuti concettualmente stimolanti, è davvero piacevole.

Rispetto al lavoro di scrittura originale, tutto procede in modo più lineare. Di solito, leggo rapidamente una volta l'intero libro, o almeno lo sfoglio selettivamente per farmi un'idea d'insieme. Poi inizio a tradurre, seguendo l'ordine del testo (anche se a volte, ovviamente, occorre tornare sui propri passi e rivedere qualche passaggio o qualche criterio). Il tempo scorre in modo relativamente omogeneo: non si può dire che sia routine, ma sicuramente tradurre è un compito più prevedibile e costante rispetto al puro scrivere.

Eppure non è un compito meno creativo: tradurre, si sa, è un po' tradire. E deve esserlo. Le peggiori traduzioni sono quelle letterali. Sia chiaro: stiamo parlando comunque di manualistica, o di saggistica di carattere tecnologico. In altri campi valgono probabilmente regole diverse. Nel caso di libri, manuali o saggi su temi di informatica e nuove tecnologie, l'obiettivo è far comprendere i concetti-chiave.

La formulazione linguistica non è sacra, è solo un mezzo e non un'espressione artistica da salvaguardare. Là dove possibile, cerco di rispettare la personalità dell'autore e lo stile complessivo dell'opera. Ma una volta che riesco a immedesimarmi, mi sento assolutamente libero di riscrivere, letteralmente, interi paragrafi, se ritengo che in italiano ci sia un modo migliore per rendere lo stesso concetto. Una traduzione di questo genere deve essere, secondo me, un'opera di mediazione intelligente e lungimirante, più che un lavoro meticolosamente filologico. Ed è un impegno spesso appassionante.

Per usare una metafora olimpionica, direi in sintesi che scrivere un libro originale assomiglia al triathlon: una serie di impegni di natura differente, un ritmo variabile, in cui si alternano tempi lunghi e scatti brucianti. Tradurre un testo del genere è invece una maratona, o meglio un lungo percorso a ostacoli: un impegno più costante, una concentrazione omogenea, qualche impennata ogni tanto.

Giusto per proseguire la metafora, bisognerebbe citare infine la staffetta: i casi in cui si traduce a più mani. Qui le difficoltà aumentano, per via della necessità di sincronizzarsi sul piano linguistico. Di solito, l'ideale è che i due (o più, ma raramente) traduttori inizino subito a costruire un glossario comune, a uso interno, man mano che entrambi incontrano termini specifici, con un incessante scambio di pareri, consigli, riflessioni, in modo che le scelte finali siano assolutamente coerenti e il libro sembri tradotto da un'unica persona. Ma qui l'argomento si dilungherebbe ulteriormente.

13) - La presente tesi è suddivisa in due parti: la prima parte concerne la manualistica ed il mondo del technical writing, mentre, la seconda parte è dedicata alla terminologia ed all'analisi terminologica. La normalizzazione della terminologia influisce direttamente sulla creazione di testi tecnici di qualità. Cosa pensa di questo legame tra comunicazione tecnica e terminologia? La produzione di glossari affidabili e ben strutturati potrà facilitare il lavoro dei redattori tecnici?

Questo è un aspetto davvero problematico. Esistono alcuni dizionari tecnici, su carta, ma tutti quelli che conosco sono pessimi: scadenti, generici e poco aggiornati. Ci si trovano riferimenti alla preistoria dell'informatica (come il linguaggio Cobol o altri termini vetusti e ormai abbandonati) mentre mancano totalmente voci oggi cruciali, come in generale quelle relative alle tecnologie Internet. Molto meglio divorare le riviste del settore (mensili su informatica e Web), che pullulano di glossari aggiornati, mirati e ragionati. Questo come risorsa di base.

Nello specifico, alcuni editori (pochi, in verità) e soprattutto alcuni service editoriali, che spesso sono i mediatori tra l'editore e il traduttore, forniscono glossari specifici, magari in formato elettronico (figura 1). Qui si trovano le traduzioni "canoniche" dei termini più specialistici, a cui occorre rigorosamente attenersi.

In molti casi, comunque, il traduttore deve ingegnarsi e aggiornarsi spontaneamente, cercando sempre le fonti più accurate. Una risorsa interessantissima, per inciso, sono i dizionari online presenti su Internet, come quella famosissimo della Logos (www.logos.it): riferimenti vivi perché costruiti dagli stessi operatori del settore e in continua evoluzione/accrescimento.

A volte, peraltro, occorre tenere conto dei precedenti storici: se in un'edizione precedente un certo termine è stato tradotto in un certo modo, può essere opportuno restare fedeli a quella traduzione (che gli utenti potrebbero aver assimilato stabilmente), piuttosto che scegliere una nuova soluzione, per quanto sembri in astratto più appropriata. Dipende dalle circostanze.

Abbondano comunque le idiosincrasie, sia da parte dei traduttori che degli editori e persino delle software house (ad esempio, Microsoft ha un suo rigoroso glossario ufficiale).

Su alcuni argomenti ci sono punti fermi: un button su cui fare clic (ad esempio, un OK button) è un "pulsante" (il pulsante OK); solo un dilettante lo tradurrebbe come "bottone". Le finestre dei programmi e tutti i loro componenti (caselle di opzioni, menu eccetera) obbediscono a una terminologia standard che bisogna conoscere e rispettare.

In altri casi ci sono diatribe ancora aperte. Ad esempio, secondo la scuola di pensiero condivisa da Microsoft e dai puristi del settore, per quanto riguarda l'utilizzo del mouse l'espressione corretta è "fare clic" (N.B.: "clic" è italiano, "click" è americano!), e non l'obbrobrioso neologismo "cliccare". Il che sembra sensato: infatti, quando è necessario si può anche dire "fare doppio clic" o "fare clic col pulsante destro", evitando di doversi inventare forme improponibili come "doppiocliccare" o "destrocliccare".

Una discussione senza fine riguarda il verbo appropriato per l'utilizzo dello scanner (dispositivo per digitalizzare le immagini), che in inglese è semplicemente to scan: "scannerizzare"? "scansionare"? "scandire"? "scannare"?… Le unità di misura restano invariate (un byte è un byte), ma l'hard disk è il disco fisso (anticamente detto anche disco rigido…). Il dischetto però resta preferibilmente floppy disk anche in italiano. E via dicendo.

Possono sembrare disquisizioni buffe o persino assurde, una specie di versione hi-tech dell'Accademia della Crusca. Ma conta anche questo. E poi, a ben vedere, in Italia siamo ancora ragionevoli: basta pensare allo sciovinismo francese, che impone una localizzazione di tutti i termini informatici, con esiti davvero maniacali e ridicoli.

In ogni caso, trovo singolare, divertente ma anche molto interessante il fatto che, dietro le quinte, un argomento freddamente tecnico come l'informatica stia animando un vivo dibattito su questioni linguistiche e culturali, inducendo gli autori e i traduttori a ripensare criticamente la stoffa del loro lavoro. Che una lingua sia viva lo si vede anche da questi retroscena.

Di esempi e aneddoti ce ne sarebbero a bizzeffe. I più gustosi, comunque, riguardano probabilmente l'abisso che corre tutt'oggi tra la traduzione effettuata da un essere umano e la traduzione effettuata da una macchina. Potremmo propriamente parlare di un confronto fra traduzione umana e traduzione automatica, o meglio fra traduzione umana e traduzione disumana…

I software per la traduzione automatica sono ben lontani dalla perfezione. Nessuno si azzarda a utilizzarli in ambito professionale, se non alcune software house che ritengono economicamente vantaggiosa questa soluzione. Non tanto nel caso dei manuali cartacei, quanto piuttosto nel caso delle guide in linea e dei manuali in formato elettronico, capita di vedere esempi di drammatica o esilarante inefficacia: invariabilmente, la ragione è che il produttore ha avuto l'ardire di effettuare in proprio e all'origine la traduzione (ricorrendo pesantemente a traduttori automatici), anziché affidarla a un'équipe professionale del Paese di destinazione. Lo stesso problema affligge la traduzione (in gergo: localizzazione) di molti programmi: nomi dei menu, comandi e opzioni risultano spesso comici o incomprensibili.

Qualche esempio dei risultati finali? "Passeggiata" invece di "percorso" (path: la posizione di un file nella gerarchia di cartelle e sottocartelle di un disco fisso), "Produzione libraio" invece di "Libreria di produzione" (production library: una raccolta di file, icone, materiali vari per integrare un progetto), "Lettore filmato attivo" invece di "Lettore ActiveMovie" (ActiveMovie è un termine tecnico legato ai file video), e così via (figura 2). Ci sono esempi ben noti agli addetti ai lavori, come l'indimenticabile "bastoncino della gioia" (più noto come joystick) o un famosissimo pseudo-manuale IBM per la manutenzione dei mouse zeppo di involontari doppi sensi ed esilaranti equivoci (figura 3). In gran parte però si tratta di leggende metropolitane. Altri esempi reali, invece, tratti da un programma per il montaggio video su PC, sono illustrati nella figura 4. Altri ancora sono illustrati nella figura 5 (manuale di un monitor per PC).

(N.B. - a proposito di traduzione automatica online, vedere anche il profilo di Alois Haba)

14) - Esistono norme UNI ISO che regolano la stesura dei testi istruzionali, fornendo alcune indicazioni redazionali generiche. Secondo Lei, queste norme sono conosciute e consultate da coloro che operano nel mondo del technical writing?

Per valutare quanto e come tali norme possano essere applicate sul campo, rivolgerei la domanda a qualche technical writer professionista che lavori in ambito aziendale, specialistico (posso citare ad esempio Vilma Zamboli, www.writec.com, come molti altri).

Da un punto di vista teorico e metodologico, temo che simili normative non siano particolarmente efficaci. Posso fare un paragone con le norme UNI ISO che riguardano le interfacce software: non conosco nessun esperto di usabilità o di ergonomia cognitiva che le consideri un valido ausilio progettuale (sebbene siano naturalmente un riferimento da tenere presente, almeno sul piano formale). Il fatto è che si tratta per lo più di norme astratte, generiche, spesso arretrate: perennemente in ritardo rispetto allo stato della ricerca e della professione.