Бизнес-анализ от а до я: профессионализм без усилий

Планирование начинается ещё до того, как сформированы все артефакты. Оно включает в себя создание “картины” проекта: его фазы, этапы, участников, зависимости, риски и подход к приоритезации. Именно с планирования должен начинаться любой проект – без этого невозможно понять, откуда стартовать и куда идти.

Планирование включает:

•      определение ключевых компонентов объема работ;

•      предварительные оценки и распределение по фазам/спринтам;

•      составление и верификацию roadmap (дорожной карты проекта);

•      выявление рисков и технических/организационных зависимостей;

•      согласование с заинтересованными сторонами;

•      построение общего нарратива: «что будет сделано», «в какой последовательности», «кем» и «зачем».

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

Декомпозиция объема работ

Этот навык я подробно описывал в своей предыдущей книге – с акцентом на разбиение задач в ежедневной операционной деятельности. Сейчас я расширяю его до уровня проектного мышления: Декомпозиция объема работ – это умение BA разбить крупный блок работы на логически связанные и управляемые части, так, чтобы обеспечить эффективность планирования, исполнения и контроля.

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

Также важно понимать: разный уровень декомпозиции может использоваться на разных уровнях управления. Например, для roadmap достаточно фреймворков и фаз, а для задач в спринте – уже нужны конкретные функции.

Контроль объема работ

Определить объём – недостаточно. BA должен уметь удерживать всю картину в актуальном состоянии. Контроль – это непрерывное наблюдение и вмешательство при необходимости. Это означает:

•      отслеживание прогресса по всем компонентам скоупа;

•      актуализация roadmap и декомпозиции при появлении новых требований;

•      оперативное выявление рисков и влияния изменений на уже запланированные части;

•      постоянное присутствие в роли координатора, например между командой, PO и внешними участниками.

Я считаю, что по-настоящему зрелый BA способен в любой момент времени сказать: «Я знаю, какая часть объема завершена, какая – в процессе, а какая – под риском».

На уровне результато-ориентированного БА развитие этого навыка ожидается на базовом уровне с последующим развитием и масштабированием на следующих уровнях. Под базовым уровнем я подразумеваю масштаб применения навыка именно в БА области работ, в то время как для следующих уровней это уже может быть уровень всей команды и далее уровень пилота всего проекта или например пилота программы или продукта.

Пример из практики

На текущем проекте мы создаём мультимедийное приложение в стиле Netflix. Я работаю с командой, ответственной за фронтенд и запуск платформ.

У меня есть чёткая декомпозиция скоупа на трёх уровнях:

•      фазы проекта

•      ключевые майлстоуны

•      фичи/функции

Также у меня есть постоянно обновляемая информация о статусе, задержках, рисках и точках блокировки. Благодаря этому, например, я знаю, что в данный момент реализация компонента A невозможна, пока не будет завершён компонент B от другой команды. Это исключает сценарий, когда команда тратит ресурсы на работу, которая всё равно не может быть реализована в ближайшее время.

Применение

Много лет назад (а точнее – спустя три года моей работы в роли бизнес-аналитика в первой ИТ-компании), я уже достиг уровня зрелого РО BA. Формально моя должность звучала как Senior Business Analyst, и в этот момент мне доверили участие в новом клиентском проекте.

Мне нужно было запланировать и реализовать продуктовый каталог для корпоративного заказчика. Я вошёл в проект на ранней стадии, и в первый же день ко мне подошёл Delivery Manager. Он сказал: «Я не работал с тобой раньше, и первое, что мне нужно от тебя – это план работ с детализацией до часов».

Он не просил юзер-стори. Не интересовался, сколько времени займёт discovery. Он хотел видеть чёткий и детализированный план объёма бизнес-аналитических работ с горизонтом в два года. Это был первый по-настоящему серьёзный вызов для меня как Пилота объема работ. Что я сделал:

Шаг 1. Построение карты типов работ

Я начал с оценки типов работ, которые могут потребоваться:

•      написание различных типов требований (data model, functional, UI/design),

•      встречи с клиентами, командой и стейкхолдерами,

•      онсайт и оффсайт активности,

•      анализ и документация,

•      поддержка дев/QA-команд,

•      валидация артефактов с заказчиком,

•      организация процессов,

•      конфигурационные действия для подготовки самого каталога.

Это был мой “базовый инструментарий” – всё, что BA должен уметь делать в течение жизненного цикла подобного проекта.

Шаг 2. Декомпозиция продукта

Затем я перешёл к декомпозиции самого продуктового решения. Я разбил будущий каталог на два уровня компонентов, которые предстояло:

•      проанализировать,

•      описать,

•      выдать в виде конкретных артефактов и решений.

Это создало основу для дальнейшей детализации оценки.

Шаг 3. Маппинг работ на продуктовые компоненты

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

Шаг 4. Оценка в часах

Затем началась самая кропотливая часть – я вручную оценивал, сколько часов заняла бы у меня каждая из этих задач.

Я учитывал не только время на саму работу, но и мой собственный уровень производительности. Так, например:

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

•      я сравнивал, сколько часов такая задача заняла бы у меня, и выводил коэффициент, насколько медленнее (в среднем) будет работать менее опытный аналитик;

•      на основе этого я рассчитывал количество BA, которое потребуется, чтобы уложиться в 2-летний график проекта.

Пример: если мне нужно было бы 100 часов, а BA с базовыми навыками делает ту же работу в Х раз медленнее, значит, нужно уже например 150 часов, а не 100. Далее я определял сколько человек потребуется, чтобы конфигурация не стала узким местом проекта.

Шаг 5. Финализация и защита плана

На основе всех этих данных я собрал план работ на два года, с точной оценкой в часах, распределением задач, типами исполнителей и учётом рисков. Я презентовал его Delivery Manager’у – и получил одобрение. Проект начался уже с чётким и структурированным скоупом, что дало мне контроль в дальнейшем.

В итоге, по завершении проекта, план отклонился от фактического выполнения всего на 19–20%. Для первой серьёзной попытки планирования с таким уровнем точности это был отличный результат – и с тех пор этот подход стал моей профессиональной опорой в любых проектах.

Челенджи / сложности

Множество неизвестных на старте планирования

Одна из ключевых сложностей при планировании объема работ – это большое количество неизвестных. Это естественно: когда создаётся что-то новое, невозможно сразу иметь полное понимание типа, содержания и объема задач. Что бы ни было запланировано – всегда появятся дополнительные элементы и корректировки.

Сложность усиливается тем, что людям по природе ближе ясность и определенность. Но с новым скоупом так бывает редко. При этом сроки на начальное планирование часто крайне сжаты – нужно начинать работы «ещё вчера».

Типичный ответ на вопрос: «Сколько времени займёт создание этого компонента?» – «Сначала нужно провести дискавери». Однако на полноценную дискавери (2–8 недель) зачастую нет времени, несмотря на её важность.

В таких ситуациях мой подход – сфокусироваться на достижении результата с разным уровнем точности. Даже неточный план – это всё равно план. Он даёт старт, создаёт основу для движения, снижает неопределённость.

Что я делаю:

•      Использую текущие знания и опыт, чтобы составить черновой план

•      Разбиваю задачи на части и прикидываю длительность каждой

•      При необходимости обращаюсь к внешним источникам (включая интернет и внутренние базы знаний)

•      Закладываю буферы и указываю на зоны риска

Главная задача в условиях неопределённости – как можно быстрее встроиться в контекст и собрать максимум исходных данных. Это ускоряет переход от тумана к структуре.

Определение критериев декомпозиции

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

•      По технологическому стеку: фронтенд, бэкенд, интеграции, аналитика

•      По функциональным блокам: логин, каталог, корзина, заказ, оплата

•      По типу работ: анализ, дизайн, реализация, тестирование

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

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

2.      Изучаю максимум контекста: цели продукта, тип команды, ограничения

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

Баланс: время – ресурсы – цели

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

•      Мало ресурсов → нужно больше времени

•      Меньше времени → нужны дополнительные ресурсы

•      Недостаток времени и ресурсов → нужно сокращать объем

Мой подход в таких ситуациях:

•      Оценка рисков по каждому из параметров

•      Раннее предупреждение менеджеров, особенно по вопросу ресурсов. Лучше заявить о дефиците квалифицированных специалистов в самом начале, чем пытаться закрыть пробел на поздних стадиях

•      Гибкость целей – обсуждение возможности перераспределения объема работ или приоритизация задач

Из трёх параметров ресурсы – самый чувствительный. Время обычно более гибкое, а скоуп может быть адаптирован. Поэтому я начинаю с оценки ресурсных ограничений и только потом выстраиваю остальные параметры. Любые изменения обязательно проговариваю с проектным менеджментом, так как они влияют на стратегию и результат проекта.

Вопросы для самопроверки

Вопрос 1:

Ты как БА подключился к проекту, где уже работают три бизнес-аналитика. У каждого из них – своя Scrum-команда, отвечающая за определённый компонент нового веб-сайта по продаже обуви. Тебя назначают ответственным за компонент “Каталог продуктов”. К концу недели твоя команда ожидает:

•      План разработки компонента,

•      Разделение на логические части,

•      Подготовленные пользовательские истории на следующий спринт.

Вопрос:

Какие действия ты предпримешь на этой неделе, чтобы качественно подготовиться к обсуждению с командой в пятницу?

Вопрос 2 (продолжение):

Прошло четыре спринта (два месяца). Возникла проблема: команда отстаёт от плана на 35%. На ретроспективе команда сообщает, что пользовательские истории требуют постоянных уточнений у аналитика, из-за чего тратится лишнее время и не удаётся завершать запланированный объём. При этом оценки спринтов команда считает адекватными.

Вопрос:

Проанализируй ситуацию. Укажи по две возможных причины / проблемы / зоны улучшения в каждой из следующих областей:

•      Планирование объема работ

•      Декомпозиция работ

•      Контроль выполнения работ

Применение вне работы

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

Я фиксирую всё: планы по профессиональному развитию, важные личные цели, семейные задачи, хобби. Обычно набирается от 7 до 12 крупных направлений. После этого я распределяю их по кварталам – важно видеть, в каком периоде какие крупные фокусы будут у меня в жизни.

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

Завершающий этап – создание записи с чекбоксами в приложении. Этот список всегда под рукой: на телефоне и на ноутбуке. Я регулярно сверяюсь с ним, отмечаю выполненное, корректирую приоритеты.

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

Ремарка

Хочу поделиться своим образом мышления относительно этого навыка.

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

Но моё мышление устроено немного иначе. Я всегда чувствовал: если я хочу развиваться, значит, должен хотя бы чуть-чуть выходить за границы привычного. Это «чуть-чуть» – как песчинка. Но со временем они складываются в навык.

Навык планирования – или, проще говоря, умение чётко ответить себе и другим на вопрос «А что дальше?» – это, на мой взгляд, один из самых естественных и органично развивающихся скиллов для бизнес-аналитика. Его можно тренировать параллельно с основными обязанностями – и он обязательно пригодится. На проектах, в продуктах, в программах, в личном развитии.

И, в завершение фраза, которая только что пришла в голову: план – это эффективное начало любой активности человека.

Презентер решений

/Solution Presenter/

Описание

Как часть своего профессионального роста результато-ориентированный бизнес-аналитик начинает развивать способность эффективно представлять решения, чтобы заинтересованные стороны могли увидеть реальное влияние предлагаемых результатов на бизнес-цели. Описывая этот навык, я бы хотел сделать особенный акцент именно на словосочетании в названии – “презентер решений”. Речь идёт именно об умении представлять решения.

Это важно, так как часто также упоминается софт-навык презентации, отражающий общее умение человека общаться с аудиторией и делать презентации. Однако “презентер решений” – это более узкая и значимая для бизнес-аналитика категория, потому что именно аналитик в большинстве случаев ответственен за презентацию решения или за её оркестрацию (так как презентация может включать в себя технические, архитектурные или другие детали, которые презентуют другие члены команды).

Основными компонентами процесса и навыка презентации решений являются:

•      подготовка презентации,

•      понимание решения,

•      ведение презентации,

•      обработка результатов презентации.

Поэтому определение этого навыка я сформулировал бы следующим образом:

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

Если меня спросить оценить сложность этих компонентов по 10-балльной шкале, я бы сказал:

•      подготовка – 10 баллов,

•      понимание – 4 балла,

•      ведение – 6 баллов,

•      обработка – 2 балла.

Хотя сложность выполнения компонентов разная, важность всех компонентов высокая.

Возможно, это звучит очевидно, но я хочу обозначить это явно: подготовка именно презентации решения (а не просто презентации чего-либо – например, первого митинга с клиентом, обсуждения пяти требований, по которым есть вопросы, или презентации бэклога для следующего спринта) – это самый сложный этап. Давайте разберём специфику каждого компонента подробнее.

Подготовка

Подготовка презентации решения включает в себя несколько ключевых пунктов:

1. Анализ целевой аудитории, для которой будет сделана презентация.

Важно понимать, кому будет адресована презентация, чтобы правильно выбрать формат, объём и участников презентации. Да-да, участников-презентёров может быть несколько, и это задача бизнес-аналитика – определить их состав и зоны ответственности каждого.

Целевая аудитория – это те люди (стейкхолдеры), для которых подготавливается презентация решения. Аудитория может быть однородной (например, сотрудники одного отдела, одной роли, одного домена) или разнородной (например, менеджеры C-уровня, операционные работники, конечные пользователи, представители разных департаментов).

Да, целевая аудитория может измениться в последний момент перед началом презентации, но базовый анализ и понимание должны быть проведены заранее.

2. Формат презентации как артефакта.

Формат зависит от целевой аудитории и типа решения. Например, если аудитория смешанная – менеджеры и технический персонал, – формат, скорее всего, должен быть тоже смешанным: сочетание верхнеуровневого визуально-понятного описания с техническими деталями в нужных местах (например, архитектурная диаграмма).

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

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

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

Тип решения также влияет на формат – это может быть описание процесса, технического backend-решения или дизайн frontend-платформы, и каждый случай требует своего подхода.

3. Объём презентации как артефакта.

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

Например, нет смысла тратить пять слайдов на описание API, если API – лишь одна из десяти частей продукта и её вариативность вряд ли повлияет на общее решение.

Объём также зависит от формата презентации как процесса. Если ожидается активное взаимодействие с аудиторией, на каждый раздел должно быть запланировано определённое количество минут. Также нужно заранее предусмотреть блок вопросов и ответов в конце.

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

Если на встрече говорят: «Оставшиеся слайды, пожалуйста, изучите офлайн», – это плохая практика. У аудитории сразу возникнет вопрос: «Если 30% мы должны смотреть офлайн, то зачем тогда тратить время на остальные 70%, которые тоже можно было бы посмотреть в своём темпе?»

4. Формат презентации как процесс (ведение презентации).

Важно учитывать не только презентацию как артефакт (документ в PowerPoint, Miro, Confluence и т.п.), но и сам процесс презентации:

•      Что будет озвучено БА, а что останется на слайде?

•      Какие инструменты будут использоваться?

•      Кто будет помогать?

•      Кто отвечает за документирование вопросов и решений?

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

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

5. Определение ожидаемых результатов.

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

И, как при выявлении требований, важно достичь единого понимания в команде.

Примеры:

•      БА считает, что цель – обсудить e2e-процесс;

•      технический лидер – что надо выбрать стек для фронтенда;

•      архитектор – что главное – определить список интеграций.

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

Понимание решения

На первый взгляд, этот компонент кажется очевидным: “если я подготовил презентацию решения – значит, я его понимаю”. Но на практике я всегда стараюсь отдельно и осознанно убедиться, что действительно понимаю презентуемое решение как единое и целостное предложение. Неважно, готовил ли я презентацию сам, совместно с командой или получил уже готовый материал. Даже в случае полной самостоятельной подготовки я всё равно задаю себе вопрос: “А действительно ли я понимаю, что именно и зачем будет презентовано?” Для этого я опираюсь на несколько ключевых критериев:

1. Терминология

Для меня принципиально важно понимать каждое слово, каждый термин и каждый акроним, используемые в презентации, и именно в контексте данной презентации. Иногда, почти автоматически, я могу вставить привычную аббревиатуру или фразу, а потом, просматривая презентацию финально, спросить себя: “А что это конкретно означает в контексте этого решения?” – и выяснить точное значение, вплоть до поиска внешних определений.

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

2. Консистентность и согласованность

Я всегда проверяю, насколько презентация согласована: есть ли логика в структуре и порядке подачи? Все ли части решения представлены связно? Нет ли разрывов в повествовании между, например, функциональной частью и архитектурной?