Две истории о том, как писать справку (часть 1)
13.08.2014
Мы уже рассказывали об инструментах для создания файлов справки и об основных пунктах, которые нужно учесть. Сегодня мы расскажем о разных подходах к её написанию.
То, как большинство техписов подходят к написанию справки, в корне неправильно. Прочитайте эти две истории о разных подходах и мышлении разных писателей.
История № 1
Проектная команда компании «Рога и копыта» создаёт комплексное приложение для большого числа пользователей и решает привлечь техписа для написания справочных материалов по использованию приложения. Техпис месяцами работает бок о бок с разработчиками при создании приложения. За это время он тщательно собирает информацию и пишет топики справки, основываясь на задачах.
И вот он, день релиза приложения. Технический писатель передаёт файл справки разработчикам, и они включают его в приложение и выпускают полный релиз. Работа окончена, технический писатель приступает к другому проекту.
Ким, один из пользователей нового софта, начинает его осваивать, у неё появляются вопросы. Она заходит в справку, но находит там только часть ответов.
Покликав и попробовав разные сочетания ключевых слов, она звонит в службу поддержки. Группа техподдержки, как правило, помочь ничем не может и перенаправляет вопрос обратно проектной команде. Бизнес-аналитик команды перезванивает пользователю и понимает, что у него особая ситуация, которую они не предусмотрели. Бизнес-аналитик объясняет временное решение.
Дни идут, Ким оказывается лишь одной из многих пользователей, кто следует одному и тому же сценарию. Из-за уникальных рабочих процессов, которые разработчики не предусмотрели, другие пользователи тоже не находят ответов в справке. У некоторых та же проблема, что и у Ким. Они обращаются за ответами к техподдержке и к Ким, так как самостоятельно ничего найти не могут.
Чем больше проходит времени, тем больше инцидентов, решений, обходных путей, странностей и багов насчитывает техподдержка и бизнес-аналитик. Через 3 месяца разработчики решают выпустить обновление для приложения. За неделю до релиза они перезванивают техническому писателю (который и не задумывался о «Рогах и копытах» с момента окончания проекта), чтобы сделать несколько обновлений в справке. Технический писатель спрашивает разработчиков, что изменилось, и делает соответствующие обновления в справке. Затем справку снова встраивают в приложение, и версия 2.0 выпущена.
Тем не менее, на этот раз, когда у пользователей появляются вопросы, они помнят свой ??предыдущий опыт со справкой и решают вообще туда не заглядывать. Они знают, что их ответов там не будет, и сразу звонят в техподдержку.
Однажды, глядя на статистику просмотров, руководитель проекта говорит техническому писателю: «Никто не обращается к справке».
«Хммммм», – говорит технический писатель.
«Может быть, приложение настолько интуитивно, что справка не нужна?» – говорит технический писатель. Но технический писатель лучше знает.
Чувствуя, что никто не читает справку, которую он создает, технический писатель придаёт меньшее значение работе. Он становится неаккуратным и небрежным. В конце концов, технический писатель видит свою роль в успехе проекта как весьма незначительную.
Когда выпускается версия 3.0, руководитель проекта забывает сказать техническому писателю об изменениях, которые необходимо внести в справку. Справка сейчас сильно устарела и неточна. Когда новые пользователи туда заглядывают и обнаруживают это, они закрывают окно справки навсегда, никогда больше не возвращаясь к нему.
(продолжение следует)
Источник: Two Stories About How to Write Help
Тэги: организация работы, Том Джонсон, эффективность
