Где начинается декомпозиция

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

Представьте: наверху возникает бизнес-проблема, а до команды она доезжает в виде задачи “Создать сервис X”. К ней прилагается подробный алгоритм: добавить таблицу, реализовать обработчик, подписаться на топик. Вроде бы написано много, но ответа на главный вопрос нет: какую проблему и для кого мы решаем?

Дальше неопределённость пытаются победить детализацией. Задачу раскладывают на подзадачи, каждую оценивают с разных сторон и в разных плоскостях – часах, story points, попугаях; составляют подробный план на недели вперёд и регулярно его переделывают. Кажется, что чем больше деталей, тем точнее прогноз. На деле получается точный план выполнения не очень понятой работы.

Детализация не создаёт понимания. Она лишь делает непонимание более подробным.

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

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

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

Ранее я уже писал, почему важно сохранять исходный контекст. Без ответа на вопросы “зачем” и “для кого” невозможно включить критическое мышление. Возможно лишь проверить алгоритм, но не его уместность. Получается код, отвечающий на вопрос “как”, хотя почему важнее, чем как.

При этом бизнесовая формулировка задачи сама по себе не делает задачу атомарной. Даже User Story может скрывать мамонта размером с сервис. Хороший “атом” – это минимальный вертикальный срез, который:

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

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

Не так важно, назовёте вы такой срез фичей, Use Case или User Story. Формула “Как пользователь, я хочу…, чтобы…” помогает сохранить мотивацию, но это только приглашение к разговору, а не магическое заклинание и не замена требованиям. Ориентир должен быть на частую поставку ценного результата, обратную связь и готовность изменить план после получения новых знаний.

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

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

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