sabato 25 maggio 2013

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...

martedì 21 maggio 2013

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...

martedì 7 maggio 2013

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...

domenica 5 maggio 2013

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...

mercoledì 1 maggio 2013

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...