Work breakdown structure что это
Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов
Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе, который поможет структурировать каждый этап проекта и учитывать все поставленные задачи. Речь идет об иерархической структуре работ WBS (Work Breakdown Structure).
Если вы помните, как использовать Agile-методологию управления проектами, определять критический путь и ставить SMART-цели, то пришло время перейти к новому уровню компетенции в управлении проектами.
Что такое иерархическая структура работ WBS?
Иерархическая структура работ WBS, или структура декомпозиции, представляет собой схему, где задачи проекта отражают их отношение друг к другу и к проекту в целом. Термин был впервые употреблен в США в 1993 году.
WBS основана на графической природе, которая помогает менеджерам проектов предсказать результаты, основанные на различных сценариях. Процесс часто описывается как структура ответвления, которая охватывает все этапы проекта в организованном порядке. WBS также может быть представлена в виде табличного списка задач и элементов в плане разбивки работ диаграмм Ганта.
Менеджеры используют структуру декомпозиции, чтобы структурировать и делить проекты на легко управляемые компоненты. Они, в свою очередь, разделяются до тех пор, пока они не назначаются конкретному специалисту в команде.
Почему стоит использовать WBS:
Планирование: исследование, планирование бюджета, согласование и утверждение плана, вопросы координации.
Питание: меню, закупки, приготовление пищи, обслуживание.
Площадка и активности: столы и посадочные места, посуда, декорирование и оборудование, брендинг.
Участники/гости: приглашения, список гостей, особые случаи.
Персонал: водители, повар, официанты, уборщики.
Хедлайнер: приглашение, вопрос логистики, согласование сценария/ плей-листа.
Компоненты WBS
Согласно иерархической структуре, необходимо пройти несколько этапов (компонентов) для того, чтобы оптимизировать и упростить процесс управления:
5 шагов для разработки простой структуры WBS
Чтобы достичь целей проекта, необходимо следовать определенному плану выполнения WBS.
Начните с концепции проекта и утверждения главных моментов в верхушке иерархии. Определите все необходимые задачи, от которых будут зависеть результаты. В идеале, в процесс планирования и определения концепции должны быть вовлечены усилия всей команды. Тем не менее, каждый специалист должен отвечать за выполнение конкретной задачи.
1. Утвердите и распишите проект
Это может быть просто предложение или абзац, описывающий концепт и функции проекта после завершающей стадии. Эта стадия WBS представляет собой основу любого проекта и, как правило, разрабатывается всей командой.
2. Выделите все ключевые этапы
После того, как первый этап завершен, можно приступать к следующим.
Может быть, вам придется делить задачу на множество этапов в зависимости от характера вашего проекта. Как правило, это зависит от требований, возможностей бюджета и временных рамок. 
3. Определите конечные результаты
Сформулируйте для себя все моменты, которые должны быть завершены в течение каждого этапа. Все они должны иметь конечные результаты. Вы должны их достичь полностью, прежде чем перейти к следующему этапу. Каждый конечный результат также должен иметь свое описание, цели и функции.
4. Разделите конечные результаты на управляемые задачи
После создания списка конечных результатов добавьте еще один уровень иерархии для расчета деталей. Задачи проекта должны быть выполнены в виде секций. Любой член команды или небольшая команда будет иметь возможность легко управлять ими.
5. Распределите задачи
Назначение ответственного за каждую часть работ является последней стадией иерархии. Конкретный специалист будет отвечать за конкретную задачу. Он/она будет участвовать в каждом этапе работы, что приведет к качественным результатам.
В видео показан легкий способ создания 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 обычно происходит в начале проекта и предшествует подробному планированию проекта и задач.
История
К июню 1962 года Министерство обороны, НАСА и аэрокосмическая промышленность опубликовали документ для системы PERT / COST, в котором описывался подход WBS. Это руководство было одобрено министром обороны для принятия всеми службами. В 1968 году Министерство обороны выпустило «Структуры аварийного отключения для оборонных материалов» (MIL-STD-881), военный стандарт, требующий использования структур аварийного отключения по всему Министерству обороны.
Документ пересматривался несколько раз, последний раз в 2018 году. Текущую версию этого документа можно найти в разделе «Структуры разбивки работ для элементов оборонных материалов» (MIL-STD-881E). Он включает определения WBS для конкретных товарных систем оборонного оборудования и обращается к элементам WBS, которые являются общими для всех систем.
Категории предметов военной техники по стандарту MIL-STD-881E:
Общие элементы, указанные в MIL-STD-881E, Приложение K: Интеграция, сборка, тестирование и проверка; Системная инженерия; Программный менеджмент; Системное тестирование и оценка; Данные; Своеобразное вспомогательное оборудование; Общее вспомогательное оборудование; Оперативная / активация сайта; Материально-техническое обеспечение подрядчика; Промышленные объекты; Первичные запчасти и запчасти. Стандарт также включает дополнительные общие элементы, уникальные для космических систем, систем ракет-носителей и стратегических ракетных систем.
В 1987 году Институт управления проектами (PMI) задокументировал распространение этих методов на не оборонные организации. В Руководстве по совокупности знаний по управлению проектами (PMBOK) представлен обзор концепции WBS, в то время как «Практический стандарт для структур декомпозиции работ» сопоставим со стандартом DoD, но предназначен для более общего применения.
Принципы дизайна
100% правило
Важный принцип проектирования структурной разбивки работ называется правилом 100%. Это было определено следующим образом:
Взаимоисключающие элементы
Планируйте результаты, а не действия
Уровень проработанности деталей
Надо решить, когда перестать разбивать работу на более мелкие элементы. Для большинства проектов достаточно иерархии от двух до четырех уровней. Это поможет в определении продолжительности действий, необходимых для получения результата, определенного WBS. Есть несколько эвристик или «эмпирических правил», используемых при определении подходящей продолжительности действия или группы действий, необходимых для получения конкретного результата, определенного WBS.
Схема кодирования
Практический пример схемы кодирования WBS:
1.0 Авиационная система
1.1 Воздушный транспорт 1.1.1 Планер 1.1.1.1 Интеграция, сборка, испытания и проверка планера 1.1.1.2 Фюзеляж 1.1.1.3 Крыло 1.1.1.4 Оперение 1.1.1.5 Гондола 1.1.1.6 Другие компоненты планера 1..n (указать) 1.1.2 Движение 1.1.3 Подсистемы автомобиля 1.1.4 Авионика 1.2 Системное проектирование 1.3 Управление программой 1.4 Системное тестирование и оценка 1.5 Обучение 1.6 Данные 1.7 Особое вспомогательное оборудование 1.8 Общее вспомогательное оборудование 1.9 Операционная / активация сайта 1.10 Промышленные объекты 1.11 Первоначальные запасные части и запасные части
Терминальный элемент
Соответствует нормам
Структура WBS более высокого уровня должна соответствовать любым нормам или шаблонам, существующим в организации или домене. Например, судостроение для ВМС США должно учитывать, что морские термины и их иерархическая структура, заложенные в MIL-STD, встроены в военно-морскую архитектуру и что соответствующие офисы и процедуры ВМС были построены в соответствии с этой структурой военно-морской архитектуры, поэтому любое существенное изменение Нумерация или именование СПП-элементов в иерархии недопустима.
Пример
На соседнем рисунке показана техника построения структурной декомпозиции работ, демонстрирующая правило 100% и технику «прогрессивной проработки». На уровне 1 WBS он показывает 100 единиц работы как общий объем проекта по разработке и созданию нестандартного велосипеда. На уровне 2 WBS 100 единиц разделены на семь элементов. Количество единиц, выделяемых на каждый элемент работы, может зависеть от усилий или затрат; это не оценка продолжительности задачи.
Дизайн WBS может поддерживаться программным обеспечением (например, электронной таблицей ), чтобы обеспечить автоматическое объединение значений точек. Оценки трудозатрат или затрат можно получить в ходе обсуждений между членами проектной группы. Этот метод совместной работы позволяет лучше понять определения содержания, исходные допущения и консенсус относительно уровня детализации, необходимого для управления проектами.
4 инструмента по полочкам. Управление проектами с WBS, Диаграммой Ганта, CPM и Time-Cost
Я не раскрою тайну, если скажу, что выстроенное управление проектами — ключ к успеху проекта. Каждый из менеджеров проектов или команд выбрал, на интуитивном уровне или практическом опыте, для себя набор инструментов, помогающих в выстраивании процессов и отношений в команде.
В течение времени инструменты управления проектами перешли от карандаша и листа бумаги (иногда они и возвращаются в виде Канбан доски в офисе) к софту для управления проектами и спредшитам (как оффлайн, так и онлайн, от простого плана проекта с использованием диаграммы Ганта и Канбан досок, заканчивая комплексными системами), призванными облегчить управление, которые так просто выбрать… и пролететь, потому что непонятно, для чего и в чем премущества.
Поэтому, так или иначе, выбор инструментов не стоит начинать с софта (кстати, здесь был большой список из 43 систем для управления проектами). Беру на себя смелось перевести неплохой гайд по четырем инструментам управления проектами от TakingITGlobal, являющихся базой для многих систем.
Work Breakdown Structure (Иерархическая Структура Проекта)
Для упрощения управления сложным проектом целесообразно его разделять на компоненты в иерархическую структуру, так называемую ИСП, или WBS (the work breakdown structure). Такая иерархическая структура проекта может быть представлена в виде блочной диаграммы:
План Иерархической Структуры Проекта
Терминология для разных уровней
Каждая организация использует собственную терминологию для классификации компонентов ИСП, согласно их уровню иерархии. Например, некоторые организации разделяют на разные уровни задачи, подзадачи и перечни работ.
Другие же используют фазы, данные и активности.
Устройство иерархии по результатам и фазам работ
ИСП может быть сформирована вокруг фаз и результатов проекта на протяжении всего его жизненного цикла. За более высокие уровни структуры обычно ответственны рабочие группы. Тогда как задачи нижнего уровня выполняются индивидуально. Таким образом, в ИСП как структуре, основанной на результатах, вовсе не обязательно создавать конкретные задачи.
Уровень деталей
Разбиение проекта на компоненты ускоряет распределение ресурсов и устанавливает сферы ответственности каждого члена команды. Чем лучше вы детализируете вашу ИСП, тем более точными будут ваши действия.С одной стороны, не следует слишком детализировать структуру, чтобы не стать жертвой микро-менеджмента. Но с другой, не стоит делать элементы слишком крупными, чтобы сохранить их управляемость. Оптимальная величина элементы — от нескольких дней до нескольких месяцев.
Назначение ролей в планировании проекта
ИСП — это основа планирования проекта. Однако она делается тогда, когда вы четко знаете взаимосвязь ваших задач и время, необходимое на их решение. ИСП создается специально, чтобы выделить задачи в CPM или PERT подходах.
Диаграммы Ганта
Диаграммы Ганта
в наше время являются стандартом в управлении проектами, принципы которых используют как в теории, так и в практике.
В эру научного менеджмента Генри Гант создал инструмент, который показывает прогресс проекта в специальной диаграмме. Изначально диаграмма создавалась для отслеживания процесса построения кораблей. Сегодня же этот инструмент представляет собой горизонтальную столбчатую диаграмму для управления проектами.
Горизонтальная ось в диаграмме Ганта — шкала времени, которая может быть выражена в абсолютном значении либо значении времени, привязанного к началу проекта. Выбор времени зависит от типа проекта: обычно используются недели или месяцы. Столбы в диаграмме показывают время начала и окончания индивидуальной задачи в проекте.
Для больших проектов, задачи могут быть разделены на подзадачи, которые имеют собственные дополнительные диаграммы Ганта для более удобного прочтения.
Как можно улучшить диаграмму Ганта?
Начальная версия диаграммы Ганта (будут это шаблоны диаграммы Ганта, или же созданные вами проекты) зачастую требует внедрения дополнительных элементов для того, чтобы она мультифункциональная и эффектина не только для построения проектов, но и для управления ими.
Сильная сторона диаграммы Ганта в возможности наглядно отобразить статус каждой задачи, создавать план проекта с шаблоном диаграммы, отслеживать процессы на основе приоритетного планирования. Обычно диаграммы Ганта строят в специальном софте для управления проектами, например, Gantt chart — GanttPRO, Smartsheet или Wrike.
CPM (Метод Критического Пути)
Критический путь
В 1957 году американская компания DuPont разработала метод, который предназначался для решении проблемы закрытия химических заводов компании для ремонта и последующего старта, когда ремонт будет завершен. Понимая всю сложность данного проекта, компания решила воспользоваться Методом Критического пути для решения такой задачи.
Такой дает следующие преимущества:
Диаграммы критического пути
Определите индивидуальные задачи
Для создания ИСП следует начать со списка всех задач проекта. Он может быть использован как базис для создания последовательностей и оценки времени выполнения проекта на следующих этапах.
Определение последовательности задач
Выполнение одних задач напрямую связано с окончанием других. Определите, какие задачи следует выполнить в первую очередь, чтобы другие задачи не сдвигались.
Нарисуйте диаграмму в виде сети взаимосвязанных задач
Когда задачи и их последовательность определена, может быть построен критический путь. Изначально он создавался как узловая активность, но сейчас некоторые менеджеры проектов предпочитают показывать его в виде арок.
Оцените время каждой активности.
Время, требуемое для завершения каждой задачи, может быть оценено на основе прошлого опыта или оценок экспертов. В то же время, критический путь — это оценочная модель, которая не учитывает разные варианты окончаний задач.
Определение критического пути
Это наибольшая по длительности цепочка задач в вашей системе. Его важность заключается в том, что задачи, располагающиеся на этом пути не могут быть отложены либо просрочены без переноса дедлайнов проекта. Такой вид анализа очень важен для оценки длительности проекта в целом.
Критический путь может быть определен 4 ключевыми параметрами каждой активности:
Критический путь — это цепочка через всю сеть задач проекта, в которой ни одна из задач не имеет резервного времени, когда БС=ПН и БО=ПО для всех задач на пути. Перерыв автоматически ведет к сдвигу проекта. Если подводить итог, то чтобы уменьшить длительность проекта, нужно уменьшить время на задачи на критическом пути.
Обновление критического пути
По ходу проекта становится ясным настоящее время завершения проекта или диаграмму следует обновлять для включения этой информации. Может появиться новый критический путь с новыми дедлайнами и структурными изменениями.
Ограничения критического пути
Разработан для сложных, но достаточно рутинных проектов с возможность минимального изменения времени завершения задач. Для более хаотичных проектов критический путь теряет свою полезность. Альтернатива — модель PERT, которая позволяет менять длительность каждой активности.
Время-Затраты
Между временем завершения проекта и его стоимостью есть взаимосвязь. Кэп. Для некоторых видов затрат эта взаимосвязь прямая. В других типах затраты изменяются за счет других.Для этих двух типов затрат, существует оптимальный шаг времени по минимальной стоимости. Понимая отношение время-стоимость, становится проще вычислить стоимость отсрочек в проекте.
Виды затрат
Затраты проекта классифицируются как прямые и непрямые.
Сжатие графика выполнения проекта
Уменьшение или вовсе поломка графика выполнения проекта используется для ускорения работ проекта для завершения его хода в более ранний срок. Время, требуемое для завершения проекта, определяется критическим путем, поэтому, чтобы уменьшить время всего проекта, нужно в первую очередь сосредоточиться на задачах критического пути.
Процесс определения оптимального времени проекта состоит из вычисления нормального (среднего) времени выполнения каждой задачи на критическом пути и экстремального времени. Экстремальное время — это наименьший срок, требуемый для завершения задачи. Прямые затраты подсчитываются и на задачи, выполняемые в нормальном и экстремальном времени. Коэффициент показывает затраты на единицу времени каждой конкретной задачи. Он показывает сколько будет стоить ускорение выполнения каждой задачи:
Стоимость = (Экстремальные затраты — Оптимальные затраты) / (Оптимальное время — Экстремальное время)
Те задачи, которые имеют наименьшую стоимость в единицу времени должны быть сокращены в первую очередь. Таким образом, следует пройтись по пути и подсчитать общее отношение затрат проекта к времени проекта. Непрямые, прямые и общие затраты могут быть подсчитаны для различной длительности проекта.
Оптимальная стоимость проекта — это точка, которая будет находиться в самой нижней части суммарной стоимостной кривой.
Затраты проекта по отношению к длительности
Следует уделить внимание критическому пути после того, как длительности задач будут сокращены. Если появится новый путь, следует подумать о новых сокращениях времени.
Чтобы минимизировать затраты, задачи, которые не лежат на критическом пути, могут быть расширены без увеличения продолжительности их выполнения.
Допущения в модели Время-Затраты
Дополнительные суждения
Есть и другие точки зрения относительно затрат проекта. Например, если проект является частью разработки нового продукта, время выхода на рынок может стать очень важным. И может быть выгодным ускорение темпов проекта к точке, когда затраты будут намного выше минимальных.
В работе по контракту, могут рассматриваться дополнительная оплата как вознаграждение за раннее окончание работ или штрафы за отставание. Такие вознаграждения и штрафы можно отнести к непрямым затратам.
Поскольку критически путь чрезвычайно важен в уменьшение сроков выполнения проекта, такие техники планирования, как критический путь или PERT, могут быть использованы перед тем, как сокращать график выполнения проекта.