|
Расписание составлялось, как для каждого подпроекта отдельно, так и для всего проекта в целом. Менеджеры подпроектов определяли необходимые работы, которые необходимо выполнить в рамках своих подпроектов, производили декомпозицию этих работ на более простые, определяли взаимосвязи и длительность работ, определяли ресурсные требования на выполнение каждой задачи. На основании этих данных составлялось расписание для каждого подпроекта, в котором описывается иерархический список работ и взаимосвязи выполнения этих работ. Менеджер проекта на основании расписаний подпроектов составлял расписание всего проекта, определяя взаимосвязи между работами подпроектов и контролируя ход выполнения этих работ. Так тестирование, возможно, проводить только после того, как завершиться параметризация поставленных модулей.
Расписание подпроектов вели и контролировали менеджеры этих подпроектов. Общее расписание проекта - менеджер проекта.
Изменения в расписание вносятся на основании отчетов о выполнении работ и запросов на изменение (шаблон приведен в приложении 6). Отчет о выполнении заполняет менеджером подпроекта и отсылается в проектный офис за 1 день до намеченной встречи в рамках проекта. Проектный офис идентифицирует отчет и сообщает менеджеру проекта о проблемах, которые описаны в отчете для подготовки к встрече. В ходе встречи рассматриваются причины повлекшие задержку или ожидаемую задержку выполнения вехи проекта, предпринятые меры и обсуждают новую дату завершения. Если руководство проектом соглашается на новые запланированные сроки, то это утверждается и происходит изменение в расписании проекта, если нет, то планируется изменение масштаба или бюджета проекта, с указанием причины, из-за которой произошли изменения.
Запросы на изменение инициируются сотрудником проекта, регистрируются в системе Request Tracker инициатором и направляются менеджеру подпроекта. Если менеджер подпроекта не может решить данный вопрос в пределах ответственности подпроекта, то тогда этот запрос перенаправляется в проектный офис. Там рассматривается запрос на изменения, проверяется степень полноты этого запроса, присваивается номер и отправляется менеджеру проекта для решения. Статус запроса на изменения постоянно отслеживается и обновляется. Менеджер проекта принимает решение об одобрении или отклонении запроса. В случае если запрос на изменения превышает полномочия менеджера проекта, то он адресует этот запрос reference group. Так же менеджер проекта сообщает о своем решении менеджеру подпроекта.
Основные вехи проекта по внедрению новой банковской системы приведены в Приложении 7
Так же происходит информирование о ходе выполнения проекта остальных сотрудников банка, которые не участвуют в нем, и устанавливается обратная связь с ними. Раз в месяц в специальных банковских выпусках рассказывается о этапах выполнения проекта. В специальной рубрике любой сотрудник банка имеет возможность задать интересующий его вопрос о проекте. В следующих выпусках он получит ответ от сотрудников проектной команды на поставленный вопрос.
На мой взгляд, недостатком является отсутствие плана управления коммуникациями. Т.е. неформально члены проектной команды, которые находятся в проекте достаточно долгое время, знают все информационные потоки, которые используются в проекте и где можно найти нужную информацию, но так как нет документа, описывающего структуру хранения проектной документации и документации о продуктах системы, то получение и поиск такой информации в случае прихода новых членов проектной команды или сотрудниками банка не входящими в проект, представляет определенные сложности, и требуют значительных временных затрат. Мне кажется, необходимо создать такой документ, где нужно описать структуру хранения, структуру распределения проектной документации и описание информации, подлежащей распространению.
9. Управление качеством проекта
Важным процессом проекта по замене новой банковской системы является управлением качеством проекта. Были приняты стандарты, которым должна удовлетворять новая банковская система, а так же процедуры, с помощью которых будет обеспечиваться заданное качество. Эти процедуры были направлены на получение устойчиво работающей новой банковской системы соответствующей заявленным банком требованиям и включают в себя:
- Определение соответствия новой банковской системы потребностям ММБ, выраженным в виде требований к данной системе, в сроки, определенные планом проекта
- Организация эффективного выявление проблем в работе системы и связанных с ними рисков
- Организация управления обнаруженными проблемами
С нашей стороны, со стороны заказчика в ходе проекта выполнялись все определенные условия для того, чтобы поставщик смог поставить качественный продукт в заявленные сроки. Мы предоставили поставщику системы подробную спецификацию, требования к продукту, были детально описаны все процессы, оказываются консультации разработчиков системы по возникающим у них вопросам, своевременно осуществляются платежи за поставляемые модули системы. Для выявления проблем в работе системы проводятся тестирования поставляемых продуктов. Вся наша работа направлена на получение качественного продукта – новой АБС. К сожалению, это нельзя сказать о поставщике системы, качество поставляемых отдельных модулей системы оставляло желать лучшего. Сроки поставок срывались, условия договора не выполнялись. Обнаруженные ошибки очень долго обрабатывались, приходилось доказывать поставщику, что это их недоработки. После этого ошибки так же долго исправлялись.
В таких условия было очень тяжело обеспечивать получение продукта надлежащего качества в определенные сроки. Тем более, что никакие штрафные санкции не давали результатов, а только наоборот ещё больше усугубляли ситуацию.
Для исключения этих проблем банку на этапе заключения договора необходимо было занять жесткую позицию, что любая проблема в системе – это ошибка I-Flex.
Так же, как я уже об этом говорил, нашему банку нужно было заключить с поставщиком соглашение об уровне услуг, в котором определено время реакции компании I-Flex на ошибку и время её исправления в зависимости от приоритета ошибки. Например, для ошибок высочайшего приоритета время реакции составляет 4 часа, ошибка должна быть исправлена не позднее, чем через 5 дней. Так же в это соглашение нужно включить не только вышеуказанные количественные показатели по исправлению ошибок, но и качественные, например:
· процент ошибок
· количество переоткрытых ошибок
Помимо этого банку необходимо приложить усилия к тому, чтобы это соглашение выполнялось на практике. Если не получается этого добиться штрафами и переговорами, то привлечь западных акционеров, в конце концов достижение положительного результата внедрения новой банковской системы направлено на общее развитие банка и как следствие получение прибыли акционерами.
Для контроля качества осуществляется тестирование программного обеспечения, программных модулей, интерфейсов различных типов (интерфейсов обмена данными, сообщениями, проведения транзакций), графических интерфейсов конечных пользователей, отчетов, пользовательской документации, процедур, интегрированной системы. Тестирование является средством контроля качества поставляемых продуктов.
При тестировании использовалась централизованная модель тестирования. Руководство процессом тестирования осуществляется менеджером тестирования. Одна из задач менеджера тестирования – не допустить децентрализации управления процессом, что может привести к избыточности или неэффективности тестирования, недостатку стандартизации, незарегистрированным ошибкам, ограниченному контролю процесса, хаотическому разрешению проблем и т.п.
В первую очередь тестировались те объекты или их свойства, которые существенным образом могут повлиять на бизнес банка в случае сбоя, т.е. объекты с требованиями, имеющими более высокий уровень приоритета. Приоритеты для требований определяются в ходе процесса управления требованиями на основе анализа существующих рисков.
Процесс тестирования основывается на использовании тест-кейсов. С каждым тест-кейсом связываются одно или несколько тестовых требований. Тест-кейсами покрываются все тестовые требования, что гарантируют полноту тестирования системы.
Если в ходе тестирования обнаружилась ошибка, она регистрируется в системе Request Tracker и ей присваивается приоритет, в зависимости от которого определяется степень и срочность исправления этой ошибки. На всем этапе исправления ошибки происходит контроль выполнения. По окончании исправления ошибки производится повторное тестирование.
Из-за поставок некачественного продукта приходится производить многократно повторяющиеся шаги тестирования одного и то же продукта, что усложняет процесс тестирования и сдвигает сроки внедрения системы. Анализируя качество работ поставщикая. у меня подвергается сомнению их уровень SEI-CMM 5.
|