Nel post precedente ho illustrato 5 ottimi motivi per i quali un'azienda dovrebbe avvalersi della professionalità di un TW. Ed ora, altri 5 motivi... vediamo se vi convinco!
;-)
6: Una buona documentazione parla della Qualità e dell'affidabilità di un'azienda
Quando compro un prodotto e la Quick Start Guide è incomprensibile, mi sento un cliente di serie B e probabilmente non comprerò un nuovo prodotto da quell'azienda, perchè mi comunica la sensazione di non aver cura dei suoi clienti. Forse è un'azienda solo motivata a massimizzare il proprio profitto, comprimendo anche i costi necessari a sviluppare la qualità del prodotto, probabilmente priva di una visione di medio-lungo periodo. E perchè dovrei fidarmi di un'azienda che non si proietta nel SUO futuro? Perchè IO dovrei credere in qualcuno che non crede in se stesso?
Una buona documentazione nobilita il brand di un'azienda ed è un moltiplicatore del rapporto di fiducia fra l'azienda e i suoi clienti.
7: La documentazione fornisce una "memoria" utile a chi sviluppa il prodotto.
Quando un prodotto è particolarmente potente e versatile, risulta inevitabilmente anche complesso da configurare e difficile da usare. Questo non dipende, in tal caso, dal fatto che sia stato progettato/disegnato male, ma deriva dalla sua ricchezza funzionale. L'evoluzione di un prodotto di questo tipo, prima ancora della sua commercializzazione, richiede lo sviluppo di una documentazione accurata, prima di tutto per uso interno, facilitando l'attività di sviluppo del prodotto medesimo.
Tipicamente, quando un nuovo membro viene inserito nel team di sviluppo, se dispone di un set di documenti adeguato può acquisire rapidamente il know-how necessario e risultare produttivo in un tempo molto breve.
Se invece deve essere continuamente affiancato da un supervisore più esperto e deve acquisire le competenze secondo lo schema "prova-sbaglia-impara-riprova", il suo inserimento sarà più lento ed inefficace.
Non siete convinti? Venerdì scorso il mio collega Riccardo ha chiesto di prendere in visione il manuale di un'applicazione Web sviluppata per un cliente, perchè deve realizzare le procedure di collaudo dell'applicazione medesima.
Grazie al fatto che il manuale è già pronto, Riccardo potrà realizzare un documento di collaudo preciso ed efficace molto velocemente.
8: Una documentazione accurata riduce i costi di supporto ed help-desk
Se un prodotto è ben documentato, i clienti possono trovare la maggiorparte delle risposte che necessitano all'interno della documentazione. Ovviamente questo non esime l'azienda che realizza quel prodotto a fornire supporto tecnico e servizi di help-desk. Ma tali servizi costano non poco e sono tanto più onerosi quante più ore di supporto devono fornire.
Se non siete convinti, vi invito a leggere questo post, datato 1995 ma ancora attuale, dal sito Web della AllBusiness.
9: Un Technical Writer può fornire supporto alla realizzazione di corsi d'aggiornamento
Dovendo documentare i prodotti/servizi/soluzioni/architetture di un'azienda, il TW finisce per divenire un esperto di tali argomenti. In particolare, è molto frequente che un tecnico conosca alla perfezione il prodotto di cui si occupa, ma magari non conosca altrettanto bene il prodotto sviluppato dal collega che lavora nella stanza accanto. Il TW invece acquisisce una conoscenza a 360° della soluzioni aziendali. E' inoltre un esperto di comunicazione ed è abituato a guardare ognoi aspetto dal punto di vista del cliente.
Quindi è particolarmente in grado di sviluppare la documentazione e occuparsi della conduzione dei corsi d'istruzione che vengono erogati ai clienti.
10: Un Technical Writer possiede uno skill molto versatile
Il TW sa scrivere i documenti che accompagnano un prodotto, ma può essere coinvolto anche nella scrittura di altre tipologie di documenti, come i contratti o i documenti di offerta. Conosce tutti i prodotti aziendali, quindi può condurre corsi presso i clienti che hanno acquistato il prodotto. Ha conoscenze di grafica e di tecnologie Web (Html, Xml, CMS, Blog,...) e può contribuire alla gestione del sito Web aziendale e alla costruzione dei suoi contenuti. Aiuta il team tecnico a testare e collaudare un prodotto. Sa realizzare una presentazione e conoscendo i prodotti aziendali può affiancare l'attività di pre-vendita o diventare egli stesso un pre-seller.
Un TW può quindi essere utile in diverse zone della scacchiera, può giocare in diversi ruoli, può adattarsi alle esigenze dell'azienda.
---
Adesso avete 10 buone idee sulle quali ragionare.
Ricordatevi che qualsiasi cosa state realizzando, SEMPLICEMENTE NON ESISTE... se non c'è qualcuno che la va a raccontare in giro.
La comunicazione tecnica è solo un sottoinsieme della più ampia strategia di comunicazione, che include la pubblicità e il marketing, finalizzata a sostenere un prodotto. Potete scegliere di non investire nella comunicazione, ma in tal caso non potrete lamentarvi della pochezza dei vostri risultati.
Per la serie "Uomo avvisato...".
POST SCRIPTUM
Recentemente, ho sentito un ingenuo collega affermare che "... Oracle è un prodotto che si vende da solo...".
Nel 1982, quando avevo 16 anni e programmavo in assembler il mio Commodore 64, Oracle era poco più di una start-up, nata qualche anno prima dalle ceneri di un vecchio progetto commissionato dalla CIA e miseramente fallito. Fatevi i conti di quanto hanno investito negli ultimi 28 anni, in termini di pubblicità, marketing e documentazione tecnica, prima di arrivare ad essere "un prodotto che si vende da solo", autentico dominatore del mercato. Sono i migliori? Oggi credo di si, ma negli anni '80 certamente no!
domenica 21 novembre 2010
Perchè un'azienda dovrebbe assumere un Technical Writer: seconda parte
Cosa ha fatto la differenza, cosa ha scavato un solco che oggi sembra difficile da colmare, come hanno moltiplicato i ricavi del loro business? E' solo merito dell'indubbia sagacia tecnica delle loro soluzioni? Fatevi una domanda... datevi una risposta... E NON PRENDETE SCORCIATOIE COME IL MIO INGENUO COLLEGA!
Categoria:
Il mestiere del TW
4 commenti:
Ovviamente una traduzione...ma veramente pessima!
Caro "anonimo", se avrai la bontà di rileggere CON ATTENZIONE l'incipit del post di Sabato 20 Novembre, cui segue quello odierno, ti accorgerai che IO NON DICHIARO MAI DI AVER TRADOTTO l'articolo di Minson, bensì propongo
"una sintesi tradotta e ragionata, conforme all'originale ma con qualche licenza personale, finalizzata a snellire, riorganizzare e contestualizzare le ottime indicazioni di Minson."
Spero che ora sia tutto più chiaro. Del resto il suddetto articolo si sviluppa in 8 pagine, impaginato su due colonne, quindi, qualora tradotto fedelmente, sarebbe illegibile nell'ottica di un blog in cui un post non dovrebbe mai sforare gli 800-1000 caratteri. Del resto, come vedi, ho comunque dovuto suddividere i contenuti su due post, pur avendo sintetizzato quanto ritenevo opportuno.
Comunque terrò conto della tua critica e in futuro sarò più attento. Grazie dell'attenzione.
ciao Alessandro, sono Alessandro da Pisa, scrivo manuali istruzioni anch'io e sono un tecnico. Buona iniziativa quella di presentare a tutti quelli che incappano nel tuo blog questo articolo poichè condivido pienamente tutti i punti sfiorati nel tuo racconto. Ma sopratutto divido con tanti come te l'idea di condividere l'esperienze dei TW, i metodi adottati nell'organizzare e pubblicare i contenuti, i processi di creazione e fruizione della documentazione, i vantaggi dell'XML, dei CMS... io sono un libero professionista per cui ho a che fare con tante aziende, per cui i processi che vedo sono diversi dal tuo... non ho la disponibilità delle macchine (spesso la macchina è quasi "sul camion" quando ti chiamano oppure non è funzionante!), non si trovano le distinte dei componenti commerciali della macchina (ho imparato a fotografare tutte le etichette/targhette dei componenti commerciali!), gli schemi arrivano sempre all'ultimo, i progettisti sono lenti nel rilasciare le risposte, i softwaristi di più...
mi sono sempre chiesto se una azienda conosce veramente la questione di cosa può fare un TW per la propria azienda. Mi sono risposto con molte delle tue affermazioni che ritrovo qua.
quoto pienamente!
Ciao Alessandro. Per questo post sono partito da un articolo di Ben Minson, che ho in buona misura "ritagliato" per poterlo contestualizzare in base alla mia esperienza. Poi ho lasciato indicato il link per leggere anche l'originale in inglese di Ben. Partendo da Ben, passando per le mie mani ed arrivando fino a te, noto con piacere che c'è comunque una condivisione "del mestiere" e delle sue implicazioni, indipendentemente dalla geografia e dallo specifico campo d'azione. In Italia facciamo parte di una nicchia professionale, spesso le aziende non capiscono il valore aggiunto della comunicazione tecnica, in qualche misura spetta a noi "vendere" bene noi stessi. Il blog nasce anche per questo. Se qualcuno cerca un luogo in cui si parla dei paradigmi teorici della comunicazione, ci sono siti ben migliori del mio. Io sono un'autodidatta e fin dall'inizio ho voluto raccontare il mio percorso, le mie conquiste, i miei errori, fornendo elementi anche d'interesse teorico ma surrogati da esempi e inidcazioni "concrete", che nascono dalla fatica che si fa sul campo, quando, come dici tu, devi scrivere una cosa credibile con pochi elementi e che deve essere pronta per IERI.
E questi aspetti, nelle scuole di comunicazione, non le insegnano. Ti ringrazio per l'attenzione e la solidarietà. SE TI INTERESSA, ti invito a leggere il post del 10 Gennaio 2011:
http://artigianodibabele.blogspot.com/2011/01/un-esperimento-per-il-2011-open-blog.html
Se ti va di collaborare al progetto Open Blog, sei il benvenuto.
Ciao.
Posta un commento