контекст простой: в команду системных аналитиков вышло несколько новых человек😊 интересен опыт сообщества в этом вопросе)

как на картинке👆🏻 уже умеем и практикуем😁

В одной из компаний был хороший подход, когда аналитиков сперва просили актуализировать текущие схемы основных процессов.
И с компонентами системы ознакомятся и с процессами.

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

Лично я потихоньку пишу в компании документы для онбординга системных аналитиков.
Как работать, куда идти с вопросами, как закидывать на архревью, как общаться со стейкхолдерами и т.д.

но ты же "в стол" пишешь?

Ну и всегда помогает список компонентов, процессов в компании и т.д.

не хочется, как на картинке) ребята мне говорят, что по другому невозможно🤷‍♀️ много модулей в компании, в которых важно ориентироваться. И пока работает только следующее: новичок берет задачу, ковыряется в ней, обращается с вопросами периодически к опытным. Мне кажется, что можно пойти по пути программы адаптации, формирования некой базы знаний и т.д. Вот пытаюсь понять, какие есть практики в других компаниях

Ага, пока процесс онбординга и управления не запустишь - пишешь в стол.
Для этого надо становиться главным аналитиком и менеджить остальных.
А этого я не хочу.

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

Выдайте новечку конкретный домен из списка прцоессов и задачи по домену. Пускай разбирается конкретно в нём. И потихоньку начнёт задевать окружающие системы и набираться понимания как у вас тут всё работает.
Раз в квартал на пару дней можно отправлять к саппорту или бизнес-чаптарам, смотреть, как у них всё работает (но это подход для слабаков конечно).

Значит нет руководителя отдела аналитики. Или он филонит.

Этим занимаются ресурс-менеджеры, они не могут поставить программу выше задач на проекте

Тогда надо создать позицию руководителя отдела аналитики.

Ресурс-менеджеру не интересы проблемы работников, их онбординг. А без интересанта с властью вы не сможете выторговывать ресурсы.

Всё сольётся к вот этому.

Создание онбординга аналитика - это методология + процесс + торги.

А кто у вас ИПР составляет для аналитиков?

1. Погрузить аналитика в проект или доменную область команды. Начиная от целей, задач, заинтересованных лиц, словаря и заканчивая описанием компонентов решения.
2. Как выше советовали - дать задачу актуализировать документацию или функциональные требования. Реально работает, я так делал неаднократно.
3. Если погружаем мидла или сеньера - дать задачу описать архитектуру решения как он понял (с обязательной валидацией у архитекторов или техлидов) и потом ее презентовать
4. Если на проекте есть технологический процесс дизайна - погрузить в создаваемых артефакты, шаблоны их описания, соглашения по из моделированию.
4. Закрепить в качестве помощника другого аналитика для решения сложной задачи (тут по бразильской системе, но под руководством наставника)

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

Так что иметь описание того, какими весёлыми активностями занимается у вас системный аналитик очень даже стоит.

Потом стоит описать процесс системной аналитики проекта:
1. Какие данные приходят на вход. Как оценить качество данных.
1.1. Описать последовательность выполняемых работ.
2. Какие артефакты требуется породить в результате работы аналитика. + иметь список артефактов в целом тоже хорошо.
3. Список примеров артефактов и технических решений.
4. Описать инструкции общения со стейкхолдерами. Работа с ком тайной, внешние и внутренние стейкхолдеры.
5. Если есть БА, то следует разделить зоны ответственности в конкретном документе и правила обновления документации.