Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорумКонтакты

Факторы, влияющие на управление проектами на заказ и с реализацией

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

Определения

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

Влияющие факторы

После наблюдения за проектами по разработке ПО (как сделанными на заказ, так и теми, которые состояли из покупки частей) были замечены следующие нюансы и различия, которые влияют на управление каждым из типов проектов.

Проекты по реализации продукта Специализированные проекты                      
1 Проект принимает или находится под влиянием методологии реализации, диктуемой провайдером. Методология оговаривается с провайдером и клиент вводится в курс дела.
2

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

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

Руководитель проекта должен спланировать управление элементами репозитория конфигурации (Configuration Repository), которые являются результатами специализации продукта для конкретного клиента.

Руководитель проекта должен фокусироваться только на проекте.
3 Изменения могут произойти вследствие необходимости исправить ошибки или улучшить продукт. Изменения зачастую происходят из-за возникновения или смены требований со стороны пользователей.
4

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

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

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

Полный набор требований составлен для конкретного клиента и никакой другой классификации не требуется.
5 Документация по продукту дает клиенту представление о том, как требования будут исполнены в разрабатываемом продукте.

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

6 Прогноз реализации зачастую выполняется путем оценки каждого действия, и результат оценивается по количеству затраченных усилий/дней. Такой метод оценки, как балльная функциональная оценка, используется редко. Руководитель проекта может создать прогноз, основываясь на своем опыте в применении определенного метода прогноза (балльная функциональная оценка, сценарии использования и т.д.)
7 Клиенты предпочитают решение, воплощенное в пакете программ для того, чтобы сократить период от начала разработки изделия до выхода его на рынок. Это объясняет, почему ожидаемые сроки разработки часто бывают агрессивными.

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

8 Прибыль проекта классифицируется как лицензионный платеж, плата за специализацию, платеж за профессионалов и годовое обслуживание контракта (AMC). Контракты обычно являются смесью фиксированного контракта и временных и материальных услуг. Прибыль проекта должна быть классифицирована в различные категории. Контракты обычно фиксированные, но бывают случаи и отдельных временных и материальных услуг.
9

Плата за лицензию обычно известна заранее. Платы за специализацию или профессионалов привязаны к контрольным точкам.

Затраты привязаны к контрольным точкам.
10 Стандарты организации провайдера используются для предоставления результатов. К примеру, шаблоны документов будут такими, какие привыкла использовать организация провайдера. Клиент может запросить организацию провайдера принять его стандарты для всех предоставляемых результатов.
11 Ожидания клиентов всегда различны и отличаются друг от друга в отношении качества. Следовательно, команды разработчиков и исполнителей должны работать вместе для того, чтобы предоставить продукт, который будет удовлетворять всем стандартам качества, установленным клиентом. Решение создается для того, чтобы удовлетворить все требования конкретного клиента, следовательно, его ожидания относительно качества должны быть удовлетворены.
12

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

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

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

Структура команды согласуется с проектом, а руководитель проекта обладает высоким уровнем власти и контроля.
14 Влиятельный руководитель проекта будет во благо, поскольку иерархическая или экспертная власть будет во вред - слишком большая концентрация и использование экспертов в команде. Власть экспертов и иерархическая власть будет во благо.
15

Продуктивность индивидуумов и команды во многом зависит от знания товара.

Продуктивность индивидуумов и команды зависит от технического опыта и опыта в предметной области.
16

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

Выпуски полностью контролируются проектной командой.
17

Права на интеллектуальную собственность принадлежат провайдеру. Права на специализированную часть продукта могут принадлежать клиенту или провайдеру - в зависимости от контракта.

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

Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.