Я могу написать статью на тему «Успешные проекты документирования.
Часть 3».
Он будет примерно охватывать следующие моменты: Понимание проектов пользовательской документации и важности хорошей документации при разработке программного обеспечения.
Объяснение трех этапов проекта пользовательской документации: создание плана проекта, написание документации и управление производственным процессом.
Кроме того, каждый этап включает советы для тех, кто участвует в проекте документации.
Индексирование: использование индексации по ключевым словам для улучшения функциональности поиска и упрощения доступа пользователей.
Просмотр пользовательской документации для обеспечения технической точности и читаемости.
Тестирование документации на достоверность, полноту и удобство для пользователя, включая соответствующие уровни тестирования и предлагаемые методы тестирования.
Локализация документации в различные версии.
языки, чтобы облегчить работу пользователям, не говорящим по-английски.
Управление изменениями: выявление изменений, оценка их воздействия и информирование руководства проекта.
Отслеживание прогресса и отчетность о соблюдении сроков и поиск возможностей для улучшения, включая регулярные встречи команды и периодические отчеты о ходе работы.
Управление производством: обеспечение высококачественной печати и переплета документов, управление составлением документации к продукту, общение с производственными группами по любым вопросам.
Оценка проекта: рассмотрение того, были ли достигнуты цели документации, решение возможных проблем с продвижением проекта и признание индивидуального вклада.
Необязательно: ссылка на общую форму отчета об оценке, когда это необходимо.
Заключение: подведение итогов важности и преимуществ хорошей документации для программных проектов как неотъемлемой части создания ценных продуктов.
Итак, вы поняли свой проект пользовательской документации и определили его. Теперь вы готовы писать. Вот несколько советов, которые помогут вам на вашем пути. Эта статья не о самом писательстве; речь идет о вещах, которые сопровождают письмо. (Информацию о написании онлайн-справки см. на сайте www.divinewrite.com/helpfulhelp.htm.)
ПРИМЕЧАНИЕ. Это последняя статья в серии из трех, описывающих ключевые элементы хорошего процесса пользовательской документации. (Чтобы прочитать первую и вторую статьи этой серии, перейдите по адресу http://www.divinewrite.com/docoprocess1.htm и http://www.divinewrite.com/docoprocess2.htm.)
Индексирование
Ключевые слова индекса должны быть определены во время написания темы. На данный момент тема ясна в сознании автора, и он хорошо знаком со всеми сложными деталями. Индексирование на этапе написания также означает, что ваши ключевые слова рассматриваются в рамках процесса разработки проекта.
Некоторые авторские инструменты не особенно хорошо поддерживают такой подход (например, некоторые не разрешают множественному доступу авторов к файлам, необходимым для индексации), но, по крайней мере, ключевые слова должны быть перечислены в конце каждого черновика. (В любом случае, в зависимости от авторского инструмента, рецензентам это может быть проще.) СОВЕТ: Дополнительную информацию об индексировании см. в книге «Искусство индексирования» (1994) Бонуры.
Обзоры пользовательской документации
Чтобы гарантировать, что ваша пользовательская документация технически правильна и удобочитаема, вам необходимо, чтобы ее проверил разумный выбор людей. Для программного проекта в ваш список отзывов должен входить эксперт в данной области (обычно программист), архитектор программного обеспечения, возможно, менеджер проекта и еще один писатель. Требования к рецензированию будут различаться в зависимости от каждого проекта, поэтому ваши рецензенты и процедуры рецензирования должны быть задокументированы в вашей рабочей практике.
Тестирование пользовательской документации
Тестирование может проводиться на нескольких уровнях:
Каждый автор должен протестировать собственную пользовательскую документацию, следуя ей при использовании продукта. Но помните, что этот вид тестирования не очень эффективен, потому что писатели склонны следовать инструкциям так, как они думают, что они их написали, а не так, как они их написали на самом деле.
Второй уровень предназначен для тестирования, проводимого другими авторами… в рамках экспертной оценки.
Третий уровень предназначен для отдела тестирования, который проводит формальное тестирование пользовательской документации. Тестирование такого типа проводится нечасто, но попытаться его провести полезно.
Четвертый уровень проводится/должен проводиться как часть бета-тестирования (см. «Управление проектами документации», автор Hackos (1994), стр. 452-453).
Независимо от того, какой уровень тестирования вы используете, он должен быть разработан так, чтобы гарантировать, что документированные задачи соответствуют продукту, а любая онлайн-справка работает правильно. Чтобы пользовательская документация прошла тестирование, она должна соответствовать целям, указанным вами на более ранних этапах проекта.
Локализация пользовательской документации
Хотя локализацию часто считают деятельностью после написания, лучше всего делать ее на этапе написания. Точные сроки могут варьироваться от проекта к проекту, но хорошее практическое правило — поручить переводчикам работать над вторыми черновиками (но только если вы не ожидаете большого количества изменений в черновике). СОВЕТ: Большинство переводчиков, вероятно, предпочтут работать с большим объемом пользовательской документации, а не с отдельными темами, отправляемыми им по частям, поэтому вам следует подождать, пока у вас не будет чего-то приличного размера, чтобы отправить им — возможно, целую предметную область. , в отличие от одной темы.
С локализацией вы балансируете. Если вы отправите пользовательскую документацию переводчикам слишком рано, вы потратите много денег на изменения в переводах. Если вы отправите его слишком поздно, он не будет готов к выпуску продукта.
Управление изменениями
Важно минимизировать влияние изменений на продукт и/или график разработки. Для этого необходимо разработать методику, которая:
1. Определяет изменение
2. Оценивает влияние во времени и/или ресурсах *
3. Информирует руководителя проекта
Вы можете использовать те же методы оценки, что и ранее в проекте.
Отслеживание прогресса написания
Важно отметить, что этап письма – это не просто письмо. Если вы будете отслеживать свой прогресс на каждом этапе пути, вы сможете увидеть, достигнете ли вы поставленных целей и сроков, а также сможете использовать этот проект в качестве учебного опыта… чтобы лучше планировать следующий. . (Вы должны убедиться, что все записи проекта легко доступны для текущего обслуживания и использования в будущем.)
Вам следует отслеживать время, необходимое для выполнения каждого шага, описанного в этой процедуре, а также каждого этапа черновика, времени рассмотрения, общего времени выполнения работ и т. д.
Проведение регулярных встреч команды
Чтобы держать всех членов команды в курсе прогресса в написании, вам следует проводить регулярные собрания команды. Эти встречи должны стать форумом для рассмотрения ваших показателей отслеживания и обсуждения примерного процента выполнения различных тем, которые в настоящее время обсуждаются. Если предполагаемый процент выполнения ниже, чем должен быть с учетом уже затраченного времени, то вы можете действовать в соответствии с этим. Эти встречи позволяют выявить заминки в процессе написания.
Написание отчетов о проделанной работе
Ваше руководство также должно быть в курсе статуса проекта. Вам следует писать периодические отчеты о ходе работы, в которых излагаются:
Где находится проект
Что вы сделали за последний месяц
Что вы планируете делать в следующем месяце
Любые проблемы, с которыми вы столкнулись
Управление производством
Значение слова «производство» варьируется в зависимости от того, над какой документацией вы работаете и какова аудитория. Он может включать в себя такие вещи, как:
Печать
Привязка
Сборка продукта (когда справка компилируется в продукт)
Хотя на этапе производства обычно требуется только управление, вам все равно придется потратить немало времени на проверку и взаимодействие с производственными людьми.
Оценить проект
Целью этапа оценки является рассмотрение:
Прошел ли проект по плану?
Почему? / Почему нет?
Какой вклад отдельные члены команды внесли в общий проект.
Как сработал менеджер проекта.
Достигла ли документация своих целей.
На этом этапе вам пригодятся ваши показатели отслеживания; если в ходе реализации проекта были какие-либо недостатки, они должны каким-то образом их выявить. Вы также можете использовать образец отчета об оценке, предоставленный Hackos в книге «Управление проектами документации» Hackos (1994), стр. 514–518.
Ваша документация прошла успешно?
Теперь, когда вы написали и опубликовали документацию, вам нужно определить, достигла ли она ваших целей. Единственный способ точно сделать это — провести дальнейшее исследование пользователей.
СОВЕТ: Подробную информацию о методах исследования см. в книгах «Управление проектами документации» Хакоса (1994), «Анализ пользователей и задач для проектирования интерфейсов» Хакоса и Редиша (1998), «Социальный маркетинг: новый императив общественного здравоохранения» Маноффа (1985). , «Проектирование качественных исследований», 2-е издание Маршалла и Россмана (1995 г.) и «Проведение фокус-групп – руководство для начинающих пользователей» в книге «Маркетинговая разведка и планирование» Тайнана и Дрейтона (1988 г.).
Вот и все! Помните, что этот процесс является «идеальным». Возьмите то, что подходит вам и вашему проекту, и оставьте то, что не подходит.
Удачи!
-
Четыре Секрета Успеха Adsense
19 Oct, 24 -
Роскосмос Опубликовал Видеоэкскурсию По Мкс
19 Oct, 24 -
Видеоигры Популярнее Кинотеатров
19 Oct, 24 -
Андроид Лаунчеры. Три Ошибки Разработчика
19 Oct, 24
