Всем привет! Меня зовут Илья, я технический писатель компании QTIM. Сегодня хотелось бы немного поговорить о своей профессии.
Данная работа не очень популярна на рынке IT в данный момент. Когда я рассказываю кому-то, кем я работаю, многие слышат впервые о такой должности и не понимают, чем я занимаюсь. Разумеется, это люди не из мира IT, хотя предположу, что и среди них не все слышали про тех. писателей. В отличие от других более популярных IT-специальностей, по которым представлено большое количество вакансий и различных обучающих курсов, по данному направлению вакансий на рынке мало, а курсов еще меньше, найти их довольно сложно. Когда я попытался узнать, какое обучение сейчас доступно для изучения и есть ли оно вообще, обнаружил, что такие курсы практически отсутствуют, либо дают лишь базовые знания, которых будет недостаточно для полноценной работы. Возможно, что-то хорошее на рынке есть, но мне, к сожалению, не удалось найти.
Во многих компаниях отсутствует должность технического писателя, и далеко не всегда есть понимание того, зачем нужна эта должность и нужна ли она вообще, поэтому я хотел бы рассказать, почему она актуальна и может быть полезна для компании.
Для начала хотелось бы в двух словах рассказать о том, что это вообще за профессия такая. Если вкратце, то технический писатель - это сотрудник, который занимается написанием технической документации.
Писатели могут заниматься написанием следующих типов документации:
для пользователей (юзер гайды)
для разработчиков
по стандартам ГОСТ
Первый тип документации представляет из себя пользовательские инструкции, в которых будет понятным для человека (с любым техническим уровнем) языком, описан порядок работы того или иного приложения, а также порядок действий, необходимых для его использования. Эта документация необходима для эффективного понимания и эксплуатации продукта или услуги, уменьшения количества запросов на поддержку и повышения удовлетворенности юзеров.
Написание документации для разработчиков будет требовать уже большего набора навыков (поговорим об этом в одной из следующих статей). Важность такого рода документации очень высока. Она предназначена для четкого и структурированного описания кода, структуры моделей и функционала.
Технические писатели, занимающиеся оформлением документов по ГОСТ. Это исключительно локальная профессия, не востребованная за пределами РФ. Данные сотрудники необходимы в определенных компаниях, где требуется оформление документов по стандартам ГОСТ.
В нашей компании возникла потребность для написания документации именно для разработчиков, поскольку Qtim занимается заказной разработкой и ведет большое количество проектов, которые нужно достаточно качественно документировать как для облегчения введения новых сотрудников в проект, так и для использования в дальнейшем проекта заказчиками и уже их командой разработки.
Каждый проект имеет достаточно обширную кодовую базу и не всегда удается обеспечить ее передачу посредством разработчиков, поэтому в нашей компании возникла необходимость в найме тех. писателя.
Существуют различные мнения о профессии и ее необходимости, предлагаю разобрать некоторые из них:
Считается, что написанием документации по коду должны заниматься разработчики, поскольку лучше них никто не поймет код, который они написали. Да, с одной стороны это действительно так, но, исходя из опыта Qtim, я могу вам сказать, что написание документации техническим писателем может иметь определенные преимущества. Мы проанализировали время, затраченное техническим писателем на погружение в проект и написание документации, а также сэкономленное время разработки. Благодаря этому нам удалось выяснить, что привлечение технического писателя позволяет нам сэкономить немалое количество часов разработки, и при этом получать документацию достаточно качественную по содержанию, написанную доступным языком и грамотно оформленную, поскольку человек был сконцентрирован именно на написании документации, а разработчик выделить столько же времени не имеет возможности.
Введение технического писателя в рабочий процесс занимает много времени и ресурсов. Это действительно так. Мне на старте работы потребовалось потратить время для погружения в проект, я проводил время за чтением документации по фреймворку, изучением видео и статей, чтобы погрузиться в специфику команды разработки, в специфику языка, на котором написан проект, а также общался с коллегами. Спустя какое-то время я смог продуктивно работать над проектами и в итоге начал экономить время команде, создавая качественные инструкции. Это как инвестирование с целью получения дохода в будущем, в моменте ты тратишь, но потом усилия окупаются.
Многие недооценивают важность качественных, грамотно составленных гайдов для продукта, репутации бренда и продаж. Например, в нашей компании была ситуация, когда заказчик был недоволен отсутствием грамотной документации предоставляемого ему продукта. В результате моей работы удалось структурировать имеющуюся информацию, проанализировать товар и сформировать технически грамотную, подробную и визуально более привлекательную документацию. В результате клиент остался доволен качеством документации и приобрел продукт за достаточно высокую стоимость, а также оплатил дополнительно услуги по составлению документации. Таким образом, проведенная мной работа оказалась достаточно выгодной для бизнеса.
Спустя довольно непродолжительный период времени после внедрения технического писателя в нашу компанию уже можно сделать выводы о пользе, которую данное решение принесло, и привести некоторые примеры из личного опыта.
Я поговорил со своими коллегами, чтобы узнать их мнение об эффективности моей работы. В результате фидбэка разработчики заметили, что документация теперь имеет единообразный формат и стиль, что делает ее более понятной и структурированной, а значит найти необходимое в ней стало намного проще. Также отмечается экономия времени, так как теперь не приходится заниматься написанием документации.
Также разработчики и менеджеры отмечают экономию времени при онбординге новых сотрудников. Например, во время онбординга нового backend-разработчика мы провели эксперимент, предоставив ему документацию, написанную мной, для ускорения его погружения в проект, и сравнили, насколько быстро сотрудник стал разбираться в проекте с использованием документации, по сравнению с предыдущими разработчиками, которые ее не использовали. В результате новичку было намного проще разобраться в проекте, это заняло у него меньше времени, чем обычно, и возникало меньше вопросов, что также снизило нагрузку на разработчиков.
В целом, технические писатели необходимы компаниям, поскольку они обеспечивают эффективную коммуникацию, соблюдение нормативных требований, защиту знаний, повышение эффективности и положительный имидж бренда. Они играют важную роль в обеспечении успеха компаний, делая сложную техническую информацию доступной и удобной для широкого круга аудитории.
Надеюсь, вам было интересно узнать об этой профессии. Буду рад, если вы поделитесь в комментариях своим опытом, а также расскажите, есть ли у вас в компании технический писатель, и если нет, было бы полезно наличие такого человека в штате?
Комментарии (2)
OlgaVivanova
22.08.2024 15:27Из обучающих курсов - очень хороший у documentat.io: бесплатный есть в Ютубе/ на сайте, на платный очередь в месяцы
Elpi
Без технического писателя (ТП) можно обойтись. В небольших компаниях этим занимается РП (тимлид).
Есть один серьезный кейс, когда без ТП сложно. Для корректного закрытия контракта с серьезным заказчиком. У которого есть требования к оформлению, собственная коллекция стилей строго по ГОСТ, проверки Счетной палаты, выделенный человек, который безжалостно заставляет перепечатывать страницы в переплетенном томе и т.п.
В остальном РП ищет ТП когда ему уже совсем надоело все делать самому. В этом случае он дает доступ к постановкам аналитиков и макетам в Figma - все остальное ТП сделает сам.
Еще есть кейс с реально вкалывающими клиентами. Например, использование МИС в частных стоматологических клиниках. Им нужны пошаговые инструкции прежде всего. В принципе, менеджер техподдержки этого клиента может и сам их сделать - но ТП сделает красивше, а у него таких клиник 20 и более.
Последний кейс - это управление знаниями внутри команды. Базы знаний в Confluence, Git и т.п. Это уже не ТП, вообще-то. Требования ну очень сильно не совпадают к тем же ТП п.2. Я бы сказал, что этим должен заниматься методолог, специально обученный из числа самых опытных аналитиков, архитекторов или владельцев продукта.
Все хотят на роль ТП всезнающего универсала. И с заказчиком общается, и требованиями управляет, и ТЗ/ЧТЗ/ПиМИ сам напишет, и код читает. Все ГОСТы и ISO наизусть цитирует. И т.д.,и т.п. Я только не понимаю, почему - если уж так нужен спец с такой подготовкой - почему не взять упомянутого менеджера техподдержки, аналитика или разраба и из него сделать ТП? Потому что разница в зарплате большая?
*
Отдельно выражаю сочувствие в связи с тем, что вас заставили выдавливать из себя этот текст. Слабый он получился.