Vi segnalo un articolo pubblicato su Forbes da Aron Fulkerson, in cui l'autore sostiene che, per un'azienda "illuminata", lo sviluppo della documentazione di prodotto può essere un moltiplicatore economico assolutamente non banale, sia in termini di abbattimento dei costi di supporto ed help-desk, sia per ciò che riguarda la fidelizzazione del cliente e la promozione del proprio business (se avete tempo e voglia potete andare a rivedere i miei articoli inerenti all'argomento White Paper).
Aron Fulkerson è co-fondatore e CEO di MindTouch.
In passato ha lavorato per Microsoft e nell'ambito della ricerca sui sistemi distribuiti.
Leggi questo articolo...
venerdì 24 settembre 2010
domenica 19 settembre 2010
La Qualità non è un pranzo di gala.
Mentre pensavo al titolo di questo post, mi è venuta in mente una delle più famose frasi di Mao Zedong e con un eccesso di immodesta imprudenza ho pensato che, sostituendo la "Qualità" alla "Rivoluzione", facesse proprio al caso mio
Nell'ultimo post vi ho parlato di due attributi, la Chiarezza e la Sintesi, che contribuiscono a definire la Qualità di un documento tecnico.
Ma il percorso che ci porta a dare sostanza a queste due caratteristiche non è un regalo degli Dei, non nasce dallo sfolgorio scintillante del talento (per lo meno non nel mio caso) o da una qualche formuletta magica, ma è frutto di un lavoro "muscolare", faticoso, in cui il testo deve essere lavorato, asciugato, riletto e riscritto, a volte scompaginato e riorganizzato, corretto e limato attraverso un processo iterativo che assomiglia al lavoro dello scultore, che toglie dal blocco di marmo tutto l'inessenziale per far emergere quello che già esiste "nel marmo", affinando via via il lavoro del martello e dello scalpello.
Sull'argomento della revisione di un testo ho già scritto diversi post, riuniti nella sezione Esercizi di riscrittura.
In particolare vi invito a leggere i post del:
Quello che mi preme sottolineare è che:
Nell'ultimo post vi ho parlato di due attributi, la Chiarezza e la Sintesi, che contribuiscono a definire la Qualità di un documento tecnico.
Ma il percorso che ci porta a dare sostanza a queste due caratteristiche non è un regalo degli Dei, non nasce dallo sfolgorio scintillante del talento (per lo meno non nel mio caso) o da una qualche formuletta magica, ma è frutto di un lavoro "muscolare", faticoso, in cui il testo deve essere lavorato, asciugato, riletto e riscritto, a volte scompaginato e riorganizzato, corretto e limato attraverso un processo iterativo che assomiglia al lavoro dello scultore, che toglie dal blocco di marmo tutto l'inessenziale per far emergere quello che già esiste "nel marmo", affinando via via il lavoro del martello e dello scalpello.
Sull'argomento della revisione di un testo ho già scritto diversi post, riuniti nella sezione Esercizi di riscrittura.
In particolare vi invito a leggere i post del:
Quello che mi preme sottolineare è che:
- la ricerca della Qualità è un PROCESSO e come tale può essere studiato e ingegnerizzato;
- la Qualità non è mai gratis, ma richiede un lavoro;
- la Qualità è un "TUTTO" che molto spesso non riusciamo ad ottenere completamente ma a volte, con opportune strategie, possiamo ottenere almeno "UNA PARTE DEL TUTTO" e sarà comunque meglio del "NULLA".
giovedì 16 settembre 2010
La Qualità della documentazione tecnica: Chiarezza e Sintesi
Iniziamo questo percorso alla ricerca della Qualità della documentazione tecnica, secondo uno schema ispirato al principio del "learning by doing", partendo da osservazioni concrete e cercando di desumere, da queste, dei principi di ordine generale... se possibile!
Quando decidiamo di leggere un romanzo per passione e per diletto, è spesso molto gratificante abbandonarsi nei labirinti concettuali che l'autore ci propone, seguendo il filo di una costruzione intrigante e ricca di enigmi e sorprese.
Quando invece leggiamo un documento tecnico, lo facciamo per motivi professionali.
Cerchiamo in esso informazioni che ci servono per il nostro lavoro, per risolvere problemi concreti (installare un software, montare un armadio, configurare le funzionalità del nostro nuovo televisore al plasma,...), disponendo di tempi generalmente sempre molto compressi.
Quindi cosa c'è di più desiderabile di un documento incentrato sulla CHIAREZZA e sulla SINTESI?
In effetti è proprio quello che vogliamo: trovare tutte le informazioni che ci necessitano espresse chiaramente, senza omissioni e senza inutili giri di parole. C'è qualcuno di voi che ha il coraggio di alzare la mano e contestrmi? Chi di voi vuole leggere un documento OSCURO e PROLISSO? Quindi sto sostenendo un'ovvietà! Siete proprio sicuri?
Ora mi viene in mente che avrei potuto scivere "senza inutili circonlocuzioni".
Secondo me "CIRCONLOCUZIONI" è molto meno di chiaro di "GIRI DI PAROLE".
Però è più sintetico, è una sola parola, mentre "GIRI DI PAROLE" sono 3 parole!
Il problema è proprio questo: generalmente CHIAREZZA e SINTESI sono due proprietà in contrasto.
UN esempio? Eccolo:
FRASE 1
"MyNet Manager è un prodotto finalizzato alla gestione ottimizzata di una LAN (Local Area Network). Attraverso la Web COnsole di Amministrazione di MyNet Manager, è possibile configurare facilmente numerosi parametri per l'analisi e la gestione della vostra rete. MyNet Manager vi mette a disposizione un largo set di opzioni finalizzate ad individuare e tracciare tutte le informazioni che caratterizzano la dinamica funzionale della vostra rete"
E' chiaro? Non ne sono certo. E' sintetico? No!
Che cosa avete capito? Troppi aggettivi? Temo di si.
Riscriviamolo:
FRASE 2
"MyNet Manager è una Administration Web Console che vi permette di monitorare un largo set di caratteristiche della vostra LAN (Local Area Network), configurando facilmente un gran numero di parametri necessari a tale scopo".
Questa versione mi piace, mi sembra abbastanza chiara e più sintetica.
La volete più sintetica?
FRASE 3
"MyNet Manager vi permette di monitorare un largo set di caratteristiche della vostra rete locale".
Mi sembra ancora sufficentemente chiara e super sintetica.
Più di così non è possibile... o si?
FRASE 4
"MyNet Manager controlla la rete locale".
La rete di che? Di chi? In che senso la controlla? Come?
No, qui non ci siamo, abbiamo ottenuto una sintesi esagerata ma la chiarezza è scomparsa.
Se volessimo avere una rappresentazione grafica qualitativa della relazione che lega CHIAREZZA e SINTESI, potremmo disegnare un grafico di questo tipo:
Ad ogni FRASE k corrisponde una coppia di coordinate (SFk,CFk) che corrispondono ai valori di SINTESI e CHIAREZZA della frase in esame.
Come si osserva facilmente, quando la sintesi è elevata (SF4), la chiarezza tende a 0 (CF4). Se la sintesi invece tende a 0 (SF1), la chiarezza tende ad essere più elevata (CF1).
Esiste poi una coppia di valori (SF,CF), indicata in BLU, che ci consente di massimizzare la chiarezza, accettando un livello di sintesi non troppo elevato. Aumentando il valore della sintesi si arriva ad individuare una zona del grafico caratterizzata da un rettangolo azzurro che forse rappresenta la zona di miglior equilibrio tra i valori combinati di questi attributi.
In effetti, sia la FRASE 2 (SF2,CF2) che la FRASE 3 (SF3,CF3) possono essere considerate accettabili. Il grafico ovviamente è solo un modo di visualizzare l'andamento qualitativo che lega questi due concetti, un ausilio a supporto della mia tesi. La cosa che mi interssa veramente è sottolineare che CHIAREZZA e SINTESI sono ingredienti necessari e contrastanti, che devono essere armonizzati quanto più possibile e che possono rappresentare la prima tessera del puzzle della Qualità che stiamo tentando di ricostruire. Leggi questo articolo...
Quando decidiamo di leggere un romanzo per passione e per diletto, è spesso molto gratificante abbandonarsi nei labirinti concettuali che l'autore ci propone, seguendo il filo di una costruzione intrigante e ricca di enigmi e sorprese.
Quando invece leggiamo un documento tecnico, lo facciamo per motivi professionali.
Cerchiamo in esso informazioni che ci servono per il nostro lavoro, per risolvere problemi concreti (installare un software, montare un armadio, configurare le funzionalità del nostro nuovo televisore al plasma,...), disponendo di tempi generalmente sempre molto compressi.
Quindi cosa c'è di più desiderabile di un documento incentrato sulla CHIAREZZA e sulla SINTESI?
In effetti è proprio quello che vogliamo: trovare tutte le informazioni che ci necessitano espresse chiaramente, senza omissioni e senza inutili giri di parole. C'è qualcuno di voi che ha il coraggio di alzare la mano e contestrmi? Chi di voi vuole leggere un documento OSCURO e PROLISSO? Quindi sto sostenendo un'ovvietà! Siete proprio sicuri?
Ora mi viene in mente che avrei potuto scivere "senza inutili circonlocuzioni".
Secondo me "CIRCONLOCUZIONI" è molto meno di chiaro di "GIRI DI PAROLE".
Però è più sintetico, è una sola parola, mentre "GIRI DI PAROLE" sono 3 parole!
Il problema è proprio questo: generalmente CHIAREZZA e SINTESI sono due proprietà in contrasto.
UN esempio? Eccolo:
FRASE 1
"MyNet Manager è un prodotto finalizzato alla gestione ottimizzata di una LAN (Local Area Network). Attraverso la Web COnsole di Amministrazione di MyNet Manager, è possibile configurare facilmente numerosi parametri per l'analisi e la gestione della vostra rete. MyNet Manager vi mette a disposizione un largo set di opzioni finalizzate ad individuare e tracciare tutte le informazioni che caratterizzano la dinamica funzionale della vostra rete"
E' chiaro? Non ne sono certo. E' sintetico? No!
Che cosa avete capito? Troppi aggettivi? Temo di si.
Riscriviamolo:
FRASE 2
"MyNet Manager è una Administration Web Console che vi permette di monitorare un largo set di caratteristiche della vostra LAN (Local Area Network), configurando facilmente un gran numero di parametri necessari a tale scopo".
Questa versione mi piace, mi sembra abbastanza chiara e più sintetica.
La volete più sintetica?
FRASE 3
"MyNet Manager vi permette di monitorare un largo set di caratteristiche della vostra rete locale".
Mi sembra ancora sufficentemente chiara e super sintetica.
Più di così non è possibile... o si?
FRASE 4
"MyNet Manager controlla la rete locale".
La rete di che? Di chi? In che senso la controlla? Come?
No, qui non ci siamo, abbiamo ottenuto una sintesi esagerata ma la chiarezza è scomparsa.
Se volessimo avere una rappresentazione grafica qualitativa della relazione che lega CHIAREZZA e SINTESI, potremmo disegnare un grafico di questo tipo:
Ad ogni FRASE k corrisponde una coppia di coordinate (SFk,CFk) che corrispondono ai valori di SINTESI e CHIAREZZA della frase in esame.
Come si osserva facilmente, quando la sintesi è elevata (SF4), la chiarezza tende a 0 (CF4). Se la sintesi invece tende a 0 (SF1), la chiarezza tende ad essere più elevata (CF1).
Esiste poi una coppia di valori (SF,CF), indicata in BLU, che ci consente di massimizzare la chiarezza, accettando un livello di sintesi non troppo elevato. Aumentando il valore della sintesi si arriva ad individuare una zona del grafico caratterizzata da un rettangolo azzurro che forse rappresenta la zona di miglior equilibrio tra i valori combinati di questi attributi.
In effetti, sia la FRASE 2 (SF2,CF2) che la FRASE 3 (SF3,CF3) possono essere considerate accettabili. Il grafico ovviamente è solo un modo di visualizzare l'andamento qualitativo che lega questi due concetti, un ausilio a supporto della mia tesi. La cosa che mi interssa veramente è sottolineare che CHIAREZZA e SINTESI sono ingredienti necessari e contrastanti, che devono essere armonizzati quanto più possibile e che possono rappresentare la prima tessera del puzzle della Qualità che stiamo tentando di ricostruire. Leggi questo articolo...
martedì 7 settembre 2010
Lo Zen e la Qualità della documentazione tecnica
Quando avevo 17 anni ho letto "Lo Zen e l'arte della manutenzione della motocicletta" di Robert Pirsig, un libro che ritengo straordinario per molti versi e nel quale, per la prima volta, mi sono imbattuto in un'analisi sistematica del concetto di "Qualità".
“Il Buddha, il Divino, dimora nel circuito di un calcolatore o negli ingranaggi del cambio di una moto con lo stesso agio che in cima a una montagna o nei petali di un fiore”
Questa frase del libro è come una porta mistica, che trascina il lettore in un percorso complesso in cui Pirsig, ad esempio, si focalizza sulla struttura della filettatura di una vite.
La capacità di capire il senso e lo scopo della filettatura di una vite è la "chiave" che ci apre la porta per incontrare il concetto di Qualità. O meglio, è una delle innumerevoli facce con cui la Qualità/il Divino "ci parla".
In questi ultimi anni mi sono spesso ritrovato ad osservare che valutare la Qualità del proprio lavoro è un rompicapo poco circoscrivibile, perchè sono molti gli elementi da valutare e le relazioni che li legano.
Ma la domanda rimane e ne richiama un'altra, più prosaica, ma strategica: quanto costa un documento tecnico?
Di solito siamo abituati a pensare che il prezzo di un bene dipenda da alcuni fattori. Nel caso di un documento tecnico i 3 principali elementi sono:
- la qualità del documento
- il tempo impiegato a realizzarlo
- gli standard di mercato (cioè il generale rapporto tra domanda e offerta)
Questi 3 elementi principali sono spesso molto intrecciati (difficilmente si potrà chiedere un prezzo molto più elevato del prezzo medio di mercato per un certo documento, ad esempio un Tutorial, anche se avete implementato delle soluzioni qualitativamente molto pregiate, impiegando magari per questo motivo un tempo superiore alla norma).
Tuttavia, alla base c'è un impianto concettuale che non può prescindere dalla Qualità. Del resto, a Natale, ho spesso acceso il camino con delle Installation Guide che non hanno mai installato nulla!
Pirsig sarebbe capace di descrivere la Qualità di un documento tecnico secondo uno schema completo e sferico. Ma io non sono Pirsig e vorrei solo provare ad individuare alcune possibili ragionevoli risposte, basate sulla mia esperienza e su quella di altri TW.
Se volete contribuire, fatevi avanti.
Leggi questo articolo...
“Il Buddha, il Divino, dimora nel circuito di un calcolatore o negli ingranaggi del cambio di una moto con lo stesso agio che in cima a una montagna o nei petali di un fiore”
Questa frase del libro è come una porta mistica, che trascina il lettore in un percorso complesso in cui Pirsig, ad esempio, si focalizza sulla struttura della filettatura di una vite.
La capacità di capire il senso e lo scopo della filettatura di una vite è la "chiave" che ci apre la porta per incontrare il concetto di Qualità. O meglio, è una delle innumerevoli facce con cui la Qualità/il Divino "ci parla".
In questi ultimi anni mi sono spesso ritrovato ad osservare che valutare la Qualità del proprio lavoro è un rompicapo poco circoscrivibile, perchè sono molti gli elementi da valutare e le relazioni che li legano.
Ma la domanda rimane e ne richiama un'altra, più prosaica, ma strategica: quanto costa un documento tecnico?
Di solito siamo abituati a pensare che il prezzo di un bene dipenda da alcuni fattori. Nel caso di un documento tecnico i 3 principali elementi sono:
- la qualità del documento
- il tempo impiegato a realizzarlo
- gli standard di mercato (cioè il generale rapporto tra domanda e offerta)
Questi 3 elementi principali sono spesso molto intrecciati (difficilmente si potrà chiedere un prezzo molto più elevato del prezzo medio di mercato per un certo documento, ad esempio un Tutorial, anche se avete implementato delle soluzioni qualitativamente molto pregiate, impiegando magari per questo motivo un tempo superiore alla norma).
Tuttavia, alla base c'è un impianto concettuale che non può prescindere dalla Qualità. Del resto, a Natale, ho spesso acceso il camino con delle Installation Guide che non hanno mai installato nulla!
Pirsig sarebbe capace di descrivere la Qualità di un documento tecnico secondo uno schema completo e sferico. Ma io non sono Pirsig e vorrei solo provare ad individuare alcune possibili ragionevoli risposte, basate sulla mia esperienza e su quella di altri TW.
Se volete contribuire, fatevi avanti.
Leggi questo articolo...
sabato 4 settembre 2010
Gli 8 errori da evitare in un White Paper: seconda parte
Nel post del 2-9-2010 ho indicato i primi 4 errori da evitare nella realizzazione di un White Paper. Ora analizziamo gli ultimi 4 errori.
ERRORE n° 5: contenuti non interessanti!
Carenza di dati validi e credibili, informazioni datate, link verso risorse non più raggiungibili,statistiche e informazioni non verificabili, impaginazione poco accurata, inutile spazio vuoto usato solo per allungare il numero delle pagine e altri orrori similari: tutto ciò svuota di credibilità il vostro White Paper.
Usate i dati (statistiche, case studies, industry report,…) di terze parti credibili e/o analisti riconosciuti del settore specifico di cui si occupa il WP.
Ma sappiate anche posizionare tali informazioni nel punto giusto e principalmente:
- nell’introduzione;
- in grafici e tabelle posizionate in prossimità dei concetti chiave;
- nelle note eventualmente presenti.
Scrivete in maniera chiara e semplice, utilizzando esempi efficaci e sintetici, con tabelle e grafici ben costruiti, fornendo riferimenti verificabili e autorevoli, costruendo il documento con ritmo ed incisività facendo emergere tutti i concetti chiave in maniera efficace.
Altrimenti, perché qualcuno dovrebbe leggerlo?
ERRORE n° 6: non utilizzare una struttura chiara!
La struttura classica di un White Paper può essere schematizzata nel modo seguente:
- SOMMARIO (1 pagina)
- INTRODUZIONE (1 pagina)
- DEFINIZIONE DEL PROBLEMA (2 pagine)
- ILLUSTRAZIONE DELLA SOLUZIONE (2 pagine)
- CASE STUDY (opzionale, 1 pagina)
- CONCLUSIONI (1 pagina)
Io prediligo uno schema un po’ meno spartano, più articolato, che vi ho già illustrato nel post del 18-2-2010, ma entrambi gli schemi possono essere validi, eventualmente con qualche opportuno adattamento.
Ma è importante che il lettore venga condotto per mano lungo un percorso logico e fluido, dall’introduzione, alla definizione del problema, all’illustrazione della soluzione, alle conclusioni.
ERRORE n° 7: un White Paper troppo corto non funziona!
Si stanno diffondendo WP di 2-4 pagine o addirittura degli “instant WP” di una sola pagina!
Un WP eccessivamente breve, nella infantile illusione di “farsi leggere” da decision maker con poco tempo ed attenzione, viene meno alla sua funzione didattico/educativa fondamentale che consiste nell’informare il lettore sulla soluzione di un problema.
Un WP troppo corto ricade, in un certo senso, nella tipologia dell’ERRORE n° 1, finendo per somigliare ad una Brochure o ad un Abstract.
Su questo aspetto vi segnalo l'opinione di Jonathan Kantor, un “White Paper Guru” molto autorevole.
ERRORE n° 8: sbagliare la chiusura!
Come abbiamo detto, al termine del White Paper il lettore deve avere voglia di contattarvi perché si è convinto che voi potete risolvere il suoproblema. Quindi dovete fornirgli tutti i necessari riferimenti, magari avendo cura di evidenziarli graficamente.
Nella mia esperienza, non sempre il White Paper presenta una chiusura ben organizzata.
Ecco un esempio della “struttura tipo” di una pagina di chiusura, in cui ho volutamente enfatizzato con colori molto marcati le diverse parti che la compongono:
Francamente vi sconsiglio caldamente di utilizzare dei colori così dissonanti in un caso “reale”!
L’importante è focalizzare che nella pagina di chiusura si devono riassumere i vantaggi della soluzione proposta (riquadro verde, in alto a sx), sottolineando eventualmente i passaggi chiave per ottenerla (riquadro beige, in basso a sx).
In alto a dx il logo aziendale o un’altra immagine efficace e in basso a dx tutti i riferimenti per contattare l’azienda. Ovviamente non è l’unica struttura possibile, è solo un esempio, ma è un buon punto di partenza.
Se il vostro White Paper non è contaminato da questi 8 errori, è probabile che sia un buon documento!
Leggi questo articolo...
ERRORE n° 5: contenuti non interessanti!
Carenza di dati validi e credibili, informazioni datate, link verso risorse non più raggiungibili,statistiche e informazioni non verificabili, impaginazione poco accurata, inutile spazio vuoto usato solo per allungare il numero delle pagine e altri orrori similari: tutto ciò svuota di credibilità il vostro White Paper.
Usate i dati (statistiche, case studies, industry report,…) di terze parti credibili e/o analisti riconosciuti del settore specifico di cui si occupa il WP.
Ma sappiate anche posizionare tali informazioni nel punto giusto e principalmente:
- nell’introduzione;
- in grafici e tabelle posizionate in prossimità dei concetti chiave;
- nelle note eventualmente presenti.
Scrivete in maniera chiara e semplice, utilizzando esempi efficaci e sintetici, con tabelle e grafici ben costruiti, fornendo riferimenti verificabili e autorevoli, costruendo il documento con ritmo ed incisività facendo emergere tutti i concetti chiave in maniera efficace.
Altrimenti, perché qualcuno dovrebbe leggerlo?
ERRORE n° 6: non utilizzare una struttura chiara!
La struttura classica di un White Paper può essere schematizzata nel modo seguente:
- SOMMARIO (1 pagina)
- INTRODUZIONE (1 pagina)
- DEFINIZIONE DEL PROBLEMA (2 pagine)
- ILLUSTRAZIONE DELLA SOLUZIONE (2 pagine)
- CASE STUDY (opzionale, 1 pagina)
- CONCLUSIONI (1 pagina)
Io prediligo uno schema un po’ meno spartano, più articolato, che vi ho già illustrato nel post del 18-2-2010, ma entrambi gli schemi possono essere validi, eventualmente con qualche opportuno adattamento.
Ma è importante che il lettore venga condotto per mano lungo un percorso logico e fluido, dall’introduzione, alla definizione del problema, all’illustrazione della soluzione, alle conclusioni.
ERRORE n° 7: un White Paper troppo corto non funziona!
Si stanno diffondendo WP di 2-4 pagine o addirittura degli “instant WP” di una sola pagina!
Un WP eccessivamente breve, nella infantile illusione di “farsi leggere” da decision maker con poco tempo ed attenzione, viene meno alla sua funzione didattico/educativa fondamentale che consiste nell’informare il lettore sulla soluzione di un problema.
Un WP troppo corto ricade, in un certo senso, nella tipologia dell’ERRORE n° 1, finendo per somigliare ad una Brochure o ad un Abstract.
Su questo aspetto vi segnalo l'opinione di Jonathan Kantor, un “White Paper Guru” molto autorevole.
ERRORE n° 8: sbagliare la chiusura!
Come abbiamo detto, al termine del White Paper il lettore deve avere voglia di contattarvi perché si è convinto che voi potete risolvere il suoproblema. Quindi dovete fornirgli tutti i necessari riferimenti, magari avendo cura di evidenziarli graficamente.
Nella mia esperienza, non sempre il White Paper presenta una chiusura ben organizzata.
Ecco un esempio della “struttura tipo” di una pagina di chiusura, in cui ho volutamente enfatizzato con colori molto marcati le diverse parti che la compongono:
Francamente vi sconsiglio caldamente di utilizzare dei colori così dissonanti in un caso “reale”!
L’importante è focalizzare che nella pagina di chiusura si devono riassumere i vantaggi della soluzione proposta (riquadro verde, in alto a sx), sottolineando eventualmente i passaggi chiave per ottenerla (riquadro beige, in basso a sx).
In alto a dx il logo aziendale o un’altra immagine efficace e in basso a dx tutti i riferimenti per contattare l’azienda. Ovviamente non è l’unica struttura possibile, è solo un esempio, ma è un buon punto di partenza.
Se il vostro White Paper non è contaminato da questi 8 errori, è probabile che sia un buon documento!
Leggi questo articolo...
giovedì 2 settembre 2010
Gli 8 errori da evitare in un White Paper: prima parte
In numerosi post precedenti ho cercato di raccontarvi “che cos’è un White Paper”.
In estrema sintesi, un White Paper è un documento di lunghezza variabile tra le 8 e le 15-20 pagine il cui scopo è quello di informare e convincere il lettore attraverso l’identificazione accurata di un problema e la conseguente illustrazione della soluzione che lo risolve.
Il White Paper “perfetto” deve indurre il lettore a contattare l’azienda che attraverso questo documento ha illustrato la sua soluzione.
In tal senso, un White Paper può essere un documento fondamentale come supporto alla vendita di un prodotto, quindi si colloca in una “terra di mezzo” tra l’ottica tecnica e l’ottica commerciale.
Le statistiche disponibili (qui potete consultare un articolo ed un PDF, entrambi autorevoli), indicano che almeno 7 utenti su 10, ritengono che un WP sia:
- un ottimo strumento per conoscere le soluzioni di un’azienda;
- utile per investigare nuove soluzioni tecniche;
- molto influente nelle loro scelte finali.
Il lettore di questo tipo di documenti è generalmente un decision maker, nel senso più ampio del termine, che dispone di poco tempo e di un livello di attenzione non elevato e che evita istintivamente la lettura di documenti molto voluminosi, sempre alla ricerca di contenuti innovativi e interessanti, confezionati in una forma sintetica e incisiva.
Vi ho già parlato di COME DEVE ESSERE REALIZZATO un White Paper.
Ora ribaltiamo il punto di vista ed esaminiamo QUALI ERRORI FONDAMENTALI BISOGNA EVITARE!
ERRORE n° 1: il White Paper… è un White Paper, non altro!
Il White Paper NON E’ una Brochure, che ha il compito di “agganciare” l’attenzione di un potenziale cliente attraverso un flusso di comunicazione rapido, d’impatto e, in qualche modo, più “emozionale” che informativo.
Il White Paper NON E’ un Manuale Tecnico e non dispone di un gran numero di pagine (15 sono già molte) , quindi non deve entrare nei particolari di una soluzione né può indagare ogni aspetto tecnico di un prodotto.
Il White Paper NON E’ un Abstract in cui si riassume, in una sola pagina e in una forma esclusivamente testuale, il senso della soluzione proposta.
Il White Paper NON E’ una presentazione, in cui le informazioni vengono presentate in un formato estremamente asciutto e che richiede sempre il supporto della “voce narrante” per poter sviluppare i contenuti riassunti nelle diverse schermate.
Concludendo, il White Paper non è null’altro che un White Paper!
Se non avete chiara la distinzione fra la struttura ed il ruolo di un White Paper rispetto alla struttura ed il ruolo di altri tipi di documenti, il White Paper non risulterà credibile.
ERRORE n° 2: non saper individuare il vostro “lettore target”!
Dovete sempre chiedervi: chi leggerà il mio White Paper?
In altri termini, dovete essere in grado di saper rispondere a domande del tipo:
- Quale sarà il suo livello di conoscenza dell’argomento trattato?
- La sua posizione professionale?
- Che tipo decisioni può prendere?
- Quanto tempo/attenzione dedicherà alla lettura del mio White Paper?
- E’ più incline a leggere un documento stampato o in formato digitale?
- Quale tono sarà più proficuo (accademico, informale, tecnico, commerciale,…)?
ERRORE n° 3: sbagliare il titolo!
Sbagliare il titolo può essere un errore senza ritorno!
Lo spazio e l’attenzione che dedicherete ad un titolo potrà fare la differenza tra un decision maker che apre il vostro WP e lo legge oppure lo accantona a prendere polvere in un angolo della scrivania!
Alcuni trucchi? Almeno 2.
TITOLO E SOTTOTITOLO
Il titolo non dovrebbe svilupparsi con più di 8-10 parole.
Il sottotitolo può svilupparsi su 2/3 righe e può aiutare a fornire più elementi semantici a supporto del titolo, consentendo di realizzare una struttura “a due livelli” che presenta una maggiore e più efficace articolazione.
DITE AL LETTORE CHE COSA OTTERRA’
Se fin dal titolo riesco ad intuire la soluzione al mio problema, allora lo leggerò!
Un esempio?
Immaginate di aver bisogno di una piattaforma di Content Management System per la vostra azienda.
Vi sottopongono due WP, intitolati rispettivamente:
(WP 1) Una piattaforma completa e potente per la gestione della comunicazione aziendale
(WP 2) Gestione documentale, blog, forum e newsletter: poco tempo e pochi click per “esistere”
Io leggerei per primo WP2, e voi?
Il titolo di WP1 è generico e banale. Potrei mai desiderare una soluzione che non fosse “completa e potente”? O pensano che io sia così fesso da spendere soldi per una soluzione “debole e incompleta”? E che significa “comunicazione aziendale”? Ci sono molti tipi di comunicazione aziendale: la comunicazione di marketing, quella interna, quella specificatamente tecnica, quella istituzionale,… di che stiamo parlando?
Il titolo di WP2 invece funziona!
Mi dice subito che otterrò 4 cose concrete, in poco tempo e con pochi click, suggerendo una facilità d’uso sopra la media, attraverso le quali l’azienda sarà in grado di mostrarsi e di comunicare, quindi di “esistere”.
Il difetto di WP2 è che è troppo lungo.
Potremmo ristrutturarlo così:
TITOLO: Gestione documentale, blog, forum e newsletter… e l’azienda ESISTE!
SOTTOTITOLO: In poco tempo e pochi click è possibile configurare tutti gli strumenti fondamentali per gestire la documentazione e la comunicazione aziendale in modo integrato e flessibile.
Si può fare di meglio? Sempre… ma già così non è male.
ERRORE n° 4: il vostro lettore non conosce la soluzione che gli state presentando!
Assumere che il lettore sia un esperto dell’argomento trattato è un’ipotesi consolante, perché ci illude di poter lavorare di meno. Ma se fosse un esperto della soluzione che state proponendo, perché dovrebbe leggere il vostro White Paper? Bisogna evitare di eccedere nell’uso di acronimi, abbreviazioni gergali, terminologia eccessivamente tecnica , altrimenti il lettore si sente “respinto”.
Voi non siete più intelligenti perché siete dei super-esperti e lui non è un cretino perché non ha confidenza con lo specifico oggetto che state illustrando.
Il vostro lettore è un potenziale cliente, non dimenticatelo.
Il resto, nel prossimo post.
Leggi questo articolo...
In estrema sintesi, un White Paper è un documento di lunghezza variabile tra le 8 e le 15-20 pagine il cui scopo è quello di informare e convincere il lettore attraverso l’identificazione accurata di un problema e la conseguente illustrazione della soluzione che lo risolve.
Il White Paper “perfetto” deve indurre il lettore a contattare l’azienda che attraverso questo documento ha illustrato la sua soluzione.
In tal senso, un White Paper può essere un documento fondamentale come supporto alla vendita di un prodotto, quindi si colloca in una “terra di mezzo” tra l’ottica tecnica e l’ottica commerciale.
Le statistiche disponibili (qui potete consultare un articolo ed un PDF, entrambi autorevoli), indicano che almeno 7 utenti su 10, ritengono che un WP sia:
- un ottimo strumento per conoscere le soluzioni di un’azienda;
- utile per investigare nuove soluzioni tecniche;
- molto influente nelle loro scelte finali.
Il lettore di questo tipo di documenti è generalmente un decision maker, nel senso più ampio del termine, che dispone di poco tempo e di un livello di attenzione non elevato e che evita istintivamente la lettura di documenti molto voluminosi, sempre alla ricerca di contenuti innovativi e interessanti, confezionati in una forma sintetica e incisiva.
Vi ho già parlato di COME DEVE ESSERE REALIZZATO un White Paper.
Ora ribaltiamo il punto di vista ed esaminiamo QUALI ERRORI FONDAMENTALI BISOGNA EVITARE!
ERRORE n° 1: il White Paper… è un White Paper, non altro!
Il White Paper NON E’ una Brochure, che ha il compito di “agganciare” l’attenzione di un potenziale cliente attraverso un flusso di comunicazione rapido, d’impatto e, in qualche modo, più “emozionale” che informativo.
Il White Paper NON E’ un Manuale Tecnico e non dispone di un gran numero di pagine (15 sono già molte) , quindi non deve entrare nei particolari di una soluzione né può indagare ogni aspetto tecnico di un prodotto.
Il White Paper NON E’ un Abstract in cui si riassume, in una sola pagina e in una forma esclusivamente testuale, il senso della soluzione proposta.
Il White Paper NON E’ una presentazione, in cui le informazioni vengono presentate in un formato estremamente asciutto e che richiede sempre il supporto della “voce narrante” per poter sviluppare i contenuti riassunti nelle diverse schermate.
Concludendo, il White Paper non è null’altro che un White Paper!
Se non avete chiara la distinzione fra la struttura ed il ruolo di un White Paper rispetto alla struttura ed il ruolo di altri tipi di documenti, il White Paper non risulterà credibile.
ERRORE n° 2: non saper individuare il vostro “lettore target”!
Dovete sempre chiedervi: chi leggerà il mio White Paper?
In altri termini, dovete essere in grado di saper rispondere a domande del tipo:
- Quale sarà il suo livello di conoscenza dell’argomento trattato?
- La sua posizione professionale?
- Che tipo decisioni può prendere?
- Quanto tempo/attenzione dedicherà alla lettura del mio White Paper?
- E’ più incline a leggere un documento stampato o in formato digitale?
- Quale tono sarà più proficuo (accademico, informale, tecnico, commerciale,…)?
ERRORE n° 3: sbagliare il titolo!
Sbagliare il titolo può essere un errore senza ritorno!
Lo spazio e l’attenzione che dedicherete ad un titolo potrà fare la differenza tra un decision maker che apre il vostro WP e lo legge oppure lo accantona a prendere polvere in un angolo della scrivania!
Alcuni trucchi? Almeno 2.
TITOLO E SOTTOTITOLO
Il titolo non dovrebbe svilupparsi con più di 8-10 parole.
Il sottotitolo può svilupparsi su 2/3 righe e può aiutare a fornire più elementi semantici a supporto del titolo, consentendo di realizzare una struttura “a due livelli” che presenta una maggiore e più efficace articolazione.
DITE AL LETTORE CHE COSA OTTERRA’
Se fin dal titolo riesco ad intuire la soluzione al mio problema, allora lo leggerò!
Un esempio?
Immaginate di aver bisogno di una piattaforma di Content Management System per la vostra azienda.
Vi sottopongono due WP, intitolati rispettivamente:
(WP 1) Una piattaforma completa e potente per la gestione della comunicazione aziendale
(WP 2) Gestione documentale, blog, forum e newsletter: poco tempo e pochi click per “esistere”
Io leggerei per primo WP2, e voi?
Il titolo di WP1 è generico e banale. Potrei mai desiderare una soluzione che non fosse “completa e potente”? O pensano che io sia così fesso da spendere soldi per una soluzione “debole e incompleta”? E che significa “comunicazione aziendale”? Ci sono molti tipi di comunicazione aziendale: la comunicazione di marketing, quella interna, quella specificatamente tecnica, quella istituzionale,… di che stiamo parlando?
Il titolo di WP2 invece funziona!
Mi dice subito che otterrò 4 cose concrete, in poco tempo e con pochi click, suggerendo una facilità d’uso sopra la media, attraverso le quali l’azienda sarà in grado di mostrarsi e di comunicare, quindi di “esistere”.
Il difetto di WP2 è che è troppo lungo.
Potremmo ristrutturarlo così:
TITOLO: Gestione documentale, blog, forum e newsletter… e l’azienda ESISTE!
SOTTOTITOLO: In poco tempo e pochi click è possibile configurare tutti gli strumenti fondamentali per gestire la documentazione e la comunicazione aziendale in modo integrato e flessibile.
Si può fare di meglio? Sempre… ma già così non è male.
ERRORE n° 4: il vostro lettore non conosce la soluzione che gli state presentando!
Assumere che il lettore sia un esperto dell’argomento trattato è un’ipotesi consolante, perché ci illude di poter lavorare di meno. Ma se fosse un esperto della soluzione che state proponendo, perché dovrebbe leggere il vostro White Paper? Bisogna evitare di eccedere nell’uso di acronimi, abbreviazioni gergali, terminologia eccessivamente tecnica , altrimenti il lettore si sente “respinto”.
Voi non siete più intelligenti perché siete dei super-esperti e lui non è un cretino perché non ha confidenza con lo specifico oggetto che state illustrando.
Il vostro lettore è un potenziale cliente, non dimenticatelo.
Il resto, nel prossimo post.
Leggi questo articolo...
mercoledì 25 agosto 2010
Saper scrivere... il Manuale d'Installazione.
Il Manuale d'Installazione di un prodotto/applicazione software è uno dei documenti più comuni che ognuno di noi ha avuto modo di utilizzare almeno una volta nella vita e sul quale, non di rado, abbiamo anche imprecato laddove risultava poco usabile, non chiaro o incompleto.
Lo scopo del Manuale d'Installazione è quello di fornire tutte le indicazioni necessarie, nel modo più chiaro e sintetico possibile, per installare correttamente un'applicazione.
Anche se alcuni elementi di questo documento possono variare in base alla tipologia di software in esame, è possibile comunque fornire una descrizione abbastanza precisa della sua struttura generale che può essere ritenuta valida nella gran parte dei casi.
Lo schema di riferimento che vi descrivo è formato da 10 sezioni:
- INTRODUZIONE
- PREREQUISITI HARDWARE
- PREREQUISITI SOFTWARE
- COMPATIBILITA' DEL BROWSER (se necessario)
- DESCRIZIONE DELLA DISTRIBUZIONE
- INSTALLAZIONE DEL DATA BASE (se necessario)
- DEPLOY DEI MODULI SULL'APPLICATION SERVER (se necessario)
- CONFIGURAZIONE DELL'APPLICAZIONE (se necessario)
- RISOLUZIONE DEI PROBLEMI
- SUPPORTO ED ASSISTENZA
Analizziamo brevemente ognuna di queste sezioni.
INTRODUZIONE
In questa prima sezione si deve fornire una breve descrizone del prodotto/applicazione.
Al termine di questa sezione può essere eventualmente specificata una frase che ribadiscce la natura e lo scopo del documento:
"Lo scopo di questo documento è quello di descrivere la procedura d’installazione del XYZManager ed è rivolto alle figure amministrative/operative che devono intervenire ai fini dell’installazione del prodotto. Ognuna di queste figure potrà consultare questo documento, utilizzandolo per quanto concerne le prerogative di sua competenza. Tutto ciò che necessita all’installazione del prodotto è specificato in questo manuale".
PREREQUISITI HARDWARE
Qui vanno specificate, se necessario, le caratteristiche minime dell'hardware necessario per poter eseguire l'applicazione (es. 512 MB di memoria centrale RAM, configurazioni LAN/WAN,... ).
PREREQUISITI SOFTWARE
Analogamente al caso precedente, vanno indicati tutti i moduli software che devono essere installati sulla macchina prima di procedere all'installazione dell'applicazione in esame.
Tipicamente, tra questi elementi va sempre specificato il Sistema Operativo ospite, con la
relativa versione. Altri elementi da specificare sono eventuali librerie necessarie all'applicazione (OPEN SSL, OPEN LDAP, ...). In generale, vanno specificati tutti i moduli software necessari che non verranno installati sulla macchina dal processo d'installazione stesso e senza i quali l'applicazione non potrà essere eseguita.
Di seguito è indicata una tabella d'esempio molto semplice che può essere utilizzata a tale scopo:
COMPATIBILITA' DEL BROWSER (se necessario)
Se l'applicazione in questione è un'applicazione Web, è necessario indicare con quali browser e relative versioni è possibile eseguirla.
Questa informazione può essere indicata anche tra i prerequisiti software.
DESCRIZIONE DELLA DISTRIBUZIONE
Un'applicazione software può essere distribuita in diversi modi: su un supporto magnetico, ottico (CD-ROM), su una USB Key, via Web o in altri modi. Indipendentemente dalla modalità e dal supporto fisico, la distribuzione di un software viene organizzata in una gerarchia di cartelle e file che racchiudono tutte le compnenti dell'applicazione.
Questa organizzazione deve essere descritta dettagliatamente, per fornire all'utente tutte le informazioni sulle diverse componenti coinvolte nel processo d'installazione.
INSTALLAZIONE DEL DB (se necessario)
In questa sezione vanno specificate tutte le operazioni necessarie all'installazione del DB.
Questa è una fase generalmente molto delicata, di solito effettuata da tecnici molto specializzati.
Io consiglo sempre di sottolineare questo elemento con una nota del tipo indicato di seguito:
L'installazione di un DB generalmente procede attraverso l'esecuzione di un certo numero di script SQL.
Questa fase deve essere illustrata in modalità "step by step", come mostrato nel breve esempio seguente:
1. Collegarsi al DB con le credenziali di amministratore.
2. Aprire la cartella SCRIPTS fornita con la distribuzione del prodotto.
3. Eseguire il file SCRIPT_01.sql.
4. Eseguire il file SCRIPT_02.sql.
...
Se l'installazione procede in un'altra modalità, bisogna comunque dettagliare tutti i passaggi essenziali.
DEPLOY DELLE COMPONENTI SULL'APPLICATION SERVER (se necessario)
Ogni fase di questa sezione deve essere illustrata in modalità "step by step".
Per ogni componente si deve indicare la posizione d'origine, all'interno della distribuzione di partenza del prodotto, e la posizione finale in cui va collocata, con la descrizione di ogni azione necessaria a tale scopo.
CONFIGURAZIONE DELL'APPLICAZIONE (se necessario)
Dopo aver definito il posizionamento delle diverse componenti dell'applicazione, talvolta è necessario intervenire su alcune di esse per apportare delle modifiche alla configurazione di default.
Questa fase può essere effettuata con l'ausilio di appositi tool o modificando direttamente i file di configurazione previsti a tale scopo. Anche questa fase deve essere attentamente dettagliata.
RISOLUZIONE DEI PROBLEMI
Durante il processo d'installazione, possono verificarsi dei problemi originati da numerose "condizioni d'errore".
Molte di queste condizioni sono note ai progettisti e un buon manuale dovrebbe fornire una descrizione della condizione d'errore e la sua risoluzione, eventualmente supportata da altre informazioni (screenshot, tabelle, ...).
SUPPORTO ED ASSISTENZA
In quest'ultima sezione vanno indicati i riferimenti (email, telefono, ...) dello staff che si occupa di fornire assistenza e supporto tecnico al cliente.
..............
Come sempre, le schematizzazioni che vi propongo sono valide in molti casi ma non possono essere prese "tal quali" ed utilizzate meccanicamente in ogni situazione.
Caso per caso, dovete decidere voi se adattare o specializzare la struttura generale, se togliere una sezione o aggiungerne un'altra, per ottimizzare la vostra soluzione.
Se siete interessati ad ulteriori approfondimenti, sapete dove trovarmi!
;-) Leggi questo articolo...
Lo scopo del Manuale d'Installazione è quello di fornire tutte le indicazioni necessarie, nel modo più chiaro e sintetico possibile, per installare correttamente un'applicazione.
Anche se alcuni elementi di questo documento possono variare in base alla tipologia di software in esame, è possibile comunque fornire una descrizione abbastanza precisa della sua struttura generale che può essere ritenuta valida nella gran parte dei casi.
Lo schema di riferimento che vi descrivo è formato da 10 sezioni:
- INTRODUZIONE
- PREREQUISITI HARDWARE
- PREREQUISITI SOFTWARE
- COMPATIBILITA' DEL BROWSER (se necessario)
- DESCRIZIONE DELLA DISTRIBUZIONE
- INSTALLAZIONE DEL DATA BASE (se necessario)
- DEPLOY DEI MODULI SULL'APPLICATION SERVER (se necessario)
- CONFIGURAZIONE DELL'APPLICAZIONE (se necessario)
- RISOLUZIONE DEI PROBLEMI
- SUPPORTO ED ASSISTENZA
Analizziamo brevemente ognuna di queste sezioni.
INTRODUZIONE
In questa prima sezione si deve fornire una breve descrizone del prodotto/applicazione.
Al termine di questa sezione può essere eventualmente specificata una frase che ribadiscce la natura e lo scopo del documento:
"Lo scopo di questo documento è quello di descrivere la procedura d’installazione del XYZManager ed è rivolto alle figure amministrative/operative che devono intervenire ai fini dell’installazione del prodotto. Ognuna di queste figure potrà consultare questo documento, utilizzandolo per quanto concerne le prerogative di sua competenza. Tutto ciò che necessita all’installazione del prodotto è specificato in questo manuale".
PREREQUISITI HARDWARE
Qui vanno specificate, se necessario, le caratteristiche minime dell'hardware necessario per poter eseguire l'applicazione (es. 512 MB di memoria centrale RAM, configurazioni LAN/WAN,... ).
PREREQUISITI SOFTWARE
Analogamente al caso precedente, vanno indicati tutti i moduli software che devono essere installati sulla macchina prima di procedere all'installazione dell'applicazione in esame.
Tipicamente, tra questi elementi va sempre specificato il Sistema Operativo ospite, con la
relativa versione. Altri elementi da specificare sono eventuali librerie necessarie all'applicazione (OPEN SSL, OPEN LDAP, ...). In generale, vanno specificati tutti i moduli software necessari che non verranno installati sulla macchina dal processo d'installazione stesso e senza i quali l'applicazione non potrà essere eseguita.
Di seguito è indicata una tabella d'esempio molto semplice che può essere utilizzata a tale scopo:
COMPATIBILITA' DEL BROWSER (se necessario)
Se l'applicazione in questione è un'applicazione Web, è necessario indicare con quali browser e relative versioni è possibile eseguirla.
Questa informazione può essere indicata anche tra i prerequisiti software.
DESCRIZIONE DELLA DISTRIBUZIONE
Un'applicazione software può essere distribuita in diversi modi: su un supporto magnetico, ottico (CD-ROM), su una USB Key, via Web o in altri modi. Indipendentemente dalla modalità e dal supporto fisico, la distribuzione di un software viene organizzata in una gerarchia di cartelle e file che racchiudono tutte le compnenti dell'applicazione.
Questa organizzazione deve essere descritta dettagliatamente, per fornire all'utente tutte le informazioni sulle diverse componenti coinvolte nel processo d'installazione.
INSTALLAZIONE DEL DB (se necessario)
In questa sezione vanno specificate tutte le operazioni necessarie all'installazione del DB.
Questa è una fase generalmente molto delicata, di solito effettuata da tecnici molto specializzati.
Io consiglo sempre di sottolineare questo elemento con una nota del tipo indicato di seguito:
L'installazione di un DB generalmente procede attraverso l'esecuzione di un certo numero di script SQL.
Questa fase deve essere illustrata in modalità "step by step", come mostrato nel breve esempio seguente:
1. Collegarsi al DB con le credenziali di amministratore.
2. Aprire la cartella SCRIPTS fornita con la distribuzione del prodotto.
3. Eseguire il file SCRIPT_01.sql.
4. Eseguire il file SCRIPT_02.sql.
...
Se l'installazione procede in un'altra modalità, bisogna comunque dettagliare tutti i passaggi essenziali.
DEPLOY DELLE COMPONENTI SULL'APPLICATION SERVER (se necessario)
Ogni fase di questa sezione deve essere illustrata in modalità "step by step".
Per ogni componente si deve indicare la posizione d'origine, all'interno della distribuzione di partenza del prodotto, e la posizione finale in cui va collocata, con la descrizione di ogni azione necessaria a tale scopo.
CONFIGURAZIONE DELL'APPLICAZIONE (se necessario)
Dopo aver definito il posizionamento delle diverse componenti dell'applicazione, talvolta è necessario intervenire su alcune di esse per apportare delle modifiche alla configurazione di default.
Questa fase può essere effettuata con l'ausilio di appositi tool o modificando direttamente i file di configurazione previsti a tale scopo. Anche questa fase deve essere attentamente dettagliata.
RISOLUZIONE DEI PROBLEMI
Durante il processo d'installazione, possono verificarsi dei problemi originati da numerose "condizioni d'errore".
Molte di queste condizioni sono note ai progettisti e un buon manuale dovrebbe fornire una descrizione della condizione d'errore e la sua risoluzione, eventualmente supportata da altre informazioni (screenshot, tabelle, ...).
SUPPORTO ED ASSISTENZA
In quest'ultima sezione vanno indicati i riferimenti (email, telefono, ...) dello staff che si occupa di fornire assistenza e supporto tecnico al cliente.
..............
Come sempre, le schematizzazioni che vi propongo sono valide in molti casi ma non possono essere prese "tal quali" ed utilizzate meccanicamente in ogni situazione.
Caso per caso, dovete decidere voi se adattare o specializzare la struttura generale, se togliere una sezione o aggiungerne un'altra, per ottimizzare la vostra soluzione.
Se siete interessati ad ulteriori approfondimenti, sapete dove trovarmi!
;-) Leggi questo articolo...
giovedì 19 agosto 2010
White Paper di scenario: un esempio interessante
Vi segnalo un esempio interessante di White Paper di scenario.
E' un WP del 2008 che parla delle prospettive relative alle transazioni economiche sicure in ambito wireless/mobile. E' un argomento al quale sono particolarmente legato, perchè è stato oggetto della mia Tesi di Laurea nel 2002.
Ero largamente in anticipo sui tempi ma oggi si stanno sperimentando diverse architetture hardware/software finalizzate a realizzare pagamenti e transazioni per mezzo di terminali mobili, come i moderni smartphone. In questo White Paper vengono illustrati gli scenari più interessanti e le loro diverse caratteristiche.
L'approccio è del tutto in linea con quanto vi avevo segnalato in un post precedente.
Dal mio punto di vista presenta alcuni difetti, quali l'eccessiva lunghezza (34 pagine) e alcune soluzioni inessenziali (come la lista delle tabelle e delle figure riportata in coda all'indice del documento). Forse alcune parti potevano essere esposte in un modo più sintetico, ma la complessità dell'argomento non rende agevole una trattazione particolarmente asciutta.
Dateci un'occhiata, se volete farvi un'idea più precisa su queta tipologia di WP. Leggi questo articolo...
E' un WP del 2008 che parla delle prospettive relative alle transazioni economiche sicure in ambito wireless/mobile. E' un argomento al quale sono particolarmente legato, perchè è stato oggetto della mia Tesi di Laurea nel 2002.
Ero largamente in anticipo sui tempi ma oggi si stanno sperimentando diverse architetture hardware/software finalizzate a realizzare pagamenti e transazioni per mezzo di terminali mobili, come i moderni smartphone. In questo White Paper vengono illustrati gli scenari più interessanti e le loro diverse caratteristiche.
L'approccio è del tutto in linea con quanto vi avevo segnalato in un post precedente.
Dal mio punto di vista presenta alcuni difetti, quali l'eccessiva lunghezza (34 pagine) e alcune soluzioni inessenziali (come la lista delle tabelle e delle figure riportata in coda all'indice del documento). Forse alcune parti potevano essere esposte in un modo più sintetico, ma la complessità dell'argomento non rende agevole una trattazione particolarmente asciutta.
Dateci un'occhiata, se volete farvi un'idea più precisa su queta tipologia di WP. Leggi questo articolo...
martedì 17 agosto 2010
Quanto costa realizzare un White Paper?
Oggi mi sono imbattuto casualmente in un sito di sedicenti "professionisti" della documentazione tecnica che si propongono per la redazione di diverse tipologie di documenti e che per ogni tipologia propongono delle tariffe standard.
Incuriosito, sono andato sulla voce White Paper, dove ho letto che per realizzare un WP necessitano 55 Euro + IVA per cartella (un foglio formato A4, 1800 battute (30 righe da 60 caratteri), spazi inclusi) e che i tempi di realizzazione oscillano tra i 7 e i 10 giorni.
Sono sempre molto ammirato da chi dimostra di avere le idee così chiare.
Ma avrei voglia di porre qualche domanda.
COME SI FA A PROMETTERE UN TEMPO DI CONSEGNA DI 7-10 GIORNI?
La raccolta dei dati per realizzare un WP può essere molto onerosa.
Tipicamente, richiede la necessità di intervistare i tecnici che hanno elaborato la soluzione da illustrare nel WP, leggere e selezionare tutta la documentazione disponibile sviluppata fino a quel momento, analizzare i dati che gli analisti del settore hanno elaborato sull'argomento.
Solo questa fase può richiedere almeno 5-7 giorni di lavoro, nella migliore delle ipotesi.
Poi bisogna abbozzare la prima stesura, realizzare se necessario i grafici e le tabelle finalizzate a far emergere le informazioni significative, individuare e sottolineare nel modo più efficace i punti salienti della soluzione. Il tutto deve essere organizzato nell'ambito di una stesura sintetica e ben equilibrata tra le diverse parti tipiche della struttura di un WP.
Anche questa fase può richiedere ragionevolmente almeno altri 5 giorni di lavoro.
Poi c'è la fase di rilettura di tutto quanto già realizzato che sovente richiede di intervenire sul 10-20% del testo già prodotto, per limare tutto ciò che non serve o aggiungere qualche elemento che nella prima fase era stato omesso. Eventualmente, qualora lo si ritenga opportuno, si può integrare nel WP un Case Study che descriva una situazione reale in cui la soluzione in oggetto è già stata approntata.
Infine, c'è da curare tutta la parte che riguarda il layout grafico vero e proprio, che supporta i contenuti e guida il lettore dall'introduzione alle conclusioni.
Appare evidente che anche indicare un tempo realizzativo complessivo di 15 giorni, rappresenta in molti casi un esercizio di sfrenato ottimismo!
E POI 7-10 GIORNI PER QUALSIASI TIPO DI WP?
Un WP comparativo può richiedere un grande lavoro iniziale di acquisizione dati e le comparazioni vanno suffragate da dati di riscontro, che vanno anch'essi acquisti, studiati e valutati; quindi vanno messi in relazione, elaborando opportunamente grafici e tabelle.
Un WP sullo stato dell'arte di una soluzione può essere più agevole se siete già ben introdotti nel campo applicativo in cui si colloca tale soluzione, ma se per voi è un campo del tutto nuovo può richiedere un tempo difficilmente prevedibile.
E SU QUALSIASI ARGOMENTO?
Io sono un Ingegnere Informatico, ho una certa esperienza e per me scrivere un WP su soluzioni di sicurezza informatica o altre tematiche tipiche dell'ambito ICT può risultare abbastanza agevole. Ma se mi chiedessero un WP comparativo tra diversi modelli di trattori agricoli, mi richiederebbe un impegno e uno sviluppo temporale sicuramente maggiore, perchè dovrei indagare un ambito nuovo rispetto a quello della mia formazione specifica.
E PER QUALE TARGET?
A partire da una certa soluzione che ne costituisce l'oggetto, è ben diverso strutturare un WP che deve essere letto da un tecnico rispetto a quello che invece è indirizzato ad un analista o ad un dirigente amministrativo.
Potrei continuare, ma mi taccio.
E tacendo sorvolo sul problema della tariffazione, che non può essere stabilita in maniera standardizzata ed aprioristica.
Se quando scrivo un WP mi limito a fare un brutale lavoro di copia&incolla di materiale già pronto, 55 Euro + IVA per cartella è un furto!
Ma se devo elaborare un grafico concettuale legando insieme dati faticosamente raccolti da fonti diverse ed autorevoli, potrei impiegare anche 2 giorni per scrivere QUELLA singola pagina/cartella e in tal caso la tariffa sopraindicata sarebbe assolutamente insufficente.
Quindi lascio ai suddetti sedicenti "professionisti" le loro ingenue certezze calendariali e tariffarie e rimango convinto che la qualità richiede tempo ma alla fine viene premiata da chi la sa apprezzare.
Tuttavia credo che ritornerò sull'argomento più generale dei costi della documentazione, perchè mi rendo conto che poi questo è un nervo sempre scoperto nel rapporto tra il TW e il committente, specialmente nell'ambito della libera professione e della consulenza.
Leggi questo articolo...
Incuriosito, sono andato sulla voce White Paper, dove ho letto che per realizzare un WP necessitano 55 Euro + IVA per cartella (un foglio formato A4, 1800 battute (30 righe da 60 caratteri), spazi inclusi) e che i tempi di realizzazione oscillano tra i 7 e i 10 giorni.
Sono sempre molto ammirato da chi dimostra di avere le idee così chiare.
Ma avrei voglia di porre qualche domanda.
COME SI FA A PROMETTERE UN TEMPO DI CONSEGNA DI 7-10 GIORNI?
La raccolta dei dati per realizzare un WP può essere molto onerosa.
Tipicamente, richiede la necessità di intervistare i tecnici che hanno elaborato la soluzione da illustrare nel WP, leggere e selezionare tutta la documentazione disponibile sviluppata fino a quel momento, analizzare i dati che gli analisti del settore hanno elaborato sull'argomento.
Solo questa fase può richiedere almeno 5-7 giorni di lavoro, nella migliore delle ipotesi.
Poi bisogna abbozzare la prima stesura, realizzare se necessario i grafici e le tabelle finalizzate a far emergere le informazioni significative, individuare e sottolineare nel modo più efficace i punti salienti della soluzione. Il tutto deve essere organizzato nell'ambito di una stesura sintetica e ben equilibrata tra le diverse parti tipiche della struttura di un WP.
Anche questa fase può richiedere ragionevolmente almeno altri 5 giorni di lavoro.
Poi c'è la fase di rilettura di tutto quanto già realizzato che sovente richiede di intervenire sul 10-20% del testo già prodotto, per limare tutto ciò che non serve o aggiungere qualche elemento che nella prima fase era stato omesso. Eventualmente, qualora lo si ritenga opportuno, si può integrare nel WP un Case Study che descriva una situazione reale in cui la soluzione in oggetto è già stata approntata.
Infine, c'è da curare tutta la parte che riguarda il layout grafico vero e proprio, che supporta i contenuti e guida il lettore dall'introduzione alle conclusioni.
Appare evidente che anche indicare un tempo realizzativo complessivo di 15 giorni, rappresenta in molti casi un esercizio di sfrenato ottimismo!
E POI 7-10 GIORNI PER QUALSIASI TIPO DI WP?
Un WP comparativo può richiedere un grande lavoro iniziale di acquisizione dati e le comparazioni vanno suffragate da dati di riscontro, che vanno anch'essi acquisti, studiati e valutati; quindi vanno messi in relazione, elaborando opportunamente grafici e tabelle.
Un WP sullo stato dell'arte di una soluzione può essere più agevole se siete già ben introdotti nel campo applicativo in cui si colloca tale soluzione, ma se per voi è un campo del tutto nuovo può richiedere un tempo difficilmente prevedibile.
E SU QUALSIASI ARGOMENTO?
Io sono un Ingegnere Informatico, ho una certa esperienza e per me scrivere un WP su soluzioni di sicurezza informatica o altre tematiche tipiche dell'ambito ICT può risultare abbastanza agevole. Ma se mi chiedessero un WP comparativo tra diversi modelli di trattori agricoli, mi richiederebbe un impegno e uno sviluppo temporale sicuramente maggiore, perchè dovrei indagare un ambito nuovo rispetto a quello della mia formazione specifica.
E PER QUALE TARGET?
A partire da una certa soluzione che ne costituisce l'oggetto, è ben diverso strutturare un WP che deve essere letto da un tecnico rispetto a quello che invece è indirizzato ad un analista o ad un dirigente amministrativo.
Potrei continuare, ma mi taccio.
E tacendo sorvolo sul problema della tariffazione, che non può essere stabilita in maniera standardizzata ed aprioristica.
Se quando scrivo un WP mi limito a fare un brutale lavoro di copia&incolla di materiale già pronto, 55 Euro + IVA per cartella è un furto!
Ma se devo elaborare un grafico concettuale legando insieme dati faticosamente raccolti da fonti diverse ed autorevoli, potrei impiegare anche 2 giorni per scrivere QUELLA singola pagina/cartella e in tal caso la tariffa sopraindicata sarebbe assolutamente insufficente.
Quindi lascio ai suddetti sedicenti "professionisti" le loro ingenue certezze calendariali e tariffarie e rimango convinto che la qualità richiede tempo ma alla fine viene premiata da chi la sa apprezzare.
Tuttavia credo che ritornerò sull'argomento più generale dei costi della documentazione, perchè mi rendo conto che poi questo è un nervo sempre scoperto nel rapporto tra il TW e il committente, specialmente nell'ambito della libera professione e della consulenza.
Leggi questo articolo...
lunedì 16 agosto 2010
L'uso dell'accento: regole sui monosillabi
In italiano le regole sugli accenti derivano sostanzialmente dall’uso prevalente consolidato, più che da motivazioni logiche; in generale è buona norma evitare di apporre l’accento se non è necessario.
L’accento distintivo serve a definire il valore grammaticale di un monosillabo, distinguendolo dagli omografi, per renderne esplicito il significato.
Se volessimo adottare una regola “riassuntiva” sui monosillabi, efficace nella maggiorparte dei casi, potremmo enunciarla così:
- un monosillabo è accentato se può avere due significati diversi;
- si accenta, tra i due, il verbo;
- se nessuno dei due monosillabi è un verbo, si accenta quello meno usato;
- se un monosillabo ha solo un significato, non si accenta mai.
Questa regola può essere utile in molti casi ma contempla delle eccezioni, come quelle relative alle note musicali.
Ad esempio, consideriamo la frase:
Il nostro Re ha molto apprezzato la Sinfonia in Re minore che il pianista ha appena eseguito.
E’ evidente che non c’è ambiguità tra il primo Re (inteso come sovrano) ed il secondo Re (inteso come nota musicale), quindi non c’è bisogno di apporre l’accento su uno dei due Re!
La tabella seguente indica l’uso prevalente relativo ai monosillabi elencati nella prima colonna a sinsitra:
La tabella non è esaustiva di tutti i casi possibili, ma riassume “l’uso consueto” per i monosillabi più comuni; unitamente alla regola sopracitata, fornisce una “bussola” per orientarci nella maggiorparte dei casi, ma in alcuni casi ci possono essere delle eccezioni.
Un esempio?
La Grammatica Italiana di Luca Serianni, l’Accademia della Crusca e il Dizionario Treccani concordano nell’indicare che "su" non prende mai l’accento.
Tuttavia in alcuni casi potreste trovare sù (avverbio) distinto da su (preposizione).
Non c'era che da tirar sù lo sportello della gabbia più piccola. (Pirandello)
In questo caso, se si fosse usato il su non accentato, era possibile fraintedere il significato della frase? Evidentemente no.
Se vi attenete alla tabella sicuramente non sbagliate ed eventuali eccezioni non fanno che confermare la proverbiale regola!
Altro esempio?
Giacomo Leopardi utilizza nella poesia A sé stesso il "sé" accentato prima di "stesso".
Per un certo periodo si è diffusa l’indicazione che “se stesso” o “se medesimo” si potesse scrivere omettendo l’accento sul se. Oggi questa posizione è giudicata un’inutile complicazione e si consiglia di mantenere comunque l’accento, come indicato in tabella.
Concludendo, l’uso dell’accento distintivo va valutato solo nei casi in cui serve effettivamente a dirimere una situazione ambigua.
Leggi questo articolo...
L’accento distintivo serve a definire il valore grammaticale di un monosillabo, distinguendolo dagli omografi, per renderne esplicito il significato.
Se volessimo adottare una regola “riassuntiva” sui monosillabi, efficace nella maggiorparte dei casi, potremmo enunciarla così:
- un monosillabo è accentato se può avere due significati diversi;
- si accenta, tra i due, il verbo;
- se nessuno dei due monosillabi è un verbo, si accenta quello meno usato;
- se un monosillabo ha solo un significato, non si accenta mai.
Questa regola può essere utile in molti casi ma contempla delle eccezioni, come quelle relative alle note musicali.
Ad esempio, consideriamo la frase:
Il nostro Re ha molto apprezzato la Sinfonia in Re minore che il pianista ha appena eseguito.
E’ evidente che non c’è ambiguità tra il primo Re (inteso come sovrano) ed il secondo Re (inteso come nota musicale), quindi non c’è bisogno di apporre l’accento su uno dei due Re!
La tabella seguente indica l’uso prevalente relativo ai monosillabi elencati nella prima colonna a sinsitra:
La tabella non è esaustiva di tutti i casi possibili, ma riassume “l’uso consueto” per i monosillabi più comuni; unitamente alla regola sopracitata, fornisce una “bussola” per orientarci nella maggiorparte dei casi, ma in alcuni casi ci possono essere delle eccezioni.
Un esempio?
La Grammatica Italiana di Luca Serianni, l’Accademia della Crusca e il Dizionario Treccani concordano nell’indicare che "su" non prende mai l’accento.
Tuttavia in alcuni casi potreste trovare sù (avverbio) distinto da su (preposizione).
Non c'era che da tirar sù lo sportello della gabbia più piccola. (Pirandello)
In questo caso, se si fosse usato il su non accentato, era possibile fraintedere il significato della frase? Evidentemente no.
Se vi attenete alla tabella sicuramente non sbagliate ed eventuali eccezioni non fanno che confermare la proverbiale regola!
Altro esempio?
Giacomo Leopardi utilizza nella poesia A sé stesso il "sé" accentato prima di "stesso".
Per un certo periodo si è diffusa l’indicazione che “se stesso” o “se medesimo” si potesse scrivere omettendo l’accento sul se. Oggi questa posizione è giudicata un’inutile complicazione e si consiglia di mantenere comunque l’accento, come indicato in tabella.
Concludendo, l’uso dell’accento distintivo va valutato solo nei casi in cui serve effettivamente a dirimere una situazione ambigua.
Leggi questo articolo...
Iscriviti a:
Post (Atom)
