Технический писатель в IT нужен командам с кодом, API и процессом релиза, а не «человеку, который умеет писать тексты». Вакансии закрывают те, у кого в портфолио документы, которыми уже можно пользоваться: гайд по запуску, описание метода API, runbook, статья «как сделать X» без воды. Эссе, копирайт лендинга и диплом филолога сами по себе слот не открывают.
В 2026-м русскоязычные команды ищут техписов в продукт, аутсорс и внутренние платформы. Ниже — какие документы собрать, как не путать роль с контент-маркетингом и где искать вход без мифа «сначала сертификация technical communication».
Коротко:
- Портфолио = 3–5 рабочих документов под одну предметку, не «пишу легко и грамотно».
- Нужно читать код и тикеты на уровне «понял, что изменилось», не обязательно быть разработчиком годами.
- Сертификаты техкомму не заменяют гайд, который можно пройти по шагам.
- Не целитесь сразу в docs-as-code платформы FAANG без одного целого руководства.
- Ищите задачи (документация API, пользовательские гайды, релиз-ноты), не слово Writer в маркетинге.
Кому этот вход подходит — и кому нет
Подходит, если вам не скучно превращать чужой черновик в шаги, которые проходит человек без контекста. Сильный смежный старт: поддержка с базой ответов, QA с тест-кейсами, перевод технички, сильный README в учебном репозитории. Слабый старт: только копирайт лендингов и диплом филолога без одного getting started.
Не подходит, если вы хотите «писать легко» без чтения тикетов и без вопросов инженеру. Не подходит вакансия блога «про IT» как замена документации продукта: другой конкурс, другие KPI. Не подходит роль, где просят сорок страниц бесплатно «на испытательный срок до договора» — это работа без оплаты, не портфолио.
Нужно запускать продукт по своей же инструкции. Если сами спотыкаетесь на шаге 3, документ сырой, новые инструменты не начинайте. Созвоны с разработкой — часть работы, даже на удалёнке. «Без звонков» обычно противоречит снятию знаний.
Чем техписатель не является
Не копирайтер продукта. Не SMM. Не переводчик без понимания предмета — хотя перевод технички бывает частью работы. Не «человек, который оформит Confluence, потому что разработчикам лень»: иногда так и есть, но нанимают за ясность и структуру, не за шрифты.
Соседние роли: аналитик, который пишет постановки (это БА или системный аналитик), QA, который пишет тест-кейсы. Если вам ближе критерии приёмки, чем гайд пользователя — не маскируйтесь под техписателя. Если ближе код — часть входа в разработку с сильным README тоже валидна, но заголовок другой.
Какие документы работают в портфолио
Одна предметка. Учебный сервис, открытый инструмент, процесс, который вы знаете. Набор:
- Getting started. Человек без контекста доходит до первого успешного шага. Засеките время: если сами путаетесь — документ сырой.
- How-to на одну задачу. Не обзор «всё о продукте».
- Справочник. Метод API, параметр, ошибка, пример запроса. Или таблица статусов.
- Changelog / релиз-ноты на учебную версию: что изменилось для пользователя, не «рефакторинг».
- Короткий стиль-гайд на страницу: как вы называете кнопки, как пишете предупреждения.
Публикуйте так, чтобы открывалось без пароля: репозиторий docs, статический сайт, PDF только если вёрстка важна заказчику. Google Drive с «док_финал_3» — плохой сигнал.
Не прикладывайте курсовые по литературе. Не прикладывайте NDA-документы с работы. Перепишите учебный аналог с вымытыми данными.
Перед откликом сами пройдите getting started с чистого профиля: новый браузер, нет ваших подсказок. Засеките, где остановились. Каждая остановка — правка документа, не «пользователь невнимательный». Если гайд требует созвона с автором, в портфолио его рано класть. Рекрутер почти никогда не будет созваниваться, чтобы понять ваш текст: либо шаги работают, либо файл не открыли дальше оглавления.
Какие навыки реально спрашивают
Русский (или английский — по рынку вакансий) без канцелярита. Умение задать инженеру пять точных вопросов вместо двадцати расплывчатых. Markdown, Git на уровне «PR с правкой доки». Понимание, что такое версия, окружение, breaking change.
Английский: для русскоязычной доки — чтение исходников и тикетов. Для англоязычной команды — письмо на языке продукта, без машинного пафоса. Не смешивайте языки в одном абзаце «для солидности».
Инструменты: Sphinx, Docusaurus, MkDocs, Confluence — берите один, в котором лежит портфолио. Не список из двенадцати CMS в навыках. Docs-as-code — плюс, если вы им пользуетесь, не если слышали термин.
Сертификат STC / «технический писатель 72 часа» не работа. Он может дать словарь. Портфолио даёт оффер чаще. Не ставьте курс в заголовок вместо ссылки на getting started. Рекрутер проверяет шаги документа, не номер удостоверения. Если после курса нет ни одного гайда, который проходит без вас, курс ещё не стал входом.
Пример 1. 90 дней из смежной роли
Исход: поддержка, QA, перевод, сильный README в учебном проекте. Цель — junior / middle-minus technical writer.
- Месяц 1. Выберите продукт (свой или открытый). Напишите getting started и how-to. Попросите человека со стороны пройти шаги, зафиксируйте, где споткнулся, исправьте.
- Месяц 2. Справочник на 8–12 страниц или эквивалент API. Changelog. Репозиторий с историей коммитов, не один файл «всё в одном».
- Месяц 3. Резюме: технический писатель / гайды и API docs. Отклики на IT-документацию, не на контент-маркетинг. В письме — ссылка на getting started, не на «портфолио текстов про HR».
Критерий: незнакомый человек доходит до успеха по вашей инструкции без созвона с вами. Пока это не так, новый инструмент не начинайте.
Пример 2. Письмо и фрагмент getting started
Вакансия: technical writer, документация сервиса, Markdown/Git, работа с разработкой, русский язык.
Откликаюсь на роль технического писателя (гайды и справочник сервиса).
По вакансии нужно вести документацию рядом с релизом и не оставлять «разработчик сам допишет». Собрал учебный комплект по сервису заказов: getting started (первый успешный заказ за 10 минут по шагам), how-to «отмена», справочник статусов, релиз-ноты v0.2. Репозиторий: [ссылка]. Коммерческого техписа в штате нет; есть год поддержки — оттуда привычка писать так, чтобы не переспрашивали одно и то же.
Готов тестовое: гайд по вашему публичному сценарию на 1–2 страницы на этой неделе.
Фрагмент, который стоит иметь в портфолио (учебный):
Цель: создать тестовый заказ. Нужны: аккаунт, ключ API из кабинета. Шаг 1 — … Шаг 2 — … Ожидаемый результат: статус «создан» в списке. Если видите 401 — проверьте ключ, не повторяйте запрос пачкой. Чего документ не покрывает: прод-оплаты.
Это язык работы, не «наш продукт позволяет клиентам эффективно…». Черновик письма: cover-letter.