WBS (иерархическая структура работ) для ИТ-проекта: пример + шаблон
«Мы забыли про обучение пользователей. И про документацию»
Вы утвердили бюджет, наняли команду, начали проект, а через месяц выясняется, что половина работ не учтена: забыли про тестирование, не заложили время на обучение, документацию вообще никто не писал. Знакомая ситуация?
Проблема в том, что многие планируют «на глаз» — сразу задачи, сроки, ресурсы — и пропускают важный шаг — декомпозицию работ. WBS (Work Breakdown Structure) — это разбивка всего проекта на мелкие, управляемые компоненты. Без неё вы не знаете, из чего состоит проект и что уже сделано.
Что такое WBS и почему она нужна
Вы берёте проект целиком и разбиваете на части, части — на подчасти, и так до уровня задач, которые можно оценить и поручить. В WBS три главных принципа.
Первый — правило 100%. WBS должна включать всю работу проекта и только её. Если вы забыли про обучение пользователей, вы нарушили это правило.
Второй — ориентация на результат. Элемент WBS — это результат, а не действие. «Написать код» — это действие, «Модуль авторизации» — это результат.
Третий — декомпозиция до рабочего пакета (4–80 часов). Каждый элемент должен быть таким, чтобы его можно было оценить и поручить одному человеку. Если задача больше 80 часов — разбейте её дальше.
Для ИТ это особенно важно: WBS помогает не забыть про управление проектом, обучение пользователей, документацию, тестирование и инфраструктуру. Всё то, что чаще всего выпадает из фокуса при планировании «на глаз».
Основные правила построения WBS
Элемент WBS — это результат, а не действие, поэтому используйте существительные, а не глаголы: «Модуль авторизации», а не «написать модуль авторизации». Сумма подзадач должна равняться родительской задаче — ничего не должно выпадать и ничего не должно добавляться. Одна работа не может входить в две ветки — никаких пересечений. Рабочий пакет должен быть в диапазоне 4–80 часов — если больше, декомпозируйте дальше. И обязательно выделите отдельную ветку для управления проектом — про это часто забывают.
Как выбрать подход к построению WBS
Можно строить WBS по-разному, в зависимости от типа проекта. По фазам — разбивка по этапам жизненного цикла (анализ, проектирование, разработка, тестирование, внедрение). Такой подход подходит для Waterfall-проектов. По компонентам — разбивка по модулям или функциям (модуль авторизации, модуль каталога, модуль корзины, модуль оплаты). Это для продуктовой разработки. По требованиям — разбивка по пользовательским историям — для Agile-проектов. И гибридный подход, который сочетает фазы и компоненты, — для большинства реальных проектов.
Пример WBS для ИТ-проекта
Внедряем модуль «Командировки и авансовые отчёты». Вот как выглядит структура.
Управление проектом (8% от общих трудозатрат). Сюда входит разработка устава, планирование проекта (WBS, расписание, бюджет), управление коммуникациями (отчёты, встречи, демо), управление изменениями и закрытие проекта (приёмка, уроки, архивация).
Обследование и требования (12%). Интервью с ключевыми пользователями, описание бизнес-процессов (As-Is), описание целевых бизнес-процессов (To-Be), формирование требований к системе и их согласование с заказчиком.
Проектирование решения (10%). Разработка архитектуры интеграции с 1С, проектирование базы данных, проектирование интерфейсов (макеты, прототипы), проектирование маршрутов согласования и утверждение проектных решений.
Разработка и настройка (35%). Разработка модуля заявок на командировку, модуля авансовых отчётов, маршрутов согласования, интеграции с 1С и настройка прав доступа и ролей.
Тестирование (15%). Модульное тестирование, интеграционное тестирование, тестирование производительности, приёмочное тестирование (UAT) с пользователями и исправление дефектов.
Внедрение и обучение (12%). Подготовка тестовой среды, миграция данных (пилотная группа), обучение пользователей (50 человек), разработка пользовательской документации и ввод в опытно-промышленную эксплуатацию.
Сопровождение и поддержка (8%). Поддержка в период ОПЭ (2 недели), исправление ошибок, выявленных в ОПЭ, доработки по результатам ОПЭ и передача в промышленную эксплуатацию.
Итог: 7 основных веток, 35 рабочих пакетов на уровне 3–4. Каждый пакет можно оценить и поручить одному исполнителю.
Ошибки, которые превращают WBS в бесполезный список
Самая частая ошибка — смешивание работ и результатов. Когда вы пишете «написать код» вместо «модуль авторизации», непонятно, что считать завершённым. Всегда формулируйте как результат, используя существительные.
Вторая ошибка — пропуск управления, обучения и документации. Если у вас нет ветки «Управление проектом», вы забываете про планирование и отчётность. Всегда добавляйте такую ветку, она должна составлять 5–10% бюджета.
Третья ошибка — слишком глубокая детализация на старте. Когда вы детализируете до уровня «написать функцию», вы тратите время на то, что изменится. Детализируйте только ближайшие 2–4 недели, остальное оставляйте на верхнем уровне.
Четвёртая ошибка — декомпозиция не до рабочих пакетов. Когда вы оставляете задачи по 200 часов, их невозможно оценить и поручить. Дробите до 4–80 часов.
Что в понедельник утром
Возьмите свой текущий проект и попробуйте разбить его на три уровня. Проверьте, не забыли ли про управление, обучение, документацию и тестирование. Если какой-то пакет больше 80 часов — разбейте дальше. И покажите структуру команде, спросите: «Что мы упустили?».
Заключение
WBS — фундамент планирования. Без неё расписание неточное, бюджет заниженный, ответственность размыта. С ней вы видите полную картину. Правила просты: результат, 100%, пакеты 4–80 часов, ветка управления. И главное — не детализируйте всё сразу, идите от крупных блоков к мелким, уточняйте по мере движения.
Хотите научиться строить WBS и другие артефакты управления проектами на практике? В модуле 4 курса «Мастер управления IT-проектами» мы на воркшопах строим WBS для ваших реальных проектов. Подробнее о курсе →