Всем привет! Меня зовут Татьяна Цикунова, я работаю системным аналитиком уже более 5 лет и за это время получила опыт в 4 проектах, а также долгое время имела честь онбордить новых аналитиков в разных командах.
Тема онбординга важна для любого IT-специалиста. Поэтому сегодня разберёмся, как провести онбординг системного или бизнес-аналитика в новую команду не только успешно, но и эффективно.
Начнём с того, что я кратко расскажу, из чего состоит статья. Мы поговорим о сложностях, с которыми сталкивается аналитик на новом проекте, расскажем лайфхаки для качественного онбординга, а в конце заправим это дело практическим чек-листом.
Сложности адаптации
Каждый аналитик, как минимум, один раз был в ситуации новичка на проекте. Мало того, что ты приходишь в новую команду, так еще и в новую компанию. Перед тобой встает непростая задача:
В сжатые сроки изучить продукт, во-первых, с бизнесовой точки зрения, во-вторых — с технической.
Изучить процессы в команде.
Изучить процесс работы аналитика в компании.
Изучить корпоративную культуру компании.
И повезло тем, кто пришёл на проект, где уже работал аналитик, где есть документация и выстроены процессы. Но нередко мы сталкиваемся с отсутствием одного или, что ещё хуже, всех трёх элементов. Придётся строить всё с нуля.
Итак, с какими сложностями нужно разобраться в первую очередь:
Изучение продукта. Продукты могут быть разные: от простых до невероятно сложных, с запутанной многовековой бизнес-логикой и legacy-частями технической реализации. Без чёткого плана можно запутаться и впасть в уныние от обилия разрозненной информации.
Встраивание своей части работы в общую схему работы команды. Часто команда имеет свой привычный уклад. Разработчики договариваются о деталях реализации налету, не заботясь о том, что через пару недель никто не вспомнит, почему было принято то или иное решение. Бизнес приносит правки в уже начавшийся процесс разработки, не взвешивая риски и сложности. Да, чаще дела обстоят лучше, но такое тоже бывает. А нам, как системным и бизнес-аналитикам, нужно вклинить свою очень важную и полезную часть работы в этот процесс максимально безболезненно.
Психологический барьер. У многих возникает соблазн не задавать много вопросов на старте онбординга, мол, потом разберусь, когда попадется связанная задача. Но если в компании выделили время на онбординг, то это хорошая легитимная возможность задавать очень много вопросов без чувства стыда, важно её не упустить. Но бывает и такое, что аналитик стесняется, боится показаться новым коллегам некомпетентным, если задаст вопрос с потенциально очевидным ответом, особенно если ты пришёл на проект как сеньор. Ничего страшного, есть еще 3 месяца, чтобы показать себя, а в первые недели можно поумерить свой синдром отличника.
Адаптация в коллективе. Подстроиться под новую команду — это большой труд. Много новых людей, все уже в теме, все кажутся незнакомыми и в чем-то могут не соответствовать нашему представлению о том, каким должен быть тот или иной специалист. Но это тоже проблема первого месяца, далее привыкаешь.
Создание процессов с нуля. Ну и самое непростое — начать писать постановки для команды разработки, если ни в команде, ни в компании нет принятого шаблона, а до тебя никто не писал документацию на проекте. Да, в целом, можно взять структуру с предыдущего проекта, накидать что-то похожее, но у каждого продукта есть свои особенности, поэтому без обкатки и правок первоначального варианта своего шаблона не обойтись.
С этим всем придётся разбираться. Давайте пройдёмся по советам, как самому аналитику облегчить себе жизнь, а затем перейдём чек-листу.
Лайфхаки успешного онбординга
Вот несколько моих наблюдений, которые были воплощены в жизнь и успешно зарекомендовали себя:
Наблюдайте, а потом действуйте. Когда мы приходим в новый коллектив, важно сначала изучить обстановку, присмотреться, разобраться, кто есть кто, какова расстановка сил, есть ли формальные и неформальные лидеры. Лишь после этого начинать проявлять себя. Никому, как правило, не нравится наблюдать за новичком, который вклинивается невпопад в диалоги или пытается показать, какой он умный. Важно чувствовать правильный момент.
Покажите лучшие качества за 3 месяца. И нам, и компании дано несколько месяцев на испытательный срок, неплохо сыграть в двойную игру. За это время важно изучить компанию, понять, подходит ли тебе то, что там происходит, с одной стороны, а с другой — постараться показать достойные результаты работы, чтобы зарекомендовать себя ценным специалистом. Да, может быть тяжело, важно не перегружать себя, но и не стоит работать в режиме «на чиле».
Станьте пользователем своего продукта. Это очень помогает в погружении в бизнес-логику. Если есть возможность, пройти хотя бы базовый флоу как пользователь — это полезно.
Не опускай руки, если проект сложный, онбординг слабый, и ты вообще ничего не понимаешь. Это нормально. Это нормально даже для суперквалифицированного аналитика. Правда в том, что общая картина складывается со временем, как пазл. Просто добавляй детальки одну за другой, и со временем начнёшь понимать: тут послушал груминг задачи, тут почитал инструкцию, здесь порылся в БД, глядишь — и уже вырисовывается какая-никакая, но картина.
Не стесняйтесь напрягать коллег и задавать вопросы. Постарайся записывать всё, что непонятно, а потом на встречах задавать вопросы. Но тут есть нюанс. Не задавай все вопросы сразу, вполне возможно, что завтра какие-то ответы найдутся сами. Тут важна золотая середина между способностью находить ответы самостоятельно и коммуникабельностью.
Используйте ИИ. Если встретил неизвестный термин или название новой технологии, иди и спрашивай у чата. Так ты более эффективно сможешь получать новую информацию. Также можно воспользоваться корпоративной моделью ИИ при работе, если таковая есть в компании. Она может помогать писать диаграммы в PluntUml по заданному алгоритму, запросы SQL и многое другое.
Ищите примеры в смежных командах. Если в команде не было аналитика, можно подглядеть в соседних командах примеры документации. Всё, что кажется полезным, бери и используй у себя.
Не изобретайте колесо для бэкенда. Если сложный запутанный и неописанный бэкенд, не беги описывать новые фичи, добавляя в постановку то, в чём не уверен. Договорись с лидом бэкендеров о помощи. Скорее всего, они сами будут не против разрабатывать решения для бэка. Иначе есть риск, что аналитик проделает большую работу, которая не вяжется с реальной архитектурой продукта.
Если документации нет — создайте её. Если на проекте вообще нет документации, стоит назначить разработчикам и тестировщикам периодические встречи и начать описывать сервисы. Сначала базовые сценарии, потом уже можно дополнять альтернативными. Так ты начнёшь понимать, как работает техническая система, и будешь опираться на эти артефакты в дальнейшей работе над задачами.
Изучайте систему технически. Структуру БД можно видеть с помощью DBeaver и пр., очереди через Kafka UI, контракты на фронте можно увидеть с помощью devtools, но общую картину потоков данных и алгоритмы ты не увидишь, если её не описывали ранее. Поэтому возвращаемся к п.9.
Вот такие 10 пунктов получилось. Теперь посмотрим на чек-лист онбординга.
Чек-лист для успешного онбординга. Берём на заметку
Итак, из чего должен состоять такого рода план для системного или бизнес-аналитика? Какие пункты — must-have, а какие — опциональны?
Я предлагаю разбить наш список на 8 ключевых блоков, которые покрывают путь от первого дня до первых самостоятельных задач.
1. Базовый старт
Здесь всё про первые шаги и снятие тревожности.
Знакомство с наставником (ваш главный проводник).
Получение общего плана онбординга на первую неделю/месяц/три месяца.
Понимание, к кому и по какому вопросу обращаться.
2. Общий технический онбординг (must-have для всех)
Без этого просто не начать работу.
Настройка корпоративной почты и календаря.
Подключение к рабочим мессенджерам (Slack, Teams) и чатам команды.
Получение доступов к базовому набору инструментов: таск-трекеру (Jira, YouTrack), базе знаний (Confluence, Notion).
Доступ к тестовым (stage) и, если нужно, prod-окружениям продуктов.
Проверка работы служебных порталов (HR, заказ оборудования и т.д.).
3. Знакомство с людьми
Проекты делают люди. Важно сразу встроиться в контекст.
Встреча с наставником для обсуждения деталей.
Короткие (15-30 мин) интро-встречи с ключевыми фигурами: тимлидом, продактом, руководителем направления.
Знакомство с командой разработки и тестирования (можно на планерке).
Знакомство со смежными командами аналитиков.
4. Специфичные инструменты аналитика
«Рабочая кухня» — то, без чего анализ невозможен.
Доступ к репозиториям (Git).
Архитектурные инструменты: Enterprise Architect, Lucidchart, диаграммы в Miro.
Доступ к Kafka UI для просмотра потоков данных.
Инструменты для работы с API: Postman, SoapUI, Swagger.
Дизайн-инструменты: Figma для просмотра макетов.
Доски для мозговых штурмов: Miro, Holst.
5. Погружение в документацию и процессы
Понимание правил игры — фундамент качества работы.
Знакомство с корпоративной культурой и общими принци��ами разработки.
Изучение правил и соглашений внутри команды.
Чтение ключевых документов по закрепленной функциональности (обзоры продуктов, спецификации).
Изучение стандартов работы аналитиков в компании: как вести требования, как проводить сессии, шаблоны артефактов.
Обзор готовых шаблонов для пользовательских историй, Use Cases, диаграмм.
6. Знакомство с продуктом
Теория должна подкрепляться практикой.
Демо-сессия от наставника или продакта: обзор продукта, его основные возможности и ценность.
Самостоятельный прогон ключевых пользовательских сценариев на тестовом стенде.
7. Первые задачи и цели
Плавный вход в рабочий режим.
Выделенные учебные/вводные задачи (например, анализ небольшого существующего функционала, описание простого улучшения).
Чёткое понимание целей на испытательный срок (что должен знать и уметь сделать к его окончанию).
Возможность подключиться к реальным задачам с поддержкой разработчиков и продакта.
8. Регулярные встречи (синки)
Системность обратной связи — залог успешной адаптации.
Важно проверить, что в календаре сразу запланированы:
Ежедневные короткие стендапы с наставником (на первую неделю).
Еженедельная 1:1 встреча с руководителем.
Регулярные встречи команды (дейли, ретроспективы, грумминги).
🗂 Готовый шаблон чек-листа для онбординга аналитика
Скопируйте и адаптируйте под свою команду. Возможный набор колонок: «Задача», «Ответственный», «Срок», «Статус», «Комментарий».
Блок 1: Базовый старт (День 1)
Проведена вводная встреча с наставником, выдан план онбординга.
Ознакомление с расписанием на первую неделю.
Блок 2: Технический онбординг (День 1-2)
Настроена почта, календарь, мессенджер.
Добавлен во все необходимые рабочие чаты.
Получен доступ к Jira/Confluence.
Получен доступ к stage-окружению.
Проверен доступ к служебным порталам.
Блок 3: Люди (Неделя 1)
Проведены интро-встречи с тимлидом, продактом, руководителем.
Представлен команде на дейли.
Ознакомлен со списком контактов ключевых коллег.
Блок 4: Инструменты аналитика (Неделя 1)
Выдан доступ к БД.
Выдан доступ к Git-репозиториям.
Настроен Postman/SoapUI.
Предоставлен доступ к Figma и Miro.
Предоставлен доступ к Kafka UI.
Блок 5: Документация (Неделя 1-2)
Изучены основные регламенты компании.
Изучены командные соглашения.
Прочитаны ключевые документы по продукту.
Изучены шаблоны и стандарты работы аналитика.
Блок 6: Продукт (Неделя 1-2)
Проведена демо-сессия по продукту.
Самостоятельно протестированы основные сценарии.
Блок 7: Первые задачи (Неделя 2-3)
Получена и выполнена первая учебная задача.
Согласованы цели на испытательный срок.
Подключен к реальной задаче.
Блок 8: Регулярные встречи (Постоянно)
В календаре стоят ежедневные синки с наставником (первая неделя).
В календаре стоит еженедельная 1:1 с руководителем.
Добавлен во все повторяющиеся встречи команды.
Итоговая встреча (Конец 1-го месяца)
Проведена ретроспектива онбординга с наставником и руководителем.
Чек-лист полностью выполнен.
Такой чек-лист — не догма, а карта. Он помогает не утонуть в потоках информации и даёт новичку чувство контроля и прогресса. А команде — уверенность, что ни один важный этап адаптации не упущен.
Итак, мы поговорили про успешный онбординг аналитика в новой команде. Надеюсь, практические советы и пример чек-листа поможет вам как самим эффективно вливаться в новые проекты, так и помогать другим аналитикам в роли наставника справляться с адаптационным процессом.
