Мнение 21/09/2022

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

Business Analyst в NIX

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

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

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

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

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

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

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

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

На входе есть требования проекта и его цели — то есть, что нам нужно сделать и зачем.

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

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

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

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

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

общая цель проекта;
запланированные стадии;
активные и будущие стадии, если речь идет о существующем проекте;
имеющиеся и ожидаемые артефакты деятельности BA по каждой стадии проекта.

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

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

удовлетворенность стейкхолдеров;
прогнозируемость и повторяемость результатов;
быстрый онбординг новых аналитиков;

прозрачность взаимодействия для клиента и команды.

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

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

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

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

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

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

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

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

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

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

Роль бизнес-аналитиков

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

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

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

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

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

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

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

Требования — бизнесовые и (не)функциональные.
Road Map — графический обзор целей и результатов проекта, представленных на временной шкале; должно быть простым и понятным.
Определение приоритетов — кто и как определяет приоритеты и согласно чему.
Release Notes — это может быть написание релиз-ноутсов по определенному формату, утвержденному клиентом.
Demo Notes — здесь можно указывать, как проходят ваши демо, кто их проводит, что должно быть зафиксировано после встреч; стоит прописать, ожидаете ли вы замечания сразу после демо или во время обсуждения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stakeholder Communication Plan

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

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

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

Правила взаимодействия

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

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

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

Requirements Management Plan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Быстрый онбординг

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

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

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.