Программа

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

Возникает вопрос: применим ли стандарт к современным системам с искусственным интеллектом? ГОСТ 34 предполагает детерминированное поведение системы, тогда как поведение ИИ-систем принципиально недетерминированное. Прямолинейное применение требований ГОСТ 34 к интеллектуальным системам дает формально правильный, но практически бесполезный результат. Требуется ли принципиально новый стандарт для ИИ-систем? Авторы считают, что общий подход, основанный на различении поведения системы и средств его реализации, остается актуальным. Однако подходы к описанию требуют пересмотра с учетом особенностей технологий ИИ.

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

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

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

В этом докладе разберем:

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

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

При росте количества продуктов в нашем департаменте стало ясно, что без единой дизайн-системы интерфейсы быстро перестанут быть целостными. Мы в команде фронтенда инициировали создание общего UI-кита как «источника истины»: от макетов в Figma до готового кода.
В докладе я расскажу, как мы построили сквозную навигацию от дизайна до продакшена, организовали работу с текстами и локализацией, вовлекли дизайнеров, техписателей, аналитиков и продакт-менеджеров. Поделюсь процессами разработки и документирования компонентов, а также опытом ведения внутреннего фронтенд-блога, который помогает масштабировать знания внутри компании.

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

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

Из доклада слушатели узнают, как интегрировать продуктовые best practices в работу над документацией, управлять ее развитием как полноценным продуктом и создавать измеримую пользу для всех сторон.

• Автогенерация форм слов (падежи, наклонения и др.) для обеспечения согласованности.
• Автоматическое форматирование документов при генерации DOC-файлов (прощай, копи-паст). 
• Работа с LLM в режиме Copilot через MD-редактор. 
• Промпты через JSON/YAML структуры для генерации качественных ответов от LLM. 
• Технические и экономические ограничения в применении LLM («экономика токенов»). 

Что дает нахождение ПО в реестре Минцифры? Льготы, гранты, преференции!

Для чего нужно вносить ПАК в реестр Минцифры и какие особенности ПАКов, предназначенных для обеспечения информационной безопасности (ФСТЭК).

Мы разберем краткую инструкцию по регистрации ПО и ПАК.

Вы узнаете список иностранных запрещенных компонентов

Вы получите чек-лист для проверки технической документации к ПО и ПАК на соответствие требованиям Минцифры для подачи в реестр отечественного ПО.

Как понять, работает ли документация и приносит ли она пользу продукту и бизнесу? 

В докладе расскажу: 

• с чего начать, какие метрики стоит внедрять,
• как команда выстроила отчётность с нуля,
• как с помощью данных мы измеряем влияние документации на бизнес-результаты и поддержку.

Подробно остановимся на «историях успеха» и проблемах на нашем пути.

Стили – важный инструмент в работе с MS Word.

Цель мастер-класса – поделиться тремя кейсами, которые родились на практике и помогут работать с документами быстрее, комфортнее и продуктивнее, а цена их внедрения равна нулю.

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

Кому это будет интересно?

Тем, кому никуда от MS Word не уйти, и тем, кто стремится разработать его аналог.

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

В докладе уделяется внимание выбору инструментов и моделей и рассматриваются критерии отбора: соответствие требованиям безопасности, качество работы, удобство использования.

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

Материал будет полезен техническим писателям, руководителям команд и другим специалистам, рассматривающим автоматизацию процессов в области документации с помощью ИИ-агентов.

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

Отдельное внимание уделено формуле «ПЯТКА», объединяющей пять ключевых свойств качественного UX-текста: пользу, ясность, структурность, краткость и активность. Такой «мультитул» позволяет техническим писателям, дизайнерам и исследователям единообразно улучшать контент и интерфейсы без постоянного привлечения пользователей.

Доклад будет полезен тем, кто хочет системно повышать качество интерфейсных решений и внедрять понятные, воспроизводимые практики UX-редактуры в команде.

База знаний призвана стать основным источником информации для сотрудников, но часто остаётся недооценённым инструментом.

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

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

Сначала мы начали собирать сhangelog из системы управления задачами, но выяснилось, что задач так много, что уследить за всеми изменениями достаточно трудно. В поисках более эффективного решения мы перешли к автоматической генерации changelog на основе истории коммитов в GitLab.

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

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

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

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

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

Презентация будет полезна руководителям, тимлидам и писателям для диагностики текущего состояния процессов работы с текстом, выявления зон роста, стратегического планирования и системного улучшения этих процессов, а также для упрощения бизнес-обоснований. Кроме того, шаблон позволяет "разложить по полочкам" и систематизировать полезные идеи и best practices с конференции или из других источников!

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

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

На примере своего портала пользовательской документации Sharx Base мы расскажем, как организовали разработку документации в своей компании с помощью MkDocs. Что послужило триггером? Какие были первые шаги? Как сейчас выглядит работа технического писателя у нас? Какие проблемы? Какие планы на будущее? Реальный кейс из реальной жизни.

Не так давно документация по продуктам VK WorkSpace решила мигрировать с одного генератора статических сайтов — MkDocs, на другой — Hugo. Хочу поделиться с вами впечатлениями и подводными камнями. Обсудим какой из инструментов больше подходит для Enterprise продуктов, а какой для стартапов. Посмотрим где у технического писателя больше возможностей для развития портала и личных навыков. 

Ну и, конечно, сыграем в бинго, чтобы сравнить два генератора и их технические возможности.

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

Мой доклад — это история эволюции простой функциональности в мощный инструмент. Я расскажу, как мы разработали сервис для экспорта веб-документации в PDF, который заменил собой Pandoc.

Вы узнаете не только о технической реализации, но и о пути, который мы прошли: от простого решения на Python и Puppeteer до высокопроизводительного Go-сервиса, использующего силу горутин и ChromeDP для параллельного рендеринга десятков страниц.

Мы обсудим:

• Почему HTML → PDF — это лучший способ получить документ, максимально совпадающий с живым сайтом.
• Архитектурные решения, которые позволили нам создать отказоустойчивый и легко развертываемый сервис.
• Ключевые причины, по которым наш собственный сервис оказался лучше и удобнее Pandoc.

Это история о том, как правильный выбор технологий и архитектуры помог превратить простую кнопку в важный элемент DocOps инфраструктуры.

Можно ли подружить документацию по ГОСТ с подходом docs-as-code? 

Как держать в актуальном состоянии сразу весь комплект документов? 

Можно ли перестать переживать за оформление документа? 

Ответы на эти и другие вопросы мы нашли при внедрении автоматизации подготовки документации.

В рамках доклада расскажу как мы:

• Решили проблему версионирования документов.
• Автоматизировали сборку и оформление документов.
• Перестали копировать одну и ту же информацию.
• Сократили время на подготовку документации, улучшив при этом её качество.

Последние несколько лет мы (documentat.io) активно изучаем техписательский рынок труда: проводим социологические исследования среди техписателей и много общаемся с компаниями, у которых есть спрос на документационных специалистов.

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

- Работодатели в зонах «меньше медианы» и «больше медианы»: кто они и почему они платят по-разному?

- Как зрелость процессов вокруг документации определяет зарплатную политику компании.

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

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

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

Разберём:

• какие документы на самом деле нужны,

• как мотивировать коллег их писать и использовать,

• какие принципы помогают внедрить документирование процессов.

Расскажу реальный кейс онбординга не только нового сотрудника в команду, но и адаптации новой команды в новый продукт.

Рассмотрим практические кейсы с вариантами онбординга и особенностями каждого из них.
Стандартные кейсы: онбординг нового сотрудника в команду и онбординг группы сотрудников в команду.

Нестандартные кейсы: онбординг новой команды в новый продукт и нового сотрудника в новую команду новых продуктов.

Рассказу про ошибки и предложу свои рекомендации.

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

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

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

Доклад предназначен для всех, кто пишет документацию – от начинающих до опытных техписателей.

• Объясним, с чего начать и как избавиться от лишних споров о терминах. 
• Покажем структуру глоссария и разберёмся, как определить, какие слова должны стать терминами.
• Расскажем, как создать ИИ-ассистента, который может упростить разработку документации с помощью глоссария.

Порой мы как огня боимся вакансий, где нужно писать документацию по ГОСТ. Оправдано ли это? Предлагаю свой взгляд техписателя, прошедшего этот этап в карьере. В докладе мы разберём, какие навыки ГОСТ-техписателя полезны всем. Как можно перейти от артефактов на полке к созданию живой документации и стать частью команды разработки. Вы узнаете, что Docs-as-Code не про «программирование для избранных», а про простые инструменты — Markdown или AsciiDoc, Git и CI/CD — которые вы легко можете использовать. В докладе покажу, что порог входа для использования подхода Docs-as-Code — минимальный. И на простых схемах объясню как работает новый подход  Docs-as-code. 

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

В докладе я расскажу о том, как мы в Yandex Cloud учились документировать Python SDK, какие инструменты использовали для этого и с какими сложностями столкнулись в процессе.

Редакторы часто сталкиваются с тем, что текст нужно проверить в сжатые сроки. Документация, пресс-релиз, пост в Telegram или внутренний дайджест — не играет роли, если пользоваться удобным инструментом. Матрица итеративного редактирования и стала для нас таким инструментом: с ее помощью мы работаем по-настоящему эффективно.

Как внедрить KPI для редакторов, какие метрики текста отслеживать, какие отчёты показывать бизнесу? И как сделать так, чтобы таблички не убили свободу и мотивацию сотрудников?
Автор доклада наблюдает любопытный парадокс — сервисные творческие команды в корпорациях должны достигать конкретных бизнес-результатов неконкретными, трудноизмеримыми средствами. А высокий уровень осознанности и менталитет творческих специалистов, например редакторов или дизайнеров, осложняет централизованное управление результатом. 
В докладе речь пойдёт о здоровом балансе корпоративного и индивидуального. Слушателей ждут конкретные подходы, личный опыт и практические советы для представителей креативной индустрии. Будет полезно линейным сотрудникам, тимлидам и их руководителям.

В нашей команде документация тесно связана с оригинальными решениями и нестандартными процессами: собственные теги разметки, оригинальные HTML-компоненты, примеры на внутреннем языке программирования. Чтобы упростить работу с таким стеком, мы разработали кастомное расширение для VS Code, которое стало незаменимым инструментом в повседневной практике.

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

В докладе рассмотрим актуальные проблемы миграции документации крупных проектов на новый технический стек. 

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

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

Как и почему мы отказались от GitBook и перешли на Diplodoc для публикации документации. Как проходил переход, сколько он занял времени и как в результате изменилась наша инфраструктура. Поделимся лайфхаками, провалами и итогами: стабильность, переиспользование контента, обратная связь и Grafana для анализа качества документации.

Комплект документации для одного и того же программного продукта может существенно различаться в зависимости от бизнес-целей: состав материалов, целевая аудитория, глубина детализации, требования к актуальности, а также соответствие правилам — ГОСТы, отраслевые стандарты, требования регуляторов, внутренние стайлгайды. Более того, на проектах могут применяться свои критерии оценки качества документации: сроки подготовки, оформление, полнота содержания, актуальность и другие параметры.

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

• необходимость строгого соответствия ГОСТам

• требования к иллюстрациям и подписям

• кликабельность перекрёстных ссылок
  и многое другое.

1. как технический писатель становится лидером, меняя фокус с написания текстов на стратегическое видение и менторство;
2. почему лидер берет на себя ответственность за ошибки команды, используя эти ошибки для улучшения процесса;
3. классические правила менеджмента, которые требуют адаптации под специфическую мотивацию технических писателей;
4. правильное делегирование — и почему это инструмент роста команды, а не микроменеджмент;
5. почему мотивация технических писателей основана на влиянии их работы с продуктом и пользователем; 
6. в чем заключается настоящее лидерство и как оно проявляется в действиях и авторитете, а не в формальной должности; 
7. как карьера технического писателя может вести как вглубь экспертизы, так и к вершинам топ-менеджмента.

В докладе будет представлен практический опыт создания и внедрения решения по автоматизации описаний команд CLI. Я расскажу про ключевые этапы его реализации, использованные технологии (скрипты, шаблоны RST, CI/CD интеграция, API репозитория).

Ранее описание каждой новой или измененной команды CLI требовало от техписателя ручного сбора информации, написания текста, форматирования в RST, создания Merge Request (MR) в репозиторий документации и последующего согласования.

Этот процесс был трудоемким и создавал узкое место.

Мы разработали и внедрили систему, которая автоматически извлекает данные, генерирует структурированные файлы, автоматизирует доставку изменений, создает задачи на техписателей.

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

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

Рассмотрим, какие бывают подходы к стажировкам и нужно ли их оплачивать.

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

Чтобы решения, связанные с автогенерацией документации были действительно эффективными нужно учитывать три вещи:

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

По закону Парето 80% результата достигается за счёт 20% усилий.

Мы проанализировали, на что уходит большая часть остальных 80% рабочего времени редактора, и нашли способы сократить время на работу над типовыми задачами.

Для этого каталогизировали задачи по типам, разработали общий алгоритм работы над контентом и его вариации для разного типа текстов. Сделали «маски текста» — набор шаблонов для разных типов контента: заявок, инструкций, уведомлений, рассылок и даже лендингов.

Всё это позволило значительно сэкономить время на работу над типовыми задачами.

В докладе мы разберем, как с помощью современных ИИ-технологий можно автоматизировать генерацию пользовательских инструкций на основе интерфейсных макетов из Figma.

Кроме того, мы продемонстрируем, как с помощью Figma API можно извлекать структуру и визуальные данные, преобразовывать их в удобный формат, а затем использовать мультимодальные модели вроде GPT-4o для генерации осмысленных, понятных пользователю инструкций.

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

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

Это доклад не про смерть профессии, а про ее перезагрузку. Вы уйдете с пониманием, какие инструменты взять и с чего начать уже в понедельник.

Доклад рассказывает о том, как требования государственных регуляторов и заказчиков влияют на развитие продукта и внутренних процессов компании. Подача заявок на включение в различные реестры или получение допусков приводит к серьезным доработкам продукта: от изменения архитектуры и смены технологического стека до усиления мер безопасности и интеграции с государственными сервисами.

Доклад будет полезен компаниям, планирующим выход на рынок B2G. 

Поделюсь опытом работы в редкой для техписателя сфере — GameDev. Здесь свои особенности: отдельные команды художников и дизайнеров, целый «зоопарк» разных разработчиков. Из-за разницы в техническом бэкграунде целевая аудитория документации очень разнородна, и необходимость доходчиво доносить технические вещи простым языком становится ещё острее. 

В этом докладе:

• Расскажу об истории своего найма: что ожидал работодатель, с чем столкнулся и что получил в итоге.
• Покажу примеры задач, которые мне пришлось решать.
• Приведу аргументы за и против, чтобы вы сами смогли решить, стоит ли идти в GameDev техписателем.