Две истории о том, как писать справку (часть 2)

15.08.2014

Продолжаем рассказ о разных подходах к написанию справки к софту. Том Джонсон, технический писатель из Калифорнии, наглядно на примере показывает нам результаты таких разных подходов. Первая часть статьи тут.

История № 2

Проектная команда компании «Рога и копыта» создаёт комплексное приложение для большого числа пользователей и решает привлечь техписа для написания справочных материалов для пользователей. Техпис создаёт максимально полную справку, основываясь на исследованиях проектной команды, пользователей, тестовых требований и других спецификаций.

Задолго до выпуска приложения технический писатель обеспечивает место для файлов справки отдельно от кода приложения, там, где он сможет обновить их на лету, а затем даёт разработчикам ссылку на интерактивную справку.

После релиза Ким, пользователь, начинает исследовать приложение и обращается к справке для ответов на вопросы. Так как её процесс отличается от того, чего ожидал технический писатель, справка не описывает её ситуацию. Она находит часть ответов и звонит в поддержку за помощью. Поддержка возвращает проблему в проектную команду, и бизнес-аналитик решает ситуацию Ким, объясняя обходной путь.

Техпис подписан на оповещение по электронной почте о каждом обращении в поддержку. Он находит проблему, обсуждает её с бизнес-аналитиком (который просил, чтобы его ставили в копию писем об обращениях пользователей), добавляет решение в справку и тут же публикует обновление.

У других пользователей появляется та же проблема, что и у Ким. Они обращаются к справке и находят решение, которое только что добавил техпис. А у Джо есть вопрос, который он не нашёл в справке. Он задаёт его во время тренинга, который проводит техпис. После тренинга технический писатель добавляет вопрос Джо и решение к справке. Он отправляет Джо ссылку на раздел справки с ответом на его вопрос.

Другим пользователям нужна помощь, и они обращаются к справке. Они удивлены тем, что встретили там такую специфичную информацию. Но они находятся в Южной Америке и их рабочие процессы немного отличаются, поэтому им нужна дополнительная информация. Бизнес-аналитик ставит техписа в копию письма с ответом, и тот обновляет справку.

Каждый раз, когда техпис обновляет справку, это происходит мгновенно в режиме реального времени. Справка основана на технологии единого источника, поэтому обновления тут же попадают и в PDF-файл, обновляя руководства пользователя. Техпису не приходится вручную редактировать печатные материалы. Публикацию можно сделать одним щелчком мышки.

Когда пользователи обращаются к справке, их уверенность растёт, так как они действительно находят нужные ответы. Технический писатель получает отзывы от клиентов о том, как полезны его справочные материалы. В результате, руководитель проекта и бизнес-аналитик могут быть уверены, что техпис вовлечён во все собрания, стоит в копии всех писем и знает обо всех проблемах, решениях и багах в системе. Как только он узнаёт что-то новое, он добавляет это к справке.

В день релиза справка содержала 75 топиков. Теперь она содержит 140. Пользователи пишут руководителю, чтобы выразить своё удовлетворение справочными материалами. Техпис знает и чувствует, что занимает важное место в проекте. Когда выпускаются версии 2 и 3, пользователи в полной уверенности, что найдут ответы на все вопросы, обращаются к справке.

Вывод

Чем отличаются эти два примера? В первом техпис действовал с полной уверенностью, что подготовит полную документацию одновременно с релизом продукта. Его справка оказалась в ловушке приложения без возможности обновиться до обновления самого софта. Когда был готов релиз, техпис был уверен, что закончил работу.

Во втором примере техпис действовал с уверенностью, что не сможет предугадать каждый сценарий, контекст, цель и способ использования приложения до релиза. Он сделал всё возможное, чтобы создать хорошую документацию, но понимал, что справка должна быть «живой» и развиваться уже после релиза.

По факту, релиз просто ознаменовал старт комплексного процесса создания справки. Техпис продолжал дополнять и обновлять существующую справку нужной пользователю информацией.

Один считал, что релиз – это конец, второй – что это только начало.

Источник: Two Stories About How to Write Help

Тэги: организация работы, Том Джонсон, эффективность