Prima di poter anche solo in parte apporofondire gli aspetti più "tecnici" della questione, presumo di dovervi convincere che il gioco vale la candela. Perchè dovreste abbandonare il modo "tradizionale" di scrivere documenti per la vostra azienda, a vantaggio di una nuova modalità che richiede di sicuro una curva d'apprendimento non banale? Per ALMENO 6 buonissimi motivi, che proverò ad esporre brevemente di seguito.
ZERO ERROR UPDATE
In un'architettura modulare, se un contenuto è replicato in N documenti, sarà necessario modificarlo una sola volta; le modifiche effettuate verranno propagate automaticamente in tutti i documenti in cui il contenuto è collocato, riducendo drasticamente le possibilità di errore che sono naturalmente implicate dalla necessità di effettuare N modifiche "a mano" in N documenti distinti.
RIUTILIZZO DEI CONTENUTI
Lo stesso contenuto può essere collocato in N documenti distinti. Questa proprietà dipende anche dalla "granularità" dei contenuti; più la granuralità di un contenuto è "fine", maggiore è la probabilità che quel contenuto possa essere collocato in ambiti diversi. Ovviamente, un eccesso di granularità può implicare problemi di gestione non banali, quindi devono essere utilizzati opportuni criteri per "spezzettare" il documento monolitico originario nel modo migliore, con la granularità più utile ai nostri scopi.
DOCUMENTI MULTICANALE
Ricordate la faccenda dei "contenuti puri" scorrelati dalla "forma"? Perfetto, visto che abbiamo contenuti puri, in che modo li vogliamo vestire? Vogliamo produrre una Scheda Tecnica in formato DOC o PDF? Vogliamo un Help on Line per Android? O vogliamo dei contenuto Web visualizzabili da un browser qualsiasi, da IE a Firefox? Non è un problema nostro, nel senso che i nostri contenuti, puri e modulari, possono essere vestiti secondo stili e formati diversi. Gli aspetti tecnici di questo passaggio non sono oggetto di questo post, sappiate solo che si può fare.
DOCUMENTI MULTILINGUA
Se ho un contenuto modulare, scritto in italiano, posso immaginare di tradurlo in tutte le lingue che mi servono. A quel contenuto si applicano tutte le considerazioni già illustrate in precedenza, per tutte le lingue che vi servono.
GESTIONE COLLABORATIVA
E' raro che una sola persona abbia la conoscenza per realizzare ogni parte di un documento tecnico. Più di frequente, una sola persona si trova a fare da collettore di molte informazioni diverse provenienti da fonti diverse. Tutto ciò può anche funzionare quando ci troviamo a lavorare su un numero molto limitato di documenti; ma immaginate di dover gestire anche solo 20-30 documenti diversi, con un tasso di aggiornamento anche solo del 30% annuo. Cosa succederebbe se fosse possibile assegnare a K persone diverse lo sviluppo di un documento? Ognuno svilupperebbe la parte di sua competenza (Giallo, Verde, Rosso, ...), senza interferire con il lavoro degli altri, condividendo solo un certo insieme di regole comuni definite nell'ambiente di sviluppo, abbattendo drasticamente i tempi di realizzazione.
INTEGRAZIONE TECNOLOGICA (XML, DITA)
Contenuti "puri", modulari, riutilizzabili. E con quale "vestito" tecnologico? E secondo quale metodo di definizione? Qui ci stiamo spingendo molto avanti, anche se è probabile che molti di voi abbiano già confidenza con lo standard XML, mentre dubito che abbiate lo stesso grado di confidenza con DITA.
Ma ora quello che importa è focalizzare il concetto che esistono diversi "mondi" paralleli in grado di manipolare contenuti modulari, secondo regole che implicano vantaggi e svantaggi, mentre NESSUNO DI QUESTI MONDI è in grado di gestire ed accogliere i vostri tradizionali documenti "monolitici".
Vi ho convinto? Ancora no? E allora riprendiamo un esempio già esposto nel post precedente.
Abbiamo sempre i nostri 12 documenti che ospitano il Glossario, la Bibliografia e le Licenze di parti specifiche contenute nel prodotto ma realizzate da terze parti.
In più, decidiamo di tradurre i nostri 12 documenti in 3 lingue: inglese, spagnolo e russo.
Abbiamo già visto che, dovendo modificare il Glossario, la Bibliografia e i termini delle Licenze, se tali elementi sono immersi in 12 doc monolitici, bisogna realizzare ALMENO 3 modifiche in 12 documenti distinti, per un totale di 36 modifiche "fisiche" distinte. E a questo punto abbiamo sistemato i documenti scritti in italiano.
Ma ora dobbiamo anche tradurre le parti appena modificate in 3 lingue, quindi dobbiamo riportare le 3 modifiche in 12 documenti (per ogni lingua), cioè 36 modifiche "fisiche" distinte per ogni lingua, quindi 36 x 3 = 108 modifiche "fisiche" disitinte (se preferite, 9 x 12).
In totale quindi 36 + 9 + 108 = 153 modifiche distinte.
Ma se questi 3 elementi informativi sono 3 elementi modulari, indipendenti, memorizzati in un Data Base e scorrelati da altri vincoli... cosa cambia? Se li concepiamo così, dobbiamo fare soltanto:
- 3 modifiche sui contenuti in italiano
- 3 traduzioni per ogni modifica, quindi 9 modifiche/traduzioni
I contenuti aggiornati verranno poi "propagati automaticamente" in qualche modo nei 12 documenti che ci servono, nelle 4 lingue considerate (italiano, inglese, spagnolo e russo).
Quindi siamo passati da 153 modifiche "fisiche" a sole 12 modifiche.
Infine, sempre la stessa domanda: se invece di 12 documenti dovessi aggiornare questi contenuti in 120 documenti diversi, quante modifiche/traduzioni dovrei apportare? SEMPRE E SOLO 12!
Ora vi ho convinto?
Nessun commento:
Posta un commento