Диссертация (1138653), страница 6
Текст из файла (страница 6)
К факторам преодоленияБекхард и Харрис относят неудовлетворенность текущей ситуацией, оценкувидения выгод от изменения и удовлетворенность результатами выполненияпервых шагов. Подход к управлению созданием ценности, разработанный внастоящей диссертации, оказывает влияние на оценку видения и получениераннихрезультатовотпервыхшагов(чтооказываетвлияниенаудовлетворенность заинтересованных сторон), благодаря чему повышаетсяпотенциал преодоления сопротивления изменениям в организации и, такимобразом, вероятность успеха самих изменений.Управление изменениями содержания является одной из ключевыхобластей знания в управлении организационными ИТ-проектами в силу ужеупомянутойвышеневозможностисогласованияполнойспецификациитребований к продукту на ранних этапах выполнения проекта, в связи с которойвозникает необходимость внесения изменений в требования к продукту и всодержание проекта по данным мониторинга внедрения организационнотехнического решения.
Как отмечают Ципес и Кузьмищев, «цели проектоворганизационных изменений, как правило, не являются четко определенными имогут изменяться. С другой стороны, методы реализации проекта часто либоизначально не определены, либо нуждаются в постоянном уточнении по ходувыполнения работ» [Ципес, Кузьмищев, 2014].В настоящее время управление многие стандарты управления проектамизатрагивают вопрос управления изменениями.
Так стандарты международнойассоциации управления проектами IPMA выделяют управление изменениями в30качестве одной из технических компетенций менеджера проекта [Андреев и др.,2010; Hermarij, 2013]. IPMA дает общие рекомендации по организации процессауправления изменениями в проектах, которое включает в себя стадии концепции(инициации)управленияизменениямивпроекте,прогнозированиеипланирование изменений, организации и контроля изменений в проекте, анализа ирегулирования изменений, закрытия управления изменениями в проекте.Стандарт PMBoK [PMI, 2013a] выделяет относящийся к группе процессовмониторинга и упраелния процесс «Интегрированный контроль изменений»,основная выгода которого состоит в том, что он позволяет организоватьрассмотрение запросов на изменения, их документирование и внесение измененийв проект централизованным способом, благодаря чему снижаются риски,обусловленные изменениями, которые вносятся в содержание проекта безрассмотрения.Стандарт PRINCE2 [OGC, 2009] рассматривает процесс управленияизменениями в составе более широкого процесса управления событиями (issues),которые наряду с изменениями содержания включают отклонения от плана, атакже проблемы и вопросы.БремиМаркусорганизационноразделяютИТ-проектначасть,выполняющуюся на стороне заказчика и часть, выполняющуюся на сторонеподрядчика [Brehm, Markus, 2000].
Жизненный цикл подпроекта, выполняемогона стороне подрядчика [PMI, 2013b], включает в себя, как правило, следующиеэтапы:Анализ,Архитектура,Дизайн,Конструирование,Интеграция,Тестирование.Данные этапы являются перекрывающимися, в зависимости от подхода кпоставке продукта проекта могут быть итерационными, инкрементными, а такжепредполагать различный хронологический порядок этапов жизненного цикла.Подпроект, выполняющийся на стороне заказчика, включает следующиеэтапы жизненного цикла, подробно описанные в литературе, посвященнойавтоматизации бизнес-процессов [Portougal, Sundaram, 2006]: Концептуализация(бизнес-кейс),Конфигурация(подробноеописаниесоставапродукта),31Развертывание, Передача в операционную деятельность. Также к областиответственности заказчика относится в проектной деятельности извлечение выгодот использования результатов проекта в соответствии со стратегией организации[ГОСТ ИСО 21500-2014, 2015].Рассмотрим обобщенный жизненный цикл ИТ-проекта с выделениемэтапов, выполняемых на стороне заказчика и подрядчика (Рисунок 4).Представленная на рисунке последовательность этапов является условной: какбудет продемонстрировано в работе далее, зачастую интеграцию и тестированиеэффективно начинать непосредственно после разработки архитектуры ивыполнять непрерывно до приемки разработанного продукта.
Расположениеэтапов жизненного цикла в последовательности на представленном рисунке вчем-то аналогично связи «окончание-окончание», применяемой при построениисетевых диаграмм, то есть, последующий этап не может закончиться ранее, чемзавершится предыдущий. Этап развертывания в различных проектах можетвыполняться командой подрядчика или командой заказчика. Более того,программный продукт может развертываться и на вычислительных мощностях,предоставляемых заказчику подрядчиком. Это не оказывает существенноговлияния на управление изменениями в проекте, поэтому в данной работе на этомвнимание не акцентируется.Такжевозможнывариантыиспользованияитеративного,либоинкрементального или адаптивного жизненного цикла, в которых указанныеэтапыповторяютсявциклахразработкиинформационной системы.Рисунок 4.
Жизненный цикл ИТ-проекта.ивнедренияразработанной32Поскольку,организационнымикакговорилосьвыше,изменениями,тоИТ-проектыонивсегдаподверженысвязанысдействиюнеопределенности, присущей таким проектам. Этапы жизненного цикла ИТпроекта, выполняемые на стороне заказчика и подрядчика, существенноотличаются по терминологии, применяемому инструментарию и требуютразличных компетенций от команды проекта. Данная проблема усложняеткоммуникацию между командами проекта на стороне заказчика и подрядчика и непозволяет определить содержание проекта на начальных стадиях таким образом,чтобы минимизировать изменения в процессе разработки [Zhao, Cao, 2015].В этих условиях, менеджмент должен направлять усилия, очевидно, нестолько на разработку более качественного плана проекта, сколько на реализациюсистемы управления проектом, устойчивой к изменениям содержания, то естьсистемы управления, обеспечивающей достижение бизнес-целей в условияхизменений содержания в процессе выполнения проекта.
Для построенияустойчивой системы управления проектом потребуется изучить драйверыизменений содержания и определить движущие силы проекта и факторы,тормозящие его реализацию. Их выявление является необходимым условиемперехода от интуитивного принятия решений о корректирующих действиях впроекте к принятию решений, основанному на фактах [Бушуев, Ярошенко, 2010;Coombs, 2015] с их последующим анализом и выявлением первопричиннаблюдаемых явлений [Кубявка, Тесля, 2014]. При этом управление изменениямистановится инструментом обеспечения устойчивости системы управленияпроектом. Целью мероприятий по управлению изменениями является удержаниепоследствий изменений в проекте в области допустимых для заказчика потерь.Ципес и Товб [Ципес, Товб, 2009] рассматривают потери проекта в трехизмерениях: по времени, ресурсам и поставляемым продуктам.Проекты разработки программного обеспечения отличаются тем, чтообычно выполняются в условиях существенной, то есть, оказывающей ощутимоевлияние на результаты проекта неопределенности требований.
При этомнедостаточно проработанный дизайн программного продукта на начальных33стадиях проекта указывается в качестве главного фактора, вызывающегорасползание требований [Kuprenas, Nasr, 2003]. Может быть выдвинута гипотеза,что увеличение трудозатрат на планирование проекта должно снижать действиенеопределенности и, как следствие, приводить к уменьшению отклонений отвыполнения проекта по плану и потерь времени, ресурсов, а также качествапоставляемых продуктов. Однако, существуют исследования [Eisenhardt, Tabrizi,1995], опровергающие эту гипотезу.
При этом Эйзенхардт и Табрици указываютна то, что полученный результат не относится к компаниям, для которыхразработка программного обеспечения является ключевой компетенцией. То есть,приложивдополнительныеусилиякпланированиюпроекта,компании,специализирующиеся на разработке ПО, могут снизить трудозатраты навыполнение проекта и повысить качество. В то же время компаниям, которыезаказывают разработку ПО для того, чтобы автоматизировать свои бизнеспроцессы, создать дополнительную ценность своих традиционных продуктов илиреализовать новую бизнес-модель, снизить влияние неопределенности за счетболее тщательного планирования оказывается, как правило, невозможно, итрудозатраты на планирование только увеличивают затраты проекта (на величинузатрат на планирование). Также следует отметить, что исключение требований изсодержания или их замена в процессе выполнения не оказывают стольнегативного воздействия на устойчивость управления проектом [Rahmesh,Madhavan, 2012].При этом не следует отрицать важность планирования как такового, так какпроцессыпланированиябудутявлятьсясущественнойсоставляющейустойчивости системы управления.
Современные исследования о методахпланирования предлагают подходы, позволяющие построить оптимальноерасписание проекта в условиях неопределенности [Herroelen, Leus, 2005; Van deVonder, Demeulemeester, Herroelen, 2008], а также ищут возможности дляпостроения расписаний, отличающихся свойством надежности и устойчивости поотношению к отклонениям в выполнении работ проекта [Herroelen, Leus, 2004a;Herroelen, Leus, 2004b; Leus, Herroelen, 2004].34Одной из наиболее важных проблем, обусловливающих невозможностьрешения проблемы расползания требований посредством тщательной проработкидизайна продукта и плана управления проектом, является существенное различиев требуемых компетенциях команд на стороне заказчика и подрядчика.Существуют подходы к управлению ИТ-проектами, в которых эта проблемарешается введением в проект роли, сочетающей в себе компетенции как вразработке программного обеспечения, так и в предметной области.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
