Декарт в «Рассуждении о методе» сформулировал четыре правила мышления. Второе из них звучит так: делить каждую из рассматриваемых трудностей на столько частей, сколько потребуется, чтобы лучше их разрешить. Прошло почти четыре века, а лучшего способа бороться со сложностью человечество так и не придумало. Мы просто дали ему новые названия. В управлении проектами одно из них звучит как WBS, Work Breakdown Structure, иерархическая структура работ.
Звучит бюрократично, я понимаю. Аббревиатура из учебника, которую сдают на экзамене и забывают. Но на практике это один из самых недооценённых инструментов менеджера. И я хочу объяснить, почему.
Мозг не умеет думать о большом
Человеческий мозг прекрасно справляется с небольшим количеством вещей одновременно. Психологи спорят о точной цифре, но все сходятся в том, что она небольшая: несколько объектов, а не десятки. Когда Вы пытаетесь думать о проекте «сделать интернет-магазин» целиком, мозг видит туманное облако. Он не может его оценить, не может распланировать, не может понять, что там внутри. И начинает либо паниковать, либо делать вид, что всё понятно.
Оба варианта плохи. Паника парализует. Ложная уверенность приводит к оценке «месяца за три сделаем», которая потом превращается в год. Выход один: разрезать облако на куски, которые помещаются в голову. Это и есть декомпозиция.
Как устроена WBS
WBS это дерево. На вершине весь проект. На следующем уровне его крупные части. Каждая часть делится на более мелкие, и так до тех пор, пока на нижнем уровне не окажутся пакеты работ, которые можно понятно оценить, назначить конкретному человеку и проверить, сделаны ли они.
Возьмём тот же интернет-магазин. Первый уровень: каталог, корзина и оформление заказа, оплата, личный кабинет, админка, интеграции, инфраструктура, запуск. Каталог делится на структуру категорий, карточку товара, поиск, фильтры, импорт товаров. Импорт товаров делится на формат файла, загрузку, обработку ошибок, обновление цен. И вот на этом уровне уже можно сказать: «загрузка и обработка ошибок импорта займёт три дня».
Есть несколько правил, которые отличают полезную WBS от формальной.
- Правило ста процентов. Сумма дочерних элементов равна родителю. Не больше и не меньше. Если чего-то нет в дереве, этого нет в проекте, и на это не заложено ни времени, ни денег.
- Декомпозиция результатов, а не действий. Узлы дерева это то, что должно получиться, а не то, что нужно делать. «Форма оплаты, принимающая карты» вместо «работать над оплатой».
- Разумная глубина. Пакет работ должен занимать от дня до пары недель. Мельче, и Вы утонете в микроменеджменте. Крупнее, и снова получите облако, которое невозможно оценить.
Главная ценность: найти забытое
Самое ценное, что даёт WBS, это не красивая схема, а момент, когда при её составлении кто-то говорит: «Подождите, а кто будет переносить данные из старой системы?» Или: «А обучение сотрудников клиента вообще в проекте есть?» Или: «А где у нас тестирование на реальной нагрузке?»
В каждом проекте есть невидимая работа, о которой никто не думает, пока не наступает момент её делать. Перенос данных, настройка серверов, документация, обучение пользователей, исправление того, что найдут на приёмке. Именно эта работа съедает сроки, потому что её не было в плане. WBS вытаскивает её на свет ещё до того, как назван срок и подписан договор.
Проект почти никогда не срывается из-за того, что было в плане. Он срывается из-за того, чего в плане не было.
Что ещё даёт декомпозиция
Когда проект разложен на понятные куски, на них можно повесить всё остальное. Оценки: суммировать маленькие оценки точнее, чем угадывать одну большую. Ответственность: у каждого пакета есть конкретный владелец, и не бывает ситуации «я думал, это делает он». Риски: видно, какие пакеты зависят от внешних факторов, от клиента, от сторонних сервисов. Контроль: прогресс измеряется закрытыми пакетами, а не ощущением «мы где-то на семидесяти процентах».
Есть и приятный побочный эффект: клиенту становится понятно, за что он платит. Вместо одной строки «разработка магазина» он видит структуру и может сам решить, что из неё убрать, если бюджет не сходится.
Фрактальность мира
Мне эта тема особенно близка, потому что наш генератор называется Fractal не случайно. Фрактал это структура, в которой каждая часть похожа на целое. Хорошая декомпозиция системы устроена так же: проект состоит из модулей, модули из экранов и сущностей, экраны из полей и действий, и на каждом уровне действуют одни и те же правила. Когда мы описываем систему на языках Fractal, мы по сути строим её WBS в машиночитаемом виде, и генератор превращает листья этого дерева в работающий код.
Что сделать завтра
Возьмите проект, который кажется Вам большим и туманным. Возьмите лист бумаги или доску и нарисуйте дерево: проект наверху, пять-восемь крупных частей под ним. Затем разбейте каждую часть ещё на уровень. Не стремитесь к идеалу, стремитесь к тому, чтобы ничего не забыть. Покажите это дерево команде и спросите: чего здесь не хватает? Почти наверняка Вы услышите пару пунктов, о которых никто не подумал. Каждый из них это сорванный дедлайн, который Вы только что предотвратили.
