Выполнение пилотного проекта

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

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

1. подтвердить достоверность результатов оценки и выбора;

2. установить, действительно ли ТС ПО годится для использо­вания в данной организации, и если да, то определить наи­более подходящую область ее применения;

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

4. приобрести собственный опыт использования ТС ПО.

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

Важной функцией пилотного проекта является принятие ре­шения относительно приобретения или отказа от использования ТС ПО. Провал пилотного проекта позволяет избежать более зна­чительных и дорогостоящих неудач в дальнейшем, поскольку пи­лотный проект обычно требует приобретения относительно не­большого количества лицензий и обучения узкого круга специа­листов.

Первоначальное использование новой ТС ПО в пилотном проекте должно тщательно планироваться и контролироваться. Пилотный проект включает следующие шаги (рис. 5.5).

Определение характеристик пилотного проекта

Пилотный проект должен обладать следующими характерис­тиками.

Типичность предметной области. Чтобы облегчить окончатель­ное определение области применения ТС ПО, предметная об­ласть пилотного проекта должна быть типичной для обычной де­ятельности организации. Пилотный проект должен помочь опре­делить любую дополнительную технологию, обучение или под­держку, которые необходимы для перехода от пилотного проекта к широкомасштабному использованию ТС ПО. В рамках этих ог­раничений пилотный проект должен иметь небольшой, но зна­чимый размер.

Масштабируемость. Результаты, полученные в пилотном про­екте, должны показать масштабируемость ТС ПО. Цель — получить четкое представление о масштабах проектов, для которых данная ТС ПО применима.

Рис. 5.5. Шаги пилотного проекта

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

Критичность. Пилотный проект должен иметь существенную значимость, чтобы оказаться в центре внимания, но не должен быть критичным для успешной деятельности организации в целом. Необходимо осознавать, что первоначальное внедрение но­вой ТС ПО подразумевает определенный риск. При выборе пи­лотного проекта приходится решать следующую дилемму: успех незначительного проекта может остаться незамеченным, с дру­гой стороны, провал значимого проекта может вызвать чрезмер­ную критику.

Авторитетность. Группа специалистов, участвующих в проек­те, должна обладать высоким авторитетом, при этом результаты проекта будут всерьез восприняты остальными сотрудниками ор­ганизации.

Готовность проектной группы. Проектная группа должна обла­дать готовностью к нововведениям, технической зрелостью и приемлемым уровнем опыта и знаний в данной ТС ПО и пред­метной области. С другой стороны, группа должна отражать в ми­ниатюре характеристики организации в целом.

В большинстве случаев существует баланс между желанием реализовать идеальный пилотный проект и реальными ограниче­ниями организации. Организация должна выбрать пилотный проект таким образом, чтобы, во-первых, способ использования ТС ПО в нем совпадал с дальнейшими планами и, во-вторых, пе­речисленные выше характеристики были сбалансированы с ре­альными условиями организации.

Кроме того, организация должна учитывать продолжитель­ность пилотного проекта (и в целом процесса внедрения). Слиш­ком продолжительный проект связан с риском потери интереса к нему со стороны руководства.

Планирование пилотного проекта

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

1. цели, задачи и критерии оценки;

2. персонал;

3. процедуры и соглашения;

4. обучение;

5. график и ресурсы.

Цели, задачи и критерии оценки

Ожидаемые результаты пилотного проекта должны быть чет­ко определены. Степень соответствия этим результатам представляет собой основу для последующей оценки проекта. Для фор­мирования такой основы необходимо выполнить следующие действия:

1. описать проект в терминах ожидаемых результатов (т.е. ко­нечного продукта). Описание должно включать форму представления и содержание результатов. Должны быть чет­ко определены договорные требования и соответствующие стандарты;

2. определить общие цели проекта, а именно: насколько хоро­шо и до какой степени ТС ПО планируется использовать в среде данного проекта. Примером цели может быть опреде­ление степени улучшения качества проектной документа­ции в результате применения ТС ПО;

3. определить конкретные задачи, реализующие поставленные цели. Каждой цели можно поставить в соответствие одну или несколько конкретных задач с количественно оценива­емыми результатами. Примером такой задачи может быть сравнительный анализ качества документации, полученной с помощью ТС ПО и без нее. Документация может включать спецификацию требований к ПО, высокоуровневые и де­тальные проектные спецификации;

4. установить критерии оценки результатов. Чтобы определить степень успеха пилотного проекта, необходимо использо­вать набор критериев, основанных на упомянутых выше за­дачах. Примером критерия может быть степень непротиво­речивости проектной документации и контролируемости выполнения требований к ПО. Значения критериев должны сравниваться с базовыми значениями, полученными до вы­полнения пилотного проекта.

Персонал

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

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

Процедуры и соглашения

Необходимо четко определить процедуры и соглашения, ре­гулирующие использование ТС ПО в пилотном проекте. Эта за­дача, скорее всего, может оказаться более долгой и сложной, чем ожидается, при этом может оказаться необходимым привлечение сторонних экспертов. Примерами процедур и соглашений, кото­рые могут повлиять на успех пилотного проекта, являются мето­ды, технические соглашения (в частности, соглашения по наиме­нованиям и структуре каталогов, стандарты проектирования и программирования) и организационные соглашения (в частнос­ти, правила учета использования ресурсов, авторизации и конт­роля изменений, а также процедуры экспертизы, проверки каче­ства и подготовки отчетов).

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

Обучение

Должны быть определены виды и объем обучения, необходи­мого для пилотного проекта. Планируемое обучение должно обеспечивать три вида потребностей: технические, управленчес­кие и мотивационные. Ресурсы, требуемые для обучения (учеб­ные аудитории и оборудование, преподаватели и учебные мате­риалы), должны соответствовать плану пилотного проекта.

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

Поставщики ТС ПО обычно предлагают обучение использо­ванию поставляемых ими средств. Помимо этого для некоторых средств может быть необходимо обучение методологии. Некото­рые виды обучения могут быть недоступны со стороны коммер­ческих организаций, они должны выполняться собственными силами. Такие виды обучения включают использование ТС ПО в контексте процессов, происходящих в организации, а также в со­вокупности с другими средствами в данной среде. Часть плана пилотного проекта, связанная с обучением, должна использо­ваться в качестве входа для плана практического внедрения.

При выборе необходимого обучения должны приниматься во внимание следующие факторы:

1. квалификация преподавателей;

2. соответствие обучения характеристикам конкретных групп специалистов (например, обзорные курсы для менеджеров, подробные курсы для разработчиков);

3. возможность проведения курсов непосредственно на рабо­чих местах;

4. возможность проведения расширенных курсов;

5. возможность подготовки самих преподавателей.

График и ресурсы

Должен быть разработан график, включающий ресурсы и сроки (этапы) проведения работ. Ресурсы включают персонал, технические средства, ПО и финансирование. Данные о персона­ле могут определять конкретных специалистов или требования к квалификации, необходимой для успешного выполнения пилот­ного проекта. Финансирование должно определяться отдельно по каждому виду работ: приобретение ТС ПО, установка, обуче­ние, отдельные этапы проектирования.

Выполнение пилотного проекта

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

Приобретение, установка и интеграция

После того как ТС ПО выбрана, она должна быть приобрете­на, интегрирована в проектную среду и настроена в соответствии с требованиями пилотного проекта. Границы этой деятельности зависят от тех действий, которые имели место в процессе оценки и выбора, а также от степени модификации средства, необходи­мой для его использования в проекте.

Процесс приобретения может включать подготовку контрак­та, переговоры, лицензирование и другую деятельность, которая выходит за рамки данных рекомендаций. Эта деятельность требу­ет затрат времени и человеческих ресурсов, которые должны быть учтены при планировании. План должен предусматривать отказ от выбранной ТС ПО на данном этапе из-за договорных разно­гласий.

После приобретения средства должны быть установлены, от­тестированы и приняты в эксплуатацию. Тестирование позволяет убедиться, что поставленный продукт соответствует требованиям контракта, обладает необходимой полнотой и корректностью. Этап приемки может быть предусмотрен контрактом, его реаль­ный срок может отличаться от того, который был предусмотрен первоначально в плане пилотного проекта. Особое внимание не­обходимо уделить соблюдению всех требований поставщика к параметрам среды функционирования ТС ПО.

После завершения приемки может потребоваться некоторая настройка и интеграция. Настройка может включать модифика­цию интерфейсов, связанную с требованиями специалистов про­ектной группы, а также с установкой прав доступа и привилегий. Настройка должна оставаться в рамках тех возможностей, кото­рые предоставляет сама ТС ПО.

Если новые средства должны использоваться в совокупности с некоторыми другими средствами, необходимо определить взаи­модействие средств и требуемую интеграцию. Для интеграции новых средств с существующими может понадобиться построе­ние специальных оболочек. Сложная интеграция может потребо­вать привлечения сторонних экспертов.

Поддержка

Доступная поддержка должна включать (по соглашению) «го­рячую линию» поставщика и поддержку местного поставщика, поддержку в самой организации, контакты с опытными пользо­вателями в других организациях и участие в работе групп пользо­вателей.

Внутренняя поддержка должна включать доступ к специалис­там, знакомым с установкой средств и работой с ними. Сущест­вует несколько возможных вариантов получения такой поддерж­ки (например, от специалиста данной организации, имеющего опыт предшествующей работы со средством; участников процес­са оценки и выбора или опытного консультанта). Такой тип под­держки должен специальным образом планироваться и администрироваться. Особое внимание должно быть уделено средствам, работающим в сетях или обладающих репозиториями, поддержи­вающими многопользовательскую работу.

Периодические экспертизы

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

Обновление версий

Пользователи ТС ПО могут ожидать периодического обнов­ления версий со стороны поставщика в течение выполнения пи­лотного проекта. При этом необходимо тщательное отношение к интеграции этих версий. Следует заранее оценить влияние этих обновлений на ход проекта. Новые версии могут как обеспечить новые возможности, так и породить новые проблемы. В то же время новая версия может потребовать видоизмененного или до­полнительного обучения, а также может оказать отрицательное воздействие на уже выполненную к этому моменту работу.

Оценка пилотного проекта

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

В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам.

1. Целесообразно ли внедрять ТС ПО?

2. Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)?

3. Какие проекты или подразделения в организации могли бы получить выгоду от использования ТС ПО?

Принятие решения о внедрении

На данном этапе процесса внедрения организация должна сделать существенные инвестиции в ТС ПО. Если ТС ПО удов­летворила или даже превысила ожидания организации, то реше­ние об ее внедрении может быть принято достаточно просто и быстро.

С другой стороны, может оказаться, что в рамках пилотного проекта ТС ПО не оправдала тех ожиданий, которые на нее воз­лагались, или же в пилотном проекте она использовалась удов­летворительно, однако опыт показал, что дальнейшие вложения в ТС ПО не гарантируют успеха.

Возможны четыре варианта результатов и соответствующих действий.

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

2. Пилотный проект потерпел неудачу, и его анализ показал, что выбранные средства не удовлетворяют потребности органи­зации. В этом случае организация может принять решение не внедрять данные средства, однако при этом также пересмот­реть свои потребности и подход к оценке и выбору ТС ПО.

3. Пилотный проект потерпел неудачу, и его анализ показал наличие таких проблем, как неудачный выбор пилотного проекта, неадекватное обучение и недостаток ресурсов. В этом случае может оказаться достаточно сложным принять , решение о том, следует ли вновь выполнить пилотный про­ект, продолжить работу по внедрению или отказаться от ТС ПО. Однако независимо от принятого решения процесс внедрения нуждается в пересмотре и повышенном внима­нии.

1. Пилотный проект завершился успешно, и признано целесо­образным внедрять ТС ПО в некоторых подразделениях или, возможно, во всей организации. В этом случае следую­щим шагом является определение наиболее подходящего масштаба внедрения.

В ряде случаев анализ пилотного проекта может показать, что причиной неудачи явился более чем один фактор. Последующие попытки внедрения ТС ПО должны четко выявить все причины неудачи. В экстремальных случаях тщательный анализ может по­казать, что в настоящий момент организация просто не готова к успешному внедрению сложных ТС ПО. В такой ситуации орга­низация может попытаться решить свои проблемы другими сред­ствами.

Особенности пилотного проекта

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

Отметим важнейшие характеристики пилотного проекта, не являющиеся представительными для организации в целом:

2. процессы в пилотном проекте в чем-либо отличаются от процессов во всей организации;

3. квалификация группы пилотного проекта не отражает ква­лификацию остальных специалистов организации;

4. ресурсы, выделенные на выполнение проекта, могут отли­чаться от тех, которые выделяются для обычных проектов;

5. предметная область или масштаб проекта могут отличаться от других проектов.

Выгода от использования ТС ПО

Результаты пилотного проекта следует сопоставить с возмож­ностями организации в целом. Например, если наиболее заинте­ресованные и квалифицированные участники проекта столкну­лись с серьезными трудностями в освоении ТС ПО, то менее за­интересованным и квалифицированным программистам из дру­гих подразделений потребуется существенно большее обучение.

Пилотный проект может также показать, что ТС ПО целесо­образно использовать для некоторых классов проектов и нецеле­сообразно — для других. Например, средство формальной вери­фикации может подходить для жизненно важных приложений и не подходить для менее критических приложений.

Перед разработкой плана перехода организация должна оце­нить ожидаемый эффект для различных подразделений или клас­сов проектов. При этом следует учитывать, что некоторые под­разделения могут не обладать необходимой квалификацией или ресурсами для использования ТС ПО.

Варианты решения о внедрении

Возможным решением должно быть одно из следующих.

6. Внедрить ТС ПО. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных Подразделений и предметной области.

7. Выполнить дополнительный пилотный проект. Такой вари­ант должен рассматриваться только в том случае, если оста­лись конкретные неразрешенные вопросы относительно внедрения ТС ПО в организации. Новый пилотный проект должен быть таким, чтобы ответить на эти вопросы.

8. Отказаться от ТС ПО. В этом случае причины отказа от конк­ретной ТС ПО должны быть определены в терминах потреб­ностей организации или критериев, которые остались неу­довлетворенными. Перед тем как продолжить деятельность по внедрению ТС ПО, потребности организации должны быть пересмотрены на предмет своей обоснованности.

9. Отказаться от использования ТС ПО вообще. Пилотный проект может показать, что организация либо не готова к внедрению ТС ПО, либо автоматизация данного аспекта процесса создания и сопровождения ПО не дает никакого эффекта для организации. В этом случае причины отказа от ТС ПО должны быть также определены в терминах потреб­ностей организации или критериев, которые остались неу­довлетворенными. При этом необходимо понимать отличие этого варианта от предыдущего, связанного с недостатками конкретной ТС ПО.

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

5.3.6.