Обо мне
Коротко обо мне, чтоб не возникало вопросов мол: "А чего он тут вообще мне рассказывает?"
Женя
CPO & Head of Operations
~ 10 лет опыта в IT на разных позициях:
ex-Software Engineer;
ex-Project Manager;
ex-Product Manager.
Работал в Fin-tech, Gambling, Crypto и E-commerce. Много нанимал и увольнял, да и сам проходил очень много собеседований. Много обучал, менторил, коучил и сам учился. Работал в IBM, получал оффер в Microsoft.
Большая часть моего опыта — это работа с зарубежными клиентами, инвесторами и продуктами. А ещё у меня много опыта с командами из СНГ, так что хорошо работаю с разным культурным кодом.
Пишу не только на Хабре. Пишу разный контент от "профильно-технического" до "а поговорить..", где раскрываю узкие технические темы либо просто поболтать о наболевшем.
Связаться со мной и почитать другой мой контент можно так-же в телеграмм.
Преамбула
Редко теперь встретишь, чтобы этот артефакт реально использовался на практике (хотя не то, чтоб я прям следил за этим трендом). Хотя WBS может быть очень полезен. Моя основная боль в том, что мало кто понимает, зачем этот документ вообще нужен и что в нем должно быть. А если и понимают, то в итоге выходит что-то малопригодное. В целом я люблю шаблоны и стандарты, когда дело касается бизнеса и работы. Но здесь важнее смысловое содержание и сам подход, чем просто форма.
Давай разберемся в том, зачем этот документ нужен, из чего должен состоять, как может выглядеть и какую пользу приносить.
Что за WBS и зачем он в целом нужен?
WBS — это такая штука, которая помогает разбить большой проект на более мелкие и понятные кусочки. Представь, что у тебя есть огромная задача, и ты не знаешь, с чего начать. WBS помогает разложить её на части, чтобы всё стало проще. Типа "разделяй и властвуй", только для задач. Она делает проект более управляемым: видишь всё, что нужно сделать, понимаешь, кто за что отвечает и сколько времени на это уйдет. Проще говоря, WBS — это способ превратить хаос в собранный пазл.
Такой подход помогает увидеть весь объем работы и не упустить ничего важного. Плюс, когда задача слишком большая, её сложно оценить и контролировать, а когда всё разложено по полочкам, то ты уже понимаешь, какие кусочки нужно делать, и кто из команды за это отвечает. Это особенно полезно в команде, где каждый знает, что ему делать и когда. (Ну а если не знают что делать — то у них есть менеджер. Ты всегда подскажешь, направишь, поделишься задачами)
Особенно полезно формировать WBS на самом старте проекта, ещё до того, как определились с роадмапой и приоритетами. Это помогает понять полный объем работы, разделить его на части и оценить, что реально потребуется для выполнения каждой задачи. Когда у тебя есть чёткое представление о том, из чего состоит проект, проще устанавливать приоритеты и формировать роадмапу — ведь ты уже знаешь, какие куски работы самые критичные и какие ресурсы понадобятся.
Давай теперь подумает над тем, из чего должен состоять WBS чтоб приносить максимальную пользу.
Из чего состоит WBS
1. Какие боли и потребности закрывает этот документ
WBS помогает закрыть множество потребностей в управлении проектами. Вот основные боли и задачи, которые этот документ решает:
Упрощает коммуникацию в команде.
Помогает оценить необходимый объем работы;
Делает задачи понятными и структурированными;
Снижает риск упущения критически важных задач;
Упрощает планирование и расстановку приоритетов;
Делает контроль сроков и прогресса более удобным;
Обеспечивает более точное распределение ресурсов между задачами.
Тут такая штука — ты можешь и от себя добавить пару пунктов. Я тут выделил основные, которые беспокоят меня с высоты моего опыта. Но моим опытом все не ограничивается, так что если надо — дополняй.
Теперь, когда примерный список понятен, давай переходить к размышлению о том, из чего должен состоять этот документ: какие компоненты, элементы и так далее.
2. Переходим к деталям: какие функции выполняет WBS?
Предлагаю идти по порядку. У нас сформировался внушительный список болей и потребностей, которые этот документ должен покрывать. Давай разбирать их по очереди и пока чисто теоретически размышлять, какие компоненты, абстракции или секции должны присутствовать в документе.
Упрощает коммуникацию в команде
Значит, в документе должны быть указаны команды. Задачи должны быть каким-то образом распределены или как минимум относиться к разным департаментам/командам, чтобы это было прозрачно и наглядно.
Помогает оценить необходимый объем работы
Не знаю, как для вас, но для меня очевидно, что здесь должна присутствовать оценка (эстимейт). А оценивать гораздо удобнее что-то маленькое и не слишком объемное, то есть декомпозированное. Поэтому в документе все фичи и компоненты должны быть декомпозированы до минимально необходимого уровня, чтобы команды, упомянутые в пункте выше, могли их оценить.
Делает задачи понятными и структурированными
Ну, "понятными" — тут речь о формулировке. Значит, формулировка должна максимально точно описывать сам компонент/элемент/фичу, либо должен быть комментарий для уточнения.
Что касается структуры, то думаю, мы могли бы это интерпретировать как "наследственность" и "последовательность". То есть весь скоуп мы декомпозируем последовательно (по очереди) и каждый из них декомпозируем "вглубь", тем самым создавая интуитивно понятную структуру, по которой будет легко ориентироваться, а не просто вываливаем список из 100500 фич без какой-либо сортировки.
Упрощает планирование и расстановку приоритетов
Очевидно, что в WBS должен быть способ приоритизации, желательно на основании конкретных данных, а не "пальцем в небо".
Делает контроль сроков и прогресса более удобным
Очевидно, что в WBS должен быть способ отслеживания сроков и прогресса, желательно с четкими метками и статусами, чтобы все было прозрачно, а не "плывем по ветру".Обеспечивает более точное распределение ресурсов между задачами
Важно, чтобы каждая команда знала, кто и что должен делать, и чтобы ресурсы не тратились впустую, а использовались там, где они действительно нужны. В этом нам поможет первый и второй пункты.
Переходим к практике — создаем 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:
Header (Заголовок страницы):
Menu Dropdown Component: Различные ссылки, такие как на Хабр, Q&A, Careers и Freelance.
Navigation Component: Основное меню с различными разделами (Мой фид, Все потоки, Разработка и др.).
Search функционал: Поиск по сайту, результаты поиска и категории результатов.
Notification функционал: Настройки уведомлений, списки уведомлений (публикации, упоминания, подписки и приложения).
Content Creation функционал: Возможность написать статью, пост или новость.
Profile функционал и компоненты: Настройки профиля (например, профиль, специализация, аккаунт, конфиденциальность и приложения).
Main Content (Основное содержимое):
Элементы статьи: такие как имя автора, дата публикации, заголовок, сложность, длина статьи, теги и рейтинг.
Возможности взаимодействия с контентом: добавление в закладки, возможность поделиться статьей и блок комментариев.
Side Bar (Боковая панель):
Feed (Лента): Список статей с указанием заголовка, просмотров и количества комментариев.
Процессная часть
UX/UI: Оценка разработки для десктопной и мобильной версий, а также создание логотипа.
Management (Управление): Проектный менеджмент и бизнес-анализ.
Development (Разработка): Код ревью, изучение спецификаций.
QA + DevOps: Тестирование и доставка в продакшн.
SEO: Оптимизация ключевых слов и создание карты сайта.
Каждый процесс разбивается на отдельные задачи и оценивается отдельно.
Некоторые процессы, такие как дизайн, я оценил в абсолютных значениях (предположив, что получил оценку от команды UX/UI). Другие процессы оценивались с использованием коэффициентов, таких как 0,1 / 0,15 / 0,3 от общей оценки разработки.
Логика в том, что чем больше объём разработки, тем больше требуется менеджмента, аналитики, тестирования и так далее. Конечно, коэффициенты могут отличаться в зависимости от процесса, и лучше всего определять их на основе опыта.
Общая оценка
Total Development: Суммарное время на разработку — от 337 до 512 часов в зависимости от лучшего или худшего сценария;
Total Process: Общая оценка времени на процессы, такие как UX/UI, менеджмент и тестирование — от 488,75 до 728 часов;
Total Estimation: Суммарное время на реализацию всех задач — от 825,75 до 1240 часов.
Вывод
Эта WBS помогаеWBS позволяет нам увидеть весь объём работы, чётко определить, что и кем должно быть сделано, а также оценить трудозатраты и ресурсы. Благодаря этому мы можем расставлять приоритеты, исключать менее важные задачи и, наоборот, добавлять новые элементы, чтобы увидеть, как это повлияет на общий баланс ресурсов и сроков. Такой подход упрощает планирование, улучшает коммуникацию в команде и делает проект более управляемым.
В итоге мы разделили проект на части, которые можно оценить, и теперь видим, какие команды будут участвовать и сколько часов им потребуется для работы над проектом. Если какие-то компоненты теряют приоритет, мы можем их выделить и исключить из оценки. Или, наоборот, можем добавить дополнительные элементы и посмотреть, как это повлияет на итоговую оценку и распределение ресурсов между командами. Если добавить колонку со статусами, то можно даже в какой-то мере отслеживать прогресс.
В идеале нужно было бы декомпозировать многие элементы ещё глубже, такие как "Страница редактирования статьи", ведь она состоит из множества элементов и функционала. Поэтому на отдельной вкладке можно декомпозировать и оценить эту страницу, а затем использовать финальную оценку в общей WBS. То же самое касается поиска по сайту, настроек профиля и других компонентов. Думаю, общий принцип понятен.
Конечно, можно было максимально упороться и сделать страшного Оптимуса прайма, но я думаю этого шаблона будет достаточно, чтоб адаптировать его под ваши нужды.
Неважно, насколько сложен проект, декомпозиция на управляемые части — ключ к его успешной реализации. Используйте WBS, чтобы лучше понимать объём работы, чётко оценивать задачи и контролировать процесс. Главное — адаптировать структуру под ваши нужды и не бояться углубляться в детали, когда это необходимо.
Мои соц сети.
Telegram Channel: https://t.me/mr_ponder
