Пару лет назад в отделе, ответственном за развитие корпоративного хранилища данных «Магнита», работало 5 системных аналитиков: они полностью закрывали весь набор задач, которые перед ними стояли. Но в 2021 году случился резкий рост: данные стали использоваться не несколькими департаментами, как было до, а сразу всей компанией — для масштабных проектов. Команда выросла в 10 раз: это потребовало перестройки процессов онбординга.
Я Григорий Гаврилков, руководитель отдела системного анализа корпоративного хранилища данных в «Магните». Поделюсь нашим опытом резкого увеличения количества системных аналитиков и расскажу про грабли, которые мы собрали за полтора года.
2021 год: начало бурного роста
В начале 2021 года появилась новая стратегия развития «Магнита». Все больше проектов стали уделять внимание данным. Например:
Появился проект по планограммам, когда выкладки планограмм загружались в хранилище, а сторонние системы их обрабатывали.
Аптеки начали активнее подключаться и использовать данные.
Начались е-ком интеграции — с Яндексом, Почтой России.
Стало понятно, что хранилище надо масштабировать. Но не просто линейно масштабировать — подключить вместо трех предметных областей пять и взять ещё нескольких людей. Так бы не получилось, потому что у каждого свой кусочек работы, про который он все знает, и ведет работу по своей структуре: это привело бы к хаосу.
Поэтому внутри департамента по работе с данными мы начали глобально перерабатывать процессы. Прорисовали картину, куда будем масштабироваться. Поняли, что из пяти системных аналитиков должны вырасти до 50 — чтобы удалось закрыть все проекты, которые стратегически наметил «Магнит».
Проблемы
В процессе роста каждая компания сталкивается с дилеммой: где взять достаточное количество профессионалов, которое будет способно не только выполнять поставленные задачи, но и успевать развиваться, не терять мотивацию, двигаться вперед и двигать вперед компанию.
Очевидно, что на рынке полностью готовых специалистов в нужном нам количестве не было: особенно с учётом узкой специфики применяемых инструментов в компании. Поэтому мы столкнулись с проблемой отсутствия онбординга и наставничества: к концу испытательного срока новоиспечённый аналитик успевал закрыть одну, максимум две задачи — это было крайне неэффективно.
Как построен онбординг
База знаний в Confluence
В 2022 году создали рабочую группу, которая два месяца прорабатывала вопрос быстрого онбординга под различный уровень новых системных аналитиков.
В итоге собрали единое пространство на Confluence, которое закрывает большинство вопросов онбординга. Мы выбрали его как единую точку входа: здесь собрано всё, чтобы быстро и просто влиться в команду и начать выполнять задачи. После того, как определились со структурой и границами пространства, начали собирать материалы для наполнения: большинство пришлось создавать с нуля.
База знаний содержит такие разделы, как:
Получение прав доступа и установка и настройка софта
Стратегия компании, IT и направлений департамента
Описание внутренних процессов сопровождения и развития
Задачи для знакомства с моделью КХД (Корпоративного хранилища данных)
Общее понимание по структуре департамента, целям и задачам
Рабочая группа и сейчас встречается для постоянного совершенствования процесса онбординга: собираем обратную связь в процессе прохождения испытательного срока и обязательно на финальной встрече испытательного срока. Первые полгода были частые улучшения процесса, сейчас уже редко и точечно.
Матричная структура
Раньше, когда системный аналитик начинал работать, ему подкидывали разные задачи: одну, вторую, третью — таким образом он набирал экспертизу. Мы не выделяли направления: системный аналитик мог сначала позаниматься кассами и чеками, через месяц — лояльностью, ещё через месяц финансами.
Погружение шло достаточно долго, методом проб и ошибок. Быстро самостоятельно изучить легаси, накопленное годами, да ещё и для редких систем было сложной задачей даже очень опытных и способных ребят.
Мы решили эту проблему с помощью матричной структуры: она появилась с начала создания департамента, но поначалу аналитиков не хватало, чтобы работать в одном направлении — ребята «шерились» на несколько направлений. Позже удалось «раскатать» матричную структуру и на аналитиков: ребята начали набирать экспертизу уже точечно в одном направлении.
Наставник
За каждым новичком закреплен наставник — его назначает руководитель, исходя из загруженности выбранного направления. Наставник сопровождает подопечного на протяжении всего испытательного срока.
Для новых сотрудников уровня junior и middle наставники выбираются из senior или middle+. У наставника должен быть необходимый опыт работы в компании и уровень компетенций. Наставничество внедрялось на добровольной основе.
В первый месяц наставник выступает в роли «папы и мамы», помогает сделать первые шаги и перенять нашу культуру. Разбирает совместно каждую задачу и способы реализации.
Во второй месяц — в роли «опытного товарища», который проверяет качество выполняемых задач и дает обратную связь, как исправить шероховатости и закрыть задачу с приемлемым уровнем качества. Консультирует по решению сложных задач.
На третьем месяце выступает в роли «контролёра» и выборочно проверяет выполняемые полностью самостоятельно задачи. Процент вовлеченности наставника в процесс примерно такой: до 30% в первый месяц, до 20% во второй и до 5–10% в третий.
Индивидуальный план развития
Обязательно определяем цели на испытательный срок до выхода нового сотрудника: каждый новый сотрудник получает ИПР — индивидуальный план развития. Первый месяц прописывается подробно, последующие 2 месяца дополняются и корректируются по результатам погружения в первом месяце.
Ожидания от сотрудника регулярно обсуждаются и корректируются на специальных встречах с наставником и руководителем. ИПР состоит из 3 блоков:
1. Общая информация: кто наставник, кто руководитель, в каком направлении, сроки испытательного срока и так далее.
2. Список задач на испытательный срок с конкретными ожиданиями по каждому пункту.
3. Задачи после испытательного срока и до конца года.
В последний день испытательного срока обязательно проводим встречу, на которой подводим итоги. На ней присутствует линейный руководитель, руководитель направления, наставник и сотрудник, проходивший испытательный срок.
На встрече наставник по ИПР озвучивает итоги выполнения каждого пункта, подсвечивает сильные стороны и зоны развития. Каждый даёт общую обратную связь по прохождению испытательного срока, выносится решение с итогом. Если испытательный срок пройден успешно, то проговариваем вектор задач и наши ожидания до конца года из пункта 3 ИПР.
Комьюнити
У нас есть специальное data-комьюнити, в котором уже почти 400 человек. Эта платформа дает возможность быстро находить необходимых экспертов и решать возникающие вопросы в сотрудничестве с коллегами. Такой обмен знаний повышает продуктивность и развивает независимость внутри команды, что особенно важно при быстром масштабировании.
Результат
Результат: продолжительность этапа адаптации сократилась до 1–2 месяцев, в сравнении с 3–4 месяцами до внедрения процесса. Теперь новички начинают приносить пользу раньше: к концу испытательного срока они уже успевают выполнить около 10 задач, в то время как раньше этот показатель оставался на уровне одной-двух.
