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