Negen technical writer mythes

Laatst had ik een gesprek met een manager: hoe krijgt mijn team van technical writers meer gewicht? Nu hangen ze er wat bij binnen het bedrijf. Hoog tijd om de mythbusters van stal te halen. Dan wordt veel duidelijk over het werk van de technical writer, zijn persoonlijkheid, zijn waarde voor het bedrijf  en zijn plaats binnen de organisatie. Om maar enkele dingen te noemen.

MythBusters_title_screen.jpg

  1. Een technical writer schrijft de hele dag.
    In werkelijkheid is een technical writer veel meer tijd kwijt aan het vergaren van informatie, het wachten op informatie en het begrijpen van informatie. Meer dan 20% van zijn tijd is hij niet bezig met schrijven.
  2. Een technical writer is een techneut.
    Als een technical writer een techneut was geweest, had hij wel op de stoel van de ontwikkelaar of de engineer gezeten. Vanuit een belangstelling voor IT of machinebouw kijkt hij met de ogen van de lezer naar de hem aangeboden informatie. Die moet helder, kort en bondig, en gestructureerd op papier worden gezet.
  3. Documentatie kost alleen maar geld.
    Technical writers beschrijven en structureren wat in de hoofden van kennisexperts (SME’s) zit. Ze maken in die zin een archief en zijn als team een belangrijk kenniscentrum waar bijvoorbeeld marketing of support een beroep op kunnen doen. Goede documentatie valt op bij prospects. Goede .documentatie is van vitaal belang voor een prospect om klant te worden. Lees ook : De onverwachte kracht van documentatie.
  4. Documentatie? Dat leest toch niemand!
    Je schrijft voor de oud papierbak. Denk je echt dat er iemand op die handleiding zit te wachten? Elke technical writer moet het een keer in zijn loopbaan hebben gehoord. Hier wat munitie. Geen enkele machine, geen enkel medisch apparaat wordt geleverd zonder documentatie. Dat is een Europese verplichting, die vooral met veiligheid te maken heeft. Een API zonder documentatie is als een zanger die een Boeing 747 wil besturen: hij heeft geen idee wat hij moet doen.
  5. Word technical writer! Lekker ontspannen werken.
    Scrum, agile, sprint, release…in een projectmatige wereld kan een technical writer alleen na afloop van een release even ontspannen. Voor de rest: laatste wijzigingen, software doet het niet, testdata zijn incorrect of niet aanwezig. Weet niemand het antwoord op de vraag X nu Y ziek is? Kun je dit project ook nog bijwerken? De deadline is naar voren geschoven. De deadline is naar achteren geschoven en je collega is ziek. Technical writer…voor mensen die tegen een stress-stootje kunnen.
  6. Ontwikkelaars en engineers hebben geen tijd voor een technical writer.
    Die heb ik vaak gehoord. Vooral als vraag in een sollicitatiegesprek hoe je daarmee om ging. Natuurlijk is deze mythe onzin. Iedereen vertelt graag waar hij mij bezig is. Verder moet jij je als technical writer niet verschansen achter je bureau. Een persoonlijke band door vele kopjes koffie in pauzes doet wonderen. Wees actief, wees aanwezig bij stand-ups, wees sociaal. Weet dat je werk belangrijk is. Echt, die collega’s bijten niet. En als je dat toch denkt..zoek een andere baan. Een technical writer moet behalve een goede taalvaardigheid en enig technisch inzicht ook een sociale persoonlijkheid zijn.
  7. Een technical writer doet niet meer dan ‘knippen en plakken’.
    Dat klinkt nogal denigrerend. Een technical writer verzamelt informatie, rangschikt die en presenteert die op een manier die toegevoegde waarde levert aan een product. Van een machineonderdeel krijg je vier pagina’s met informatie, je hebt slechts vier regels nodig; ‘knippen en plakken’? Van een API krijg je de reference documentatie met weinig beschrijvingen van keys, parameters en methods. Dat wordt eerst een vragenrondje en daarna pas tabelgewijs de API beschrijven. Knippen en plakken? Was het maar waar!
  8. Een technical writer heeft geen rol binnen productontwikkeling
    Ben je een technical writer? Dan slaak je nu een diepe zucht. Helaas, in de Software Development Life Cycle (SDLC) wordt onze rol niet genoemd. Het gevolg:
    – geen inzicht in de verschillende ontwikkelfases
    – te laat toegang tot requirements
    – te laat kunnen beginnen met documentatie
    – documentatie niet op tijd af
    – geen toegang tot de User Interface en dus geen mogelijkheid om verbeteringen aan te geven
    – etc.
    – etc.
  9. Tools zijn belangrijker dan technische kennis
    Een tool als RoboHelp, MadCapFlare of AuthorIt heb je binnen een week onder de knie. Dit geldt ook voor een tool als Swagger editor. Al is het dan wel handig dat je enige kennis van YAML hebt. Ook dat is te leren. Over het algemeen zal kennis van een bepaald terrein: medische apparatuur, machinebouw, belangrijker zijn bij het goed kunnen uitoefenen van je werk dan tool-kennis.

En nu een echte mythbuster! Voor een leuk gesprek met een ontwikkelaar of engineer.

Can a penny dropped from a building kill a pedestrian below? The MythBusters have the answer!

 

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google photo

Je reageert onder je Google account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s

Blog op WordPress.com.

Omhoog ↑

%d bloggers liken dit: