Пару лет назад в отделе, ответственном за развитие корпоративного хранилища данных «Магнита», работало 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 задач, в то время как раньше этот показатель оставался на уровне одной-двух.