Декомпозиция задач — разбиение большой работы на меньшие части. В управлении проектом она нужна, чтобы команда могла договориться о действиях, оценить ближайшую работу и проверить готовность. Количество подзадач само по себе ничего не говорит о качестве плана.
Фраза «сделать онлайн-запись» оставляет слишком много неизвестного. Но и сто строк «обсудить», «подумать» и «доработать» могут сохранить ту же неопределённость. Нужны промежуточные результаты, которые позволяют перейти к следующему действию.
Начните с результата целой задачи
Сначала ответьте, что изменится после завершения. Для учебного примера: посетитель выбирает доступное занятие, отправляет заявку и получает однозначное подтверждение. Администратор видит запись и может обработать отмену.
Такое описание ограничивает первую версию. Программа лояльности, рекомендации и сложная аналитика могут быть полезны позже, но не обязаны входить в эту задачу. При необходимости уточните исходную постановку задачи до разбиения.
Разделите работу по проверяемым переходам
| Часть работы | Результат | Что открывает дальше |
|---|---|---|
| Уточнить правила записи | Согласованы доступные места, обязательные данные и отмена | Можно проектировать сценарий без угадывания бизнес-правил |
| Подготовить сценарий и макет | Понятны экраны, ошибки и сообщение о подтверждении | Разработка и проверка согласны, какое поведение ожидается |
| Собрать рабочий сценарий | Выбор занятия и отправка заявки работают в тестовой среде | Можно проверять весь путь, а не отдельный экран |
| Проверить ограничения | Разобраны повторная отправка, отсутствие мест и отмена | Можно решить, допустим ли запуск на ограниченной группе |
| Провести ограниченный запуск | Собраны результаты и затруднения первых пользователей | Можно выбрать следующие изменения на основе наблюдений |
Это пример структуры, а не универсальный производственный регламент. Если в проекте сложная интеграция, её проверка может понадобиться до макета. Если сценарий уже известен, часть подготовки можно сократить. Последовательность должна отражать реальные зависимости.
Когда детализации достаточно
Попросите исполнителя объяснить, что он сделает следующим, какие данные ему нужны и что передаст дальше. Если ответ снова звучит как «буду заниматься задачей», стоит уточнить ближайшую часть.
Подробность зависит от горизонта. Для дальнего месяца достаточно значимого результата. Для завтрашней работы нужны конкретное действие и условие завершения. Не обязательно заранее расписывать все будущие шаги с одинаковой точностью.
Часть достаточно ясна, если исполнитель может начать, команда может проверить завершение, а следующий участник понимает, какой результат получит.
Проверьте зависимости и участие людей
В главе «Приоритизация» показано, что работа специалиста не изолирована: дизайнеру нужны уточнения постановщика, тестировщику — комментарий разработчика, менеджеру — решение заказчика. Если учитывать только основную загрузку, консультации превращаются в очередь ожидания.
Для каждой части проверьте три вещи: какие входные данные обязательны, кто поможет при вопросе и когда этот человек доступен. Затем выделите действия, которые действительно можно начать параллельно. Параллельность без готовых входных данных часто создаёт переделки.
От декомпозиции — к выталкивающей таблице
Разделённая работа ещё не стала планом. Теперь нужно договориться о последовательности, сроках ближайших результатов и ответственных. В выталкивающих таблицах части получают место в недельном и дневном горизонтах, а на сверке команда проверяет их движение.
Если согласование задержалось, видно не только просроченную подзадачу, но и передачу макета, начало разработки и последующую проверку. Это позволяет принять решение о связанной работе, а не молча сдвигать все даты.
Шаблон для разбора большой задачи
Какие ошибки мешают
- Деление только по отделам. «Дизайн — разработка — тестирование» не объясняет, какие результаты нужны на переходах.
- Одинаковая подробность на полгода. Команда тратит время на шаги, которые изменятся после первой проверки.
- Потеря целого. Подзадачи закрыты, но пользовательский сценарий никто не проверил.
- Отсутствие права на изменение. Если новый факт выявил ненужную часть, её стоит пересмотреть, а не выполнять ради процента готовности.
Завершите разбор общим планом проекта и договоритесь о ритме проверки. Декомпозиция становится полезной, когда помогает команде доводить части до общего результата.