Меня зовут Нина Золотова, я технический писатель 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 регулярно публикует всякие полезные штуки для техрайтеров