Зачем нужна декомпозиция проекта, цели и методы

Упростить задачу и избежать прокрастинации. Понять, реально ли это. Составить пошаговый план. Понять, хватит ли ресурсов.

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

Декомпозиция — это по сути часть Скрам–метода. Основная задача Scrum — поставлять заказчику продукт по частям и регулярно получать от него обратную связь. Тот самый принцип вертикальной декомпозиции. Именно он используется в Agile чаще всего.

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

Декомпозиция — это разделение крупного проекта на мелкие части. Ее используют в IT, в бизнесе, в тайм–менеджменте. Декомпозиция показывает бизнес–модель. Она про цифры.

В разных сферах этот способ помогает:

• Упростить задачу и избежать прокрастинации. Например, страшная на первый взгляд задача: написать книгу. Если разложить ее на простые части — писать в день по 2000 слов — то цель становится вполне осуществимой.
• Понять, реально ли это. Когда задача раскладывается на этапы, можно оценить, сколько времени займет ее выполнение. И хватит ли на это жизни, например. Допустим, человек решил научиться играть на фортепиано, также виртуозно как Денис Мацуев. Думает, что справится за год. Но когда делит задачу на этапы, понимает, что в лучшем случае этой займет у него 10 лет.
• Составить пошаговый план. По сути каждая задача, каждый этап — это четкий план по достижению цели.
• Понять, хватит ли ресурсов. Возьмем тот же пример с фортепиано. Чтобы играть как Денис Мацуев, нужно: купить инструмент, нанять педагогов высокого уровня, платить им за индивидуальные занятия. Декомпозиция помогает оценить, хватит ли времени, сил и денег на эту цель.

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

А что нужно сделать, чтобы осуществить их? Опять расписываем все по этапам. Это будут цели третьего порядка.

Такую процедуру нужно повторить необходимое количество раз. К примеру, если нужен план ежедневных задач, то нужно максимально детализировать декомпозицию. Разделять все на короткие задачи, которые будут занимать от 15 минут в день до 2-х часов.

• Важно не ошибиться с подзадачами: если все это сделать, то задача верхнего уровня будет выполнена? Если нет, то нужно добавить подзадач.
• Но лучше не делить на более чем 7 подзадач. Просто потому, что их сложно будет за один раз удержать в памяти. К примеру, декомпозиция уборки квартиры может состоять из 10 и более подзадач: пропылесосить пол, помыть посуду, полить цветы, протереть пыль и так далее. А можно разделить на два объекта: кухня (помыть посуду, помыть пол, очистить плиту) и комната (пропылесосить пол, сложить одежду в шкаф, вымыть окна).

Удобнее всего разделять цель на мини–задачи в формате ментальных карт. Создавать их можно в бесплатных программах: X-mind, Freemind.

• Детализировать без необходимости. Возьмем пример с книгой: пока она не будет написана, стоит ли продумывать по шагам этапы верстки и выбора издательства? Не исключено, что в процессе выполнения задач, появится новая информация, которая заставит провести новую декомпозицию.
• Не выделять задачи без строгих сроков выполнения. Стоит продумать, что можно сделать заранее или когда есть простой по другим этапам. Чтобы в случае чего не сидеть без дела.
• Планировать «впритык».Оставляйте немного времени между этапами. Вдруг что–то пойдет не так, тогда весь план псу под хвост. Так быть не должно. Лучше заложить небольшой резерв. Даже если все пройдет как по маслу, это сэкономленное время можно будет потратить на задачи из пункта 2.
• Ставить не измеримые задачи. Чтобы достичь цели, нужно конкретизировать каждую задачу. Есть специальные SMART–критерии.

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

В аббревиатуре SMART каждая буква имеет свое значение.

• S–конкретика. Как вы поймете, что цель достигнута? Каким должен быть результат выполнения этой задачи? Цель должна вести к какому–то конкретному результату. Иначе как вы поймете, достигнута ли она. Например, цель: хочу выучить английский язык. Конкретики нет.

Цель: хочу прочитать Гарри Поттера в оригинале без словаря. Все конкретно и понятно.

• M–измеримость. Результат можно представить в виде измеримых показателей? Лучше всего измерять, конечно в цифрах. Например, цель: стать богатым. Это не измерить. Цель: зарабатывать в месяц от 250 тысяч рублей. Это уже измерить можно.
• A–достижимость. У вас хватит знаний, сил, денег, упорства, чтобы достичь этой цели? Вы точно представляете, что нужно делать? К примеру, хочу похудеть на 20 кг за неделю. Не слишком реалистично, да еще и опасно для здоровья. Цель: хочу сбросить 3 кг за 10 дней. Вполне реально.
• R–актуальность. Эта цель точно важна для вас? Если есть малейшие сомнения, стоит цель проверить. Например, цель: устроиться работать UX–дизайнером. А вам точно понравится?

Цель: пойти на курсы UX–дизайнера и пройти стажировку в компании, чтобы убедиться, что это мое.

• T–ограниченность по времени. Когда цель должна быть достигнута? Точная дата — залог успеха. Если ее нет, то цель легко забросить в дальний угол при первой неудаче. Задачи становятся необязательными. К примеру, цель: издать книгу. Нет сроков, этот процесс может растянуться на годы или вовсе не закончиться никогда. Издать книгу к 25 июня 2021 года в издательстве МИФ. Конкретно и мотивирует.

В IT чаще используют вертикальную декомпозицию проекта. В ней каждый блок задач можно реализовать и продемонстрировать заказчику. Он видит, что работа идет, понимает, в каком направлении и сразу может внести правки, сменить курс, если это необходимо.

Кроме того, каждый такой блок задач — это ценность (деньги/отношение клиентов) для компании. Следовательно, у них самый высокий приоритет на выполнение.

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

Проще говоря, декомпозиция в IT дает понимание:

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

К примеру, в веб–студию поступает заявка: сделать функционал покупки товара для интернет–магазина по продаже цветов. Не очень понятно, что именно нужно сделать, правда?

Проведем декомпозицию и разложим эту большую задачу на мелкие составляющие:

• Создать корзину товаров.
• Прикрутить функцию добавления товаров в корзину.
• Просмотр в корзине.
• Удаление из корзины.
• Ввод данных пользователя.
• Комментарии/пожелания к заказу.
• Выбор доставки.
• Способы оплаты.

Декомпозиция — это по сути часть Скрам–метода. Основная задача Scrum — поставлять заказчику продукт по частям и регулярно получать от него обратную связь. Тот самый принцип вертикальной декомпозиции. Именно он используется в Agile чаще всего.

При вертикальной декомпозиции каждая конечная пользовательская история несет в себе большую ценность для бизнеса. Такие задачи можно сравнивать друг с другом и приоритезировать.

Пользовательские истории (они же User Story) описывают пожелания заказчика, то, для чего продукт нужен пользователям.

Выделяют 5 подходов к декомпозиции на основе User Story:

• Разделение по этапам работы. К примеру, возьмем любое мобильное приложении для вызова такси. Здесь можно выделить несколько этапов: определение адреса клиента, куда ехать, как платить, нужно ли детское кресло, категория машины, отзыв водителю. Каждый из этих этапов можно выделить и описать. Затем для них продумывать пользовательские истории.
• Разделение по ролям. Этим способом пользуется 90% Agile–команд. Среди всех пользователей можно выделить определенные категории, которые по–особому взаимодействуют с продуктом: зарегистрированные и незарегистрированные, администратор сайта, специалист техподдержки и другие. Все это роли людей, которые пользуются продуктом. И у каждой из них будет свой путь, каждому нужен свой функционал.

Возьмем для примера интернет–магазин. В нем мы выделим роли: владелец, администратор и покупатель. И на их основе поставим задачи (декомпозируем). Так, для владельца интернет–магазина важен функционал по созданию и удалению товаров / услуг в каталоге, просмотр и редактирование описаний. Администратору также нужен просмотр и редактирование описаний товаров, плюс он должен иметь возможность обрабатывать заявки и комментарии клиентов. Сам клиент хочет просматривать описания товаров / услуг и заказывать их. С такой декомпозицией сразу становится понятно, какие функции нужны и их приоритет. Так, на первом этапе будет достаточно базового набора для каждой роли. А затем функционал можно расширять и дополнять.

• Разделение на основе позитивных и негативных сценариев. Здесь на первый взгляд все просто: в позитивном сценарии пользователь достиг своей цели и все ок. В негативном — что–то пошло не так. К примеру, пользователь забыл пароль для входа в личный кабинет и должен его восстановить, или клиент такси хочет отменить поездку, а таксист уже приехал. Здесь мы определяем, какие сценарии нужно проверять в первую очередь, проводим тесты, чтобы понять все ли корректно сработало.
• Декомпозиция по операциям. Например, функцию по управлению ассортиментом / каталогом товаров можно разделить на несколько операций: пополнение ассортимента, удаление старых товаров, обновление описаний и цен. Такая декомпозиция по операциям позволяет понять, какие из них нужно внедрять в первую очередь, как они взаимосвязаны между собой (например, пополнение ассортимента автоматически подразумевает и возможность удаления старых товаров).
• Декомпозиция по правилам бизнеса. Здесь мы определяем набор сценариев, по которым может выполняться процесс с соблюдением (или нет) неких условий. Например, в интернет–ритейле товары резервируются на определенное время, если оплата не прошла, то резервация снимается. Опять же никто не будет собирать заказ на складе до тех пор, пока его не оплатит пользователь. В системах по бронированию авиабилетов можно смотреть календарь с датами и ценами. В службах доставки еды есть сумма минимального заказа для бесплатной доставки.