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

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

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

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

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

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

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

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

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

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

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

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

• общая цель проекта;
• запланированные стадии;
• активные и будущие стадии, если речь идет о существующем проекте;
• имеющиеся и ожидаемые артефакты деятельности 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-процесса поможет существенно повысить производительность команды. Вы можете избежать многих спорных вопросов во время общения с коллегами и заказчиком. Конечно, этот сценарий можно оптимизировать под особенности вашего проекта. Тем самым сделав свою работу более удобной.