#писалитирекомендует
Всем привет!
Как найти работу, если нет опыта?
Да, намекаем на стажировки)
Мы уже рассказывали о стажировках в Озоне и Лаборатории Касперского. А теперь знакомим новичков с PTЛабс — это те самые Госуслуги)
Почитать о всей программе стажировок можно вот здесь. В этом году РТЛабс открыл набор и стажёров-техписателей.
С вопросами и резюме можно приходить к лиду техписателей в РТЛабс Марии Киселёвой @fintiplushka.
Всем привет!
Как найти работу, если нет опыта?
Да, намекаем на стажировки)
Мы уже рассказывали о стажировках в Озоне и Лаборатории Касперского. А теперь знакомим новичков с PTЛабс — это те самые Госуслуги)
Почитать о всей программе стажировок можно вот здесь. В этом году РТЛабс открыл набор и стажёров-техписателей.
С вопросами и резюме можно приходить к лиду техписателей в РТЛабс Марии Киселёвой @fintiplushka.
about.rtlabs.ru
Стажировка 2025
Вакансии для студентов
🔥10❤6🌚2
This media is not supported in your browser
VIEW IN TELEGRAM
😁61🔥14😢4🐳4💯3🤣3
#какэтоработает
Всем привет! Сегодня у нас маленькая, но очень важная тема:
Три правила хороших Release Notes
Release Notes — это описание изменений в продукте, которые появились после выпуска новой версии. Его называют релизнотами, а по-русски — описание релиза или список изменений (и ещё пара десятков названий на любой вкус).
Собирать релизноты — это целое искусство, но поделимся только 3 правилами, которых мы рекомендуем придерживаться.
1️⃣ Структурируйте информацию. Вы можете разделить текст на три условных части:
- Что нового
- Что доработано
- Что исправлено/удалено.
2️⃣ Пишите в мире пользователя: поясняйте, что для него изменится в продукте. Не рассказывайте, что сделала команда — говорите, что теперь сможет сделать пользователь. Например, вместо "доработали механизм группировки задач" поясните, что пользователь теперь может группировать задачи по важному для него признаку.
3️⃣ Не перегружайте release notes информацией. Оставьте только самое важное. Пользователю не обязательно знать, на сколько градусов изменилось закругление рамки вокруг блока.
И, конечно, публиковать Release Notes нужно вовремя, вместе с обновлением продукта. Но это уже совсем другая история)
Эти правила — взгляд админов Техписалити! и касаются только пользовательской документации. Не соглашайтесь и делитесь своим опытом в комментариях)
Всем привет! Сегодня у нас маленькая, но очень важная тема:
Три правила хороших Release Notes
Release Notes — это описание изменений в продукте, которые появились после выпуска новой версии. Его называют релизнотами, а по-русски — описание релиза или список изменений (и ещё пара десятков названий на любой вкус).
Собирать релизноты — это целое искусство, но поделимся только 3 правилами, которых мы рекомендуем придерживаться.
1️⃣ Структурируйте информацию. Вы можете разделить текст на три условных части:
- Что нового
- Что доработано
- Что исправлено/удалено.
2️⃣ Пишите в мире пользователя: поясняйте, что для него изменится в продукте. Не рассказывайте, что сделала команда — говорите, что теперь сможет сделать пользователь. Например, вместо "доработали механизм группировки задач" поясните, что пользователь теперь может группировать задачи по важному для него признаку.
3️⃣ Не перегружайте release notes информацией. Оставьте только самое важное. Пользователю не обязательно знать, на сколько градусов изменилось закругление рамки вокруг блока.
И, конечно, публиковать Release Notes нужно вовремя, вместе с обновлением продукта. Но это уже совсем другая история)
Эти правила — взгляд админов Техписалити! и касаются только пользовательской документации. Не соглашайтесь и делитесь своим опытом в комментариях)
👍42❤22🔥4
#мемница
В нашей профессии важно обучаться без пауз и быть внимательным на всех встречах с носителями знаний)
Поскольку сегодня День учителя, предлагаем в комментариях поделиться, у кого и какие знания вы перенимали)
В нашей профессии важно обучаться без пауз и быть внимательным на всех встречах с носителями знаний)
Поскольку сегодня День учителя, предлагаем в комментариях поделиться, у кого и какие знания вы перенимали)
😁78❤15👍3💯3🤗1
#личныйОпыт
Статьи, которые мыне прочитаем
Всем привет!
Сейчас всё больше и больше опытных техписателей запускают собственные каналы. Один пост интереснее другого, одна статья полезнее другой. Пост — в Избранное, статью — в закладки. И так формируется целый "бэклог" публикаций, которые мы... скорее всего не прочитаем.
По крайней мере, с нами всё происходило именно так. И даже список статей мы назвали ровно так, как и этот пост.
✋ — Хватит это терпеть!
Давайте вместе найдём способ читать чуть больше и с пользой!
Мы предлагаем создать из непрочитанных статей базу знаний. Это должна быть очень личная база, настроенная только под вас.
Создайте таблицу, где каждый столбец будет соответствовать направлениям ваших рабочих задач. Сохраняйте ссылки на понравившиеся статьи не просто в закладки, а в ячейки в нужном столбце. Цветом можно выделить важность: зеленый цвет обозначает, что это точно вам подойдёт, а синий — статьи "навырост", то есть то, что ещё предстоит внедрить.
Например, вы описываете API в Confluence. Статьи о способах авторизации будут в зелёном спектре. А посты об описании API в парадигме docs as code — в синем.
Каждый раз, приступая к рабочей задаче, прочитывайте одну задачу из зелёного спектра. А если есть время, то и одну из синего. Новая информация позволит вам иначе посмотреть на рутинное занятие и, возможно, улучшить ваше решение.
А вы как решаете проблему бэклога статей? Поделитесь вашим подходом. А мы пока подольём масла в огонь и напомним об открытой базе знаний для техписателей, в том числе с книгами по профессии.
Статьи, которые мы
Всем привет!
Сейчас всё больше и больше опытных техписателей запускают собственные каналы. Один пост интереснее другого, одна статья полезнее другой. Пост — в Избранное, статью — в закладки. И так формируется целый "бэклог" публикаций, которые мы... скорее всего не прочитаем.
По крайней мере, с нами всё происходило именно так. И даже список статей мы назвали ровно так, как и этот пост.
Давайте вместе найдём способ читать чуть больше и с пользой!
Мы предлагаем создать из непрочитанных статей базу знаний. Это должна быть очень личная база, настроенная только под вас.
Создайте таблицу, где каждый столбец будет соответствовать направлениям ваших рабочих задач. Сохраняйте ссылки на понравившиеся статьи не просто в закладки, а в ячейки в нужном столбце. Цветом можно выделить важность: зеленый цвет обозначает, что это точно вам подойдёт, а синий — статьи "навырост", то есть то, что ещё предстоит внедрить.
Например, вы описываете API в Confluence. Статьи о способах авторизации будут в зелёном спектре. А посты об описании API в парадигме docs as code — в синем.
Каждый раз, приступая к рабочей задаче, прочитывайте одну задачу из зелёного спектра. А если есть время, то и одну из синего. Новая информация позволит вам иначе посмотреть на рутинное занятие и, возможно, улучшить ваше решение.
А вы как решаете проблему бэклога статей? Поделитесь вашим подходом. А мы пока подольём масла в огонь и напомним об открытой базе знаний для техписателей, в том числе с книгами по профессии.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥40❤13❤🔥5
#предложка
Всем привет! У нас новая рубрика, в которой мы отвечаем на ваши вопросы в чат канала. И у нас уже есть первый вопрос 😎
Кто решает, какие задачи попадают в Release Notes?
Документация — это часть продукта, поэтому за неё тоже отвечает менеджер продукта. Именно он чаще всего определяет, что должно попасть в релиз. Даже в тех случаях, когда в список изменений входят абсолютно все задачи, менеджер продукта определяет, что нужно указать первым.
Но бывают случаи, когда техписатели обладают большей экспертизой в общении с целевой аудиторией и могут самостоятельно определять приоритетность задач и то, что нужно рассказать, а что не следует.
В вопросе как подать чаще всего руководствуются редполитикой и tone of voice (голосом продукта). А это уже артефакты технических писателей. Если никаких стандартов нет, стиль предлагает технический писатель.
В больших продуктах, которые состоят из множества связанных между собой сервисов со своими менеджерами, за состав релизнота могут отвечать другие специалисты.
Рассказывает лид UX-редакторов приложения Wildberries Валерия Железова:
— Мы накидываем идеи вместе с релизными менеджерами. Очень часто релизы состоят из улучшений, про которые на всех не расскажешь: это либо очень технические вещи, либо то, что раскатывается не на всю аудиторию. Поэтому многие, даже почти все используют отписки в духе «улучшили производительность, ускорили приложение, пофиксили баги». Ну а мы стараемся это разнообразить, чтобы те, кто такие штуки читает, хотя бы улыбнулись.
Для примера один из Release Notes приложения Wildberries для Google Play Market:
А как организован процесс создания Release Notes у вас?
Всем привет! У нас новая рубрика, в которой мы отвечаем на ваши вопросы в чат канала. И у нас уже есть первый вопрос 😎
Кто решает, какие задачи попадают в Release Notes?
— Кто должен решать, какие задачи попадают в релизноты? Продакты или техписатели? На мой взгляд, продакт решает что включить, техписатель решает как подать. Интересно узнать, как оно у других.
Документация — это часть продукта, поэтому за неё тоже отвечает менеджер продукта. Именно он чаще всего определяет, что должно попасть в релиз. Даже в тех случаях, когда в список изменений входят абсолютно все задачи, менеджер продукта определяет, что нужно указать первым.
Но бывают случаи, когда техписатели обладают большей экспертизой в общении с целевой аудиторией и могут самостоятельно определять приоритетность задач и то, что нужно рассказать, а что не следует.
В вопросе как подать чаще всего руководствуются редполитикой и tone of voice (голосом продукта). А это уже артефакты технических писателей. Если никаких стандартов нет, стиль предлагает технический писатель.
В больших продуктах, которые состоят из множества связанных между собой сервисов со своими менеджерами, за состав релизнота могут отвечать другие специалисты.
Рассказывает лид UX-редакторов приложения Wildberries Валерия Железова:
— Мы накидываем идеи вместе с релизными менеджерами. Очень часто релизы состоят из улучшений, про которые на всех не расскажешь: это либо очень технические вещи, либо то, что раскатывается не на всю аудиторию. Поэтому многие, даже почти все используют отписки в духе «улучшили производительность, ускорили приложение, пофиксили баги». Ну а мы стараемся это разнообразить, чтобы те, кто такие штуки читает, хотя бы улыбнулись.
Для примера один из Release Notes приложения Wildberries для Google Play Market:
Что общего между Wildberries и аптекой? Во-первых, после них становится как-то полегче. Во-вторых, и там, и там продают лекарства. В каталоге появился раздел «Еаптека»: там можно заказать всё для здоровья с доставкой в ближайшую аптеку, курьером или в отделение Почты России.
Мы вот уже закупились гематогенками, а заодно исправили ошибки, улучшили производительность и вообще сделали всё, чтобы приложение не болело.
А как организован процесс создания Release Notes у вас?
1👍14❤12✍3👏3🔥2🙈1
Привет!
Недавно мы говорили о том, как собирать релиз ноты и кто решает, на какие задачи их стоит писать. А сегодня поговорим про внутренние релиз ноты и о том, для кого их пишут.
Да, кажется, что ответ лежит на поверхности — релизы обычно пишут для пользователей, менеджеров, смежных команд, но… задумывались ли вы, что в ЦА релиз нотов могут входить и технические писатели?😑
Три причины, почему техпису стоит следить за релиз нотами:
📌 Синхронизация с продуктом
Релиз ноты помогают проверить, что документация по новым фичам написана, а по старым — обновлена. Если релиз есть, а доки или задачи на такую доку нет — повод насторожиться и задуматься над процессами.
📌 Помощь в написании статей
Релиз ноты — это готовые абзацы для документации. А если в работе документация по большой фиче, информацию о ней также можно черпать из внутренних мелких релиз нотов.
📌 Более глубокое понимание продукта
Чем больше техпис знает об устройстве продукта, тем более полные и точные документы он может публиковать. Также, он может обнаружить несостыковки и задавать точечные вопросы, которые могут помочь не только в написании понятной доки, но и обнаружить баги.
Поэтому не стоит забывать, что релиз ноты есть не только «внешние», но и внутренние, которые как раз помогают прокачать свои знания о продукте.
А вы следите за релиз нотами, которые не пишете самостоятельно?
Недавно мы говорили о том, как собирать релиз ноты и кто решает, на какие задачи их стоит писать. А сегодня поговорим про внутренние релиз ноты и о том, для кого их пишут.
Да, кажется, что ответ лежит на поверхности — релизы обычно пишут для пользователей, менеджеров, смежных команд, но… задумывались ли вы, что в ЦА релиз нотов могут входить и технические писатели?
Три причины, почему техпису стоит следить за релиз нотами:
Релиз ноты помогают проверить, что документация по новым фичам написана, а по старым — обновлена. Если релиз есть, а доки или задачи на такую доку нет — повод насторожиться и задуматься над процессами.
Релиз ноты — это готовые абзацы для документации. А если в работе документация по большой фиче, информацию о ней также можно черпать из внутренних мелких релиз нотов.
Чем больше техпис знает об устройстве продукта, тем более полные и точные документы он может публиковать. Также, он может обнаружить несостыковки и задавать точечные вопросы, которые могут помочь не только в написании понятной доки, но и обнаружить баги.
Поэтому не стоит забывать, что релиз ноты есть не только «внешние», но и внутренние, которые как раз помогают прокачать свои знания о продукте.
А вы следите за релиз нотами, которые не пишете самостоятельно?
Please open Telegram to view this post
VIEW IN TELEGRAM
✍15👍9🔥3
#анонс
Всем привет! Друзья, мы впервые анонсируем новый митап - Tech Writing Winter Jam, который пройдёт 3 декабря в башне ОКО в Москва-сити.
На наши вопросы ответил организатор митапа, devrel компании ИнфоТеКС Стас Доброхотов.
- Стас, ты продвигаешь бренд в области аналитики, почему появилась идея организовать митап для техписателей?
- Это в первую очередь личный челлендж. Наши технические писатели помогают не только ребятам из разработки, в том числе аналитикам, но и вычитывают статьи для HR-бренда. Я много общался с ними в процессе работы и понял, что им не меньше других направлений хочется встречаться, общаться, делиться рабочими практиками, но чаще всего у компаний нет на это фокуса. Захотелось это изменить. Отсюда цель: создать площадку для общения, разгрузки и обмена опытом. Наём мы сейчас не ведём, так что никаких скрытых замыслов)
- Этот митап - начало чего-то нового?
- Сейчас трудно сказать, но я бы хотел проводить его дважды в год.
- Главный вопрос, который обычно задают организаторам митапов, - запись будет?
- Есть пока технические моменты на площадке, которые мы думаем, как победить 🙂 Не обещаю, но будем стараться решить этот вопрос.
_______________
А теперь о самом митапе:
Yandex.Cloud, Avito.Tech и ИнфоТеКС собирают технических писателей на новогодний митап на 47 этаже башни ОКО (Москва-сити).
Вход бесплатный, но нужно обязательно зарегистрироваться заранее.
Организаторы просят: берите друзей, хорошее настроение и приходите заряжаться — будет полезно, весело и точно не банально!
В программе:
- Как избегать типичных ошибок и делать тексты понятнее.
- Автолинтер на YandexGPT: экономим время на правках.
- Работа с продуктовыми командами: как договориться и не перегореть.
Вас ждут в башне ОКО 3 декабря в 19-00.
Ссылка на регистрацию
Всем привет! Друзья, мы впервые анонсируем новый митап - Tech Writing Winter Jam, который пройдёт 3 декабря в башне ОКО в Москва-сити.
На наши вопросы ответил организатор митапа, devrel компании ИнфоТеКС Стас Доброхотов.
- Стас, ты продвигаешь бренд в области аналитики, почему появилась идея организовать митап для техписателей?
- Это в первую очередь личный челлендж. Наши технические писатели помогают не только ребятам из разработки, в том числе аналитикам, но и вычитывают статьи для HR-бренда. Я много общался с ними в процессе работы и понял, что им не меньше других направлений хочется встречаться, общаться, делиться рабочими практиками, но чаще всего у компаний нет на это фокуса. Захотелось это изменить. Отсюда цель: создать площадку для общения, разгрузки и обмена опытом. Наём мы сейчас не ведём, так что никаких скрытых замыслов)
- Этот митап - начало чего-то нового?
- Сейчас трудно сказать, но я бы хотел проводить его дважды в год.
- Главный вопрос, который обычно задают организаторам митапов, - запись будет?
- Есть пока технические моменты на площадке, которые мы думаем, как победить 🙂 Не обещаю, но будем стараться решить этот вопрос.
_______________
А теперь о самом митапе:
Yandex.Cloud, Avito.Tech и ИнфоТеКС собирают технических писателей на новогодний митап на 47 этаже башни ОКО (Москва-сити).
Вход бесплатный, но нужно обязательно зарегистрироваться заранее.
Организаторы просят: берите друзей, хорошее настроение и приходите заряжаться — будет полезно, весело и точно не банально!
В программе:
- Как избегать типичных ошибок и делать тексты понятнее.
- Автолинтер на YandexGPT: экономим время на правках.
- Работа с продуктовыми командами: как договориться и не перегореть.
Вас ждут в башне ОКО 3 декабря в 19-00.
Ссылка на регистрацию
Tech Writing Winter Jam
Митап для технических писателей от ИнфоТеКС, AvitoTech и Yandex Cloud
🔥19👍8❤5✍2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
😁73🔥10💯4❤🔥2❤1
#twd3
Всем привет! Мы с новостями об одной из крупнейших конференций для техписателей — TechWriterDays#3, которая пройдёт 27-28 марта следующего года в Москве.
На днях программу конференции обновили, она почти готова. Ещё будет дополняться секция С второго дня.
Напомним, что канал Техписалити! снова стал информационным партнёром конференции. На этот раз накануне мы разыграем среди наших подписчиков один офлайн-билет.🤗
Всем привет! Мы с новостями об одной из крупнейших конференций для техписателей — TechWriterDays#3, которая пройдёт 27-28 марта следующего года в Москве.
На днях программу конференции обновили, она почти готова. Ещё будет дополняться секция С второго дня.
Напомним, что канал Техписалити! снова стал информационным партнёром конференции. На этот раз накануне мы разыграем среди наших подписчиков один офлайн-билет.🤗
techwriterdays.ru
TechWriter Days - 3
TechWriter Days - 3. Третья Международная конференция технических писателей. 27-28 Марта 2026. Москва, Россия
🔥39❤7
This media is not supported in your browser
VIEW IN TELEGRAM
1😁58🤣28💯12🤔1😱1
#мемница
Всем привет!
У нас тут назрел вопрос вселенского масштаба...
О врачах, юристах, детективах, космонавтах сняты сотни культовых фильмов. И о программистах, и об учителях, и о переводчиках!
Но где фильм про технических писателей?
Мы, между прочим, живём тоже вполне насыщенной (а порой и весьма драматичной) жизнью:
⚡️спасаем релизы, когда важную фичу добавили в самый последний момент
⚡️достаём информацию, когда, казалось бы, она безвозвратно утрачена
⚡️выживаем во время созвонов, когда фраза «Это всё нужно будет задокументировать» звучит как угроза жизни
⚡️порой находим баги раньше QA (не гордимся, но и не отрицаем это)
Так что материала для сценария более чем достаточно...
Но пока вместо фильма у нас есть лишь небольшая подборка мемов с актёрами, которые могли бы сыграть в этом фильме🎥
Давайте посмотрим (не забудьте заглянуть в комментарии к посту! ) и будем вместе продолжать мечтать о том дне, когда на большом экране кто-то наконец скажет:
«Они спасли релиз. Никто не заметил, но это важно.»🦸
Всем привет!
У нас тут назрел вопрос вселенского масштаба...
О врачах, юристах, детективах, космонавтах сняты сотни культовых фильмов. И о программистах, и об учителях, и о переводчиках!
Но где фильм про технических писателей?
Мы, между прочим, живём тоже вполне насыщенной (а порой и весьма драматичной) жизнью:
⚡️спасаем релизы, когда важную фичу добавили в самый последний момент
⚡️достаём информацию, когда, казалось бы, она безвозвратно утрачена
⚡️выживаем во время созвонов, когда фраза «Это всё нужно будет задокументировать» звучит как угроза жизни
⚡️порой находим баги раньше QA (не гордимся, но и не отрицаем это)
Так что материала для сценария более чем достаточно...
Но пока вместо фильма у нас есть лишь небольшая подборка мемов с актёрами, которые могли бы сыграть в этом фильме🎥
Давайте посмотрим (
«Они спасли релиз. Никто не заметил, но это важно.»🦸
2😁40🔥22🎉6❤5🤩2