Любой человек, не только управленец или владелец бизнеса, сталкивается со сложностью деления комплексных задач на более мелкие составляющие. Одно дело, когда в список на исполнение прилетает простой и чёткий пункт, исполнение которого займёт от силы 10-15 минут, ну максимум час. А другое дело, когда задача вроде бы одна, но исполнение её может занять месяцы и даже годы. За это время может измениться всё, что угодно, даже сама задача.
Итак, в этой статье подробно разберём процесс декомпозиции сложных задач, все существующие подходы и их подводные камни.
Что такое декомпозиция задач (в проектной деятельности)
Если композиция – это составление чего-то целого из разнородных объектов (структур, систем и т.п.), их компоновка, то декомпозиция – это всегда обратный процесс.
Декомпозиция задач – это разбиение (разбор) большой и обычно сложной задачи на более мелкие составляющие, которые можно решить за относительно короткие итерации (временные промежутки) и с потенциальным привлечением дополнительных специалистов (за счёт делегирования).
Ранее мы рассматривали тему как правильно ставить цель и задачи. А также как заставить сотрудников выполнять поставленные задачи.
Как ни странно, но все эти вопросы, формулировки и мотивации тесно перекликаются с правильной декомпозицией (разбивкой) задач.
Причём, все эти проблемы крайне важны в системе управления. Вопрос выполнимости задачи всегда встаёт очень остро. Например, если вы поставите задачу сотруднику украсть Луну перенести 1 тонну груза за один раз без подручных инструментов и материалов, то он никак не сможет её выполнить. Вместе с тем, ту же тысячу килограмм человек даже без специальных технических средств сможет перенести без какого-либо надрыва – малыми порциями. Главное правильно рассчитать темп, оптимальную нагрузку и время на отдых. Готово.
Это и есть пример декомпозиции.
В любых бизнес-процессах разложение задач на составляющие работает точно так же – оно делает невыполнимые задачи выполнимыми.
Суть декомпозиции и зачем она нужна
Важно помнить, что декомпозиция задач в проектной деятельности – это исключительно мыслительный процесс. Никакой механической работы для расчленения задач не требуется (разве что со стороны конечных исполнителей).
Понятно, что разбивка сложных задач на простые позволяет решить множество проблем. Но у самого процесса декомпозиции есть множество подводных камней: до какого уровня нужно детализировать задачи, какую конечную цель нужно решить, насколько полученная декомпозиция будет эффективной, какие дополнительные проблемы она может решить и т.п.
Поэтому умение правильно раскладывать задачи на более мелкие – это важный навык проектного менеджера (всё о хард-скилах ПМ’а), а также часто и администратора проекта (что делает администратор проекта).
Понимания правильной декомпозиции задач в проектах приходит только с опытом и с умением учитывать различные факторы: навыки отдельных участников команды (у кого и какой темп, в каком формате нужно ставить задачи, до какого уровня нужно «разжевать» задачу), какие требования у заказчиков (или у других стейкхолдеров проекта, кто такие стейкхолдеры), как всё это может сказаться на конечном результате, заложены ли возможные риски и т.п.
Поэтому суть декомпозиции – не в том, чтобы упростить что-то в вашем проекте до максимума (ведь максимальной планки на самом деле не существует), а в том, как сделать так, чтобы соблюсти баланс между исходной сложностью и эффективностью работы.
Уже исходя из сказанного становится понятно, зачем нужна декомпозиция:
- Получение адекватной оценки сложности проекта и сроков его реализации, необходимых ресурсов (человеческих и материальных), а также потенциальных изменений, которые могут потребоваться для выполнения задач.
- Вычленение наиболее приоритетных действий в краткосрочной и долгосрочной перспективе.
- Выявление слабых мест (узких горлышек) и возможности их обхода. Например, за счёт усиления отдельных направлений, за счёт распараллеливания задач и т.п.
Ещё один пример. Задача: поменять ценники, так как действующая цена в базе (учётной системе) изменилась.
Простое решение: распечатать ценники и расставить их по местам. Всё просто и понятно? Не совсем. А если у вас не просто магазин, а гипермаркет? И цены поменялись не на одну, а на пару тысяч позиций? А если это не один гипермаркет, а целая сеть, и в разных торговых точках используются разные цены на один и тот же товар? Тут уже придётся согласовывать массу деталей: в какую точку и какой прайс отправлять, кто и за что будет ответственным, какие специалисты будут задействованы для печати, кто будет расставлять ценники и т.п. Получается целый бизнес-процесс, который логично оформить в виде отдельного руководящего документа.
Как правильно составлять декомпозицию
Главное, что нужно понять – не существует единого правильного процесса декомпозиции. Всё индивидуально.
Но существует общий подход к разбивке – как свод правил. И вот ими уже можно пользоваться для того, чтобы получить детализацию задач нужного вам уровня.
Основные правила декомпозиции:
- Разложение задач на составляющие должно выполняться в виде понятной иерархии (для отражения наглядности подчинённости вложенных задач вышестоящей). На нулевом уровне, соответственно, будет располагаться та задача, которую нужно разложить. Идеальный вариант, когда конечные ветви иерархии остаются открытыми, то есть связанными только со своими «родителями». Худший сценарий – когда есть общие ветви и горизонтальные связи (переход от одной задач того же уровня к другой). Это повышает сложность и не решает основную задачу декомпозиции.
- Деление задач внутри уровня следует проводить по одному и тому же критерию. По некоему постоянному признаку. Например, функциональное назначение частей, предметные характеристики, присущий этап работы и т.п.
- Все составные подзадачи должны в совокупности представлять собой вышестоящую задачу. Это значит, что ни в коем случае нельзя забывать о каких-то составляющих. Например, если забыть установить в машину мотор или тормоза, то её невозможно будет использовать по назначению, так как важной составляющей не хватает.
- Глубина декомпозиции должна быть согласована с исходными требованиями. Не нужно пытаться объять необъятное. В ином случае можно дойти до микроменеджмента. Когда вы обложитесь массой руководящих документов и правил, зарегламентируете всё до мельчайших подробностей, потратите на это уйму времени, но проект так и не заработает, так как существенно возрастёт порог вхождения – исполнителям потребуется ещё столько же времени, чтобы со всем этим разобраться, изучить, понять и только потом переходить к непосредственным действиям.
Очень важно помнить, что деление задач на подзадачи обусловлено рядом внешних факторов: необходимость учёта ресурсов и времени, оценки результатов при приёмке, имеющиеся профессиональные навыки у исполнителя и т.п.
Всё это может быть крайне индивидуальным.
Но суть сводится к одному – получаемая (выдаваемая) конкретному исполнителю задача должна быть реализуемой.
Лучше всего требования к задачам сформулированы в SMART-подходе (как работать по SMART):
- Конкретика (что, куда, зачем).
- Измеримость (можно в числах).
- Достижимость (с имеющимися/выделенными ресурсами и умениями исполнителя).
- Значимость (какую цель решает в конечном счёте).
- С обозначенными сроками (например, сколько времени должно занять или к какой дате должно быть сделано).
Выводы и нюансы
Декомпозицию задачи нужно остановить на том уровне, когда она становится ясна и понятна ответственному специалисту (исполнителю), и при этом он может её выполнить в обозначенные сроки.
Что немаловажно – так как декомпозицией занимаются обычно руководители проекта, они могут смотреть на эту задачу «со своей колокольни», и это может приводить к неожиданным результатам. Например, подзадача будет неверно оценена или сформулирована, её невозможно будет выполнить или она будет требовать дальнейшей декомпозиции.
И именно здесь на помощь должен прийти опыт и понимание возможностей (профессиональных навыков, полномочий и имеющихся ресурсов) подчинённых специалистов. И если таких навыков нет, то к обсуждению декомпозиции нужно привлекать соответствующих экспертов, например, тех же специалистов, которые будут исполнять эту задачу. Второй, не менее интересный нюанс – учёт и визуализация результатов. Человеческий мозг так устроен, что может что-то забыть или упустить из виду. И чтобы этого не случилось, нужно использовать некую физическую среду, способную всё зафиксировать. Кто-то использует блокноты, кто-то стикеры на доске или на мониторе, но мы рекомендуем профессиональный софт для управления проектами.