#вакансии
Всем привет!
Воскресный пост с интересной вакансией для уверенных джунов.

Наша коллега Ольга из Айрим (Сколково) сейчас в поисках напарника - технического писателя, который влюблен в возможности ИИ и медицину, не боится ГОСТ и владеет начальным английским. Удаленно можно. Тонкостям из предметной области обучат за счёт компании.

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

Подробнее о вакансии читайте в Олином посте в большом чате техписов, спрашивайте в комментариях или личных сообщениях.

#какэтоработает #пользовательскоеписалити
Всем привет!
Сегодня холиварная тема, а именно:

Пользователь должен или может?

Да, речь о модальных - о словах, которые обязывают, запрещают или предписывают.

1️⃣ Долженствование
Первое, что мы запоминаем: пользователь никому ничего не должен. Поэтому модальные с этим оттенком смысла употреблять не рекомендуется. Замените должен или обязан глаголом повелительного наклонения или изъявительного в форме 3 лица (по вашей редполитике):
Пользователь должен нажать Сохранить.
Пользователь нажимает Сохранить.
Нажмите Сохранить.

2️⃣ Запрет
Так же как и обязанности, мы не можем вменить пользователю и запрет на действия.
Редактировать карточку запрещено.
Не редактируйте карточку, это приведет к ошибкам (таким-то).
Если пользователь отредактирует карточку, система выдаст ошибку.

3️⃣ Невозможность
Мы не можем определять, что пользователь в состоянии выполнить, а что нет. Но мы можем обозначить, что чего-то не делает наш продукт.
Редактировать карточку нельзя.
Редактировать карточку могут только пользователи с правами администратора. Или Редактирование карточки не предусмотрено.

4️⃣ Желание
Говорить о желаниях пользователя - тоже не задача документации. Неважно, что хочет пользователь, важно, что может продукт.
Если хотите создать заявку...
Чтобы создать заявку...

5️⃣ Необходимость
Еще одна диктаторская замашка техписателя - определять необходимость действия. Нужно и необходимо пользователю дышать или пить чистую воду, а не выполнять инструкции. Поэтому:
Пользователю необходимо выбрать экземпляр.
Чтобы создать заявку, выберите экземпляр.
Пользователь выбирает экземпляр.

Подытожим.
Неважно, пользователь должен или может. Возможности пользователя - не ваша работа.
Описывая продукт, описывайте продукт.

#выпуск 6
Всем привет! Как и обещали, возвращаемся с рассказом о вакансии.
Но сначала - результаты опроса. Спасибо всем, кто участвовал!

Признаться, опрос прояснил только одно: оценить стоимость работы техписателя по каким-то фиксированным критериям без собеседования очень сложно. Сразу напрашивается вывод: важно ходить на собеседования, чтобы уметь соотносить свои навыки и зарплату.

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

❗️Человек, который поставил "30 000", напишите мне в личку @litulyagan, побеседуем о вашей карьере. Это бесплатно.

Не все, кто ставил "знаю облачные технологии" на самом деле знают их или знают в нужной степени, что тоже смазывает результат. Поэтому возвращаемся к главному выводу о собеседованиях.

Все ожидания передали команде. Вилка в рынке, но верхняя граница будет определена после собеседования.

И к вакансии. Техписателя ищет команда WB Cloud. Это в одной компании со мной (Лида). Задача - поднять документацию с нуля и настроить процессы документирования. Самый огонь для смелых и плюс в резюме.
Подробно вакансия описана на hh. Пусть вас не пугает обозначенный опыт, смотрят всех. Вопросы и резюме можно отправлять Насте.

#анонс
Всем привет!

Уже в этот четверг, 28 сентября, в 19:00 по московскому времени пройдёт митап для технических писателей, организованный коллегами из Ozon Tech и X5 Tech.

О чем пойдёт речь?

► Арина Кузнецова из Ozon расскажет об атрибуциях документации: какие документы помогают облегчить работу с текстами и сделать их понятнее.
► Владимир Гусаров из X5 Tech расскажет, зачем нужны стайлгайды и какие проблемы они решают.
► Круглый стол «Роль технического писателя в продуктовой команде»

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

Всем привет!

Организаторы конференции технических писателей TechWriter Days #1 сообщают, что открыли регистрацию и прием докладов.

Конференция пройдет 5-6 апреля 2024 г. в Москве в гостинице "Holiday Inn Сокольники".
Формат конференции: офлайн + онлайн.

До 31.10.2023 действует super early bird период оплаты.

Сайт мероприятия: https://techwriterdays.ru/
Телеграмм: @twdays

🔆А теперь информация для слушателей:

Как сходить на конференцию и получить максимум пользы

Пост Екатерины Ушаковой из Ozon Tech про то, как посещать конференции с пользой

#выпуск 7
Всем привет!
Сегодня у нас важная тема, которая волнует всех новичков:

Как получить опыт, когда всем нужны готовые специалисты?

1️⃣Учитесь и делайте учебные проекты

Кто-то скажет: это всё ерунда. Но на самом деле сидишь на собесе, и такой хороший по софт скиллам соискатель попался, и команде понравился, но технически не подкован. И ты думаешь: "Ну скажи, скажи, что ты хотя бы учился, хотя бы читал!" - и нет(
Учебные проекты - это как раз для таких случаев.

2️⃣Ищите "простые" работы и внедряйте технологии там

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

3️⃣Ищите стажировку

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


4️⃣Ищите "продвинутую" работу и не теряйте надежду на везение

Можно попасть в команду, которая готова подтянуть в вас технические знания или знания инструментов, если вы хорошо пишете и любите тексты. Это, например, такие случаи, о которых рассказывал Семен Факторович.
Взамен вы можете помочь команде с другими задачами, например, вести блог или канал с обновлениями.

И помните о самом главном: огонь в глазах может компенсировать отсутствие знаний.

#анонс
Всем привет!

Уже в эту пятницу, 20 октября, в 18:00 по московскому времени пройдёт митап для технических писателей «TeamSnack TechWriters», организованный коллегами из Cloud.ru.

О чем пойдёт речь?

► Юрий Никулин из Cloud.ru расскажет о документации как о рок-н-ролле, части продукта и части продуктового процесса.
► Анна Атаманова и Алексей Миронов из SberWorks поразмышляют о противостоянии когнитивного стресса и знаний и о том, как выжить в мире перегрузки мыслей
► Екатерина Ушакова из Ozon поделится мастерством в технической документации: структурой, качеством и метриками.
► Сергей Кулаков из Cloud.ru расскажет о CopycatCatcher — бесплатном умном инструменте для авторов и менеджеров баз знаний.

Митап можно посмотреть онлайн или приехать в московский офис Cloud.ru. Регистрируйтесь на митап в любом формате по ссылке.

#какэтоработает

Всем привет!
Давайте поговорим о довольно важном документе — Release Note.

Release Notes — это, грубо говоря, новости вашего продукта. Они, как и документация, бывают разными, но мы выделим два типа: пользовательские и технические.

🫅🏼 Пользовательские релиз ноты — это заметки к релизным версиям продукта.
Когда обновляете приложение на телефоне, то на странице в магазине вы наверняка видели блок «Что изменилось?» или «Что нового?» и небольшой список изменений. Это и есть «пользовательские релиз ноты».

Сюда обычно пишут изменения, которые коснулись пользователей напрямую: например, появился новый функционал, изменился дизайн, усилена безопасность. Язык таких релиз нотов должен быть простым и понятным любому человеку. Здесь не должно быть сложных технических терминов.
Но не забывайте про ЦА! Если ваш продукт рассчитан, например, на системных администраторов, будет странно, если в нотах все термины будут разжёваны так, словно читатель — первоклассник.

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

🧑🏼‍💻 Технические релиз ноты обычно нужны разработчикам внутри компании и в целом их можно назвать внутренними.

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

Кроме самих разработчиков, к релиз нотам часто имеют отношение технические писатели. Они могут:
1. Настроить процесс релиз нотов. Иногда случается, что в компании вообще релиз ноты не пишут, хотя стоило бы.
2. Следить, чтобы у новых версий продукта всегда был релиз нот.
3. Собирать технические релиз ноты и делать из них новости продукта для пользователей.
4. «Переводить» технические релиз ноты на «человеческий» язык, чтобы любой человек из компании понял, что изменилось.

Поделитесь в комментариях, какое вы имеете отношение к релиз нотам.
А если интересно, как мы настроили процесс релиз нотов к продукту, у которого много компонентов, накидайте 🤨

#какэтоработает
Всем привет!

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

Что же мешает тексту быть простым и динамичным?

📌 Длинные предложения
Предложения, которые занимают две-три строчки текста, очень нагромождают текст. Более того, без условных пауз читатель может уже забыть о том, что было в начале. Начнёт перечитывать, подумает о своём и опять ничего не поймёт. По заветам Ильяхова: сокращайте! Дробите сложные предложения. Дробите абзацы. Чем проще синтаксические конструкции в предложениях, тем проще читать и понимать тексты. В конце концов, мы с вами не Львы Толстые.

📌 Отглагольные существительные
Текст читается легче, если он динамичный. Динамичным текст делают глаголы. Старайтесь не использовать отглагольные существительные — они «замедляют» текст и делают его сложнее для восприятия. Если есть отглагольное существительное, то, скорее всего, его можно превратить в обычный глагол. Сравните:
► «Для открытия формы записи нажмите кнопку “Анкета”».
► «Чтобы открыть форму записи, нажмите кнопку “Анкета”».
А если ещё добавить первый пункт:
► «Чтобы записаться, нажмите кнопку “Анкета”».

📌 Много существительных подряд
Пункт пересекается с предыдущим, но иногда бывает так, что в тексте долгое время не встречаются даже отглагольные существительные. Наверняка вы встречали предложения, в которых несколько существительных идут подряд. Такие тексты выглядят сухо и плохо читаемы. Сравните:
► «Для поддержания здорового внешнего вида хранение фруктов и овощей допустимо в специально отведенных местах».
► «Храните овощи и фрукты в специально отведённых местах, чтобы они дольше оставались свежими».
Текст сразу становится более динамичным и дружелюбным.

📌 Модальные глаголы
Вы решили разбавить текст глаголами, но разбавили модальными. Это тоже не очень хорошая практика. Это не относится к динамичности, но, скорее всего, ваш текст не пострадает, если глаголы вроде «может», «должен», «нужно» и прочее удалить. Да, это разбавляет текст, но не делает его динамичным. Скорее делает его неуверенным. Сравните:
► «Чтобы вызвать лифт, нужно нажать кнопку вызова»
► «Чтобы вызвать лифт, нажмите кнопку вызова»
Иначе можно задаться вопросом: кому нужно? Мне, лифтёру или консьержке?
Повелительные формы глаголов — ваш друг, они сделают текст более уверенным. Если, конечно, в вашей редполитике не написано иначе.

Расскажите, какими ещё внутренними установками или правилами вы пользуетесь, чтобы сделать текст более динамичным?

#выпуск 8
Всем привет! 

Когда пытаешься войти в профессию, иногда от рекрутеров и потенциальных руководителей можно услышать фразу «Это хороший трамплин в IT». Из-за этого может сложиться ошибочное впечатление, что техническому писателю некуда развиваться. Но это не так. 

Техническое писательство — профессия, которая может нести в себе смежные должности. Например, отсюда можно вырасти в аналитики или UX-редакторы. Но будет ли это тот рост, который вам нужен? Если ваша цель — «войти в айти», то возможно.

Давайте посмотрим, куда можно расти, если хочешь и дальше писать документацию.


📌 Вертикальный рост

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

Но учтите, что с менеджерством приходит больше управления и меньше писательства. Если хотите писать, то рост до руководителя отдела – не всегда лучшее решение.


📌 Горизонтальный рост

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

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

► Изучайте новые технологии
Чем сложнее технология, тем выше шансы получать больше денег за работу! Например, знания кубернетиса или облаков не такие популярные у технических писателей, а значит и конкуренция меньше.

► Пишите на других языках
Если хорошо знаете иностранные языки, то можно попробовать развиваться как иноязычный специалист. Причём для этого необязательно работать в зарубежных компаниях. На рынке достаточно компаний, которым нужна англоязычная документация. 


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

#выпуск 9
Всем привет!
Сегодня поищем ответ на вопрос, который задают после собеседования и начинающие, и опытные техписатели: "Почему меня не взяли?"
Наша тема прозвучит так:

Топ-5 ошибок на собеседовании

Сложно определить, какая из ошибок будет на первом месте, а какая - на пятом, поэтому просто перечислим их.

1️⃣Не включить камеру
Если собеседование проходит по видеосвязи, команда ожидает, что кандидат включит камеру. Аргументы вроде "у меня не работает камера" или "плохая связь", как правило, выглядят некрасиво и даже нелепо.
При плохой связи попытайтесь включить камеру, показать себя, либо заранее предупредите рекрутера. Лучше, конечно, связь настроить или собеседоваться в тихом кафе.
Если проблема глубже, и вы стесняетесь включать камеру, рекомендуем не стесняться (от создателей "не грусти")). Если серьёзно, то навык работы с камерой вам ещё пригодится, к тому же это здорово повышает самооценку.
Можно не включать камеру, если люди, которые вас собеседуют, тоже не включили. Осуждаем их).

2️⃣Говорить невнятно
Правило хорошего техписателя: уметь рассказывать о своей работе. Если ваша речь несмелая и несвязная, создаётся ощущение, что вы ничего не знаете и не умеете.
Тренируйте свою речь, репетируйте вопросы и ответы заранее.

3️⃣Задавать вопросы невпопад
Заготовить вопросы заранее - это очень хорошо. Важно в процессе разговора вычёркивать лишние. Если команда говорит, что никаких регламентов у них нет, странно спрашивать, если ли у них какие-то регламенты. Держите список вопросов перед собой и корректируйте их по ходу беседы. Вопросы, оторванные от беседы, никого не красят.

4️⃣Не показывать самостоятельность и проактивность
Часто от технического писателя ожидают самостоятельности. Команда не хочет "няньчить" своего новичка, даже если он не первый техпис. Покажите, что вы способны планировать свой день, оценивать задачи, расставлять приоритеты, и ни в коем случае не валите всё на менеджеров.
С демонстрацией проактивности не перестарайтесь) Например, не продвигайте инструменты с позиции "я это умею, поэтому нужно сделать это". Поинтересуйтесь процессами в команде и предложите адаптированный вариант, покажите желание помочь, а не самореализоваться.

5️⃣Не готовиться к собеседованию
Не забудьте перед собеседованием прочитать требования к вакансии. Освежите в памяти какие-то моменты из предметной области. Если вы джун, изучите документацию схожего продукта, приготовьтесь рассказать о плюсах и минусах такой документации. Изучите продукт, если доступ к нему открыт. Если доступа нет, попытайтесь изучить похожие.

Удачи на собеседованиях!

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

Всем привет!

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

Суть: у нас есть персонаж, и мы описываем некоторую ситуацию из жизни. Затем проводим опрос, что персонаж должен сделать и, отталкиваясь от ответов, развиваем сюжет.

Часть 1. Пенелопа меняет профессию

Пенелопа несколько лет работает аккаунт-менеджером в небольшой компании. Она чувствует, что близка к выгоранию, но сделать с этим ничего не может. Где бы она ни работала аккаунтом, меньше стресса, звонков и времени, когда нужно быть на связи, не будет. Также ей надоело, что у неё нет нормального work-life balance: желательно быть на связи вечером, в выходные и даже в отпуске.
Пенелопе это всё надоело, и она решила сменить работу на менее стрессовую и менее зависимую от клиентов. Чтобы видеть результат своей работы, а также приносить пользу другим людям. А вишенкой на торте — получать больше денег.
Посмотрев на рынок труда, она увидела привлекательную профессию — технический писатель. Изучив, кто это такой, ей показалось, что это человек, который сидит в тишине, пишет инструкции для пользователей и никто его не трогает. Она тоже писала инструкции для своих клиентов и обучала их работе с системой. Девушка подумала, что это оно.
Пенелопа почитала рекомендации, обновила и выложила своё резюме. В нём она указала, что умеет работать с большим количеством информации, писала инструкции для клиентов, умеет в коммуникации и может сопровождать небольшие проекты.
Девушка начала откликаться и временами проходить собеседования.

#Пенелопа_ищет_икигай #невыдуманныеистории