Параметры ролей проектной группы
| Роль | Ответственность | Приоритеты |
| Менеджер проекта | Определение проблемы Продвижение продукта | Удовлетворенность заказчика |
| Менеджер программы | Управление спецификациями Координация работ Отслеживание состояния проекта | Разработка качественного продукта в срок и в рамках выделенного бюджета Поиск и решение проблем |
| Разработчик | Проектирование функциональности Создание продукта Тестирование продукта | Надежный и полный продукт |
| Тестер | Определение стратегии тестирования Проведение тестирования Отслеживание результатов тестирования | Согласованный и надежный проект |
| Инструктор | Разработка документации Ведение глоссария (определение терминов) Тестирование Обучение пользователей | Продукт, который можно использовать и сопровождать |
| Логистик | Прогнозирование ситуации Подготовка внедрения Сопровождение продукта на этапе внедрения Обеспечение адекватной инфраструктуры | Обеспечение гладкого внедрения и развития продукта |
Модель процесса проектирования MSF в отличие от традиционных моделей ЖЦ ориентируется на вехи. Она направлена на решение проблем традиционной модели, но используя понятие «вех» (точек синхронизации проектной группы и заказчика) и укорачивая цикл проектирования с помощью механизма выпуска версий, совместно с моделью проектной группы определяет четкую ответственность ролей. В основе этой модели лежит несколько основных идей:
|
|
|
- конструирование решений из обозримых и управляемых частей;
- завершение вехами фазы проекта;
- выпуск версий продукта;
- выполнение планирования с учетом рисков.
Модель процесса проектирования MSF (рис. 2.11) состоит из четырех фаз и четырех вех, которыми завершаются эти фазы.
Рис. 2.11. Модель процесса проектирования с вехами
Ориентация на вехи определяет, что небольшая, заранее определенная часть общего решения будет получена и оттестирована вовремя, и риски планирования и качества будут известны заранее – следовательно, будет время на них среагировать.
Вехи больше ориентированы на заказчика, чем на разработчика. Каждая веха – это точка синхронизации, когда команда заново пересматривает ожидания заказчика и риски. Это точки обсуждения и ревизии, а не точки фиксации принятых решений. Они позволяют проектной группе и заказчикам сравнить границы проекта и ожидания пользователей.
Каждая веха определяет набор документов, которые должны быть созданы и согласованы с заказчиком. Они отражают текущую ситуацию и ее текущее понимание проектной группой и заказчиком.
Выпуск нескольких версий продукта предпочтительнее, чем попытка сделать все сразу. Развитие технологий очень быстро изменяет возможности, а следовательно, и ожидания пользователей персональных компьютеров. Границы проекта могут уточняться тогда, когда это необходимо. Потребность в изменении границ проекта может вызываться изменением требований заказчика или рисками, которые трансформировались в проблемы
|
|
|
Как правило, работы на первой фазе проекта проводятся до того, как сформированы требования, осуществляются бесплатно для заказчика (до заключения договора) и длятся одну-две недели. Эта фаза необходима для того, чтобы команда разработчиков получила данные и оценила усилия, необходимые для создания функциональной спецификации, которая впоследствии будет использована при разработке.
Основным результатом первой фазы «Анализ» является составление документа «Образ и границы проекта». Это документ объемом пять-семь страниц, он составляется менеджером проекта (отвечает за правильное отображение потребностей заказчика) и менеджером программы (отвечает за соответствие задачи ожиданиям заказчика) и предназначен для четкого и ясного определения следующего:
|
|
|
• цели проекта, ожидания заказчика, база для исходной оценки рисков проекта. Данный документ определяет, какая концепция решения закладывается в основу;
• критерии для применения модели процесса разработки MSF, для совершенствования характеристик проекта, формирования команды и определения организации, которые будут принимать участие в проекте;
• ожидаемые затраты, требуемые для формирования функциональной спецификации, которая должна быть создана на следующей фазе проекта.
После анализа данных, моделирования различных процессов и планирования процесса разработки данный документ должен быть дополнен с учетом лучшего понимания потребностей заказчика, обнаруженных технических решений или рисков, достигнутого компромисса между объемами и сроками работ. Изменения, вносимые в документ «Образ и границы проекта» по мере его разработки, должны становиться все менее и менее значительными, так как они все больше начинают влиять на риски, связанные с временем исполнения проекта.
После утверждения функциональной спецификации изменения в документе «Образ и границы проекта» запрещаются, так как он является первичным, основополагающим документом для планирования проекта и управления процессом разработки. Достижение вехи «Общее описание проекта» означает, что проектная группа и заказчик достигли совместного понимания того, что будет представлять собой результат проекта (продукт) и какие ограничения должны быть учтены.
|
|
|
Фаза «Планирование» завершается вехой «Функциональные спецификации». Это означает, что заказчик и проектная группа пришли к соглашению по распределению и значениям приоритетов и ожиданий. Это позволяет пересмотреть риски и первоначальные оценки сроков и ресурсов, требуемых для проекта.
Функциональные спецификации описывают, какими возможностями должен обладать результирующий продукт, и являются одним из основных результатов этой фазы. Этот документ представляет собой как бы договор между проектной группой и заказчиком. За составление функциональных спецификаций отвечает менеджер программы.
Все роли проектной группы готовят план-график, который определяет, когда будет готово то, что описано в функциональных спецификациях.
Фаза «Разработка» завершается вехой «Завершение разработки». Эта веха достигается тогда, когда получена первая бета-версия полного продукта, содержащая полный код, который должен быть тщательно оттестирован. Кроме того, пользователи могут апробировать продукт и определить, все ли их потребности нашли в нем отражение. Кроме того, это — первое тестирование процедур внедрения и поддержки продукта. На этой фазе разрабатывается стратегия внесения изменений в работающий продукт. Она будет поддерживать и выпуск последующих версий.
Фаза «Стабилизация» завершается вехой «Выпуск версии (Релиз)». Достижение этой вехи означает, что продукт или услуга работоспособны и что они передаются группам поддержки сопровождения. На этой фазе полностью задействуются группы поддержки и сопровождения. Эффективность их процедур проверяется во время бета-версий. К моменту выпуска версии продукта этими группами уже накоплен необходимый опыт по сопровождению, собран материал об имеющихся особенностях и типовых трудностях, с которыми сталкиваются пользователи при работе с продуктом.
Не менее важно выполнение работ по продвижению продукта, информированию о его возможностях, особенностях и «цене» заказчика и конечных пользователей, для того чтобы создать положительное восприятие нового продукта или следующей версии. Этими работами не стоит пренебрегать даже в том случае, если вы уже «продали» результаты проекта, в дальнейшем вы сэкономите себе значительное время и усилия.
Управление рисками. Планирование с учетом рисков — это прием, когда компоненты проекта, связанные с наибольшим риском, разрабатываются первыми. Особенно важно планировать с учетом рисков в проекте, связанном с разработкой программного обеспечения или созданием инфраструктур.
• MSF поощряет разработчиков, создавать макеты и прототипы как можно раньше. Это снижает риск получения неполноценного продукта, нереального графика или краха всего проекта.
• Определяется, какие возможности и когда должны быть реализованы; приоритеты задачам расставляются на основании:
- управленческих и бизнес-рисков — гарантия того, что в очередной версии будут реализованы особенно важные для бизнеса функции;
- технических рисков — гарантия того, что потенциально рискованные функции будут реализованы в первую очередь, и это предоставит достаточный ресурс времени для тщательного тестирования, если потребуется.
• Разрабатывается план по предотвращению наиболее вероятных и опасных ситуаций и, на всякий случай, план «ликвидации катастрофы», т.е. план возврата к последнему работоспособному варианту без потери данных.
• Обязательно пересматривается проектный план для включения в него этого «смягчающего» риски плана. Как правило, это потребует ресурсов и времени, а также выполнения дополнительных задач.
Если компоненты, связанные с высокой степенью риска, потребуют больше времени, чем вы рассчитывали, то планирование с учетом рисков предоставит дополнительное время для реагирования.
Следует также учитывать, что одним из ключевых факторов успешного бизнес-решения является вовлечение пользователей в процесс проектирования на всех его фазах. «Лучший способ приобрести сторонников — это сделать их причастными».
К сожалению, вовлечением пользователей в процесс проектирования сложно управлять. Основные соображения, почему организации и команды разработчиков не привлекают пользователей к работам над проектом, следующие:
• пользователи плохо формулируют то, что им нужно;
• как правило, они сопротивляются изменениям. Им не нужны новые технологии, и соответственно они не хотят работать над их проектированием;
• пользователи придерживаются различных мнений о том, какие возможности должна включать в себя новая система, и имеют широкий спектр предпочтений цветов и расположения элементов на экране;
• пользователи просят реализовать ту или иную функцию, но, когда это сделано, они хотят чего-нибудь другого.
Однако если нет ясных перспектив ежедневного (повседневного) использования системы, то можно предсказать серьезные препятствия на пути к успеху.
Выпуск версий продукта. Выпуск нескольких версий продукта означает, что не вся функциональность реализует сразу, процесс разработки итерационен и проектная группа принимает решения о включении той или иной функциональности по мере необходимости, ориентируясь на версии и даты выпуска.
При последовательном выпуске версий проектная группа может начать с реализации функций, наиболее критичных для заказчика, и планомерно получать от пользователей обратную связь, которая потребуется при разработке следующих версий.
Первый выпуск продукта содержит базовый набор функций, а последующие — включают все больше и больше дополнительных функций, вплоть до финального продукта. Последующие версии позволяют проектной группе в очередной раз проверить или изменить образ продукта (например, если изменились требования бизнеса).
Механизм выпуска последовательных версий позволяет управлять взаимоотношениями с заказчиком и достигать оптимального баланса между конкурирующими целями. Когда этот баланс найден удовлетворенность заказчика и качество продукта максимальны.
Особо следует отметить тот факт, что выпуск последовательных версий продукта требует меньших маркетинговых затрат, чем выпуск совершенно нового продукта. Одну из версий продукта проще позиционировать и продвигать на рынок.
Полученная версия может быть названа качественным продуктом, если она:
• удовлетворяет ожиданиям заказчика и пользователей;
• удовлетворяет проектным ограничениям;
• соответствует реальным потребностям;
• обеспечивает умение его использовать;
• обеспечивает его гладкое внедрение.
При этом:
• далеко не каждый проект должен быть выполнен как можно скорее;
• далеко не каждый проект должен реализовывать максимум возможностей и реализовывать все возможности сразу;
• далеко не каждый проект требует решений, не содержащих ошибок.
Дата добавления: 2019-07-17; просмотров: 137; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!