Часто вижу статьи на Хабре про то что найм в IT сломан (как хороший референс из недавних приведу вот эту - “Может, нам стоит остановить гонку вооружений и сесть за стол переговоров?”).

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

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

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

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

Что я имею в виду когда говорю про “технический” онбординг

Начнем с того что я понимаю под техническим онбордингом.

Технический онбординг - это организованный командой процесс передачи технического и продуктового контекста, цель которого как можно быстрее довести нового сотрудника до осмысленной самостоятельной работы. (Рисунок 1).

За время технического погружения в проект новому сотруднику нужно разбираться в коде и микросервисах, в том как хранятся секреты и как они обновляются, как устроен CI/CD, как выглядят слои абстракции в коде сервисов за которые отвечает команда. Безусловно, во всем вышеперечисленном можно копаться самостоятельно - читать код, смотреть историю коммитов, запускать тесты наперевес с дебаггером и спрашивать коллег. Но если такой процесс не организован командой специально, то называть такое даже “плохим техническим онбордингом” я бы не стал.

Начинается с собеседования

Итак, смотрим на название статьи - “Как вы проводите технический онбординг?” И именно такой вопрос я задаю на собеседованиях когда 

1. являюсь кандидатом на вакансию и хочу больше узнать про компанию. Вопрос, в таком случае, задаю будущим коллегам, инженерам, программистам, девопсам, нанимающим менеджерам и так далее. И звучит он так “Какой технический онбординг был у вас когда вы пришли в компанию?” Именно в такой формулировке - это позволяет оценить реальные процессы, а не желаемое (идеальное) видение человека. Хотя и последнее бывает полезным уточнить.

2. мы нанимаем нового разработчика к себе в команду. Тогда это обычно связано с решением технического задания  от кандидата и вопрос звучит немного по другому - “Представим что Ваше решение превратилось в полноценный продукт. Как бы Вы провели технический онбординг?”

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

Какие ответы я слышал*

• С нанимающей стороны (даны немного утрированные выжимки чтобы сразу был понятен посыл):

  • “Мы ищем того кто сам начнет для нас все делать” 

  • “У нас есть хорошая документация, мы дадим доступ и сам разберется”

  • “Мы выделим тебе опытного сотрудника в качестве напарника и он / она подскажет”

  • “У нас большой бэклог с задачами - начнешь делать и втянешься”

  • “Выбирай сам с чего начать” 

• Со стороны кандидатов:

  • “Я сначала проведу встречу на которой бы объяснил реализацию основных модулей и почему они написаны так как написаны”

  • “Часть задач будем делать как парное программирование”

  • “История git коммитов написана так, что можно начать с самого начала и пройти последовательно к последней версии коммит за коммитом следя за тем что и как изменялось - чтобы полностью восстановить весь контекст” (к слову, любопытный ответ, особенно когда размер проекта небольшой и коммиты написаны как по учебнику)

*Статистика личная и собрана на основе собеседований в компании с количеством сотрудников от 2 человек до более 10000 на позиции Senior Software Developer / Senior Data Scientist / Machine learning engineer. Страны: США, Финляндия, Россия, Вьетнам (за подробностями прошу в репозиторий https://github.com/Dreamlone/job-search - там приведены ссылки на конкретные вакансии хоть и без отдельных пометок как именно в компаниях мне отвечали).

В чем я вижу проблему

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

Мы, люди, в большинстве своем ценим плоды системного подхода:

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

• Мы, инженеры в частности, программисты, аналитики, тестировщики, девопсы, любим строить и использовать предсказуемые и надежные системы. Разрабатывать программное обеспечение так удобно, потому что инженеры додумались до системы контроля версий, до бэкапов, до, прости господи, Kubernetes и множества других технологий.

• И другие примеры…

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

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

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

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

Два контраргумента:

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

   1. “Так раз он архитектор, так и сам должен разобраться” - Разберется. Но вместо условно потраченной недели, занять это может пять. Да и помимо критерия скорости и эффективности, всегда можно указать на возрастающий риск ухода “новичка” из компании, а это значит, что снова придется опытных коллег отвлекать от работы для проведения собеседований. 

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

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

1. Что мне нужно узнать?

2. В каком порядке мне это узнавать?

3. Как мне наиболее эффективно изучить выбранную область?

4. Как понять, что я уже разобрался на достаточном уровне?

Как решают

Отметим решения которые встречались при литературном обзоре:

• В одной из статей корпоративного блога Yandex Cloud & Yandex Infrastructure “Система онбординга комфорт-класса” (автор - Евгений Антонов) предлагается разделить онбординг на общий и локальный, заранее описать основные шаги и ожидания в виде инструкций и чек-листов, а затем поддерживать их актуальность с помощью обратной связи от новых сотрудников.

• “Онбординг без стресса” (автор - shadowphoenix) - документация в лице “чемодана новичка” выступает как фундамент на который надстраивается система живых вводных встреч с объяснением продуктов, архитектуры и других интересностей. То есть подход через структурирование знаний - документацию - встречи. 

• Статья “От хаоса к системе: как построить эффективный онбординг в ИТ-команде” (автор - Даниил Курбатов) блога Уралсиб опирается на погружение через простые задачи, регулярную обратную связь и использование матрицы компетенций как roadmap развития (не могу не отметить эту отличную идею хотя на мой взгляд то как эта дорожная карта составлялось в статье раскрыто недостаточно глубоко)

• Статья “Онбординг в графиках: как превратить адаптацию в измеримый и предсказуемый процесс” (автор - Руслан Назаров) в блоге YADRO описывает, пожалуй, самый зрелый, я бы даже сказал продвинутый, вариант из рассмотренных: трёхэтапный онбординг, проверку усвоенных навыков и систему метрик как инструмент обратной связи. Рекомендую прочитать статью - выглядит очень интересно. Однако, на мой взгляд, такая система в полном объёме будет работать только там, где у компании уже есть хороший задел для выстраивания онбординга, хотя отдельные принципы и рекомендации безусловно применимы значительно шире.

• Статья в блоге Dodo Engineering “Онбординг разработчиков” (автор - Олеся Балашова) смотрит на решение проблемы через распределение ответственности. Мне особенно нравится их начальная оптика с тремя крайностями: бросить человека выплывать самому; всё делать за него; или дать инструменты, научить пользоваться и постепенно отпустить. Дальше они формализуют роли ментора, onboarding lead и HR-куратора, вводят checkpoints, а участие ментора постепенно уменьшается.

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

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

Как хотелось бы

Систему технического онбординга имеет смысл выстраивать не от общих правильных подходов, которые безусловно будут работать там, где для этого уже есть необходимые задатки, а от основного стержня — ежедневной работы. И начинать с ответа на вопрос: “Какую дыру в системе мы пытаемся закрыть, нанимая нового человека?” Если речь идёт о замещении, то, скорее всего, ещё на этапе подготовки вакансии были выписаны задачи, которые выполнял человек на этой должности ранее, сервисы, за которые он отвечал, и неформальные, но полезные компетенции, которыми обладал. Затем всё это было трансформировано в описание рабочих обязанностей, на которое позже пригласили кандидатов.

Именно вопрос “закрытия дыры в системе” имеет смысл сделать главным, и именно его нужно в первую очередь превратить в осязаемое основание онбординга - что новому сотруднику нужно знать и уметь. 

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

Такие “уровни” можно описывать по разному, но мне нравится определять их через два аспекта:

• Навыки (например деплоить сервис и откатывать его обратно, то что сотрудник может делать самостоятельно)

• Знания (мочь отвечать на вопросы про конкретную технологию или техническое решение)

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

Для удобства ветки можно упорядочивать по важности основываясь на важности для бизнеса, например разобраться во внутреннем устройстве Java сервисов в компании может быть важнее чем понять как работают пайплайны данных на Python в Airflow. И исходя из двух измерений (приоритета веток и глубины понимания) намного легче подбирать задачи из бэклога для нового сотрудника. 

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

Как говорил Лев Выготский: “Зона ближайшего развития ребенка — это расстояние между уровнем его актуального развития [...] и уровнем возможного развития, определяемым с помощью задач, решаемых под руководством взрослых и в сотрудничестве с более умелыми сотоварищами”. Иными словами, интересующая нас область находится на границе между тем, что человек уже способен делать самостоятельно, и тем, чего он пока не умеет, но способен освоить с помощью более опытного коллеги. Поэтому при онбординге имеет смысл подбирать задачи чуть за пределами текущих знаний и навыков новичка: не полностью в знакомой области, но и не настолько далеко, чтобы задача была для него недоступна. Так, двигаясь по дорожной карте, мы стараемся как можно дольше оставаться на этой границе и постепенно её расширять.

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

Пытаясь ответить на “Вопрос 3. Как мне наиболее эффективно изучить выбранную область?”, спускаемся на масштаб отдельных блоков из диаграммы выше (Рисунок 5). Это момент, когда нужно выбирать задачи, которые отвечают бизнес-приоритетам и при этом позволяют новичку осваивать уровни карты, не перепрыгивая сразу через три ступени.

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

• Контекст

• Задача 

• Люди

• Проверка навыков и понимания

Если чуть подробнее (Рисунок 6):

• Контекст - вместе с задачей даем новичку чуть больше информации, чем коллеге, который работает с системой не первый год: где искать нужный код, с чем он связан, почему решение устроено именно так и какой бизнес-контекст за ним стоит. Не нужно давать готовое решение, достаточно отправной точки. Формат: детальное текстовое описание, ссылка на документацию (если есть) или встреча на полчаса-час на которой презентуется новая задача. 

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

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

• Проверка навыков и понимания - после завершения задачи возвращаемся к выбранному уровню дорожной карты и проверяем, какие знания и навыки действительно появились. Это можно сделать вместе с коллегой или оставить в формате самопроверки — важнее не форма, а понимание того, что уровень действительно освоен. Это завершающий аккорд, который отвечает на “Вопрос 4. Как понять, что я уже разобрался на достаточном уровне?”

"Возражения не принимаются"

Наконец хотел бы затронуть два важных момента:

• Насколько это гибко

• Насколько это вообще нужно

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

Теперь про нужность. Задам гипотетический вопрос сам себе после представления вот такого многоуровневого фреймворка - “Да это все переусложнение! Какая-то мета-работа, лишь бы настоящими задачами не заниматься”

Позвольте мне спросить:

• Писать понятные коммиты, это мета-работа?

• Проводить code review — это мета-работа, отвлекающая вас от принесения пользы бизнесу? 

• Писать подробное сообщение в чат с достаточным контекстом для соседней команды, чтобы они могли помочь вам как можно быстрее, — это мета-работа? 

• А тесты, документация, performance review, регулярные созвоны с командой и менеджментом? 

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

Если попытаться привести какие-то цифры, то могу, пожалуй, рассказать только про собственный опыт найма старшего разработчика в команду (для которого и был применен описываемый в посте подход). Мы потратили в сумме примерно 40 человеко-часов на разработку фреймворка, описания ландшафта компетенций команды, составление плана онбординга и его обсуждение. Точно подсчитать количество сэкономленных часов в итоге трудно, но я оцениваю разницу в месяцы: через четыре месяца новый разработчик мог самостоятельно работать с ключевыми частями системы примерно на том же уровне, что и я. Мне самому, когда я пришёл в этот проект без технического онбординга, на достижение сопоставимого уровня потребовалось больше года.

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

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

Заключение

Технический онбординг не обязательно должен быть сложным или трудозатратным. Я считаю, что он просто должен быть. Чтобы новый сотрудник понимал, что ему нужно узнать, в каком порядке это делать и как определить, что очередной уровень уже освоен. Дорожная карта, реальные задачи с подробным объяснением (когда это необходимо) и регулярная проверка понимания — один из способов этот процесс организовать. 

В данном посте Михаил Сарафанов был искренне рад рассказать про своё видение проблемы :) 

А как вы проводите технический онбординг?