Технический писатель - летописец от мира IT?

Екатерина Валерьевна Каляева – выпускница программы "Фундаментальная и прикладная лингвистика", сохраняющая связь с программой уже в роли преподавателя. Кроме того, Екатерина Валерьевна — технический писатель, отвечающий за создание и поддержание технической документации (документов, которые объясняют, как работает продукт), а также UX-писатель, который фокусируется на создании удобного пользовательского интерфейса. В интервью вы узнаете о том, как лингвисту найти дорогу в IT: чем именно занимаются технический и UX-писатель, какие лингвистические и технические навыки для этого нужны.

Фото из личного архива Е.В. Каляевой

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

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

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

• Есть еще один стереотип о том, что технический писатель переводит очень сложный и тяжёлый язык программистов, IT-специалистов на обычный язык. Так это или не так?

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

• Получается, что техническая документация — это, по сути, мануал для пользователя?

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

Существуют инструкции, руководства, концепции, сценарии использования, справочники API. То, что вы назвали – документация и мануал – соотносятся как часть и целое.

•  Какие рабочие задачи ставятся перед вами как перед техническим писателем и UX писателем?

По задачам технического писателя у меня, наверное, стандартный флоу. Начинается работа с планирования задач с командой, где я подключаюсь и расписываю, какая нужна документация. Затем идет подготовка описания того, что должно быть изменено, формулировка вопросов по недостающим знаниям к владельцу знаний, его интервьюирование, структурирование полученной информации, оформление ее в документации. Дальше – проверка у владельца знания, что все правильно и точно. Проверка у технических писателей, что все корректно по языку и соответствует нашим требованиям внутри публикации. Отслеживание изменений и метрик по документации, то есть смотрят или не смотрят, как долго смотрят, как попали на страницу. Это тоже отдельная тема.

UX-писатель — это часто отдельный человек, но, например, на моем продукте и в компании они совмещаются, и в этом есть плюс.

Я сейчас описала примерный цикл работы технического писателя за какой-то период времени. А как вообще в целом идет работа над продуктом? Появляются какие-то запросы от клиентов, или результаты исследований, или гипотезы продуктов, происходит их аналитика, отбор, прописываются требования, создается какой-то дизайн, потом он уходит в разработку, после этого тестируется, создается документация, и все это публикуется.

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

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

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

• Как распределяется ваше рабочее время на разные задачи, какие аспекты требуют наибольшее количество энергии, профессионализма, времени?

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

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

Естественно, огромная часть – это встречи.  С утра есть полтора-два часа тишины, чтобы просто поработать работу. После 10 начинаются утренние дейлики для синхронизации с командой.

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

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

Какие инструменты и навыки нужны техническому писателю?

• Получается, что техническая документация — это в любом случае большое количество текста, так или иначе описывающее продукт. Достаточно ли каких-то простых инструментов или технологий, чтобы создать техническую документацию? Есть ли какие-то специфические инструменты, которые вы используете в своей работе?

Здесь я бы сказала, что всё зависит от продукта и от крупности компании, от того, на какой ступени развития она находится. Я работала в разных. Например, в компании, где всего человек 40 в разработке, я просто писала в Word’е.

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

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

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

Опять же это история не про то, что круто и модно иметь docs-as-code, а про то, что эти инструменты закрывают определенные потребности, и не всем компаниям, не всем документациям это нужно. Но тренд давно есть, конечно, и стандарт в развитых компаниях тоже.

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

Насколько важно техническому писателю знать какой-то язык программирования? В целом это из серии nice to have, но не что-то критично-обязательное. Я бы сказала, что навык коммуникации и напористости важнее. Что касается языков программирования, во-первых, иногда бывает такое, что техническому писателю открывается дорога в исходники кода — например, если он пишет документацию API. Тогда полезно знать основы языка, чтобы примерно понимать, что делает тот или иной метод или для чего нужен какой-то класс, который описал разработчик. Во-вторых, возможна более редкая история: когда есть мощная команда технических писателей, 10+ человек, они будут на самом деле с разным набором узких компетенций. Кто-то лучше в организационных навыках, кто-то в языковой части, кто-то в технической. В таком случае, когда возникает потребность написать какой-нибудь скрипт для вашей документационной сборки, "выигрывает" техписатель с соответствующими навыками. Например, из моего опыта: мы сейчас работаем над тем, чтобы создать и внедрить линтер на исходники документации. Здесь мне пригождаются мои знания Python.

Подводя итог,  не обязательно знать и уметь программировать, но плюшки это свои даёт.

 А по поводу английского языка, здесь больше зависит от компании, команды продукта. У меня продукт русскоязычный, на английском я не пишу, но сталкиваюсь с большим количеством англоязычных материалов. Чтобы в это пойти, нужно, конечно, иметь от B1.

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

Молча отсидеться и просто писать тексты здесь точно не получится.

Потому что чем больше компания, чем больше команды, чем сложнее продукт, тем более рассредоточены знания о нём на кучу народа.

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

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

Есть же всякие мемы про то, что вот я продакт-менеджер, я прихожу на работу, и у меня просто 8 часов стоят встречи в календаре. У нас, конечно, такого объема нет, но хватает.

•  Учитывая такое большое количество коммуникации, какие еще навыки или софт-скиллы нужны техническому писателю для эффективной работы?

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

Дальше напористость. Откровенно скажем, наличие пользовательской документации, еще и на каком-то отдельном портале, где это все разрабатывается как код, – это роскошь, которая требует ресурсов, команды, времени. Не каждый продукт, не каждая компания может позволить себе это. Поэтому есть такая проблема: из-за того, что не у всех есть опыт общения с техническими писателями, в какие-то периоды горящих сроков документация может немножко отодвигаться. Здесь нужно проявлять терпение и настойчивость, нет ничего плохого в том, чтобы напомнить про себя второй раз, третий. Раньше мне казалось это неправильным, а сейчас я понимаю, что у меня есть задача, я знаю, что этот человек мне поможет, значит, я буду к нему пробиваться.

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

•  Хватило ли вашего образования для работы техническим писателем?

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

Продолжение следует

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

О том, что поможет разобраться в профессии, какие лайфхаки есть у технических писателей и даже о том, можно ли совместить эту работу с преподаванием - читайте во второй части интервью с Екатериной Валерьевной.

 

Автор: Евгений Баронов, 22ФиПЛ