Кто такой IT бизнес-аналитик в 2026 году: обзор must have навыков и практик

Я прошел путь: Junior -> Middle-> Senior-> Lead Business Analyst-> Product Owner. В этой статье – краткая выжимка через призму моего опыта и понимания роли: какие навыки востребованы в реальных Agile-командах и как причинять реальную пользу, а не быть просто ретранслятором идей стейкхолдеров. Ну что, погнали?

BABOK, К. Вигерс, Яндекс-практикум. Примерно так обычно выглядит Starter Pack начинающего IT-бизнес-аналитика. Мой выглядел аналогично, только вместо Яндекс-практикума были двух-недельные курсы бизнес-анализа от Газпром нефти, где я на тот момент работал, и месяц практических задач от местной Agile команды.

Когда я наконец решился выйти на рынок, чтобы попасть в настоящую IT компанию, я ожидал увидеть гуру бизнес-анализа и четкие правила игры. На деле оказалось, что многие даже не знают, как должен работать настоящий бизнес-аналитик и везде свои правила. Из общего - только уже набившее оскомину определение аналитика как «посредника между бизнесом и разработкой».

Разное понимание роли бизнес-аналитика в компаниях

Во-первых – не все понимают разницу между просто «бизнес-аналитиком» и «IT бизнес-аналитиком». При поиске вакансий надо сразу обращать на это внимание, чтобы не тратить зря свое время. Детали будут в описании вакансии. IT бизнес-анализ в Agile команде это про проектирование информационной системы на уровне бизнес-требований и взаимодействие с командой разработки. Просто бизнес-анализ - это обычно про аналитику и оптимизацию бизнес-процессов. Во втором случае речь совсем не про IT и ближе к практикам Lean (бережливое производство).

Но даже если мы говорим про IT роль, есть различия в понимании «бизнес» Vs «системный аналитик». Где-то хотят, чтобы один человек отрабатывал задачи и по бизнес, и по системному анализу, и получается «fullstack-аналитик», а где-то идет разделение.

Откуда такие разночтения? Agile это про: «люди и взаимодействие важнее процессов и инструментов». А значит процессы и инструменты каждый выбирает сам.

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

Как процесс разработки влияет на роли и навыки?

Независимо от размера компании и команды, процесс разработки неизменно включает в себя следующие этапы (Software Development Lifecycle – SDLC):

Где-то цикл длиннее, где-то короче. Где-то в нем участвуют 3 человека, а где-то 23. Общий набор рабочих задач не меняется, а вот их распределение между членами команды может отличаться.

Пример: я работал бизнес-аналитиком на продукте автоматизации ТОиР (тех обслуживание и ремонты) в команде с сильной декомпозицией ролей - общее планирование было за Product Owner, шаг дизайна был закреплен за Системным аналитиком и UX дизайнером, тестирование полностью закрывал QA инженер, а поддержкой занималась команда внедрения. Мне оставалось просто хорошо разбираться в бизнес-процессах заказчика, качественно выявлять потребность и оформлять требования. Ну и проводить приемку результатов работы по другим этапам, чтобы убедиться что исходные бизнес-требования выполняются.

Сейчас я Product Owner в команде где есть только я и команда разработки. Максимальный Agile. То есть все функции бизнес-аналитика я выполняю самостоятельно. Также отвечаю за соблюдение Scrum методологии. И немного подрабатываю дизайнером, привлекая ресурс AI помощника "Figma Make". Тестирование делим с командой разработки - они делают авто-тесты, а я проверяю руками как пользователь - что получилось.

Роли остались, людей меньше.

Ниже пример, какие наборы ролей в команде встречаются сегодня на рынке чаще всего:

В Хардкор варианте иногда есть выделенный скрам-мастер, который фасилитирует все организационные аспекты.

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

Наличие такой конфигурации ролей указывает на логичный трек развития для бизнес-аналитика – двигаться в сторону роли владельца продукта или скрам-мастера. Роли действительно пересекаются.

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

В конфигурации «Хардкор» бизнес-аналитику проще - нет необходимости погружаться в техническую часть благодаря выделенной роли системного аналитика. Но трек развития в системный анализ и архитектуру будет маловероятен, т.к. мало точек соприкосновения.

Далее рассмотрим вариант «Оптимум» как наиболее часто встречающийся – когда один человек совмещает функции бизнес и системного аналитика.

Что в целом делает команда по циклу SDLC:

Что вам с вероятностью 99% придется делать как бизнес-аналитику в такой конфигурации команды и какие знания/навыки для этого нужны:

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

Важно держать фокус на проблеме, а не на решении

Для качественного выполнения задач на шаге «Сбор и анализ требований» критически важно понимать разницу между первопричиной и следствием и отличать реальные «боли» пользователя от хотелок.

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

Пример - заказчик попросил добавить в систему ТОиР возможность группировать несколько заказов на ремонтные работы в один. Спроектировали, заказчик подтвердил, почти запустили в разработку. А потом оказалось, что на самом деле ему была нужна полноценная система для годового планирования работ, и простая группировка мелких заказов на работы ВООБЩЕ не решает задачу годового планирования. И роли в системе нужны другие - не те, что работают с частными заказами. Вернулись на шаг назад, погрузились в процессы, разобрались с проблемами, спроектировали нормально. А могли сесть в лужу и зря потратить время и деньги.

Как выявлять проблемы? Нужно «встать в тапки» пользователя и понять: как он сейчас выполняет задачу и где теряет время, нервы и деньги. Там и будет проблема. Для этого нужно глубоко погрузиться в автоматизируемые бизнес-процессы. Выявлять проблемы в процессах и совместно с командой продумывать для них решения – задача аналитика, а не пользователя.

Какие литературные источники могу посоветовать для начинающего бизнес-аналитика чтобы закрыть пробелы в теории?

ДА - К.Вигерс «Разработка требований к программному обеспечению». Очень толковая книга, охватывающая все аспекты работы бизнес-аналитика. Написана простым языком и практико-ориентированная. Для входящих в профессию – must read. Узнаете и про задачи, и про компетенции.

НЕТ - BABOK. Его можно использовать, но только как справочник техник и фреймворков. Как книгу – читать невозможно. Написано роботами для роботов. Начинающим – будет не понятно. Опытным – слишком оторвано от практики и поэтому практически бесполезно.

Какие инструменты рекомендую изучить, чтобы быть эффективным в практике?

Без чего точно не получится качественно выполнять задачи в B2B?

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

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

Я нанимал и помогал с адаптацией людям с разным бэкграундом. Основной вывод, который сделал – обучиться IT бизнес-анализу можно за полгода. Но если нет понимания бизнес-процессов и аналитического склада ума – и 5 лет может оказаться недостаточно.

В B2B больше всего ценят бизнесовый опыт, на приобретение которого требуется несколько лет практики. И если компания разрабатывает, к примеру, ПО для автоматизации процессов ТОиР (тех обслуживание и ремонты), то с большей охотой возьмут на работу толкового Инженера по ТОиР и дообучат на бизнес-аналитика, чем просто толкового Бизнес-аналитика, который до этого занимался автоматизацией для маркетплейсов.

Резюме:

Чтобы не быть бесполезным в роли Бизнес-аналитика и приносить реальную пользу в B2B нужно:

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

А какие навыки и знания с вашей точки зрения первостепенны для бизнес-аналитика? Делитесь мнением в комментариях.