Как навести порядок в своем бизнесе. Как построить надежную систему из надежных элементов. Практикум - Михаил Рыбаков

Итак, проект официально запущен. Теперь настало время детально его спланировать: по составу работ, срокам, ресурсам и т. д.

Вот общий алгоритм планирования проекта (рис. 27):

Рисунок 27. Общий алгоритм планирования проекта

Как-то по завершении моего трехдневного практикума по управлению проектами один из участников так описал полученную пользу: «Я понял – проектами можно управлять!» На тот момент он работал руководителем проекта в инжиниринговой компании уже несколько лет. И подобные отзывы люди давали не раз…

Для начала нужно понять, какие работы в проекте выполнить необходимо, а какие – нет. Например, строительство гостиницы входит в ответственность руководителя проекта. А запуск и вывод на заданный уровень прибыли? Это понимание ложится в основу всего дальнейшего планирования. Ошибки на этой стадии приводят к неверным оценкам сроков, ресурсов, бюджета и т. д.

Так, на одном заводе главный инженер с гордостью показывал консультантам новые образцы мотоциклов, разработанные его командой за последние годы. Однако эти мотоциклы не встречались на дорогах страны, а завод после развала СССР влачил довольно жалкое существование. Как оказалось, беда состояла в том, что в проект по созданию нового мотоцикла забывали включать мероприятия по его продвижению на рынок: сказывалось отсутствие маркетингового мышления. А когда разработали и воплотили в жизнь, дела завода пошли на поправку.

В управлении проектами для описания того, что входит в проект, широко используется термин scope. Он не имеет точного перевода на русский: обычно так и говорят: «скоуп». Примерными аналогами являются термины: «объем работ», «масштаб проекта», «граница проекта».

Очень важно разумно определить scope.

• Не взять лишнего, т. к. это резко снижает вероятность успеха проекта. Грамотный руководитель «подпишется» только под то, в успехе чего уверен. Хорошо, когда цель сложная, но реалистичная.

• Не уменьшить проект сверх необходимости, т. к. в этом случае вы не используете многие возможности. Например, правильно ли ограничиваться рынком своего региона, когда ваш продукт не имеет прямого аналога в России и можно продавать его по всей стране?

При планировании предметной области применяется инструмент, который имеет несколько равноценных названий:

• Work breakdown structure (WBS). В русскоязычной среде часто произносят «вэ-бэ-эс»[169].

• Структурная декомпозиция работ (СДР).

• Иерархическая структура работ (ИСР).

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

• Продуктовая, когда проект разбивается по элементам продукта проекта (рис. 28):

Рисунок 28. Фрагмент продуктовой WBS

• Функциональная: декомпозиция по функциональным областям управления (рис. 29):

Рисунок 29. Фрагмент функциональной WBS

• По этапам жизненного цикла проекта (рис. 30):

Рисунок 30. Фрагмент WBS по этапам жизненного цикла

Могут быть и другие, в том числе смешанные типы.

Наша цель – получить перечень элементарных работ проекта: «листья дерева» WBS. Они ложатся в основу всего дальнейшего планирования: построения сетевого графика и диаграммы Гантта, ресурсного и финансового планирования.

Есть несколько принципов построения структурной декомпозиции работ.

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

• WBS строится по принципу правильного дерева, т. е. у одной ветки/листа может быть только один «родитель».

• На одном уровне декомпозируем строго по одному выбранному принципу. Например, нельзя смешивать элементы продукта проекта с функциональными задачами (фундамент и маркетинг)[170].

• Декомпозируем настолько, насколько необходимо нам для управления. Как правило, элементарная работа – та, которую делает один человек, и/или та, которую мы хотим контролировать как отдельную единицу. Различные ветви WBS можно декомпозировать до разной глубины.

• Иногда полезно бывает построить WBS двух видов (например, продуктовую и функциональную), чтобы получить максимально полный перечень элементарных работ и ничего не упустить, а потом выбрать один для дальнейшей работы, включив в него работы из другого.