Live-данные · обновлено 23.06.26

Технический писатель: кто это и чем занимается

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

ИА Игорь Антонов · Технический редактор · Senior technical writer / documentation lead
Вакансии
31
Москва и МО · 23.06.26
Оценка зарплаты
130 000 ₽
Оценка по вакансиям за 180 дней
Спрос
13 / 100
Низкий · #43
Уровень
Senior
58% вакансий
Формат
офисный формат
удал. 3% · гибрид 45% · офис 52%
Выборка зарплат
34
вакансий с зарплатой

Как ещё называют технического писателя

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

Синонимы
технический писательтехпистехрайтерtechnical writertechnical authordocumentation writerdocs writerAPI technical writer
Смежные роли
технический редакторtechnical editorредактор технической документацииUX writercontent designerknowledge managerdeveloper advocateбизнес-аналитиксистемный аналитикспециалист поддержки
Рыночный вывод

Свежие данные рынка: 31 активных вакансий, зарплатная оценка 130 000 ₽, спрос 13/100. Срез по Москве и МО от 23.06.2026. Для технического писателя сейчас используется estimated-зарплата: SkillStat считает оценку по расширенному окну профессии, потому что в активном срезе мало вакансий с открытой зарплатной вилкой.

Все профессии Подробнее о зарплате

Коротко о профессии

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

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

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

Для этой профессии доступны ограниченные данные. Аналитика носит ориентировочный характер.

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

Источники и методология

Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.

Регион
Москва и МО
Срез
23.06.26
Зарплата
Оценка по вакансиям за 180 дней
Выборка
n=34
Методология зарплат Методология спроса

Как мы считали

  • Рыночные числа на странице относятся к Москве и Московской области; описание technical writing относится к роли в целом и не замораживает текущие вакансии в тексте.
  • Зарплату и спрос нужно читать через live-блоки SkillStat. Если зарплата показана как Оценка по вакансиям за 180 дней, это ориентир по доступной выборке, а не точная live-медиана текущего дня.
  • Навыки сгруппированы по рабочим слоям: структура документа, техническая база, API, docs-as-code, базы знаний, проверка сценария и работа с экспертами.
  • Вакансии могут называться технический писатель, technical writer, техпис, техрайтер, технический автор, documentation writer или API technical writer.

Актуальные данные по профессии

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

Вакансии Количество активных вакансий на сегодня в регионе Москва и МО. Не включает закрытые или приостановленные.
31
активных вакансий
Москва и МО · текущий срез 23.06.26
7 дней назад
36
16.06.26 -14%
30 дней назад
32
24.05.26 -3%
Спрос 50 = средний по рынку, 100 = в 4× больше вакансий чем у средней IT-профессии. Метрика считается по актуальной выборке Москва и МО.
13
из 100
Ранг по спросу
#43 из 71
Статус
Низкий
Топ спроса
#1
Системный аналитик
645
#2
Продакт-менеджер
521
#3
Бизнес-аналитик
504
Оценка зарплаты
Оценка
130 000₽
Москва и МО · Оценка по вакансиям за 180 дней
Вакансии профессии за 180 дней · n=34
Диапазон и позиция в зарплатном рейтинге не показаны: зарплата рассчитана в estimated-режиме, поэтому SkillStat не выводит эти значения, чтобы не создавать ложную точность.
Средний тренд Сначала сравниваем последние 30 дней с предыдущими 30. Если в одном из окон меньше 14 точек, пробуем 45, 60, 90 дней. Ряд использует ту же семантику активных публичных вакансий, что и верхнее число.
1.7%
последние 30 дней vs предыдущие 30
существенного сдвига между окнами нет
30 против 31 вакансий, последние 30 дней vs предыдущие 30
сглаживание 30 дней

Кто такой технический писатель

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

Работа начинается не с текста, а со сценария читателя. Нужно понять, кто читает материал, что он хочет сделать, какие условия обязательны, где он ошибётся и какой результат должен увидеть. Иногда это короткая инструкция. Иногда API reference, troubleshooting, руководство администратора, release notes или раздел базы знаний.

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

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

Рабочий объект

Документация для пользователей, разработчиков, администраторов, поддержки и внутренних команд: инструкции, справка, API, руководства, база знаний

Главная ценность

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

Ключевой риск

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

Когда документ действительно работает

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

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

Как технический писатель добывает точность

Эксперт редко приносит готовое объяснение в удобной форме. Один описывает внутренними терминами, другой перескакивает через шаги, третий уверен, что читателю и так всё понятно. Технический писатель собирает эти куски, перепроверяет смысл и превращает их в ясную последовательность действий без лишнего профессионального тумана.

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

Почему документация не должна быть складом статей

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

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

Технический писатель, технический редактор, UX writer, аналитик и поддержка: в чём разница

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

Роль Главный читатель Что делает Типовой результат Чем отличается от технического писателя
Технический писатель Пользователь, администратор, интегратор, поддержка, внутренняя команда. Собирает факты, проверяет сценарий, пишет и обновляет документацию. Инструкция, user guide, API documentation, база знаний, release notes, troubleshooting. Это базовая роль страницы: отвечает за документ, по которому читатель выполняет действие.
Технический редактор Автор документа, документационная команда, продуктовая или инженерная команда. Проверяет точность, структуру, стиль, термины, стандарты, ссылки и единообразие. Отредактированный и согласованный документ, style guide, чек-лист качества. Чаще редактирует и проверяет материал, а не создаёт весь документ с нуля.
API technical writer Разработчик, интегратор, партнёрская команда. Описывает endpoint, method, параметры, auth, request, response, status codes и ошибки. API reference, OpenAPI-описание, примеры запросов, SDK snippets. Это специализация технического писателя с упором на API и интеграции.
UX writer Пользователь внутри интерфейса. Пишет microcopy: кнопки, подсказки, ошибки, пустые состояния, onboarding. Короткие интерфейсные тексты и правила тона продукта. Работает внутри интерфейса, а не с длинной документацией и базой знаний.
Content Designer Пользователь продукта или сервиса. Проектирует содержание сценария вместе с UX, продуктом и исследованием. Контент-модель, структура экранов, тексты, пользовательский путь. Фокус шире текста документа: содержание становится частью продуктового дизайна.
Knowledge Manager Сотрудники, поддержка, внедрение, внутренние пользователи. Строит систему знаний, владельцев разделов, поиск, архив и актуализацию. База знаний, правила публикации, метрики использования, процесс обновления. Меньше пишет отдельные документы, больше управляет knowledge system.
Бизнес-аналитик Заказчик, команда разработки, владелец продукта. Собирает требования, описывает процесс, ограничения и критерии приёмки. Требования, user stories, модели процессов, acceptance criteria. Описывает, что нужно сделать в системе; техпис объясняет, как системой пользоваться.
Системный аналитик Разработка, интеграции, тестирование. Описывает поведение системы, API, данные, статусы, ошибки и интеграции. Спецификация, модель данных, описание API, схема интеграции. Готовит техническое описание для реализации, а не пользовательскую документацию.
Специалист поддержки Пользователь с конкретной проблемой. Разбирает обращение, диагностирует ситуацию, даёт решение или эскалирует. Ответ пользователю, тикет, workaround, сигнал для базы знаний. Решает один случай; техпис превращает повторяющийся случай в документ.
Developer advocate Внешние разработчики, партнёры, сообщество. Объясняет продукт разработчикам, делает примеры, собирает обратную связь, выступает. Tutorials, demo apps, guides, talks, sample code, developer portal. Документация является частью работы, но фокус шире: adoption и developer relations.

Чем занимается технический писатель

Требования

сценарии, критерии и постановка задачи

  • Проверить текст на действии: проходит ли сценарий, совпадают ли названия и не пропущены ли условия.
  • Обновлять документы после релизов, правок интерфейса, новых версий и вопросов поддержки.
Система

данные, api, статусы и интеграции

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

согласование и работа с разработкой

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

Как выглядит работа по задаче

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

Шаг 01

Определяет читателя

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

Шаг 02

Собирает технические факты

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

Шаг 03

Проектирует структуру

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

Шаг 04

Пишет и проверяет

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

Шаг 05

Поддерживает актуальность

Следит за релизами, изменениями интерфейса, версиями API, вопросами поддержки и устаревшими разделами документации.

Технический писатель и технический редактор: где граница

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

01
Главный результат
Технический писатель

Инструкция, API reference, user guide, release notes, troubleshooting или раздел базы знаний, по которому читатель действует.

Технический редактор

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

02
Фокус работы
Технический писатель

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

Технический редактор

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

03
Критерий качества
Технический писатель

Читатель может выполнить задачу без личного объяснения эксперта.

Технический редактор

Документ точен, согласован, не противоречит стандарту и одинаково читается в общей системе материалов.

04
Когда роли пересекаются
Технический писатель

В небольших командах техпис сам редактирует свои документы и ведёт style guide.

Технический редактор

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

Навыки технического писателя: что требуют работодатели

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

В текущих вакансиях часто встречаются Git, Confluence, техническая документация, Jira, ГОСТ, ЕСКД, Markdown, API, Linux, Python и SQL. Это не один общий стек для всех техписов. Git и Markdown важны для docs-as-code, Confluence и Jira - для корпоративной базы знаний и процесса, API и OpenAPI - для документации разработчиков, ГОСТ/ЕСКД/ЕСПД - для регламентированных продуктов.

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

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

В текущем активном срезе по этой роли 31 вакансий. Список работодателей ниже построен по накопленной статистике SkillStat, поэтому его нужно читать как ориентир по источникам вакансий, а не как долю текущего рынка.
Топ работодателей
Компании, которые встречаются в вакансиях по профессии Технический писатель
1
Лаборатория Касперского
7 вак.
2
Аквариус. R&D
5 вак.
3
Группа компаний Астра
4 вак.
4
РОСКОСМОС
3 вак.
5
amoCRM
3 вак.
6
АО Российские космические системы
3 вак.
Навыки из вакансий % вакансий, где навык явно упомянут работодателем.
Навыки и инструменты, которые работодатели чаще всего указывают в вакансиях по этой роли.
Confluence 29% Git 29%
Техническая документация 26%
Jira 19% GitLab 13%
Полная карта навыков: частотность, по грейдам и связки технологий →
Полная карта навыков Технический писатель →
Вход через junior
26%
от рынка

Вход в профессию для начинающих выглядит достаточно реалистично.

На одну junior-вакансию приходится примерно 2.2 senior-позиции.
Навыков на вакансию
6.5
в среднем

Столько требований работодатели обычно собирают в одной позиции по этой роли.

Какие документы пишет technical writer

Формат выбирают не по привычке, а по задаче читателя. Один и тот же продукт может требовать короткой инструкции для пользователя, API reference для интегратора, troubleshooting для поддержки и release notes для команды внедрения.

Пошаговая инструкция

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

User guide / admin guide

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

API documentation

Описывает endpoint, method, параметры, auth, request, response, status codes, error examples и рабочий пример. Хорошее API-описание экономит время интеграторов и инженеров поддержки.

Troubleshooting

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

Release notes

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

База знаний

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

Technical Writing Core: что реально нужно знать

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

Сценарий читателя

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

Форматы документации

Инструкция, справка, user guide, admin guide, API reference, tutorial, release notes, troubleshooting, knowledge base и FAQ.

Техническая база

HTTP, API, JSON, авторизация, ошибки, Git, Markdown, OpenAPI, базовый SQL, CLI и логи на уровне, достаточном для точных вопросов к эксперту.

Docs-as-code

Git, branch, pull request, review, versioning, changelog, CI/CD публикации и статическая генерация документации.

API documentation

Endpoint, method, parameters, request, response, status codes, auth, errors, examples и SDK snippets. Здесь особенно важна проверяемость примеров.

Стандарты и стиль

ГОСТ, ЕСКД, ЕСПД, ГОСТ 19, ГОСТ 34, style guide, терминология, глоссарий и шаблоны. Стандарт нужен там, где документ должен пройти формальную приёмку.

Проверка качества

Проверка по сценарию, тестовая среда, совпадение с интерфейсом, актуальность после релиза и ревью эксперта.

Работа с экспертами

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

Система знаний

Структура базы, владельцы разделов, версия продукта, поиск, архив, устаревшие статьи и метрики обращений.

Навыки технического писателя: ядро и технический контекст

В вакансиях могут стоять Git, Confluence, Jira, ГОСТ, Markdown, API, Linux, Python и SQL рядом. Их нельзя читать как один обязательный стек. Часть навыков относится к самой документации, часть - к продуктовой среде.

Группа Что входит Зачем нужно
Документационное ядро Техническая документация, структура инструкции, ясный язык, проверка сценария, работа с экспертом. Чтобы документ помогал выполнить действие, а не просто красиво описывал продукт.
Инструменты публикации Confluence, Markdown, Git, GitLab, Jira, базы знаний, review-процесс. Чтобы документы имели владельцев, версии, связи с задачами и понятный процесс обновления.
API и developer docs HTTP, JSON, API, OpenAPI / Swagger, auth, status codes, error examples, CLI, logs. Чтобы описывать интеграции, методы, ошибки и рабочие примеры для разработчиков.
Стандарты ГОСТ, ЕСКД, ЕСПД, ГОСТ 19, ГОСТ 34, глоссарий, style guide, шаблоны. Чтобы документы были единообразными и проходили формальные требования проекта или отрасли.
Технический контекст Linux, Python, SQL, 1С, Miro и продуктовые инструменты. Полезно для инженерных продуктов и внутренних систем, но не заменяет документационное мышление.
Смежные роли

Роли, с которыми технический писатель чаще всего пересекается или из которых переходит в documentation и product knowledge.

Бизнес-аналитик Системный аналитик Product Manager Продуктовый аналитик Manual QA Backend-разработчик DevOps-инженер

Сколько зарабатывает Технический писатель

Для технического писателя сейчас доступна рыночная оценка дохода, а не точная медиана только по текущим активным вакансиям. Её лучше читать вместе с подписью источника и структурой рынка по уровням.
Оценка зарплаты Оценка
130 000₽
Москва и МО · Оценка по вакансиям за 180 дней
Вакансии профессии за 180 дней · n=34
Опора оценки
34
наблюдений в опорном срезе
Диапазон и позиция в зарплатном рейтинге не показаны: зарплата рассчитана в estimated-режиме, поэтому SkillStat не выводит эти значения, чтобы не создавать ложную точность.
Подробная статистика зарплат Технический писатель →
По данным SkillStat для Москвы и МО зарплатная оценка технического писателя составляет 130 000 ₽. Это estimated-оценка, а не точная медиана активного дня: расчёт сделан по расширенному окну профессии. Диапазон и позиция в зарплатном рейтинге не показываются, потому что открытых зарплат недостаточно для устойчивой вилки.
Зарплата по грейдам
Медиана зарплаты по грейду. n — выборка вакансий с указанной суммой.

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

Распределение по уровням
Senior
58% рынка
Senior
58%
Middle
16%
Junior
26%
По структуре вакансий видно, какой уровень для этой профессии считается базовым на рынке. Это помогает читать грейды не как абстрактную лестницу, а как реальную точку входа и роста.
Дополнительный разбор

Где начинается рост

Оплата зависит не от красивого стиля, а от цены ошибки в документации. Простая справка и обновление готовых статей оцениваются ниже, чем API documentation, docs-as-code, руководства администраторов, документация для сложного B2B-продукта, ГОСТ-комплекты, релизный процесс и ownership базы знаний.

Что говорит структура рынка

Выше ценятся специалисты, которые сами проверяют сценарии, работают с экспертами, понимают HTTP, JSON, авторизацию, ошибки, OpenAPI, Git, версии продукта и умеют объяснять ограничения. Если документ ломает интеграцию или увеличивает нагрузку на поддержку, это уже не редакторская мелочь, а продуктовый риск.

Вакансии технического писателя: спрос и динамика рынка

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

Активные вакансии
31
в активном найме
Москва и МО · текущий срез 23.06.26
7 дней назад
36
16.06.26 -14%
30 дней назад
32
24.05.26 -3%
Спрос
13
из 100
Ранг по спросу
#43 из 71
Статус
Низкий
Среднее число активных вакансий по месяцам
Блок показывает среднее число активных вакансий за месяц, чтобы видеть общую картину без шума отдельных дней.
июнь 30 неполный -1
май 31 -7
апрель 38 +7
март 31 -11
февраль 42
Июнь пока показан как текущий неполный месяц, поэтому его лучше читать как живую картину рынка, а не как итог месяца.
Дополнительный разбор

В актуальном срезе SkillStat у технического писателя 31 активных вакансий, спрос 13/100 и ранг #43 из 71. Статус спроса низкий, но это не означает, что техническая документация не нужна. Часто задачи документации распределены между аналитиками, поддержкой, разработчиками, product-менеджерами или небольшой документационной командой.

Отдельная вакансия technical writer появляется там, где документация уже стала частью продукта, внедрения или API. Это сложные B2B-системы, инфраструктурные продукты, безопасность, платформы для разработчиков, корпоративные базы знаний, регламентированные отрасли и продукты с частыми релизами.

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

Формат работы технического писателя

Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.

Сейчас сильнее всего выражен офисный формат: его отрыв от следующего сценария составляет около 6 п.п.
Удалённо
3%
Гибрид
45%
Офис
52%
По 31 вакансиям

Карьерный путь технического писателя

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

01
Junior

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

02
Middle

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

03
Senior

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

04
Lead

Дальше есть несколько направлений: docs lead, владелец базы знаний, продуктовый аналитик, product education или content design. Рост зависит от того, берёт ли специалист ownership за систему знаний, а не только за отдельные тексты.

Где работает технический писатель

Продуктовые сервисы

Пишет справку, инструкции, подсказки, материалы к релизам и разделы, которые помогают пользователям освоить сложные функции.

Платформы и API

Описывает методы, параметры, авторизацию, ошибки, примеры запросов, версии и сценарии интеграции для разработчиков.

Внутренние знания

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

Путь в профессию: техническим писателем

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

01
Научиться писать инструкции

Брать реальные функции и описывать путь пользователя: цель, условия, шаги, результат, возможные ошибки и способ проверки.

02
Освоить техническую базу

Разобраться с Markdown, Git, HTTP, REST, JSON, OpenAPI, авторизацией, кодами ошибок и базовой работой с тестовой средой.

03
Собрать портфолио разных форматов

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

04
Тренировать интервью с экспертами

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

05
Понять процесс обновления

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

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

Что учить сначала

Лучший порядок обучения идёт от понятного документа к инженерному контуру. Если сразу начать с OpenAPI, ГОСТов или docs-as-code, легко выучить инструмент и не научиться помогать читателю.

01

Ясное техническое письмо

Учитесь писать без канцелярии, рекламных обещаний и лишних объяснений. Один абзац - одна задача для читателя.

02

Структура инструкции

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

03

Интервью с экспертом

Задавайте вопросы о сценарии, ограничениях, ошибках, ролях, версиях и примерах. Не принимайте непонятное объяснение как готовый факт.

04

Проверка сценария

Пройдите шаги сами или с тестовым пользователем. Если действие нельзя повторить по документу, материал ещё не готов.

05

Markdown и Git

Markdown нужен для чистой структуры, Git - для версий, pull request и ревью документации.

06

Confluence или база знаний

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

07

HTTP, API, JSON

Поймите request, response, status codes, auth и error cases. Без этого API documentation превращается в неточный пересказ.

08

OpenAPI / Swagger

Научитесь читать спецификацию и проверять, совпадает ли описание с рабочим примером.

09

Docs-as-code

Добавьте branch, pull request, review, versioning, changelog, сборку и публикацию документации.

10

Release notes и changelog

Пишите не список задач, а объяснение: что изменилось, кому важно, что нужно сделать и где ограничения.

11

Troubleshooting

Учитесь описывать симптом, диагностику, решение и момент, когда проблему нужно эскалировать.

12

Style guide и портфолио

Соберите 4-5 документов с пояснением: кто читатель, какую задачу решает текст и как проверена точность.

Что не надо учить сразу

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

Не начинать с ГОСТов

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

Не учить API-доки без HTTP и JSON

Сначала разберитесь с request, response, auth, status codes и ошибками. Иначе описание метода будет выглядеть техническим, но не будет проверяемым.

Не делать портфолио из красивых текстов

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

Не писать docs-as-code без Git

Docs-as-code начинается не с модного названия, а с версии документа, ветки, pull request, ревью и понятной публикации.

Не путать грамотность с точностью

Гладкий текст бесполезен, если в нём неправильный параметр, пропущено условие или шаг нельзя повторить.

Не переписывать эксперта до проверки

Сначала проверьте сценарий, термины и ограничения. Красивое переписывание непроверенного объяснения только закрепляет ошибку.

Не игнорировать поддержку

Повторяющиеся вопросы пользователей - лучший источник тем для troubleshooting, FAQ и базы знаний.

Не обещать technical editor без ревью-навыков

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

Что добавить в портфолио технического писателя

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

Пошаговая инструкция

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

API documentation

Опишите endpoint, auth, parameters, request, response, status codes, error examples и working example. В README объясните, как проверяли пример.

Troubleshooting article

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

Release notes

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

Переработка плохого документа

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

Что спрашивают на собеседовании технического писателя

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

Сценарий

Как понять читателя, цель, контекст, ограничения и ожидаемый результат. Частый вопрос: с чего вы начинаете документ?

Текст

Структура, ясность, краткость, предупреждения и примеры. Могут попросить переписать плохой фрагмент и объяснить, почему стало лучше.

Техническая база

API, HTTP, JSON, auth, status codes, Git, Markdown и OpenAPI. Важно не заучить термины, а показать, как проверить пример.

Работа с экспертами

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

Документация

Instruction, API reference, guide, release notes, troubleshooting и база знаний. Проверяют, когда какой формат выбрать.

Docs-as-code

Git, review, versioning, pull requests и публикация. Могут спросить, чем такой процесс лучше папки с файлами.

Качество

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

Примеры вопросов

Чем technical writer отличается от technical editor? Что такое OpenAPI? Что должно быть в error example? Как понять, что статья в базе знаний устарела?

Плюсы и минусы профессии

Плюсы

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

Минусы

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

Кому подойдет

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

Подойдет

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

Не подойдет

  • Если человеку хочется писать свободные тексты без проверки фактов, избегать технических деталей или работать только с готовыми объяснениями, профессия будет тяжёлой.
  • Здесь приходится много уточнять, спорить за точность и отвечать за то, сможет ли читатель выполнить действие по написанному.

FAQ по профессии технический писатель

Кто такой технический писатель простыми словами?

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

Чем занимается technical writer?

Он собирает факты у экспертов, разбирает сценарий читателя, пишет инструкции, API documentation, user guides, release notes, troubleshooting и поддерживает документы после релизов.

Можно ли войти из копирайтинга или редакции?

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

Какие навыки нужны техническому писателю?

Нужны ясное техническое письмо, структура инструкции, интервью с экспертами, проверка сценария, Markdown, Git, Confluence, базовое понимание API, OpenAPI и процесса обновления документации.

Можно ли войти из поддержки?

Да. Поддержка даёт сильное понимание реальных вопросов пользователей. Нужно научиться превращать отдельные обращения в устойчивые инструкции и статьи базы знаний.

Заменит ли AI технических писателей?

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

Что спрашивают на собеседовании?

Спрашивают, как вы начинаете документ, работаете с экспертом, проверяете API, используете Git, обновляете устаревшую статью и оцениваете качество документации.

Сколько зарабатывает технический писатель?

В Москве и МО SkillStat показывает зарплатную оценку 130 000 ₽ на 23.06.2026. Это estimated-оценка по расширенному окну профессии.

Какой документ показать в портфолио?

Покажите пошаговую инструкцию, API documentation, troubleshooting, release notes и переработку плохого документа. К каждому примеру добавьте читателя, задачу и проверку точности.

Куда расти после technical writing?

Можно расти в senior technical writer, docs lead, documentation manager, API documentation, knowledge management, content design, product education или developer advocacy.

Нужен ли английский?

Английский часто нужен для чтения технических материалов, API, интерфейсов и issue tracker. Для международных продуктов он может быть обязательным рабочим языком.

Нужно ли знать ГОСТ?

ГОСТ, ЕСКД, ЕСПД, ГОСТ 19 и ГОСТ 34 важны в регламентированных проектах. Для старта в IT-документации чаще важнее инструкция, API, Markdown, Git и проверка сценария.

Нужно ли знать программирование?

Production-код писать обычно не нужно. Но для API-документации и инженерных продуктов полезно понимать HTTP, JSON, auth, ошибки, Git, CLI, логи и базовый SQL.

Нужно ли знать API?

Для пользовательской справки API может быть не главным. Для API technical writer это обязательная база: endpoint, method, parameters, request, response, status codes, auth и error examples.

Нужно ли знать Git?

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

Нужно ли знать Markdown?

Markdown полезен почти всем техписам: он помогает быстро структурировать документы, README, инструкции и материалы в docs-as-code процессе.

Почему отдельных вакансий мало?

Документацию часто распределяют между аналитиками, поддержкой, разработчиками и product-менеджерами. Отдельная вакансия появляется там, где документация стала частью продукта, внедрения или API.

Чем технический писатель отличается от бизнес-аналитика?

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

Чем технический писатель отличается от поддержки?

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

Чем технический писатель отличается от технического редактора?

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

Чем technical writer отличается от UX writer?

UX writer пишет короткие тексты внутри интерфейса: кнопки, подсказки, ошибки. Technical writer работает с инструкциями, справкой, API, базой знаний и длинными объяснениями.

Что такое API documentation?

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

Что такое docs-as-code?

Docs-as-code - подход, при котором документация хранится и меняется как код: Git, ветки, pull request, review, versioning, changelog, сборка и публикация.

Что такое OpenAPI?

OpenAPI - формат машинно-читаемого описания API. Он помогает описывать методы, параметры, ответы и ошибки так, чтобы по спецификации можно было генерировать документацию и проверки.