Кто такой бизнес-аналитик в IT: задачи, навыки и как начать

Коротко о роли

Бизнес-аналитик (BA) — это переводчик между бизнесом и разработкой. Заказчик говорит «нам нужна CRM», а аналитик выясняет, зачем она, какие процессы сейчас ломаются, кто будет ей пользоваться и что считать успехом. Результат его работы — требования, по которым команда может оценить, построить и проверить продукт.

Главная ценность BA не в документах, а в том, что команда делает правильную вещь, а не просто делает вещь правильно.

Чем аналитик занимается каждый день

• Интервью и встречи со стейкхолдерами. Выяснить цели, ограничения, кто принимает решения.
• Описание процессов «как есть» и «как будет». Часто в нотации BPMN: видно, где ручная работа, задержки и дубли.
• Формулировка требований. Бизнес-требования (зачем), пользовательские (что нужно людям), функциональные и нефункциональные (что делает система и с каким качеством).
• User stories и критерии приёмки. Формат «Как <роль>, я хочу <действие>, чтобы <ценность>» плюс условия, по которым история считается готовой.
• Работа с бэклогом. Вместе с владельцем продукта расставить приоритеты, разбить крупное на части.
• Ответы команде. Разработчики и тестировщики приходят с вопросами — аналитик снимает неясности.
• Приёмка. Проверить, что сделанное действительно решает исходную задачу.

Пример истории с критериями приёмки:

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

Критерии приёмки:
- В списке сделок есть фильтр «Без активности 7+ дней».
- Активностью считаются звонок, письмо или смена этапа.
- Фильтр учитывает только сделки текущего менеджера.

Чем BA отличается от соседних ролей

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

Какие навыки нужны

Жёсткие навыки:

• написание требований и user stories, критерии приёмки;
• моделирование процессов: BPMN, а также UML-диаграммы (use case, activity, sequence) на базовом уровне;
• понимание, как устроены веб- и мобильные приложения, что такое API, база данных, клиент и сервер;
• базовый SQL, чтобы самостоятельно проверить данные;
• инструменты: таск-трекер, вики, редактор диаграмм, прототипирование в Figma на уровне вайрфреймов.

Мягкие навыки:

• умение задавать уточняющие вопросы и слышать, что стоит за просьбой;
• структурное письмо: коротко, однозначно, без «и т. д.»;
• фасилитация встреч и умение договариваться при конфликте интересов;
• критическое мышление: замечать противоречия и пробелы.

Как начать: первые шаги

1. Разберитесь в основах разработки. Как идёт проект от идеи до релиза, что такое Scrum, спринт, бэклог.
2. Изучите нотации. Нарисуйте BPMN-схему знакомого процесса: заказ в кафе, оформление отпуска.
3. Сделайте учебный проект. Возьмите реальное приложение (доставка, запись к врачу) и опишите для него процесс, 10–15 user stories с критериями приёмки и простой прототип. Это и есть портфолио.
4. Подтяните SQL и английский. Многие материалы, инструменты и вакансии на английском.
5. Используйте текущий опыт. Переход часто идёт из QA, поддержки, продаж или отраслевой работы (банк, логистика, ритейл): знание домена — сильное преимущество.
6. Ищите стажировки и позиции junior BA, а также роли рядом: аналитик поддержки, внедренец CRM.

Профессиональные своды знаний вроде BABOK полезны как карта профессии, но сертификат на старте не обязателен — работодатели чаще смотрят на то, как вы мыслите и пишете.

Типичные ошибки новичков

• Записывать решение вместо проблемы. «Нужна кнопка экспорта» — это решение; важно понять, зачем экспорт.
• Писать расплывчато. «Система должна работать быстро» нельзя проверить.
• Общаться только с заказчиком. Конечные пользователи часто описывают процесс иначе.
• Исчезать после передачи требований. Работа аналитика продолжается до приёмки.