Как происходит анбординг и вхождение в работу
Что проверяют
Умеете ли вы сами разобраться в чужой предметной области и системах, не дожидаясь, пока всё объяснят. Для аналитика вход в проект это не только доступы, а понимание бизнес-процессов и того, как устроены интеграции. Вопрос работает и в обратную сторону: вы спрашиваете работодателя, как у них вводят в работу.
Как отвечать
Покажите свой план на первый месяц, опираясь на прошлый опыт:
- контекст: зачем существует продукт, кто пользователи, какие метрики важны бизнесу. Тут помогают встречи с продактом и владельцем процесса;
- артефакты: требования и спецификации, схемы процессов в BPMN, описания API в OpenAPI, модель данных. Сразу отмечайте, что устарело;
- глоссарий: в каждой предметной области свои термины, и одно слово у разных команд значит разное. Свой словарик экономит недели путаницы;
- as-is: нарисовать для себя текущую картину систем и потоков данных, даже если она уже где-то есть, и сверить её с разработчиками;
- первая задача: небольшая доработка или описание одного сценария, на которой вы проходите весь цикл от сбора требований до приёмки.
Сроки приводите свои: когда начали вести задачи самостоятельно, что было узким местом. Если вы строили онбординг для других аналитиков (шаблон задачи, карта систем, чек-лист первого месяца), это отдельный плюс, но только если это правда.
Когда спрашиваете вы, узнайте, есть ли наставник, где лежит актуальная документация, сколько систем в контуре команды, какие цели ставят на испытательный срок и когда ждут первую самостоятельную задачу.
Где спотыкаются
Описывают онбординг как пассивное получение знаний: «мне провели встречи, дали документацию». От аналитика ждут активности: сами назначали интервью, сами собирали картину.
Сразу предлагают всё переделать. Идеи на первой неделе без понимания контекста выглядят как незнание того, почему процесс устроен именно так.
Не упоминают стейкхолдеров. Документы можно прочитать, но реальные правила процесса часто живут в головах людей, и найти этих людей тоже часть входа.