2015-01-30
404
Заказчик размышлял об обновлении ПО следующим образом:
«Компания покупает ту или иную компьютерную систему, но со временем она устаревает и компания сталкивается с дилеммой, следует ли ей обновить текущую систему до более новой версии или купить совершенно иную систему? Новая система - это новый поставщик, новые функциональные возможности и необходимость нового обучения всех пользователей. Кроме того, вся информация должна быть извлечена из старой системы и перенесена в новую. Это привносит в ситуацию определенные риски: необходимо убедиться, что вся информация, накопленная за прошедшие годы, аккуратно перенесена и размещена в новой системе.
На первый взгляд кажется, что лучший вариант -продолжить пользоваться уже имеющейся системой и услугами старого Поставщика. В этом случае компания может продолжать использовать старое, проверенное и зарекомендовавшее себя ПО. Впрочем, теперь не такое уж и старое - ведь оно обновлено до новой версии, лишенной выявленных недостатков и обладающей дополнительными возможностями. Да и обновление обычно протекает легче, чем переход на новую систему, поскольку не сопровождается никакими сложностями и проблемами, сопутствующими внедрению нового ПО. Это, в свою очередь, означает, что компания может сфокусироваться на основной деятельности, не беспокоясь о работоспособности новой компьютерной системы.»
Процессы управления проектом
При выполнении проекта была использована систематическая методология управления проектами, При этом были использованы следующие компоненты:
• Управление интеграцией;
• Управление содержанием;
• Управление сроками и стоимостью;
• Управление качеством;
• Управление контрактом;
• Управление коммуникацией;
• Управление рисками.
Управление интеграцией:
План проекта был разработан, доведен до сведения ключевых заинтересованных сторон проекта и одобрен.
Управление содержанием:
Еще до того, как проект вообще был задуман, Поставщик обратился к Заказчику с предложением обновить ПО. Заказчик попросил Поставщика подготовить бизнес-план и выполнить анализ осуществимости. На эту работу ушло шесть недель, а в подготовленных документах рассматривались проблемы текущей версии системы, разбирались подходы к решению этих проблем в новой версии и акцентировались дополнительные функциональные возможности, которые станут доступны при обновлении ПО до новой версии.
Поставщик представил документ Заказчику и был приглашен на проводимую Заказчиком ежегодную конференцию по планированию, чтобы изложить свою концепцию. Идея была принята с энтузиазмом. Концепция была доведена до сведения соответствующих лиц и одобрена Заказчиком.
Затем Поставщик посетил несколько ключевых филиалов Заказчика, чтобы обсудить с пользователями влияние обновления на соответствующие участки бизнеса. Сделанные пользователями комментарии были отмечены и включены в определение проекта.
Затем Поставщик организовал совещание для всех ключевых заинтересованных сторон из числа пользователей, в ходе которого были описаны все предметы поставки. Далее определение проекта было изучено группой из двенадцати пользователей в ходе двухдневного рабочего совещания, по окончании которого документ был подписан.
Управление сроками:
Было разработано простое укрупненное расписание проекта, приведенное на Рис. 1. В задачи были выделены соответствующие ресурсы.
Управление стоимостью:
При определении общей стоимости проекта использовались различные существующие категории расценок.
Управление контрактом:
Стороны договорились, что выполняемый проект будет проектом с фиксированной ценой. За месяц до этого Заказчик и Поставщик заключили пятилетнее лицензионное соглашение, не содержавшее "параграфа о выходе" (не предусматривавшее расторжения). Это соглашение обязывало Заказчика работать с Поставщиком и использовать его ПО. Проект обновления гарантировал, что Заказчик получит в свое распоряжение новейшую версию ПО. Еженедельно каждый член команды проекта заполнял табель учета рабочего времени, и эти данные вводились в расписание проекта. Это позволяло менеджеру проекта отслеживать ход работ по каждой задаче и готовить отчет об общем ходе работ по проекту.
Управление качеством:
Предметы поставки были разбиты на "пакеты" меньшего размера. Для каждого пакета была выработана проектная спецификация (технические нормы на проектирование), и работа не продолжалась до тех пор, пока пользователи не подписывали ее. После этого Поставщик готовил техническую спецификацию (технические условия - прим. редактора) для внутреннего пользования. Она подлежала одобрению как минимум двоими независимыми рецензентами. После того как программист писал и проверял программный код, этот код тестировали члены команды тестировщиков, чтобы убедиться в его состоятельности. И наконец, система была подвергнута четырем полным циклам тестирования.
Управление коммуникациями:
С самого начала фазы разработки проводились еженедельные совещания комитета управления проектом. Постоянными участниками со стороны пользователя на этих совещаниях были менеджер проекта со стороны пользователя и технический консультант со стороны пользователя (см. Рис. 2). Менеджер проекта со стороны Поставщика возглавлял совещания и по мере необходимости приглашал на них членов команды проекта и другой персонал. Цель совещаний состояла в том, чтобы увидеть общую картину статуса проекта и проинформировать всех заинтересованных лиц о том, что уже сделано и что еще планируется сделать. Совещания давали возможность вынести на обсуждение такие проблемы как недоступность того или иного ресурса или неудовлетворенность выполняемой работой.
Управление рисками:
"Риски" включались в повестку всех еженедельных совещаний по проекту. Журнал рисков постоянно обновлялся и содержал все идентифицированные риски, способные так или иначе повлиять на "сдачу в эксплуатацию" согласно плану. Ранжирование рисков по вероятности возникновения и степени влияния на проект выполнялось при помощи матрицы. Каждому риску назначался ответственный. Потенциальное влияние каждого риска на успех проекта учитывалось, а описание статуса обновлялось еженедельно. Риски, которые становились "проблемами", вносились в журнал проблем.
Ход работ по проекту Фаза 1 - инициация проекта
Как показано на Рис.1, проект был разделен на фазы, начиная с "инициации проекта". Проект был стандартным, а его результат казался предсказуемым. Заказчик использовал систему почти 5 лет и был удовлетворен ей как в смысле функциональности, так и в смысле способности работать с большими объемами данных. ПО было разработано в начале 90-х годов XX века, так что для глобального обновления время было самое подходящее.
Первый шаг заключался в том, чтобы провести презентации для ключевых лиц компании-Заказчика, принимающих решения, с елью демонстрации им выгод обновления. Укрупненное содержание было одобрено, дата поставки была установлена и было оговорено, что это будет проект с фиксированной ценой. Организационная структура проекта была стандартной, включала в себя Управляющий комитет проекта, который собирался по мере необходимости, и Комитет управления проектом, который собирался еженедельно.
Технический консультант со стороны пользователя был единственным лицом, уполномоченным подписывать спецификации. Он не делился этими документами с остальными пользователями, лишая их возможности познакомиться с новой системой. Это мотивировалось тем, что консультант превосходно разбирается в системе и бизнес-приложениях ПО. Наличие единственного контактного лица со стороны пользователей значительно повышало управляемость проекта, позволяло избежать проблем со сбором множества занятых людей в одно время в одном месте для подписания того или иного документа.
Фаза 2 – Разработка проекта
Проект включал в себя двенадцать контрольных событий, связанных с различными пакетами работ, включенными в фазу разработки. Это было сделано для того, чтобы дать Заказчику точное понимание того, что делается в проекте, и получить его одобрение. Приемлемое решение для обеих сторон достигалось всегда. Через 7 месяцев после начала проекта управляющий директор Заказчика по работе с клиентами заверил обе стороны, что все идет намеченным курсом, тем более, что 80% проектных работ были выполнены.
