Данные из 17вакансий · 12 августа 2026

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

Как стать техническим писателем: путь от нуля до первого оффера

Не «стань разработчиком за 3 месяца» — реальный путь входа на основе данных по 17 вакансий.

Мурадов ЮрийАвтор·Мурадов Юрий·Аналитик SkillStat
ИАПроверено·Игорь Антонов·Технический редактор·Senior technical writer / documentation lead
Junior-вакансий сейчас
3
18% от всех 17 вакансий
Сложность входа
Низкая
18% junior-вакансий
Senior / Junior+Intern
3.3x
На каждого junior+intern — 3.3 senior
Навыков / вакансия
5
медиана по вакансиям
Всего вакансий
17
активных в Москве
Можно ли с нуля Короткий план Roadmap Junior-рынок Портфолио Резюме Собеседование Ошибки Обучение FAQ

Можно ли стать техническим писателем с нуля

Да. По данным SkillStat, 18% вакансий технического писателя — уровня junior или стажёр. Это 3 вакансии прямо сейчас.

«С нуля» для технического писателя — это без коммерческого опыта, но не без навыка объяснять. К первому отклику нужны: инструкция, по которой незнакомый человек дошёл до результата и не застрял; умение задать эксперту точный вопрос вместо «расскажите, как это работает»; Git на уровне ветки и правки по замечаниям; понимание, что документ живёт после релиза. Медиана требований — 5 навыков: список короткий, и это ловушка — за коротким списком стоит длинная проверка на понятность.

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

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

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

01
Инструкция на действии
Возьми функцию, которой пользуешься, и опиши путь: цель, условия, шаги, результат, что делать при ошибке. Проверка одна: незнакомый человек проходит сценарий и не задаёт тебе вопросов.
02
Структура под читателя
Разработка технической документации — в 23.5% вакансий технического писателя, пользовательской — в части. Формат идёт от задачи: инструкция, справка, база знаний и материалы к релизу — разные документы, а не разный объём.
03
Вопросы к эксперту
Учись спрашивать про условия, ограничения, версии, права доступа и исключения. «Расскажите, как работает» даёт пересказ кода. «Что произойдёт, если у пользователя нет прав» даёт абзац.
04
Git и docs-as-code
Git — в 17.6% вакансий технического писателя, CI/CD — в части. Ветка, правка по замечаниям, история версий: документация живёт рядом с кодом, и ревью текста работает как ревью кода.
05
ГОСТ и портфолио
ГОСТ 34 — в 17.6% вакансий, ГОСТ 19 — в 17.6%, ЕСКД — в 17.6%. Разберись, где документ пишется по регламенту, а где по задаче читателя. Дальше — портфолио из разных форматов.

Что учить техническому писателю первым

Не всё сразу. Вот очерёдность по частотности в вакансиях — от самого нужного к менее срочному.

Полный список навыков с частотностью, связками и зарплатной премией — навыки технического писателя →

Roadmap технического писателя: от нуля до junior

Порядок опирается на частотность навыков по данным вакансий. Первые 4–5 этапов — минимум для первого оффера.

  1. 01
    Инструменты документирования

    Confluence, Notion, GitLab Wiki, Markdown — публикация и поддержка технической документации.

    Подробнее →
  2. 02
    Техническая документация 35.3% вакансий

    ГОСТ, user manual, API-документация, архитектурные описания, release notes.

  3. 03
    Git и процесс review 17.6% вакансий

    Ветки для доков, pull request с review, CI-публикация документации (MkDocs, Docusaurus).

    Подробнее →
  4. 04
    Linux и CLI

    Базовые команды терминала, понимание окружения разработчика, работа со скриптами.

    Подробнее →
  5. 05
    Инструменты задач

    Jira для ведения задач на документацию, Python для автоматизации генерации доков.

    Подробнее →

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

Срез построен на 17 активных вакансий.

Junior-вакансий
3
inc. стажировки
Доля junior
18%
от всего рынка
Senior / Junior+Intern
3.3x
соотношение
Навыков / вакансия
5
медиана
Распределение вакансий по грейдам
Junior — 20% (3)
Middle — 13.3% (2)
Senior — 66.7% (10)
Что значат эти цифры. 3 вакансии уровня junior из 17 — вход доступный. Особенность роли: вакансия технического писателя закрывается портфолио быстрее, чем опытом. Работодателю нечего проверять, кроме текста, — и текст он проверяет за пять минут. Второй вход шире: поддержка, тестирование, аналитика и внедрение, где документацию пишут между делом. Оттуда переход внутрь короче, чем снаружи по отклику.

Какие проекты сделать для портфолио

Портфолио технического писателя — это сам текст, и проверяется он мгновенно. Главный экспонат — кусок документации до и после твоей правки с объяснением, почему стало понятнее. Не «стало красивее»: конкретно — какой шаг читатель пропускал, какое условие не было названо, где термин менялся по дороге.

Переписанный кусок документации: до и после
Лёгкая–средняя · 1 неделя
Стек: Разработка технической документации, техническая документация, draw.io
GitHub: Три файла: исходный текст, переписанный и разбор — что было непонятно, что изменил, почему так понятнее
Ценность: Главный артефакт роли: показывает не стиль, а мышление — видно, что ты нашёл дыру, которую автор не заметил
Инструкция, проверенная на живом человеке
Лёгкая–средняя · 1 неделя
Стек: Разработка пользовательской документации, Confluence, Jira
GitHub: Инструкция плюс протокол проверки: где читатель застрял, что переписал после этого
Ценность: Разработка пользовательской документации — в части вакансий: единственное доказательство понятности — чужие руки
Описание API: метод, ошибки, пример
Средняя · 1–2 недели
Стек: Git, Linux, техническая документация
GitHub: Описание метода: назначение, параметры, обязательность, пример запроса и ответа, коды ошибок и что делать по каждому
Ценность: Разработчики читают документацию иначе: им нужен пример, который работает, и честный список ошибок
Документ по ГОСТ 34
Средняя · 1–2 недели
Стек: гост 34, гост 19, ЕСКД, разработка технических заданий
GitHub: Раздел технического задания по структуре ГОСТ 34 и короткий разбор: что регламент требует и зачем
Ценность: ГОСТ 34 — в 17.6% вакансий технического писателя, ЕСКД — в 17.6%: обойти регламент на отклике не получится
База знаний для поддержки
Средняя · 1–2 недели
Стек: Confluence, Разработка внутренней документации, Jira
GitHub: Несколько статей по частым обращениям плюс правила: как называем термины, когда заводим новую статью, кто обновляет после релиза
Ценность: Разработка внутренней документации — в части вакансий, Confluence — в части: внутренние материалы — самый частый первый заказ

Как оформить GitHub и резюме

Профиль GitHub
  • Портфолио писателя — это текст, и он должен открываться в один клик: публичный репозиторий, страница в Confluence или PDF. Не архив по запросу
  • Кусок «до и после» — главный экспонат: исходник, правка и разбор, почему стало понятнее
  • Git — в 17.6% вакансий технического писателя: веди портфолио в репозитории, история коммитов сама покажет, что ты работаешь по замечаниям
  • Схемы — через draw.io: картинка в README, исходник рядом
  • В README портфолио — оглавление по форматам: инструкция, описание API, регламентный документ, база знаний. Работодатель ищет свой формат
  • Если текст с работы — перепиши: убери названия продуктов и заказчиков, оставь структуру и приёмы
Резюме без коммерческого опыта
  • Резюме технического писателя читают как рабочий образец: если в нём канцелярит и обороты вроде «производилась разработка документации», дальше можно не смотреть
  • Раздел «Работы» вместо «Обязанности»: ссылка на текст ценнее любого описания
  • По каждой работе: кто читатель, какую задачу он решает, что было не так до тебя, что изменил
  • Навыки — только рабочие: техническая документация, Разработка технической документации. «Владею Confluence» без текста в портфолио читается как ноль
  • Опыт из смежной роли — валюта: поддержка, тестирование, аналитика, внедрение. Ты уже объяснял продукт людям, которые его не понимают
  • Назови домен: ГОСТ 34 — в 17.6% вакансий технического писателя, и регламентированная документация — это другой мир, чем документация для разработчиков
Слабое резюме

«Писал техническую документацию, владею Confluence и Markdown, знаком с Git, грамотный русский язык»

Сильное резюме

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

Самостоятельно, курсы или вуз — какой путь выбрать

Самостоятельно
Тренироваться можно на любой документации: берёшь чужую инструкцию, проходишь по ней и переписываешь то, на чём застрял. Материал бесконечен и бесплатен
Тебе будет казаться, что стало понятнее. В одиночку это не проверить — нужен чужой человек и его руки
Если есть на ком проверять текст и хватает дисциплины отдавать его на разбор
Курсы с ментором
Разбор твоего текста редактором — единственное, что реально ускоряет: он покажет пропущенное условие и термин, который поехал
Дорого; часть программ учит инструментам и стилю, но не трогает ГОСТ и работу с экспертом — то есть самое сложное
Если проверять текст не на ком и обратной связи взять негде
Вуз / колледж
Техническое образование помогает разбираться в продукте, филологическое — в языке и структуре. Работают оба
Профессии не учат ни там, ни там: техническое письмо собирается из практики и правок
Если выбираешь первое образование — бери то, где есть инженерная или языковая база, а профессию добирай текстами
Ловушка технического письма: «мне понятно — значит, понятно». Ты знаешь продукт, пока пишешь, и пропускаешь шаг, который читателю неочевиден: включённый флаг, права администратора, версию, где кнопка называется иначе. В голове это не проверяется. Единственный работающий приём — отдать текст человеку не из команды и молча смотреть, где он остановится. Вторая ловушка рядом: писать красиво. Платят за то, чтобы читатель дошёл до результата, а не за слог.

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

Структура и читатель
Типовые вопросы
  • ·Как поймёшь, для кого пишешь
  • ·Чем инструкция отличается от справки
  • ·С чего начинается документ: с описания системы или с задачи читателя
  • ·Как проверишь, что текст понятен
Как показать проектом

Кусок «до и после»: объясни, какой шаг читатель пропускал

Работа с экспертом
Типовые вопросы
  • ·Разработчик отвечает «там всё очевидно» — твои действия
  • ·Какие вопросы задашь про новую функцию
  • ·Эксперт занят и переносит встречу третий раз
  • ·Как проверяешь, что понял правильно
Как показать проектом

Инструкция из портфолио: расскажи, что уточнял у эксперта

Git и процесс
Типовые вопросы
  • ·Git — в 17.6% вакансий технического писателя: зачем он писателю
  • ·Что такое ветка и правка по замечаниям в документации
  • ·CI/CD — в части вакансий: что происходит с документом при сборке
  • ·Как документация связана с релизом и кто отвечает за её актуальность
Как показать проектом

Репозиторий портфолио: покажи историю правок по одному тексту

ГОСТ и регламент
Типовые вопросы
  • ·ГОСТ 34 — в 17.6% вакансий технического писателя: что он регламентирует
  • ·Чем ГОСТ 19 отличается от ГОСТ 34
  • ·Зачем ЕСКД, если есть здравый смысл
  • ·Как писать по регламенту и остаться понятным
Как показать проектом

Документ по ГОСТ: покажи, где регламент помог, а где мешал

Поддержка документа
Типовые вопросы
  • ·Релиз вышел, интерфейс поменялся — как узнаёшь
  • ·Что делать с документом, который расходится с продуктом
  • ·Как ведёшь термины, чтобы они не менялись по дороге
  • ·Что записываешь в материалы к релизу
Как показать проектом

База знаний из портфолио: покажи правила терминов

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

Минимум
4–7 мес
С опытом рядом с продуктом: поддержка, тестирование, внедрение — ты уже объяснял продукт людям
Медиана
8–12 мес
Самостоятельно, с нуля, с портфолио из разных форматов вместо конспектов
Реалистично
12–18 мес
При совмещении с работой и без человека, на котором можно проверять понятность текста

Почему «писать я умею» не равно «работа через месяц». Грамотность — входной билет, а не профессия. Дальше идёт то, что тренируется только правками: увидеть пропущенное условие, развести термины, построить документ от задачи читателя, а не от устройства системы. Медиана требований — 5 навыков, и короткий список тут не облегчение: проверять будут текстом.

Скорость решают три вещи: есть ли на ком проверять понятность, отдаёшь ли ты текст на разбор регулярно и берёшь ли форматы, которые страшно брать, — описание API и документ по ГОСТ. Именно они закрывают вакансии.

Ошибки новичков

Пишут от устройства системы

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

Как исправить: Начинай с задачи: что человек хочет сделать, что для этого нужно, какие шаги, как понять, что получилось

Не проверяют текст на человеке

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

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

Задают эксперту общие вопросы

Почему мешает: «Расскажите, как это работает» даёт пересказ кода. Условия, ограничения и исключения так не всплывают — а из них состоит половина документа

Как исправить: Спрашивай точечно: что произойдёт при недостатке прав, какая версия, что если поле пустое, где увидим ошибку

Считают ГОСТ пережитком

Почему мешает: ГОСТ 34 — в 17.6% вакансий технического писателя, ГОСТ 19 — в 17.6%, ЕСКД — в 17.6%. Отказ от регламентированной документации заметно сужает выбор вакансий

Как исправить: Разберись со структурой хотя бы одного документа по ГОСТ 34 и положи его в портфолио

Пропускают Git

Почему мешает: Git — в 17.6% вакансий технического писателя, CI/CD — в части. Документация всё чаще живёт рядом с кодом, и писатель без ветки и правки по замечаниям выпадает из процесса

Как исправить: Минимум: ветка, коммит, правка по замечаниям, история версий. Веди в этом своё портфолио — заодно и тренировка

Пишут красиво

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

Как исправить: Простая проверка: убери предложение. Если смысл не пострадал — оно было лишним

Бросают документ после публикации

Почему мешает: Продукт меняется, и документация, которая расходится с реальностью, хуже её отсутствия: она врёт с уверенным видом

Как исправить: Свяжи документ с релизом через Jira и сверяй текст после каждого выпуска

Термины плывут по тексту

Почему мешает: «Учётная запись», «профиль» и «аккаунт» в одном документе — это три сущности для читателя, даже если для тебя одна

Как исправить: Заведи список терминов до того, как начнёшь писать, и не отступай от него — даже когда хочется разнообразия

Портфолио из одного формата

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

Как исправить: Собери разные: инструкцию, описание метода API, документ по ГОСТ и раздел частых ошибок

Как SkillStat считает данные

Источник: 17 вакансий в московском сегменте. Навыки и грейды извлекаются автоматически из текста каждой вакансии.

Грейды: определяются по требованиям вакансии — уровню опыта, упоминанию «junior», «intern», «стажёр». Это рыночная оценка объявления.

Сложность входа: рассчитывается по доле junior-вакансий и медиане навыков на junior-уровне. Это индикатор, а не гарантия.

Обновление: данные пересчитываются регулярно. Текущий срез — 12 августа 2026.

Частые вопросы

Можно ли стать техническим писателем с нуля?
Да, и это одна из немногих IT-ролей, где вход не требует программирования. По данным SkillStat, junior и стажёров среди вакансий технического писателя — 3 из 17. Берут за портфолио: инструкцию, по которой посторонний человек дошёл до результата, и кусок документации «до и после». Технического образования обычно не требуют, а разобраться в продукте — требуют всегда.
Нужно ли программировать техническому писателю?
Нет. Нужно читать и понимать: Linux — в части вакансий технического писателя, и это про документацию для администраторов — командная строка, конфигурация, журналы. Писать код не придётся, а вот пройти сценарий самому, посмотреть ответ сервиса и разобрать ошибку — придётся, иначе документ пишется с чужих слов.
Нужен ли Git?
Да, и это главное отличие роли от «пишу тексты». Git — в 17.6% вакансий технического писателя (3 из 17), CI/CD — в части. Документация всё чаще живёт рядом с кодом: ветка, правка по замечаниям, история версий, сборка при релизе. Глубина нужна небольшая — уровень «веду свои тексты в репозитории» закрывает почти всё.
Что такое docs-as-code и обязательно ли это?
Подход, при котором документация лежит в репозитории рядом с кодом и живёт по правилам кода: ветка, ревью, версии, автоматическая сборка. Git — в 17.6% вакансий технического писателя, CI/CD — в части, так что для продуктовых команд это норма. Для регламентированной документации — реже. Обязательным подход делает не мода, а то, что иначе документ отстаёт от продукта.
Нужны ли ГОСТ 34 и ЕСКД?
Для заметной части рынка — да. ГОСТ 34 — в 17.6% вакансий технического писателя, ЕСКД — в 17.6%, ГОСТ 19 — в 17.6%. Это документация для инженерных, корпоративных и государственных продуктов: там структура документа задана регламентом, а не твоим вкусом. Учить наизусть не нужно — нужно один раз пройти документ по структуре и понять логику разделов.
Чем ГОСТ 19 отличается от ГОСТ 34?
Предметом. ГОСТ 19 — про программную документацию, то есть про саму программу. ГОСТ 34 — про автоматизированные системы целиком: техническое задание, документация на систему, её части и эксплуатацию. На практике чаще спрашивают ГОСТ 34: он в 17.6% вакансий технического писателя против 17.6% у ГОСТ 19. ЕСКД (17.6%) добавляется там, где рядом есть железо.
Чем технический писатель отличается от копирайтера?
Целью текста. Копирайтер должен убедить, писатель — довести читателя до результата так, чтобы тот не застрял. Здесь метафора мешает, а красивый слог — лишний шаг для человека, который спешит. Проверка тоже разная: у копирайтера — отклик, у писателя — прошёл ли посторонний человек сценарий без вопросов.
Чем технический писатель отличается от системного аналитика?
Направлением работы. Аналитик описывает, как система должна работать, — до того, как её сделали. Писатель объясняет, как ей пользоваться, — после. Пересечение есть: разработка технических заданий встречается в части вакансий технического писателя, и в регламентированных проектах писатель часто ведёт ТЗ. Но читатель разный: у аналитика — команда, у писателя — пользователь или администратор.
Нужны ли Confluence и Jira?
Учить отдельно нечего: Confluence — в части вакансий технического писателя, Jira — в части. Это рабочие поверхности. Ценность не в кнопках: по Confluence видно, умеешь ли держать базу знаний в состоянии, где статью можно найти, а по Jira — связана ли документация с релизами и задачами. Заведи бесплатный аккаунт и веди в нём портфолио.
Какое образование нужно?
Любое, и это не фигура речи. Техническое помогает разбираться в продукте, филологическое — в структуре и языке. Требуют другое: портфолио и умение задать эксперту точный вопрос. Гуманитарий с инструкцией, проверенной на живом человеке, обходит инженера, который пишет «мне же понятно».
Можно ли перейти в техническое письмо из другой профессии?
Это основной путь. Поддержка, тестирование, аналитика, внедрение, преподавание — везде ты уже объяснял продукт тем, кто его не понимает. Не хватает обычно только формы: структура под читателя, Git, работа с экспертом, регламенты. Переход внутри своей компании проще всего: продукт ты знаешь, эксперты сидят рядом.
Какие проекты сделать для портфолио?
Три разных формата, а не пять одинаковых инструкций: кусок документации «до и после» с разбором, инструкция, проверенная на постороннем человеке, и что-то из страшного — описание API или документ по ГОСТ 34. Используй ключевые навыки профессии: техническая документация, Разработка технической документации, ЕСКД. Портфолио должно открываться в один клик, иначе его не откроют вовсе.
Как показать «до и после», если работал только с учебными текстами?
Бери чужую документацию. Возьми инструкцию к любому сервису, пройди по ней сам, отметь, где застрял, и перепиши. Разбор важнее самой правки: какой шаг был пропущен, какое условие не названо, где термин поехал. Открытые проекты дают ещё один вариант — правка их документации через открытый вклад, и это уже подтверждаемая работа.
Сколько времени нужно, чтобы стать техническим писателем?
Медиана — 8–12 месяцев при самостоятельном обучении с портфолио. С опытом рядом с продуктом (поддержка, тестирование, внедрение) — 4–7 месяцев: продукт и вопросы пользователей уже знакомы. Грамотность при этом в срок не входит — она входной билет.
Когда начинать откликаться?
Когда портфолио открывается по ссылке и в нём есть три формата, включая кусок «до и после». Junior-позиций 3 вакансии — параллельно смотри поддержку, тестирование и внедрение в компаниях с документацией: оттуда переход внутрь короче. И не пропускай тестовые задания: здесь они решают больше, чем резюме.
Что писать в резюме без коммерческого опыта?
Работы как опыт: кто читатель, какую задачу он решает, что было не так до тебя, что изменил. Инструменты — только рабочие: техническая документация, Разработка технической документации. И следи за языком самого резюме: его читают как образец текста. Канцелярит в сопроводительном закрывает вопрос раньше, чем откроют портфолио.
Что спрашивают на собеседовании?
Структуру под читателя, работу с экспертом, Git и процесс обновления, ГОСТ — если продукт регламентированный. Почти всегда есть тестовое: дают функцию или сырой текст и смотрят, что ты с ним сделаешь. Подробнее — в разделе «Собеседование» на этой странице.
Сколько зарабатывает начинающий Технический писатель?
Ориентир для junior — 54 000–78 000 ₽ при медиане по профессии 120 000 ₽. Разбивка по грейдам и динамика — на странице зарплат технического писателя.
Где посмотреть навыки технического писателя?
На странице навыков технического писателя — частотность по 17 вакансий, разбивка по грейдам и связки инструментов.