Il nuovo sondaggio di Sharon Burton: da scaricare e da valutare

Lo scorso anno vi avevo segnalato un'indagine condotta da Sharon Burton intitolata: "Consumer Feelings About Product Documentation".

Durante il 2013 Sharon ha continuato a raccogliere dati ed ha arricchito il sondaggio con altre 3 domande (numero 14, 15 e 16) inerenti alla "qualità" della documentazione di prodotto che, in qualche modo, viene percepita dal cliente.

Dai risultati della Domanda 14 emerge chiaramente come i consumatori si aspettino un'elevata qualità della documentazione che accompagna un prodotto proporzionale al suo prezzo (52%). Ma almeno un consumatore su 3 si aspetta comunque un'elevata qualità anche indipendentemente dal prezzo del prodotto.



La Domanda 15 è indicativa delle aspettative dei consumatori rispetto al prezzo del generico prodotto. Personalmente sono molto sorpreso dal fatto che il 37% degl intervistati si aspetta di trovare della buona documentazione anche per prodotti dal prezzo bassissimo, nella fascia che va da 0 a 25$! Ma questo dato conferma quanto emerge dalla 14.



I risultati della Domanda 16 sono DEVASTANTI: pochissimi utenti sono disponibili a pagare qualcosa "di più" per ottenere una migliore documentazione. Il 66% da per scontato che una documentazione di buon livello DEVE essere inclusa nel prezzo.



Seguendo questo link, potete scaricare liberamente un PDF che contiene un estratto dell'indagine. Se volete un documento più esteso e completo, potete acquistarlo presso Amazon per poco più di 7$, nella versione per Kindle.

Fatemi avere le vostre impressioni. Leggi questo articolo...

Dalla scrittura monolitica alla scrittura modulare: DITA overview (dal blog di Petra Dal Santo)

Da un po' di tempo stavo preparando un lungo post per offrirvi una visione generale e completa su DITA (Darwin Information Typing Architecture), uno degli standard più importanti per la strutturazione dei contenuti tecnici.

Ma all'inizio della settimana mi sono accorto che Petra Dal Santo, sul suo blog, aveva pubblicato un ottimo articolo sull'argomento, sollevandomi dal gravoso incarico di terminare la mia fatica!

E in onore al principio del "riuso dei contenuti", vi invito a leggere il suo lavoro, molto ben realizzato.

DITA nasce nella pancia di IBM e viene poi "regalato" alla comunità "open" come standard OASIS.
IBM, fin dall'inizio degli anni '90 del secolo scorso, si trovò a dover gestire migliaia di manuali, con una rilevante percentuale di ripetizione dei contenuti. Come razionalizzare tutto il ciclo di sviluppo e produzione della manualistica, migliorando la qualità dei contenuti, abbattendo i costi e i tempi di realizzazione? La risposta fu DITA, una metodologia basata sullo standard XML che consente di realizzare contenuti ri-usabili e topic-oriented.

Vi rimando al lavoro di Petra per una panoramica di tutte le caratteristiche salienti e mi limito ad una considerazione "filosofica".

Da molti anni, anche tra coloro che apprezzano DITA, si discute sulla sua effettiva "semplicità d'uso".

Io non utilizzo DITA per produrre la documentazione tecnica di CrossIdeas, l'azienda in cui lavoro. E il motivo è semplice.

Lo sforzo iniziale che si richiede per produrre documentazione secondo le regole di DITA è molto elevato ed è giustificabile solo se:

• i volumi di documentazione da produrre sono notevoli;
• la % di ripetizione dei contenuti è apprezzabilmente congrua e costante nel tempo;
• si è ragionevolmente certi che tali parametri rimangano invariati nel medio-lungo periodo (alcuni anni).

Inoltre, è altamente improbabile che siate in grado, al primo progetto, di mettere su un processo di authoring e publishing "DITA-based" se non vi affidate alla consulenza esterna di professionisti esperti, che possano fornirvi un minimo di formazione di base e vi possano aiutare ad avviare i necessari processi.

In altri termini, DITA è una straordinaria metodologia per le esigenze di IBM (che produce i suoi manuali con questo standard) e per altre grandi aziende che producono tecnologia, ma dubito che una piccola/media impresa  possa investire su DITA per produrre i suoi 15-20 manuali, che descrivono prodotti che cambiano rapidamente nel tempo.

Ma questa è solo la mia opinione. Aspetto le vostre indicazioni. Leggi questo articolo...

Come si forma un comunicatore tecnico: quarta parte

Nel post precedente di questa serie, partendo dalla definizione ufficiale della STC, ho iniziato ad abbozzare il perimetro delle competenze che deve avere un comunicatore tecnico, individuando 3 aree:

• COMPETENZE FONDAMENTALI 
• COMPETENZE SPECIALISTICHE
• COMPETENZE COMPLEMENTARI

Queste 3 aree poggiano a loro volta su le 3 colonne portanti che ho già descritto e che costituiscono "le fondamenta" sulle quali possiamo immaginare di costruire il nostro "edificio" professionale, che riassumo nella triade: preparazione linguistica, preparazione tecnica, attitudine (talento?) per la comunicazione.

Ma le fondamenta, appunto, sono "solo fondamentali" e da sole non bastano, perchè vanno a definire solo il vostro "potenziale" professionale.

Come cantava Gaber "...un'idea... se rimane soltanto un'idea è solo un'astrazione... se potessi mangiare un'idea, avrei fatto la mia rivoluzione...".

Quindi il vostro"potenziale" può anche rimanere inespresso per sempre, se non si misura con le COMPETENZE che dovrete faticosamente acquisire.

COMPETENZE FONDAMENTALI

Teoria della Comunicazione: è bene conoscere i paradigmi di base (Shannon) della buona comunicazione, le sue implicazioni psicologiche, i rudimenti della semiologia, le regole essenziali della comunicazione scritta e orale (...che non sono quasi mai sovrapponibili).

Principi essenziali di scrittura professionale: saper descrivere concetti complessi con un linguaggio semplice, preciso e conciso. Padroneggiare processi di scrittura e di analisi del testo, editing e proofreading, tecniche di scrittura ed aspetti stilistici, concetti tipografici, saper definire regole di redazione e template per diversi tipi di documenti, conoscere la struttura standard dei documenti professionali più comuni (il Case Study, il White Paper, la Newsletter, la Scheda Tecnica, la Scheda di Collaudo, ...). Inoltre, è essenziale conoscere le regole di adattamento della scrittura rispetto al target di pubblicazione: scrivere per il web non è come scrivere per produrre un documento cartaceo.

Comunicazione Visuale: un'immagine/uno screenshot ed una didascalia di una sola riga sono quasi sempre più espressive di 6 righe di noiosissimo testo. Le regole per combinare testo e immagini non sono così scontate. E' necessario conoscere i principi per manipolare un'immagine, i formati più diffusi e le loro caratteristiche, acquisire confidenza con i software più comuni che possono aiutarci in questa attività.

Direttive, regolamenti e standard per la Comunicazione Tecnica: in base al settore in cui opererete, sarà opportuno conoscere gli standard e le normative che devono essere osservate nella realizzazione dei documenti. Se scrivete manuali per una macchina, dovrete avere cognizione della Direttiva Macchine. Se scriverete documenti in ambito medico-scientifico, dovrete attenervi ad una serie di regole e terminologie specifiche DI QUELL'AREA.

Principi di Project Management e pianificazione/sviluppo della documentazione: Come si costruisce un'intervista strutturata? Come si raccolgono le informazioni che ci necessitano?  Come si pianifica lo sviluppo di un documento? Quali obiettivi ci prefiggiamo? Come si gestisce il ciclo di vita della documentazione aziendale? Come si valutano i costi del processo di sviluppo della documentazione? Queste e altre domande, prima o poi, busseranno alla vostra porta...

Principi di usabilità: per chi stiamo scrivendo? Per un partner tecnologico molto esperto o per l'utente finale?
Quale canale ospiterà i nostri contenuti? Se dobbiamo produrre documentazione per realizzare manuali stampabili, dovremo organizzare le nostre informazioni secondo la gerarchia classica di un libro (capitoli, paragrafi, sottoparagrafi,...). Ma se dobbiamo creare un Help on Line, le stesse informazioni potranno essere navigate come un ipertesto, quindi cambia il modo in cui verranno organizzate. Se poi il nostro HoL deve essere visualizzato sul piccolo schermo di un smartphone, la sua natura dovrà essere ben diversa dall'analogo che possa essere fruito attraverso lo schermo più comodo di un laptop.

Strutturazione e standardizzazione dei contenuti: Information Mapping, Guide di Stile, Mappe Mentali, XML, CSS, DTD, DITA, indicizzazione e altro ancora. Ci sono molte metodologie e standard tecnici per la definizione e la strutturazione dei contenuti. Tali elementi possono essere combinati tra loro in diversi modi per ottenere gli obiettivi che ci prefissiamo.

COMPETENZE SPECIALISTICHE

Terminologia, localizzazione ed internazionalizzazione: sarà capitato anche a voi il collega stupidotto che, dovendo tradurre un documento tecnico in un'altra lingua, vi dice che "non c'è problema, lo faccio fare alla mia amica russa... è madrelingua!" ... oppure... "lo facciamo fare al nostro partner commerciale tedesco che capisce l'italiano...". Ecco, se uno si vuole auto-consegnare la patente del cretino, queste sono due frasi perfette per l'occasione! Per tradurre un documento tecnico non basta un "madrelingua", non basta un traduttore professionista, ci vuole un traduttore TECNICO professionista, anzi per essere più precisi un LOCALIZZATORE TECNICO. Un comunicatore tecnico che sia anche un localizzatore è una perla rara. Può anche accadere che un traduttore tecnico possa diventare un ottimo comunicatore tecnico. In ogni caso, un comunicatore tecnico deve conoscere almeno i principi di base della localizzazione terminologica, deve essere in grado di accedere a dei glossari settoriali, deve conoscere almeno le basi dei processi di traduzione, le memorie di traduzione e i CAT Tools, almeno nelle loro funzionalità di base. Tutto ciò gli consentirà di relazionarsi con un localizzatore, per integrare meglio le rispettive competenze.

Help on Line (HoL): se scrivete documentazione in ambito software, prima o poi qualcuno vi affiderà lo sviluppo dell'Help on Line dell'applicazione. Anche qui dovrete imparare ad usare tools specifici e vi accorgerete che strutturare i contenuti di un manuale tradizionale NON E' EQUIVALENTE a strutturare un HoL.

Tools professionali: non solo software per l'elaborazione dei testi o per la manipolazione delle immagini, ma anche CMS (Content Management System) e CCMS (Component Content Management System) sono ormai strumenti d'uso comune.

Guide di Stile: scrivere un manuale per un utente americano, per un prodotto software, per un'area tecnica settoriale può richiedere l'applicazione di nomenclature e regole stilistiche specifiche, non sempre intercambiabili.

COMPETENZE COMPLEMENTARI

Capacità gestionali e di relazione: saper definire le fasi di  un progetto editoriale, seguire ed ottimizzare tutte le fasi del ciclo di sviluppo della documentazione, predisporre iniziative innovative e definizione di metriche per la valutazione dell'efficenza dei processi di produzione della documentazione, seguire l'evoluzione tecnologica, saper lavorare in team, saper motivare i collaboratori e gestire eventuali conflitti: tutto ciò contribuisce a definire un'evoluzione professionale sempre più ricca di contenuti. Tali qualità si acquisiscono con lo studio e l'esperienza e si innestano sulle competenze fondamentali per potenziarle e valorizzarle.

Capacità di formazione: saper trasmettere le proprie conoscenze professionali in azienda o usare le tecniche della comunicazione tecnica per realizzare attività di training per i partner e/o i clienti che utilizzano i prodotti/servizi  realizzati dalla propria azienda.

Capacità di integrare diversi tipi di comunicazione: la scrittura, le immagini e la grafica, i video, la visual business intelligence, i principi della User Experience, la semiotica, i social media e il web. Chi di voi oggi potrebbe tracciare dei confini netti e asciutti tra questi ambiti/discipline/modalità, ognuno ben definito ma tutti sempre più fluidi e mutuamente contaminanti?

Ecco... ora avete una traccia, se pur parzialissima e sintetica, di quanti e quali competenze necessitano ad un Comunicatore Tecnico.

Così quando qualcuno vi chiederà "Di cosa ti occupi?... Scrivi manuali?... Cioè?", potete dargli il link per leggere questo post! Leggi questo articolo...

MadCap Flare full immersion: scusate l'assenza...

Scusate per la latitanza dal blog, ho più di un post in divenire che non riesco a chiudere e a proporvi, ma sono totalmente preso dal "giocattolo nuovo", MadCap Flare.

Sto imparando ad usare questo prodotto e non solo per passione e diletto, visto che dovrò presto mettere in campo un nuovo Help on Line.

L'impresa non è banale, visto che solo per la gestione degli stili c'è un manuale di quasi 900 pagine!

Vi farò sapere...

Nel frattempo, vi segnalo uno SPLENDIDO articolo di Petra Dal Santo dal suo blog.

In questo momento, stiamo trattando argomenti analoghi, ma fra di noi non c'è concorrenza, anzi, l'unione fa la forza! E per unione s'intende l'idea di divulgare i vantaggi della pubblicazione di documenti basati su una gestione strutturata e "single source", usando strumenti adatti allo scopo e abbandonando una gestione "artigianale" della documentazione aziendale.

A presto!

Leggi questo articolo...

Il prossimo 26 Giugno a Milano, seminario COM&TEC: come cambia la comunicazione tecnica aziendale

Vi segnalo un evento COM&TEC che si svolgerà a Milano il prossimo 26 Giugno, dal titolo:

Come cambia la comunicazione tecnica aziendale: strumenti e processi.

Il programma è interessante ed è una delle pochissime occasioni di confronto su questo tema che possiamo avere sul territorio italiano.

Il tema del resto mi è molto caro, tanto da aver iniziato a scrivere un serie di articoli "di base" per descrivere la logica attraverso la quale si deve migrare da una produzione tradizionale, artigianale, di documentazione "monolitica", ad una produzione incentrata sulla "modularizzazione" dei contenuti e su processi automatizzati.

Per chi è interessato, di seguito i link ai primi 4 articoli della serie:

Dalla scrittura monolitica alla scrittura modulare

1. Prima parte
2. Seconda parte
3. Terza parte
4. Quarta parte

E' in fase di sviluppo il 5° articolo, poi altri seguiranno.

In sintesi, direi che quella del 26 Giugno è una bella occasione per una presa di contatto con la necessaria evoluzione dello sviluppo dei contenuti aziendali, che sono sempre più strategici per il successo di un'azienda. Chi può, ne approfitti. Io conto di esserci.

Leggi questo articolo...

L'Esattezza secondo Calvino: un insegnamento anche per la comunicazione tecnica

Ho spesso sostenuto che la "scrittura tecnica" è un tipo di scrittura molto specialistica, ma sempre di scrittura trattasi, non nasce su Marte e non è "altro" rispetto alle regole generali, di base, della buona scrittura.

Un calciatore, un pugile o un maratoneta praticano tutti la corsa di fondo, se pur con modalità diverse, perchè la corsa di fondo è un buon esercizio di base per migliorare la resistenza organica di qualsiasi atleta; allo stesso modo, un comunicatore tecnico dovrebbe, di tanto in tanto, riprendere confidenza con i classici.

E la lezione sull'Esattezza di Italo Calvino è particolarmente interessante per un comunicatore tecnico.

Per questo vi segnalo un bell'articolo di Alessandro Lucchini, uno dei pochi "guru" italiani della scrittura su web dai cui scritti molto ho imparato quando, nel 2005, ho iniziato ad occuparmi di comunicazione tecnica ed ho trovato nella Palestra della Scrittura un luogo dove ho rubato/assorbito idee e ispirazioni che spero di aver messo a frutto, almeno in parte.

Lucchini parte dal nucleo della lezione di Calvino sull'esattezza:

"... Esattezza vuol dire per me soprattutto tre cose:

1) un disegno dell’opera ben definito e ben calcolato;

2) l’evocazione di immagini visuali nitide, incisive, memorabili;

3) un linguaggio il più preciso possibile come lessico e come resa delle sfumature del pensiero e dell’immaginazione."

...e poi alza lo sguardo su aspetti dell'uso della lingua che sono parte viva anche della nostra quotidianità e che spesso ci sgomentano, come il seguente:

"Per mancanza di moneta divisionale i pazienti solventi sono pregati di presentarsi allo sportello muniti della suddetta."
... e pare che Munch, dopo aver letto questo, abbia dipinto il suo "Urlo"!

Cosa è l'Esattezza per un Com Tec? Per me significa:

1) scrivere tutto e solo quello che serve per comunicare un concetto
2) rafforzare quello che scrivo con supporti visuali (grafici, tabelle, immagini) che facilitino la comprensione del concetto
3) realizzare quanto ai punti 1 e 2 con la massima sintesi e proprietà di linguaggio, semplificando all'osso la struttura della frase

In particolare, estrapolo un brano dal testo originale di Calvino:
"... le lingue naturali dicono sempre qualcosa in più rispetto ai linguaggi formali, comportano sempre una certa quantità di rumore che disturba l’essenzialità dell’informazione...".

In molte occasioni vi ho indicato come abbattere il rumore della comunicazione sia l'aspetto FONDAMENTALE della comunicazione tecnica.

Come vedete, le idee di Calvino possono servire anche per scrivere della buona comunicazione tecnica. Leggi questo articolo...

Appunti sulla Comunicazione Tecnica: il blog di Petra Dal Santo

Quando ho iniziato nel 2009 ero pressocchè da solo. Ora, per fortuna, altri professionisti della Com Tec si affacciano in rete con i loro blog. In realtà, alcuni di loro sono da tempo in rete con i propri siti aziendali, ma il blog è uno spazio diverso dal sito aziendale, anche quando è collegato e funzionale a quest'ultimo.

Oggi vi segnalo Petra Dal Santo ed il suo blog, Appunti sulla Comunicazione Tecnica.

Petra ricopre dal 2000 il ruolo di Project Manager in Kea, società di cui è anche socia.

La Kea è una società italiana che fornisce servizi di documentazione tecnica ai propri clienti e il cui fiore all'occhiello è Argo, un CMS che aspira a confrontarsi con i migliori prodotti americani presenti sul mercato.

Dal mese di Febbraio di quest'anno, Petra ha messo in rete e gestisce il blog aziendale della Kea. Ovviamente, come qualsiasi blog aziendale, tende giustamemente a dare risalto alle soluzioni prodotte in casa, ma non si limita a questo solo compito "istituzionale".

Vi segnalo, ad esempio, un post sui criteri con i quali ci si deve orientare per la scelta di un CMS: in questo post Petra parla ovviamente anche di Argo, ma illustra sinteticamente delle linee guida di base che possono essere utili a chiunque stia pensando di trasformare i processi di sviluppo della documentazione, da una modalità "artigianale" e "monolitica" verso una modalità "automatizzata" e "modulare".

Io e Petra ci conosciamo da più di due anni. La contattai per avere una demo di Argo e non ci siamo più persi di vista. Condividiamo l'idea che si debba operare, in qualche modo, per diffondere la cultura della comunicazione tecnica, per spiegare gli enormi vantaggi che un 'azienda può ricavare da una gestione ben organizzata della produzione della documentazione di prodotto e di progetto, superando la visione retrograda che vede la produzione della documentazione soltanto come un "costo", visione per altro destituita di ogni fondamento, come i dati ormai ci dimostrano ampiamente.

E in Italia, in tal senso, c'è una prateria quasi vergine da seminare!

Io faccio del mio meglio, con il mio blog a cui posso dedicare solo poche ore alla settimana. Ora c'è anche lei.

Andate sul suo blog, ci sono cose molto interessanti da scoprire... poi però tornate anche qui!

Leggi questo articolo...

Dalla scrittura monolitica alla scrittura modulare: quarta parte

Nel post precedente abbiamo iniziato a fare i primi concreti passi nel tema della scrittura modulare.

 

Prima di poter anche solo in parte apporofondire gli aspetti più "tecnici" della questione, presumo di dovervi convincere che il gioco vale la candela. Perchè dovreste abbandonare il modo "tradizionale" di scrivere documenti per la vostra azienda, a vantaggio di una nuova modalità che richiede di sicuro una curva d'apprendimento non banale? Per ALMENO 6 buonissimi motivi, che proverò ad esporre brevemente di seguito.

ZERO ERROR UPDATE
In un'architettura modulare, se un contenuto è replicato in N documenti, sarà necessario modificarlo una sola volta; le modifiche effettuate verranno propagate automaticamente in tutti i documenti in cui il contenuto è collocato, riducendo drasticamente le possibilità di errore che sono naturalmente implicate dalla necessità di effettuare N modifiche "a mano" in N documenti distinti.

RIUTILIZZO DEI CONTENUTI
Lo stesso contenuto può essere collocato in N documenti distinti. Questa proprietà dipende anche dalla "granularità" dei contenuti; più la granuralità di un contenuto è "fine", maggiore è la probabilità che quel contenuto possa essere collocato in ambiti diversi. Ovviamente, un eccesso di granularità può implicare problemi di gestione non banali, quindi devono essere utilizzati opportuni criteri per "spezzettare" il documento monolitico originario nel modo migliore, con la granularità più utile ai nostri scopi.

DOCUMENTI MULTICANALE
Ricordate la faccenda dei "contenuti puri" scorrelati dalla "forma"? Perfetto, visto che abbiamo contenuti puri, in che modo li vogliamo vestire? Vogliamo produrre una Scheda Tecnica in  formato DOC o PDF? Vogliamo un Help on Line per Android? O vogliamo dei contenuto Web visualizzabili da un browser qualsiasi, da IE a Firefox? Non è un problema nostro, nel senso che i nostri contenuti, puri e modulari, possono essere vestiti secondo stili e formati diversi. Gli aspetti tecnici di questo passaggio non sono oggetto di questo post, sappiate solo che si può fare.

DOCUMENTI MULTILINGUA
Se ho un contenuto modulare, scritto in italiano, posso immaginare di tradurlo in tutte le lingue che mi servono. A quel contenuto si applicano tutte le considerazioni già illustrate in precedenza, per tutte le lingue che vi servono.

GESTIONE COLLABORATIVA
E' raro che una sola persona abbia la conoscenza per realizzare ogni parte di un documento tecnico. Più di frequente, una sola persona si trova a fare da collettore di molte informazioni diverse provenienti da fonti diverse. Tutto ciò può anche funzionare quando ci troviamo a lavorare su un numero molto limitato di documenti; ma immaginate di dover gestire anche solo 20-30 documenti diversi, con un tasso di aggiornamento anche solo del 30% annuo. Cosa succederebbe se fosse possibile assegnare a K persone diverse lo sviluppo di un documento? Ognuno svilupperebbe la parte di sua competenza (Giallo, Verde, Rosso, ...), senza interferire con il lavoro degli altri, condividendo solo un certo insieme di regole comuni definite nell'ambiente di sviluppo, abbattendo drasticamente i tempi di realizzazione.

INTEGRAZIONE TECNOLOGICA (XML, DITA)
Contenuti "puri", modulari, riutilizzabili. E con quale "vestito" tecnologico? E secondo quale metodo di definizione? Qui ci stiamo spingendo molto avanti, anche se è probabile che molti di voi abbiano già confidenza con lo standard XML, mentre dubito che abbiate lo stesso grado di confidenza con DITA.
Ma ora quello che importa è focalizzare il concetto che esistono diversi "mondi" paralleli in grado di manipolare contenuti modulari, secondo regole che implicano vantaggi e svantaggi, mentre NESSUNO DI QUESTI MONDI è in grado di gestire ed accogliere i vostri tradizionali documenti "monolitici".

Vi ho convinto? Ancora no? E allora riprendiamo un esempio già esposto nel post precedente.

Abbiamo sempre i nostri 12 documenti che ospitano il Glossario, la Bibliografia e le Licenze di parti specifiche contenute nel prodotto ma realizzate da terze parti.

In più, decidiamo di tradurre i nostri 12 documenti in 3 lingue: inglese, spagnolo e russo.

Abbiamo già visto che, dovendo modificare il Glossario, la Bibliografia e i termini delle Licenze, se tali elementi sono immersi in 12 doc monolitici, bisogna realizzare ALMENO 3 modifiche in 12 documenti distinti, per un totale di 36 modifiche "fisiche" distinte. E a questo punto abbiamo sistemato i documenti scritti in italiano.

Ma ora dobbiamo anche tradurre le parti appena modificate in 3 lingue, quindi  dobbiamo riportare le 3 modifiche in 12 documenti (per ogni lingua), cioè 36 modifiche "fisiche" distinte per ogni lingua, quindi 36 x 3 = 108 modifiche "fisiche" disitinte (se preferite, 9 x 12).

In totale quindi 36 + 9 + 108 = 153 modifiche distinte.

Ma se questi 3 elementi informativi sono 3 elementi modulari, indipendenti, memorizzati in un Data Base e scorrelati da altri vincoli... cosa cambia? Se li concepiamo così, dobbiamo fare soltanto:

• 3 modifiche sui contenuti in italiano
• 3 traduzioni per ogni modifica, quindi 9 modifiche/traduzioni

... per un totale di 12 modifiche "fisiche" distinte.

I contenuti aggiornati verranno poi "propagati automaticamente" in qualche modo nei 12 documenti che ci servono, nelle 4 lingue considerate (italiano, inglese, spagnolo e russo).

Quindi siamo passati da 153 modifiche "fisiche" a sole 12 modifiche.

Infine, sempre la stessa domanda: se invece di 12 documenti dovessi aggiornare questi contenuti in 120 documenti diversi, quante modifiche/traduzioni dovrei apportare? SEMPRE E SOLO 12!

Ora vi ho convinto?


Leggi questo articolo...

Come si forma un comunicatore tecnico: terza parte

La Society for Technical Communication (STC) ci fornisce questa definizione:

Technical writing is a broad field that includes any form of communication that exhibits one or more of the following characteristics:

• communicating about technical or specialized topics, such as computer applications, medical procedures, or environmental regulations;

• communicating by using technology, such as web pages, help files, or social media sites;

• providing instructions about how to do something, regardless of how technical the task is, and regardless of whether technology is used to create or distribute that communication

Nel mio post precedente, con minor capacità di sintesi, vi ho esposto il mio punto di vista riguardo il fatto che la dizione "technical writer" di fatto debba essere soppiantata dalla dizione Technical Communicator.

Mi sembra che anche la definizione della STC sia orientata in tal senso, ma avvitarmi in una disquisizione formalistica è proprio l'ultimo dei miei pensieri, mentre mi sembra interessante mettere sul tavolo una questione di metodo: per capire cosa mi serve per fare il mio lavoro, per capire cosa devo studiare e come mi devo formare, devo capire quali sono i diversi aspetti del mio lavoro, i diversi "cappelli" che devo indossare, in ultima analisi le competenze che devo acquisire.

Alla base, ci deve essere una buona predisposizione/preparazione linguistica, almeno per quanto riguarda tutti gli aspetti generali e fondamentali. Se avete una preparazione linguistica ottenuta attraverso un percorso accademico ben strutturato è meglio. In caso contrario, avere passione per la lettura e la scrittura aiuta; curiosità per le parole, confidenza con terminologie settoriali, un continuo allenamento anche inerente a diversi stili di scrittura, non necessariamente tecnici. Tutti questi aspetti vanno a definire una "base" ineludibile, un pò come la corsa di resistenza è la base per moltissimi sport.

Un secondo architrave su cui poggiare il vostro "edificio professionale" è la preparazione tecnica.
A mio avviso è molto meno fondamentale di quella linguistica, ma può facilitarvi nel velocizzare la comprensione delle tematiche che andate ad illustrare. Io sono un ingegnere informatico che normalmente documenta prodotti software, ma i miei studi di elettronica e di fisica mi aiuterebbero anche nel caso in cui dovessi scrivere il manuale di manutenzione di un impianto fotovoltaico. Se non siete ingegneri, è comunque necessario che abbiate passione e curiosità per la tecnologia, altrimenti non credo che possiate fare bene questo lavoro.

Poi dovete avere anche un briciolo di talento naturale per la comunicazione: dovete aver voglia di spiegare, insegnare, divulgare. E lo dovete fare nello stile di un comunicatore tecnico, ovviamente; ma ricordatevi che lo stile si può imparare, il talento si può solo perfezionare e amplificare, ma deve essere già presente.

Ma queste 3 colonne portanti sono solo le fondamenta dell'edificio professionale di cui sopra. Per costruire le mura, i solai e le diverse stanze dobbiamo classificare le competenze che un Tech Comm deve possedere.

Alcuni amano fare una suddivisione basata sul "livello" professionale (junior, senior, master/advanced) ma nella mia esperienza non è possibile definire dei confini di competenze ben netti sulla base di questo criterio.

Io preferisco classificare le competenze tentando di riconoscere 3 aree:

• COMPETENZE FONDAMENTALI

• COMPETENZE SPECIALISTICHE

• COMPETENZE COMPLEMENTARI
  

Al prossimo post, per i dettagli su ognuna di queste aree. Leggi questo articolo...