Дата публикации: .
В этом году гильдия технических писателей RWB (IT-структура Wildberries) провела онлайн-митап TechDocs для всех, кто интересуется документацией для цифровых платформ, разработкой пользовательской документации и управлением знаниями в IT-компаниях. В организации работает более 9000 IT-специалистов, технические писатели входят в команды инфраструктуры, финтеха, маркетплейса и других продуктов. Им не хватало возможности глубоко общаться друг с другом и делиться решениями — так родилась идея создать неформальное профессиональное объединение.
В гильдии обсуждают сложные вопросы, делятся опытом, разрабатывают единую редакционную политику и используют в работе самые разные методы создания корпоративной документации и управления знаниями, например, применяют матрицу компетенций техписателя. Когда накопилось много кейсов, гильдия решила делиться опытом не только внутри компании, но и со всем сообществом — так родился этот митап.
На примере реальных кейсов спикеры показали, как писать пользовательскую документацию и техническую в крупной IT-компании — от API до внутренних систем: документирование публичного API для разработчиков, использование системы оценки задач и интеграция подхода "документация как услуга". Ведущей вечера выступила Екатерина Косаткина (технический писатель, команда Публичного API). Она рассказала о гильдии и представила трех спикеров: Лидию Рудакову, Евгению Красильникову и Антона Гафарова.
Лидия Рудакова о документации API
В своем докладе Лида наглядно показала, как писать документацию для API в условиях растущей нагрузки и как выстроить процесс, чтобы он приносил пользу и разработчикам, и бизнесу. Она пришла в RWB, чтобы работать именно с этим продуктом.
На момент появления команды публичного API в 2023 году документация представляла собой PDF-файлы и Swagger-ссылки, которые поддержка вручную рассылала продавцам. У продавцов не было единого источника, документация не локализовалась на английский, не велась история изменений, а писали ее специалисты без навыков документирования.
Команда поставила цель — улучшить пользовательский опыт. Первый портал, созданный в 2023 году, ввел единый формат, локализацию, журнал изменений и централизованный доступ. Но остались проблемы: структура была неудобной, английская версия отставала от русской, а документацию все еще писали непрофильные специалисты.
В конце 2023 года с приходом Лиды начался рефакторинг OpenAPI-спецификаций, приведение английской версии к русской, разработка стандартов описания, включая стайлгайд для техписателей и кодстайл для спецификаций. Параллельно шла разработка нового портала с участием бизнес-аналитиков, дизайнеров, разработчиков и контент-менеджеров. Новый портал запустили в сентябре 2023 года. На тот момент было 30 000 продавцов, сейчас — 170 000, а количество запросов в секунду сейчас достигает 10 000.
На новом портале появились: поиск по методам, единый раздел со Swagger-тестированием, пользовательские статьи, форум, календарь изменений и статус API. Технические писатели разработали стайлгайд, инструкции, кодстайл для спецификаций, а также получили инструменты: отдельный репозиторий (деплой за 5 минут), инструменты проверки переводов, линтеры, проверку ссылок и орфографии.
Ключевые выводы Лиды: успех портала заключается в кроссфункциональной команде, автоматизации документирования и постоянной ориентации на пользовательский опыт.
Евгения Красильникова о единой системе оценки задач
Евгения Красильникова — технический писатель на проектах Russtech. В IT она 8 лет, успела поработать в технической поддержке, и внедрении документации.
Ее команда пишет пользовательскую документацию для внутренних нужд и для сторонних пользователей. Они решили изменить подход к документированию, сделав его более человечным, а заодно оптимизировать процессы. Возник вопрос: как оценивать нагрузку команды объективно?
Раньше оценка была интуитивной — каждый опирался на свой опыт. Команда выделила два параметра, на которые уходит время: исследование функции и объем изменений в документации. Оба параметра разложили на пять уровней сложности. Получилась матрица из 25 комбинаций, для каждой из которых прописали сложность и время выполнения.
Матрица оказалась громоздкой, поэтому команда обратилась к нейросети. Та сгенерировала HTML-калькулятор, который встроили в Wiki-систему. Теперь техписатель выбирает нужные значения, калькулятор показывает сложность и оценку — и данные переносятся в задачу.
Ключевые выводы Жени: пользователи не читают длинные таблицы. Им нужен визуальный инструмент, который упрощает, а не усложняет. Такой подход имеет смысл, когда команда регулярно принимает однотипные решения.
Антон Гафаров: документация как услуга
Антон Гафаров — технический писатель в управлении автоматизации инфраструктуры Финтеха. Он работает с документацией с 2016 года, в IT — с 2021-го.
Полтора года назад Антон пришел в команду, где было четыре GitLab-репозитория, около 30 статей в Markdown, и все это читали прямо в GitLab. Он решил создать полноценный документационный продукт. Вместе с DevOps-инженерами он настроил докпортал на MkDocs с темой Material, организовал окружения Stage и Prod, ввел обязательное ревью всех изменений.
На старте у Антона было 30 авторов, 4 репозитория и 1 техписатель. Ревью проходило в личных сообщениях. Со временем команда добавила генерацию диаграмм, ролевую модель доступа, шифрование конфиденциальных данных, формализовала ежедневные релизы и сделала ревью прозрачным — через отдельный чат.
Сейчас у Антона 12 репозиториев, около 80 авторов (активных — 15), более 500 статей и три докпортала, объединенных в одну систему. Но главное — он переосмыслил свою роль. Технический писатель тратит 10% времени на написание и 90% — на ревью и развитие системы. Антон внедрил концепцию "документация как услуга" с четырьмя базовыми услугами:
- хостинг документации команды;
- техническая поддержка документации;
- разработка документации с нуля;
- ревью и профессиональная вычитка.
В планах — автоматическое тестирование документации, инструменты локальной сборки и полноценный сервис-деск.
Ключевые выводы Антона:
- Никогда не оставайтесь просто техническим писателем — примеряйте роли аналитика, разработчика, владельца продукта.
- Используйте концепцию "документация как продукт": собирайте требования, формулируйте ТЗ, подбирайте инструменты.
- Четко формулируйте цели и планируйте с учетом нагрузки.
- Попробуйте внедрить docs‑as‑code — начиная с малого, с одного репозитория, масштабируйте поэтапно.
- Организовывайте процессы через себя как согласующее звено.
- Вовлекайте коллег — без них система не выживет.
От себя добавим, что подобные практики масштабирования знаний и автоматизации активно применяются и у зарубежных IT-гигантов. Например, в технических подразделениях Amazon Web Services (AWS) стандартом де-факто стал подход docs-as-code, когда исходные тексты документации хранятся в репозиториях рядом с кодом, а сборка и деплой порталов автоматизированы через CI/CD-пайплайны. Кроме того, зарубежные команды переходят к концепции управления контентом как полноценным продуктом (Documentation-as-a-Product), где технические писатели выступают внутренними сервис-провайдерами, предоставляя разработчикам готовые платформы, стайлгайды и автоматизированные инструменты проверки качества.
В одном из материалов блога Dr.Explain мы затрагивали тему использования концепции docs‑as‑code в разработке пользовательской документации.
Вопросы и ответы
После доклада спикеры отвечали на вопросы зрителей. Вот некоторые из них.
Вопросы Лиде:
- Вопрос: Как вы отслеживаете изменения в документации API и можно ли откатиться на предыдущую версию через Git?
Лидия: Да, все через Git, откат стандартный. Изменения отслеживаем в репозитории, а о новых методах узнаем от продуктовых команд. - Вопрос: Как синхронизируется работа техписателей с командами и техническими решениями?
Лидия: За счет четкого разделения ролей и проектного менеджера, который оркестрирует задачи. Техписатели не берут на себя лишнего. - Вопрос: Как оцениваете качество локализации?
Лидия: В команде высокая экспертиза английского, плюс используем инструменты проверки переводов, чтобы ничего не пропустить.
Вопросы Евгении:
- Вопрос: Есть ли у вас ритуалы, которые вы регулярно проводите в команде?
Евгения: Да, у нас есть чат для советов и неформальные встречи раз в месяц, где говорим не о работе — это помогает сохранять дружескую атмосферу. - Вопрос: С каких метрик начать команде, где нет единого понимания структуры работ?
Евгения: Начать стоит с совместного обсуждения, а метрики зависят от типа документации — для пользовательской они одни, для технической — другие. - Вопрос: Как избежать необъективной оценки задач?
Евгения: У нас все на доверии, плюс мы постоянно сравниваем фактические затраты с матрицей и при необходимости корректируем ее.
Вопросы Антону:
- Вопрос: Как формировалось видение портала и его функциональности?
Антон: Органично, как "рискованное земледелие" — мы начинали с MVP, а затем добавляли фичи по мере возникновения потребностей у команд. - Вопрос: Как организовано ревью документации?
Антон: Ревью проходит через отдельный чат, где я выступаю в роли корректора: правлю текст сам, а автор согласовывает результат на стейдже. - Вопрос: Как приоритизируете задачи, если появляется несколько критичных?
Антон: В порядке живой очереди, но хотфиксы берем сразу. Если задач много, выстраиваю приоритеты на основе срочности запросов. - Вопрос: Как оценить качество смысловой проверки, если ревьюер не в контексте темы?
Антон: Технический писатель должен уметь писать, а не разбираться глубоко в предмете. Хороший текст понятен даже без полного погружения, а содержательные правки мы всегда согласовываем с автором. - Вопрос: Как вы отслеживаете, что документацию нужно актуализировать?
Антон: Во-первых, следим за анонсами изменений. Во-вторых, наши коллеги сами приносят обновления в документацию вместе с изменениями в инфраструктуре — в 95% случаев.
Этот митап стал яркой демонстрацией того, как создается качественная пользовательская документация для цифровых продуктов в реальной корпоративной среде. Опыт RWB доказывает, что системный подход к процессам, внедрение принципов docs-as-code и трансформация техписателя из исполнителя во владельца сервиса позволяют масштабировать знания и эффективно управлять нагрузкой даже в крупнейших IT-экосистемах. Организаторы пообещали сделать следующую встречу еще ярче и полезнее.
Материал подготовлен на основе стенограммы митапа технических писателей RWB, прошедшего 16 июля 2026 года.