Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка.

У нас был онбординг для новых аналитиков, и он не работал. Спустя месяц новички все еще не могли выполнить базовую задачу без помощи наставника. Мы решили подойти к онбордингу как к продукту: с метриками, жизненным циклом, MVP, UAT и поддержкой — и за 320 часов перепроектировали процесс с нуля.

Что изменили: 

1. Сделали результат онбординга измеримым.

2. Сократили время адаптации: через неделю аналитик готов к работе. 

3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников. 

4. Повысили лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла. 

Почему онбординг не работал и что с этим делать

Когда я пришел в Т‑Банк, меня удивил масштаб адаптации. Здесь выстроена целая система: новичка погружают в компанию, профессию, конкретный продукт и инструменты.

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

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

Инициативу взял на себя я — системный аналитик из команды «Профиль». У меня не было опыта в ведении подобных проектов. Для меня это выход зоны комфорта, но я хотел попробовать свои силы в чем‑то кардинально отличающимся от моих основных рабочих задач. 

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

Онбординг аналитиков в финтехе — сложная задача

Однажды мне написал младший аналитик из соседней команды, что ему нужно поменять название кнопки на нашем экране. Я согласовал правки, но он попросил созвониться. Оказалось, что спустя месяц работы он не знал, как изменить текст в интерфейсе приложения (базовая задача для аналитика). Хотя он читал онбординг, но в момент действия — завис.

Причин, почему новичок не справился с задачей, оказалось две:

1. Не было наставника — его коллега ушел из команды, и новичок остался один.

2. Онбординг перестал работать, когда ушел наставник.

Почему онбординг перестал работать без наставника:

• При разработке материалов онбординга попытались добавить максимум информации, чтобы охватить все команды и инструменты. В итоге получили полотно текста и множество ссылок. Эти материалы быстро устарели, а ссылки протухли и вели на пустые страницы. Когда наставник был — он рассказывал, что именно нужно прочитать в онбординге, и подсвечивал неактуальные материалы.

• Материалы были набором разрозненных инструкций и не показывали, как процессы взаимосвязаны между собой. Не было ответа на ключевые вопросы: что делать на каждом этапе, в какой момент включаться, какие критерии готовности (DOR/DOD) каждого этапа — это все рассказывал устно наставник.

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

Я выделил три основных фактора, влияющих на сложность создания материалов нашего онбординга:

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

Инструментов Jira/Confluence недостаточно. Аналитику недостаточно уметь работать с Jira и Confluence. Нужно научиться работать с большим набором внутренних процессов и их инструментов, таких как локализация, фича‑тогглы, A/B‑тесты, UI‑компоненты, диплинки и многие другие.

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

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

Что такое хороший онбординг

Метрик для процесса адаптации «Онбординг» существует много, они позволяют оценить, насколько хорошо процесс выстроен. Мы выбрали те метрики, которые получится измерить для нашего онбординга:

1. Удовлетворенность — насколько процесс оправдал ожидания новичка: была ли информация понятной, актуальной и действительно полезной. Мы измеряем это через 10-балльные шкалы и текстовые комментарии.

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

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

4. Контролируемость — возможность проверить, что онбординг действительно был пройден и правильно понят.

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

Решение: проектировать онбординг как продукт

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

Вот как мы разложили процесс на составляющие:

• Пользователи: новые аналитики и их наставники.

• MVP: минимальный набор знаний, необходимый для выполнения первой базовой задачи.

• Главная метрика: время до первой самостоятельной задачи (оно же — скорость прохождения онбординга).

Сбор требований — первый этап. Я провел опрос и интервью с новичками, наставниками и стейкхолдерами. Нам удалось подсветить главные боли текущего процесса и собрать много важной информации:

• непонятно, можно ли приступать к задачам до завершения онбординга;

• невозможно оценить результат — отсутствуют артефакты;

• прохождение онбординга оценивается субъективно, нет механизма проверки знаний;

• не определены сроки и объем материалов для старта;

• отсутствует механизм актуализации онбординга.

Проблемы основного артефакта процесса (страницы в confluence с материалами):

• слишком много информации на одной странице и непонятен обязательный объем для изучения;

• множество вложенных ссылок, ведущих на устаревшие или отсутствующие страницы;

• нет примеров из практики и тестовых заданий.

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

Интересно, что в итоге наш подход интуитивно повторил структуру модели Киркпатрика: от реакции и усвоения — к поведению и результату. Мы не ставили целью следовать какой‑либо известной модели обучения (я не подумал об этом на старте), но в итоге мы пришли к проверенной педагогической практике естественным путем.

Проектирование прототипа оказалось более сложной и долгой задачей. Чтобы не повторить проблем из собранной ОС, при разработке материалов мы решили:

1. Ограничить материалы только полезными для 100% команд МБ знаниями — это позволит эффективнее поддерживать онбординг в актуальном состоянии и уменьшить его размер. Это означает, что знания, которые являются спецификой работы в конкретном домене или команде, не добавляются в наш онбординг. 

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

2. Сделать фокус материалов на процессах, а не на инструментах. Вместо «как заводить переводы в сервисе локализации» → «зачем нужен процесс локализации, кто участвует, в чем твоя роль, какие входы/выходы (DoR/DoD) и какие инструменты используются по пути». Это дает контекст и снижает зависимость от наставника.

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

4. Добавить возможность оценки качества онбординга.

Я изучил подходы к онбордингу в разных отделах и командах, и ни один из вариантов в его текущем виде не подошел под наши требования:

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

Что вошло в итоговое решение

Процесс:

1. Аналитик от наставника (или тимлида) получает стартовую страницу материалов онбординга.

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

3. Генерирует через шаблон страницу‑отчет, на которой располагаются задания для закрепления материала и форма для оценки трудозатрат.

4. Изучает материалы и выполняет задания на странице‑отчете.

5. Проверяет с наставником выполнение заданий.

6. Оставляет обратную связь (это важно для регулярной актуализации материалов и оценки качества онбординга).

Центральный артефакт — страница‑отчет. Это не просто чек‑лист с заданиями, это лучшая заметка для новичка на первое время работы. Новичок в процессе онбординга по нашему шаблону сам наполняет для себя страницу, к которой потом будет возвращаться как к шпаргалке. 

Страница‑отчет:

• создается удобно по кнопке с генерацией шаблона;

• содержит задания с полями для ответов для закрепления знаний по каждому модулю онбординга. Пример задания: «Найди раздел с документацией твоей команды. Приложи ссылку на уровень „Экраны“ документации твоей команды». // Аналитик по нашим заданиям собирает для себя удобную базу знаний;

• фиксирует прогресс и затраченное время;

• позволяет наставнику добавить на эту же страницу пункты для адаптации в команде (специфику работы в команде), а новичку — собрать все важные ссылки на одной странице, чтобы после возвращаться к ней;

• используется для проверки + дает канал обратной связи (форма для отзыва).

Примеры:

• покрывает один ключевой процесс: требования, локализация, фича‑тогглы, A/B‑тесты, тестирование и так далее;

• содержит только MVP знаний → фокусирует внимание на самом главном;

• не содержит обязательных для изучения ссылок → некоторые ссылки остались, но отмечены как необязательные для изучения в рамках онбординга и будут полезны при получении рабочей задачи;

• имеет рекомендуемое время на изучение → позволяет планировать нагрузку;

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

Чек‑лист наставника. Памятка для наставника с информацией о том, на что стоит обратить внимание при проведении онбординга нового сотрудника в МБ.

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

Результаты: цифры и обратная связь

В сентябре 2025 провели пилот на небольшой группе — это был UAT этап нашего проекта. Собранная ОС показала, что структура верная, но новичкам сложно воспринимать некоторые из материалов.

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

Время до продуктивности → уложились в неделю:

• Старый процесс: измерения не было.

• Новый: среднее время составило 39 часов. Изначально мы ставили цель дать новичку MVP знаний примерно за одну рабочую неделю, и нам удалось попасть в этот период. 

Удовлетворенность процессом → выросла на 26%, с 7,3 до 9,2 балла.

Измеримость → теперь видим нагрузку и можем планировать трудозатраты:

• Старый процесс не имел возможности измерения, так как вся информация была сконцентрирована на одной большой странице.

• Новый: у каждого модуля‑страницы появилось рекомендованное время изучения (в среднем это ~2 ч). По итогам прохождения онбординга аналитик фиксирует в шаблоне‑отчете затраченное время по каждому модулю и суммарное время на весь процесс.

Контролируемость → теперь можем подтвердить освоение новых знаний:

• Старый процесс: механизма контроля не было.

• Новый: аналитик создает страницу с шаблоном, в котором указывает наставника, ответственного за проверку понимания материала. Наставник отмечает успешно изученные модули.

Самостоятельность → онбординг стал понятным и доступным для новичка. В старом процессе общая оценка составляла 3,8 из 5. В новом:

• подача материала — на 8,6 из 10;

• структура материала — на 9,6 из 10;

Отдельно измерили, как часто в процессе приходилось обращаться к наставнику. Использовалась пятибалльная шкала, где 1 — это «крайне редко», а 5 — «часто». Среднее значение составило 1,28, а 30% участников указали, что наставник привлекался только для проверки заданий.

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

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

Обратная связь от новичков:

1. Понравилась пошаговость, удобно отслеживать процесс и идти в своем темпе.

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

3. Понравилось, что суперподробно и понятно описана каждая тема, есть инструкции на все случаи жизни:) Также отмечу организацию процесса: изучаю вики по определенной теме → делаю задания → обсуждаю задания на встрече с ментором — отличный процесс.

Обратная связь от наставников

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

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

3. Концепция с заданиями по темам делает сильно прозрачнее точки, в которых у менти есть просадки в понимании.

4. У менти после онбординга есть понимание, где искать инструкции по инструментам, когда встретишься с ними на практике. Материалы в онбординге подаются доступно для аналитика, и он практически не задавал вопросов для уточнения.

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

Над разработкой нового процесса онбординга работала команда из 9 человек — четверо на этапе проработки процесса, и еще пять подключились для разработки материалов.

Мы начали работу 01.10.2024 с плановой датой окончания 30.06.2025, но закончили ровно через год 01.10.2025. Время распределилось так:

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

• 1 месяц — на разработку самого процесса.

• 4 месяца — на проработку структуры материалов.

• 6 месяцев — на разработку материалов.

Общие трудозатраты на проект — 320 часов.

Две причины, по которым задержались на 4 месяца:

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

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

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

Искусственный интеллект для ускорения мы тоже использовали — внутренние модели хорошо помогали с текстами. Но взять и загрузить им всю документацию, а на выходе получить готовые материалы не получилось. С разработкой структуры он тоже не помог — слишком много нюансов, которые нужно понимать: AI хорошо умеет структурировать текст, но не понимает, что действительно важно для новичка, а что только создает лишнюю нагрузку и не нужно для начала работы. Для этого нужен опыт и понимание того, как у нас проходит адаптация новых сотрудников, какие первые задачи будут у сотрудника.

Что дальше и кому пригодится такой онбординг

Мы проектировали процесс онбординга как продукт и сразу заложили в него обязательный этап — поддержку. Для этого этапа предусмотрели несколько важных вещей:

1. Модульную структуру материалов — при появлении новых рабочих процессов их можно будет удобно добавлять в виде отдельных страниц и модулей.

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

3. Опрос для аналитиков после завершения онбординга.

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

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

Как понять, что процесс пригодится:

• Если продукт (или компания/команда) вырос настолько, что вокруг него появились общие процессы, единые базы знаний и множество команд, которым нужно одинаково понимать процессы работы.

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

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

Итог

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

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

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

Если есть вопросы или хотите поделиться опытом — добро пожаловать в комментарии!