Технический писатель — это такой человек, который знает всё о продукте, которого ещё нет, и пишет документацию, которую никто не читает. Красиво, да? Но больно.
Вдохновение для этой статьи мы черпали на конференции Techwriter Days 2, где технические писатели делились с нами своими реальными переживаниями и проблемами, с которыми сталкиваются в своей работе. Это было не просто обсуждение теории, а откровенные истории о трудностях, связанных с дедлайнами, отсутствием данных, постоянными правками и недостаточным вниманием к их труду.
Мы просто спросили “как дела”, а они рассказали всё
Если бы техписы могли встать и громко закричать — их бы наконец услышали. Но они молча сидят в Confluence и ревут по ночам, пока пишут документацию на фичу, которую релизнули два дня назад (без документации, конечно).
Мы собрали честные ответы от техписов — что их раздражает, демотивирует и заставляет задуматься о дауншифтинге и жизни на Бали. Всё по-настоящему.
Сводка страданий — топ боли
Темы, которые повторялись чаще всего:
- Док нужен вчера, продукта нет, но оцени срочно
- Всё в головах разработчиков (а головы — в отпуске)
- “Напиши как-нибудь, доделаем когда-нибудь”
- Один ты пишешь, тестируешь, вычитываешь и страдаешь
- Дока прекрасна, но никто её не читает
- Форматирование — это ад. Confluence — это ад с багами.
Разберём чуть подробнее
«Док нужен вчера»
Классика. К тебе приходят в пятницу вечером с запросом: “Нам нужна дока до понедельника. Ну, ничего сложного. Просто опиши всё.” Ты открываешь продукт — а его нет. Или он есть, но другой.
«Знания в головах»
Разработчик: “Ну, я всё рассказал на митинге. Там понятно.”
Ты: открывает Notepad и включаешь запись: «…ну вот тут как бы понятно… ну ты там опиши как-нибудь… ну типа…». И ты сидишь, как дешифровщик НЛО.
«Док никто не читает»
Ты вылизал каждую запятую. Потратил 3 дня на согласование формулировки «нажмите на кнопку». А потом тебе говорят: “Ой, а у нас свой текст. Мы его уже в релиз засунули. Твой не читали.”
«Автор vs проверяющий: финал сезона»
Три круга правок. Один и тот же коммент на 4 страницы:
“А давайте перепишем это предложение?”
«Зачем?»
«Ну просто.»
«Один в поле воин»
Ты — единственный техпис в компании. У тебя 3 проекта, 5 продуктов, 7 чатов и вечный вопрос:
“А когда будет готово?”
А ты уже не помнишь, когда ел.
Но это не просто нытьё
Это — последствия системных проблем:
- Нет процесса. Техписа подключают, когда всё уже сгорело.
- Нет данных. Всё держится на личных связях с разработчиками.
- Нет времени. Зато есть срочные задачи “на часик”.
- Нет уважения к профессии. Док — это ведь “чтобы галочка была”.
Что с этим делать
Для команд, где есть техписы:
- Подключайте техписов с начала проекта. Нет, не “вот вам релиз-ноуты, а теперь пиши”. А прям с дизайна, обсуждений и первых черновиков. Документация — это не “финальный штрих”, это часть продукта. Чем раньше техпис в контексте, тем: меньше недопониманий, меньше “а чё ты не знал?” и боли у всех участников процесса.
- Делитесь знаниями. Техпис не экстрасенс. Если что-то есть — покажите. Если ничего нет — скажите честно. Базовый набор полезностей:
- Схемы архитектуры, даже на салфетке
- Скриншоты, мокапы, кликабельные прототипы
- Переписка с клиентом, где “объясняли, как работает”
- Да хоть голосовое, где кто-то быстро объясняет суть. Всё лучше, чем “ну там понятно, пиши как хочешь”.
- Давайте время. Док — это не Ctrl+C / Ctrl+V из требований. Это аналитика, синтез, структура, слова, термины, визуал. Оставьте в планировании время на доку. Не “прикрутим в последнюю ночь”, а “заложим фазу на подготовку, написание и вычитку”. Хотите, чтобы документация работала — дайте ей дышать.
Для техписов (список, который вы и так знаете, но всё равно):
- Показывайте свою ценность. Не ждите, что вас поймут “по умолчанию”. “Я просто пишу текст” — плохой питч. “Я делаю информацию доступной” — гораздо ближе к сути. Рассказывайте как вы сокращаете обращения в поддержку, как ускоряете онбординг, как помогаете продавать (серьёзно, дока — это UX + маркетинг). Внутренняя “техпис-евангелизация” — штука мощная.
- Сокращайте, визуализируйте, адаптируйте. Не надо 8 абзацев, если можно одну схемку и буллеты. Длинные простыни → в гайд. Частые вопросы → в FAQ. Повторяющиеся шаги → в шаблон. Сложное → в схему. Скучное → выкинуть. Чем проще воспринимается текст — тем выше шанс, что его вообще прочитают.
- Просите помощи. Или найдите себе помощника-бота. Один техпис — это не стратегия. Это выживание. Если не дают второго техписа — автоматизируй всё, что можно: инструменты для сравнения версий, макросы, сниппеты, шаблоны, GPT и друзья для черновиков, редактуры, генерации скучных таблиц. Никто не даст тебе “ещё одного себя” — кроме тебя и пары скриптов.
Бонус: общий совет для всех
Относитесь к документации как к продукту. Она тоже требует проектирования, тестирования и поддержки. А техпис — это не придаток, а дизайнер интерфейса между человеком и сложным миром.
Вместо вывода
Мы всё понимаем. Реалии, дедлайны, команды, бизнес. Но техпис — это не просто человек, который “пишет и оформляет текст”. Это голос продукта. Это фасад. Это поддержка. А ещё техпис — это человек. Который хочет, чтобы его труд заметили. Или хотя бы прочитали.
Берегите техписов. Или хотя бы не скидывайте им задачу в пятницу вечером.
