Основы

Кто такой бизнес-аналитик

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

По материалам: IIBA, Руководство BABOK® v3, разд. 2.4.1; IIBA, Global Business Analysis Core Standard; К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 4; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., гл. 1.

На этой странице

Главные идеи#

Роль, а не должность#

В Руководстве BABOK® бизнес-анализ (business analysis) — это работа, которая делает возможными изменения в организации: выяснить, что нужно организации, а затем рекомендовать решения, которые приносят ценность тем, кого затрагивает изменение. Бизнес-аналитик — тот, кто отвечает за эту работу. Руководство BABOK также считает аналитика заинтересованной стороной в любой деятельности по бизнес-анализу: он отвечает за работу и иногда координирует вклад в неё других ролей.

Многие делают эту работу под другими названиями. Стандарт IIBA Global Business Analysis Core Standard перечисляет, среди прочих, системного аналитика, аналитика процессов, аналитика данных, менеджера или владельца продукта, консультанта по управлению и бизнес-архитектора. Вигерс и Битти добавляют аналитика требований, инженера по требованиям и ИТ-аналитика. Книга BCS представляет аналитика как внутреннего консультанта, который исследует бизнес-ситуации, оценивает варианты улучшений, определяет требования и помогает бизнесу получать ценность от информационных систем.

Как выглядит эта работа#

Вигерс и Битти описывают девять типичных видов деятельности:

  1. Определить бизнес-требования (зачем нужно изменение).
  2. Спланировать работу с требованиями.
  3. Определить заинтересованные стороны и классы пользователей.
  4. Выявить требования.
  5. Проанализировать их.
  6. Задокументировать их.
  7. Донести их до тех, кому они нужны.
  8. Руководить их валидацией.
  9. Организовать приоритизацию и управлять требованиями на протяжении всей работы.

В терминах Руководства BABOK эта работа распределена по всем шести областям знаний: Планирование и мониторинг бизнес-анализа, Выявление и сотрудничество, Управление жизненным циклом требований, Анализ стратегии, Анализ требований и определение дизайна и Оценка решения. Как вы её выполняете, зависит от ваших базовых компетенций и от ракурса, в котором вы работаете (Agile, BI, ИТ, бизнес-архитектура, управление процессами).

Типичные рабочие продукты#

Чем роль отличается от соседних#

Роль Главный фокус Где пересекается с бизнес-анализом
Руководитель проекта Выполнение проекта: баланс границ, бюджета, сроков, ресурсов, качества и рисков (так эту роль описывает Руководство BABOK) Вигерс и Битти: руководитель проекта отвечает за коммуникацию о проекте, аналитик — о продукте.
Системный аналитик Как будет работать ИТ-решение: поведение системы, данные, интерфейсы Книга BCS считает системный анализ в ИТ соседней областью, которую некоторые организации объединяют с бизнес-анализом в роль «ИТ-бизнес-аналитика».
Владелец продукта Ценность продукта: видение, дорожная карта, порядок бэклога В ракурсе Agile Руководства BABOK роль аналитика может играть владелец продукта, бизнес-аналитик или кто-то ещё. Аналитики часто выступают прокси-владельцем продукта.
Аналитик стратегии / бизнес-архитектор Направление развития и структура предприятия Книга BCS выносит стратегический анализ в основном за пределы роли аналитика, но ожидает, что аналитик понимает стратегию, которой служит.

Когда один человек совмещает роли, Вигерс и Битти подчёркивают, что это всё равно две разные работы, которым нужны разные навыки.

Что отличает хороший анализ#

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

Как применять#

  1. Запишите свою зону ответственности. Отметьте, какие из девяти видов деятельности выполняете вы, какие — кто-то другой, а какие — никто. Бесхозные виды деятельности — это риски.
  2. Не смешивайте роли. Если вы ещё и руководите проектом или владеете продуктом, разделяйте вопросы о продукте и вопросы о проекте и говорите, в какой роли сейчас выступаете.
  3. Договоритесь о результатах заранее. Для каждого рабочего продукта назовите аудиторию, формат и срок.
  4. Оспаривайте решения, замаскированные под требования. Спросите, какую проблему решает запрос (см. принцип «Зачем? Что? Как?»).
  5. Проявляйте творческий подход открыто. Вигерс и Битти призывают аналитиков предлагать возможности, о которых заказчики не подумали, но выносить их на одобрение, а не реализовывать втихую.

Пример#

Владелец «Мастерской», вымышленной сети из 12 веломастерских, говорит: «Нам нужно приложение, как у больших сетей». Аналитик не начинает с перечня экранов. За первые недели он:

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

Подводные камни#

  • Роль секретаря. Записывать, что говорят люди, — ещё не анализ. Спрашивайте «зачем», сравнивайте источники, ищите пробелы.
  • Слепые зоны из-за прошлого опыта. Вигерс и Битти отмечают, что аналитики обычно приходят в профессию из пяти типичных групп: бывшие пользователи, бывшие разработчики или тестировщики, руководители проектов, эксперты в предметной области и выпускники без опыта. Бывшие пользователи склонны слишком рано описывать требования как экраны. Бывшим разработчикам может не хватать терпения в общении с пользователями.
  • Недооценка роли. Вигерс и Битти приводят оценки по модели COCOMO II: опытный аналитик может сократить трудозатраты проекта примерно на треть по сравнению с неопытным.

Источники и что почитать#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Разд. 2.4.1 (бизнес-аналитик как заинтересованная сторона); разд. 11 (ракурсы Agile и «Информационные технологии»).
  • IIBA. Global Business Analysis Core Standard. International Institute of Business Analysis. Разд. «Who is a Business Analyst?».
  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 4 (бизнес-аналитик: задачи, навыки, пути в профессию).
  • D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 1 (роль, границы и руководящие принципы).