#статьи
- 23 янв 2023
-
0
Что такое декомпозиция? Как декомпозировать проект? До какой степени его детализировать? Разбираемся с экспертом.
Фото: Dominic Lipinski / PA Images / Getty Images
Обозреватель Skillbox Media, отраслевой журналист. Работала с TexTerra, SMMplanner, «Нетологией», «ПланФактом», Semantica. Написала больше 60 текстов для рекламных кампаний в «Дзене». Вела нишевой канал на YouTube.
О WBS рассказал
Один из популяризаторов гибкой разработки в России. Основатель Scrum-студии «Сибирикс». Студия специализируется на крупных интеграционных проектах. В числе её клиентов — «Северсталь», «Орматек», «Металл Профиль», Disney, TP-Link, Logitech, «Атол», Greenfield, «Сочи Парк», Adobe и другие.
Автор «Настольной книги project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учётом российских реалий».
В проектном менеджменте есть много концепций, которые упрощают управление проектами. Одна из таких концепций — WBS, или структурная декомпозиция.
В этом материале Skillbox Media разберёмся:
- что такое WBS и зачем она нужна;
- какие есть принципы WBS;
- как сделать структурную декомпозицию;
- как визуализировать WBS;
- как узнать больше о проектном управлении.
WBS — work breakdown structure, или структурная декомпозиция. Другое название — иерархическая структура работ. Это инструмент планирования, в основе которого лежит популярный приём тайм-менеджмента: чтобы съесть слона, нужно делать это по кусочкам. WBS используют не только в проектном менеджменте, но и во многих других сферах.
С помощью структурной декомпозиции большие и сложные проекты делят на маленькие простые части. Например, проект разбивают на блоки, блоки — на задачи, задачи — на подзадачи. Получается иерархическая схема, в которой отражены все работы по проекту.
Скриншот: Skillbox Media
Структурную декомпозицию используют, чтобы быстро получить представление об объёме работ. Это нужно, чтобы верно оценить сроки, трудозатраты и стоимость проекта — и презентовать эти данные клиенту или руководству.
Также WBS помогает:
- отметить «контрольные точки» проекта и результаты, которых нужно в них достичь;
- спрогнозировать дополнительные затраты, которые могут возникнуть в процессе работ, — например, на подписку на сервисы или покупку дополнительного ПО;
- понять, как все работы по проекту связаны между собой, и правильно определить приоритеты задач;
- определить количество задействованных на проекте сотрудников или подрядчиков и распределить нагрузку между ними;
- назначить ответственных за каждый этап проекта и наладить коммуникацию в команде;
- заранее увидеть возможные трудности и снизить риски — например, понять, что текущих ресурсов не хватит и нужны дополнительные сотрудники.
Иерархическая структура облегчает создание стратегии проекта. Это документ, в котором описана последовательность работ, сроки и ответственные за каждый этап проекта.
Принципы структурной декомпозиции — это правила, по которым проект «разбирают» на составляющие. В разных источниках описывают множество принципов. Мы расскажем о пяти правилах, которым следуют чаще всего.
В схему нужно включать все этапы работы над проектом. То есть всё, что может повлиять на его результат. Если не включить какой-то «второстепенный» этап, есть риск забыть про него.
При декомпозиции нужно соблюдать иерархию. Это значит, что у каждого подпункта должен быть только один «родительский» пункт. Элементы (задачи) не должны дублироваться.
Верхние блоки должны быть равнозначными и автономными. Сверху располагают главные этапы работы над проектом. У каждого из них должны быть свои исходные данные и измеримый результат.
Каждый блок работ нужно детализировать. Этапы нужно декомпозировать до уровня простых задач, которые может выполнить или проконтролировать один сотрудник. Если для работы нужно несколько человек, значит, эту задачу тоже можно декомпозировать.
В схеме не должно быть разночтений. Для каждой задачи в схеме составляют описание и указывают дедлайн, ответственного и желаемый результат. Это описание не должно вызывать вопросов и уточнений.
Менеджер проектов может сделать декомпозицию самостоятельно или привлечь к этому команду. Чтобы получить иерархическую схему работ, нужно пройти семь шагов.
Первый шаг — постановка задачи. На этом этапе определяют, к какому результату нужно прийти. Желательно сразу прописать чёткие цели проекта — например, «создать сайт компании с каталогом товаров и корзиной для покупок».
Второй — поиск результатов, необходимых для достижения целей, они же главные этапы работы. Например, для запуска сайта нужно:
- собрать информацию и подготовить контент;
- провести анализ конкурентов, рынка, компании;
- составить техническое задание;
- разработать интерфейс;
- выбрать стек разработки и написать код;
- выполнить вёрстку страниц;
- провести тестирование.
Третий — перечисление блоков работ. Это самые важные этапы — те, что были определены на предыдущем шаге. Для каждого блока нужно прописать результат — чего нужно достичь на этом этапе. Например, на этапе составления технического задания — получить документ, описывающий требования к сайту.
Четвёртый — разбивка блоков на задачи. Каждый этап работы нужно детализировать до задач и по каждой из них определить дедлайн. На основе этих дедлайнов можно определить сроки сдачи каждого блока и проекта в целом.
Пятый — распределение задач. На этом этапе нужно проанализировать трудозатраты и загруженность команды — и распределить задачи между сотрудниками. Если они не успеют выполнить в срок все работы, можно подключить подрядчиков и назначить тех, кто будет контролировать их работу.
Шестой — составление бюджета. Исходя из стоимости работы специалистов и подрядчиков, нужно рассчитать стоимость всего проекта. При необходимости в неё включают дополнительные затраты — например, расходы на покупку софта.
Седьмой — создание контрольных точек. Благодаря декомпозиции проект детализирован и контролировать каждую задачу не нужно. Но стоит определить контрольные точки — ключевые этапы проекта, результат которых нужно утвердить с клиентом. Часто в качестве контрольных точек используют блоки — главные этапы, которые мы нашли на втором шаге.
Результат структурной декомпозиции обязательно визуализируют — рисуют схему, отражающую иерархию задач. Есть разные способы визуализации. Мы перечислим четыре распространённых решения.
Иерархическая таблица. Это список задач в таблице. В первом столбце пишут названия блоков, задач и подзадач. В следующих — даты начала и окончания процессов, затраченное время, имена ответственных и другие данные. Такую таблицу удобно использовать для линейных процессов.
Создать иерархическую таблицу можно в Excel или в «Google Таблицах» — сервисе для работы с онлайн-таблицами.
Скриншот: Skillbox Media
Древовидная структура. Это визуализация иерархической таблицы в виде перевёрнутого дерева. Его «корень» — название проекта. От него отходят «ветви» — задачи и подзадачи.
Древовидная структура — один из самых простых способов визуализации. Можно нарисовать её от руки или использовать специальные сервисы — Creately, Draw.io, Microsoft Visio, Octopus.do. Последний создан для визуализации карты сайта, но подойдёт и для декомпозиции.
Инфографика: Майя Мальгина для Skillbox Media
Диаграмма Ганта. Это визуальное представление графика работ. Диаграмма состоит из отрезков, размещённых вдоль временной оси. Каждый отрезок — это задача. Диаграмма показывает, когда будут выполняться задачи и сколько на это уйдёт времени. Подробнее об инструменте можно почитать здесь.
Диаграмму можно построить в обычной таблице вроде Excel или в специальных сервисах: GanttPro, TeamGantt и других.
Скриншот: Skillbox Media
Диаграмма PERT. Она детализированнее диаграммы Ганта. На ней тоже можно показать даты начала и окончания задачи, её длительность и оставшееся на выполнение время. А ещё она отражает взаимосвязи между задачами.
Диаграмма PERT подойдёт для структурной декомпозиции небольших проектов или отдельных блоков, потому что большое число задач делает её запутанной. Составить такую иерархическую схему можно в SmartDraw, Visme, Edraw Max и других сервисах.
Инфографика: Майя Мальгина для Skillbox Media
- Проект — временное предприятие, направленное на получение уникального результата. В Skillbox Media есть материал, в котором мы подробно разобрали термин — объяснили, в чём разница между проектом и процессом и что может быть целью проекта.
- Управление проектами — самостоятельное широкое направление в менеджменте. В нём множество методик, принципов, концепций и практик. Начать изучение проектного управления можно с этой статьи.
- Декомпозиция — один из множества инструментов, которые могут пригодиться в проектном управлении. Владимир Завертайлов выпустил «Настольную книгу project-менеджера», в которой рассказал, какие ещё инструменты можно использовать и с какими нюансами придётся столкнуться менеджеру проектов.
- Менеджер проектов — человек, который отвечает за результат. Чтобы получить его, нужно уметь управлять сроками, бюджетом и командой. Освоить необходимые навыки можно на курсе Skillbox «Профессия Менеджер проектов». На нём дают универсальные знания, необходимые любому руководителю, и погружают в специфику проектного управления.
Научитесь: Профессия Менеджер проектов
Узнать больше
Иерархическая структура работ (ИСР), или структурная декомпозиция работ, или WBS (Work Breakdown Structure) ― метод разбиения большой цели на чёткие шаги, который позволяет выстроить путь к достижению результата и успешно выполнить рабочий или личный проект.
Команда онлайн-сервиса для управления бизнесом Flowlu рассказывает, зачем формировать ИСР, из чего она состоит и какие принципы помогут её сформировать.
Статья будет особенно интересна проектным командам, владельцам бизнеса, руководителям и тем, кто ставит жизненные цели.
ИСР ― это метод планирования работ, который обычно иллюстрируют в виде многоуровневой схемы задач, где главная задача — это масштабная цель, которая разбивается на этапы, а затем на более мелкие задачи и подзадачи — понятные и достижимые. Деление происходит до того момента, когда все необходимые работы для достижения результата учтены.
На каждую задачу назначаются ответственные.
ИСР позволяет команде сфокусироваться на выполнении конкретных измеримых задач и контрольных точек проекта, что помогает достичь поставленных целей быстрее и эффективнее.
ИСР не включает в себя информацию о сроках и ресурсах и представляет собой первый шаг в проектной стратегии. Далее команда создаёт план-график проекта — документ со списком работ в определённой последовательности и с установленными сроками.
ИСР ― универсальный и широко используемый инструмент. Применить его можно практически ко всему: от собственных целей вроде «купить машину» до разработки программного обеспечения.
Например, вот как может выглядеть ИСР по проекту «Завести собаку»:
Команда наглядно видит, как решение каждой задачи приближает достижение конечного результата.
ИСР обеспечивает эффективное планирование, помогает оценить загруженность команды на разных этапах и корректно закрепить задачи за участниками проекта.
Декомпозиция работ отразит, сколько на каждый этап выделить ресурсов, где задач больше всего, когда может понадобиться больше вложений или людей. А также определит зону ответственности исполнителя перед заказчиком и позволит своевременно выявить недопонимание или вопросы внутри команды — и проработать их.
Видно, на чём нужно заострить внимание, как распределить ресурсы, как заказчик представляет себе поставленные перед командой задачи и что ставит в приоритет.
ИСР становится основой для последующих задач, добавления и корректировки результатов. Может стать шаблоном для типовых проектов.
Кроме ИСР существуют и другие инструменты — их выбор зависит от условий, в которых предстоит реализовать цель.
Например, для завязанных с жёсткими сроками проектов используют метод критического пути, где также отражаются результаты и зависимости между ними, но с одной принципиальной разницей: вносятся определённые сроки их достижения. Все задачи в методе критического пути взаимозависимы, а сроки критичны, и при отклонении от графика нужно применять срочные меры, чтобы не нарушить ход всего проекта.
ИСР более гибкий с этой точки зрения инструмент, но если нужно ориентироваться на дедлайны, то больше подойдёт метод критического пути.
Пункт очевидный, но с нюансом: следует охватить весь спектр нужных задач, при этом оставить за рамками ИСР несоответствующие и посторонние.
Например, в планировании ремонта по ИСР нужно включить закупку материалов, но не нужно — «попросить скидку у поставщика», «ещё раз попросить скидку».
Также не нужно дублировать задачи и слишком детально прописывать шаги.
Здесь главное «что», а не «как» — это поможет концентрироваться на результатах. Например, сравним «составить план на разработку концепции» и «разработанная концепция». Последнее, более ёмкое и краткое, акцентирует внимание на полученном результате — смещает фокус в правильное русло.
Этого достаточно для большинства проектов. Ориентируясь на этот принцип, легче вычленять главное и делать упор на результат. Определить, где остановить декомпозицию, поможет положительный ответ на вопрос, можно ли поставить одного исполнителя на конкретный пакет работ. Если один человек с ним не справится ― разбивайте задачи дальше.
Каждый пакет работ закрепляется за конкретной командой или за отдельным ответственным. Если сформировать ИСР верно, обязанности всем будут понятны и не будут дублироваться.
- Познакомитесь с опытом практикующих экспертов и евангелистов agile
- Сможете поменять стиль управления в бизнесе и донести ценность продукта до клиентов
- Научитесь управлять скоростью вывода продукта на рынок
Исполнитель может составить ИСР проекта самостоятельно. Однако, если в процессе задействовать всю команду, а в идеале и представителя(ей) заказчика, участники будут лучше понимать суть работ, общий результат и отдельные задачи.
Ради чего создаётся планирование и к какому результату нужно прийти ― обозначаем это на вершине иерархической структуры.
Декомпозируем главную цель на достижимые, конкретные результаты.
Выполнить это разделение можно несколькими способами:
- по результатам проекта ― достигнутым вехам, например, при строительстве дома это могут быть фундамент, экстерьер, интерьер;
- по длительности выполнения или срокам — с привязкой к отчётным периодам (кварталам, полугодиям);
- по обязанностям — исполнителя, заказчика или поставщиков;
- по отделам — разработка, маркетинг, техподдержка;
- по финансированию — какие результаты будут достигнуты за счёт выделяемых средств.
Деление опционально и как его выполнять зависит от предпочтений сторон. Так как один и тот же проект может быть представлен в разных способах разделения по ИСР, при выборе советуем отталкиваться от того, какой из критериев важнее конкретно для рассматриваемого проекта.
Нужно сформулировать все задачи, которые станут ответвлениями от этапов, и внести их. По мере закрытия задач проект автоматически будет двигаться по ИСР к главной цели.
После создания уровня иерархии нужно добавить ещё один ― для выписывания подзадач и их группировки в пакеты работ.
Пакетами работ традиционно называют завершающие ответвления ИСР на самом низком уровне, где указываются действия для закрытия этапов. У каждого пакета работ должно быть описание с данными об ответственных и ходе выполнения соответствующих задач.
Это последняя стадия декомпозиции. За каждой задачей закрепляется представитель исполнителя, который будет отвечать за неё и участвовать в каждом из этапов работы.
Выбирая визуализацию ИСР, лучше ориентироваться на комфортное восприятие.
Рассмотрим основные форматы.
Самый простой и доступный вариант построения ИСР. Нужно собрать задачи вместе и расписать их значение и иерархической последовательности, пользуясь числовыми обозначениями для подзадач или располагая их друг под другом в определённой последовательности. Вот как на этом примере:
Показывает зависимость задач друг от друга ― иерархию, но без подробной визуализации. Поскольку это компактная таблица, её удобно построить и разместить в любом файле.
Как понятно из названия, по структуре этот вариант напоминает дерево. Он наглядно отображает суть построения: есть родительская и дочерняя задачи, ведущие к главной цели.
Цели ИСР — определить задачи на каждом этапе работы, показать результаты, которых нужно достичь, и всё это наглядно представить.
Для создания ИСР можно распределять стикеры на доске, использовать простой шаблон в Word или программное обеспечение с поддержкой управления проектами и инструментами для декомпозиции, которое пригодится для взаимодействия ИСР с разными данными и документами.
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Время на прочтение
6 мин
Количество просмотров 65K
Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе, который поможет структурировать каждый этап проекта и учитывать все поставленные задачи. Речь идет об иерархической структуре работ WBS (Work Breakdown Structure).
Если вы помните, как использовать Agile-методологию управления проектами, определять критический путь и ставить SMART-цели, то пришло время перейти к новому уровню компетенции в управлении проектами.
Что такое иерархическая структура работ WBS?
Иерархическая структура работ WBS, или структура декомпозиции, представляет собой схему, где задачи проекта отражают их отношение друг к другу и к проекту в целом. Термин был впервые употреблен в США в 1993 году.
WBS основана на графической природе, которая помогает менеджерам проектов предсказать результаты, основанные на различных сценариях. Процесс часто описывается как структура ответвления, которая охватывает все этапы проекта в организованном порядке. WBS также может быть представлена в виде табличного списка задач и элементов в плане разбивки работ диаграмм Ганта.
Менеджеры используют структуру декомпозиции, чтобы структурировать и делить проекты на легко управляемые компоненты. Они, в свою очередь, разделяются до тех пор, пока они не назначаются конкретному специалисту в команде.
Почему стоит использовать WBS:
- Помогает правильно организовать проекты;
- Оказывает помощь в описании содержания проекта для заинтересованных сторон;
- Помогает распределить обязанности;
- Показывает основные этапы проекта и все ракурсы контроля;
- Позволяет правильно оценить затраты, риски и время работ.
Разберем WBS на примере планирования какого-нибудь мероприятия. Предположим, есть задача — организовать и курировать корпоративной пикник или тимбилдинг. Используя WBS, можно описать и разделить задачи следующим образом:
Планирование: исследование, планирование бюджета, согласование и утверждение плана, вопросы координации.
Питание: меню, закупки, приготовление пищи, обслуживание.
Площадка и активности: столы и посадочные места, посуда, декорирование и оборудование, брендинг.
Участники/гости: приглашения, список гостей, особые случаи.
Персонал: водители, повар, официанты, уборщики.
Хедлайнер: приглашение, вопрос логистики, согласование сценария/ плей-листа.
Компоненты WBS
Согласно иерархической структуре, необходимо пройти несколько этапов (компонентов) для того, чтобы оптимизировать и упростить процесс управления:
- Утверждение концепции проекта;
- Этапы, которые зависят от размера проекта;
- Задачи с промежуточными результатами.
Эти компоненты могут иметь разные названия в зависимости от компании.
5 шагов для разработки простой структуры WBS
Чтобы достичь целей проекта, необходимо следовать определенному плану выполнения WBS.
Начните с концепции проекта и утверждения главных моментов в верхушке иерархии. Определите все необходимые задачи, от которых будут зависеть результаты. В идеале, в процесс планирования и определения концепции должны быть вовлечены усилия всей команды. Тем не менее, каждый специалист должен отвечать за выполнение конкретной задачи.
Итак, шаги:
1. Утвердите и распишите проект
Это может быть просто предложение или абзац, описывающий концепт и функции проекта после завершающей стадии. Эта стадия WBS представляет собой основу любого проекта и, как правило, разрабатывается всей командой.
2. Выделите все ключевые этапы
После того, как первый этап завершен, можно приступать к следующим.
Может быть, вам придется делить задачу на множество этапов в зависимости от характера вашего проекта. Как правило, это зависит от требований, возможностей бюджета и временных рамок.
3. Определите конечные результаты
Сформулируйте для себя все моменты, которые должны быть завершены в течение каждого этапа. Все они должны иметь конечные результаты. Вы должны их достичь полностью, прежде чем перейти к следующему этапу. Каждый конечный результат также должен иметь свое описание, цели и функции.
4. Разделите конечные результаты на управляемые задачи
После создания списка конечных результатов добавьте еще один уровень иерархии для расчета деталей. Задачи проекта должны быть выполнены в виде секций. Любой член команды или небольшая команда будет иметь возможность легко управлять ими.
5. Распределите задачи
Назначение ответственного за каждую часть работ является последней стадией иерархии. Конкретный специалист будет отвечать за конкретную задачу. Он/она будет участвовать в каждом этапе работы, что приведет к качественным результатам.
В видео показан легкий способ создания WBS.
Кто может использовать WBS?
Как правило, менеджеры используют структуру при разработке коммерческих, жилищных и строительных проектов. С ней инвесторам и клиентам проще понять, что и как происходит в развитии проекта.
Разработчики ПО тоже сперва утверждают концепции и создают требований на ее основе. Это придает WBS черты идеального инструмента для разработки.
Если попробовать классифицировать команды, которые могут использовать инструменты WBS, получим такой список:
- Творческие группы. Творческие люди ценят структуру за возможность вместе организовывать мозговой штурм.
- Технические команды. Технически ориентированные специалисты выбирают WBS за аналитическую перспективу охвата работ и их прогрессирование.
- Команды, которые работают непосредственно с клиентами. Иерархическая структура работ хороша для специалистов, разрабатывающих программное обеспечение для клиентов, поскольку она отвечает их потребностям. А еще она помогает повысить уверенность клиента в вашей команде.
- Внутренние проекты команд.
- Удаленные команды.
Преимущества структуры WBS для менеджеров ИТ проектов
Структура WBS стала популярной и широко используемой в разработке программного обеспечения благодаря ее очевидным преимуществам. Руководители проектов смело ее применяют. И вот почему:
1. Усиление коммуникации в команде проекта
Неважно, имеет ли ваш ИТ проект внутреннюю или внешнюю направленность. Иерархическая структура работ включает в себя коммуникационные акты на каждом шагу.
2. Поле для творчества
Похоже на стереотип, но люди думают, что разработка программного обеспечения – это только аналитическая работа. Нет, здесь еще есть пространство для развития творческих способностей. При определении концепции проекта члены команды могут использовать WBS и предлагать творческие идеи для развития проекта.
3. Фокусировка на конечных целях
WBS помогает держать всю команду в фокусе и сосредоточенной на конечной цели. Это сводит к минимуму вероятность выполнения ненужной работы.
4. Детализация
Каждая деталь тщательно рассматривается, поэтому в проекте ничего не теряется.
5. Предвидение появления проблем
Когда проект будет готов, могут возникнуть непредвиденные проблемы. Иерархическая структура работ помогает сократить их число, поскольку все детали учитываются перед выполнением.
6. Коллективный мозговой штурм
Менеджеры используют структуру для мозгового штурма, чтобы найти полезные идеи и решения. С ее помощью их легко собрать, а затем из них вычеркивать ненужные.
7. Вопросы планирования
С помощью WBS легко определить, какие из запланированных задач отстают от графика.
8. Управление рисками
Если вы используете WBS, вы уменьшаете риски и управляете ими с самого начала. Это помогает распределить все ресурсы: денежные средства, время и трудозатраты.
9. Распределение задач
Когда вы структурировали свой проект, становится легче назначать задачи конкретным людям.
10. Гибкость для различных команд
Иерархическая структура работ используется в различных сферах. Не имеет значения, сколько людей в команде: WBS всегда будет поддерживать процесс выполнения проекта. Она также может стать отличным инструментом для привлечения клиентов, так как показывает процессы изнутри и помогает их лучше понять.
WBS + диаграмма Ганта = улучшенный процесс планирования
Для отображения иерархической структуры работ широко распространена практика применения диаграмм Ганта. Именно они четко отображают всю структуру, причем в очень удобном виде. Диаграммы Ганта используются во многих программах и сервисах для управления проектами, таких как GanttPRO, MS Project, Wrike и т.д.
Вот, как это выглядит на примере GanttPRO.
Диаграмма Ганта позволяет расширить функционал иерархической структуры работ. Так, благодаря ей четко видны сроки начала и окончания задачи, ее полная протяженность, кто ее выполняет, каков прогресс выполнения, зависимости между задачами. Кроме того, можно обозначить вехи — важные события, влияющие на проект, а также критический путь.
Онлайн диаграмма Ганта подходит и для управления командой проекта. Под каждой задачей можно оставлять комментарии, прикреплять файлы, делиться самим графиком, экспортировать его в популярные форматы, просматривать историю изменений — командная работы действительно удобна. Впрочем, как и отслеживание других процессов, связанных с управлением проектами.
Подведем итоги
Иерархическая структура работ — распространенный и удобный способ планирования ИТ и любых других проектов. А если отобразить ее диаграммой Ганта, то в таком виде она значительно упрощает процесс не только планирования, но и управления. С ней можно:
- Ставить задачи и распределять их между участниками;
- Задавать сроки выполнения задач, их продолжительность, прогресс;
- Устанавливать зависимости между задачами;
- Визуализировать важные ключевые события — вехи;
- Определять критический путь;
- Взаимодействовать с командой.
Крупные проекты становятся головной болью даже для опытных проджект-менеджеров. Обилие задач, размытые сроки, большое количество дополнительных согласований — все это усложняет работу над проектом и сдвигает дедлайны. Именно поэтому крупные задачи оптимальнее всего прорабатывать по методу WBS или структурной декомпозиции.
Помните популярный прием из тайм-менеджмента — чтобы съесть слона, нужно делать это по кусочкам? Этот принцип и лежит в основе WBS (Work Breakdown System) — структурной декомпозиции. Метод учит разбивать крупный проект на мелкие, выстраивая иерархию задач. Таким образом, сам проект разделяется на блоки, те — в свою очередь — на задачи, задачи — на подзадачи и т. д., пока вы не получите полное представление об объеме всей работы.
Конечно, метод структурной декомпозиции можно применять не только в менеджменте проектов, но и в бытовых вопросах, и в планировании досуга, и в постановке личных целей. Так, например, по WBS можно разбить подготовку к отпуску.
Хорошо, что лето в разгаре, заказчики по отпускам, и можно потеоретизировать. Сегодня у нас на очереди статья о том, что такое WBS проекта и зачем она нужна. Опытные РМы – пропускают, ничего нового там не будет. Новички – читают в обязательном порядке.
Что такое WBS проекта
WBS проекта (она же Work Breakdown Structure или ИСР, Иерархическая Структура Работ) – это разбиение проекта на конкретные результаты, которые должны быть достигнуты для достижения целей проекта.
Как правило, на верхнем уровне указывается сам проект, под ним (на первом уровне) – основные результаты, каждый из которых, в свою очередь, детализируется, то есть следующий уровень всегда меньше предыдущего по объему работ и, как правило, включает 2 и более пакетов работ. При этом в разных ветках WBS может быть разное количество уровней в зависимости от нужной степени детализации.
На словах, как всегда, мало что понятно, поэтому любимый пример с ремонтом (картинка большая, для детального просмотра ее лучше открыть в новой вкладке):
В конце поста будут ссылки на скачивание этого и других примеров WBS!
Важно понимать, что в WBS собираются именно результаты работ, а не задачи, которые нужно выполнить для получения этих результатов.
В классическом подходе все блоки WBS (так называемые Work Packages) нумеруются, но в жизни я таких ответственных РМов видела буквально несколько раз. Сама я, как правило, нумеровать не то что бы ленюсь – просто не вижу смысла, так как после завершения планирования WBS использую как инструмент оперативного управления, и при нумерации становится сложнее поддерживать корректную интеграцию в проекте.
Зачем нужна WBS
WBS – крайне полезная вещь в планировании проекта и вот почему:
- WBS – если не единственный, но точно самый эффективный способ наглядно отразить весь объем проекта.
- WBS фокусирует внимание не на процессе а на ожидаемом результате, и создает нужный «посыл».
- В идеале в разработке WBS участвует заказчик или его представитель и вся команда, что позволяет а) обеспечить единое понимание результатов проекта и его объема б) увидеть важность и вклад отдельных элементов в общий результат
- С помощью WBS можно наглядно обосновать необходимости в финансах или человеческих ресурсах, так как против конкретного описанного объема возражать гораздо сложнее, чем против «да что там системку написать, посадите программиста и все».
- WBS помогает предотвратить риски и изменения или по крайней мере значительно (очень значительно!) снизить их вероятность и влияние, так как именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем другое» (и так и должно быть, для этого инструмент и предназначен).
- На уровне WBS уже можно определить и согласовать контрольные точки проекта (как для решений о продолжении проекта после очередного этапа, так и для контроля затрат человеческих и финансовых ресурсов).
Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во вторых – у вас появится хороший рычаг влияния на будущее.
Группировка и декомпозиция WBS
Первый вопрос, который возникает в начале создания WBS – как группировать элементы WBS, по какому принципу?
Способ группировки, как правило, выбирается в зависимости от проекта, основной критерий тут – чтобы было понятно вам и команде.
Классические варианты группировки WBS:
- По стадиям жизненного цикла проекта (например, отдельно описываются результаты фаз планирования, анализа, разработки, приемки и проч.) – это самый простой и популярный подход, особенно если проект идет по утвержденному процессу и всем понятно, что должно быть на выходе какой фазы.
- По высокоуровневым результатам проекта (проект разбивается на ключевые результаты, например, готовая система, обученные пользователи, разработанная нормативная документация, согласованное использование системы с государственными органами и проч.) – я чаще всего использую именно этот вариант, мне нравится видеть конкретные результаты проекта и, на мой взгляд, этот формат лучше понимает заказчик.
- По организационной структуре (например, вы, заказчик, подрядчик(и) и проч.) – этот вариант удобен, когда вам надо жестко разграничить ответственность за результаты работ.
- Про срокам (например, по кварталам) – если для проекта критична привязка к срокам.
- По техническим областям (производство, маркетинг, закупки и проч.)
- По источникам финансирования (какая часть результатов за какие средства достигается или за бюджет какого года, например).
- По странам (такое видела однажды всего на одном из международных проектов, и показалось крайне неудобным).
Одним словом – можно любой свой вариант придумать, лишь бы было удобно.
Второй любимый вопрос начинающего PMа – до какой степени нужно детализировать WBS? Забавно, но правильного ответа на этот вопрос не существует. Степень декомпозиции зависит как от размера, так и от типа проекта, а также от количества времени, которое вы можете потратить на проработку.
Поэтому ответ очень простой – при планировании проекта и разработке WBS нужно просто определиться, какой объем работы на нижнем уровне для вас приемлем, чтобы вы могли ее контролировать. Слишком большие задачи – плохо, так как не будет понимания реальной картины, слишком маленькие – тоже плохо, так как найти время на контроль станет сложнее (например, если вы контролируете результат раз в неделю – нет смысла бить задачу на однодневные результаты, проверить все равно сможете только в комплексе).
При подготовке к сдаче PMP в книжке Риты Малкахи приводятся такие усредненные рекомендации:
- Для маленьких проектов – 4-40 часов,
- Для средних проектов – 8-80 часов
- Для больших проектов – в зависимости от масштаба, но желательно не более 300 часов.
В жизни такой идеальный баланс найти не всегда удается, поэтому в WBS попадают как небольшие задачи, результат которых критически важен для проекта, так и крупные. Так, например, в примере с ремонтом есть как «закрытие договора с текущим ЖЭКом» длительностью максимум 30 минут (ЖЭК у меня на 1м этаже сидит в соседнем подъезде), так и штукатурка по маякам, которая несколько дней займет (но мне с этим комфортно, так как проконтролировать промежуточный результат или как-то всерьез повлиять на скорость высыхания штукатурки я все равно не смогу).
В работе лично я стараюсь ориентироваться на планку «8 часов на нижнем уровне WBS».
Самый простой критерий, по которому можно проверить, что вы достигли «дна» WBS – это возможность поставить конкретную задачу одному исполнителю для выполнения указанного пакета работ. Если исполнителей несколько и выделить среди них единого ответственного нельзя – значит, нужно декомпозировать дальше.
К слову, декомпозиция может идти как сверху вниз (мы детализируем высокоуровневые результаты) или снизу вверх (у нас есть разрозненное понимание отдельных задач, и мы их компонуем в более высокоуровневые для облегчения понимания и управления).
Третий вопрос, отражающий веяния времени – что делать, если проект выполняется по гибкой методологии и результаты вы получаете итерационно?
Правильного ответа тоже нет, но есть варианты:
- Отражать итерации как способ группировки (каждый итерация или спринт идут отдельным блоком в WBS) – удобно, если результаты спринтов заранее известны.
- Разбивать каждый из результатов на итерации – удобно, если у вас делается сразу весь объем, а в дальнейшем только улучшается и детализируется (но тут нужно очень хорошо понимать объем проекта, что при agile бывает не так часто)
- Использовать обычную WBS и уточнять ее для каждой итерации (то есть количество WBS в итоге будет равно количествам итераций)
- Просто использовать обычную WBS и ограничиться этой степенью детализации.
- Любой другой вариант, дающий вам нужную степень понимания и детализации.
Инструменты для разработки WBS
Единственное правило тут – разрабатывать в том, в чем удобно. Если у вас есть какой-то инструмент для построения диаграмм – отлично, если нет – подойдет любой другой, например, Mind Manager, Excel, MS Project, Visio или любой онлайн-аналог.
Я последние пару лет перешла от диаграмм к майнд-мепам (ментальным картам), на мой взгляд, формировать структуру работ там очень удобно из-за гибкости инструмента. Самый неудачный выбор, на мой взгляд – это Excel или MS Project, так как они сводят создание WBS к работе со списками и не дают нужной наглядности.
Типовая ошибка тех, кто делает WBS в MS Project – одновременно пытаться описать результаты и указать зависимости (в самых тяжелых случаях – еще и трудоемкость и ресурсы). Цель WBS – получить именно полное содержание проекта, а не закрыть задачу планирования одним махом. А еще так легко что-то упустить, так как представление в MS Project не наглядное.
WBS Dictionary или Словарь ИСР
WBS Dictionary (он же Словарь ИСР) – это описание на страничку А4 (или подробнее) для каждого пакета работ, включающее код пакета работ, его наименование, детальное описание результата, критерии приемки, ответственного (это, наверное, самое ценное в словаре), ограничения и допущения и вообще все, что кажется вам полезным.
Я сама в жизни это использовала буквально 2 или 3 раза, слишком уж трудозатратная вещь, тем более в очень динамичных проектах разработки ПО. В какой-нибудь стройке или энергетике, наверное, без этого никуда.
Это, наверное, все, что нужно знать о создании и использовании WBS для старта. Удачи!
P.S. И да, неполная, недостаточная и не совсем правильная WBS все равно гораздо лучше, чем ее отсутствие
Cкачать пакет примеров реальных WBS с различных проектов вы можете всего за 199 руб. После оплаты на почту вы получите архив с WBS по трем реальным проектам и – бонусом! – WBS приведенного в посте примера с ремонтом, в котором уже настроено удобное форматирование для построения своего варианта. В пакет входят WBS для проектов разного типа – создания новой ИТ-системы с нуля, доработки существующей системы и миграции с одной системы на другую. Также в них разный фокус и разный уровень детализации, чтобы, ознакомившись с примерами WBS, вы смогли сделать свою WBS такой, какая нужна именно вам. Все файлы WBS представлены как в исходном формате mmap (открываются в Mindjet MindManager), так и в jpg с высоким разрешением на тот случай, если у вас не установлен MindJet. Воспользуйтесь чужим опытом и сэкономьте свое время, оно стоит намного дороже! Скачайте примеры, изучите их и начните строить WBS для вашего проекта на основе лучших практик прямо сейчас!
Купить шаблоны за 199 руб.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 