WBS — это иерархия элементов, которая позволяет разбивать план проекта на отдельные рабочие задания. WBS имеет следующую информационную структуру:.

■ Общее описание всех значительных работ.

■ Четкое разбиение на задачи для распределения ответственности.

■ Схема для определения сроков, финансирования и контроля над расходами.

На разбиение всей работы на отдельные задачи может оказывать влияние множество факторов: подсистемы продукта, компоненты, функции, организационные единицы, стадии жизненного цикла, даже география. Большинству систем присуще разбиение первого уровня — на подсистемы. Подсистемы, в свою очередь, разбиваются на компоненты, одним из которых обычно является ПО. В следующем разделе основное внимание уделяется программным элементам WBS независимо от того, является ли создание ПО смыслом всего проекта или одним из компонентов более сложной системы.

10.1.1 Проблемы традиционной WBS.

Традиционные декомпозиции работ обычно имеют три фундаментальных порока.

1.

Они создаются преждевременно при разработке продукта.

2.

Они преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно.

3.

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

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

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

Рис. 10.1. Традиционная декомпозиция работ, привязанная к структуре продукта.

Традиционные декомпозиции преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно. В больших проектах существует тенденция к избытку планов, а в малых — к недостатку планов. WBS, приведенная на рис. 10.1, оказывается чрезмерно упрощенной для широкомасштабных проектов, где обычными считаются шесть и более уровней элементов WBS. Команда управления проектом тщательно планирует каждый элемент и определяет основы бюджета и сроки создания ПО для каждого задания на данном уровне детализации. С другой стороны, большинство небольших или «домашних» разработок довольствуется созданием WBS с одним уровнем без сопровождения его какими-либо подробностями. Команда управления планирует и ведет проект, используя приблизительное распределение заданий, нежесткую отчетность по срокам и затратам. Оба этих подхода не являются взвешенными. Вообще говоря, имеет смысл WBS, разработанная, по крайней мере, до двух или трех уровней. В случае крупномасштабных систем может понадобиться несколько дополнительных уровней на более поздних стадиях жизненного цикла. Основной проблемой при включении в план с самого начала слишком большого числа деталей заключается в том, что эти детали не меняются параллельно с уровнем качества плана. Например, не представляется возможным точно расписать на первом месяце — когда составляются основы плана, и до того, как будут разработаны архитектура и сценарии тестирования, — детали работ по тестированию, намеченных к выполнению 18 месяцами позже.

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

■ Каково соотношение между производительными видами деятельности (требования, проектирование, реализация, оценка, внедрение) и непроизводительными (управление проектом, создание рабочей среды)?.

■ Каков процент усилий, затраченных на доработки?.

■ Каков процент затрат на основное программное оборудование (расходы на среду)?.

■ Каково соотношение между продуктивным тестированием и (непродуктивной) интеграцией?.

■ Каковы затраты на версию N (являющиеся основанием для планирования затрат на версию N+1)?.

10.1.2 Эволюционирующие декомпозиции работ.

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

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

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

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

Стандартная WBS, соответствующая схеме процесса (стадии, рабочие процессы и рабочие продукты), показана на рис. 10.2. Эта рекомендуемая структура является примером того, каким образом элементы процесса могут быть сведены в план. Она предлагает схему для оценки затрат и сроков по каждому элементу, их распределения по организации, выполняющей проект, и отслеживания расходов.

Приведенная структура должна рассматриваться как отправная точка. Ее необходимо подогнать под особенности проекта по многим направлениям.

■ Масштаб. Более масштабные проекты будут иметь больше уровней и подструктур.

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

■ Объем разработок на заказ. В зависимости от характера проекта в рабочих процессах управления требованиями, проектирования и реализации внимание может уделяться разным аспектам. Проект реинжиниринга бизнес-процессов, основанный по большей части на уже существующих компонентах, должен иметь большую глубину детализации требований и не слишком углубляться в проектирование и реализацию. Разработка единственного в своем роде технического приложения, выполняемая полностью на заказ, может потребовать действительно глубокой проработки в части проектирования и реализации, для того чтобы справиться с рисками первого поколения новых компонентов.

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

■ Предшествующий опыт. Очень немногие проекты начинаются с чистого листа. Большинство из них разрабатывается либо как новые поколения унаследованных систем (с устоявшейся WBS), либо в контексте существующих организационных стандартов (с предопределенным построением WBS). Важно подстроиться под эти ограничения для гарантии, что новый проект сможет воспользоваться имеющимся опытом и достигнутым уровнем производительности.

WBS разбивает содержимое проекта на части и ставит их в соответствие жизненному циклу, бюджету и персоналу. Рассмотрение WBS позволяет уточнить важные атрибуты, приоритеты и структуру плана проекта. Выполняя оценку проектов и аудит управления проектами по созданию ПО на протяжении последних нескольких лет, автор обнаружил, что WBS является наиболее ценным источником объективной информации о плане проекта. В то время как план разработки ПО и бизнес-план создают контекст для рассмотрения, WBS и соответствующие бюджеты, распределяемые по элементам, являются наиболее осмысленными показателями подхода, приоритетов и приемов управления.

Рис. 10.2. Стандартная декомпозиция работ

Рис. 10.2. Стандартная декомпозиция работ (продолжение).

Другой важной особенностью хорошей WBS является то, что точность планирования, присущая каждому элементу, согласуется с текущей стадией жизненного цикла и состоянием проекта. Эта идея представлена на рис. 10.3. Одной из главных причин, по которой WBS организована именно так, является необходимость в учете изменения элементов плана от общего планирования (приблизительные бюджеты, которые приводятся в качестве оценки для последующего уточнения, а не расписываются подробно по частям) до сетки окончательно спланированных видов деятельности (с точно определенным бюджетом и постоянной оценкой реального состояния по сравнению с планируемыми затратами).

Рис. 10.3. Эволюция точности планирования в WBS на протяжении жизненного цикла