Работа технического писателя в IT-компании: цели, зоны роста, кому подходит

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

Технические писатели на самом деле занимаются более интересной работой, чем можно себе представить на первый взгляд. Должность технического писателя сочетает менеджерские и аналитические функции. Помимо всего прочего, специальность технического писателя еще и востребованная. Все больше компаний ищут специалистов на эту позицию: на момент публикации статьи на Head Hunter 435 вакансий по запросу «технический писатель», на Хабре — 75.

О том, как устроена работа технического писателя в сфере заказной разработки, рассказывает Сергей Кузьмишкин, руководитель подразделения Nota.Docs в компании Notamedia. В статье вы узнаете о горизонтальном и вертикальном росте техписа, а также о том, какой тип личности подходит на эту работу в зависимости от специфики проекта.

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

Документация бывает как для внешних пользователей (пользователей сервиса), так и внутренних (сотрудников компании).

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

Над разработкой продукта в IT-компании работает проектная команда. И для подготовки документации технический писатель взаимодействует со всеми ее участниками:

• Разработчики. Технический писатель переводит понятные и прописные истины программиста на удобный для пользователя язык. Для этого он идет к разработчику и задает вопросы о том, как работает система.

• Финансисты. Для оплаты услуг субподрядчика или оплаты услуг компании нужны сопутствующие документы. Технический писатель вместе с финансовым отделом участвует в разработке этих документов для заказчика и их приемке от субподрядчика.

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

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

• Руководители проектов. С РП технический писатель взаимодействует для координации и контроля над соблюдением всех необходимых формальностей со стороны участников проекта. Обеспечивает консистентность формальной части проекта.

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

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

Для технического писателя важно не зацикливаться на самом тексте, а смотреть в суть. Прийти к разработчику и спросить: «Все ли я правильно понял и написал?».

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

Представим ситуацию, что человек приходит на позицию технического писателя, перерастает грейд Junior и в какой-то момент начинает думать: «А куда дальше развиваться? Буду ли я до конца карьеры писать технические документы, такие как руководство пользователя?»

Ответ: нет. У технического писателя есть конкретные зоны роста — как горизонтального, так и вертикального. Поговорим о горизонтальном росте подробнее.

Зона роста № 1 — управление

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

Также техпис должен уметь оценивать затраты на разработку той или иной документации:

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

2. С учетом качества и количества исходных данных прикинуть свои трудозатраты на формирование отчетной документации.

3. Уложить это все на план-график исполнения контракта, понять, сколько нужно людей, какой трек согласования документации, и как вообще при этом выжить.

То есть это процессное и ресурсное управление, которым он должен владеть. И это схожие процессы с теми, которые есть у руководителя проекта.

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

Зона роста № 2 — аналитика

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

Бывают и неклассические аспекты аналитики.

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

Поэтому технический писатель может вырасти в аналитика.

Зона роста № 3 — юриспруденция

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

Вертикальный рост технического писателя прост и понятен. В подразделении Nota.Docs четко выстроена градация между специалистами уровня Junior, Middle и Senior:

• Junior — новичок, обладающий базовыми компетенциями: грамотность, владение MS Office, системность и структурированность мышления, внимательность к деталям. Но ему нужна помощь от более опытных коллег по ряду вопросов.

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

• Senior — это уже расширенные компетенции и нечто большее, чем все функциональные обязанности специалиста Middle. Это «большее» может быть с точки зрения, например, управленца — то есть человек, который ставит задачи нескольким мидлам. Или человек, который глубоко знает определенную предметную область или систему.

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

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

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

Давайте смоделируем несколько ситуаций: проектов и подходящих под них типажей кандидатов.

Типаж 1 — «библиотечный бука»

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

Типаж 2 — «решала»

Проект Б. На проекте много согласующих, но несложная документация. Не требуется глубоко лезть в технические вещи. На этом проекте, чтобы согласовать небольшую стопку документов, нужно встретиться с заказчиками и с 5-6 людьми договориться, понять, что они хотят, найти к каждому подход. Поэтому на этот проект нужен своеобразный «решала» — человек, который умеет договариваться, нравиться людям и находить компромиссы.

Типаж 3 — «бодала»

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

• Технический писатель в IT — это полноценный член проектной команды. Он взаимодействует со всеми участниками и напрямую отвечает за успех проекта.

• У технического писателя есть конкретные зоны роста, помимо создания технической документации — это менеджмент, аналитика и юриспруденция.

• Технический писатель может расти как горизонтально, так и горизонтально-вертикально, так и вертикально.

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

• Хард-скилы также могут сильно отличаться и зависят от проекта. Бывает, что нужен продвинутый техпис-аналитик, под конкретный проект с конкретным стеком технологий. И хард-скилы — это то, что легче прокачать, в отличие от софтов.

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

#карьера #техническийписатель #работатехническимписателем #техническийписательвit #карьеравit