Как правильно декомпозировать задачи

Декомпозиция задач

Любой человек, не только управленец или владелец бизнеса, сталкивается со сложностью деления комплексных задач на более мелкие составляющие. Одно дело, когда в список на исполнение прилетает простой и чёткий пункт, исполнение которого займёт от силы 10-15 минут, ну максимум час. А другое дело, когда задача вроде бы одна, но исполнение её может занять месяцы и даже годы. За это время может измениться всё, что угодно, даже сама задача.

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

Что такое декомпозиция задач (в проектной деятельности)

Если композиция – это составление чего-то целого из разнородных объектов (структур, систем и т.п.), их компоновка, то декомпозиция – это всегда обратный процесс.

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

Как ни странно, но все эти вопросы, формулировки и мотивации тесно перекликаются с правильной декомпозицией (разбивкой) задач.

Причём, все эти проблемы крайне важны в системе управления. Вопрос выполнимости задачи всегда встаёт очень остро. Например, если вы поставите задачу сотруднику украсть Луну перенести 1 тонну груза за один раз без подручных инструментов и материалов, то он никак не сможет её выполнить. Вместе с тем, ту же тысячу килограмм человек даже без специальных технических средств сможет перенести без какого-либо надрыва – малыми порциями. Главное правильно рассчитать темп, оптимальную нагрузку и время на отдых. Готово.

Это и есть пример декомпозиции.

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

Суть декомпозиции и зачем она нужна

Важно помнить, что декомпозиция задач в проектной деятельности – это исключительно мыслительный процесс. Никакой механической работы для расчленения задач не требуется (разве что со стороны конечных исполнителей).

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

Поэтому умение правильно раскладывать задачи на более мелкие – это важный навык проектного менеджера (всё о хард-скилах ПМ’а), а также часто и администратора проекта (что делает администратор проекта).

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

Поэтому суть декомпозиции – не в том, чтобы упростить что-то в вашем проекте до максимума (ведь максимальной планки на самом деле не существует), а в том, как сделать так, чтобы соблюсти баланс между исходной сложностью и эффективностью работы.

Уже исходя из сказанного становится понятно, зачем нужна декомпозиция:

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

Ещё один пример. Задача: поменять ценники, так как действующая цена в базе (учётной системе) изменилась.

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

Как правильно составлять декомпозицию

Главное, что нужно понять – не существует единого правильного процесса декомпозиции. Всё индивидуально.

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

Основные правила декомпозиции:

• Разложение задач на составляющие должно выполняться в виде понятной иерархии (для отражения наглядности подчинённости вложенных задач вышестоящей). На нулевом уровне, соответственно, будет располагаться та задача, которую нужно разложить. Идеальный вариант, когда конечные ветви иерархии остаются открытыми, то есть связанными только со своими «родителями». Худший сценарий – когда есть общие ветви и горизонтальные связи (переход от одной задач того же уровня к другой). Это повышает сложность и не решает основную задачу декомпозиции.
• Деление задач внутри уровня следует проводить по одному и тому же критерию. По некоему постоянному признаку. Например, функциональное назначение частей, предметные характеристики, присущий этап работы и т.п.
• Все составные подзадачи должны в совокупности представлять собой вышестоящую задачу. Это значит, что ни в коем случае нельзя забывать о каких-то составляющих. Например, если забыть установить в машину мотор или тормоза, то её невозможно будет использовать по назначению, так как важной составляющей не хватает.
• Глубина декомпозиции должна быть согласована с исходными требованиями. Не нужно пытаться объять необъятное. В ином случае можно дойти до микроменеджмента. Когда вы обложитесь массой руководящих документов и правил, зарегламентируете всё до мельчайших подробностей, потратите на это уйму времени, но проект так и не заработает, так как существенно возрастёт порог вхождения – исполнителям потребуется ещё столько же времени, чтобы со всем этим разобраться, изучить, понять и только потом переходить к непосредственным действиям.

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

Всё это может быть крайне индивидуальным.

Но суть сводится к одному – получаемая (выдаваемая) конкретному исполнителю задача должна быть реализуемой.

Лучше всего требования к задачам сформулированы в SMART-подходе (как работать по SMART):

• Конкретика (что, куда, зачем).
• Измеримость (можно в числах).
• Достижимость (с имеющимися/выделенными ресурсами и умениями исполнителя).
• Значимость (какую цель решает в конечном счёте).
• С обозначенными сроками (например, сколько времени должно занять или к какой дате должно быть сделано).

Выводы и нюансы

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

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

И именно здесь на помощь должен прийти опыт и понимание возможностей (профессиональных навыков, полномочий и имеющихся ресурсов) подчинённых специалистов. И если таких навыков нет, то к обсуждению декомпозиции нужно привлекать соответствующих экспертов, например, тех же специалистов, которые будут исполнять эту задачу.Второй, не менее интересный нюанс – учёт и визуализация результатов. Человеческий мозг так устроен, что может что-то забыть или упустить из виду. И чтобы этого не случилось, нужно использовать некую физическую среду, способную всё зафиксировать. Кто-то использует блокноты, кто-то стикеры на доске или на мониторе, но мы рекомендуем профессиональный софт для управления проектами.

Как справиться с декомпозицией задач и не перестараться

Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.

Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.

Как видно из приведенных примеров, описание каждой задачи зависит по большей части от фантазии и здравого смысла заказчика. Где-то оно больше, где-то оно меньше, но аналитикам надо как-то с этим работать. Иногда указывают еще и границы функционала, а иногда присылают просто тему. Если передать такую задачу сразу в разработку, на выходе получим что-то непонятное. Что приходится делать?

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

Зачем нужна декомпозиция

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

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

Если задача изначально большая и мы взялись за нее сразу целиком, то мы потратим на нее очень много времени и после комментариев заказчика нам придется все выбросить. Ну а если задача маленькая, день-два работы от силы, — ничего страшного. Переделка займет еще примерно столько же. Второй подход, к тому же, обойдется еще и дешевле. Не говоря уже о сэкономленных нервах с обеих сторон.

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

Плюс быстрое тестирование и исправление багов. Опять же, мелкий функционал гораздо проще и быстрее тестировать, чем монструозную махину. И если что-то пойдет не так, на «пофиксить» разработчик потратит совсем немного, и все быстрее заработает.

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

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

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

Основные подходы и правила декомпозиции

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

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

Гораздо удобнее вертикальный подход, при котором в каждой задаче можно сделать наглядный функционал — задача проходит по всем стадиям и на выходе есть результат, который можно проанализировать, протестировать, показать заказчику и поправить, если надо. И быстренько запустить в работу и использовать.

Если говорить про правила, здесь я выделил всего три. Во-первых, задача должна быть логически завершенной, то есть независимой сама по себе. Она не должна ломать логику вокруг себя и обязательно должна нести в себе хоть какой-нибудь бизнес-смысл, который в результате получит пользователь. При этом не стоит разбивать на части те задачи, которые не несут бизнес-смысла (в идеале их вообще не должно быть).

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

В-третьих, не стоит разбивать задачу на совсем уж микроскопические части. Если разбить слишком мелко, очень много времени уйдет на управление этими задачами. На каждом этапе их, возможно, придется переприоритезировать, заново проставлять связи зависимости и вот это всё. Таким образом, скорость разработки не увеличится, а наоборот, резко упадет. Поэтому нужно искать золотую середину.

Способы декомпозиции

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

Несколько потребностей

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

Сценарии использования

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

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

От простого к сложному

Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.

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

Как раз недавно я занимался похожей задачей по реализации баннера. Баннер должен был висеть на главной управляться из CMS. Если спросить у заказчика, а чем бы именно он хотел управлять, он, не моргнув, радостно ответит — всем. Поэтому здесь было важно немного погрузиться в тему и выделить то, чем нужно управлять прямо сейчас, чем просто часто, а чем почти совсем не пользуются. И таким образом расставить приоритеты по реализации и поделить на задачи.

Операции (CRUD)

Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.

Варианты интерфейса

Используется, когда надо поддержать несколько вариантов интерфейса. Например, сайт должен поддерживать несколько языков. Сначала мы делаем русскоязычную версию. Затем, при запусках в других странах, добавляем английский. Если же в стране используется язык, отличный от английского, то можем добавить и его. В этом случае проще все сделать сначала на одном языке, а потом постепенно добавлять переводы.

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

Разделение по ролям

Подходит для ситуаций, в которых функциональность подразумевает работу нескольких ролей и групп пользователей. На сайте «Спортмастера» у пользователя могут быть разные роли. Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя, и, допустим, пользователь колл-центра. Последняя роль также может делиться на две — это может быть как рядовой пользователь, так и администратор.

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

Обработка ошибок

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

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

Что в такой ситуации делать? Этот вопрос можно вынести в отдельную задачку и затем обрабатывать каждое отдельное поле. То есть, если не пришла цена, то выполняем одно действие, потерялось описание товара — другое. То же самое с ошибками пользователя. Если он ввел что-то некорректно и отобразилась ошибка, например, «Страница не найдена» или ошибка 500, мы должны показать ему конкретную информацию о том, что случилось, и предложить ему сценарий, что он может сделать дальше.

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

Статические, затем динамические

Это один из моих любимых способов. Подходит в ситуациях, когда можно реализовать функционал «на заглушках», то есть внешние системы не готовы поддержать функционал. Например, какие-то блоки на главной странице не могут управляться из CMS. Или меню, когда мы делаем его у себя в коде и отображаем пользователю, но при этом им не может управлять бизнес. И чтобы внести изменения, бизнесу надо постоянно ходить в разработку и просить это сделать.

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

Мы часто используем этот способ: сначала делаем функционал на своих данных, которыми нельзя управлять со стороны, а потом уже добавляем динамику и начинаем получать данные из сторонних систем.

Производительность

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

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

Возможные трудности

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

Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?

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

Еще у нас была проблема с тем, что не всегда понятны границы эпика. Недавно нам поставили задачу с оформлением заказа. Где у нее границы? Что должно получиться на выходе? Нам было непонятно, нужно ли нам делать весь функционал до самого конца, или выбрать какую-то часть. Входит ли в этот эпик оплата, или это уже отдельный эпик.

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

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

Спасибо, что дочитали!

• аналитика
• декомпозиция
• спортмастер
• постановка задач
• task management
• декомпозиция задач
• управление временем

• Блог компании Sportmaster Lab
• Анализ и проектирование систем
• Управление разработкой
• Управление проектами

Что такое декомпозиция задач и как ее выполнять

Декомпозиция задач — это процесс их разделения на отдельные небольшие шаги (подзадачи). Например, чтобы выполнить задачу «уборка на кухне», нужно помыть посуду, протереть столы и подмести. Проделав эти шаги, мы выполним и саму задачу.

Декомпозиция — это один из самых популярных приемов тайм-менеджмента. Сегодня мы расскажем, как пользоваться этим приемом и в каких ситуациях он может быть полезен.

Пример декомпозиции задачи #

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

Предположим, мы составили следующий план на выходной день:

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

1. Непонятно, что именно нужно сделать. Если мы просто протрем пыль со стола, будет ли задача выполнена? А если помоем чашку? Формально мы что-то запланировали, но по факту не запланировали ничего.
2. В задаче сейчас легко допустить ошибку. Скорее всего, мы уже мысленно решили, что нужно сделать. Но поскольку этот план существует только у нас в голове, мы можем напрочь забыть о некоторых этапах уборки.
3. В нынешнем виде задача выглядит сложной и расплывчатой. Именно такие задачи обычно и вызывают у людей внутреннее сопротивление и прокрастинацию. Давайте составим этот список снова, но на этот раз выполним декомпозицию сложной задачи:

Все перечисленные выше проблемы сразу исчезли. Во-первых, теперь мы четко понимаем, чем будем заниматься. Во-вторых, мы уже не забудем ни о фильтрах, ни о занавесках. В-третьих, у нас теперь не «одна сплошная задача», а несколько простых и легко выполнимых шагов.

Да, в результате получился еще один список дел. Но этот дополнительный список делает план на день более конкретным и выполнимым.

Виды декомпозиции #

Метод дерева целей:
как написать себе пошаговую инструкцию к жизни

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

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

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

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

Чек-лист для работы:
как избежать досадных ошибок

Параллельная декомпозиция хорошо подходит для составления проверочных списков (чек-листов).

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

Одношаговая. Этот вариант подходит для тех случаев, когда мы имеем дело с непонятными задачами или действуем в условиях неопределенности.

Допустим, мы хотим составить план спортивных тренировок. Раньше мы этого никогда не делали и даже не знаем, с чего начать. Как быть?

В этом случае можно действовать так:

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

Повторяем пункты 2 и 3, пока задача не станет понятной или пока она не будет полностью выполнена.

Как выполнять декомпозицию. Обзор инструментов #

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

Бумажный блокнот

Предположим, вы составили список дел на день. Вы смотрите на этот список и понимаете, что одну из задач не мешало бы разделить на подзадачи.

В этом случае нужно просто взять отдельный лист и составить еще один, дополнительный список. Например:

Программы для планирования

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

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

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

Способ 3. Прикрепить к задаче чек-лист. Хорошо подходит для повторяющихся задач, которые вам приходится выполнять снова и снова. Например, вы можете составить чек-лист еженедельной уборки в квартире или чек-лист публикации статьи.

Ментальные карты

FreeMind, XMind, MindManager и другие аналогичные приложения — это, по сути, специальные программы для декомпозиции задач.

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

Однако выполнять задачи «по ментальным картам» не очень удобно. После завершения мозгового штурма его результаты лучше перенести в свой блокнот или планировщик.

Некоторые нюансы #

1. Правило Джорджа Миллера

Теоретически задачу можно разбить на сколько угодно подзадач: 5, 10, 20, 30 и т. д. Однако в какой-то момент этот перечень перестает нормально восприниматься и превращается в одно сплошное месиво. Работать с ним сложно и неприятно.

Причина этого явления заключается в правиле Джорджа Миллера. Звучит оно так: человек не способен одновременно воспринимать более 7 объектов. Это число может колебаться от 5 до 9, но суть остается неизменной: у нас есть лимит, после которого мы перестаем нормально воспринимать свои задачи.

Если подзадач в вашем списке получилось больше семи, их полезно сгруппировать по какому-нибудь признаку. Например:

Группировка задач:
полезный прием тайм-менеджмента

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

2. Метод слона

Метод слона в тайм-менеджменте
Как съесть слона? По кусочку!

Это популярный прием тайм-менеджмента, который представляет собой один из способов применения декомпозиции. Предположим, перед вами стоит крупная задача, которая пугает вас своим объемом. Например:

• Помыть окна в квартире
• Покрасить огромный забор
• Выучить 30 билетов к экзамену и т. д.

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

Есть известная присказка: «Как съесть слона? По кусочку!». Именно так и рекомендуют поступать с задачами-слонами: нарезать их на небольшие одинаковые кусочки («бифштексы») и выполнять каждый день. Например:

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

В этом случае в качестве «бифштексов» можно использовать временные интервалы. Например, созданием своего сайта можно заниматься по полчаса каждый день. Если неукоснительно следовать этому плану, то в какой-то момент «слон» будет полностью съеден.

Как работает декомпозиция и почему менеджеры проектов не могут без неё

Зачем использовать декомпозицию? Сколько должно быть уровней декомпозиции? Рассказывает эксперт.

Иллюстрация: Оля Ежак для Skillbox Media

Дарья Чепурнова

Обозреватель Skillbox Media, отраслевой журналист. Работала с TexTerra, SMMplanner, «Нетологией», «ПланФактом», Semantica. Написала больше 60 текстов для рекламных кампаний в «Дзене». Вела нишевой канал на YouTube.

О декомпозиции рассказал

Владимир Завертайлов

Один из популяризаторов гибкой разработки в России. Основатель Scrum-студии «Сибирикс». Студия специализируется на крупных интеграционных проектах. В числе её клиентов — «Северсталь», «Орматек», «Металл Профиль», Disney, TP-Link, Logitech, «Атол», Greenfield, «Сочи Парк», Adobe и другие.

Автор «Настольной книги project-менеджера».

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

Этот материал Skillbox Media поможет разобраться в инструменте.

• Что такое декомпозиция и где её используют
• Зачем нужна декомпозиция
• Какие объекты можно декомпозировать
• Какие принципы декомпозиции нужно соблюдать
• Какие есть методы декомпозиции
• Как научиться декомпозировать: советы
• Как узнать больше об управлении проектами

Что такое декомпозиция и где её используют

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

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

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

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

Умение декомпозировать особенно важно для менеджеров проектов. Это базовый инструмент планирования и управления проектами. Также декомпозиция пригодится всем менеджерам и руководителям — она позволяет эффективнее управлять процессами и людьми.

Зачем нужна декомпозиция

Декомпозиция нужна менеджерам проектов прежде всего для того, чтобы получить реалистичные оценки проекта до начала работ. В первую очередь — понять, сколько времени займёт его выполнение. Это особенно важно в IT-отрасли, потому что реалистичная оценка сроков (трудоёмкости) позволяет адекватно оценить и стоимость проекта.

Также декомпозиция помогает:

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

Научиться управлять проектами помогут курсы Skillbox

• «Профессия Менеджер проектов» — изучить гибкие методологии и понять, как управлять сроками, бюджетами и командой.
• «Управление проектами» — запускать проекты в разных нишах, от IT до ретейла.
• «Профессия Продакт-менеджер» — изучить специфику управления продуктами — от приложений до автомобилей.

Какие объекты можно декомпозировать

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

Декомпозиция целей. Её используют для достижения и амбициозных личных целей, и целей бизнеса. Если речь идёт о компании, цель могут декомпозировать по отделам. Например, если директор хочет занять 20% рынка в Москве, он может поставить цели отделам маркетинга, продаж и производства.

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

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

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

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

Правила и принципы декомпозиции

В декомпозиции нет жёстких правил. Всё, что нужно, — разделить сложное на простые части. Но есть принципы декомпозиции, которые помогут делать это правильно. Вот они:

• Каждая часть должна быть логически изолирована от остальных. Проще говоря, у вас должны получиться чётко сформулированные задачи, не пересекающиеся друг с другом.
• Объекты нужно разбивать, следуя иерархической структуре. Каждая задача должна подчиняться задаче верхнего уровня, а та — задаче уровнем ещё выше.
• Сумма частей должна совпадать с целым. Под целым понимают результат — 100%. Каждая задача — доля результата, а сумма этих долей должна составлять 100%. Проще говоря — если все задачи выполнены, проект тоже должен быть завершён.

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

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

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

Например, для декомпозиции разработки сайта можно использовать три уровня деления:

• разбить проект на крупные блоки: товары, сервисная информация, блог;
• блоки разобрать на страницы — например, для сервисной информации это будут страницы «Доставка», «Оплата», «Возврат», «О компании», «Контакты»;
• страницы разбить на элементы, которые на них используют. Для страниц с товарами — визуальный контент, характеристики, отзывы, всплывающие окна.

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

Методы декомпозиции

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

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

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

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

Например, для визуализации декомпозиции в IT часто используют два инструмента:

• Диаграмму Ганта. Это визуальное представление графика работ, построенное согласно плану проекта. Диаграмма состоит из полос, расположенных вдоль оси времени. Длина полосы отражает продолжительность задачи. Все задачи расположены последовательно по приоритетности или по логике выполнения.
• Диаграмму PERT. Она похожа на диаграмму Ганта, но учитывает взаимосвязь этапов. PERT-диаграмма отражает ключевые вехи развития проекта — их обозначают кругами или прямоугольниками. Задачи обозначают линиями или стрелками — они соединяют ключевые вехи друг с другом, показывая зависимости.

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

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

Учиться можно от простого к сложному. На примере IT-отрасли это будет выглядеть так:

• Сначала взять готовый проект, уже разобранный на составляющие. Посмотреть, по какому принципу проект разделили на задачи и как их оценили.
• Попробовать разобрать на задачи стандартный проект и оценить его — сколько времени и ресурсов на него понадобится.
• Декомпозировать более сложные проекты. Например, проекты, в которых есть только прототип, только стандартное техническое задание или плохое и сложное ТЗ.

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

Как узнать больше об управлении проектами

• Проект — временное предприятие для получения уникального результата. Например, разработка продукта или сайта. Управление проектами — обширное направление в менеджменте, в нём много инструментов, методов и систем. Подробно об инструментах, проектах и проектном управлении можно почитать в этой статье.
• Декомпозиция — один из множества инструментов, которые нужны менеджеру проектов. Владимир Завертайлов выпустил «Настольную книгу project-менеджера», в которой рассказал о других необходимых инструментах и об управлении проектами в российских реалиях.
• Диаграмма Ганта — инструмент визуализации проектов, который помогает декомпозировать их. В этом материале мы разобрали инструмент: рассказали, на что обращать внимание при построении и какие сервисы можно использовать.
• Менеджер проектов должен уметь управлять сроками, бюджетами и командой. Получить необходимые навыки можно на курсе Skillbox «Профессия Менеджер проектов». На нём разбирают особенности управления проектами и дают универсальные знания, необходимые каждому менеджеру.

Другие материалы Skillbox Media, которые могут быть вам полезны

• Что такое проект, чем он отличается от процесса и что может быть его целью
• Зачем нужна структура проекта и как собрать её за семь шагов: разбор на примере
• Управление рисками в проекте: как найти их, оценить их и защититься от них
• Как управлять бюджетом проекта: пошаговое руководство
• Гайд по коммуникациям в проекте: как управлять ими, чтобы проект не провалился