ИТУП / лекционный материал / Управление проектами и разработка ПО

проведении испытаний и т.д.) должны быть включены и определены соответствующие пакеты работ.

+Совместимость. Все пакеты работ должны быть совместимы с организационной структурой и структурой затрат.

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

−Нахождение баланса между задачами описания содержания проекта и требованиями к сбору фактической информации и отчетности. (Напомним, что основная функция WBS — это определение объема работ). WBS — это инструмент, позволяющий руководителю проекта декомпозировать проект до уровня, необходимого и достаточного для определения требований проекта. Чрезмерная детализация WBS требует излишнего уровня контроля и отчетности. Недостаточная детализация WBS ведет к потере управляемости проектом.

−Недостаточное внимание к разработке WBS и переход непосредственно к формированию плана-графика (диаграммы Ганта, расчету критического пути или сетевого графика). Это может привести к потере важных для проекта работ, и, следовательно, к задержкам проекта на поздних стадиях его реализации после выявления упущений.

−Разработка элементов WBS, учитывающих только стадии проекта, либо организационную структуру без учета промежуточных результатов проекта (объектов, продуктов, артефактов), может привести к перерасходу по проекту, поскольку при таком подходе трудно оценить плановые показатели и проконтролировать выполнение проекта.

−Упущение определения пакетов работ, описывающих начальные и завершающие элементы, такие как планирование, опытную эксплуатацию и сопровождение. В этом случае объем работ может быть оценен неверно.

−Назначение пакетов работ с несколькими ответственными за создание тех или иных результатов (артефактов) — «у семи нянек дитя без глаза».

−Упущение вспомогательных результатов управления проектами, таких как управление процессами, услуги, информационное обеспечение и коммуникации, регламенты, обучение и инструментальное программное обеспечение.

111

5.6.4. Определение приемлемого уровня детализации

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

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

Чем больше количество положительных ответов, тем более обоснованным является дальнейшая детализация WBS.

Опросный лист: нужно ли дальше детализировать WBS?

112

Как было определено ранее, уровень детализации WBS зависит от размера проекта и баланса между сложностью, риском и требованиями руководителя проекта к контролю проекта. Уровень детализации может также изменяться в процессе жизненного цикла проекта.

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

5.6.5. Взаимосвязь между риском проекта и WBS

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

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

113

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

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

5.6.6. Взаимосвязь планирования и контроля ресурсов и WBS

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

Чтобы соответствующим образом подготовиться к планированию ресурсов в соответствии с WBS, необходимо рассмотреть следующие вопросы при определении уровня детализации WBS.

√Все ли работы запланированы с достаточной степенью детализации, необходимой для формирования и соблюдения обязательств?

√Существует ли возможность установления и контроля индивидуальных назначений ресурсов на работы со структурой отчетности, определенной данной WBS?

√Можно ли определить назначения на работы при постепенном расширении WBS? Будут ли они обоснованы как при разворачивании WBS сверху-вниз, так и при сборе данных снизу-вверх?

√Будут ли назначения ресурсов на работы согласованы с формальной системой расчета расписания?

√Как будут распределяться бюджеты?

√Можно ли будет связать бюджет с предполагаемым увеличением работы?

114

√Можно ли измерить увеличение объема работы на приемлемом уровне (т.е. соответствует ли уровень детализации WBS эффективному планированию и контролю)?

√Можно ли логически собрать данные по индивидуальным рабочим заданиям (т.е. можно ли работы, определенные в WBS, сгруппировать логически)?

√Как будет определяться состояние работ в процессе выполнения проекта?

5.6.7.Разработка WBS

WBS разрабатывается путем итерационного рассмотрения целей и

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

Основной процесс разработки WBS состоит из следующих шагов:

1.Определение конечных результатов проекта – что должно быть произведено (поставлено) для обеспечения успешного завершения проекта.

2.Определение основных пакетов работ, необходимых для получения конечных результатов (продуктов) проекта.

Часто такие основные пакеты работ соответствуют целям проекта, но вместе с тем, сами по себе они не являются целями проекта (например, технические требования к разработке программного обеспечения).

3.Объединение дополнительных уровней детализации в соответствии с внутренней системой управления и единой системой контроля. Такие элементы обычно связаны с четким и раздельным определением отдельных результатов (продуктов) проекта.

4.Пересмотр (анализ) и усовершенствование WBS до тех пор,

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

115

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

5.7. Разработка проектно–сметной документации

Проектно-сметная документация – нормативно установленный комплекс документов, обосновывающих целесообразность и реализуемость проекта, раскрывающих его сущность, позволяющих осуществить проект.

5.7.1. Материально-техническая подготовка проекта

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

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

•Компьютеры. Персональный компьютер является основным инструментом разработчика. Сейчас общепринятой является практика один разработчик — один компьютер. В большинстве случаев все разработчики в проекте используют компьютеры близкой конфигурации. При этом следует принять во внимание следующие вопросы.

o Является ли переменным число разработчиков на протяжении всего проекта? Если да, то предусмотрены ли способы оперативного изменения числа компьютеров, задействованных в проекте?

o Зависит ли разрабатываемый продукт от аппаратной платформы? Если да, то будет ли применяться кроссплатформенная разработка или же во время разработки будут использоваться специальные компьютеры?

116

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

o Являются ли заявленные минимальные требования продукта к конфигурации аппаратных средств более низкими, чем типовая конфигурация компьютера тестера? Если да, то обеспечены ли тестеры компьютерами минимальной и типовой заявленной конфигурации?

o Являются ли заявленные максимальные требования продукта к производительности/масштабируемости более высокими, чем позволяет реализовать типовая конфигурация компьютера тестера? Если да, то обеспечены ли тестеры компьютерами для нагрузочного тестирования?

•Инфраструктура. Разработка программного обеспечения — это офисная, конторская работа, для которой достаточно стола с компьютером и относительной тишины. При этом следует принять во внимание следующие вопросы.

o Является разработка распределенной? Если да, то как обеспечивается оперативная и защищенная связь между разработчиками (Интернет, телефонные конференции и т.д.)?

o Есть ли необходимость в использовании нестандартного режима рабочего времени (например, общение с заказчиком за океаном)? Если да, то обеспечены ли необходимые рабочие условия для разработчиков (транспорт, горячее питание)?

o Предусматривает ли процесс проведение коллективных действий (производственных совещаний, мозговых штурмов и т.д.)? Если да, то имеется ли подходящее помещение для этого?

o Используют ли разработчики печатные материалы (книги, документы, инструкции)? Если, то где хранятся эти материалы?

5.7.2.Типовая смета расходов

Составление финансовых документов обычно не входит в сферу

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

117

финансовых вопросов. Менеджер проекта должен понимать смысл основных статей сметы расходов проекта и уметь оценивать влияние, которые эти расходы оказывают на ход проекта.

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

•Зарплата. Как показывает практика, это основная статья расходов. Разработанная программа — это почти на 100% овеществленный труд. Менеджеру проекта полезно помнить, что начисления на зарплату в настоящее время в России составляют около 40%.

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

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

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

•Накладные расходы. Накладные расходы – это плата за то, что проект выполняется в организации, а не «под открытым небом». Как правило, величина этих расходов регламентирована и от менеджера проекта не зависит.

•Прочие расходы. Если корпоративные стандарты позволяют включить в смету такую статью, то это стоит сделать. Забытые при планировании мелочи и неприятные неожиданности нельзя исключить. Если же «прочих расходов» не будет, то ничего страшного — экономия средств не вызовет нареканий.

Подробнее особенности управления финансами проекта будут обсуждаться в дальнейшем.

5.8. Организационная структура исполнителей

118

Организационные структуры проекта (Project organization) –

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

Существуют и используются различные организационные структуры проекта. Ниже рассмотрены наиболее популярные. Прежде чем описывать конкретные структуры, следует определить основные термины, используемые в них. Таких терминов три:

•функция;

•роль;

•должность.

Функция — это вид деятельности, выполняемой в ходе проекта. Выполнение каждой функции требует наличия определенной специфической квалификации и способностей.

Приведем примеры функций:

•Администрирование. Ведение договоров; разговоры с заказчиком; составление внешних формальных документов, доклады начальству.

•Проектирование. Составление бумажных и/или электронных концепций, моделей, спецификаций и планов.

•Кодирование. Ручная и/или полуавтоматическая генерация кода на языке программирования. Автономная (поблочная) отладка кода. Рисование и тестирование интерфейсных элементов (форм).

•Тестирование. Пробное использование приложения с целью сломать его, а не решить задачу.

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

Роль – это временное назначение сотруднику набора функций в рамках конкретного проекта.

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

119

характер деятельности, а набор конкретных результатов (вех), ответственность за достижение которых налагает роль.

В проектах разных типов используются разные наборы ролей из следующего множества:

•Аналитик. Функции: планирование, администрирование.

•Администратор. Функции: администрирование, планирование.

•Программист. Функции: проектирование, кодирование, тестирование, сопровождение.

•Тестер. Функции: тестирование.

•Эксплуатационник. Функции: сопровождение, тестирование.

Должность – это сертифицированная способность играть определенные роли и выполнять определенные функции.

В отличие от роли и функции должность не привязана в конкретному проекту и носит (почти) постоянный характер по времени. В большинстве организаций предусматривается по меньшей мере три уровня иерархии должностей:

•Начальник (отдела, подразделения).

•Руководитель (группы, проекта, направления).

•Исполнитель (инженер, технический специалист).

5.8.1.Иерархическая модель

Иерархическая модель (или модель дерева субординации (см. рис.

1)) являются самой распространенной и известной организационной моделью.

Офицер

Рис. 1. Иерархическая модель команды (дерево)

Эта модель обладает целым рядом достоинств:

120