qvib.pro
EN

Business Analyst

Мост между бизнесом и разработкой: собирает требования и описывает процессы.

бесплатно любой

Кто это и зачем нужен

Business Analyst — мост между бизнесом и разработкой. Его миссия — перевести расплывчатую потребность бизнеса («хотим, чтобы клиенты быстрее оформляли заказ») в понятные, проверяемые, непротиворечивые требования, по которым команда может строить. BA говорит на двух языках: бизнеса и IT — и устраняет разрыв между ними.

Боль, которую он закрывает: бизнес и разработка понимают задачу по-разному, требования живут в головах и переписках, на демо выясняется «мы имели в виду не это». BA фиксирует и согласовывает, что именно нужно, ДО кода.

Что ломается без него: требования размытые и противоречивые, процессы «as-is» никто не описал, скрытые краевые случаи всплывают на проде, переделки съедают бюджет. Бизнес и команда обвиняют друг друга.

День из жизни

Утро. Встреча со стейкхолдером: выясняет реальную потребность за «хотелкой» (5 почему), фиксирует процесс as-is — как сейчас и где боль. День. Структурирует собранное: рисует BPMN-диаграмму процесса to-be, формулирует требования и user stories, ищет пробелы и противоречия («а что, если заказа нет?»). Согласовывает с командой на feasibility. Вечер. Обновляет BRD/SRS, ведёт матрицу трассировки (каждое требование → откуда пришло → чем покрыто), готовит вопросы к следующему уточнению.

Ключевые навыки

Hard: элиситация требований (интервью, воркшопы), моделирование процессов (BPMN/UML), написание BRD/SRS и user stories, анализ as-is/to-be, трассировка требований, gap-анализ, базовый SQL/данные. Soft: активное слушание и «правильные вопросы», перевод между бизнесом и IT, разрешение противоречий, документирование ясно и однозначно, переговоры со стейкхолдерами.

Артефакты, которые пишет

  • BRD / SRS — бизнес- и системные требования.
  • User Stories — требования глазами пользователя.
  • BPMN-диаграммы — процессы as-is / to-be.
  • Матрица трассировки — требование ↔ источник ↔ покрытие. Истории и критерии оформляет по User Story и Definition of Ready из базы; передаёт System Analyst для технической постановки.

Как ИИ/вайб-кодинг усиливает роль

  1. Структурирование сырых требований. Промт: «Вот сырые заметки со встречи <вставить>. Структурируй в требования (функциональные/нефункциональные), выдели пробелы, неоднозначности и противоречия списком уточняющих вопросов.»
  2. Процессная диаграмма. Промт: «По описанию процесса <…> построй текстовое описание BPMN (роли, шаги, ветвления, исключения) и список краевых случаев, которые легко упустить.»
  3. User stories из требований. Промт: «Преврати эти требования <…> в набор user stories по INVEST с критериями приёмки Given/When/Then.»
  4. Gap-анализ as-is/to-be. Промт: «Сравни процесс as-is <…> и желаемый to-be <…>: что меняется, какие новые требования и риски возникают.»
  5. Проверка непротиворечивости. Промт: «Проверь набор требований <…> на конфликты и дубли, отметь требования без чёткого критерия проверки.»

Путь развития: Junior → Middle → Senior → Lead

  • Junior BA: собирает и документирует требования по шаблону под присмотром, ведёт трассировку.
  • Middle BA: самостоятельно ведёт элиситацию, моделирует процессы, согласовывает требования со стейкхолдерами и командой.
  • Senior BA: работает со сложными доменами, влияет на продуктовые решения, наставляет, выстраивает практику анализа.
  • Lead BA / Business Analysis Lead: координирует команду аналитиков, стандарты требований, связь с продуктом и архитектурой.

Частые ошибки и как избежать

  • Записал «хотелку» как требование. → Копай до настоящей потребности (зачем за хотелкой), 5 почему.
  • Требования без критерия проверки. → Каждое требование должно быть проверяемым (как поймём, что выполнено).
  • Игнор краевых случаев и исключений. → Спрашивай «а что если…»; happy path — лишь часть.
  • Документ ради документа. → Артефакт должен помогать команде строить, а не лежать «для галочки».
  • Не согласовал с разработкой. → Проверяй feasibility и трассировку, иначе требование нереализуемо.

Что освоить (мини-программа)

  • Концепции: BABOK (свод знаний BA), элиситация, BPMN/UML, as-is/to-be, нефункциональные требования, трассировка, gap-анализ.
  • Инструменты: Confluence/Notion, draw.io/BPMN-редакторы, Jira, SQL-клиент.
  • Почитать: BABOK Guide; «Software Requirements» К. Вигерс; материалы по BPMN.

Зарплатные ориентиры (RU)

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

    Зависит от грейда, домена, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Прямого mapsTo нет, но бизнес-сторона требований ближе всего к агенту analyst. В Quest analyst на фазе спеки помогает превратить задачу владельца в проверяемые EARS-требования и критерии приёмки — это и есть «перевод потребности в требование», ядро роли BA. Техническую детализацию подхватывает System Analyst (тоже analyst).

🤖 Промт-персона

Ты — опытный Business Analyst, мост между бизнесом и разработкой. Помогаешь мне превращать расплывчатые пожелания в чёткие, проверяемые, непротиворечивые требования. Всегда сначала докапывайся до настоящей потребности за хотелкой (зачем, какую боль решаем). Структурируй требования на функциональные/нефункциональные, проси недостающее списком уточняющих вопросов, активно ищи краевые случаи и исключения («а что если…»). Каждое требование делай проверяемым. По запросу строй BPMN-описания процессов as-is/to-be и user stories по INVEST с Given/When/Then. Документируй ясно и однозначно.

Read in English →