Как мы нанимали технического писателя

    Меня зовут Нина Золотова, я технический писатель Parimatch Tech, сама не один раз проходила собеседования на эту позицию, затем проводила их, поэтому знаю процесс найма с обеих сторон. Теперь хочу поделиться, как мы это делаем и на что обращаем внимание.

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

    «Болтал сегодня с инженерами и ПМами во время ревью документа и они такие:«У нас это впервые — совсем новый для нас процесс». Не перестает удивлять, насколько люди не знакомы с работой техрайтера и документацией. Наверное, я – роскошь.» Том Джонсон, техрайтер, автор блога I’d rather be writing и разработчик курса по документированию API.

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

    В другой компании после первого разговора с HR собеседовал меня архитектор. Мы немного поговорили о тех документах, которые я готовила на предыдущих проектах, потом я как-то интуитивно спросила: «А в чем у вас проблема с документами?» и дальше все собеседование сидела и с интересом просто слушала про то, что у них на тот момент болело. 

    Кого мы искали

    Ещё до начала собеседований мы между собой обсудили, каким представляем себе идеального кандидата. Если перевести с языка требований вакансии на человеческий, то мы ждали человека:

    • с техническим образованием

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

    • в идеале также хотелось видеть опыт аналитика у кандидата

    • с грамотным письменным русским и английским

    Рассчитывали на миддла или сильного джуна, были готовы обучать при необходимости.

    Почему так? Дело в том, что на тот момент у нас уже была небольшая команда, относительно налажены процессы, подобраны инструменты, разработаны шаблоны (потом мы все сломали, но об этом, наверное, в другой раз). Нам был нужен человек, который впишется в команду, быстро вникнет в то, что мы тут делаем, будет при этом достаточно самостоятельным и инициативным, его не нужно будет контролировать на каждом шагу. Сложился такой стиль управления: ставят конечную цель, но как её достичь — это уже полностью на усмотрение сотрудников, а стремление самому найти себе задачу поощряется.

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

    Если бы пришлось писать документацию с нуля или налаживать процессы, то и требования предъявлялись бы иные, но наш кейс был вот таким.

    Кто пришел на самом деле

    На позицию подалось 48 кандидатов, среди них: техрайтеры, копирайтеры, специалисты техподдержки, ПМы, маркетологи, бизнес-аналитики, переводчики и даже редактор глянца. Из них 10 прошли прескрин у HR и добрались до технического собеседования, 6 согласились сделать тестовое задание, четверо его таки сделали, по результатам тех. собеседования двое получили оффер (не одновременно). 

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

    Тестовое задание

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

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

    Тестовое задание у нас было такое:

    1. Написать пользовательскую инструкцию, как сделать ставку на сайте компании. Язык — английский.

    2. Не обязательная часть.  Изобразить этот процесс в виде схемы/диаграммы в любой выбранной нотации.

    На что мы обращали внимание при его оценивании:

    • Хороший технический документ — грамотный, понятный, логичный, консистентный, выдержан в едином стиле

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

    • Есть скриншоты или другие иллюстрации, они аккуратно оформлені

    • Инструкция рабочая — если сделать все как в ней написано, то действительно получится поставить ставку.

    Пример замечательного внутреннего документа с бинго из фраз, которые не хотел бы услышать ни один техрайтер: «никто не напишет», «по-разному, смотря где» и «сейчас все забыли». Сам документ по форме и по содержанию отличный. Человек, который так пишет, нас бы точно очень заинтересовал (но он уже работает в компании).

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

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

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

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

    Вопросы на собеседовании

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

    Какие вопросы задавали: 

    • Выясняли общетехнический уровень — что такое фронтенд и бекенд, что такое микросервисная архитектура, что такое html и xml и чем они отличаются

    • Умеет ли человек объяснять сложное простыми словами — объяснить, что такое API, своей бабушке

    • Какие типы документов уже приходилось писать? Что самое сложное было в работе над ними? Критерии хорошего документа?

    • С чего начнете работу над новым документом, новой задачей?

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

    • Как относитесь к задачам типа «пойди туда не знаю куда, принеси то, не знаю что»?

    • Что нравится в работе, что не нравится? Есть ли какие-то задачи, которые вообще неприемлемы?

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

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

    Кого мы в итоге наняли

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

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

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

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

    Бонус

    Когда создаешь в таск-трекере задачу под названием Библия, просто невозможно удержаться от шуточек на эту тему

    Если хотите побольше узнать про создание технической документации, кроме упомянутого в начале статьи блога Тома Джонсона рекомендую:

    • На Youtube-канале documentat.io есть отличный курс лекций, который дает общее понимание, что это и зачем, охватывает основные инструменты и стандарты

    • Телеграм-канал Technical Writing 101 регулярно публикует всякие полезные штуки для техрайтеров

    Parimatch Tech
    Parimatch Tech. Developing. Exciting.

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

      0
      привет! очень интересно, спасибо) можно вот в этом хабе тоже выложить habr.com/ru/hub/technical_writing.
      и опечатка, требования повторяются два раза подряд:
      • хотя бы с небольшим опытом работы в IT, причем необязательно техрайтером — вполне подошло бы и что-то смежное, например UX-райтер или тестировщик. Желательно чтобы он слышал про языки разметки текста и мог начертить хоть какую-то диаграмму
      • в идеале также хотелось видеть опыт аналитика у кандидата
      • с грамотным письменным русским и английским
      • хотя бы с небольшим опытом работы в IT, причем необязательно техрайтером — вполне подошло бы и что-то смежное, например UX-райтер или тестировщик. Желательно чтобы он слышал про языки разметки текста и мог начертить хоть какую-то диаграмму
      • в идеале также хотелось видеть опыт аналитика у кандидата
      • с грамотным письменным русским и английским
        +1
        Благодарю, исправили!
        0
        Интересно, почему мифический «единорог» отклонила оффер — просто проверяла себя и изначально не собиралась менять работу или ей не понравилось что-то в оффере?
          0
          Мне тоже интересно, но уже никак не узнать) В переписке была вежливая формулировка в духе «не вижу себя на этой позиции»
          0
          Очень интересно стало посмотреть на обезличенный вариант эталона дипломатичного отказа. Не удовлетворите ли праздное любопытство?
            0
            Извините, не считаю возможным выкладывать личную переписку на публичный ресурс) даже в обезличенном виде.
            Могу попробовать передать содержание своими словами: там были сначала комплименты в адрес всех, кто участвовал в собеседованиях, причем не общие слова, а все по делу, каждому в соответствии с его ролью. Например, в адрес HR — за максимально комфортно выстроенный для кандидата процесс. И в конце вежливый отказ с формулировкой в духе «не вижу себя на этой позиции»
              0
              Спасибо. Да, наверное так лучше
            0

            А вот расскажите мне, как вы защищаете документацию от гниения? Я никак не могу справиться. Написать-то написал, но пол-года спустя эта документация имеет отношение к версии -3, частично касается версии -2 и полностью не имеет отношения к версии 0 и +1 которая вот-вот будет зарелижена.

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

                Лучшая идея, которую я подсмотрел у благородных донов (и реализовал чуть-чуть в одном проекте) состоит в том, чтобы все сниппеты кода (запросов, примеров и т.д.) из документации были частью CI. Как только кто-то что-то непоправимо улучшит и сниппеты перестанут выполняться, так CI обвалится. После этого кто-то должен либо откатить изменения, либо поправить документацию.


                Но это работает в маленьком подмножестве документации и не покрывает текстовую часть.

                  0
                  Поделюсь двумя решениями, о которых слышала от коллег:
                  1). когда разработчик написал свой кусок кода на гите и отправляет merge request, его обязательно аппрувит не только лид, но и технический писатель (чтобы там были правильно и в соответствии со стайлгайдом написаны все необходимые комменты, из которых собирается потом документация)
                  2). тоже административное решение — техрайтер должен сначала задокументировать доработку, а разработчик или лид проревьюить этот документ, только потом доработка может попасть в релиз. Нет документа — нет релиза. Но именно в этом случае речь шла о каком-то узкоспециализированном медицинском софте, который должен был проходить сертификацию и для них наличие актуальной документации было просто критично важно.

                  Мне самой на практике не удалось их проверить — пока чаще сталкиваюсь с подходом, когда пункт из аджайл-манифеста «Работающий продукт важнее исчерпывающей документации» интерпретируют как «Документация не нужна, давайте быстрее пилить фичи». Но на всякий случай запомнила)
              0
              Мой опыт работы ТП за 10 лет (Яндекс, Электронная Москва, Манго Телеком и др.) показал, что ТП в чистом виде сейчас уже мало кого интересует. Как правило речь идет о расширении функционала на срезе бизнес-аналитики, документации ГОСТ и техподдержки. Компании, где единый источник документации ( DITA XML, DOCBOOK XML ) является must know skill можно по пальцам пересчитать.
                0
                Полностью согласна, добавлю ещё к этому перечню
                речь идет о расширении функционала на срезе бизнес-аналитики, документации ГОСТ и техподдержки

                функции information architect, т.е. от техписателя ожидают, что он не только будет писать странички в условном конфлюенсе, но и придумает, как этот самый конфлюенс упорядочить понятно для остальных.
                +2
                Пример тестового, как мне кажется, хорошо иллюстрирующий, чем отличается текст техрайтера и копирайтера, показывали недавно в техрайтерском телеграм-канале.
                Захотелось посмотреть на пример. Открыл указанный канал. Начал скроллить. Доскроллил до упоминания этого поста. Обрадовался, что двигаюсь в нужном направлении. Скроллил еще минут 10. Решил задать здесь вопрос о сакральном смысле этого упоминания примера без ссылки с «якорем».

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

                Самое читаемое