mercoledì 29 luglio 2009

Eccomi a voi con questa mia a dirvi...

..."ADDIRVI... tutta una parola!", come diceva il principe Antonio De Curtis, in arte Totò, nella celeberrima e immortale scena della redazione della lettera, con Peppino De Filippo, in "Totò, Peppino e la malafemmina".

Dunque, a dirvi... che sono tornato dopo due settimane di corso d'Inglese full-immersion in cui, mentre tentavo di migliorare la mia conoscenza della lingua, ho abbozzato una serie di idee per molti nuovi post che vi proporrò prossimamente.
Per ora... un mini set di semplici acronimi che si possono usare (ma senza esagerare...) in una mail professionale, specialmente se avete maturato una particolare confidenza con il destinatario della medesima:
  • ASAP as soon as possible
  • NRN no reply necessary
  • FYI for your info
  • RFI request for information
  • PCM please call me
  • LMK let me know
Prendo spunto da questa idea per sottolineare che l'uso degli acronimi, nell'ambito della Business Communication, è soggetto a delle regole ben codificate, che in quanto tali possono però contemplare delle eccezioni.

Presto dedicherò un post proprio a questo argomento, particolarmente critico nell'ambito dell'Information and Computer Technology, ove gli acronimi proliferano come i funghi nel bosco a Settembre. Leggi questo articolo...

mercoledì 15 luglio 2009

Quali documenti... per quale prodotto?

Nel post del 2 Luglio ho fornito una roadmap minima attraverso la quale è possibile pianificare la produzione della documentazione di un'azienda. In funzione del contesto, tale roadmap può essere arricchita e diversificata.
Ma supponendo di partire da zero, gli elementi indicati sono da ritenersi gli elementi di base necessari da cui possiamo partire per organizzare il nostro lavoro.

A questo punto, chiediamoci COSA dobbiamo documentare e QUALI/QUANTI documenti dobbiamo mettere in cantiere a tale scopo.
Io lavoro in un'azienda IT che realizza prodotti software, in un'area di mercato altamente specializzata. Nel mio caso, per documentare un singolo prodotto, è sempre necessario realizzare ALMENO i seguenti documenti:

- BROCHURE: è il documento di marketing che fornisce, al cliente potenziale, le prime informazioni fondamentali sul prodotto.

- TECHNICAL SPECIFICATION: è il documento di sintesi che racchiude tutte le informazioni tecniche necessarie sul prodotto.

- INSTALLATION MANUAL: è il documento che fornisce tutte le informazioni per installare ed eventualmene configurare il prodotto.

- GETTING STARTED MANUAL (QUICK START GUIDE): è il documento che consente di prendere confidenza rapidamente con tutte le funzionalità di base del prodotto.

- ADMINISTRATION MANUAL: è un documento che contiene tutte le informazioni dettagliate, spesso in modalità Tutorial, rivolto ad un utente "evoluto", destinato al ruolo di Amministratore del prodotto e che quindi deve conoscere ogni aspetto del medesimo.

Perchè li ho elencati con la dizione inglese ?
Perchè abbiamo deciso di scrivere la documentazione di prodotto in inglese, visto che il mercato al quale ci rivolgiamo non è limitato all'interno dei confini nazionali.

Poi è spesso necessario mettere a punto altri documenti quali:

- USER MANUAL: è un documento rivolto ad un utente che deve usare il prodotto (tipicamente un sottoinsieme delle funzionalità disponibili nel prodotto) ma non ha le esigenze dell'utente a cui è dedicato l'Administrator Manual.

- INTEGRATION MANUAL: è un documento che descrive in che modo è possibile integrare il prodotto in un'architettura software pre-esistente, o l'aggiornamento del prodotto rispetto ad una versione precedente gia installata nel sistema ospite.

- API REFERENCE MANUAL: è un documento, finalizzato ad un tecnico programmatore, che descrive le librerie software eventualmente associate al prodotto.

Inoltre, all'interno delle applicazioni software, è necessario predisporre un HELP in formato HTML, i cui contenuti possono essere mutuati da uno o più manuali tra quelli elencati ma che richiedono un lavoro di filtro e formattazione che non può essere realizzato attraverso un banale
e meccanico "copia e incolla" di quanto già realizzato.

Ogni singolo prodotto deve poi essere testato e collaudato e questo richiede lo sviluppo di un'appropriata DOCUMENTAZIONE DI COLLAUDO.

C'è tutto? Certamento no... ma c'è abbastanza.

E TUTTO QUESTO PER OGNI SINGOLO PRODOTTO!

Ma se invece di un prodotto software dobbiamo documentare un video-registratore?
In tal caso l'INSTALLATION MANUAL e la QUICK START GUIDE dovrebbero essere sufficenti, almeno per iniziare ad usare il prodotto. Ma deve essere predisposto anche lo USER MANUAL per i clienti più esigenti, che vogliono indagare anche le funzionalità meno comuni.

L'altra settimana ho comprato una piscina di plastica da giardino... di quelle per far giocare i bambini nei giorni più torridi dell'estate; c'era il MANUALE DI MONTAGGIO in forma cartacea ed un CD ROM contenente un filmato di presentazione in formato AVI, in cui sono illustrate
accuratamente tutte le fasi di montaggio e manutenzione.

Insomma, ogni prodotto richiede un set di documenti ben preciso, in base alla sua natura, all'uso che se ne deve fare e a chi lo dovrà utilizzare.

E' ASSOLUTAMENTE NECESSARIO STABILIRE CON ATTENZIONE la manualistica da realizzare per ogni prodotto, nelle diverse forme possibili.

E QUANDO REALIZZIAMO UN PROGETTO PER UN CERTO CLIENTE?

Un progetto si sviluppa attraverso diverse fasi ben distinte; generalmente, ogni fase prevede un certo tipo di documentazione.
Ad esempio, nella fase iniziale di un progetto software, viene redatto il DOCUMENTO DI ASSESSMENT, in cui viene delineata l'analisi del progetto e le soluzioni funzionali richieste, sulla base delle specifiche caratteristiche tecniche e delle logiche di business proprie del cliente,
nonchè di altri vincoli in essere (moduli software/hardware già posseduti dal cliente, prescrizioni legislative, ecc...).

Nella fase finale del progetto, quando l'architettura software viene rilasciata in esercizio, viene prodotto il MANUALE DI ESERCIBILITA', che racchiude tutte le informazioni tecniche necessarie alla gestione dell'architettura.

Se l'architettura prevede l'integrazione di uno più prodotti, dovrà essere rilasciata tutta la necessaria documentazione relativa ad ogni singolo prodotto e l'eventuale sopracitato INTEGRATION MANUAL.

Se poi sono state introdotte delle personalizzazioni "ad-hoc", anche tali moduli personalizzati dovranno essere documentati con manuali dedicati.

Il DOCUMENTO DI ASSESSMENT e il MANUALE DI ESERCIBILITA' possono essere idealmente considerati il documento iniziale e il documento finale di un progetto sofware; lungo lo sviluppo del progetto potranno poi essere rilasciati un gran numero di documenti intermedi.

Analoghe considerazioni possono essere svolte in altri ambiti tecnici.

La DOCUMENTAZIONE DI PROGETTO riveste una sua specificità ed è ancor meno schematizzabile rispetto a quella che dobbiamo sviluppare per un prodotto. La stretta collaborazione tra i diversi progettisti ed il TW, nonchè l'esperienza di tali soggetti nella gestione delle diverse fasi del progetto, sono elementi essenziali per poter sviluppare dei buoni documenti.

In conclusione, spero di avervi convinto, pur non potendo esaurire l'argomento in un singolo post, che la capacità di pianificare COSA si deve fare, PRIMA DI INIZIARE "A FARE", rappresenta il fidato "filo di Arianna" che ci garantisce di non perderci nel labirinto.
Leggi questo articolo...

domenica 12 luglio 2009

14 Luglio Sciopero dei Blogger contro il DDL Alfano

scaricaillogobanner

L'artigiano di Babele aderisce alla protesta dei blogger organizzata da Diritto alla Rete contro il DDL Alfano.

Non è nostra intenzione inserire argomenti di politica in questo forum, ma non condividiamo questo decreto che consideriamo pericoloso per la libertà di espressione.

Ricordiamo che L'artigiano di Babele, NON E’ UNA TESTATA GIORNALISTICA, in quanto viene aggiornato senza alcuna periodicità. Non può pertanto considerarsi un prodotto editoriale ai sensi della legge n. 62 del 7.03.2001, ma il decreto non si rivolge solo alle testate giornalistiche ma a qualsiasi sito informatico.

Le perplessità che abbiamo riguardano l’obbligo di rettifica entro le 48 ore dalla richiesta di un’eventuale soggetto offeso dalle dichiarazioni pubblicate da un sito informatico:

Art. 15.
(…) «Per le trasmissioni radiofoniche o televisive, le dichiarazioni o
le rettifiche sono effettuate ai sensi dell’articolo 32 del testo
unico della radiotelevisione, di cui al decreto legislativo 31 luglio
2005, n. 177.
Per i siti informatici, le dichiarazioni o le rettifiche
sono pubblicate, entro quarantotto ore dalla richiesta, con le stesse
caratteristiche grafiche, la stessa metodologia di accesso al sito e
la stessa visibilità della notizia cui si riferiscono»;

Per come è stato scritto, darebbe modo a chiunque non fosse d’accordo con una frase o un post di richiedere la rettifica, vanificando così il pensiero dell’autore.

Se non vi sarà una rettifica, una smentita sul sito, il gestore o il proprietario dello stesso pagherà una multa che può arrivare fino a circa 13.000 euro. Questo vale non solo per i blogger, ma anche per i forum e quindi anche per i post che i lettori inviano.

Benchè in questo sito non esprimiamo pareri negativi su aziende o persone, il decreto ci sembra comunque pericoloso per la libertà di pensiero, in generale, anche per gli altri blogger.

Le leggi sulla diffamazione esistono già ma è sempre un giudice a garantire che quanto dice il presunto offeso sia reale o semplice voglia di creare danno o “chiudere la bocca” ad un’altra persona.

Il 14 Luglio vi sarà una manifestazione a Roma, in Piazza Navona, con i Blogger imbavagliati per una protesta pacifica.

Leggi questo articolo...

sabato 4 luglio 2009

Una perla dal blog di Luisa Carrada

Oggi un post breve breve per segnalarvi una "perla", molto attinente alle problematiche di cui mi occupo.
Lo trovate su http://mestierediscrivere.splinder.com, in data 1° Luglio 2009.

Questo blog è un "luogo delle delizie" per chi si interessa di scrittura professionale e affini e l'ho già segnalato nella categoria DA VISITARE, che trovate in questa pagina, in basso a destra.

Luisa Carrada è una "guru" in questo campo e nel mio percorso da autodidatta, ho imparato molto "saccheggiando" i suoi suggerimenti.
Pur non conoscendola di persona, ho avuto modo di ringraziarla via mail per tutto quello che mi ha insegnato indirettamente, attraverso la lettura dei suoi post e la biblioteca dei "quaderni".

C'è molto da imparare... approfittatene. Leggi questo articolo...

giovedì 2 luglio 2009

Pianificare la produzione della documentazione

Uno degli errori più grossolani che si possono commettere nella produzione della documentazione aziendale, consiste nel NON PIANIFICARE tutte le fasi del processo di produzione. Se siete chiamati sporadicamente a realizzare un documento, potete anche pensare di dare fondo al vostro talento con tutto il corredo di estemporaneità che può derivarne. Ma il talento è nulla senza la tecnica e la capacità di pianificare in ogni aspetto tale processo di produzione. Questo aspetto diviene via via più decisivo in proporzione diretta alla quantità e alla qualità dei documenti che siete chiamati a produrre.

Come sempre, non esiste uno schema universale ed esaustivo che possa andar bene per ogni azienda o contesto professionale.

Esistono però dei passaggi chiave che devono essere sempre tenuti ben presenti e che possono trovare una valida applicabilità nella gran parte delle situazioni.

L'elenco che vi propongo identifica un "set minimo" di attività che può essere arricchito in base alle vostre esigenze:

DEFINIRE UN'ELENCO DI DOCUMENTI CHE ACCOMPAGNANO OGNI PRODOTTO

DEFINIRE UN INSIEME DI TEMPLATE PER OGNI TIPO DOCUMENTO


DEFINIRE UNA CONVENZIONE DI FILE-NAMING PER LA DOCUMENTAZIONE


INDIVIDUARE IL REPOSITORY DELLA DOCUMENTAZIONE AZIENDALE


ORGANIZZARE LA DOCUMENTAZIONE NEL REPOSITORY PRESCELTO


DEFINIRE I CRITERI DI ACCESSO/DISTRIBUZIONE DELLA DOCUMENTAZIONE

NESSUNO DI TALI PUNTI PUO' ESSERE OMESSO nella pianificazione del processo di produzione della documentazione tecnica di un'azienda.

Ovviamente, non è obbligatorio seguire in modo rigidamente sequenziale i passi sopraindicati.
Come ho già raccontato nel post precedente, quando ho cominciato il mio percorso di TW, ho definito per prima cosa una CONVENZIONE PER IL NAMING della documentazione; avevo una priorità assoluta di classificare quanto era stato prodotto, senza alcuna pianificazione, nei precedenti 4 anni e questa prima scelta mi ha facilitato molto il lavoro.

Invece, la definizione dei TEMPLATE è stato un processo progressivo e stratificato, sviluppato per approssimazioni successive e ancora oggi è ben lungi dall'essere terminato.

Nei prossimi post mi riprometto di approfondire i dettagli che mi sembrano più interessanti, inerenti al "set minimo" che vi ho segnalato.
Leggi questo articolo...

domenica 21 giugno 2009

Regole di Naming per la documentazione

Quando nel 2005 iniziai il mio lavoro, per prima cosa dovetti classificare centinaia di documenti realizzati in azienda, all'insegna della più completa anarchia, nei precedenti 4 anni.
La casistica disponibile era sorprendente:
  • documenti sostanzialmente identici salvati con nomi diversi
  • documenti notevolmente diversi salvati con lo stesso nome
  • documenti relativi allo stesso prodotto ma concettualmente diversi (la Scheda Tecnica, il Manuale d'Installazione, il Manuale dell'Amministratore,...) anch'essi identificati dallo stesso nome
  • documenti relativi a versioni diverse dello stesso prodotto salvati con nomi "mimetici" rispetto alla versione
  • documenti salvati con nomi assolutamente scorrelati dal contenuto
  • altro ancora... che al sol pensier ancor mi dole il cor...
Il lavoro di classificazione mi ha impegnato per 3 mesi e la prima cosa che ho fatto è stata quella di definire UNA REGOLA DI NAMING.
Non esistono indicazioni univoche su come impostare una regola di Naming della documentazione aziendale. Anche i guru del Technical Writing di matrice anglosassone, forniscono indicazioni assolutamente ragionevoli e ispirate a principi di "buon senso" che ognuno di noi può identificare autonomamente e deve essere in grado di adattare alla propria realtà lavorativa.

IL PRINCIPIO FONDAMENTALE è:
NON SI INIZIA A CLASSIFICARE NULLA SENZA UNA REGOLA DI NAMING.

La regola che ho adottato e che è ancora in vigore, è estremamente semplice e si struttura in questo modo:

ACRONIMO PRODOTTO/PROGETTO-VERSIONE PRODOTTO/PROGETTO-NOME MANUALE-VERSIONE DOCUMENTO-NOME AZIENDA/CLIENTE

Vediamo due esempi:

NMM-210-Installation_Manual-100-EngNetServices.pdf
Questo nome indica l' Installation Manual del prodotto Network Monitoring Module (NMM), giunto alla versione 2.1.0; la versione del documento è la 1.0.0 e il nome dell'azienda che lo produce è EngNetServices.

PPWC-340-Administration_Manual-120-ENELERGSUN.doc
Questo nome indica l'Administration Manual del prodotto Profile Provisioning Web Console (PPWC), sviluppato per il cliente ENELERGSUN, giunto alla versione 3.4.0; la versione del documento è la 1.2.0.

Come vedete, non è necessaria un'intelligenza cartesiana per definire una regola di Naming.

Tipicamente, ne fanno uso le aziende di alto livello e ben organizzate, in cui la produzione e la classificazione della documentazione rappresenta un'elemento importante della filosofia di business.
In particolare, le aziende che si sottopongono ad un percorso di certificazione di qualità dei processi produttivi, adottano regole di Naming anche molto più articolate di quella che ho adottato io.

Ovviamente questa regola non è la migliore possibile ma funziona abbastanza bene.
In questo modo i nomi apposti ai documenti divengono "parlanti", nel senso appena illustrato.

L'efficacia di una regola di Naming dipende anche dal contesto.
L'ACRONIMO PRODOTTO/PROGETTO ha più senso in un'ottica "interna" che esterna.
Quindi questa regola va benissimo per la documentazione tecnica, molto meno per la documentazione di Marketing, dove anche il nome del documento deve, in genere, essere più "esplicito".
Nulla vieta di adottare 2 o 3 regole di Naming distinte, all'interno dell'azienda, purchè siano ben specificate e note a tutti gli appartenenti della medesima.
Io preferisco una regola unica, semplice e flessibile quanto basta.

Ma ovviamente e come sempre, non si può avere tutto dalla vita; in quest'ottica vediamo in che modo si potrebbe modificare la regola illustrata se volessimo ottenere nomi "più compatti" (ma meno "parlanti").

Immaginiamo di assegnare un codice numerico a tutte le tipologie di documentazione previste per un generico prodotto:

001 - Technical Specification
002 - Installation Manual
003 - Getting Started Manual
004 - Administration Manual
005 - Product Manual
006 - Developer Manual

Riprendiamo gli esempi precedenti:

NMM-210-Installation_Manual-100-EngNetServices.pdf
NMM-210-002-100-EngNetServices.pdf

PPWC-340-Administration_Manual-120-ENELERGSUN.doc
PPWC-340-004-120-ENELERGSUN.doc

Come vedete, la regola induce a nomi più compatti ma meno intellegibili.

Ovviamente, una regola di Naming può essere utile anche per classificare i vostri documenti privati.

Come sempre, vi sottopongo la mia esperienza senza la pretesa di proporre formule esaustive, ma con l'intenzione di fornirvi spunti utili per una migliore gestione della documentazione.
Usate le regole di Naming... ne trarrete solo vantaggi.
Leggi questo articolo...

giovedì 11 giugno 2009

Contenuti di una pagina Web: la regola "F shape"

Alcuni giorni orsono la mia fidata collega Claudia, che mi aiuta nella realizzazione della documentazione aziendale, mi segnalava la sua difficoltà nel documentare una specifica funzionalità di una Web Console per l'amministrazione di uno dei nostri prodotti.
Ci mettiamo insieme a guardare il problema... e continuiamo a non vederlo.

Sarà la stanchezza del fine giornata ? Dopo un pò di tempo (diciamo un pò troppo...) ci accorgiamo della label identificativa di un accordion pane posizionato in basso a destra... di colore celeste su sfondo chiaro!

Eppure nei nostri prodotti questo elemento grafico viene usato con una certa frequenza... perchè stavolta non lo avevamo visto?
Dopo un breve smarrimento mi è ritornata in mente una delle lezioni più famose di Jacob Nielsen, il guru riconosciuto della Web "usability" e della comunicazione efficace dei contenuti Web.


La figura precedente la trovate sul suo sito www.useit.com, che vi invito a visitare e saccheggiare... intellettualmente parlando.
La figura rappresenta ciò che io chiamo la "densità di sguardo", cioè la tendenza a posizionare gli occhi di un lettore di una pagina Web prevalentemente su certe zone della pagina rispetto ad altre.
Le zone rosse sono quelle dove gli occhi del lettore tendono a posizionarsi più frequentemente; via via, la frequenza diminuisce virando dal rosso al giallo, al blù fino al grigio.
Tale ricerca ha suggerito che sia conveniente "addensare" i contenuti significativi di una pagina Web nella zona alto-centrale-sinistra, perchè è in quella zona che, prevalentemente, andiamo con lo sguardo a cercare le informazioni.

Quando scriviamo per il Web o progettiamo applicazioni Web, questa è una delle regole auree che bisognerebbe sempre osservare.

Quindi, se poi alle ore 19 ci si ritrova con un elemento grafico CELESTE... SU SFONDO CHIARO... IN BASSO A DESTRA... se proprio non lo si vede al primo colpo... siamo, almeno in parte, giustificati!
Leggi questo articolo...

sabato 6 giugno 2009

Saper scrivere... il Curriculum Vitae: una breve mappa per non perdersi

Come si scrive un buon CV? In rete esistono decine di guide, centinaia di pagine Web, più o meno dettagliate, che cercano di spiegare come si scrive un CV efficace.

Ho avuto modo di leggerne alcune ma alla fine si avverte la sensazione che l'unica certezza sembra consistere... nel non avere certezze.

Chi propone schemi validi per tutti gli usi, scivola necessariamente in una brodosa generalità priva di generalizzazione.

All'opposto, chi propone idee anche interessanti ma eccessivamente "verticali" (CV audiovisivi, "You Tube style" tanto per capirsi), rischia di condurre la composizione del CV in una specie di fiordo, eccessivamente angusto e particolare, magari adatto ad una particolare nicchia di mercato ma di scarsa efficacia nella maggior parte dei casi.

Questo post non intende aggiungere un altra manciata di pagine Web a tutte quelle già presenti sull'argomento, ma sollevare delle bandierine su alcuni passaggi chiave che sarebbe utile tener sempre ben presenti.
Ho avuto modo, nella mia professione, di dover condurre delle selezioni in team con altri colleghi e alcune delle osservazioni che vi propongo di seguito nascono anche da questa esperienza personale e diretta.

Focalizziamo i seguenti elementi:

- USATE UN FORMATO STANDARD PER IL VOSTRO CV
- SINCERI NELLA SOSTANZA MA INTERESSANTI NELLA FORMA
- HO FORSE FATTO TROPPO POCO... ALLUNGHIAMO LA MINESTRA!
- TROPPA ROBA... COSA TAGLIARE ?
- LA TRIADE MALEDETTA: Professionista, Serio, Motivato
- QUELLO CHE SCRIVETE NON VALE NULLA SE NON LO SCRIVETE BENE
- ALLEGATE AL CV LA LETTERA DI PRESENTAZIONE
- NUOVE TENDENZE: FATE DEL VOSTRO NOME UN BRAND


- USATE UN FORMATO STANDARD PER IL VOSTRO CV

Oggi, nella composizione di un CV, si è largamente affermato l'uso del "CV in Formato Europeo". Non si tratta di chissà quale incredibile parto dell'umano intelletto nè apporta alcun significativo set informativo aggiuntivo rispetto ai CV un pò più naive che potevamo leggere in passato.

E' SEMPLICEMENTE PIU' COMODO DA LEGGERE per il selezionatore, perchè la sua struttura è standard; se un selezionatore deve leggere decine di CV, in quelli scritti nel Formato Europeo è più semplice andare a reperire le informazioni d'interesse, perchè appunto esse andranno ad
occupare una posizione predefinta nella struttura del documento.
Se invece scrivete un CV in un formato più "personale", il selezionatore dovrà spulciarlo riga per riga per individuare le necessarie informazioni... quindi dovrà gestire una difficoltà aggiuntiva.

E VOI NON VORRETE INDISPETTIRE IL VOSTRO SELEZIONATORE VERO ? :-)

- SINCERI NELLA SOSTANZA MA INTERESSANTI NELLA FORMA

In un CV non conviene mentire. Un selezionatore accorto vi potrà smascherare con un soffio.
La bugia più frequente che mi capita di osservare riguarda la conoscenza della lingua inglese.
Vantare certificazioni indimostrabili o dichiarare il proprio inglese "fluent" può rivelarsi un boomerang disastroso, che può crollare in 5 minuti di conversation o a valle di una traduzione incerta di una mezza pagina.
Anche un sedicente DBA Oracle può essere "smontato" con poche precise domande.
Non raccontare balle non significa rinunciare a valorizzare le proprie esperienze, presentandole nel modo efficace.

Dichiarare l'ottenimento di una certificazione CISSP può darvi delle buone chance per una posizone si Security Consultant; ma se aggiungete due righe per indicare nell'ambito di quale progetto avete usato le competenze attestate nella certificazione, arricchirete di significato questo dato.

Se invece siete un animatore turistico e specificate di aver gestito un concorso canoro, non dimenticate di aggiungere che avete supervisionato ogni aspetto tecnico-artistico-organizzativo della manifestazione, se aspirate a ripercorrere le orme di Fiorello!

In altri termini, non inventate balle ma imparate a "vestire" in modo interessante le vostre "reali" competenze.

- HO FORSE FATTO TROPPO POCO... ALLUNGHIAMO LA MINESTRA!

Nella mente dei candidati più giovani spesso s'affaccia l'angoscia del "CV leggero".
Poche esperienze (se si è giovani e magari neo-laureati è quasi inevitabile), "avvertite" dal candidato come terribilmente non significative.
E invece di scavare per far emergare il meglio possibile dal materiale disponbile, si è mortalmente attratti dalla risposta sbagliata: allunghiamo la minestra!
Testo scritto in Arial 14, qualche riga vuota in più, una dozzina di avverbi coreografici in ordine sparso, magari una lunga lista di hobbies... NON VI ILLUDETE... non trarrete in inganno nessuno.
Meglio un CV sintetico e concreto che una poco abile operazione di autogol-marketing!

- TROPPA ROBA... COSA TAGLIARE ?

Un CV non è un'autobiografia.
Il selezionatore non ha fatto probabilmente nulla di malvagio per meritarsi la punizione di dover leggere il diario della vostra vita!
Se però avete avuto una carriera ricca di esperienze, non è nemmeno giusto auto-censurarsi per paura di dover presentare un CV "troppo lungo".
D'altra parte, a volte bisogna saper selezionare gli aspetti che devono emergere in funzione della figura professionale e della posizione per la quale ci proponiamo.
Se vogliamo ricoprire il ruolo di Business Developer in una Software Company, indicare nel CV che avete lavorato per 4 anni come programmatore Visual Basic può risultare non essenziale.
Se volete lavorare come DJ in una discoteca, segnalare la partecipazione ad un corso di paracadutismo nulla aggiunge alle vostre potenzialità.
In sintesi, cerchiamo di collezionare in modo mirato le nostre frecce migliori in funzione del bersaglio che vogliamo colpire.

- LA TRIADE MALEDETTA: Professionista, Serio, Motivato... ?!?

Mi riprometto prima o poi di lanciare una raccolta di firme per gli avverbi e gli aggettivi CHE NON SI DEVONO MAI PIU' USARE IN UN CV; tra tutti questi, credo che LA TRIADE MALEDETTA sia "Professionista, Serio, Motivato".

A chi usa tale triade io vorrei chiedere... PERCHE'?
Perchè pensate di distinguervi agli occhi di un selezionatore usando questi termini ?
Pensate che esista un selezionatore intenzionato ad assumere un DILETTANTE, BUFFONE E DEMOTIVATO ? Ad un'azienda che riceve centinaia di CV ogni anno, gli eccessi verbali, i toni saccenti ed iperbolici suonano falso come un televenditore di coltelli che non si devono affilare mai!

- QUELLO CHE SCRIVETE NON VALE NULLA SE NON LO SCRIVETE BENE

Evariste Galois morì nel 1841, all'età 20 anni, in un duello: dai 17 anni alla sua morte, gettò le basi di tutta la matematica moderna... in sole 60 pagine di appunti disordinati e misteriosi, sparse i semi che hanno generato tutte le vie della matematica più avanzata degli ultimi 150 anni... quelle 60 pagine hanno rischiato di andare perse... per un difetto di comunicazione, avremmo potuto perdere le intuizioni di un genio assoluto dell'umanità e la Scienza e la Tecnologia che conosciamo oggi... non sarebbero state la stesse.

LE VOSTRE MIGLIORI DOTI NON SERVONO A NULLA E A NESSUNO... SE NON LE SAPETE COMUNICARE!
E NELLA COMUNICAZIONE SCRITTA LA FORMA E' IMPORTANTE!

Anche lo skill più interessante può venire affossato da errori grammaticali, sintassi incerta e una cura superficiale degli aspetti formali... state scrivendo il vostro CV, non la lista della spesa!
La cura della forma si acquisisce con l'attenzione alla scrittura, va affinata giorno per giorno, allenandovi alla riscrittura dei contenuti del vostro CV. A tal proposito potrebbe esservi utile "giocare" con i concetti che trovate in questo blog, nella sezione "Esercizi di riscrittura".

- ALLEGATE AL CV LA LETTERA DI PRESENTAZIONE

Su questo argomento ho già scritto un post a cui vi rimando.

- NUOVE TENDENZE: FATE DEL VOSTRO NOME UN BRAND

Il CV può non essere l'unico modo di presentarsi ad un'azienda. La rete è piena di headhunters, "cacciatori di teste" che stanno cercando persone da inserire negli organici di un'azienda e che scandagliano la rete per individuare i candidati potenzialmente più interessanti, da convocare per un colloquio.
Quindi dovete "essere nella rete", attraverso un sito Web personale, un Blog, sfruttando le infrastrutture del Social Network per veicolare i contenuti professionali che pensate di poter offrire. Se siete in grado di "organizzare e comunicare" il vostro potenziale, forse qualcuno vi contatterà prima ancora di ricevere il vostro CV.
E comunque, anche questa attività di auto-promozione va segnalata nel CV...
Leggi questo articolo...

sabato 30 maggio 2009

Proteggere i nostri documenti con una password

Nel momento in cui realizziamo un documento, dobbiamo cautelarci da indesiderate manomissioni del suo contenuto, che possono verificarsi specialmente quando siamo obbligati a condividere con altri utenti la stessa postazione o più in generale la stessa "area di lavoro".

Se ad esempio operiamo sulla stessa LAN con altri utenti e non facciamo sufficente attenzione alla disciplina di condivisione dei nostri file, qualcuno potrebbe aprire il nostro documento e modificarlo/danneggiarlo, pregiudicando il nostro lavoro.

Il modo più comune di proteggere un file da sguardi indiscreti è quello di CIFRARLO, sottoponendolo ad un processo a valle del quale il suo contenuto risulti illegibile.
Un file cifrato può essere decifrato solo da colui che possiede LA CHIAVE adatta.

La chiave in questione è sempre una stringa ben definita di bit.
Tale stringa di bit può essere, nel caso più comune, ricondotta ad una sequenza di caratteri alfanumerici forniti dall'utente, generalmente denominata "password".

Ci sono diverse modalità per cifrare con una password un .doc con Microsoft Office Word 2003.

In particolare possiamo definire:

- una password per poter aprire un documento IN LETTURA

- una password per poter aprire un documento IN MODIFICA

La password può essere costituita da una combinazione di lettere, cifre, spazi e simboli e può contenere fino a 15 caratteri (opzione di default).
Se si selezionano opzioni di codifica più evolute, sarà possibile creare password anche più lunghe.

Per definire una password, dalla barra dei menù selezioniamo Strumenti->Opzioni, quindi selezioniamo la scheda Protezione.


Qui possiamo scegliere se:
  1. impedire l’accesso al documento: inserire la password nella text-area Password di apertura
  2. consentirne la sola lettura: inseriamo la password nella text-area Password di modifica.
In entrambi i casi, alla pressione del tasto OK viene richiesto di confermare la password appena indicata, reinserendola, per verificarne la correttezza.

Nel caso 1, ogni volta che si aprirà un documento protetto, verrà richiesto l’inserimento della password per potervi accedere.
Se abbiamo optato per una password di modifica (caso 2), possiamo accedere al documento anche senza la password, ma soltanto in lettura; la password specificata verrà richiesta nel momento in cui cerchiamo di salvare il documento dopo aver apportato una qualsiasi modifica allo stesso.

Se vogliamo apporre una password più lunga di 15 caratteri, è possibile premere il pulsante Avanzate e selezionare un sistema crittografico più sicuro rispetto a quello di default (denominato Compatibile con Office 97/2000):


Se, ad esempio, si sceglie l'opzione indicata in figura, si potranno utilizzare delle password lunghe almeno 40 caratteri.
Tuttavia, se si sceglie un Cryptographic Provider molto avanzato, trasportando il nostro documento su un PC diverso dal nostro e magari meno aggiornato, potrebbe essere impossibile aprire il documento, pur conoscendo la password adatta.

Per gli usi più comuni, l'opzione di default può andar bene, pur essendo debole di fronte ad un attacco "del dizionario" molto deciso.

Si osservi che, attraverso la check-box Crittografa proprietà documento, è possibile cifrare anche le proprietà accessibili selezionando dalla barra dei menù File->Proprietà.

L'immissione di una password non è l'unico modo di proteggere o limitare l'accesso ai contenuti di un documento e mi riprometto di approfondire questo tema nei prossimi post. Leggi questo articolo...

sabato 23 maggio 2009

Perchè usare 74 parole quando ne bastano 45?

Ecco un esercizio breve breve, per tenere allenato il cervello.
Ridurre, asciugare, sottrarre... questo è il segreto.

Questo documento è stato realizzato con lo scopo di fornire al lettore una dettagliata spiegazione inerente al processo di censimento e registrazione dei dati utente nel nostro sistema informatico.
Esso descrive le attività che vengono correntemente realizzate più comunamente, con cadenza giornaliera e/o settimanale. Nell'ottica di fornire un'introduzione ai processi che vengono implementati dagli impiegati, abbiamo preparato un overview di sole tre pagine, che riassume i passaggi salienti dell'attività in questione.

Questo documento illustra dettagliatamente il processo di registrazione dei dati utente. Esso descrive le attività più comuni, che vengon svolte con cadenza giornaliera e/o settimanale.
A tal fine abbiamo preparato un overview di sole tre pagine, che riassume i passaggi salienti dell'attività in questione. Leggi questo articolo...