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

Проблема новичка в том, что слово «бизнес-аналитик» в вакансиях звучит одинаково, а жизнь — нет. В одном месте вас будут любить за то, что вы нашли точку роста в онбординге и подняли конверсию на 0,8 п.п. В другом — за то, что вы поймали противоречие в ТЗ до подписания допсоглашения и сэкономили компании пару недель и пару нервных срывов.

Ирония рынка: чаще всего «продуктовая» компания тоже делает проекты (интеграции, внедрения, кастомизации), а «проектная» внезапно имеет свой продукт (внутренний, коробочный или полу-коробочный). Поэтому правильный вопрос на собеседовании звучит не «у вас продукт или проекты?», а «что будет мерилом моей полезности: метрики или акт сдачи-приёмки?»

Где заканчивается “анализ” и начинается реальная работа

Цель и единица результата: метрика против артефакта

Тезис. Продуктовый бизнес-аналитик отвечает за изменения, которые двигают метрики продукта; проектный бизнес-аналитик — за изменения, которые укладываются в объём работ, сроки и договорённости.

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

Практический вывод. Если вам нравится “постоянно думать и проверять гипотезы” — продукт. Если нравится “собрать требования, разложить по полочкам, держать контур” — проекты.

Подводный камень. Новички в продукте пытаются «дописать идеальное ТЗ» и тормозят delivery. Новички в проекте пытаются «покрутить гипотезы» после фиксации требований — и внезапно открывают портал в ад допсоглашений.

Процессы: Agile по-настоящему и Agile “на плакате”

Тезис. В продукте Agile чаще живой (итерации, экспериментирование, A/B), в проекте Agile часто превращается в удобный способ “делать Waterfall спринтами”.

Обоснование. Проект ограничен контрактом: много что нельзя менять без последствий. Поэтому даже при Scrum/Kanban у вас будет сильная потребность в фиксации scope. В продукте scope плавающий, а KPI — фиксированный (выручка, конверсия, удержание, NPS).

Практический вывод. На интервью просите примеры: “как вы меняете требования”, “кто владелец приоритизации”, “что важнее — срок релиза или результат эксперимента”. Ответы скажут больше, чем слово Agile в описании вакансии.

Подводный камень. Слова “у нас Scrum” иногда означают “у нас ежедневные созвоны, а дедлайны как в 2008”.

Инструменты: одинаковые названия, разная нагрузка

Тезис. Набор программ похож: Jira/YouTrack, Confluence/Notion, Miro, Figma, BPMN/UML, SQL, Excel. Разница — что именно вы в них делаете каждый день.

Практический вывод. Если вы хотите быстрее расти в сторону продакта/PO — продуктовая роль ближе. Если хотите сильную базу в системности, границах и документации — проектная роль даёт “скелет”.

Подводный камень. В продукте недооценивают юридическую и интеграционную реальность. В проектах — недооценивают, что “пользовательская ценность” всё равно вернётся бумерангом через поддержку и негатив.

Артефакты: что вы реально производите

Тезис. Разные компании по-разному называют документы, но набор повторяется.

• Продуктовый BA: гипотезы, описания фич, сценарии, прототипы, требования в формате user story, план эксперимента, метрики успеха.
• Проектный BA: ТЗ/ЧТЗ, спецификации интеграций, схемы BPMN, согласованные протоколы, реестр требований, матрица трассируемости (что из требований где реализовано и как проверяется).

Практический вывод. Хотите “меньше бумаги” — всё равно не получится, просто бумага будет называться по-другому. В продукте она уходит в backlog и аналитические отчёты. В проекте — в формальные согласования.

Подводный камень. В проекте попытка “не документировать, чтобы быстрее” заканчивается тем, что спорить о требованиях будете в самый дорогой момент — ближе к сдаче.

Сопоставление с рынком РФ: что требуют в вакансиях и сколько обычно платят

Что чаще просят

Тезис. В РФ для продуктовых BA чаще требуют работу с метриками, SQL и понимание продуктового discovery; для проектных — BPMN/UML, опыт сбора требований у заказчика и навык фиксации договорённостей.

Практический вывод. Если вы входите в профессию с нуля, проще “продать” себя как проектного BA (много коммуникаций, структура, документы). Если вы уже в IT (QA, support, dev) — продуктовая траектория часто быстрее, потому что вы знаете, как устроена поставка изменений.

Подводный камень. Вакансия “бизнес-аналитик продуктовый” иногда означает “проектный BA в продуктовой компании на интеграциях”. Спрашивайте про долю времени на discovery и на согласования.

Зарплаты и сроки входа (ориентиры, не магия)

По рынку РФ (вилка зависит от города, домена и компании) типичные ориентиры такие:

• Junior BA: ~80–140 тыс. ₽/мес.
• Middle BA: ~150–250 тыс. ₽/мес.
• Senior BA: ~250–350+ тыс. ₽/мес.

Сроки. При нормальной интенсивности обучения и практике в задачах: 3–6 месяцев до first offer на Junior (если вы реально делали артефакты и можете их показать), 12–24 месяца до Middle — если попали в сильную команду и не “просто писали протоколы”.

Реальные кейсы: как это ломается (и как чинится)

Кейс 1 (продукт): “идеальное ТЗ” убило скорость

Команда делала улучшение оплаты в мобильном приложении. Продуктовый бизнес-аналитик решил “сначала описать все сценарии” — от идеальных до апокалипсиса, включая редкие ошибки эквайринга. В итоге 3 недели ушло на согласование текста, а гипотеза была простая: переставить один экран и убрать лишнее поле. После переключения на формат user story + критерии приёмки + быстрый прототип в Figma релизнули за неделю и получили рост конверсии оплаты на 1,1 п.п. Самое смешное: редкие ошибки всё равно поймали потом, но уже точечно.

Кейс 2 (проект): “потом уточним” превратилось в допсоглашение

Во внедрении внутренней системы (учёт заявок) заказчик сказал: “интеграцию с 1С потом обсудим”. Проектный бизнес-аналитик это проглотил и ушёл писать остальное. Когда дошли до приёмки, внезапно выяснилось, что без 1С “это не работает”, а интеграция — отдельный объём, безопасность, доступы, тестовый контур. Итог: конфликт, перенос сроков и допработы. Лекарство банальное: фиксировать границы (scope) и явно прописывать “вне объёма” с условиями изменений.

Коммерческие факторы: где новички теряют деньги на обучении

Рынок курсов по профессии «бизнес-аналитик» в РФ обычно ходит в диапазоне 40–180 тыс. ₽ за 2–6 месяцев. “Трудоустройство” чаще означает карьерные консультации и разбор резюме, а не очередь из работодателей у вашей двери.

• Что обычно входит: основы требований, BPMN/UML, Jira/Confluence, немного SQL, практика на кейсах.
• Скрытая цена: время (200–350 часов), необходимость собрать портфолио артефактов, и иногда — платный доступ к тренажёрам/подпискам.
• Риск: курс учит “всё обо всём”, а вам на интервью зададут 10 конкретных вопросов: как описать интеграцию, как проверить требование, как приоритизировать, как посчитать эффект.

Если хотите сравнивать подходы трезво, а не по обещаниям лендингов — на https://itokno.ru как раз удобный формат: разборы, критерии и логика выбора без поклонения “успешному успеху”.

Экспертный вердикт и инструмент: как выбрать направление без гадания на Jira

1. Спросите на интервью: “по чему оценивают BA — по метрикам или по закрытым этапам?”
2. Попросите пример последней задачи: какие артефакты выдали, кто согласовывал, что считали успехом.
3. Уточните контур: интеграции с 1С, Госуслугами, СБП, внутренними шинами — это продукт или проект? По факту часто проект.
4. Проверьте реальность данных: есть ли доступ к продуктовой аналитике (хотя бы события), или “у нас всё на ощущениях”.
5. Посмотрите на власть приоритизации: кто решает “делаем / не делаем”. Если никто — готовьтесь к хаосу.

Частые вопросы