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

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

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

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

Чему вообще можно научить стажера за четыре недели

Технического писателя нельзя подготовить только на лекциях о ГОСТах, правилах оформления и видах документации.

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

Поэтому мы не ставили перед собой задачу за месяц подробно изучить все виды документации. Хотели, чтобы после стажировки человек умел:

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

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

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

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

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

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

При проверке я смотрела:

  • попытался ли человек самостоятельно разобраться в приложении;
  • насколько последовательно описал действия пользователя;
  • смог ли выстроить структуру документа;
  • выполнил ли условия задания;
  • как использовал возможности Microsoft Word;
  • посмотрел ли рекомендованный ГОСТ;
  • правильно ли добавил рисунки;
  • подготовил ли требуемую схему;
  • не скопировал ли текст из готовой инструкции.

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

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

Почему тестовое мы обязательно разбирали на собеседовании

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

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

Иногда после такого разговора впечатление от тестового менялось. Человек мог формально сделать всё правильно, но не суметь объяснить ни одного решения. А мог допустить ошибку и при этом показать нормальную логику рассуждений.

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

Что пришлось подготовить до первого дня

Одного расписания было недостаточно. Нужны были материалы и для стажёра, и для ментора. Я подготовила короткую памятку о профессии: кто такой технический писатель, какие задачи решает, какие существуют грейды и варианты развития, какие инструменты и литература могут пригодиться.

Отдельно появился план стажировки с темами, материалами и заданиями, а затем подробное расписание: сколько времени отводится на самостоятельную работу, изучение документов и встречи с ментором. Ещё мы предложили стажёру вести шпаргалку в Google-документе и записывать туда термины, правила и выводы по программе. Для стажёра это был рабочий конспект. Для меня — ещё один способ понять, как человек воспринимает материал. Готовое задание показывает, что стажёр сделал. Рабочие заметки иногда позволяют увидеть, почему он сделал именно так.

Теория была, но превращать стажировку в четыре недели лекций мы не хотели

Сначала стажёр знакомился с профессией и внутренним контекстом. Например, изучал пространство технических писателей в Confluence и проводил его ревью: искал грамматические и стилистические ошибки, отмечал непонятные формулировки и предлагал улучшения. Было и менее формальное задание — дополнить страницу с мемами и шутками о работе технических писателей. Так внутреннее пространство переставало выглядеть как безликое хранилище регламентов. Заодно стажёр знакомился с тем, как общается команда и чем она живёт.

Следующий этап — ГОСТы. Мы не предлагали прочитать всю нормативную базу. В программе были конкретные документы и разделы, которые могли понадобиться дальше. И здесь принцип был тот же: не запомнить нормативный документ целиком, а научиться находить нужное требование тогда, когда оно понадобится в работе.

Почему основу стажировки составили материалы госпроектов

После вводной части стажёр получал комплект документов государственного ИТ-проекта:

  • техническое задание;
  • частное техническое задание;
  • руководство пользователя;
  • архитектурные документы;
  • программы испытаний;
  • акты;
  • протоколы.

Документы были частично обезличены, а стажёр подписывал NDA. Для человека без опыта такой комплект сначала выглядит довольно сложным для восприятия. Но именно поэтому он оказался хорошим учебным материалом.Технический писатель в реальной работе редко существует внутри одного изолированного документа. Требование может появиться в ТЗ, уточниться в ЧТЗ, реализоваться в системе, затем проверяться во время испытаний и в итоге попасть в пользовательскую или отчётную документацию.

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

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

Первое задание: найти данные и ничего не потерять

Практику мы начали с подготовки проектов актов и протоколов по новому частному техническому заданию (ЧТЗ). У таких документов достаточно определённая структура, поэтому новичку не нужно было одновременно решать слишком много задач.

Нужно было:

  • найти необходимые сведения;
  • выбрать подходящий образец;
  • перенести данные;
  • сохранить структуру;
  • проверить оформление.

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

Второе задание: найти ошибки, в том числе там, где их нет

Затем стажёр получал готовый документ, в который мы заранее внесли ошибки. У ментора был отдельный документ-ключ с перечнем ожидаемых замечаний. Он помогал быстрее проверять работу и сравнивать результаты разных стажёров. Но интересно было не только то, какие ошибки человек нашёл. Иногда стажёр правил корректный фрагмент. Тогда на разборе мы обсуждали: действительно ли здесь есть ошибка, улучшает ли изменение документ или человеку просто субъективно больше нравится другой вариант. Такое задание одновременно проверяло несколько вещей: внимательность, знание уже изученных требований и способность аргументировать замечания. Недостаточно написать: «здесь неправильно». Техническому писателю нужно уметь объяснить, что именно не так, почему и на что это влияет.

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

Главное задание: собрать руководство пользователя

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

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

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

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

Что делать, если один стажёр идёт быстрее другого

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

Так у программы появилось обязательное ядро и дополнительная часть. Если человек справлялся быстрее, ему не приходилось ждать. Если отставал, сначала нужно было понять почему. Причины могли быть разными. Иногда действительно не хватало времени на конкретный документ. А иногда стажёр слишком долго пытался самостоятельно найти «единственно правильный» ответ и не задавал вопросов. Это тоже оказалось важным наблюдением. Самостоятельность не означает, что человек должен несколько часов биться над задачей в одиночку. В реальной работе умение вовремя сформулировать вопрос не менее важно, чем способность самому найти решение.

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

Зачем стажёру командные синки

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

Финальное задание — объяснить собственную работу

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

  • какие задания выполнил;
  • что оказалось самым сложным;
  • какие ошибки допустил;
  • чему научился;
  • какие темы хотел бы изучить дальше.

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

20 часов ментора оказалось недостаточно, хотя формально их хватало

Во всех трёх стажировках я участвовала либо как ментор, либо как куратор менторов. На четыре недели одному ментору выделялось 20 часов. Если смотреть только на календарь, этого хватало: вводные встречи, обсуждения заданий и основные проверки помещались в запланированное время. Проблема в том, что менторство не заканчивается вместе со встречей. В течение дня у стажёра появляются короткие вопросы: «Я правильно понял требование?», «Тот ли документ использую?», «Можно выбрать другую структуру?», «Мне продолжать искать решение самому или уже лучше спросить?»

Я старалась оставаться на связи и отвечать не только во время запланированных встреч. Поэтому фактическая нагрузка оказалась выше той, что стояла в плане. Для следующих запусков это стало одним из главных организационных выводов: при расчёте нагрузки нужно учитывать не только встречи и проверку работ, но и фоновую доступность ментора в течение дня. И был ещё один вывод: хороший технический писатель не автоматически становится хорошим ментором. Увидеть ошибку самому — одно. Объяснить, почему это ошибка, показать её последствия, помочь найти решение и при этом не переписать документ за стажёра — совсем другое. Кроме профессионального опыта здесь нужны терпение, последовательность и готовность объяснять похожие вещи несколько раз, иногда в разных контекстах.

Что мы изменили после первых запусков

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

А сработала ли такая модель

За последние три года в KODE прошло три стажировки технических писателей.

За это время мы получили более 350 откликов, провели более 50 первичных интервью, проверили 43 тестовых задания и провели более 15 собеседований. Стажировку прошли 9 человек, из них испытательный срок успешно завершили 5 человек.

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

Что мы поняли после трёх стажировок

Когда мы начинали, легко было представить стажировку технического писателя как сокращённый курс по Word, ГОСТам и видам документации. За четыре недели человек должен успеть пройти небольшой, но похожий на реальную работу цикл:

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

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

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

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