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

Привет, Хабр!

Вокруг профессии технического писателя ходит немало мифов — от стереотипов про скучные инструкции до предположений о том, что это просто "работа с текстами".

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

"Меня зовут Дмитрий, я технический писатель с опытом работы в различных IT-проектах. За свою карьеру я успел погрузиться в множество аспектов этой профессии и хочу поделиться своим опытом, чтобы развеять мифы и дать вам более точное представление о том, чем мы на самом деле занимаемся."

Кто такой технический писатель? Многие о них слышали, но мало кто точно понимает, что они делают. Часто приходится сталкиваться с мифами: кто-то считает, что это скучная, рутинная работа, кто-то — что технический писатель должен разбираться во всём сразу, как настоящий технический гуру. Из-за нехватки информации вокруг профессии возникло много стереотипов, и большинство из них довольно забавные (или досадные, если вы сами из этой сферы).

Миф №1: Технический писатель только пишет

Часто слышу: "Технический писатель? А, это тот, кто просто пишет инструкции!" — и каждый раз ухмыляюсь. Да, писательство — часть работы, но назвать это основной задачей всё равно что сказать, что разработчик просто "пишет код". На самом деле, писать — это, пожалуй, лишь вершина айсберга.

Реальность такова, что технический писатель — это больше про проектирование пользовательского опыта, про выстраивание структуры документации, про поиск информации в самых неожиданных местах и работу с людьми (и это очень важно). Документация не создаётся сама по себе — она рождается из плотного взаимодействия с разработчиками, инженерами, пользователями, и здесь технический писатель играет роль переводчика между миром технологий и миром пользователей.

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

Писатели создают не только текст, но и визуальные материалы: схемы, таблицы, графики. Когда мы делаем документацию, мы проектируем её так, чтобы минимизировать количество вопросов от пользователей, а для этого важно, чтобы каждая деталь была на своём месте. Это означает, что работа технического писателя состоит в том, чтобы сделать сложное понятным, а иногда и добавить немного юмора, чтобы разбавить сухую информацию.

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

Миф №2: Технические писатели — интроверты

Существует довольно стойкий стереотип, что технические писатели — это такие тихие интроверты, которые сидят в своём уголке и строчат мануалы, избегая всех и вся. Наверное, это представление возникает из-за того, что их работа действительно предполагает много времени за компьютером и, казалось бы, не требует общения. Но на деле это далеко от истины.

Если вы хотите стать хорошим техническим писателем, придётся научиться разговаривать с людьми. И не просто разговаривать, а задавать правильные вопросы, выяснять все мелочи и, возможно, даже объяснять что-то тем же разработчикам. Реальность такова, что чтобы написать точную и полезную документацию, нужно досконально разобраться в продукте. А это требует постоянного взаимодействия с инженерами, дизайнерами, экспертами по продукту и даже пользователями. Мы, технические писатели, часто становимся своего рода медиаторами между разными отделами: находим общий язык с разработчиками, выясняем детали у QA, получаем фидбек от пользователей и превращаем это всё в чёткую, понятную и полезную документацию.

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

Таким образом, работа технического писателя на 70-80% состоит из общения и только на 20-30% из непосредственного написания текста. Мы собираем информацию, задаём вопросы, организуем встречи и обсуждения. И, поверьте, если вам не нравится работать с людьми, эта профессия быстро утомит. Но если общение и поиск нужной информации вам в радость, то техническое писательство — это именно то, что подарит вам массу интересных задач и приятных моментов. Так что миф про интровертов здесь явно не работает.

Миф №3: Технический писатель обязательно должен иметь техническое образование

Этот миф пугает многих, кто задумывается о карьере технического писателя, но не имеет технического образования. Кажется, что без диплома инженера или навыков программирования здесь делать нечего — ведь работа с техническими продуктами требует глубокого знания технологий, верно? Не совсем.

Да, технические знания помогают, но на практике куда важнее — желание и способность учиться. Хороший технический писатель — это тот, кто умеет быстро разбираться в новой информации и превращать её в понятные и чёткие объяснения. Моя коллега, например, пришла в профессию с гуманитарным образованием, закончив факультет иностранных языков, и всё, что она знала о программировании на тот момент, можно было уместить в пару предложений. Но это не помешало ей стать настоящим профессионалом, так как она быстро адаптировалась, много общалась с инженерами и училась у них.

Пример из практики: у меня тоже филологическое образование, и мне часто приходилось разбираться с незнакомыми технологиями, вроде документации для кофемашины с интеграцией в умный дом. Оказалось, что кофемашина может подключаться к Wi-Fi, и мне нужно было описать весь процесс настройки так, чтобы любой пользователь смог справиться. Это был забавный опыт — писать инструкции о том, как научить вашу кофемашину делать кофе, подчиняясь умной колонке. 

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

Конечно, есть определённые ситуации, когда глубокие технические знания могут быть преимуществом, например, при работе с API или документацией для разработчиков. Но и в этих случаях важно не столько знание всех технологий, сколько способность объяснить сложное простыми словами. А этому как раз и учат в гуманитарных вузах: структурировать мысли, анализировать информацию и доносить её понятно. Так что, если у вас есть стремление учиться и вы умеете общаться с людьми — всё остальное приложится в процессе работы.

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

Миф №4: Техническим писателем быть скучно

Есть мнение, что работа технического писателя — это однообразная деятельность, связанная исключительно с написанием инструкций и руководств. Что ж, давайте развеем этот миф раз и навсегда. На самом деле, техническое писательство — это постоянный вызов, который никогда не даёт заскучать.

Технические писатели работают над множеством разных проектов, которые могут касаться программного обеспечения, медицинских устройств, аппаратных решений, и это далеко не полный список. Каждый новый проект — это новая область, новые технологии, новые задачи. Например, вчера я писал о конфигурации облачных сервисов, сегодня занимаюсь документированием внутреннего API, а завтра могу погрузиться в описание нового функционала для пользовательского интерфейса. Разве это похоже на скучную рутину?

Пример из практики: однажды мне нужно было работать над проектом, связанным с разработкой пользовательского интерфейса для приложения умного дома. Это было очень увлекательно — нужно было создать документацию, которая помогала бы пользователям легко настроить подключение разных устройств, от лампочек до климат-контроля, чтобы они все взаимодействовали друг с другом. Этот проект позволил мне глубже понять принципы IoT и разработки удобных пользовательских интерфейсов. Этот увлекательный опыт позволил мне узнать много нового и взглянуть на техническое писательство под новым углом.

К тому же, работа технического писателя включает множество обучающих мероприятий. Мы посещаем конференции, митапы, обсуждаем новые технологии и лучшие практики. Всё это делает нашу работу динамичной и помогает постоянно учиться и развиваться. Технические писатели осваивают такие методологии, как Agile, стандарты XML и DITA, учатся работать с инструментами для создания графики и видеоконтента, чтобы делать документацию максимально понятной и привлекательной.

Кроме того, креатив здесь тоже в почёте. Визуализация данных, создание инфографики, использование интерактивных элементов — всё это часть нашей работы, которая позволяет сделать документацию не только полезной, но и интересной для пользователя. Технические писатели не просто пишут текст — мы проектируем пользовательский опыт, и в этом нет ничего скучного. Так что, если вам кажется, что техническое писательство — это про рутину и скуку, смело вычёркивайте этот миф.

Миф №5: Технические писатели используют только MS Word и Google Docs

Существует распространённое заблуждение, что технические писатели ограничены традиционными текстовыми редакторами, такими как MS Word и Google Docs, и что их работа сводится к простому набору текста. Возможно, такой подход и срабатывал лет десять назад, но сейчас он явно устарел. Современные проекты требуют куда более продвинутых инструментов, что подтверждает Семён Факторович в своем мега-опросе.

В 2024 году использование только MS Word или Google Docs для технического писательства — это не просто ограниченно, а зачастую и непрофессионально. Современные инструменты для документирования включают специализированные платформы, которые обеспечивают удобство, гибкость и возможность работы в команде. Например, Документерра, которую мы используем в нашей команде, — это целая экосистема, которая поддерживает свыше 200 функций, предназначенных специально для работы с технической документацией.

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

Современные инструменты поддерживают командную работу и предлагают удобные рабочие процессы. Например, можно одновременно создавать контент, а затем экспортировать его в разные форматы — PDF, адаптивный HTML5, или даже интегрировать в базы знаний напрямую. Всё это упрощает процесс публикации и делает его менее хаотичным.

Применение современных платформ даёт возможность создавать более качественный контент, быстрее реагировать на изменения и справляться со сложностями. Так что, если кто-то думает, что работа технического писателя ограничена только Google Docs и Word — это давно уже не так.

Миф №6: Технические писатели не участвуют в разработке продукта

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

Технические писатели активно вовлечены в разработку продукта с самых первых этапов. Мы часто становимся первыми тестировщиками, которые проверяют продукт с точки зрения удобства использования и функциональности. Наша задача — выявить те моменты, которые могут вызвать у пользователя сложности. Например, во время тестирования ранних версий продукта я неоднократно замечал элементы интерфейса, которые могли бы быть более интуитивными. Мои замечания помогли разработчикам внести правки и улучшить UX ещё до выхода в продакшн.

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

Технические писатели работают рука об руку с разработчиками, дизайнерами, менеджерами продуктов и другими членами команды. Мы участвуем в обсуждениях, даём обратную связь, вносим предложения по улучшению интерфейсов и функционала. Бывает, что при создании документации я замечаю, что какой-то шаг можно оптимизировать или сделать понятнее, и делюсь этим с командой. Это важная часть процесса, которая помогает сделать продукт более качественным и удобным для конечного пользователя.

Кроме того, технические писатели активно участвуют в сборе и анализе обратной связи от пользователей. Мы выясняем, какие вопросы и проблемы чаще всего возникают у пользователей, и передаём эти данные разработчикам. Благодаря этому команда может лучше понять, что работает хорошо, а что нуждается в улучшении. Технический писатель — это не просто автор документации, а посредник между продуктом и его пользователями, который помогает выявлять и устранять слабые места.

Миф №7 Технические писатели нужны только в IT сфере

Многие думают, что технические писатели востребованы исключительно в IT-индустрии, и их работа ограничивается созданием документации для программного обеспечения и технологических продуктов. Это узкое восприятие значительно ограничивает реальное понимание возможностей профессии.

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

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

Технические писатели также востребованы в финансовом секторе, где мы описываем финансовые продукты, инструменты, создаём отчёты и инструкции для пользователей. В научной сфере нас привлекают для работы над статьями и отчётами, чтобы сделать сложные концепции доступными для широкой аудитории.

Таким образом, технические писатели нужны везде, где требуется передать сложные идеи в простой и понятной форме. Наши универсальные навыки помогают улучшать коммуникацию и понимание, и это делает нас ценными специалистами в самых разных областях.

Что в итоге

В этом посте мы развенчали семь наиболее распространённых мифов о профессии технического писателя (спасибо, Дмитрий). Возможно, раньше вы думали, что это скучная и однообразная работа без перспектив, но, как оказалось, реальность намного интереснее. Техническое писательство — это и о постоянных вызовах, и о креативе, и о том, как сделать сложное простым и понятным.

Эта профессия предлагает огромные возможности для развития: вы можете учиться новому каждый день, работать в самых разных отраслях и напрямую влиять на улучшение продуктов, которыми пользуются тысячи (а то и миллионы) людей. К тому же, техническое писательство — это не просто увлекательная работа, но и карьера с хорошими перспективами и доходом.

Мир технической документации всегда нуждается в талантливых, увлечённых и амбициозных людях, которые хотят делать технологии понятными и доступными. Так что, если у вас есть желание разбираться в сложных вещах и делиться этим знанием с другими — добро пожаловать в профессию!

Комментарии (14)


  1. IvanZaycev0717
    09.12.2024 14:51

    Я сталкивался с техническими писателями - с ними не о чем разговаривать. Это не программисты, не разработчики. Они просто берут какой-то стандарт RFC, криво переводят его на русский язык, а разработчики даже и не читают эту локализованную техническую документацию.

    У меня был смешной случай с VK, когда технический писатель в документации пишет про PKCE, а по факту это даже и не реализовано - "в Киеве бузина, в огороде дядька". Я и смотрю что без PKCE и с PKCE с шифрованием SHA256 - результат один и тот же. Бывает тимлиду "в падлу" организовать написание технической документации, он нанимает на фрилансе какую-нибудь безграмотную девочку, которая ничего не понимает в разработке. Она переводит, никто это не читает, не тестирует, что там написано и всё - дыру заткнули, у нас есть техническая документация по проекту. Все молодцы.


    1. Documen-Terra Автор
      09.12.2024 14:51

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

      Случаи, когда документация оказывается оторванной от реальности, как ваш пример с PKCE, чаще всего говорят о слабом взаимодействии внутри команды. Технический писатель не обязан быть экспертом в программировании, но он должен быть интегрирован в процессы, чтобы понимать продукт и его особенности. Это, в свою очередь, зависит от менеджмента: привлекли ли писателя к обсуждению технических требований, дали ли доступ к тестированию, проверяется ли документ специалистами до публикации?

      Если "дыры затыкают" без реальной проверки, проблема в подходе, а не в профессии. С хорошими писателями и грамотной организацией вы бы не заметили разницы между документацией и продуктом — всё бы работало как часы.

      Ну и к слову: утверждение, что с техписами "не о чем поговорить", — это тоже стереотип. Многие писатели — это люди с инженерным или ИТ-фоном, они способны обсуждать архитектуру, стандарты и фреймворки. Всё зависит от конкретных специалистов и задач, которые перед ними ставят.


    1. Parawriter
      09.12.2024 14:51

      А чем разработчики отличаются от программистов?))


    1. Petrvictorovich
      09.12.2024 14:51

      Может быть, от того, что вам "не о чем разговаривать" с техписами, им и приходится "брать  какой-то стандарт RFC и криво переводить его на русский язык"....


  1. dih81
    09.12.2024 14:51

    Так что, если у вас есть желание разбираться в сложных вещах и делиться этим знанием с другими — добро пожаловать в профессию!

    Желание в профессию не этим должно определяться, и не определяется после рождения детей. Так и в учители можно уйти.

    Плох техпис, который не мечтает в менеджеры или погромисты. Во-первых, это карьерный тупик, во-вторых, при тренде "а давайте-ка заменим <примерно всё, что сможем, или хотя бы попытаемся> ИИ", с реакцией топ-менеджмента на подобные предложения в диапазоне от аплодисментов до гримасы восторга со слюнями - профессия вымрет, как вымерла профессия переводчика.

    Советую все же ближе к коду, UX, дизайну, или бизнес-логике. Писательство ОЧЕНЬ неблагодарная профессия, профессия падальщика - ты от всех зависишь, а от тебя - никто.

    Еще и в комментах обосрут: "разговаривать с ними не о чем". Ну, милай, не разговаривай. За тебя тимлид поговорит. А мудаков эффективных менеджеров всегда хватает, техписы-то тут причем.


    1. Documen-Terra Автор
      09.12.2024 14:51

      Ну что ж, комментарий как артхаус — читаешь и ощущаешь сразу весь спектр эмоций. Давайте разберём по частям.

      1. Про "карьерный тупик". Это смотря как смотреть. Если техпис видит себя исключительно как "падальщика", который только и делает, что пишет под диктовку, то да, перспектива так себе. Но современный техпис давно уже не про копирование RFC. Это и UX-исследования, и взаимодействие с продуктовой командой, и настройка CI/CD для документации, и работа с API. Ближе к коду? Да это уже давно рядом, просто под другим углом.

      2. "ИИ всё заменит." Вы знаете, как и переводчики, техписы адаптируются. ИИ умеет генерировать тексты, но он не умеет проверять, работает ли оно, и делать так, чтобы разработчику и юзеру было понятно. А ещё у топ-менеджеров иногда и на ИИ реакция «восторг со слюнями», а потом выясняется, что документацию всё равно нужно — и качественную, а не автогенерацию.

      3. "Зависимость." Да, техпис зависит от команды. Но и команда от техписа зависит, если только не хочет тонуть в макулатуре багрепортов, недоумении новых сотрудников и хаосе с API. Это больше про взаимную выгоду, а не "зависимость".

      4. "Обсуждения с техписом." Тут каждый проецирует своё. С кем-то и поговорить приятно, а кому-то, может, и с собачкой общаться тяжело. Но это скорее про личное восприятие, чем про профессию.

      5. "Советую ближе к коду." Отличный совет! А теперь угадайте, сколько техписов уже этим занимаются: пишут скрипты, автоматизируют, мейнтейнят собственные проекты. Техпис XXI века — это практически междисциплинарный специалист, и если вы думаете иначе, возможно, просто не повезло встретить хорошего.

      Ну и, конечно, всегда можно уйти в менеджеры. Главное, чтобы это было не из-за усталости от «эффективных».


      1. dih81
        09.12.2024 14:51

        Мне не надо объяснять и гадать, я в индустрии, на полях, дольше, чем Хабр существует. Я не говорю, что профессия ненужная или не требует квалификации и компетенций. Но ROI низкий, лучше время и усилия вложить в другую область. Документация всегда вторична-третична по приоритету в глазах стейкхолдеров. Скриптопис так и не будет оценен - менеджер скажет на викли "кудос" и всё, "для себя ж автоматизировал". Снаружи это "достижение" никому не видно, кроме пиэма, которому на тот же скрипт не хотелось на пару часов инженера привлекать, пока техпис пару дней потратил. Что, говорите? У вас техписы за час пишут? А что ж они еще не инженеры?


    1. rJIynbIuKOT
      09.12.2024 14:51

      это карьерный тупик

      Чёт орнул, так тогда можно и про остальных IT спецов сказать))) аналитики, тестировщики привет)


      1. dih81
        09.12.2024 14:51

        Аналитики данных - нет, тестировщики - да.


  1. fireapple
    09.12.2024 14:51

    только ворд и gdocs, только хардкор


  1. BosonBeard
    09.12.2024 14:51

    Мифы не то чтобы очень распространенные, ну в плане, не помню чтобы ко мне подходили люди на улице или коллеги и говорили: "а ты знаешь техписы не участвуют в разработке и только пишут" (хотя кстати многое зависит от процессов а компании).

    Но если компания не забюрократизировалось на столько что каждый человек прям вот винтик с единичной функцией. То сказанное в статье справедливо. Именно поэтому из инициативных техписов со временем вырастают аналитики.

    Так что за статью ставлю лайк.


    1. AlMurr
      09.12.2024 14:51

      Если так подумать, из любых инициативных сотрудников со временем вырастают очень интересные персонажи :) А из техписов кто только не вырастает, с учётом навыков внятно писать, внятно говорить и объяснять, вовлечённости в технические вещи, вовлечённости в кросс-командные процессы, в построение взаимоотношений с клиентами, и т.д. Это очень верно ещё и для тех. поддержки, которая имеет сходный профиль вовлечённости. Так что роль техписателя зачастую не тупик, а трамплин.