Настоящая инженерная поддержка начинается с адаптации

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

Отлично. Время закругляться, расслабиться? Не так быстро.

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

Проблема адаптации разработчиков

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

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

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

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

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

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

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

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

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

Состояние адаптации

Несколько лет назад я уволился с работы в Facebook и основал стартап.

Когда мы нанимали наших первых сотрудников, мы использовали контрольный список в общем документе Google (со ссылками на другие документы Google и вики-страницы). Это было паршиво. Впрочем, большинство других компаний ничем не отличаются. Некоторые используют Confluence, который не предназначен для онбординга. Многие команды создают заявки на включение в Jira или Asana и подталкивают разработчиков к работе над кодом — по сути, учатся путем рандомизации. Но это возлагает на инженера бремя поиска ресурсов для изучения используемых технологий, изучения архитектуры продукта и изучения внутренних библиотек и API — и все это без какого-либо четкого пути.

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

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

Разработка решения для адаптации

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

Требования для адаптации

1. Поддержка нескольких пользователей и классов пользователей

1. Менеджеры

1. Члены команды

1. Наставники

1. Структурированное и направленное обучение

1. Модульная библиотека технических материалов

1. Создание материала по мере необходимости

1. Интерактивная среда обучения

1. Поверхностная информация (отчетность)

1. Пользовательская персонализация путей онбординга

1. Сотрудничество между новым инженером, наставниками и менеджером

1. Асинхронное использование

1. Масштабируемость от индивидуальных до команд корпоративного уровня (мировой масштаб)

Ограничения адаптации

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

Новые инженеры могут чувствовать себя перегруженными выбором. Подумайте об изучении JavaScript и React: поиск в Google выдает тысячи результатов, видео на YouTube, блоги, платные курсы, Quora и Stack Overflow… Без направления инженер не может знать, какие ресурсы имеют отношение к его конкретным потребностям.

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

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

Как выглядит этот план адаптации

![Менеджер или наставник может управлять персонализированным планом, используя как общедоступные, так и частные библиотеки, в то время как отдельный пользователь может выполнить свой план адаптации, сохраняя при этом доступ для расширения своего набора навыков из доступных им библиотек навыков, не рискуя материалами или производством.] (https://cdn.hackernoon.com/images/G9YRlqC9joZNTWsi1ul7tRkO6tv1-53a3bsu.png)

Технические возможности для новых инженеров

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

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

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

Сосредоточьтесь на следующих областях:

1. Обучите их основным навыкам, которые им нужны, например, JavaScript, Python, React, Django и т. д. Предоставьте им практические материалы курса, и они смогут быстро освоить их.

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

1. Предоставьте им структурированный способ подключения к вашим внутренним API и платформам.

1. Дайте им четкие инструкции о том, как настроить свою среду разработки, протестировать их код локально, а также протестировать их код на промежуточной стадии, в рабочей среде и т. д.

1. На каждом этапе у них должна быть возможность поднять руку, если они застряли, а наставник/менеджер может быстро их разблокировать.

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

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

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

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

![Будь то новый сотрудник или уже работающий член команды, поддержка инженеров начинается с предоставления разработчикам инструментов, необходимых им для обучения и достижения успеха. Лучший код, лучшая производительность команды, более быстрая доставка и достижение масштаба — все это следует из обучения.

Заключительные мысли по адаптации инженеров

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

Таким образом, инженерным менеджерам и бизнес-лидерам было бы полезно напрямую заняться адаптацией. У разработчиков есть уникальные потребности в отношении адаптации, так зачем нам давать им однообразный инструмент адаптации? Карьерный путь инженера-программиста представляет собой разветвленное дерево; зачем всем инженерам одинаковые ресурсы?

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