Non perdiamo i nostri documenti.

Ecco... il documento è quasi finito; un'intera giornata di lavoro... ora effettuo qualche ritocco... inserisco l'ultima immagine...ma...che succede? Schermata di allarme...l'applicazione è esplosa! E tutto il mio lavoro? TUTTA LA MIA GIORNATA DI LAVORO? DOVE E' FINITA? DOVE STA IL MIO FILE? PERCHE' NON L'HO SALVATO PRIMA? Calma... sicuramente starà da qualche parte... nel mio PC... in una qualche cache... forse... MA DOVE?

Chi scrive molti documenti, per diletto e/o per lavoro, usando il software più diffuso al mondo, Microsoft Office Word, almeno una volta nella vita ha vissuto la dolorosa esperienza di perdere una giornata di lavoro per via di un malfunzionamento dell'applicazione.

Ma non è difficile cautelarsi da tali eventi, se solo si ricorre alle possibiltà che Word ci mette a disposizione.

Le indicazioni che ora vi fornirò si riferiscono a Microsoft Office Word 2003 (per versioni diverse potrete facilmente individuare i passaggi corrispondenti).


Dalla barra dei menù, selezionare Strumenti>Opzioni, quindi selezionare il tab Salva:


Qui è necessario selezionare ALMENO le seguenti 3 check-box:

• Crea sempre copia di backup: ogni volta che salverete il vosto documento (cioè ricorrendo ad un comando esplicito di Salva/Salva con nome), verrà automaticamente salvata la versione precedente, nella stessa cartella in cui è ospitato il documento sul quale state lavorando.Il file della copia di backup ha estensione .wbk e viene salvato nella stessa cartella del documento originale.

• Consenti salvataggio in background: mentre lavorate, Word effettua un salvataggio in background, in una cartella che andremo a definire dopo; durante il salvataggio in background, nella barra di stato viene visualizzata un'icona a forma di dischetto lampeggiante.

• Salva automaticamente ogni X minuti: il salvataggio in background sopraindicato avviene ogni X minuti e crea automaticamente un file di recupero nell'intervallo specificato nella casella minuti, ove si può indicare un numero compreso tra 1 e 120. Se il PC si blocca o si verifica un'interruzione improvvisa della corrente, la volta successiva che si apre Word verrà visualizzato automaticamente il file di recupero contenente le informazioni che altrimenti sarebbero andate perse. Si noti che la caratteristica Salvataggio automatico non sostituisce il comando Salva. È necessario salvare esplicitamente il documento quando si termina di lavorare.
  

Selezionando queste tre opzioni, avrete la certezza che ogni X minuti, anche se vi dimenticate di salvare esplicitamente il vostro lavoro, il sistema lo farà per voi. La scelta di X deve essere ragionevole: io uso 30 ma può andar bene anche 60 o 120. Usando X=30 mi assicuro che, a fronte di un improvviso crash di Word, potrò perdere, nel caso peggiore, 30 minuti di lavoro.

Ma in quale cartella verranno effettuati tali salvataggi?
A questo punto dobbiamo selezionare il tab Directory predefinite.


Qui è sufficente selezionare, nella colonna Tipo file, l'elemento Salvataggio automatico file; in corrispondenza, sulla colonna Directory, è indicata la cartella in cui avverrà il salvataggio automatico, configurato come abbiamo visto in precedenza.

Se volete cambiare la cartella, premete il pulsante Modifica... e seguite la procedura per determinare una nuova cartella per il salvataggio automatico. Leggi questo articolo...

Saper scrivere... la Lettera di Presentazione.

Quando ci mettiamo alla ricerca di un lavoro, generalmente affidiamo al Curriculum Vitae (CV) tutte le nostre speranze, trascurando la valenza della Lettera di Presentazione, che dovrebbe accompagnare il CV.

La Lettera deve catturare l'attenzione del selezionatore, al fine di ottenere un colloquio. Essa serve ad introdurre il CV, chiarendo alcuni aspetti fondamentali riguardo ai nostri obiettivi e desideri.

Deve essere meno schematica del CV e non deve riprenderne i contenuti specifici, ma deve avere un carattere di "spontaneità organizzata", dalla quale devono emergere fondamentalmente:

- la nostra personalità
- le motivazioni che ci spingono a voler lavorare per quell'azienda

Il testo deve essere sobrio ma incisivo ed organizzato secondo uno schema ben preciso che indichi:

- a chi ci si rivolge
- perché ci si candida
- come si caratterizza la nostra candidatura

Lo stile è importante; nemmeno un genio dell'umanità, portatore di un'arca di scienza, può sopravvivere ad una lettera di presentazione contrassegnata da imperfezioni formali ed inacettabili errori ortografici, che vengono fatalmente interpretati come il "segno di Caino" della più sciatta approssimazione.

Prima di scrivere, dobbiamo informarci sull'azienda in cui vogliamo lavorare: possiamo studiare il sito Web aziendale, leggere articoli sui giornali, chiedere informazioni a persone che la conoscono e altro ancora.

Non c'è nulla di peggio di un candidato che in sede di colloquio non sa rispondere efficacemente alla più prevedibile delle domande:
"Lei sa di cosa si occupa la nostra azienda ?"

Le lettere di accompagnamento possono essere di due tipi:

LETTERA IN RISPOSTA AD UN ANNUNCIO -
In questo caso bisogna far sempre riferimento esplicito all'inserzione a cui stiamo rispondendo, con una frase diretta del tipo: "Mi permetto di presentare la mia candidatura per il posto di…".
Bisogna esplicitare la relazione fra le nostre doti ed i requisiti richiesti dall'azienda, nonchè richiamare i motivi che ci hanno portato a scegliere la professione in oggetto e a focalizzare l'attenzione proprio su quell'azienda.
In altri termini, dobbiamo far capire perchè abiamo "scelto" QUELLA azienda.
Ovviamente va inserito un riferimento al CV allegato alla lettera.
Quindi si conclude con le formule rituali di saluto e ringraziamento.

LETTERA DI AUTOCANDIDATURA -
In questo caso dobbiamo motivare adeguatamente la nostra candidatura, dobbiamo far capire perchè vogliamo lavorare in quella azienda.
Per il resto, valgono considerazioni analoghe a quelle già delineate nel caso precedente.

Ma quali sono i principali elementi di cui dobbiamo tener conto ?

Sul piano formale, ricordiamoci che la lettera di presentazione non deve essere identica per tutti i destinatari, ma personalizzata con riferimenti specifici all'azienda cui è indirizzata (prodotti, marchi, area di mercato, ...).
Dobbiamo usare la prima persona e scrivete la lettera al computer, non a mano.
Quindi inserire la firma in originale e specificate che alla lettera viene allegato il CV.

Sul piano sostanziale, distinguiamo principalmente tra le cose DA EVITARE e quelle DA EVIDENZIARE.

COSE DA EVITARE -
La lettera non deve essere troppo formale e fredda, che darà di noi un'idea di rigidità mai ben vista in un ambiente lavorativo, nè troppo pirotecnica e farcita di aggettivi esagerati, che ci farà correre il rischio di sembrare un "tele-venditore".

Sottolinere di essere "seri" e "motivati" non ha alcun peso... nessun datore di lavoro assume una persona inaffidabile e demotivata.

Non utilizziamo frasi negative o dubitative, del tipo:
"...non so se può interessarvi...", "...non ho proprio l’esperienza richiesta...", e similari.

Non millantiamo conoscenze o doti di cui non disponiamo... in sede di colloquio, un esaminatore accorto scoprirà facilmente il bluff.

Non proponiamoci per "qualsiasi posizione"; chi pensa di poter fare tutto, in un impeto di malintesa flessibilità, darà l'impressione di non saper fare nulla.

COSE DA EVIDENZIARE -
Usiamo uno stile propositivo, diretto ed efficace.

La conoscenza delle lingue, la capacità di lavorare in gruppo ed una buona capacità di comunicazione sono doti apprezzabili in ogni ambito professionale.

Un elemento decisivo è quello di evidenziare la relazione tra le nostre conoscenze, attitudini ed aspirazioni e le carattersitche dell'azienda a cui ci proponiamo; in questo modo daremo un messaggio di capacità di analisi e chiarezza di idee.

Spieghiamo cosa pensiamo di poter offrire all'azienda, indicando la nostra disponibilità a trasferirci, a frequentare uno stage, a lavorare senza orari.

Citiamo sinteticamente i principali titoli, eventuali master o altri corsi di specializzazione.

Il messaggio che deve arrivare al destinatario deve suonare più o meno così:voglio lavorare con Voi perché mi piacete e penso di essere la persona giusta.

Congediamoci con lo stesso stile, mostrandoci convinti rispetto alla possibilità di ottenere un incontro personale: se riusciamo a incuriosire la persona che ci interessa, è probabile che ci convochi per un colloquio o che, comunque, si ricordi di noi al momento giusto.

STRUTTURA GENERALE

Vediamo quali sono le parti fondamentali di cui si compone una lettera di presentazione:

DATI PERSONALI (in alto a sinistra):

• nome e cognome
• indirizzo
• numero di telefono

DATI DELL'AZIENDA (in alto a destra):

• nome dell'azienda
• nome della persona a cui si indirizza - "Alla cortese attenzione di:"
• indirizzo

CORPO DELLA LETTERA:
è opportuno iniziare sempre rivolgendosi alla persona e non parlare ad una generica e "spettabile" azienda: usate frasi del tipo: "Egregio Dottore/Signore/Ingegnere" per gli uomini, o "Gentile Dottoressa/Signora" per le donne.
Per i contenuti, valgono le indicazioni sopracitate.

FIRMA:
autografa, in originale, biro blù o nera

E nel prossimo post... alcuni esempi.
Leggi questo articolo...

Saper scrivere... un Tutorial.

Quando bisogna scrivere un manuale che verrà utilizzato da un utente poco esperto, l'approccio migliore è quello del Tutorial.

Un Tutorial è un documento in cui un certo argomento viene esposto in una modalità estremamente semplificata, attraverso delle descrizioni sintetiche, spesso in modalità "passo-passo", corredate da immagini di supporto finalizzate a migliorarne la comprensione.

Esso deve assecondare il processo di apprendimento ed esecuzione dei compiti tipico dell’utente e deve fare largo uso di esempi, limitando al minimo gli approfondimenti e le specifiche tecniche.

Ora proviamo a mettere in fila i criteri fondamentali per arrivare a scrivere un buon Tutorial.

1. Chiarire subito l’oggetto del Tutorial: è necessario far capire al lettore cosa si appresta a leggere, descrivendo precisamente l’oggetto del tutorial nel titolo o nell’introduzione del medesimo.

2. Sintesi e chiarezza: l’obiettivo è quello di far imparare nuove cose a chi lo legge, quindi è necessario utilizzare parole chiare, semplici e non dilungarsi troppo, rischiando di stancare il lettore.

3. Non scrivere paragrafi troppo lunghi: i concetti espressi in ogni paragrafo devono essere ben strutturati e suddivisi in passi semplici.

4. Utilizzare uno stile redazionale ordinato: è importante utilizzare liste e tabelle, nonchè righe di spaziatura per facilitare la lettura e alleggerire "visivamente" la struttura del testo.

5. Inserire delle immagini: in molti casi un'immagine è più esplicativa di decine di parole.

6. Definire prima di usare: ogni termine tecnico o concetto deve essere correttamente definito prima di poterlo usare.

7. Fare degli esempi: dopo la lettura della teoria è importante la pratica, quindi è sempre buona norma inserire degli esempi brevi ed esaustivi.

8. Inserire delle F.A.Q.: può essere utile abbinare al Tutorial delle risposte alle domande più frequenti, al fine di chiarire ancora meglio le idee al lettore.

9. Elementi da integrare: in fondo ad un Tutorial può essere utile inserire un glossario e/o una raccolta di link utili a pagine Web che possono arricchire i contenuti espressi.

10. Aggiornare il Tutorial: è opportuno mantenerlo sempre aggiornato e integrare, quando necessario, i contenuti espressi.

Infine una raccomandazione: quando si scrive un Tutorial, bisognerebbe proporre esempi e soluzioni che derivano direttamente dalla propria competenza ed esperienza diretta sull'argomento.
Proprio perchè è un tipo di documento rivolto ad un utente principiante, è estremamente facile fornire indicazioni inesatte o fuorvianti se tali indicazioni vengono "riportate" da altri testi e non direttamente sperimentate.

Prossimamente, vedremo un esempio di un semplice documento rivolto ad utente principiante, nonchè un "contro esempio" su come NON SI DOVREBBE scrivere un tutorial.
Leggi questo articolo...

COSA FA il Technical Writer ? Scrivere per qualcuno

Quando il TW progetta un manuale, non ha in mente solo l’architettura o il software da illustrare, ma anche l’utente finale che leggerà quel manuale.
La Scienza delle Comunicazioni ci avvisa che in ogni testo vengono incorporate implicitamente due immagini: quella dell'autore e quella del lettore.

Ogni testo è condizionato dallo stile e dalle intenzioni dell'autore, nonché dal modello di utente target a cui ci si rivolge. Pur riferendosi allo stesso software, un manuale destinato all'operatore principiante sarà ben diverso da un manuale destinato all'amministratore di una rete aziendale.

Dal punto di vista cognitivo, costruire un manuale incentrato sul lettore finale, significa tenere come riferimento le esigenze del lettore nei confronti dello strumento descritto nel manuale.

Il TW scrive quindi per un utente che ha un piano d'uso: aspettative, competenze e obiettivi. Cosa deve spiegare, e cosa può trascurare? Da dove iniziare? Come articolare il testo, come calibrare il peso relativo degli argomenti? Le priorità concettuali ? Dove generalizzare ? Quali esempi proporre ? In che modo bilanciare testo e grafica ? Quali difficoltà possono essere utilmente proposte e quali invece devono essere appianate ? Quali pre-requisiti assumere ?

Ecco solo alcuni dei criteri che entrano in gioco se si riflette sulla progettazione di un manuale.

Naturalmente, non sempre c'è il tempo per una progettazione sistematica e accurata in ogni particolare.
Spesso i tempi di realizzazione sono compressi dalla logica economica, in cui la qualità del lavoro risulta quasi sempre sgradita ospite.

A volte si procede per approssimazione e l’esperienza in tale frangente svolge un ruolo prevalente.

Tuttavia, aldilà del contesto in cui si trova ad operare e di altri eventuali condizionamenti, chi scrive si prefigura un certo target di utenza: più questa proiezione è ben strutturata, meglio potrà calarsi nei suoi panni e valutarne caratteristiche, difficoltà e aspettative per poi trasfonderle in modo più mirato nella struttura del manuale.
Leggi questo articolo...

COSA FA il Technical Writer ? L'interazione con i tecnici

Nella realtà industriale spesso sono dei tecnici, generalmente degli ingegneri, a scrivere i manuali delle macchine o di un prodotto software.
MA SIAMO COSI’ CONFIDENTI CHE SIA LA SCELTA PIU’ OPPORTUNA ?

Il progettista è in genere la persona meno adatta a spiegare ad altri il funzionamento della sua opera; in altre parole, la sua competenza tecnica specifica non lo rende automaticamente un bravo scrittore-istruttore.
Per quanto controintuitiva possa sembrare tale affermazione, quanto più un tecnico risulta essere un vero specialista, tanto più avrà difficoltà ad adottare quel distacco essenziale per far emergere una visione d'insieme dell'argomento.

Uno specialista è tale quando le nozioni acquisite vengono metabolizzate, interiorizzate e automatizzate. Compiere il percorso inverso, ri-esplicitare la propria conoscenza e saperla comunicare ad utenti meno esperti non è affatto semplice.

Sul piano psicologico, mettersi nei panni di un neofita, comprenderne e anticiparne le difficoltà e facilitare il suo percorso di apprendimento, è un processo estremamente arduo per un esperto.

Il super-esperto, nella migliore delle ipotesi, tende a dare per scontate delle informazioni che invece non risultano affatto banali per il lettore finale del manuale.

Per tale motivo, il buon manuale nasce dall’interazione tra un tecnico e un TW. Il TW affianca il tecnico, pone domande, estrae le conoscenze dalla “pancia” del progettista e le organizza secondo schemi differenziati, in base alla natura del documento che sta scrivendo a al lettore a cui si rivolge, attraverso una prassi in cui si mescolano metodi ben definti e procedimenti “ad hoc”.

Spesso il TW coadiuva il tecnico anche segnalando difetti e potenziali migliorie della macchina o dell'applicazione software che sta usando allo scopo di documentarne il funzionamento.
In quest'ottica, specie nelle aziende più lungimiranti, il TW diviene "consulente" del gruppo di sviluppo tecnico, grazie alla sua capacità di porsi dal punto di vista dell'utilizzatore della macchina/del software.

Ovviamente, se il TW ha competenze tecniche adeguate, il processo d'interazione con il progettista potrà risultare più efficace e spedito.

La mia esperienza in tal senso è un pò atipica, perchè sono un tecnico che ha sempre coltivato la passione per la scrittura ed ho avuto l'opportunità di stare da entrambe le parti della barricata; forse proprio per questo credo di poter dire che saper scrivere un buon manuale è un processo più complesso di quanto non si pensi, in cui "il saper scrivere" occupa un posto sicuramente fondamentale, rispetto alla "conoscenza tecnica dell'argomento".

In altre parole, le nozioni tecniche necessarie si apprendono più facilmente di quanto non si possa imparare a comunicarle efficacemente... e considerato che sono un ingegnere, a questo punto la mia onestà intellettuale mi sembra accertata oltre ogni ragionevole dubbio!
Leggi questo articolo...

COSA FA il Technical Writer ?

Proviamo a rispondere a questa domanda delineando le diverse parti di un puzzle molto interessante.

Nell’accezione più schematica, il TW si occupa di scrivere manuali.
Questa prima indicazione, così formulata, potrebbe suonare estremamente riduttiva.
In realtà il TW è il tramite tra il prodotto e l’utilizzatore del medesimo.
Deve rendere comprensibile ciò che non lo è, quindi scrive per spiegare.

Si pone dalla parte dell’utilizzatore, usando il linguaggio più opportuno per spiegare il funzionamento di un software o di una macchina.

Alcuni dei prodotti editoriali più comuni realizzati dal TW possono essere elencati di seguito:

• il libretto di istruzioni per un elettrodomestico


• il manuale d’installazione di un prodotto software


• la guida alla manutenzione di un’automobile


• la newsletter che informa i clienti sull’evoluzione dei prodotti


• la quick reference per usare il telefonino


• il manuale utente di un programma software


• il documento di collaudo di un’architettura hardware


• il manuale API di una libreria software, finalizzato agli sviluppatori


• la scheda tecnica di un prodotto


• l'help online contestuale ad un’applicazione software


• la check-list per l’analisi dei guasti di un aereoplano


• i contenuti del sito aziendale

… e altro ancora.

Ma per ognuno di questi prodotti, il TW applica uno schema di lavoro rigido e univoco o, nell’accezione migliore, “ben ingegnerizzato”… oppure deve adottare una strategia flessibile ed adattativa rispetto al contesto?

In altri termini, come si procede nella scrittura di un manuale ?

Pensando alla risposta migliore da dare a questa domanda, mi viene in mente un quadro di Mondrian, un insieme di rettangoli colorati, di diversa dimensione, ben distinti, che si compongono nelle modalità più diverse, a costituire un tutto organico, geometrico e cromaticamente armonico.

Proviamo a citare almeno le componenti principali di questo processo, sperando di riuscire a ricomporre un quadro convincente.

Leggi questo articolo...

Soluzioni: uso degli elenchi.

Una delle situazioni più tipiche che mi è capitato di riscontrare nei documenti tecnici scritti in modo poco accorto, consiste nello scarso utilizzo degli elenchi (puntati e/o numerati) laddove sarebbero utili e necessari.
Consideriamo l'esempio seguente:

"...attraverso la console degli eventi è possibile controllare l'utente che ha effettuato una certa operazione, l'ora in cui è stata effettuata, il suo ruolo operativo registrato nel sistema, il dispositivo sui cui è stata effettuata, l'insieme degli eventi che sono stati scatenati dall'operazione, i dati coinvolti, le eventuali notifiche configurate..."

Che cosa abbiamo appena letto?
Niente di complicato... un semplice "elenco".

Un elenco di concetti, esattamente un elenco delle funzionalità accessibili attraverso una fantomatica "console degli eventi".
E allora perchè non lo scriviamo IN FORMA DI ELENCO ?

"...attraverso la console degli eventi è possibile controllare:

• l'utente che ha effettuato una certa operazione;
• l'ora in cui è stata effettuata;
• il suo ruolo operativo registrato nel sistema;
• il dispositivo sui cui è stata effettuata;
• l'insieme degli eventi che sono stati scatenati dall'operazione
• i dati coinvolti;
• le eventuali notifiche configurate.

..."

La differenza non è trascurabile.

Presentare in maniera banalmente descrittiva un set d'informazioni che, strutturalmente, identificano un elenco, costringe il lettore a ricostruire, nella sua testa, la struttura dell'elenco, inducendolo ad un inutile esercizio che lo distrae dal nocciolo della comunicazione.

Non è l'esempio più cattivo che potevo fare... ho visto elenchi di concetti/oggetti che si dipanavano su una dozzina di righe... in genere già alla sesta riga l'attenzione del lettore viene messa a dura prova.

Ma a questo punto dobbiamo fare un ulteriore distinzione tra "elenchi puntati" ed "elenchi numerati".
Nell'esempio precedente abbiamo usato un elenco puntato, perchè le informazioni presentate costituiscono "un insieme non ordinato"; che significa ?
Significa che modificare la posizione di uno più items dell'elenco, non modifica il contenuto della comunicazione.

Ma ora consideriamo un'altro esempio:

"...

1. Selezionare l’evento in errore più antico tra quelli prodotti.
2. Ricostruire la causa dell’errore in base agli indizi disponibili.
3. Sanare l’evento in base a quanto ricostruito.
4. Riavviare il Motore degli Eventi al fine di rielaborare l’evento.
5. Se l’evento va ancora in errore, è necessario ritornare al punto 2.

..."

E' evidente che, in questo caso, modificando l'ordine dei concetti, verrebbe meno il senso della comunicazione.

L'elenco numerato DEVE ESSERE SEMPRE utilizzato quando tra un insieme di oggetti/concetti esiste una relazione di ordinamento
che determina la semantica dell'elenco.

Leggi questo articolo...

CHI E' il Technical Writer ?

CHI E'... e COSA FA... il Technical Writer?

Sempifichiamo... iniziamo dal CHI E'. Per rispondere a questa domanda, ci si trova a dover superare ostacoli di non poco conto.

Il primo riguarda la “bassa densità” di questa figura nel panorama professionale italiano, dove spesso la figura del redattore tecnico è considerata erroneamente come una figura professionale di serie B.

Il nostro paese non riveste il ruolo di leader nella produzione di tecnologie innovative e di prodotti incentrati su di esse.

Il numero molto limitato, rispetto al mondo anglosassone o asiatico, di aziende che realizzano “prodotti”, influenza negativamente la promozione di figure specializzate nella redazione di documentazione tecnica.

Il secondo è relativo al problema della “formazione” del TW, che non è banalmente schematizzabile. Nei paesi anglosassoni ci sono scuole e corsi universitari per insegnare a scrivere documentazione tecnica; in Italia da alcuni anni, se pur lentamente, si stanno diffondendo alcuni corsi, di solito incastonati nel piano di studi delle facoltà di Lettere, Ingegneria o Scienze della Comunicazione.

Tuttavia siamo ancora lontani da un percorso formativo completo, in grado di nutrire un profilo versatile come quello che deve caratterizzare un TW.

Nella maggiorparte dei casi, il TW si forma "sul campo", all'interno della realtà aziendale in cui ha origine l'esigenza di produrre documentazione tecnica.

Generalmente, si parte da una buona base tecnica, legata all’ambito specifico in cui ci si trova ad operare; scrivere un manuale che descrive un'architetture hardware/software è un compito che può, in teoria, essere affidato anche ad un profano, ma è abbastanza probabile che un ingegnere informatico possa operare in tal senso con maggior cognizione di causa.

Tuttavia, molti TW "guru" italiani denotano una formazione di tipo letterario-umanistica.
Da questi elementi, concludiamo che la tipologia di formazione non è vincolante.

La formazione è solo uno scheletro, che poi deve essere rivestito attraverso la “pratica” che deve rivestire di senso la necessaria “grammatica”.

Quindi quali altri elementi entrano in gioco ? Se si ha la ventura di lavorare in un'azienda che realizza prodotti, allora ci si trova in una posizione di vantaggio rispetto alla possibilità di accedere a questa professione; Darwin direbbe che "l'ambiente favorisce l'evoluzione della specie".

Ma poi è necessaria una "predisposizione" soggettiva.

Passione per la letteratura e per la scrittura, curiosità, interesse per la comunicazione e per gli aspetti psicologici ad essa associati, capacità di interagire con tutti coloro che possono fornirci le informazioni necessarie, fantasia, elasticità mentale, creatività e precisione, capacità di visione, conoscenze tecniche e redazionali, velocità di apprendimento... e forse altro che ora non mi sovviene. E tutti questi elementi miscelati in percentuale ignota.

E poi ci vuole "l'occasione"... perchè finchè non si viene messi alla prova, tutte le qualità sopracitate, quandanche presenti, non avranno modo di manifestarsi.

A me è capitato tutto questo: la formazione tecnica, l'ambiente, la predisposizione, l'occasione. Direi che per ora possiamo fermarci qui, ma nei prossimi post mi riprometto di approfondire diversi altri temi inerenti alla professione del TW.
Leggi questo articolo...

Soluzioni: uso delle tabelle.

Nella letteratura tecnica, l'uso delle tabelle può essere particolarmente efficace per comunicare le relazioni che intercorrono tra due o più entità.

Non siamo generalmente allenati ad esaminare una situazione, un contesto, una descrizione e a riconoscere la struttura relazionale dei diversi elementi in essa coinvolti.

Di contro, è molto comune trovarsi a leggere una descrizione estesa di un'insieme di relazioni che spesso conduce il lettore in un gorgo in cui annegare può sembrare il minore dei mali!

Un esempio? Eccolo:

"... l'architettura proposta è caratterizzata da 3 parametri (A, B e C); nel caso in cui la piattaforma si trovi nello stato di sviluppo, la terna di parametri assume i valori 1, 1 e 0. Se si trova nello stato di collaudo, i parametri valgono 1, 0 e 0.
Quando la piattaforma viene portata nello stato di esercizio, i tre parametri vengono posti a 1..."

Si può fare di meglio ? Si... con una tabella!

Ma ora esaminiamo un secondo esempio ...eccolo:
"... le statistiche ci indicano che, ad un anno dal conseguimento della laurea, i laureati in Ingegneria che ottengono un contratto a tempo determinato sono il 57% ed un contratto a tempo indeterminato è appannaggio del 29%.
A due anni le percentuali si modificano passando, rispettivamente, al 61% e al 32%. A tre anni, siamo al 55% e al 41%. Come vanno le cose per i Fisici ? Ad un anno, 39% e 7%; a due anni 59% e 18%; a tre anni, 45% e 48%.
Per i Chimici, dopo un anno, 18% e 5%; dopo due, 39% e 22%; dopo 3 anni, 40% e 50%.
E come vanno le cose per le facoltà umanistiche ? Prendiamo in esame Scienze Politiche, Giurisprudenza e Lettere.
Per Scienze Politiche, ad una anno della laurea le percentuali sono sconfortanti: il 20% riesce ad ottenere un contrato a tempo determinto e soli il 2% a tempo indeterminato.
A due anni, le percentali salgono di poco, 28% e 8%.
Al terzo anno, 33% e 15%.
Per Giurisprudenza... "
Che ne dite ? Io mi sono già perso... E L'HO SCRITTO IO!
Anche qui, una tabella sarebbe in grado di coniugare sintesi e semantica, guidando l'occhio del lettore a cogliere i dati essenziali, senza disperderli in un periodo iper strutturato.

I due esempi proposti servono a focalizzare un'idea che ritengo fondamentale: non si deve MAI costringere il lettore ad uno sforzo superfluo, rispetto a quello strettamente necessario, per comprendere il concetto che vogliamo comunicare.
In altri termini... SEMPLICITA'!
Questa idea chiave, che a me sta molto a cuore, verrà spesso riproposta in questo blog e la ritroveremo anche nei post relativi all'uso dele immagini.
Scrivere "complicato" non è sinonimo di maggior cultura o di fine intelligenza, anzi.
Un TW deve trasmettere concetti spesso complessi nel modo più chiaro e diretto possibile, senza stravolgere i contenuti ma proponendoli in una forma essenziale e completa... e una tabella è spesso una buona alleata!
Leggi questo articolo...

Una CHECK-LIST per l'analisi di un testo.

In un precedente articolo di questa sezione, vi ho fornito una descrizione "qualitativa" del mio approccio al lavoro di riscrittura di un testo.

Tuttavia, mi sono reso conto che potrebbe essere molto utile fornire una "check-list" di tutti gli elementi che è opportuno verificare quando si analizza un testo.


VERIFICA DEI CONTENUTI:

• Ci sono idee che non convincono o non correlate al tema?


• Ci sono idee ripetitive?


• Ci sono idee che evidenziano una forte contraddizione con altre idee?


• Le idee sono formulate in modo chiaro e completo o sembra che manchi qualche elemento?


• Risulta con chiarezza quali sono i punti principali?


• C’è equilibrio nello sviluppo dei vari punti trattati?

VERIFICA DELL'ORGANIZZAZIONE DEI CONTENUTI:

• La suddivisione in capitoli, paragrafi, ecc... è efficace?


• I diversi paragrafi sono ben collegati?


• Nell'ambito di ogni paragrafo, le frasi sono connesse?


• Ogni parte del testo ha un buon attacco e una buona chiusura?


• Il contenuto sarebbe più efficace cambiando l’ordine di qualche parte?

VERIFICA DELLA CORRETTEZZA FORMALE LINGUISTICA:

• L’ortografia delle parole è corretta?


• Le frasi sono costruite in modo grammaticalmente corretto?


• La punteggiatura è corretta e funzionale?


• Ci sono sequenze di frasi troppo lunghe e contorte o monotone?


• Le parole sono usate appropriatamente, nel loro significato corretto?


• Ci sono concetti ridondanti e aspecifici, che non apportano maggiore informazione?


• Ci sono ripetizioni ravvicinate di parole?

VERIFICA DELLA CORRETTEZZA FORMALE GRAFICA:

• Tutti i grafici, le immagini e le tabelle sono coerentemente collocati nel documento?


• La numerazione di grafici, immagini e tabelle è corretta?


• Il testo è coerente sul piano grafico (font, stili, formato delle tabelle, stile della grafica...)?


• Se il testo è navigabile internamente attraverso un insieme di link, tutti i link funzionano correttamente?

Quando si prende confidenza con il mestiere della scrittura, molti elementi di questa check-list vengono attuati in modo "quasi automatico"dalla nostra mente, mentre verifichiamo la trama del documento, allo stesso modo in cui un atleta esegue un gesto tecnico in un modo che sembra, appunto, automatico e naturale.
In realtà, sappiamo che l'atleta ha ripetuto quel gesto migliaia di volte in allenamento e solo questo gli ha permesso di acquisirlo ed eseguirlo con facilità.

Quando si inizia a scrivere documenti per ragioni professionali, usare una check-list come questa (non necessariamente questa) è veramente molto utile. Leggi questo articolo...