Не поздно ли переходить в BA — мой опыт

Коллега на одном из первых проектов бросил фразу, которая застряла на годы: «Ты не бизнес-аналитик, ты технический писатель». Я тогда только вышел из банка — больше десяти лет на руководящих позициях, начальник управления, начальник департамента — и полгода как отучился на фулстека, чтобы наконец разговаривать с разработкой на одном языке. По штатному расписанию я был бизнес-аналитиком. По факту — нет, и коллега заметил это раньше меня.

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

Это личный опыт, не абстрактный совет. Если ты сейчас думаешь, что уже поздно начинать — тебе полезно знать, сколько лет такой переход занимает на самом деле, и что в нём было честно тяжело, а не «немного непривычно».

Не хватало аргументов, не знаний

В банке я был близко к BA-функциям — процессное моделирование, анализ — просто это так не называлось. Настоящая проблема всплыла не в терминах, а в спорах. Я пытался продавить более понятные для пользователя фичи — удобство, UX. IT отвечал одно и то же: можно обойтись меньшим. Спорить я не боялся. Мне не хватало словаря. Я не знал, какие вообще есть альтернативные способы реализации, чтобы сказать: «А давайте вот так» — конкретно, а не «сделайте удобнее».

Дело было не в том, что я не умел отстаивать позицию бизнеса. Я не знал, чем её отстоять.

Чему учит обучение, а чему — нет

Полгода фулстека дали ровно то, чего не хватало в тех спорах: понимание архитектуры. Что такое фронтенд, бэкенд, сервис, как они связаны между собой. Основы SQL, структура базы данных, диаграммы классов. Термины Agile — спринт, бэклог, церемонии. Всё это реально пригодилось, и не только на словах — я стал понимать, о чём вообще спорит разработка.

Чего курс не дал — практики самой роли. Как именно бизнес-аналитик работает день в день. Какие вопросы задаёт первыми. Где граница между «уточнить у заказчика» и «решить самому». Обучение было ближе к программированию, чем к бизнес-анализу. Детали я знал по верхам. Отсюда и комментарий про технического писателя — я умел описать требование. Бороться за него — ещё нет.

Waterfall и Agile — два разных мира, не два процесса

В банке решение о новой фиче проходило так: сначала комитет, потом совет директоров, потом ещё один круглый стол — прежде чем кто-то вообще открывал техническое задание. Пока согласование шло, документ успевал устареть и его переписывали заново, иногда не один раз. Правка одного requirement занимала недели, а не часы. В IT-продукте всё было наоборот: спринт две недели, планирование в понедельник, демо в пятницу, и следующая итерация уже с учётом фидбека — то, что в банке было полугодовым циклом согласований, здесь укладывалось в один спринт.

Первая роль в аутсорс-продуктовой компании была BA только по названию должности. По сути — переходная позиция между двумя логиками, банковской и продуктовой. Тяжело было именно стоять на границе, а не оказаться по одну из сторон.

Деньги на входе — если честно

Часто держишься на работе не потому, что она устраивает, а потому что платят достаточно, чтобы не срываться с места. И вот в этот момент IT выглядит слишком хорошо, чтобы отказаться: более интересная работа, понятная перспектива роста — и деньги вроде бы тоже не хуже. Здесь и есть нюанс.

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

Десять лет спустя

С момента перехода прошло десять лет. За это время — BA, тимлид бизнес-аналитиков, Senior BA, и в итоге операционный директор в необанке. Домены — от классического банкинга и крипты до гемблинга и HR-систем. Ни один из этих шагов не случился за полгода обучения. Обучение открыло дверь. Остальное — годы практического опыта.

Если сжать в один совет: найди практическую базу и хорошего ментора, и советуйся с ним постоянно — не с тем, кто только критикует, а с тем, кто реально учит. И не бойся задавать вопросы, даже очевидные на первый взгляд. Умение задать правильный вопрос — один из ключевых навыков BA, а не признак того, что ты недостаточно готов.

Дальше в блоге разберу инструменты, с которых реально стоит начинать джуну — SQL, Miro, Jira — без раздувания списка софта, который тебе не понадобится в первый год.