Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Когда в команду приходит новый QA‑инженер, у его непосредственного руководителя есть примерно три месяца на то, чтобы превратить его из «человека с резюме» в самостоятельного участника процесса.

Да, три месяца — это тот самый испытательный срок, в течение которого новый сотрудник должен подтвердить свои компетенции, но в реальности нам нужно не просто проверить человека, но и интегрировать его в команду. И об этом мы будем говорить далее в статье.

Онбординг vs. адаптация

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

Итак, давайте рассмотрим подробнее эти понятия.

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

В свою очередь адаптация является психофизиологическим процессом, происходящим с человеком, по итогам которого он отвечает на вопрос: «Что происходит внутри сотрудника, пока он привыкает к новой среде?» Это история скорее про тревожность в первые недели, принятие норм и негласных правил, присутствующих в компании и выстраивание необходимых отношений с коллегами. И хотя, адаптацию нельзя полностью контролировать, мы можем создать условия, при которых она будет проходить быстрее и мягче.

Например, если мы даём новому QA доступ к тестовому стенду, необходимую документацию по продукту и наставника, то это онбординг.

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

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

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

Модель 30–60–90 дней

Для эффективного онбординга и адаптации в течение этих 90 дней нам необходимо подготовить каркас, который разделит данный период на три этапа с разными акцентами.

В качестве такого каркаса может выступать модель 30–60–90, которая хороша тем, что задаёт ожидания и новичку, и команде. То есть, все понимают, что на 15-й день никто не ждёт от него самостоятельного тестирования релиза, а вот на 80-й уже ждёт.

Итак, давайте пройдемся по всем этим этапам.

Целью первых 30 дней является ориентация, то есть новый QA должен понять продукт, команду, процессы, инструменты, познакомиться с архитектурой и основными пользовательскими сценариями.

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

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

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

Особое значение здесь приобретает наличие обратной связи по качеству артефактов, например, то, насколько понятно оформлен баг или насколько полон тест‑кейс.

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

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

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

На самом деле, представленная модель 30–60–90 не является догмой. В небольшой продуктовой команде с коротким циклом релиза эти этапы могут сжиматься до 20–40–60. А в тяжелом энтерпрайзе с длинными согласованиями, наоборот, растягиваться на больший срок.

Но сама логика «сначала понять, потом включиться, затем привнести» остаётся рабочей.

Что необходимо подготовить для онбординга QA‑инженера

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

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

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

Здесь хорошей практикой является отправка «приветственного» письма или сообщения в общий чат от руководителя с представлением нового QA и указанием, кто его наставник.

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

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

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

К назначению наставника также нельзя относиться формально, так как наставник это не тот, кто просто «сидит рядом», а тот, кто тратит своё время на объяснения, проверку артефактов и обратную связь. Нагрузку наставника нужно учитывать в планировании спринта, иначе он будет разрываться между своими задачами и новичком.

Материалы, инструменты и ресурсы для нового сотрудника

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

В этот список должна входить:

• документация по продукту (описание функциональности, пользовательские истории, схемы интеграций, глоссарий);

• тестовая документация (тест‑кейсы, чек‑листы, стратегии тестирования);

• инструменты (баг‑трекер, таск‑трекер и так далее).

Также, важными ресурсами являются списки стендов, их назначение, правила работы с ними и особенности данных.

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

Первые рабочие активности и критерии готовности к самостоятельной работе

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

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

• В первую неделю новичку необходимо пройти основной пользовательский сценарий вручную, познакомиться с тест‑кейсами, понаблюдать за тем, как наставник тестирует фичу.

• На второй неделе QA предстоит уже самостоятельная проверка небольшого баг‑фикса или мелкой фичи под присмотром.

• На третьей‑четвёртой — участие в регрессе по чек‑листу с проверкой результатов наставником.

• Во второй месяц новичку необходимо выполнить самостоятельное тестирование фич средней сложности и активно участвовать в написании тест‑кейсов.

• И третий месяц — это полная нагрузка, активное участие в планировании и внесение предложений по улучшению.

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

Вот пример такого критерия для QA.

«К концу 60-го дня QA самостоятельно проводит тестирование фичи, заводит баги с достаточной детализацией и участвует в триаже без напоминаний».

Такой критерий можно достаточно легко проверить, обсудить и скорректировать.

Как учитывать ограничения при планировании онбординга

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

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

Первое ограничение — это время наставника, которое он тратит на нового QA. Если наставник загружен на 100% в спринте, он не сможет уделять новичку достаточно внимания.

И здесь возможны различные варианты:

• снизить его загрузку на первые две недели;

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

• использовать парное тестирование как формат обучения.

Главное, при планировании нагрузки не делать вид, что наставничество для компании бесплатно.

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

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

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

Не стоит забывать и об уровне нанимаемого QA, так как junior и senior требуют разного онбординга. Senior быстрее разберётся в продукте, но ему важно понять политику и процессы команды. Junior, в свою очередь, дольше осваивает инструменты, но может быть более гибким в принятии норм. Таким образом, план стоит адаптировать под уровень, а не использовать один шаблон для всех.

Ну и инфобез тоже может вносить свои коррективы. Так, в некоторых компаниях доступ к данным в продуктиве или к определённым стендам выдаётся не сразу (его нужно заслужить). Соответственно, это тоже нужно учитывать в плане, то есть не надо ставить задачи, которые невозможно выполнить из‑за отсутствия доступа.

Как отслеживать прогресс сотрудника

Во многих компаниях за прогрессом новых сотрудников принято следить, что называется, для галочки, то есть формально.

Но на самом деле отслеживание прогресса — это не про контроль ради контроля, а про своевременную корректировку плана.

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

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

На них обсуждается не только «что сделано», но и «что было сложно», «какие вопросы остались» и «что мешает».

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

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

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

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

Итоги

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

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

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

План онбординга является полезным инструментом для сокращения этого срока.

Здесь также важно донести, какие риски он снижает:

1. долгий выход на продуктивность;

2. ошибки из‑за непонимания процессов;

3. потерю нового сотрудника в первые месяцы и другие.

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

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

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

На открытых уроках разберём, как планировать адаптацию сотрудников, выстраивать процессы внутри команды и создавать условия для эффективной работы:

• 30 сентября в 19:00. «Онбординг QA‑инженера: воркшоп по планированию первых 90 дней». Записаться

• 20 октября в 19:00. «Стабильность команды и взаимозаменяемость людей». Записаться