Любая задача выглядит простой, пока она существует в голове. В голове всё работает идеально: “да там кнопочку добавить”, “ну форму прикрутить”, “текст обновить — пять минут”. А потом начинается реальность: “нужны тексты”, “нужны доступы”, “а кто согласует?”, “а на мобилке поехало”, “а аналитику забыли”, “а на проде 500-ая ошибка”.
Декомпозиция нужна именно для этого момента. Она превращает “кажется просто” в “понятно, что делать”: список работ, порядок, зависимости и критерии готовности. И самое приятное: сюрпризы обнаруживаются ДО старта, а не после.
Что такое декомпозиция простыми словами
Декомпозиция — это разбор задачи на шаги, которые:
- можно оценить по времени,
- можно назначить ответственным,
- можно принять по признаку “готово/не готово”.
Если шаг нельзя проверить (“ну должно быть нормально”) — это не шаг, а пожелание в стиле “сделай красиво”.
Быстрый тест: что считается “шагом”
Шаг — это то, где вы можете ответить на два вопроса:
- что появится в результате?
- как мы проверим, что готово?
Примеры нормальных критериев:
“форма отправляет данные и показывает сообщение об успехе/ошибке”
“на мобильном ничего не наезжает и не прыгает”
“событие клика появляется в аналитике”
Пример ненормального критерия:
“сделано хорошо”
Как декомпозировать задачу: рабочий алгоритм
-
Шаг 1.
Зафиксируйте результат “на выходе”
Что именно будет существовать в мире после выполнения задачи? Страница опубликована? Интеграция работает? Отчёт сформирован? Это один абзац, но он спасает от “мы думали другое”.
-
Шаг 2.
Опишите сценарий пользователя (или процесс)
Сценарий — это рельсы, которые не дают забыть половину работы. Пример: пользователь увидел → нажал → заполнил → отправил → получил подтверждение → данные ушли в систему.
-
Шаг 3.
Разложите работу по слоям
Чтобы не забыть “хвосты”, удобно раскладывать по слоям:
- контент (тексты, сообщения об ошибках, FAQ)
- дизайн (макет/компоненты/состояния)
- разработка (вёрстка/логика/интеграции)
- аналитика (события/цели/метки)
- тестирование (сценарии/ошибки/пограничные случаи)
- запуск (выкладка/проверка на проде/план отката)
-
Шаг 4.
Для каждого пункта добавьте критерий “готово”
Без критериев вы не сможете ни оценить, ни принять, ни объяснить, почему “ещё не готово”.
-
Шаг 5.
Найдите зависимости и блокеры
Тут обычно всплывает всё, что убивает сроки:
- доступы и права
- данные/тексты/макеты
- согласующие (кто “даёт добро”)
- внешние системы (CRM, платёжка, API)
-
Шаг 6.
Отделите MVP от “ещё чуть-чуть”
Если срок ограничен — часть пунктов сразу маркируйте как “после релиза”, иначе “ещё чуть-чуть” станет бесконечным сериалом.
Типовые ошибки декомпозиции
- Слишком крупные шаги (“сделать интеграцию”) — оценить невозможно.
- Слишком мелкие шаги (100 микродействий) — теряется смысл и приоритеты.
- Забыли аналитику, тестирование и запуск — классика “почему на проде всё иначе”.
- Нет критериев “готово” — приёмка превращается в спор вкусов.
- Не учли зависимости — работа стопорится на “нужен доступ/текст/согласование”.
Мини-практика: “форма заявки + отправка в CRM” (как это выглядит в реальности)
Задача звучит просто: “сделать форму”. Декомпозиция показывает реальный состав работ:
- определить поля, обязательность, валидации
- подготовить тексты: подсказки, ошибки, сообщение об успехе
- согласовать, куда и в каком виде уходят данные (CRM, теги, источник)
- сделать компонент формы (дизайн/верстка)
- подключить отправку (endpoint, ключи, обработка ошибок)
- настроить аналитику (отправка/ошибка/успех)
- протестировать сценарии (плохая сеть, дубль, пустые поля, мобилка)
- выкатить и проверить на проде (логи, реальные заявки)
И вот тут “пара часов” часто превращается в нормальный небольшой проект. И это нормально — если вы увидели это заранее.
| Шаг | Что делаем | Результат | Критерий “готово” | Зависимости | Ответственный |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
Декомпозиция — это не усложнение, а снятие иллюзий. Она делает задачу управляемой: появляются шаги, порядок, зависимости и критерии. А значит — меньше “внезапно” и больше предсказуемого результата.