ru:https://highload.today/blogs/hvatit-izobretat-velosiped-kak-pravilno-postroit-protsessy-biznes-analiza-poshagovyj-gajd/ ua:https://highload.today/uk/blogs/dosit-vinahoditi-velosiped-yak-pravilno-pobuduvati-protsesi-biznes-analizu-pokrokovij-gajd/
logo
Мнение      21/09/2022

Хватит изобретать велосипед: как правильно построить процессы бизнес-анализа — пошаговый гайд

Анна-Марія Чміль BLOG

Business Analyst в NIX

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

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

Как выглядит процесс бизнес-анализа и когда его стоит строить

Любой процесс — это совокупность взаимосвязанных и взаимодействующих видов деятельности. На входе есть базовая информация. На ее базе выполняется определенная активность, а на выходе возникают результаты данной активности.

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

Схематически изображена работа бизнес-аналитика

Схематическое изображение работы бизнес-аналитика

Рассмотрим процесс бизнес-анализа подробнее:

  • На входе есть требования проекта и его цели — то есть, что нам нужно сделать и зачем.
  • На основе этой информации формируется бизнес-процесс, и на него оказывают непосредственное влияние стейкхолдеры.
  • На выходе получаем определенные артефакты. Это выводы о том, как работать на проекте по каждому направлению. Сюда относятся планы коммуникации со стейкхолдерами, изменения требований.

Далее поговорим о каждом входном пункте отдельно.

Требования проекта

Прежде всего мы должны исследовать сам проект. Для этого бизнес-аналитикам следует разобраться в его требованиях.

К ним относятся:

Англійська для початківців від Englishdom.
Для тих, хто тільки починає вивчати англійську і хоче вміти використовувати базову лексику і граматику.
Реєстрація на курс
  • общая цель проекта;
  • запланированные стадии;
  • активные и будущие стадии, если речь идет о существующем проекте;
  • имеющиеся и ожидаемые артефакты деятельности BA по каждой стадии проекта.

Цели по производительности BA-процесса

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

  • удовлетворенность стейкхолдеров;
  • прогнозируемость и повторяемость результатов;
  • быстрый онбординг новых аналитиков;
  • прозрачность взаимодействия для клиента и команды.
  • Онлайн-курс "Business English for Marketers" від Laba.
    Опануйте професійну англійську для маркетингу.Розширте карʼєрні можливості для роботи з іноземними колегами: від розробки нових продуктів до презентації стратегії бренду.
    Детальніше про курс

Стейкхолдеры

Часто под стейкхолдерами подразумевают только заказчиков и разработчиков. Но не только они оказывают влияние на построение процесса бизнес-анализа. На иллюстрации ниже можно увидеть, как все виды стейкхолдеров распределяются в зависимости от степени их близости к проекту:

Виды стейкхолдеров в зависимости от степени их близости к проекту.

Виды стейкхолдеров в зависимости от степени их близости к проекту.

  • Команда проекта. Это люди, непосредственно занимающиеся разработкой продукта. Сюда относятся девелоперы и все принимающие решения по проекту в ходе работы над ним.
  • Связанные подразделения. Эта категория включает тех, чья работа изменится после получения продукта. Это могут быть конечные пользователи и, например, служба поддержки.
  • Организации или предприятия. Эта группа специалистов может не касаться разработки и даже не затрагивать продукт, но взаимодействовать с предыдущей категорией. К примеру, это инвесторы или CTO компании-заказчика.
  • Наружные стейкхолдеры. Эти люди могут не знать о продукте, но они влияют на его работу и развитие. Например, поставщики и законодательные органы, регулирующие отрасль.

Построение процесса бизнес-анализа – 5 основных шагов

Вышеописанные моменты мы получаем на входе в новый или уже активный проект. После этого начинается основная деятельность BA.

Для наглядности в некоторых случаях я буду ссылаться на реальный проект из своей практики. Этот кейс касается модернизации существующего сайта для фрилансеров. Над ним работали несколько команд: со стороны заказчика, моя команда и третья, посторонняя.

Схематический процесс бизнес-анализа

Схематический процесс бизнес-анализа

1 Определение ожиданий

В нашем случае это было особенно важно, учитывая наличие нескольких независимых команд разработки. Речь идет об ожиданиях не к продукту, а именно к процессу. На старте следует понимать, как мы будем общаться, описывать и утверждать изменения. Для этого определите:

  • Роль бизнес-аналитиков
  • Курс-професія "Дизайнер інтер'єрів" від Skvot.
    Велика практична програма для всіх, хто хоче засвоїти професію дизайнера інтер'єрів і заробляти на реальних проєктах відразу після курсу. Досвідом та інсайтами діляться одразу три лектори.
    Програма курсу

Первоочередная задача — понять видение стейкхолдерами задач BA. В моем проекте было три бизнес-аналитика. Наша команда занималась фронтендом, потому я описывала только эту часть продукта. Внешняя команда занималась бэкендом, соответственно их BA описывал бэк. Аналитик на клиентской стороне писал требования для нас обоих.

  • Ожидание документации

Необходимо выяснить, где фиксировать требования, в каком формате и с какой структурой. У нас заказчик хотел собирать требования ClickUp, но этот инструмент не подошел. Программа хороша для заметок, но писать требования по привычным стандартам в ней неудобно. В поисках оптимального решения мы со стейкхолдерами сравнили их и наши темплейты. Они оказались схожими, отличия были только в названиях и дополнительных секциях. Я уточняла необходимость практически каждой детали темплейта. В результате мы определили список нужных документов и их формат. В ClickUp мы оставили небольшую часть с приоритетом, поскольку там есть тикеты. Основные требования решили писать в Confluence на стороне третьей команды.

  • Ожидания по коммуникации

Бизнес-аналитикам важно разобраться, с кем и что они должны обсуждать. Мне нужно было вести коммуникацию с обоими аналитиками и Рroduct Owner.

2 Определение результатов деятельности

После того, как вы узнали ожидания стейкхолдеров, определите желаемые результаты работы бизнес-аналитиков. Речь идет о конкретных артефактах, форматах и ​​шаблонах. К ним относятся:

  • Требования  — бизнесовые и (не)функциональные. 
  • Road Map  — графический обзор целей и результатов проекта, представленных на временной шкале; должно быть простым и понятным.
  • Определение приоритетов  — кто и как определяет приоритеты и согласно чему.
  • Онлайн-курс "Project Manager" від Laba.
    Станьте проджектом, що вміє передбачати ризики наперед і доводити проєкт до результату, який хочуть замовники. Поділиться досвідом Павло Харіков, former Head of PMO в Kyivstar.
    Програма курсу і реєстрація
  • Release Notes  — это может быть написание релиз-ноутсов по определенному формату, утвержденному клиентом.
  • Demo Notes  — здесь можно указывать, как проходят ваши демо, кто их проводит, что должно быть зафиксировано после встреч; стоит прописать, ожидаете ли вы замечания сразу после демо или во время обсуждения.

3 Определение типов сессий с командой и клиентом

Они делятся на две группы:

  • сессии, проводимые бизнес-аналитиками: информационные встречи, груминги и т.п.;
  • сессии, в которых аналитики должны участвовать: планинг, демо, спринт-ревью и т.д.

На этом этапе проговорите технические детали проведения мероприятий. Как часто они будут происходить и в каком порядке, на какой платформе будут проходить онлайн-встречи.

4 Презентация подхода

Когда вы пытаетесь на словах объяснить «давайте делать так и так», это никогда не работает.

Поэтому очень важно визуализировать свои идеи по организации BA-процесса. Так вы сможете как можно лучше «продать» стейкхолдерам ваш подход.

Выбираем, кто будет готовить презентацию

Существует множество вариантов оформления презентации. К примеру, в своем проекте я сделала небольшое пошаговое описание. Одна из его частей представлена ​​на следующей иллюстрации. При получении запроса мы в первую очередь выясняем, касается ли он текущего бэкенда. Если да, то эти изменения описывает Ксения, аналиткиня из внешней команды. Если ответ «нет», тогда их описываю я.

Также в своей презентации я показала роль всех аналитиков. Первоначально Рroduct Owner считал, что требований от Чарльза, BA на стороне заказчика, достаточно для старта разработки. Но нет. На схеме я разграничила сферу ответственности всех специалистов. Чарльз определяет бизнес- и юзер-требования, а мы с Ксенией — системные.

Онлайн-курс Бізнес-аналіз. Basic Level від Ithillel.
В ході курсу студенти навчаться техніці збору і аналізу вимог, документуванню та управлінню документацією, управлінню ризиками та змінами, а також навчаться моделювати процеси і прототипуванню.
Приєднатися

Схема, кто за какие требования отвечает

Мне важно было показать процесс обработки созданных Чарльзом требований. Они не могли идти сразу к разработчикам. Сначала их обрабатывают бизнес-аналитики. При этом в процессе задействован UX/UI-эксперт, который производил на основе подготовленных требований мокапы для обновленного сайта.


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

Помните: как бы здорово вы ни разобрали процесс, заказчику он может не подойти.

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

5 Формализация

Финишный этап — суммируем все наработки. В идеале рекомендую сделать для выводов отдельную страницу на Confluence. Там вы сможете описать процесс общения в вашем проекте, какие у кого роли и обязанности, как происходит утверждение изменений и т.д. Это будет прозрачным для вас, команды и клиента. Упорно советую формализовать и утвердить такой документ со всеми участниками процесса. Апрув от клиента избавит вас от возможных недоразумений в будущем.

Выходы процесса бизнес-анализа

Stakeholder Communication Plan

Этот документ важен для дальнейшей работы бизнес-аналитиков. В нем вы подробно описываете:

  • Анализ стейкхолдеров

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

  • Правила взаимодействия
  • Курс QA Manual (Тестування ПЗ мануальне) від Powercode academy.
    Навчіться знаходити помилки та контролювати якість сайтів та додатків.
    Записатися на курс

Это расписание активностей, геолокация, преимущества стейкхолдеров, стандарты эскалации. О последнем скажу отдельно. Представьте, что основной для вас стейкхолдер заболел, ушел в отпуск или просто долго не отвечает. Это может приостановить всю вашу работу. В такой ситуации план эскалации укажет, к кому обращаться за требованиями или апрувом. К примеру, можете написать: «Если через два дня Чарльз не отвечает, BA пишет письмо Рroduct Owner».

  • Потребности в коммуникации

В этой главе описываете, кому и какая информация необходима. Также здесь следует указать способ передачи информации и уровень ее детализации. В моем проекте руководителю над Рroduct Owner достаточно было кратко написать в ClickUp суть новой фичи, а сам Рroduct Owner нуждался в подробном описании будущего функционала.

Requirements Management Plan

Этот план — основной артефакт для бизнес-аналитика. Он делится на две части. Одна из них статическая и касается свойств и хранения требований. В нее входят:

  • организация требований;
  • атрибуты требований;
  • детализация;
  • трассировка;
  • переиспользование;
  • Онлайн-курс "Корпоративна культура" від Laba.
    Як з нуля побудувати стабільну корпоративну культуру, систему внутрішньої комунікації та бренд роботодавця, з якими ви підвищите продуктивність команди, — пояснить HR-директор Work.ua.
    Детальніше про курс
  • доступ и хранение.

Второй блок относится к управлению требованиями. Он более динамичен и включает:

  • принятие решений;
  • управление изменениями;
  • приоритезацию;
  • утверждение.

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


Оценка эффективности процесса бизнес-анализа

BA-процесс не может быть «замороженным». Вы должны постоянно мониторить его и при необходимости вносить изменения.

Советую помнить следующее:

Онлайн-курс "React Native Developer" від robot_dreams.
Опануйте кросплатформну розробку на React Native та навчіться створювати повноцінні застосунки для iOS та Android.
Програма курсу і реєстрація
  • количественные метрики лучше других;
  • усилия по сбору метрик должны быть оправданы;
  • метрики нуждаются в интерпретации;
  • измерять нужно процесс, а не людей.

Что отслеживать и измерять зависит от конкретного проекта. Но я для примера выделю основные категории:

  • Удовлетворенность стейкхолдеров

Для каждой группы заинтересованных лиц используют свои методы оценки удовлетворенности. К примеру, для представителей клиента можно применять техники Customer Satisfaction Survey и Net Promotion Score. Разобраться с удовлетворенностью команд и бизнес-аналитиков помогут ретроспективы, Feedback 360, а также 1-2-1 с менеджером проекта.

  • Прогнозируемость и повторяемость результатов

Укажите время создания артефактов определенного размера, количество циклов ревью, количество Change Request и горизонт беклога. Например, если 10 раз проверяется одна и та же фича, то в процессе есть проблемы. В таком случае может потребоваться дополнительный шаг для демо-требований с командой.

Онлайн-курс Frontend-разробник від Powercode academy.
Курс на якому ти напишеш свій чистий код на JavaScript, попрацюєш із різними видами верстки, а також адаптаціями проектів під будь-які екрани. .
Зарееструватися
  • Быстрый онбординг

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

  • Прозрачность взаимодействия

Оценка этой категории состоит из количества блокирующих вопросов в текущем спринте, времени простоя при ожидании ответа и результатов проверки Health Check.


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

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Курс English For IT: Communication від Enlgish4IT.
Почни легко працювати та спілкуватися з мультикультурними командами та міжнародними клієнтами. Отримайте знижку 10% за промокодом ITCENG.
Інформація про курс

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Ваша жалоба отправлена модератору

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: