La réponse idéale serait « aussitôt que possible ». Cela fait des décennies que nous le disons et aussi longtemps qu’on l’ignore.

Si vous avez un plan éditorial compatible avec un plan de produit, c’est à la fois le produit et sa documentation qui peuvent être conçus au même rythme et sans doute avec la même méthode Agile. Cette vision va peut-être effrayer les chefs de projet et les chefs de produit, s’ils pensent que ça va augmenter la redondance ou les coûts. Si les structures Agile fonctionnent pour le développement logiciel, pourquoi ne serait-ce pas le cas pour la documentation ?

Commencez dès que possible.

Définissez des objectifs éditoriaux

Identifiez la cible de la documentation.

Existe-t-il plusieurs niveaux d’expertise chez les utilisateurs ? Si oui, répondez spécifiquement à leurs besoins.

Planifier les parties du logiciel que vous devez documenter. Oui, ceci fait partie d’un plan éditorial.

Définissez les points clés du style rédactionnel.

Identifiez les contributeurs clés

Tous les intervenants sur le produit peuvent être des contributeurs.

  • un responsable produit ou un chef de projet sait pourquoi il requiert un logiciel
  • les développeurs connaissent les détails
  • les équipes support connaissent les problèmes auxquels les utilisateurs sont confrontés

Faites travailler ces acteurs ensemble sur le même plan de projet et le même logiciel.

Planifiez les étapes éditoriales

Faites la distinction entre l’aide contextuelle in-situ et les autres formes de documentation.

La documentation contextuelle doit être écrite de façon collaborative entre les développeurs et les rédacteurs. Cette combinaison évite une double erreur ; le développeur se parlant à lui-même, et le rédacteur qui comprend mal et qui en fait trop.

D’autres formes de documentation peuvent être identifiées pour compléter l’aide contextuelle. Le processus documentaire doit permettre de valider leur réelle utilité.

Planifiez la relecture et les phases de validation

Un logiciel est généralement testé avant sa sortie. Cela doit aussi être le cas pour la documentation technique.

Livrer la documentation avec le produit et mettez-la à jour au même rythme

Les phases de tests alpha et beta doivent intégrer la documentation. Elle doit être traitée selon les mêmes critères.

Qui doit rédiger ?

Des types de documentation différents peuvent avoir des contributeurs différents. Beaucoup d’éditeurs de logiciel n’ont pas forcément d’équipes dédiées à la rédaction technique. Dans ce contexte :

  • les guides d’installation et d’administration peuvent être rédigés par des informaticiens
  • les procédures peuvent être définies par les responsables produit
  • les « Getting Started» peuvent être décrits par les équipes support ou les formateurs
  • les Foires Aux Questions peuvent être suggérées et identifiées par l’équipe support

Si vous avez des rédacteurs techniques, ils peuvent mener le processus et y contribuer. Si vous n’en avez pas, vous pouvez en engager temporairement pour qu’ils ajustent régulièrement votre contenu.