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

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

Для этой статьи мы открыли наручники, развязали руки и налили кофе нашему техпису:

Митюнин Даниил

Технический писатель IT Monsters

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

Начнем с самого начала. Технический писатель (он же technical writer, он же инженер по документации, он же «этот парень, который делает pdf‑ки») — это специалист, отвечающий за подготовку, структурирование и поддержку в актуальном состоянии технической документации.

Это может быть что угодно:

• документация по API,

• мануалы для пользователей и админов,

• внутренняя проектная документация,

• инструкции по установке и эксплуатации,

• спецификации, архитектурные описания, баг‑репорты и даже changelog'и.

Если у вас в проекте есть что‑то, что кто‑то когда‑то должен понять — технический писатель уже нужен.

Зачем он вообще нужен? Мы же и сами всё пишем…

Конечно, можно поручить написание документации разработчику. Или тестировщику. Или тимлиду. Или Product Owner»у, если уж совсем туго. Но, как показывает практика, обычно это заканчивается одним из трёх сценариев:

1. «Времени нет, потом напишем.» Документация отсутствует.

2. «Я же написал README, чего вам еще?» Документация на уровне «разберись сам».

3. «Тут всё понятно, просто вызови метод processData и жди чуда.» Документация без контекста и связей.

Вот тут и выходит на сцену технический писатель. Причем не как автор, а как архитектор знания. Он:

• задает неудобные вопросы, которые никто не задал, но стоило бы;

• систематизирует разрозненные знания команды;

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

Технический писатель = Системный аналитик?

А вот тут самое интересное. В реальных проектах технический писатель часто выполняет (добровольно или нет) функции системного аналитика. Почему?

Потому что чтобы грамотно описать систему, нужно:

• понимать бизнес‑логику продукта,

• разбираться в архитектуре,

• понимать взаимосвязи между компонентами,

• видеть, где требования не сходятся с реальностью.

И вот он — технический писатель — садится описывать API и внезапно понимает, что:

• параметр user_type нигде не документирован,

• метод getUserInfo() возвращает 7 разных структур в зависимости от луны в фазе рыб,

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

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

Что теряет проект без техписа?

Вот краткий список того, что начинает сыпаться:

• Коммуникация между командами. Разработчики и тестировщики гадают, кто что имел в виду.

• Потеря экспертизы. Один уволился — и всё, вместе с ним ушло знание о критичном модуле.

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

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

А ещё — невозможно автоматизировать то, что не задокументировано. Без техписа никакие DevOps‑магии и AI‑чаты не спасут.

Когда техпис становится незаменимым?

• Когда проект большой и долгоиграющий.

• Когда есть много интеграций с другими системами.

• Когда команда распределенная и коммуникации идут через документацию.

• Когда заказчик требует формального описания требований.

• Когда нужно готовиться к сертификации или аудиту.

Или, проще говоря, почти всегда.

А может, это просто «писатель», а не «технический»?

Нет. Технический писатель — это не копирайтер. Его задача — не «красиво написать», а точно, структурно и понятно донести суть сложного. А еще он знает, что такое Swagger, JSON Schema, UML, Markdown, Git и REST API. И умеет с этим жить.

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

Скорее всего — технический писатель. Тот самый человек, который сидел в углу, задавал «глупые вопросы» и описывал, как на самом деле работает ваша система.

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

Без него — хаос, мифы, и три разных README в трёх разных ветках.