ENG
Перед началом каждого квартала или года в компаниях происходит примерно одно и то же: руководители и владельцы продуктов собираются, рисуют красочные дорожные карты и утверждают стратегию на месяцы вперед. Обычно такой «идеальный план» выглядит очень стройно:
- суперпродукты или суперфичи (за что дадут премию);
- улучшения и доработки (сделаем приятное бизнесу и пользователям);
- архитектурные задачи (чтобы не развалилось, что уже есть + импортозамещение);
- технический долг (в прошлом году не всё успели и в этом не всё успеем).
Сформулированные крупными блоками задачи оценивают и расставляют в календарь релизов. В план закладывают резерв времени в 10–15% на дефекты и непредвиденные расходы.
Планы утверждены, бюджеты под них заложены. Проходит время, и в план врываются:
- Регуляторные задачи. Они всегда «прибиты гвоздями». Их нельзя сдвинуть, иначе — штрафы или остановка работы.
- «Давно обещанное». Бизнес напоминает, что фичу обещали «еще в прошлом году».
- Проблемы с интеграциями. Смежники не успевают, приходится делать временные решения — костыли, которые усиливают технический долг.
- Новые вводные от бизнеса. Рынок изменился, приоритеты поменялись — «надо срочно делать».
- Критические дефекты продаж. Команда уходит в пожарный режим.
План трещит по швам, сроки горят, команда в аврале. Виной тому — две проблемы стратегического планирования:
- Мы не можем предсказать всё на год вперед.
- Мы не можем закладывать слишком большой процент затрат на риски — бизнесу нужен результат, и только за него он готов платить командам разработки.
Как исправить ситуацию? Нужные инструменты есть в арсенале системных аналитиков — это декомпозиция и приоритизация. Умелое их использование помогает вернуть управляемость.
Планирование задает вектор движения и ключевые «что и когда мы хотим сделать», аналитик отвечает на вопрос «как мы это сделаем, не сойдя с ума, когда всё пойдет не по плану».
Что такое декомпозиция
Декомпозиция — это процесс последовательного разбиения сложной, многосоставной задачи на более мелкие, атомарные и понятные единицы работы, которые можно взять в спринт, оценить, реализовать за ограниченное время и сразу же продемонстрировать результат. Если пользоваться метафорой, то это искусство «нарезки слона». Зачем она нужна?
Во-первых, для устранения неопределенности. Любая задача на старте проекта представляется как «черный ящик». Пока мы не заглянем внутрь и не поймем, из чего она состоит, мы не можем дать реалистичную оценку сроков. Декомпозиция вскрывает этот ящик, показывая все подводные камни, скрытые зависимости и технические сложности.
Во-вторых, для создания предсказуемости. План, состоящий из десятков мелких задач, гораздо точнее, чем план из двух-трех крупных. Можно отслеживать прогресс поэтапно: «задача А готова, задача Б в работе, задача В еще в бэклоге». Это дает прозрачность для менеджмента и бизнеса.
В-третьих, для гибкости и маневренности. Когда в середине спринта появляется срочная задача (та самая «регуляторка»), команда, работающая с монолитной фичей, встает перед выбором: бросить все и сорвать срок поставки или проигнорировать срочный запрос. Команда, практикующая декомпозицию, может легко заменить одну мелкую задачу на другую, сохранив общий ритм поставок.
Наконец, декомпозиция помогает в распределении работ. Чем мельче и независимее задачи, тем проще распределить их между разными участниками команды, ускоряя общую разработку.
Методов декомпозиции придумано и описано великое множество, и выбор конкретного инструмента зависит от того, на каком этапе планирования мы находимся и какого размера «куски» нам нужны.
На этапе стратегического (годового) планирования, когда мы имеем дело с размытыми пожеланиями от бизнеса «сделайте нам хорошо», на первый план выходят методы, помогающие увидеть общую картину и верхнеуровнево оценить реалистичность сроков. Здесь незаменимы User Story Mapping (картирование пользовательских историй), позволяющее выстроить путь пользователя и определить MVP, и Impact Mapping, который связывает функциональность с бизнес-целями. Эти методы помогают создать иерархию того, что предстоит сделать, не углубляясь в технические детали.
Когда мы спускаемся на уровень квартального или релизного планирования, задачи становятся более конкретными, и в ход идут структурные методы. Функциональная или объектная декомпозиция (особенно в связке с DDD) позволяют разбить крупные фичи на модули и сервисы, определить их границы и взаимодействия. На этом этапе важно заложить основу для архитектуры и понять, какие компоненты будут разрабатываться параллельно.
Наконец, на уровне спринтового планирования, когда мы работаем с конкретными пользовательскими историями, нужна максимальная детализация. Здесь применяются Use Cases для проработки сценариев использования, BDD-сценарии для формализации требований через примеры и, конечно, декомпозиция исключительных сценариев, позволяющая не забыть про обработку ошибок, защиту от падений и консистентность данных. Обычно это 80% кода, которые не видны пользователю, но критичны для надежности системы. Если не запланировать их заранее, они все равно появятся, но уже в режиме пожара.
Что такое приоритизация
Приоритизация — это процесс определения относительной важности задач для выбора порядка их выполнения в условиях ограниченных ресурсов.
Если декомпозиция отвечает на вопрос «из чего состоит задача», то приоритизация отвечает на вопрос «что делать прямо сейчас, а что – никогда». Это естественное продолжение работы: нарезав «слона» на управляемые куски, нужно понять, в каком порядке их подавать, чтобы команда не подавилась, а бизнес не умер с голоду в ожидании обещанных релизов.
Как и в случае с декомпозицией, методы приоритизации эволюционируют вместе с горизонтом планирования. На стратегическом уровне (год, квартал) работают качественные фреймворки вроде MoSCoW, которые помогают отделить зерна от плевел: что обязательно должно попасть в релиз (Must have), что важно, но подождет (Should), что было бы неплохо (Could), а что мы сознательно режем (Won't have).
Здесь же пригождается RICE (Reach, Impact, Confidence, Effort), позволяющий математически взвесить ценность фичи против трудозатрат, особенно когда нужно сравнить разнородные задачи — например, «новую платежную интеграцию» и «рефакторинг старого модуля».
На тактическом уровне (ближайшие спринты) в игру вступают более оперативные методы, тесно связанные с управлением потоком задач. Здесь работает Weighted Shortest Job First (WSJF) из методологии SAFe, который помогает выбирать задачи, дающие максимум ценности за минимальное время, что критично в условиях горящих сроков.
Приоритизация становится искусством компромиссов: «У нас прилетела регуляторка — что из запланированного мы выкидываем, чтобы сохранить ресурс?». И здесь снова возвращаемся к декомпозиции: только мелко нарезанные задачи дают пространство для маневра, позволяя заменять «плюшки» из категории Could на срочные Must, не разрушая каркас продукта. Таким образом, приоритизация — постоянный процесс, балансирующий между ожиданиями бизнеса и реальными возможностями команды.
Когда же всем этим заниматься?
Сроки горят, команда на каждом дейли грустно отвечает «не успеваем, а вы с планированием пристаете». В этих ситуациях эффективнее всего — остановиться, продумать план, наметить шаги.
Agile-практики вообще придумали специальную церемонию — PBR (Product Backlog Refinement) — время для непрерывного процесса «причесывания» бэклога, который часто недооценивают. В рамках регулярных (обычно еженедельных) сессий команда совместно проходит по задачам бэклога, уточняет детали, переоценивает их с учетом новой информации и, самое главное, проверяет, достаточно ли хорошо задачи декомпозированы для того, чтобы быть взятыми в следующий спринт. PBR позволяет выявить «подводные камни» еще до того, как задача ушла в разработку, снижая риск сюрпризов в середине спринта.
Кто же должен всем этим заниматься? Владелец продукта знает, «что нужно бизнесу», но часто не понимает технической сложности реализации. Техлид знает, «как это сделать», но часто только верхнеуровнево, его задача следить за архитектурой, на мелочи не остается времени. Менеджер следит за ресурсами и сроками, но не вникает в суть требований. И только системный аналитик владеет целостной картиной: с одной стороны, осознает потребности бизнеса, с другой — понимает архитектуру и ограничения системы, видит скрытые зависимости, держит в голове пользовательские сценарии со всеми их исключениями. Именно аналитик способен «нарезать» фичу так, чтобы она сохранила бизнес-ценность, но при этом была технически реализуема в жесткие сроки.
Итак, главное, что нужно запомнить:
- Планировать идеально невозможно. Реальность всегда внесет коррективы в виде регуляторки, проблем смежников и внезапных хотелок.
- Декомпозиция помогает маневрировать. Чем мельче нарезаны задачи, тем легче переставлять их местами, не ломая релиз.
- Приоритизация помогает не прятать голову в песок, а осознанно выбирать, что мы (не)делаем в этом спринте.
- Регулярный PBR — это выгодно. Лучше потратить день на «причесывание» бэклога, чем месяц на тушение пожаров.
Владение разными методами декомпозиции позволяет аналитику быть гибким и совместно с командой применять правильный инструмент на каждом этапе жизненного цикла задачи, гарантируя, что план будет не только красивым, но и реалистичным.
