Давайте вакансию!

В Positive Technologies открылся поиск технических писателей! Компания занимается разработкой в сфере кибербезопасности и внедряет подход Docs as code🚀

📌Первая вакансия — для специалистов в конкурсной документации (ГОСТ 2, 19, 34)
📌Вторая вакансия — для тех, кто пишет пользовательские инструкции по внутренним стандартам компании

Самое интересное:
▪️ Погружение в продукт: технические писатели близко к разработке
▪️ Решаем сложные технические задачи и исследуем новое
▪️ Прозрачные условия: IT аккредитация, бронь, 10 дополнительных дней отпуска, удаленка и многое другое

Хочешь присоединиться к команде? Пиши рекрутеру в тг: @ksnstv
#давайте_вакансию

Давайте уже итоги розыгрыша!

Что ж, давайте. Мы раздали номера всем участникам и раскрутили виртуальный барабан.

И та-дам! Поздравляем @MariyaTW

К вам в личку скоро придет специальный человек и расскажет, как получить ваш билет на WriteConf! :)

А всем остальным участникам розыгрыша организаторы конференции по нашей просьбе решили дать скидку 10% на онлайн или офлайн-билет. Напишите в комментариях, если вам нужно, и мы отправим вам промокод.

Техпис и аналитик: где граница

Отвечает ли технический писатель за всю документацию на проекте? Очевидно, нет. Но где тогда граница его ответственности? Пожалуй, больше всего вопросов возникает в точке пересечения обязанностей техписа и аналитика. Допустим, в команде есть системный и/или бизнес-аналитик и технический писатель — за какие артефакты отвечает каждый из них?

Мы считаем, что аналитики разрабатывают документы, которые нужны, чтобы продукт создавать и поэтому подключаются на самых ранних этапах разработки. И это, прежде всего, внутренние документы — для самой команды. Оформить «хотелки» заказчика в бизнес-требования, чтобы разработчики опирались на них, создавая приложение, описать все возможные пользовательские сценарии в User Stories, сформулировать системные требования и так далее. Эти артефакты нужны, чтобы продукт вообще появился на свет.

Задача же технического писателя — делать продукт более понятным тем, кто им пользуется. В этом смысле мы всегда имеем дело с уже созданным сервисом и подключаемся к работе на поздних этапах. И наши артефакты почти всегда внешние. Для конечных пользователей мы пишем инструкции и руководства, release notes и даже рассылки, чтобы рассказать обо всех возможностях сервиса. Для поддержки мы создаем описания сервиса, рассказываем о типичных проблемах и способах их решения. Другим командам разработки, которые хотят интегрироваться с нашим сервисом, рассказываем, как работает API.

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

Что думаете про такой критерий разделения? Давайте обсудим.

P.S. Речь про границы профессий, а не конкретные рабочие позиции. Если в вашей трудовой написано «технический писатель», но вы пишете не только инструкции, но и бизнес-требования, это лишь означает, что на этом конкретном рабочем месте вы еще и аналитик по совместительству.

#давайте_про_профессию

Вечное обслуживание. Ну, почти — до 17.08.
Порядок слов в текстах не важен, говорите? 😉

Давайте перепишем?

#давайте_фейл

Last call

Осталось совсем мало времени, чтобы успеть подать доклад на третью конференцию Techwriter Days!

В прошлых двух мы принимали участие и в третьей тоже обязательно будем.

Очень ждем новых встреч и, конечно, интересных докладов!

Расскажите о своем опыте использования ИИ, о подходе к редактуре, про автоматизацию или локализацию — нераскрытых тем бесконечно много. Среди них точно есть та, в которой вы эксперт.

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

#давайте_анонс

Вся наша редакция сегодня на WriteConf!
Если вы тоже, подходите поздороваться ;-)

В честь Дня знаний принесли вам азбуку техписа :)
Делитесь с коллегами :)

Пишем е или ë, кешбэк или кэшбэк? Ставим ли точки в таблицах? Аппрувим или подтверждаем?
Как избежать пустых споров и быстро принять решение в спорных случаях, рассказала Женя Береснева, один из авторов нашего канала, на конференции WriteConf. С удовольствием делимся с вами записью.
Давайте обсудим!

А у нас день рождения!

Сегодня исполняется год нашему каналу 🎉

Главные цифры на картинке, а вот еще немного статистики:
— Больше всего репостов собрал чек-лист оформления инструкции
— Вот этот мемчик собрал больше всего лайков
— А пост про зону ответственности техписа оказался самым обсуждаемым

Кстати, лучший подарок для любого канала — новые читатели. Репостните любой наш пост в ваш рабочий чатик или просто расскажите про нас коллегам, мы будем очень рады 😊

Поздравления в комментариях тоже принимаем 🥳

Карьерные вопросы. Почему не нужно грустить из-за отказа

Каждый из нас хотя бы раз искал работу. А учитывая новые тенденции, некоторые ищут работу в среднем раз в год. И, конечно же, хотя бы раз все мы получали отказ.

Отказ можно получить на любом из этапов: HR-скрининг, тестовое задание, техническое собеседование или собеседование с командой. Когда читаешь “к сожалению, мы не готовы предложить вам…”, особенно первое время, кажется, что “я плохой”, “я недостаточно хорош для компании”, даже если собеседование прошло хорошо и казалось, что офер в кармане.

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

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

Митап для техписов 15 октября

Уже на следующей неделе пройдет Techdoc Meetup X5 Tech #6.

Техническая документация сегодня — это не просто мануалы. Это язык продукта, опыт пользователя и даже инструмент маркетинга. 15 октября мы соберёмся на площадке X5 Tech, чтобы обсудить всё: от UX-текстов до генерации документации по коду.

📌 В программе:
— Как сохранить привычный ToV и заговорить с пользователем по-новому
— История гуманитария в IT: от 20 отказов до преподавателя
— Автоматическая генерация документации из исходного кода
— Документация как маркетинговый инструмент бизнеса
— Как диалог с пользователями меняет инструкции

🎤 Спикеры из Лаборатории Касперского, X5 Tech, Wildberries и Gramax поделятся кейсами и своим опытом.

📅 15 октября
🕒 17:30–21:30
📍 БЦ "Оазис", офлайн
Регистрация: https://x5-tech-event.timepad.ru/event/3607314/
Советуем поторопиться с регистрацией, число мест ограничено

#давайте_анонс

5 мифов о техписах

Технический писатель в IT — роль, понятная не всем. Отсюда самые разные стереотипы о нашей профессии. Вот те пять, с которыми мы сталкиваемся чаще всего. Добавляйте свои в комментариях!

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

Миф второй. Техписа надо звать ближе к релизу
Неделя до релиза, и команда вдруг поняла, что нужны инструкции и документация для поддержки. Знакомо? Там же работы на пару часов, что переживать. Конечно, вероятнее всего, технический писатель не успеет, работы больше, чем кажется. И продукт выйдет в свет без инструкций. На деле лучший момент — когда все требования утверждены и готов тестовый стенд, в крайнем случае есть окончательные макеты. Если нужна помощь с интерфейсными текстами, то еще раньше.

Миф третий. Основная работа техписа — писать
На самом деле, формулировка «разработчик технической документации» была бы точнее. Потому что непосредственное написание текста — это меньшая часть нашей работы и по затратам времени, и по важности. Мы анализируем сервис и аудиторию, самостоятельно проходим все пользовательские сценарии, добываем информацию всеми способами, создаем логичную и понятную структуру документации и только потом наполняем ее текстами. А их еще надо отредактировать, отдать на вычитку и согласовать с заказчиками.

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

Миф пятый. Техписы жуткие душнилы
Стоит техпису оказаться в команде, как начинаются «придирки» про неверное оформление и грамматические ошибки. Коллеги могут посчитать, что это наш скверный характер, но на деле все эти требования рождаются не на пустом месте — мы следуем принятой в компании редполитике либо ГОСТам, а также правилам русского языка. И лучше всех знаем, что небрежная документация и ошибки в интерфейсах портят репутацию отнюдь не техписа, а всей компании.

А с какими мифами сталкиваетесь вы?

#давайте_про_профессию

Задача — сделать стайлгайд. Неочевидные советы

✅ Стайлгайд должен быть написан по стайлгайду.
✅ Фиксируйте, где правило жесткое, а где только рекомендация и остается на усмотрение автора. Старайтесь, чтобы жестких правил не было слишком много. Например, строго запрещаем добавлять нумерацию в заголовках. А вот формулировать заголовки через глаголы рекомендуем, но не настаиваем.
✅ Стайлгайд это не только документ, но и процесс вокруг него. Если нет внутреннего ревью, вы делали гайд зря.
✅ Учитывайте Tone of Voice компании и сложившуюся стилистику текстов, если она есть.
✅ Если где-то идете против правил русского языка, обязательно включите это в гайд. Например, решили писать слово не как в словарях или не использовать кавычки в названиях.
✅ А вот стандартные правила языка в гайде повторять как раз не нужно. В некоторых случаях можно сослаться на словари и справочники.

#давайте_про_стайлгайд

Поддержка будет довольна — топ-5 советов для описания проблем и решений

Один из самых распространенных типов документа в инструкциях для поддержки — описание проблем и решений.
Мы собрали топ-5 советов, как описать проблемы и решения так, чтобы этот документ был полезен коллегам.

Совет #1
Публикуйте страницу с проблемами и решениями отдельно от пользовательской документации.
Это упростит поиск по всему документу и сделает его структуру более понятной, ведь со временем документ точно станет больше.

Совет #2
Описывайте только сами проблемы и их пошаговый путь решения.
Информацию о том, как работать с сервисами, получить доступ, к кому обратиться с вопросами, вынесите на отдельные страницы. Сотрудники поддержки уже могут иметь доступ к сервисам, знать, как с ними работать — лишняя информация будет отвлекать.

Совет #3
Каждая проблема — отдельный законченный кейс.
Если в разных проблемах повторяются одни и те же действия, дублируйте их. Ребята из поддержки решают только одну проблему и не должны ходить по всему документу, чтобы проанализировать ее и найти решение.

Совет #4
Отдельным шагом укажите перечень того, что нужно приложить к инциденту для передачи на следующую линию поддержки. Так вы сэкономите время и силы коллег из поддержки и поможете получить тикет, не требующий уточнений.

Совет #5
Проблемы и решения сортируйте от частых к редким и от общих к частным.
Если проблем больше 10, то однотипные проблемы формируйте в блоки, например, по разделам приложения, где возникает проблема.
Все это поможет быстрее найти проблему и решить ее.

Делитесь своими советами. Что вам важно в документации для поддержки?

#давайте_лайфхак