Revision [678]

Last edited on 2010-02-23 12:22:31 by DickSpierings [categorie toegevoegd]
Additions:
======Planning en ontwerp======
Bij de planning en initieel ontwerp van de algehele projectaanpak komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden.
=====Andere partijen betrekken=====
=====Terminologie en bewoording =====
=====Project documentatie =====
----
Categorie: [[Projectaanpak]]
Deletions:
Bij planning en initieel ontwerp komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden.
======Andere partijen betrekken ======
======Terminologie en bewoording ======
======Project documentatie ======

Revision [664]

Edited on 2010-02-17 16:40:53 by DickSpierings
Additions:
Juist omdat er zoveel partijen bij betrokken zijn is het aan te bevelen alle afspraken en visies op papier te zetten voordat iedereen zich terugtrekt om 'zijn' ding te doen. Daarbij moet gezegd dat eenmaal gemaakte project documentatie niet heilig is: inzichten en omstandigheden zullen vaak gaandeweg het proces wijzigen en dan is het zaak regelmatig te overleggen en de project documentatie hierop aan te passen.
Deletions:
Juist omdat er zoveel partijen bij betrokken zijn is het aan te bevelen alle afspraken en visies op papier te zetten voordat iedereen zich terugtrekt om 'zijn' ding te doen.
Daarbij moet gezegd dat eenmaal gemaakte project documentatie niet heilig is: inzichten en omstandigheden zullen vaak gaandeweg het proces wijzigen en dan is het zaak regelmatig te overleggen en de project documentatie hierop aan te passen.

Revision [663]

Edited on 2010-02-17 16:40:15 by DickSpierings [toegevoegd project documentatie + links]
Additions:
Zorg ook dat een redactionele fase wordt ingepland die teksten hierop screent.
======Project documentatie ======
Juist omdat er zoveel partijen bij betrokken zijn is het aan te bevelen alle afspraken en visies op papier te zetten voordat iedereen zich terugtrekt om 'zijn' ding te doen.
Daarbij moet gezegd dat eenmaal gemaakte project documentatie niet heilig is: inzichten en omstandigheden zullen vaak gaandeweg het proces wijzigen en dan is het zaak regelmatig te overleggen en de project documentatie hierop aan te passen.
Wel is het zo dat men er tussentijds van mag uitgaan dat alle partijen zich zullen conformeren aan de afspraken die in de op dat moment geldende versie van de project documentatie zijn gemaakt.
- Gebruik technieken als SCRUM of PRINCE II om regelmatig de geldigheid van de projectdocumentatie te verifiëren.
- gebruik een versiebeheersysteem om wijzigingen in de projectdocumentatie te monitoren en ervoor te zorgen dat iedereen met dezelfde versie werkt (distributie!).
Onderdelen van de project documentatie zijn:
- [[ProjectdocInfoplan het informatieplan]]
- [[ProjectdocProjectplan het projectplan]]
- [[ProjectdocPlanning de planning]]
- [[ProjectdocDocStructuur de document structuur]]
- [[ProjectdocTermsStyle de terminologie en schrijfstijl]]

Revision [619]

Edited on 2010-02-03 23:13:53 by DickSpierings [Link naar SingleSourcing toegevoegd]
Additions:
- Een andere manier is het gebruik van [[SingleSourcing content re-use]] waarbij alle technische communicatieproducten uit één bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.
Deletions:
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit één bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.

Revision [612]

Edited on 2010-02-03 19:43:10 by PeterVanBart
Additions:
======Andere partijen betrekken ======
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle neuzen één kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikaspecten van communicatie in een hoofdstructuurontwerp terugkomen.
- Documentatie en trainingen worden voor gebruikers ontwikkeld. Voor welke gebruikers wordt er ontwikkeld? Vergeet hierbij niet de interne gebruikers. Naast (externe) klanten zijn de verkoop- marketing en engineeringsafdeling ook gebruikers; wat zijn hun behoeften?
- Welke media is/zijn gewenst voor gegevensontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm en content voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder en een powerpointpresentatie.
- Veel professionele producten gaan gepaard met trainingen; bij softwareproducten wordt vaak een online help meegeleverd. Alle informatie uit deze technische communicatieproducten moet met elkaar in lijn zijn -dezelfde boodschap uitdragen. Als meerdere communicatieproducten gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) bron wordt gecoördineerd. Denk aan informatie-overdrachtmeetings door specialisten of een R&D-hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden gemaakt en verwerkt worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwatert, teams uit elkaar vallen en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld een pdf en online help.
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit één bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.
======Terminologie en bewoording ======
Deletions:
======andere partijen betrekken ======
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen.
- Documentatie en trainingen wordt voor gebruikers ontwikkeld. Voor welke gebruikers wordt er ontwikkeld? Vergeet hierbij niet de interne gebruikers. Naast (externe) klanten zijn de verkoop- marketing en engineeringsafdeling ook gebruikers; wat zijn hun behoeften?
- Welke media is/zijn gewenst voor gegevens ontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm en content voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.
- veel professionele producten gaan gepaard met trainingen; bij software producten wordt vaak een online help meegeleverd. Alle informatie uit deze technische communicatieproducten moeten met elkaar in lijn zijn -dezelfde boodschap uitdragen. Als meerdere communicatieproducten gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) bron wordt gecoördineerd. Denk aan informatie-overdracht meetings door specialisten of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden gemaakt en verwerkt worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwaterd, teams uit elkaar vallen en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld een pdf en online help.
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit een bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.
======terminologie en bewoording ======

Revision [611]

Edited on 2010-02-03 17:25:09 by DickSpierings
Additions:
- Welke media is/zijn gewenst voor gegevens ontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm en content voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.
Deletions:
- Welke media is/zijn gewenst voor gegevens ontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.

Revision [610]

Edited on 2010-02-03 17:24:36 by DickSpierings
Additions:
- Welke media is/zijn gewenst voor gegevens ontsluiting en welke content moet het bevatten? (denk bij media ook aan (E-)training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.
Deletions:
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.

Revision [609]

Edited on 2010-02-03 17:23:24 by DickSpierings
Additions:
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een gedetailleerde handleiding op CD dan met een paar kilo papier. Een verkoper die op pad moet zal daarentegen meer behoefte hebben aan een beknopte fysieke folder een een powerpoint presentatie.
Deletions:
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een handleiding op CD of online dan met een paar kilo papier...

Revision [608]

Edited on 2010-02-03 17:17:00 by DickSpierings
Additions:
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan training). Bedenk hierbij dat niet elke vorm voor elk type gebruiker even handig is: een monteur met laptop is bijvoorbeeld meer gebaat met een handleiding op CD of online dan met een paar kilo papier...
- veel professionele producten gaan gepaard met trainingen; bij software producten wordt vaak een online help meegeleverd. Alle informatie uit deze technische communicatieproducten moeten met elkaar in lijn zijn -dezelfde boodschap uitdragen. Als meerdere communicatieproducten gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) bron wordt gecoördineerd. Denk aan informatie-overdracht meetings door specialisten of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden gemaakt en verwerkt worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwaterd, teams uit elkaar vallen en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld een pdf en online help.
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit een bron worden samengesteld. Hiervoor is vaak wel meer technische kennis en tooling nodig. Tevens dient de hoofdstructuur hierin te voorzien.
Deletions:
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan vormen van training)
- veel professionele producten gaan gepaard met trainingen; bij software producten zit vaak een online help applicatie. Alle informatie uit deze technische communicatieproducten moeten met elkaar in lijn zijn, dezelfde boodschap uitdragen. Als meerdere communicatievormen gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron wordt gecoördineerd. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden en verwerkt kunnen worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwaterd en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld pdf en online help inhoud.
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig. Tevens dient de hoofdstructuur hierin te voorzien.

Revision [607]

Edited on 2010-02-03 17:09:16 by DickSpierings
Additions:
- veel professionele producten gaan gepaard met trainingen; bij software producten zit vaak een online help applicatie. Alle informatie uit deze technische communicatieproducten moeten met elkaar in lijn zijn, dezelfde boodschap uitdragen. Als meerdere communicatievormen gecreëerd moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron wordt gecoördineerd. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden en verwerkt kunnen worden. Review elkaars producten. Risico hierbij is wel dat dit proces verwaterd en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld pdf en online help inhoud.
- Een andere manier is het gebruik van content re-use waarbij alle technische communicatieproducten uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig. Tevens dient de hoofdstructuur hierin te voorzien.
Behalve een planning en een initieel ontwerp moeten ook afspraken worden gemaakt over te gebruiken terminologie en bewoording: hoe worden bepaalde onderdelen van het product genoemd? Houden alle afdelingen (service, R&D, enginering, verkoop) er dezelfde terminologie op na? Bij vertalingen (localization) moet tevoren ook duidelijk zijn welke termen wel moeten worden vertaald en welke niet. Zo zullen geregistreerde productnamen vaak niet in aanmerking komen voor vertaling. Zorg dus voor een handboek waarin de overeengekomen terminologie is vastgelegd, overleg regelmatig over nieuwe termen en communiceer dit in overleg met marketing naar alle betrokken afdelingen.
Deletions:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; bij software producten moet de online help informatie in lijn zijn met de bijbehorende handleiding op papier (pdf). Als meerdere communicatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron wordt gecoördineerd. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden. Risico hierbij is wel dat het proces verwaterd en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld pdf en online help inhoud.
- Een andere manier is het gebruik van content re-use waarbij alle communicatievormen gelijktijdig uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig. Tevens dient de hoofdstructuur hier op ingericht zijn.
Er moeten ook afspraken worden gemaakt over te gebruiken terminologie en bewoording: hoe worden bepaalde onderdelen van het product genoemd? Houden alle afdelingen (service, R&D, enginering, verkoop) er dezelfde terminologie op na? Bij vertalingen (localization) moet tevoren ook duidelijk zijn welke termen wel moeten worden vertaald en welke niet. Zo zullen geregistreerde productnamen vaak niet in aanmerking komen voor vertaling. Zorg dus voor een handboek waarin de overeengekomen terminologie is vastgelegd, overleg regelmatig over nieuwe termen en communiceer dit in overleg met marketing naar alle betrokken afdelingen.
to be continued...

Revision [606]

Edited on 2010-02-03 17:01:49 by DickSpierings
Additions:
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen.
Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; bij software producten moet de online help informatie in lijn zijn met de bijbehorende handleiding op papier (pdf). Als meerdere communicatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron wordt gecoördineerd. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden. Risico hierbij is wel dat het proces verwaterd en er op den duur verschillen gaan ontstaan tussen bijvoorbeeld pdf en online help inhoud.
- Een andere manier is het gebruik van content re-use waarbij alle communicatievormen gelijktijdig uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig. Tevens dient de hoofdstructuur hier op ingericht zijn.
Deletions:
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als...) de bijbehorende handleiding op papier (pdf). Als meerdere communiciatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron plaatsvindt, die voor iedereen beschikbaar is. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden.
- of... maak een van de vrij te geven communicatievormen leidend.
- Een andere manier is het gebruik van content re-use waarbij alle communicatievormen gelijktijdig uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig.

Revision [605]

Edited on 2010-02-03 16:54:48 by DickSpierings
Additions:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als...) de bijbehorende handleiding op papier (pdf). Als meerdere communiciatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- vanuit één (unieke) informatiebron plaatsvindt, die voor iedereen beschikbaar is. Denk aan informatie-overdracht meetings of een R&D hoofddocument. Zorg ervoor dat wijzigingen aan alle partijen tegelijk bekend worden.
- of... maak een van de vrij te geven communicatievormen leidend.
- Een andere manier is het gebruik van content re-use waarbij alle communicatievormen gelijktijdig uit een bron worden samengesteld. Hiervoor is vaak wel speciale tooling of een eigen IT omgeving nodig.
Deletions:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als...) de bijbehorende handleiding op papier (pdf). Als meerdere communiciatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- één (master) informatiebron heeft -zoals een gezamenlijke informatie-overdracht of een R&D hoofddocument en parallel plaats vindt, zodat wijzigingen door alle partijen worden meegenomen of
- maak een van de vrij te geven communicatievormen leidend (dit laatste heeft wel impact op de planning).
- Een andere manier is het gebruik van content re-use.

Revision [604]

Edited on 2010-02-03 16:48:17 by DickSpierings
Additions:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als...) de bijbehorende handleiding op papier (pdf). Als meerdere communiciatievormen uitgegeven moeten worden, zorg dan dat de ontwikkeling hiervan:
- één (master) informatiebron heeft -zoals een gezamenlijke informatie-overdracht of een R&D hoofddocument en parallel plaats vindt, zodat wijzigingen door alle partijen worden meegenomen of
- maak een van de vrij te geven communicatievormen leidend (dit laatste heeft wel impact op de planning).
- Een andere manier is het gebruik van content re-use.
Deletions:
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als) een uit te geven handleiding op papier (pdf).

Revision [603]

Edited on 2010-02-03 16:39:11 by DickSpierings
Additions:
De initiële ontwerpfase is hét moment om andere communicatiepartijen, zoals training en marketing, bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:
Deletions:
Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:

Revision [602]

Edited on 2010-02-03 16:37:26 by DickSpierings

No differences.

Revision [601]

Edited on 2010-02-03 16:37:10 by DickSpierings
Additions:
Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Het (initieel) ontwerp geldt als basis voor alle betrokken partijen en wordt mede ingevuld door de antwoorden op onderstaande vragen:
- Documentatie en trainingen wordt voor gebruikers ontwikkeld. Voor welke gebruikers wordt er ontwikkeld? Vergeet hierbij niet de interne gebruikers. Naast (externe) klanten zijn de verkoop- marketing en engineeringsafdeling ook gebruikers; wat zijn hun behoeften?
Deletions:
Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Dit (initieel) ontwerp geldt dan als basis voor alle betrokken partijen.
- Documentatie en trainingen wordt voor gebruikers ontwikkeld. Vergeet hierbij niet de interne afdelingen. Naast klanten zijn de verkoop- marketing en engineeringsafdeling ook gebruikers, wat zijn hun behoeften?

Revision [600]

Edited on 2010-02-03 16:33:51 by DickSpierings
Additions:
======andere partijen betrekken ======
Deletions:
======hoofdstructuurontwerp ======

Revision [599]

Edited on 2010-02-03 16:33:13 by DickSpierings
Additions:
Bij planning en initieel ontwerp komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden.
======hoofdstructuurontwerp ======
Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Dit (initieel) ontwerp geldt dan als basis voor alle betrokken partijen.
- Welke media is/zijn gewenst voor gegevens ontsluiting? (denk ook aan vormen van training)
- te ontwikkelen trainingen dient aan te sluiten op de beoogde documentatieset; een online help bij software dient in lijn te zijn met (dezelfde informatie te bevatten als) een uit te geven handleiding op papier (pdf).
======terminologie en bewoording ======
Er moeten ook afspraken worden gemaakt over te gebruiken terminologie en bewoording: hoe worden bepaalde onderdelen van het product genoemd? Houden alle afdelingen (service, R&D, enginering, verkoop) er dezelfde terminologie op na? Bij vertalingen (localization) moet tevoren ook duidelijk zijn welke termen wel moeten worden vertaald en welke niet. Zo zullen geregistreerde productnamen vaak niet in aanmerking komen voor vertaling. Zorg dus voor een handboek waarin de overeengekomen terminologie is vastgelegd, overleg regelmatig over nieuwe termen en communiceer dit in overleg met marketing naar alle betrokken afdelingen.
Deletions:
Bij planning en initieel ontwerp komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden. Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Zou je dit pas later doen dan kan dat voor ongewenste verrassingen zorgen.
- Welke media wenst men te gebruiken voor gegevens ontsluiting? (denk ook aan diverse vormen van training)
- een eventueel te ontwikkelen training dient aan te sluiten op de beoogde documentatieset; een online help dient in lijn te zijn met (dezelfde informatie te bevatten als) een uit te geven handleiding op papier (pdf). Om dubbel werk en en interpretatieverschillen tussen diverse ontwikkelteams te voorkomen moeten alle hergebruikte aspecten van communicatie in een hoofdstructuurontwerp terugkomen. Dit (initieel) ontwerp geldt dan als basis voor alle betrokken partijen.
- Er moeten ook afspraken worden gemaakt over te gebruiken terminologie en bewoording: hoe worden bepaalde onderdelen van het product genoemd? Houden alle afdelingen (service, R&D, enginering, verkoop) er dezelfde terminologie op na? Bij vertalingen (localization) moet tevoren ook duidelijk zijn welke termen wel moeten worden vertaald en welke niet. Zo zullen geregistreerde productnamen vaak niet in aanmerking komen voor vertaling. Zorg dus voor een handboek waarin de overeengekomen terminologie is vastgelegd, overleg regelmatig over nieuwe termen en communiceer dit in overleg met marketing naar alle betrokken afdelingen.

Revision [598]

Edited on 2010-02-03 16:29:33 by DickSpierings
Additions:
Bij planning en initieel ontwerp komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) welke ontwikkeld moet worden. Dit is tevens het moment om andere communicatiepartijen zoals training en marketing bij de ontwikkeling te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Zou je dit pas later doen dan kan dat voor ongewenste verrassingen zorgen.
Deletions:
Bij planning en initieel ontwerp komt veel tegelijk om de hoek kijken. Technische communicatie behelst vaak meer dan een (set) handboek(en) die ontwikkeld moet worden. Dit is tevens het moment om andere communicatiepartijen zoals training en marketing voor het beoogde product te betrekken en een gezamenlijk draaiboek op te stellen waarbij alle gezichten een kant op staan. Zou je dit pas later doen dan kan dat voor ongewenst meerwerk zorgen.

Revision [597]

The oldest known version of this page was created on 2010-02-03 16:27:55 by DickSpierings
Deze website wordt beheerd door de Stic.
Creative Commons License