Элитные страдания с Work Breakdown Structure (WBS)
Оглавление
Преамбула
Редко теперь встретишь, чтобы этот артефакт реально использовался на практике (хотя не то, чтоб я прям следил за этим трендом). Хотя WBS может быть очень полезен. Моя основная боль в том, что мало кто понимает, зачем этот документ вообще нужен и что в нем должно быть. А если и понимают, то в итоге выходит что-то малопригодное. В целом я люблю шаблоны и стандарты, когда дело касается бизнеса и работы. Но здесь важнее смысловое содержание и сам подход, чем просто форма.
Давай разберемся в том, зачем этот документ нужен, из чего должен состоять, как может выглядеть и какую пользу приносить.
Что за WBS и зачем он в целом нужен?
WBS — это такая штука, которая помогает разбить большой проект на более мелкие и понятные кусочки. Представь, что у тебя есть огромная задача, и ты не знаешь, с чего начать. WBS помогает разложить её на части, чтобы всё стало проще. Типа "разделяй и властвуй", только для задач. Она делает проект более управляемым: видишь всё, что нужно сделать, понимаешь, кто за что отвечает и сколько времени на это уйдет. Проще говоря, WBS — это способ превратить хаос в собранный пазл.
Такой подход помогает увидеть весь объем работы и не упустить ничего важного. Плюс, когда задача слишком большая, её сложно оценить и контролировать, а когда всё разложено по полочкам, то ты уже понимаешь, какие кусочки нужно делать, и кто из команды за это отвечает. Это особенно полезно в команде, где каждый знает, что ему делать и когда. (Ну а если не знают что делать — то у них есть менеджер. Ты всегда подскажешь, направишь, поделишься задачами)
Особенно полезно формировать WBS на самом старте проекта, ещё до того, как определились с роадмапой и приоритетами. Это помогает понять полный объем работы, разделить его на части и оценить, что реально потребуется для выполнения каждой задачи. Когда у тебя есть чёткое представление о том, из чего состоит проект, проще устанавливать приоритеты и формировать роадмапу — ведь ты уже знаешь, какие куски работы самые критичные и какие ресурсы понадобятся.
Давай теперь подумает над тем, из чего должен состоять WBS чтоб приносить максимальную пользу.
Из чего состоит WBS
Какие боли и потребности закрывает этот документ
WBS помогает закрыть множество потребностей в управлении проектами. Вот основные боли и задачи, которые этот документ решает:
- Упрощает коммуникацию в команде.
- Помогает оценить необходимый объем работы;
- Делает задачи понятными и структурированными;
- Снижает риск упущения критически важных задач;
- Упрощает планирование и расстановку приоритетов;
- Делает контроль сроков и прогресса более удобным;
- Обеспечивает более точное распределение ресурсов между задачами.
Тут такая штука — ты можешь и от себя добавить пару пунктов. Я тут выделил основные, которые беспокоят меня с высоты моего опыта. Но моим опытом все не ограничивается, так что если надо — дополняй.
Теперь, когда примерный список понятен, давай переходить к размышлению о том, из чего должен состоять этот документ: какие компоненты, элементы и так далее.
Переходим к деталям: что должно быть в WBS?
Предлагаю идти по порядку. У нас сформировался внушительный список болей и потребностей, которые этот документ должен покрывать. Давай разбирать их по очереди и пока чисто теоретически размышлять, какие компоненты, абстракции или секции должны присутствовать в документе.
1. Упрощает коммуникацию в команде
Значит, в документе должны быть указаны команды. Задачи должны быть каким-то образом распределены или как минимум относиться к разным департаментам/командам, чтобы это было прозрачно и наглядно.
2. Помогает оценить необходимый объем работы
Не знаю, как для вас, но для меня очевидно, что здесь должна присутствовать оценка (эстимейт). А оценивать гораздо удобнее что-то маленькое и не слишком объемное, то есть декомпозированное. Поэтому в документе все фичи и компоненты должны быть декомпозированы до минимально необходимого уровня, чтобы команды, упомянутые в пункте выше, могли их оценить.
3. Делает задачи понятными и структурированными
Ну, "понятными" — тут речь о формулировке. Значит, формулировка должна максимально точно описывать сам компонент/элемент/фичу, либо должен быть комментарий для уточнения.
Что касается структуры, то думаю, мы могли бы это интерпретировать как "наследственность" и "последовательность". То есть весь скоуп мы декомпозируем последовательно (по очереди) и каждый из них декомпозируем "вглубь", тем самым создавая интуитивно понятную структуру, по которой будет легко ориентироваться, а не просто вываливаем список из 100500 фич без какой-либо сортировки.
4. Снижает риск упущения критически важных задач
Думаю предыдущие 2 пункта справятся.
5. Упрощает планирование и расстановку приоритетов
Очевидно, что в WBS должен быть способ приоритизации (желательно на основании конкретных данных, а не "пальцем в небо").
6. Делает контроль сроков и прогресса более удобным
Очевидно, что в WBS должен быть способ отслеживания сроков и прогресса (желательно с четкими метками и этапами (статусами), чтобы все было прозрачно, а не "плывем по ветру").
7. Обеспечивает более точное распределение ресурсов между задачами
Важно, чтобы каждая команда знала, кто и что должен делать, и чтобы ресурсы не тратились впустую, а использовались там, где они действительно нужны. В этом нам поможет первый и второй пункты.
Переходим к практике — создаем WBS
Для наглядности я буду постепенно заполнять документ в Google Sheets и делиться скриншотами. В конце статьи оставлю ссылку на готовый шаблон для скачивания (если возникнут трудности с доступом — пишите в ЛС, контакты будут внизу статьи).
Предлагаю рассмотреть конкретный пример. Для этого возьмем что-то простое, но практичное и понятное — например, эту страницу на Хабре и наследственные фичи, которые и нее вытекают.
Можете для наглядности открыть эту страницу в соседней вкладке, чтоб сверять WBS с компонентами и функционалом на самой странице.
Предположим, что у нас есть предварительный вайрфрейм этой страницы от команды UX/UI и черновое описание функционала. Прежде чем приступать к разработке, мы хотим оценить, сколько это будет стоить, сколько времени потребуется на разработку и тестирование, а также зафиналить скоуп и приоритеты.
Начинаем составлять WBS
Визуально я могу разделить весь интерфейс вайрфрейма на три части:
Таким образом, WBS мы сразу разбиваем на эти три части, а затем декомпозируем каждую из них до деталей.
Поскольку на данном этапе у нас есть только вайрфрейм, дизайн еще предстоит создать, и его тоже нужно будет включить в объем работ.
- Back-end;
- Front-end;
- Тестирование после разработки;
- UXUI финальный (учитывая, что сейчас у нас лишь Wireframe);
- Развертывание и настройку серверов для разработки (DevOps);
- Работу SEO специалиста, который спроектирует правильные заголовки и архитектуру страницы с перелинковками;
Давайте начнем с того, что уже обсудили и внесем это все в WBS.
Результат WBS на скрине ниже, и промежуточный результат можно скачать или посмотреть по ссылке.
Ссылка на док: Click
Анализируем WBS, которая у нас получилась
Наша WBS представляет собой декомпозицию проекта разработки страницы на Хабре. Структура разбита на несколько крупных эпиков: Header, Main Content, Side Bar, а также этапы процессов, таких как UX/UI, менеджмент, разработка, QA + DevOps и SEO.
Каждый компонент и функционал включает в себя оценку Front-end и Back-end задач для наилучшего и худшего сценария. Далее процентная часть, которая включает в себя оценку менеджмента, тестирования, дизайна, SEO и т.д.
- Header (Заголовок страницы):
- Menu Dropdown Component: Различные ссылки, такие как на Хабр, Q&A, Careers и Freelance.
- Navigation Component: Основное меню с различными разделами (Мой фид, Все потоки, Разработка и др.).
- Search функционал: Поиск по сайту, результаты поиска и категории результатов.
- Notification функционал: Настройки уведомлений, списки уведомлений (публикации, упоминания, подписки и приложения).
- Content Creation функционал: Возможность написать статью, пост или новость.
- Profile функционал и компоненты: Настройки профиля (например, профиль, специализация, аккаунт, конфиденциальность и приложения).
- Main Content (Основное содержимое):
- Элементы статьи: такие как имя автора, дата публикации, заголовок, сложность, длина статьи, теги и рейтинг.
- Возможности взаимодействия с контентом: добавление в закладки, возможность поделиться статьей и блок комментариев.
- Side Bar (Боковая панель):
Каждый процесс разбивается на отдельные задачи и оценивается отдельно.
Некоторые процессы, такие как дизайн, я оценил в абсолютных значениях (предположив, что получил оценку от команды UX/UI). Другие процессы оценивались с использованием коэффициентов, таких как 0,1 / 0,15 / 0,3 от общей оценки разработки. Логика в том, что чем больше объём разработки, тем больше требуется менеджмента, аналитики, тестирования и так далее. Конечно, коэффициенты могут отличаться в зависимости от процесса, и лучше всего определять их на основе опыта.
- UX/UI: Оценка разработки для десктопной и мобильной версий, а также создание логотипа.
- Management (Управление): Проектный менеджмент и бизнес-анализ.
- Development (Разработка): Код ревью, изучение спецификаций.
- QA + DevOps: Тестирование и доставка в продакшн.
- SEO: Оптимизация ключевых слов и создание карты сайта.
Total Development: Суммарное время на разработку — от 337 до 512 часов в зависимости от лучшего или худшего сценария.
Total Process: Общая оценка времени на процессы, такие как UX/UI, менеджмент и тестирование — от 488,75 до 728 часов.
Total Estimation: Суммарное время на реализацию всех задач — от 825,75 до 1240 часов.
Эта WBS помогает спланировать весь проект, разделить его на управляемые части и сделать прозрачную оценку трудозатрат на разработку, тестирование и управление.
В итоге мы разделили проект на части, которые можно оценить, и теперь видим, какие команды будут участвовать и сколько часов им потребуется для работы над проектом. Если какие-то компоненты теряют приоритет, мы можем их выделить и исключить из оценки. Или, наоборот, можем добавить дополнительные элементы и посмотреть, как это повлияет на итоговую оценку и распределение ресурсов между командами. Если добавить колонку со статусами, то можно даже в какой-то мере отслеживать прогресс.
В идеале нужно было бы декомпозировать многие элементы ещё глубже, такие как "Страница редактирования статьи", ведь она состоит из множества элементов и функционала. Поэтому на отдельной вкладке можно декомпозировать и оценить эту страницу, а затем использовать финальную оценку в общей WBS. То же самое касается поиска по сайту, настроек профиля и других компонентов. Думаю, общий принцип понятен.
Конечно, можно было максимально упороться и сделать страшного Оптимуса прайма, но я думаю этого шаблона будет достаточно, чтоб адаптировать его под ваши нужды.
Вывод
Использование WBS (Work Breakdown Structure) остаётся ценным инструментом для планирования и управления проектами, даже несмотря на то, что в реальной практике этот артефакт встречается нечасто. Основная проблема в том, что многие не до конца понимают, зачем нужен этот документ и как его правильно составить, в результате чего WBS часто превращается в бесполезный список. Но дело не в форме, а в сути — именно подход к декомпозиции задач, правильная оценка и структурирование работы делают проект управляемым и прозрачным.
WBS позволяет нам увидеть весь объём работы, чётко определить, что и кем должно быть сделано, а также оценить трудозатраты и ресурсы. Благодаря этому мы можем расставлять приоритеты, исключать менее важные задачи и, наоборот, добавлять новые элементы, чтобы увидеть, как это повлияет на общий баланс ресурсов и сроков. Такой подход упрощает планирование, улучшает коммуникацию в команде и делает проект более управляемым.
Неважно, насколько сложен проект, декомпозиция на управляемые части — ключ к его успешной реализации. Используйте WBS, чтобы лучше понимать объём работы, чётко оценивать задачи и контролировать процесс. Главное — адаптировать структуру под ваши нужды и не бояться углубляться в детали, когда это необходимо.
Ставь реакции, если было полезно.
Мои соц сети.
- Instagram: https://www.instagram.com/yevhenii.pishchikov
- Linkedin: https://www.linkedin.com/in/yevheniip/
- Telegram Channel: https://t.me/mr_ponder