Данная статья не предполагает каких-то заумных и крайне неочевидных советов по написанию и проверке технической документации. Многие из перечисленных «советов» многим покажутся очевидными, но из раза в раз, анализируя документацию наших пользователей, мы сталкиваемся с одними и теми же банальными ошибками, которые чаще всего происходят из-за фактора «забыл». Так что данный пост можно расценить как памятку не техническому писателю.
Приятного чтения.
Люди читают пользовательскую документацию, когда самостоятельно не могут с чем-то разобраться. Они не делают это для развлечения. И эмоции, которые преобладают в этот момент, далеко не всегда позитивные. Как разработчик пользовательской документации может помочь пользователю? Что ему необходимо учитывать при написании документа?
“Что за дело? Это многих славных путь.”
Н.А. Некрасов
Всем привет!
Меня зовут Карина, и я “совместитель” — совмещаю учёбу в магистратуре и работу технического писателя в Veeam Software. О том, как у меня это вышло, я и хочу рассказать. Заодно кто-то узнает, как можно прийти в эту профессию, и какие я вижу для себя плюсы и минусы в работе во время учебы.
Я работаю в Veeam без году неделю полгода с небольшим, и это были самые насыщенные полгода моей жизни. Я пишу техническую документацию (и учусь её писать) — сейчас я занимаюсь руководством по Veeam ONE Reporter (вот оно) и гайдами по Veeam Availability Console (про нее была статья на Хабре) для конечных пользователей и реселлеров. Еще я из тех, кому сложно парой слов ответить на вопрос «Откуда ты приехала?». Вопрос «Как ты проводишь свободное время?» тоже не из простых.
Взгляд работающего студента, когда ему жалуются на недостаток свободного времени
Читать полностью »
Документация к софту — это просто набор статей. Но даже они могут вывести из себя. Сначала долго ищешь нужную инструкцию. Потом разбираешься в малопонятном тексте. Делаешь как написано, а проблема не решается. Ищешь другую статью, нервничаешь… Через час плюёшь на всё и уходишь. Так работает плохая документация. Что делает её такой, и как это исправить — читайте под катом.
Читать полностью »
В одной из предыдущих статей мы в общих чертах рассказывали, как именно происходит процесс документирования и локализации наших продуктов.
На этот раз под катом – руководство нашего технического писателя Андрея Старовойтова, которое поможет сделать вашу документацию для пользователей проще и понятнее (описанные приемы применяют при документировании своих продуктов Apple, Microsoft и другие компании).
Читать полностью »
Как бы ни старался UX-дизайнер, не сможет человек с улицы разобраться в интерфейсе управления космическим кораблём без подсказки. И даже не с улицы. Просто потому, что ракета большая и настроек много.
Мы делаем продукты попроще софта для ракет, но всё равно технически сложные. Очень стараемся, чтобы интерфейсы новых версий были простыми, но осознаём — всегда найдётся пользователь, который что-нибудь не поймёт и пойдёт в документацию. Поэтому дока должна быть, а чтобы не портить впечатление о продукте, она должна быть полезной и удобной.
У нас шесть продуктов, документацию к которым 13 лет писали разработчики. Уже полгода мы переписываем старые и пишем новые статьи. Под катом — 50 вопросов, которые помогают нам делать это хорошо. Но для начала немного вводных.
Есть два типа компаний: первые ориентированы на пользователей, вторые — на свой продукт. По мере того как бизнес растет, часто главным для него становится продукт, который необходимо развивать и поддерживать, а забота о клиенте отходит на второй план.
При всех своих масштабах и линейке более чем из 60 настраиваемых решений «Лаборатория Касперского» действует прежде всего в интересах пользователя. Важная часть нашей работы — тексты: мы общаемся с пользователями наших продуктов с помощью элементов интерфейса и документации.
Год назад в «Лаборатории Касперского» прошла первая встреча «ProКонтент» для технических писателей, редакторов, переводчиков и локализаторов. 16 марта 2017 года мы вновь приглашаем к себе всех желающих, чтобы раскрыть свои секреты и поговорить о том, что нас объединяет. О контенте.
Читать полностью »
Работая в компании, которая занимается системной интеграцией, мне приходилось много раз читать и дополнять документы типа ТКП, ТЗ по ГОСТу, Планы приемки и прочее. Проекты по автоматизации предприятий преследовали похожие цели и имели приблизительно одинаковый формат. Одни и те же фразы повторялись из документа в документ.
Я решила собрать самые распространенные фразы, попадавшие в раздел «цели и задачи». И добавить принципы, которых следует придерживаться при формировании решений.
Список не универсальный. Буду рада, если кому-то это поможет при написании документов.
С другой стороны, некоторые принципы, собранные в этом списке — это мое понимание того, к чему должны стремиться как и большие корпорации, так и отдельные команды по разработке продуктов. Ступеньки на пути к информатизации общества.
Я призываю придерживаться многих из этих принципов в своей работе, чтобы держаться некой планки, ниже которой — просто уже не современно быть.
В прошлый раз мы говорили о разнице между login и log in. В продолжение темы — ещё несколько нюансов, о которых вы просили рассказать в комментариях.
‘Login’ или ‘log in’? Одно слово или два? Это достаточно распространенный вопрос среди тех, кто пишет на английском языке. Давайте разберемся, как же правильно.
