Читать книгу: «Бизнес-анализ от а до я: профессионализм без усилий», страница 3

После первого успешно проведённого дня рождения я задумался: «А ведь через год всё это снова повторится!» И тогда я решил проанализировать пройденные шаги, внести коррективы:

•      поменять порядок задач для повышения эффективности,

•      добавить недостающие шаги,

•      предусмотреть вариативность (например, список мест, где можно купить призы в зависимости от количества детей),

•      заложить временные буферы.

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

Возможно, кто-то спросит: «Зачем так серьёзно подходить к простому празднику?»

Мой ответ прост: профессиональные привычки естественно перетекают в повседневную жизнь.

Если это делает процессы лучше и создаёт больше радости для близких – разве это не замечательно?

Ремарка

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

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

Как именно их осваивать – путь индивидуальный.

Я делюсь своим опытом, подходами и примерами, надеясь, что они помогут вам открыть что-то новое.

Организация и оркестрация активностей

/Activities Setup and Orchestration (Team/Customer)/

Описание

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

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

Организация активности

Когда бизнес-аналитик начинает работу на новом проекте, его первая задача – понять, чем заняться, в каком порядке и почему. Способность быстро и точно сформулировать план действий на основе целей и контекста проекта – признак зрелого РО БА.

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

Я неслучайно говорю об организации активности, а не, например, о “разработке подхода к бизнес-анализу”. Почему? Потому что “подход к БА” – это чаще всего про структуру документов, формат взаимодействия со стейкхолдерами, механики декомпозиции и приоритезации. Это важно, но далеко не то, что критично в первые дни проекта. За всю мою карьеру мне ни разу не приходилось сразу документировать подход к бизнес-анализу в качестве самого первого шага. Всегда есть более срочные и ценные активности.

Что действительно важно на старте – определение объема проекта или продукта. Я чувствую себя неуверенно, пока не составлю цепочку действий, которая приведёт к ясности: “что мы делаем, зачем и где границы этого решения”. Умение быстро и по делу задать эти рамки – одна из важнейших компетенций РО БА.

Организация активности – это:

•      Определение ключевых действий и их цели.

•      Определение приоритета на основе контекста.

•      Выстраивание логической последовательности действий.

•      Декомпозиция крупных задач до управляемого уровня (например, активности, которые можно завершить за день).

•      Постоянная сверка с участниками проекта: менеджером, командой, заказчиком.

Каждый новый проект я начинаю с прямых вопросов:

•      “Что от меня ожидается?”

•      “Какие задачи стоят в приоритете у команды?”

•      “Какие цели у заказчика?”

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

1.      Потребности команды.

2.      Ожидания заказчика.

3.      Моё собственное профессиональное видение как БА.

Оркестрация активности

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

Оркестрация – это комплексный навык, так же агрегирующий в себе:

•      Приоритезацию

•      Декомпозицию

•      Оценку усилий

•      Тайм-менеджмент

Эти навыки должны быть развиты на экспертном уровне. Почему? Потому что именно такая экспертиза позволяет не просто участвовать в активности, а эффективно ими управлять в режиме реального времени.

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

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

Применение

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

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

В какой-то момент вопрос был направлен прямо ко мне:

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

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

С этого момента и началось применение моего навыка вживую.

Я начал действовать не “со следующего утра” и не “после окончания митинга”, а в ту же минуту, как сказал “Да, я займусь этим”.

Вот как шаг за шагом я организовывал эту активность:

1. Понимание контекста – цель и артефакты

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

• Какова основная цель этой активности? (Зачем мы вообще делаем маппинг?)

• Какие артефакты ожидаются на выходе? (Что должно быть создано и в каком виде?)

2. Перехват управления митингом

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

3. Подтверждение плана – быстрый фидбэк-цикл

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

4. Декомпозиция и приоритезация

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

5. Старт активности – конкретика, сроки, исполнители плюс общее сообщение по плану на неделю

Так как сроки были предельно сжаты, в течение часа я подготовил и отправил всем участникам сообщение с:

• Четким описанием задач/активностей и важность и смысл.

• Конкретными сроками – План на неделю;

• Конечную цель;

Каждое взаимодействие – это мини-договор: кто, что, когда и где. Без этого не будет продуктивной активности.

Когда все участники понимают, к чему мы идём и как это связано с результатом, вовлечённость и синхронность значительно повышаются.

Хочу выделить ещё один принципиально важный момент:

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

1.      Подготовить систему.

2.      Определить и запустить активности по наполнению этой системы.

Можно было бы пойти по пути “сначала настроим систему, потом дадим задания участникам”, но я сознательно пошёл другим путём.

Почему?

Потому что без активности – нет артефактов. Активности – первичны. Артефакты – следствие.

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

Я часто иллюстрирую этот принцип таким примером:

Если на красном проекте меня спросят – “Когда ты подготовишь артефакт, описывающий подход к бизнес-анализу?”

То мой ответ будет: “Я подготовлю этот документ в последнюю очередь. Когда проект станет зелёным.”

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

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

Организация активностей

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

Например, проект только начался. Команда разработки ожидает юзер-стори с оформленными требованиями для начала работы. В то же время клиент хочет провести новые Discovery-сессии. Как понять, чем заняться в первую очередь?

Здесь важно выявить возможные критерии приоритезации. Для Discovery-сессий это могут быть:

•      доступность клиента (например, только на этой неделе или только по вторникам);

•      стадия проекта (плановая discovery-фаза или дополнительные сессии уже во время разработки);

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

•      готовность материалов (если требуется серьёзная подготовка – или наоборот, ничего не нужно);

•      формат сессий (удалённо, на стороне клиента, в офисе), и другие параметры.

Для юзер-стори:

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

•      доступность команды (готова ли команда обсуждать детали в процессе или только во время планирования);

•      требования к оформлению (текстовые, графические и т.д.);

•      текущий статус бэклога (пуст или уже содержит готовые элементы).

После выявления критериев можно оценить относительную важность каждой группы активностей. Но и здесь возникает вызов: каждая заинтересованная сторона будет “тянуть одеяло на себя”. Если писать юзер-стори вместо проведения Discovery-сессий – клиент может быть недоволен. Если проводить только сессии – дев-команда может быть заблокирована без входящих требований.

И здесь задача БА – самостоятельно принять оптимальное решение.

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

Оркестрация активностей

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

Чем больше направлений работы – тем сложнее мозгу быстро переключаться и возвращаться в нужный контекст. Например, вы только что завершили приоритетные активности из группы A и переключились на новую группу B. Но через два дня вам нужно вернуться в A, чтобы заняться оставшимися задачами. Каждое возвращение требует времени на “перезагрузку” контекста.

Почему я фокусируюсь на этом именно в рамках роли бизнес-аналитика? Потому что именно в работе БА наблюдается самая высокая степень контекстного расслоения. В течение одного дня вы можете:

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

•      подготовить шаблон для пользовательской истории,

•      провести дискуссию о приоритетах бэклога,

•      участвовать в discovery-сессии,

•      оформить результаты в систему.

Я не эксперт во всех IT-ролях, но, насколько могу судить, ни одна другая роль не требует такой многомерности и гибкости мышления. Разработчик, QA, дизайнер – их направления более узко специализированы. БА же работает на стыке коммуникации, анализа, документации и организации взаимодействия.

Именно поэтому я считаю важным прокачивать навык оркестрации как можно раньше. Он кажется простым – “взял и спланировал” – но с ростом вашей зрелости как эксперта и масштабов проектов сложность этого навыка неизбежно возрастает. Его развитие требует постоянных тренировок и внимательного отношения к самому себе.

Вопросы на самопроверку

Полезные вопросы, чтобы посмотреть и оценить свои же размышления!

Вопрос 1:

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

Он рассказывает, что:

•      Раз в неделю у него было по одному митингу с каждой командой по текущему спринт-бэклогу.

•      Раз в две недели – митинги по планированию следующего спринта.

•      Два раза в неделю – встречи с ключевыми стейкхолдерами для уточнения и согласования требований.

•      Остальное время он тратил на подготовку и написание пользовательских историий.

Когда ты впервые подключаешься:

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

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

Вопрос:

Как ты, как результато-ориентированный бизнес-аналитик, организуешь и приоритезируешь свои активности, чтобы учесть оба типа фидбека – от команд и от стейкхолдеров?

Вопрос 2:

Ты работаешь как бизнес-аналитик на активном проекте и замечаешь, что почти каждый день заканчиваешь работу не в 18:00, а в 19:00–20:00.

Ситуация:

•      Дев-команды просят больше сторей на спринт.

•      QA-команда часто обращается с вопросами по тест-кейсам.

•      Митинги идут по расписанию.

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

Вопрос:

1.      Какие три вероятные причины твоей переработки?

2.      Какие три решения ты мог бы применить, чтобы эффективно работать в даже в более комфортном графике (например, с 9:00 до 16:00) и сохранять/улучшать результативность?

3.      Какие новые активности или изменения в текущем процессе могли бы улучшить ситуацию?

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

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

Мой простой и действенный подход:

1.      Записываю активность в электронный блокнот (например, Apple Reminders). Как только она «на бумаге», мозг освобождается от необходимости её помнить.

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

На это уходит 10–20 секунд. Всё. Активность запланирована – и можно двигаться дальше.

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

Ремарка

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

Важно: сокращение времени не должно снижать ценность результата.

Поэтому я стараюсь регулярно переосмысливать подход к активностям:

•      на уровне часа,

•      дня,

•      недели.

Я ставлю себе вызов: «А могу ли я достичь того же результата, но быстрее?»

Такой взгляд помогает не просто управлять временем, а усиливать свою эффективность – и на работе, и за её пределами.

Пилот объема работ – планирование, декомпозиция и контроль

/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. Маппинг работ на продуктовые компоненты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что я делаю:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос 1:

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

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

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

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

Вопрос:

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

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

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