Alors vous comprenez votre projet de documentation de l'utilisateur et vous avez specced it out. Vous êtes maintenant prêt à écrire. Voici quelques conseils pour vous aider sur votre chemin. Cet article n'est pas au sujet de l'écriture réelle elle-même ; Il s'agit de choses qui vont avec l'écriture. (Pour plus d'informations sur l'écriture d'aide en ligne, voir http://www.divinewrite.com/helpfulhelp.htm.)
NOTE : Ceci est le dernier article d'une série de trois qui explique les éléments clés d'un processus de documentation utilisateur bien. (Pour lire les articles premiers et deuxième de cette série, aller à http://www.divinewrite.com/docoprocess1.htm et http://www.divinewrite.com/docoprocess2.htm).
Indexation
Mots clés d'index doivent être définis, alors que le sujet est en cours d'écriture. À cette époque, le sujet est clair dans l'esprit de l'auteur, et ils sont très au courant de tous les détails complexes. Indexation lors de l'étape d'écriture signifie aussi que vos mots clés sont examinés dans le cadre du processus de projet.
Certains outils de création ne vraiment facilitent ce genre d'approche particulièrement bien (par exemple, certains ne permettent pas plusieurs accès d'auteur pour les fichiers nécessaires à l'indexation), mais au moins les mots clés doivent figurer à la fin de chaque projet. (En fonction de l'outil de programmation, cela peut effectivement être plus facile pour les examinateurs, en tout cas.) Astuce : Pour plus d'informations sur l'indexation, voir l'Art d'indexation (1994) de Bonura.
Commentaires de documentation utilisateur
Pour vous assurer que votre documentation utilisateur est techniquement correcte et lisible, vous devez l'obtenir par une sélection intelligente des personnes. Pour un projet de logiciel, votre liste de contrôle devrait inclure un expert en la matière (généralement le programmeur), l'architecte logiciel, peut-être le chef de projet et un autre écrivain. Aux exigences d'examen variera selon chaque projet, donc vos réviseurs et revoir les procédures doivent être documentées dans votre travail pracs.
Tester votre documentation utilisateur
Test peut s'effectuer à plusieurs niveaux :
• Chaque auteur devrait tester leur propre documentation utilisateur en suivant qu'il utilise le produit. Mais n'oubliez pas, ce genre de test n'est pas très puissant, parce qu'il y a une tendance chez les écrivains de suivre les instructions qu'ils pensent qu'ils ont écrit, pas tels qu'ils ont rédigés en fait leur.
• Le deuxième niveau est pour les essais à effectuer par d'autres auteurs... dans le cadre de l'examen par les pairs.
• Le troisième niveau est pour le département de test exécuter des tests formels sur la documentation de l'utilisateur. Ce type de test n'arrive pas souvent, mais il est bon d'essayer d'obtenir ce qui se passe.
• Le quatrième niveau est/devrait être réalisé dans le cadre du bêta-test (voir gestion de vos projets de Documentation par Hackos (1994), pp.452-453).
Peu importe quel niveau de test que vous utilisez, il doit être conçu pour s'assurer que les tâches documentées sont true pour le produit, et que toute aide en ligne fonctions correctement. Pour la documentation de l'utilisateur de passer des tests, il a besoin satisfaire les objectifs spécifiés dans les premières phases du projet.
La localisation de votre documentation utilisateur
Même si la localisation est souvent considérée comme une activité post-writing, il est préférable de le faire dans le cadre de la phase de rédaction. Le moment exact peut varier d'un projet, mais une bonne règle est d'obtenir les traducteurs travaillant sur les projets de deuxième (mais seulement si vous n'attendez pas beaucoup de changements au projet). Astuce : La plupart des traducteurs probablement préfèrent travailler sur une partie non négligeable de documentation de l'utilisateur, plutôt que sujets individuels envoyés à eux fragmentaire, donc vous devez attendre jusqu'à ce que vous avez quelque chose d'une taille respectable pour les envoyer – peut-être un domaine entier, par opposition à un seul sujet.
Avec la localisation, vous effectuez un acte d'équilibrage. Si vous envoyez la documentation de l'utilisateur pour les traducteurs trop tôt, vous allez passer beaucoup d'argent sur les modifications apportées à la traduction. Si vous l'envoyez trop tard, il ne sera pas prêt à temps pour la sortie du produit.
Gestion du changement
Il est important que vous réduire au minimum l'impact des modifications apportées à l'annexe du produit et/ou le développement. Pour ce faire, vous devez développer une technique qui :
1. Identifie le changement
2. Estimations de l'impact dans le temps et/ou de ressources *
3. Informe le gestionnaire de projet
Vous pouvez utiliser les mêmes techniques d'estimation que vous avez utilisé précédemment dans le projet.
Suivi des progrès par écrit
Il est important de noter que l'étape d'écriture n'est pas simplement au sujet de l'écriture. Si vous suivez vos progrès à chaque étape le long du chemin, vous serez en mesure de voir si vous allez rencontrer vos jalons et les délais, et vous serez également en mesure d'utiliser ce projet comme une expérience d'apprentissage... de mieux planifier celle qui suit. (Vous devez vous assurer que tous les dossiers de projet sont facilement accessibles pour l'entretien continu et de référence de projet à venir).
Vous devez suivre le temps nécessaire pour effectuer toutes les étapes décrites dans cette procédure ainsi que chaque étape de projet, délais d'examen, les délais total, etc..
Tenue de réunions régulières de l'équipe
Pour éviter que tous les membres de l'équipe informés des progrès d'écriture, vous devez exécuter des réunions régulières de l'équipe. Ces réunions devraient être un forum pour jeter un oeil à vos mesures de suivi et de discuter de l'estimation du pourcentage complet pour les différents thèmes en cours. Si l'estimation du pourcentage complet est plus faible qu'il faudrait du temps déjà passé, alors vous pouvez agir sur elle. Ces réunions permettent d'identifier des attelages dans la progression de l'écriture.
Rédaction des rapports d'étape
Votre gestion doivent également être tenus au courant de l'avancement du projet. Vous devez écrire des rapports d'étape périodiques décrivant :
• Lorsque le projet est à
• Ce que vous avez fait au cours du mois dernier
• Ce que vous voulez faire au cours du mois prochain
• Des problèmes que vous avez rencontrés
Gérer la Production
Le sens de « production » varie en fonction de quel type de documentation que vous préparez et qui est de l'auditoire. Elle peut englober des éléments tels que :
• Impression
• Liaison
• Génération de produit (lorsque l'aide est compilé avec le produit)
Bien que généralement, la phase de production requiert seulement une gestion, vous devez toujours passer un bon bout de temps sur la vérification et assurer la liaison avec les spécialistes de la production.
Évaluation du projet
L'étape de l'évaluation vise à examiner :
• Le projet a-t-il été aller comme prévu ?
• Pourquoi ? / Pourquoi pas ?
• Manière dont les membres ont contribué à l'ensemble du projet d'équipe.
• Comment effectuer le gestionnaire du projet.
• Déterminer si la documentation atteint ses objectifs.
Vos mesures de suivi s'avéreront utiles au cours de cette étape ; s'il y avait des défauts dans l'avancement du projet, ils devraient aller quelque peu à les identifier. Vous pouvez également utiliser l'exemple de rapport d'évaluation fourni par Hackos dans la gestion de vos projets de Documentation par Hackos (1994), pp.514-518.
Votre documentation est réussie ?
Maintenant que vous avez écrit et publié de la documentation, vous devez déterminer si elle a atteint vos objectifs. La seule façon de le faire avec précision consiste à mener de nouvelles recherches de l'utilisateur.
Astuce : Pour plus d'informations sur les méthodes de recherche, jetez un oeil à la gestion de vos projets de Documentation par Hackos (1994), l'utilisateur et l'analyse de la tâche pour la conception de l'Interface de Hackos & Redish (1998), Social Marketing : nouvel impératif pour la santé publique de Manoff (1985), conception Qualitative de recherche 2e édition par Marshall & Rossman (1995) et « Mener des groupes de discussion – A Guide pour nouveaux utilisateurs », en Intelligence Marketing et planification de Tynan & Drayton (1988).
Et c'est tout ! N'oubliez pas, ce processus est un processus « idéal ». Prendre les bits qui conviennent à votre projet et vous et laissez les bits qui ne font pas.
Bonne Chance!
No comments:
Post a Comment