Михаил Бахрах – Бизнес-анализ от а до я: профессионализм без усилий (страница 9)
Я ставлю себе вызов: «А могу ли я достичь того же результата, но быстрее?»
Такой взгляд помогает не просто управлять временем, а усиливать свою эффективность – и на работе, и за её пределами.
Пилот объема работ – планирование, декомпозиция и контроль
/Scope Pilot/
Описание
После навыков, связанных с артефактами и активностями, мы подходим к следующему блоку – к навыку, который отвечает не столько на вопрос “как?”, сколько на “что?”. Что именно нужно сделать? Что включает в себя наш путь? Что составляет продукт или проект?
Речь идёт об объёме работ (scope of work) – одном из самых часто употребляемых и ключевых понятий в любой проектной деятельности. Без чёткого понимания, из чего состоит объём работ, и без системного подхода к его планированию, декомпозиции и контролю практически невозможно добиться успеха ни в одном проекте. И любой артефакт или активность теряют свою ценность, если не встроены в понятный и управляемый скоуп.
На этом уровне BA я называю этот навык “Пилот объёма работ” – человек, который не просто участвует в проекте, а ведёт его по траектории выполнения объёма работ, как пилот ведёт самолёт по маршруту. Он понимает, как построен скоуп, умеет навигировать в нём сам и способен помогать другим.
Этот навык складывается из трёх компонентов:
1. Планирование объема работ
2. Декомпозиция объема работ
3. Контроль объема работ
Это не последовательные стадии, а скорее параллельно применяемые практики, которые BA осваивает и комбинирует на протяжении всей жизни проекта. Обсудим кратко каждую.
Планирование объема работ
Планирование начинается ещё до того, как сформированы все артефакты. Оно включает в себя создание “картины” проекта: его фазы, этапы, участников, зависимости, риски и подход к приоритезации. Именно с планирования должен начинаться любой проект – без этого невозможно понять, откуда стартовать и куда идти.
Планирование включает:
• определение ключевых компонентов объема работ;
• предварительные оценки и распределение по фазам/спринтам;
• составление и верификацию 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. Маппинг работ на продуктовые компоненты
Далее я построил таблицу, в которой по горизонтали разместил продуктовые компоненты, а по вертикали – типы бизнес-аналитических работ. Это дало мне удобный и наглядный способ разложить проект по полочкам.