Диссертация (1138653), страница 7
Текст из файла (страница 7)
Эта роль вразных методологиях носит различные наименования и имеет некоторыесмысловые отличия: владелец продукта [Сазерленд, 2016; Satpathy and others,2013], системный инженер [Батоврин, 2015a; Батоврин, 2015b], техническийруководитель проекта [Зельда, 2015]. В любом случае на эту роль в проектевозлагается ответственность за организацию разработки дизайна продукта иинтеграцию процессов жизненного цикла проекта, выполняемых на сторонезаказчика и подрядчика. Вообще, наличие подобного специалиста в команде ИТпроекта характерно для организаций, специализирующихся на разработкепрограммного обеспечения, а также в крупных проектах [Whyte, Stasis, Lindkvist,2016]. В компаниях, для которых разработка программного обеспечения неявляется ключевой компетенцией, наличие такого специалиста неэффективно.Выделение роли подобного технического лидера (владелец продукта)является одним из наиболее важных инструментов гибкого управления проектами– распространенной в сфере разработки программного обеспечения методологииуправления проектами в условиях ожидаемых изменений.
Несмотря на наличиеподтвержденного исследованиями опыта успешной реализации проектов сиспользованием гибкого управления ИТ-проектами в условиях неопределенноститребований[Serrador,Pinto,2015],даннуюметодологиюневозможнорекомендовать в качестве универсальной для применения в организационных ИТпроектах.Этосвязанокакснедоступностьюспециалистатребуемойквалификации на роль владельца продукта, так и непониманием заказчиком самойметодологии и нежеланием его следовать рекомендуемым процессам [Половинко,2013].
Тем не менее, вовлечение заказчика в проект, даже при невозможности в35полной мере выполнять роль владельца продукта, хотя и не гарантируетотсутствия расползания требований, но позитивно влияет на итоговое качествопродукта [Антипов, 2014].В некоторых исследованиях выдвигается гипотеза, что можно повыситьэффективность управления ИТ-проектами в подобных случаях, предложивметодологию,сочетающуюдостоинствагибкогоитакназываемого«традиционного» управления проектами [Дагаев, Лутфуллин, 2015; Špundak,2014]. В настоящее время идея не получила практического развития, хотя несуществует ограничений в стандартах гибкого и традиционного управления наприменения подобных гибридных подходов.Практики гибкого управления проектами могут применяться ситуативно вслучаях, когда это оправдано с точки зрения управления рисками проекта.
Такимипрактиками являются, например, непрерывная интеграция и разработка черезтестирование. Их использование существенно снижает риск возникновенияошибок интеграции на поздних стадиях проекта и в этом смысле способствуетповышению устойчивости системы управления [Jeffries, Melnik, 2007].Можно выделить следующие отличия предложенного в настоящейдиссертации подхода от моделей и методов, использующихся в настоящее время вуправлении организационными изменениями и управлении ИТ-проектами:• Благодаря тому, что подэтапы диагностики проблемы, выбора решений,а также обучения из модели Левина включены в этап выполненияизменений (вместо этапов размораживания и замораживания системы)• Достигаетсявозможностьреализациипроектасиспользованиеминкрементного жизненного цикла, что, в свою очередь ведет квозможности получения ранних результатов, что снижает сопротивлениеизменениям и позволяет в течение всего проекта поддерживать видениеизменения актуальном состоянии• Поддержание видения изменения в актуальном состоянии в течениевсего жизненного цикла проекта позволяет снизить риски недостижения36стратегических целей организации, реализацию которых поддерживаетИТ-проект• Управление изменениями содержания проекта является важнейшиминструментом создания ценности организационного ИТ-проекта идолжно осуществляться на основе мониторинга выполнения планареализации ценностиПриэтомпосколькуизменениясодержанияпроектаявляютсяинструментом реализации ценности, особую актуальность приобретает вопросуправления устойчивостью системы управления к этим изменениям, так как внеустойчивой системе они приведут к расползанию требований и объема проектаи, как следствие, недостижению его целей.
В настоящее время исследования вобластиустойчивостисистемуправленияпроектамипреимущественносфокусированы на вопросе построения расписания, устойчивого к отклонениям.Обзор подходов к построению устойчивого расписания проекта приведен вследующем параграфе.1.3.Подход к обеспечению устойчивости систем управления проектами,основанный на построении устойчивого расписанияРассмотримподробнеепроблемупостроенияустойчивыхсистемуправления проектами, необходимость в которых сформулирована в предыдущемпараграфе.
Исследования устойчивости проектов как правило относятся кустойчивости расписания [Cioffi, 2006; Ortiz de Orue and others, 2009], то есть, вних рассматриваются вопросы построения такого расписания, при котором вслучае возникновения задержек в выполнении работ проект вследствие наличияправильно рассчитанных буферов вернется со временем к выполнению всоответствии с первоначально определенным расписанием, а значит завершится всрок. Рассматривают при этом следующие варианты поведения проекта:37• Послеокончаниядействиявозмущающегофактораотклонениесокращается, и выполнение работ возвращается к первоначальномурасписанию;• Отклонение, возникшее вследствие задержки работы, не уменьшается ине увеличивается до конца проекта;• Возмущение вызывает увеличивающееся со временем отставание,приводя к изменению длительности проекта более чем на величинупервоначальной задержки.Первый вариант расписания проекта в некоторых случаях называютположительноустойчивым,второйнейтральноустойчивым,третий–неустойчивым [Swartz, 2008].Подход к обеспечению устойчивости проекта, основанный на построенииустойчивого расписания, может во многих случаях гарантировать соответствиедлительности проекта плановой величине, однако, только в том случае, еслиотклонение от выполнения по плану обусловлено не изменением содержанияпроекта.
Если цели проекта формулируются в терминах разработки программногопродукта и не привязываются к метрикам изменяемых бизнес-процессов, тодостаточным для исследования возможности достижения целей проекта вусловиях изменений является рассмотрение вопроса устойчивости проекта вразрезе устойчивости расписания. В этом случае следовало бы обратить вниманиена метод критической цепи [Лич, 2010] и его производные. Вопрос обеспеченияустойчивости при этом сводится к вопросу о правильном определении размерабуферов и об их эффективной расстановке в расписании проекта.Этот подход, однако, неприемлем для целей данной диссертации, посколькуне учитывает возможные изменения содержания проекта, обусловленныеуточнением целей проекта и дизайна разрабатываемого программного продукта впроцессе выполнения. Для ИТ-проектов, между тем, изменение содержаниеявляется, как уже говорилось выше, одной из основных причин возникновенияотклонений от выполнения по плану.
Таким образом, построение устойчивого38расписания может рассматриваться только как один из инструментов построенияустойчивой системы управления проектом, но никак не единственный.Кроме того, выполнение плана по длительности проекта является неединственным показателем качества управления проектом, а соблюдениеограничений классического проектного треугольника не гарантирует успешностиорганизационного изменения, для осуществления которого выполняется ИТпроект.
Система управления ИТ-проектом должна, таким образом, включатьпроцессы мониторинга влияния, оказываемого разрабатываемым продуктом нацелевое организационное изменение, и принятия решений о внесении измененийв содержание при отклонении выявленного влияния от желаемого [Sudhaman,Thangavel, 2015].Сложность управления организационным ИТ-проектом состоит в том, чтозачастую затруднительно определить, обусловлено ли отклонение в реализацииорганизационногоизменениянедостаткамиразработанногопродуктаилипричинами организационного характера, такими, как например, сопротивлениеизменениям [Vrhovec and others, 2015], которое, в свою очередь, также можетиметь множество причин возникновения [Жукова, 2014; Лукьянова, Алексеева,2011;O’Toole,1995].Решенияокорректирующихдействияхдолжныприниматься по итогам аудита проекта рабочей группой, включающейпредставителей различных заинтересованных сторон.Обеспечение устойчивости управления проектом требует реализацииотрицательных обратныхсвязейв системеуправления[Zuykov, 2015].Соответственно, задача построения устойчивой системы управления проектамисвязана с организацией мониторинга проекта для раннего выявления проблем, чтоможет включать один или несколько инструментов, таких как анализ рисков,аудит проекта, контроль по методу освоенного объема, анализ стейкхолдеров,причинно-следственный анализ, аудит зрелости, управление интерфейсами ворганизационнойструктурепроекта,использованиенакопленногоопыта,экспертные методы [Haji-Kazemi, Andersen, Klakegg, 2015; Taylor, 2006].
Все этиметоды имеют свою область применимости и технологию применения. Для того,39чтобы сделать вывод о соответствии того или иного метода поставленной задаче иего возможностей для повышения устойчивости системы управления требуетсямоделированиединамикисистемыуправления.Далееприводитсяобзорсовременных методов моделирования динамики проектов.1.4.Моделирование обратных связей в системах управления проектамиметодом системной динамикиОбзор публикаций на тему применения компьютерного моделирования впроизводственной сфере и бизнесе (обзор затрагивает моделирование вразличных областях менеджмента, но в целом выводы относятся и к управлениюпроектами, на что авторы статьи указывают) с 1997 по 2006 год [Jahangirian andothers, 2010] показывает, что наиболее популярным методом моделированияявляется DES (discrete event simulation, симуляция дискретных событий). Приэтом моделирование осуществляется в программном обеспечении, построенномна базе электронных таблиц. DES упоминается в 40% всех публикаций,отобранных для исследования.
Второе место по популярности применения висследованиях занимает системная динамика (более 15%). Преимуществомсистемной динамики по сравнению с методами, считающимися традиционными,состоит в том, что она позволяет учитывать такие важные для модели системыэлементы, как обратные связи [Зуйков, 2013]. Иными словами, построенные припомощи системной динамики модели позволяют учесть влияние на проектуправленческих решений, принимаемых на основе данных мониторинга процессавыполнения проекта, благодаря чему формируется отрицательная обратная связь.Также системная динамика предназначена для моделирования систем, в которыхсуществуют задержки, связанные с инерционностью процессов. К таким системамотносятся и системы управления проектами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
