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