Как декомпозировать большую задачу

Когда нужна декомпозиция

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

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

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

Главное правило

Разбивать нужно не по удобству календаря и не только по экранам, а по проверяемым изменениям в системе.

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

1. Сначала зафиксировать цель

Перед разбиением стоит ответить:

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

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

2. Разложить сценарии

Следующий шаг — не список задач, а карта сценариев.

Для каждого сценария полезно назвать:

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

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

3. Найти границы данных

Частая ошибка — разбить задачу по интерфейсу и забыть, что основная сложность спрятана в данных.

Проверьте:

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

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

4. Отделить технические неизвестные

Неизвестное не стоит маскировать под обычную подзадачу.

Лучше отдельно вынести:

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

Такая часть может быть spike, проверочным контуром или короткой технической гипотезой. Ее результат — не production-функция, а ответ на вопрос, который снижает риск.

5. Выбрать полезные срезы

Хороший срез задачи должен давать команде проверяемое движение.

Полезные варианты:

• один полный сценарий с ограниченными данными;
• сначала ручной обход, потом автоматизация;
• сначала проверочный контур интеграции, потом продуктовая логика;
• сначала happy path и диагностика ошибок, потом редкие исключения;
• сначала внутренняя операция, потом внешний пользовательский слой.

Слабые варианты:

• “сделать весь backend”;
• “сделать весь frontend”;
• “подготовить все документы”;
• “разобраться по ходу”;
• “разделить поровну по людям”.

Сквозной пример: доступ к внутренней системе

Возьмем вымышленную задачу: «Сделать самостоятельную выдачу сотрудникам доступа к внутренней системе».

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

Шаг 0. Вынести неизвестное из оценки

До продуктовых частей команде нужно проверить:

• есть ли у внешней системы стабильный API для выдачи и отзыва прав;
• как она обрабатывает повтор одного запроса;
• кто владеет каталогом ролей;
• какие действия требуют участия информационной безопасности;
• что считать успешной выдачей доступа.

Результатом короткого spike становится не «готовая интеграция», а подтвержденный контракт, ограничение решения или решение оставить операцию ручной. Пока этого ответа нет, оценка автоматической выдачи будет маскировать неизвестность числом.

Часть 1. Заявка и ручное выполнение

• Результат: сотрудник выбирает одну согласованную роль и отправляет заявку, а оператор видит ее и вручную отмечает выполненной.
• Проверка: заявку можно пройти от создания до конечного статуса без будущей автоматизации.
• Граница оценки: форма, минимальные данные, очередь оператора и статусы текущей части.
• Зависимость: согласованный каталог ролей и оператор, который владеет ручной очередью.
• Оставшийся риск: ручная операция пока не подходит для большого потока.

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

Часть 2. Решение руководителя

• Результат: руководитель одобряет или отклоняет заявку с причиной.
• Проверка: система не передает отклоненную заявку оператору, а решение и автор остаются в истории.
• Граница оценки: один маршрут согласования без замещений и сложной матрицы полномочий.
• Зависимость: заявка и история из части 1, а также однозначный владелец решения для выбранной роли.
• Оставшийся риск: правила для нескольких согласующих вынесены отдельно.

Часть 3. Автоматическая выдача одной роли

• Результат: после одобрения система выдает одну роль через подтвержденный внешний контракт.
• Проверка: успешный ответ переводит заявку в конечный статус, а повтор не создает вторую операцию.
• Граница оценки: одна роль, один внешний контур, известные ответы и согласованные тайм-ауты.
• Зависимость: одобренное решение из части 2 и подтвержденный на шаге 0 внешний контракт.
• Оставшийся риск: редкие ошибки и ручное восстановление еще не закрыты.

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

Часть 4. Ошибки, восстановление и отзыв доступа

• Результат: временная ошибка не теряет заявку, оператор видит причину и может безопасно повторить операцию или отозвать доступ.
• Проверка: повтор не выдает права дважды, финальная ошибка требует явного решения, а отзыв оставляет аудиторский след.
• Граница оценки: согласованный набор сбоев, один ручной сценарий восстановления и один сценарий отзыва.
• Зависимость: автоматическая выдача из части 3, согласованная таксономия ошибок и владелец ручного восстановления.
• Оставшийся риск: расширение на другие системы и роли становится отдельной задачей после проверки первого контура.

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

6. Описать критерий готовности для каждой части

Для каждой части нужно ответить:

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

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

Проверка части перед оценкой

Перед обсуждением срока или story points проверьте каждую часть:

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

Если на несколько вопросов нет ответа, часть еще не готова к оценке. Ее нужно уточнить, объединить с зависимой частью или сначала проверить неизвестное.

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

Рабочий шаблон декомпозиции

Используйте этот шаблон после проверки готовности задачи и до оценки.

1. Общая цель.

• Что должно измениться после задачи?
• Для кого результат важен?
• Что не входит в первую версию?
• Какой результат можно проверить?

2. Сценарии.

Для каждого сценария:

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

3. Границы данных и систем.

• Какие данные появляются или меняются?
• Где источник истины?
• Какие системы участвуют?
• Какие данные чувствительные?
• Где нужна совместимость со старым поведением?

4. Неизвестные места.

Отдельно вынесите все, что нельзя честно оценить как обычную разработку:

• внешний API;
• формат данных;
• авторизация;
• производительность;
• миграция;
• спорное бизнес-правило;
• поведение при ошибках.

Для каждого неизвестного места укажите следующий шаг: уточнение, spike, decision record, ограничение MVP или принятие риска.

5. Проверяемые части.

Для каждой части заполните:

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

6. Порядок.

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

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

Минимальный результат декомпозиции

После нормальной декомпозиции у команды есть:

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

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