Преамбула

Редко теперь встретишь, чтобы этот артефакт реально использовался на практике (хотя не то, чтоб я прям следил за этим трендом). Хотя WBS может быть очень полезен. Моя основная боль в том, что мало кто понимает, зачем этот документ вообще нужен и что в нем должно быть. А если и понимают, то в итоге выходит что-то малопригодное. В целом я люблю шаблоны и стандарты, когда дело касается бизнеса и работы. Но здесь важнее смысловое содержание и сам подход, чем просто форма.

Давай разберемся в том, зачем этот документ нужен, из чего должен состоять, как может выглядеть и какую пользу приносить.

Что за WBS и зачем он в целом нужен?

WBS — это такая штука, которая помогает разбить большой проект на более мелкие и понятные кусочки. Представь, что у тебя есть огромная задача, и ты не знаешь, с чего начать. WBS помогает разложить её на части, чтобы всё стало проще. Типа "разделяй и властвуй", только для задач. Она делает проект более управляемым: видишь всё, что нужно сделать, понимаешь, кто за что отвечает и сколько времени на это уйдет. Проще говоря, WBS — это способ превратить хаос в собранный пазл.

Такой подход помогает увидеть весь объем работы и не упустить ничего важного. Плюс, когда задача слишком большая, её сложно оценить и контролировать, а когда всё разложено по полочкам, то ты уже понимаешь, какие кусочки нужно делать, и кто из команды за это отвечает. Это особенно полезно в команде, где каждый знает, что ему делать и когда. (Ну а если не знают что делать — то у них есть менеджер. Ты всегда подскажешь, направишь, поделишься задачами)

Особенно полезно формировать WBS на самом старте проекта, ещё до того, как определились с роадмапой и приоритетами. Это помогает понять полный объем работы, разделить его на части и оценить, что реально потребуется для выполнения каждой задачи. Когда у тебя есть чёткое представление о том, из чего состоит проект, проще устанавливать приоритеты и формировать роадмапу — ведь ты уже знаешь, какие куски работы самые критичные и какие ресурсы понадобятся.

Давай теперь подумает над тем, из чего должен состоять WBS чтоб приносить максимальную пользу.

Из чего состоит WBS 

1. Какие боли и потребности закрывает этот документ

WBS помогает закрыть множество потребностей в управлении проектами. Вот основные боли и задачи, которые этот документ решает:

1. Упрощает коммуникацию в команде.

2. Помогает оценить необходимый объем работы;

3. Делает задачи понятными и структурированными;

4. Снижает риск упущения критически важных задач;

5. Упрощает планирование и расстановку приоритетов;

6. Делает контроль сроков и прогресса более удобным;

7. Обеспечивает более точное распределение ресурсов между задачами.

Тут такая штука — ты можешь и от себя добавить пару пунктов. Я тут выделил основные, которые беспокоят меня с высоты моего опыта. Но моим опытом все не ограничивается, так что если надо — дополняй.

Теперь, когда примерный список понятен, давай переходить к размышлению о том, из чего должен состоять этот документ: какие компоненты, элементы и так далее.

2. Переходим к деталям: что должно быть в WBS?

Предлагаю идти по порядку. У нас сформировался внушительный список болей и потребностей, которые этот документ должен покрывать. Давай разбирать их по очереди и пока чисто теоретически размышлять, какие компоненты, абстракции или секции должны присутствовать в документе.

2.1 Упрощает коммуникацию в команде

Значит, в документе должны быть указаны команды. Задачи должны быть каким-то образом распределены или как минимум относиться к разным департаментам/командам, чтобы это было прозрачно и наглядно.

2.2 Помогает оценить необходимый объем работы

Не знаю, как для вас, но для меня очевидно, что здесь должна присутствовать оценка (эстимейт). А оценивать гораздо удобнее что-то маленькое и не слишком объемное, то есть декомпозированное. Поэтому в документе все фичи и компоненты должны быть декомпозированы до минимально необходимого уровня, чтобы команды, упомянутые в пункте выше, могли их оценить.

2.3 Делает задачи понятными и структурированными

Ну, "понятными" — тут речь о формулировке. Значит, формулировка должна максимально точно описывать сам компонент/элемент/фичу, либо должен быть комментарий для уточнения.

Что касается структуры, то думаю, мы могли бы это интерпретировать как "наследственность" и "последовательность". То есть весь скоуп мы декомпозируем последовательно (по очереди) и каждый из них декомпозируем "вглубь", тем самым создавая интуитивно понятную структуру, по которой будет легко ориентироваться, а не просто вываливаем список из 100500 фич без какой-либо сортировки.

2.4 Снижает риск упущения критически важных задач

Думаю предыдущие 2 пункта справятся. 

2.5 Упрощает планирование и расстановку приоритетов

Очевидно, что в WBS должен быть способ приоритизации, желательно на основании конкретных данных, а не "пальцем в небо".

2.6 Делает контроль сроков и прогресса более удобным

Очевидно, что в WBS должен быть способ отслеживания сроков и прогресса, желательно с четкими метками и статусами, чтобы все было прозрачно, а не "плывем по ветру".

2.7 Обеспечивает более точное распределение ресурсов между задачами

Важно, чтобы каждая команда знала, кто и что должен делать, и чтобы ресурсы не тратились впустую, а использовались там, где они действительно нужны. В этом нам поможет первый и второй пункты.

Переходим к практике — создаем WBS

Для наглядности я буду постепенно заполнять документ в Google Sheets и делиться скриншотами. В конце статьи оставлю ссылку на готовый шаблон для скачивания

Если возникнут трудности с доступом — пишите в ЛС, контакты будут внизу статьи.

Предлагаю рассмотреть конкретный пример. Для этого возьмем что-то простое, но практичное и понятное — например, эту страницу на Хабре и наследственные фичи, которые и нее вытекают. 

Можете для наглядности открыть эту страницу в соседней вкладке, чтоб сверять WBS с компонентами и функционалом на самой странице.

Предположим, что у нас есть предварительный вайрфрейм этой страницы от команды UX/UI и черновое описание функционала. Прежде чем приступать к разработке, мы хотим оценить, сколько это будет стоить, сколько времени потребуется на разработку и тестирование, а также зафиналить скоуп и приоритеты.

Составляем WBS

Визуально я могу разделить весь интерфейс вайрфрейма на три части:

• Header, выделенный красным;

• Side Bar, выделенный синим;

• Main Part, выделенная зеленым.

Таким образом, WBS мы сразу разбиваем на эти три части, а затем декомпозируем каждую из них до деталей.

Поскольку на данном этапе у нас есть только вайрфрейм, дизайн еще предстоит создать, и его тоже нужно будет включить в объем работ.

Что надо учесть и добавить в документ:

• Back-end;

• Front-end;

• Тестирование после разработки;

• UXUI финальный (учитывая, что сейчас у нас лишь Wireframe);

• Развертывание и настройку серверов для разработки (DevOps);

• Работу SEO специалиста, который спроектирует правильные заголовки и архитектуру страницы с перелинковками;

Давайте начнем с того, что уже обсудили и внесем это все в WBS. 

Результат WBS на скрине ниже, и промежуточный результат можно скачать или посмотреть по ссылке.

Анализируем WBS, которая у нас получилась

Наша WBS представляет собой декомпозицию проекта разработки страницы на Хабре. Структура разбита на несколько крупных эпиков: Header, Main Content, Side Bar, а также этапы процессов, таких как UX/UI, менеджмент, разработка, QA + DevOps и SEO.

Каждый компонент и функционал включает в себя оценку Front-end и Back-end задач для наилучшего и худшего сценария. Далее процентная часть, которая включает в себя оценку менеджмента, тестирования, дизайна, SEO и т.д.

Основные элементы WBS:

1. Header (Заголовок страницы):

   • Menu Dropdown Component: Различные ссылки, такие как на Хабр, Q&A, Careers и Freelance. 

   • Navigation Component: Основное меню с различными разделами (Мой фид, Все потоки, Разработка и др.).

   • Search функционал: Поиск по сайту, результаты поиска и категории результатов.

   • Notification функционал: Настройки уведомлений, списки уведомлений (публикации, упоминания, подписки и приложения).

   • Content Creation функционал: Возможность написать статью, пост или новость.

   • Profile функционал и компоненты: Настройки профиля (например, профиль, специализация, аккаунт, конфиденциальность и приложения).

2. Main Content (Основное содержимое):

   1. Элементы статьи: такие как имя автора, дата публикации, заголовок, сложность, длина статьи, теги и рейтинг.

   2. Возможности взаимодействия с контентом: добавление в закладки, возможность поделиться статьей и блок комментариев.

3. Side Bar (Боковая панель):

   1. Feed (Лента): Список статей с указанием заголовка, просмотров и количества комментариев.

Процессная часть

1. UX/UI: Оценка разработки для десктопной и мобильной версий, а также создание логотипа.

2. Management (Управление): Проектный менеджмент и бизнес-анализ.

3. Development (Разработка): Код ревью, изучение спецификаций.

4. QA + DevOps: Тестирование и доставка в продакшн.

5. SEO: Оптимизация ключевых слов и создание карты сайта.

Каждый процесс разбивается на отдельные задачи и оценивается отдельно.

Некоторые процессы, такие как дизайн, я оценил в абсолютных значениях (предположив, что получил оценку от команды UX/UI). Другие процессы оценивались с использованием коэффициентов, таких как 0,1 / 0,15 / 0,3 от общей оценки разработки.

Логика в том, что чем больше объём разработки, тем больше требуется менеджмента, аналитики, тестирования и так далее. Конечно, коэффициенты могут отличаться в зависимости от процесса, и лучше всего определять их на основе опыта.

Общая оценка

1. Total Development: Суммарное время на разработку — от 337 до 512 часов в зависимости от лучшего или худшего сценария;

2. Total Process: Общая оценка времени на процессы, такие как UX/UI, менеджмент и тестирование — от 488,75 до 728 часов;

3. Total Estimation: Суммарное время на реализацию всех задач — от 825,75 до 1240 часов.

Вывод

Эта WBS помогаеWBS позволяет нам увидеть весь объём работы, чётко определить, что и кем должно быть сделано, а также оценить трудозатраты и ресурсы. Благодаря этому мы можем расставлять приоритеты, исключать менее важные задачи и, наоборот, добавлять новые элементы, чтобы увидеть, как это повлияет на общий баланс ресурсов и сроков. Такой подход упрощает планирование, улучшает коммуникацию в команде и делает проект более управляемым.

В итоге мы разделили проект на части, которые можно оценить, и теперь видим, какие команды будут участвовать и сколько часов им потребуется для работы над проектом. Если какие-то компоненты теряют приоритет, мы можем их выделить и исключить из оценки. Или, наоборот, можем добавить дополнительные элементы и посмотреть, как это повлияет на итоговую оценку и распределение ресурсов между командами. Если добавить колонку со статусами, то можно даже в какой-то мере отслеживать прогресс.

В идеале нужно было бы декомпозировать многие элементы ещё глубже, такие как "Страница редактирования статьи", ведь она состоит из множества элементов и функционала. Поэтому на отдельной вкладке можно декомпозировать и оценить эту страницу, а затем использовать финальную оценку в общей WBS. То же самое касается поиска по сайту, настроек профиля и других компонентов. Думаю, общий принцип понятен.

Конечно, можно было максимально упороться и сделать страшного Оптимуса прайма, но я думаю этого шаблона будет достаточно, чтоб адаптировать его под ваши нужды.

Неважно, насколько сложен проект, декомпозиция на управляемые части — ключ к его успешной реализации. Используйте WBS, чтобы лучше понимать объём работы, чётко оценивать задачи и контролировать процесс. Главное — адаптировать структуру под ваши нужды и не бояться углубляться в детали, когда это необходимо.

Мои соц сети.

• Telegram Channel: https://t.me/mr_ponder