Декомпозиция задачи в разработке: приёмы, которые работают

Задача «добавить оплату на сайте» может занять два часа, две недели или сорвать релиз: всё зависит от того, что именно команда считает результатом. Рабочая декомпозиция превращает такую формулировку в набор проверяемых изменений — с понятными границами, зависимостями и критериями готовности. Ниже — четыре приёма для разработки, правила выбора между ними и признаки того, что задачу раздробили неправильно.

Начинайте не с подзадач, а с результата

Первая ошибка — открыть трекер и сразу создать пункты «сделать API», «добавить кнопку» и «написать тесты». Это список активностей, а не план результата. Если требования изменятся, команда будет защищать уже созданные тикеты, хотя пользовательская проблема останется нерешённой.

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

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

Например, вместо «интегрировать платежи» точнее написать: «покупатель может оплатить заказ картой, а магазин получает подтверждение платежа и не создаёт повторный заказ при повторной отправке запроса». В этой формулировке уже видны пользовательский сценарий, серверная логика и граничный случай.

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

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

Четыре приёма декомпозиции

1. Разбивка по пользовательским сценариям

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

Для оплаты это может выглядеть так:

1. покупатель открывает форму оплаты и вводит данные;
2. платёж проходит успешно, заказ получает статус «оплачен»;
3. банк отклоняет операцию, покупатель видит причину и может повторить попытку;
4. платёж подтверждён, но уведомление от провайдера пришло с задержкой;
5. клиент повторно отправляет запрос, а система не создаёт второй платёж.

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

2. Разбивка по бизнес-правилам и состояниям

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

У заказа могут быть состояния «создан», «ожидает оплаты», «оплачен», «отменён» и «возвращён». Вместо общего тикета «добавить статусы заказа» появляются конкретные задачи: разрешить переход из «ожидает оплаты» в «оплачен» только после подтверждения провайдера, запретить оплату отменённого заказа, записывать причину отмены и отправлять уведомление после успешного перехода.

Главная выгода — меньше скрытых противоречий. Правило перехода можно проверить отдельно. Цена подхода — необходимость заранее договориться о модели состояний. Если бизнес ещё меняет правила каждый день, ранняя детализация быстро устареет.

3. Разбивка по слоям системы

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

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

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

4. Разбивка по рискам и неизвестности

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

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

Такой приём экономит время, если неизвестность действительно способна изменить решение. Но исследование нельзя оставлять бесконечным. Заранее задайте вопрос, на который нужен ответ, срок эксперимента и критерий остановки.

Как выбрать подход

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

Как сделать подзадачу проверяемой

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

Перед передачей задачи проверьте пять признаков:

1. в описании есть один результат, а не несколько независимых целей;
2. приёмка описывает наблюдаемое поведение;
3. понятны входные данные и ожидаемый выход;
4. указаны ограничения: права доступа, совместимость, лимиты или внешние зависимости;
5. задачу можно показать или проверить без чтения всего проекта.

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

Что ломается чаще всего

Задачи стали слишком маленькими

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

Все подзадачи зависят друг от друга

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

В задачу попало всё сразу

Требования «добавить оплату, историю операций, возвраты, отчёты и мобильную адаптацию» нужно разделить по самостоятельным результатам. Иначе команда не сможет понять, что можно выпустить первым, а обсуждение каждого изменения будет затрагивать весь объём.

Исключения оставили на потом

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

Критерий готовности заменили словами «готово»

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

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

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

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

Что сделать дальше

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

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