#выпуск 20 #практика
Всем привет! Сегодня несём новичкам (и не только!) два отличных курса от наших коллег.
1️⃣ Docs as code для самых маленьких
Автор канала Parawriter Антон Гафаров рассказывает о парадигме docs as code и объясняет, как с нуля развернуть свою документацию.
2️⃣ Курс по проектированию и документированию API для технических писателей
Техписатель Денис Ребенок (канал @pro_techwriting) разъясняет, как описывать API и как затем опубликовывать API-документацию.
Давайте качать харды вместе! 😎
Всем привет! Сегодня несём новичкам (и не только!) два отличных курса от наших коллег.
1️⃣ Docs as code для самых маленьких
Автор канала Parawriter Антон Гафаров рассказывает о парадигме docs as code и объясняет, как с нуля развернуть свою документацию.
2️⃣ Курс по проектированию и документированию API для технических писателей
Техписатель Денис Ребенок (канал @pro_techwriting) разъясняет, как описывать API и как затем опубликовывать API-документацию.
Давайте качать харды вместе! 😎
👍45🔥29❤12✍2
#анонс
Всем привет!
Нас попросили рассказать об одной конференции, и мы с радостью это делаем. И вот почему:
1. Это содержательная и полезная конференция для техписателей.
2. Много технины — то, по чему соскучились опытные коллеги. Ух, давно такое не анонсировали!
3. Это бесплатно. И можно подключиться онлайн — отличная возможность для техписателей из регионов. Если вы из Москвы или можете приехать в столицу, отлично — побываете в офисе СберТеха и позадаёте вопросы лично. Нетворкинг — наше всё)
А теперь конкретика (цитируем):
Doc Config 2025: как ИИ, скрипты и автоматизация меняют документацию
🗓26 сентября СберТех зовет на Doc Config 2025 — конференцию по технологичному документированию для разработчиков и технических писателей.
➡️О чем поговорим:
• Инструменты — скрипты для генерации контента с нуля, валидаторы, линтеры и многое другое;
• Автоматизация — от структурной миграции тысяч файлов до генерации готовых документов;
• ИИ в документировании — практические инструменты для проверки стиля, качества или интеллектуального поиска;
• Суровые кейсы — опыт разработки сложнейшей документации от экспертов СберТеха и ведущих ИТ-компаний.
Вас ждут очно и онлайн!
🔗Посмотреть программу и зарегистрироваться
Всем привет!
Нас попросили рассказать об одной конференции, и мы с радостью это делаем. И вот почему:
1. Это содержательная и полезная конференция для техписателей.
2. Много технины — то, по чему соскучились опытные коллеги. Ух, давно такое не анонсировали!
3. Это бесплатно. И можно подключиться онлайн — отличная возможность для техписателей из регионов. Если вы из Москвы или можете приехать в столицу, отлично — побываете в офисе СберТеха и позадаёте вопросы лично. Нетворкинг — наше всё)
А теперь конкретика (цитируем):
Doc Config 2025: как ИИ, скрипты и автоматизация меняют документацию
🗓26 сентября СберТех зовет на Doc Config 2025 — конференцию по технологичному документированию для разработчиков и технических писателей.
➡️О чем поговорим:
• Инструменты — скрипты для генерации контента с нуля, валидаторы, линтеры и многое другое;
• Автоматизация — от структурной миграции тысяч файлов до генерации готовых документов;
• ИИ в документировании — практические инструменты для проверки стиля, качества или интеллектуального поиска;
• Суровые кейсы — опыт разработки сложнейшей документации от экспертов СберТеха и ведущих ИТ-компаний.
Вас ждут очно и онлайн!
🔗Посмотреть программу и зарегистрироваться
Platform V
Doc Config 2025:технологичное документированиев эпоху автоматизации и нейросетей - информация об актуальных событиях компании СберТех
Doc Config 2025:<br />технологичное документирование<br />в эпоху автоматизации и нейросетей - событие компании СберТех. Создаем бизнес-решения на базе цифровой платформы Platform V.
👍26❤10🔥6👏1
#писалитирекомендует
Всем привет!
Как найти работу, если нет опыта?
Да, намекаем на стажировки)
Мы уже рассказывали о стажировках в Озоне и Лаборатории Касперского. А теперь знакомим новичков с 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