WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 14 | 15 || 17 | 18 |   ...   | 33 |

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

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

Опросный лист: нужно ли дальше детализировать WBS № Вопрос Ответ Есть ли необходимость в повышении точности 1. Да Нет оценки стоимости и длительности по пакету работ Для пакета работ определен более чем один ответственный Для выполнения работ в рамках 2. пакета могут использоваться различные ресурсы, Да Нет однако должен быть назначен только один ответственный за каждый пакет работ.

Объем работ, выполняемый в рамках данного пакета, описывает больше, чем один тип процесса 3. Да Нет или больше, чем один результат (артефакт) проекта Есть ли необходимость в раздельном определении 4. стоимости процессов или результатов, описанных в Да Нет данном пакете работ Есть ли зависимость между частью работ внутри 5. Да Нет пакета работ и другими внешними пакетами Наблюдаются ли существенные перерывы в 6. Да Нет выполнении работ в рамках пакета Меняются ли требования к ресурсам в течение 7. Да Нет времени в рамках выполнения пакета работ Различаются ли исходные условия для работ внутри 8. Да Нет пакета работ Существуют ли четкие, объективные критерии 9. Да Нет измерения выполнения для пакета работ Существуют ли специфические риски, связанные с 10. частью пакта работ и требующие дальнейшей Да Нет детализации пакета для выделения этих рисков Может ли для части пакета работ отдельно 11. Да Нет пересчитываться расписание Как было определено ранее, уровень детализации WBS зависит от размера проекта и баланса между сложностью, риском и требованиями руководителя проекта к контролю проекта. Уровень детализации может также изменяться в процессе жизненного цикла проекта.

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

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

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

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

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

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

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

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

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

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

Все ли работы запланированы с достаточной степенью детализации, необходимой для формирования и соблюдения обязательств Существует ли возможность установления и контроля индивидуальных назначений ресурсов на работы со структурой отчетности, определенной данной WBS Можно ли определить назначения на работы при постепенном расширении WBS Будут ли они обоснованы как при разворачивании WBS сверху-вниз, так и при сборе данных снизу-вверх Будут ли назначения ресурсов на работы согласованы с формальной системой расчета расписания Как будут распределяться бюджеты Можно ли будет связать бюджет с предполагаемым увеличением работы Можно ли измерить увеличение объема работы на приемлемом уровне (т.е. соответствует ли уровень детализации WBS эффективному планированию и контролю) Можно ли логически собрать данные по индивидуальным рабочим заданиям (т.е. можно ли работы, определенные в WBS, сгруппировать логически) Как будет определяться состояние работ в процессе выполнения проекта 5.6.7. Разработка WBS WBS разрабатывается путем итерационного рассмотрения целей и результатов проекта, объема работ, реализации технических требований и других атрибутов. Верхние уровни WBS могут быть разработаны на ранней, концептуальной стадии проекта. Дальнейшая детализация WBS возможна, как только будут определены цели проекта и подготовлены спецификации.

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

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

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

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

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

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

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

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

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

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

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

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

При этом следует принять во внимание следующие вопросы.

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

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

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

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

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

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

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

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

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

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

5.8. Организационная структура исполнителей Организационные структуры проекта (Project organization) – наиболее соответствующая проекту временная организационная структура, включающая всех его участников и создаваемая для успешного достижения целей проекта.

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

• функция;

• роль;

• должность.

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

Выполнение каждой функции требует наличия определенной специфической квалификации и способностей.

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

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

Pages:     | 1 |   ...   | 14 | 15 || 17 | 18 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.