Декомпозиция задач: от эпика до задачи в IT и программировании

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

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

Как выглядит результат: что видно на доске в конце?

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

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

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

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

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

Что нужно уметь за шаг до этого дерева?

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

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

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

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

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

Какой навык стоит ещё на шаг раньше?

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

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

Границы держатся приоритизацией. Когда историй набирается двадцать, решение «что первым» перестаёт быть очевидным, и тут выручает формальная рамка вроде матрицы приоритетов RICE и MoSCoW. Формула переводит спор о вкусах в арифметику.

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

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

С чего начинается самый первый шаг?

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

Фраза строится по схеме «кто, что получает, по какому признаку мы поймём, что получил». Например: «покупатели оформляют заказ без регистрации, доля брошенных корзин падает». Коротко, проверяемо, понятно и разработчику, и заказчику.

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

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

Сколько времени занимает каждый этап маршрута?

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

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

Какое первое занятие провести сегодня вечером?

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

1. Выпишите на бумагу задачу, которая сейчас выглядит самой пугающей.
2. Сформулируйте её результат одной фразой по схеме «кто, что получает, как поймём».
3. Разложите на три или четыре истории, каждая с понятной пользой для пользователя.
4. Каждую историю разрежьте на задачи, которые закрываются за половину дня.
5. К каждой задаче допишите строку «сделано, когда…».
6. Перенесите всё в трекер и проставьте очерёдность выполнения.

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

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

Где маршрут ломается чаще всего?

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

Задачи размером в неделю

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

Критерии готовности задним числом

Когда признак завершённости придумывается на демонстрации, спор неизбежен. Заказчик ждал одного, команда сделала другое, обе стороны формально правы. Строка «сделано, когда…» в карточке снимает этот разговор заранее.

Декомпозиция в одиночку

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

Дерево без порядка

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

Вопросы читателей

Чем эпик отличается от пользовательской истории?

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

Какого размера должна быть задача в трекере?

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

Кто отвечает за декомпозицию: менеджер или команда?

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

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

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

Источники

• The Scrum Guide, определения продуктового бэклога и элементов спринта.
• Манифест гибкой разработки программного обеспечения, принципы итеративной поставки ценности.
• Project Management Institute, стандарт по иерархической структуре работ.