Tech Writer

Кто это и зачем нужен

Tech Writer делает знание о продукте доступным: ясная документация, гайды, API-референс, release notes. Его миссия — чтобы продукт и систему было легко понять и использовать, без боли «разберись сам по коду». Технический писатель переводит сложное в понятное и пишет так, чтобы читатель достиг цели за минимум времени.

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

Что ломается без него: устаревшие/отсутствующие доки, разнобой терминов, нечитаемый API-референс, мучительный онбординг, рост нагрузки на поддержку и инженеров (отвечают одно и то же).

День из жизни

Утро. Берёт фичу/API для документирования. Разбирается, как это работает (читает код/спеку, говорит с инженером), определяет аудиторию и её задачу. День. Пишет: структурирует от задачи читателя (не от структуры кода), добавляет примеры, проверяет на реальном сценарии («пройди по своей же инструкции»). Держит единый стиль и терминологию (глоссарий). Вечер. Обновляет release notes, переводит RU/EN, чистит устаревшее, проверяет консистентность терминов и ссылок. Собирает обратную связь: что осталось непонятным.

Ключевые навыки

Hard: ясное письмо (plain language), структурирование информации, docs-as-code (Markdown, Git), API-документирование (OpenAPI), чтение кода, стиль-гайды и терминология, основы информационной архитектуры доков, RU/EN. Soft: эмпатия к читателю (что он знает/не знает), умение упрощать сложное, любознательность, работа с инженерами, внимание к точности и деталям.

Артефакты, которые пишет

• Docs / гайды — как пользоваться, онбординг.
• API reference — точное описание интерфейса.
• README — точка входа в проект.
• Release notes — что изменилось (в паре с Release Manager).
• Глоссарий — единая терминология. Связан с разделом «📚 Гайды» базы (гайды как markdown-шаги); опирается на User Story (понять задачу читателя) и спецификации.

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

1. Черновик доков из кода/спеки. Промт: «По этому коду/спеке <вставить> напиши пользовательскую документацию для аудитории <…>: что это, как использовать, примеры, частые ошибки. Структурируй от задачи читателя.»
2. API-референс. Промт: «Сгенерируй справочник по этому API <…>: эндпоинты, параметры, примеры запроса/ответа, коды ошибок. Единообразно.»
3. Перевод RU/EN. Промт: «Переведи эту документацию <…> на английский: сохрани термины из глоссария <…>, технически точно и естественно.»
4. Проверка ясности/терминов. Промт: «Проверь этот текст <…> на ясность, канцелярит, неоднозначность и расхождение терминов с глоссарием <…>. Перепиши проблемные места.»
5. Примеры и сниппеты. Промт: «Сгенерируй 2–3 практических примера использования <фичи/API> с кодом и пояснением, для уровня <новичок/про>.»

Путь развития: Junior → Middle → Senior → Lead

• Junior: пишет/обновляет доки по шаблону под присмотром, осваивает стиль и инструменты.
• Middle: самостоятельно документирует фичи/API, держит стиль и терминологию, работает с инженерами.
• Senior: проектирует структуру документации продукта, ставит docs-процессы, наставляет, влияет на DX.
• Lead / Docs Lead / Head of DocOps: отвечает за документацию и её процесс на продукт/компанию, стандарты, инструменты.

Частые ошибки и как избежать

• Документ от структуры кода, а не задачи читателя. → Пиши от того, что читатель хочет сделать.
• Канцелярит и сложность. → Plain language: короткие фразы, простые слова, активный залог.
• Устаревшие доки. → Docs-as-code рядом с кодом, обновляй в одном PR; устаревшая дока хуже, чем никакой.
• Нет примеров. → Примеры и сниппеты — читатели учатся на них быстрее, чем на абстракциях.
• Разнобой терминов. → Глоссарий и единый стиль; один термин = одно значение во всех доках.

Что освоить (мини-программа)

• Концепции: plain language, структурирование от задачи (task-based), docs-as-code, информационная архитектура, стиль-гайды, DX (developer experience), Diátaxis (типы доков).
• Инструменты: Markdown, Git, статические генераторы (Docusaurus/MkDocs), OpenAPI/Swagger, Vale (линтер стиля).
• Почитать: «Docs for Developers»; Google/Microsoft Style Guide; фреймворк Diátaxis (diataxis.fr); «The Product is Docs».

Зарплатные ориентиры (RU)

• Junior Tech Writer: ~80–140 тыс ₽/мес.
• Middle Tech Writer: ~140–220 тыс ₽/мес.
• Senior Tech Writer: ~220–330 тыс ₽/мес.

  Зависит от грейда, технической глубины, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Отдельного mapsTo нет: документация по итогам в доме — часть фазы Deliver конвейера Quest (отчёт + обновление docs/JOURNAL). House-rule «доки обновлены» входит в Definition of Done. Под документные форматы у дома есть скиллы docx/xlsx/pdf/pptx; раздел «📚 Гайды» базы — это и есть продуктовая документация в формате markdown-шагов.

🤖 Промт-персона

Ты — опытный технический писатель. Помогаешь мне делать знание о продукте доступным через ясную документацию. Всегда сначала определи аудиторию и её задачу, и структурируй текст от того, что читатель хочет сделать (task-based), а не от структуры кода. Пиши plain language: короткие фразы, простые слова, активный залог, без канцелярита. Добавляй практические примеры и сниппеты — на них учатся быстрее. Держи единую терминологию (глоссарий) и единый стиль. Документацию держи рядом с кодом и актуальной — устаревшая дока хуже отсутствующей. По запросу выдавай доки из кода/спеки, API-референс, перевод RU/EN и проверку ясности.