ВведениеИспользование классических стандартов управления проектами базируется на тщательном планировании, систематическом контроле и управлении изменениями многочисленных параметров проектов, что бывает достаточно трудоемким, излишне бюрократизированным и не всегда выполнимым с необходимым уровнем качества, как со стороны руководителя проекта, так и участников проектных команд. Это приводит к снижению заинтересованности и вовлеченности сотрудников и, как следствие, к ухудшению результатов проектов. Гибкие методологии акцентируют внимание на создании ценности для клиента и позволяют за счет регулярных итераций и интенсивного, структурированного взаимодействия с заказчиком создавать готовые к использованию продукты.В связи с разнообразием методологий, методов и инструментов управления проектами ключевой задачей проектного управления является обоснованный выбор наиболее подходящих из них для конкретного проекта [1, 2, 34]. Для выявления наиболее востребованных методов и инструментов гибкого управления, а также целей организаций различных отраслей, осуществляющих Agile-трансформацию, автором был проведен анализ отчетов об исследовании Agile-трансформации в России «Agile в России 2020» [3] и за рубежом «The 15th annual state of Agile report » [4], а также источников [5−7], что позволило сделать выводы о наиболее значимых тенденциях в данной области.Целью исследования являлась разработка алгоритма, позволяющего сделать обоснованный выбор методологии управления цифровыми инновационными проектами с учетом особенностей предприятия, команды, внедряемой технологии. Основные результаты исследованияСреди Agile-методов во всем мире доминирует Scrum и Россия − не исключение (см. рис. 1). В общемировом исследовании доля Scrum очень высока и довольно стабильна: по состоянию на 2020 г. (58%). В России она несколько ниже, но все равно данный метод занимает лидирующее положение (41%). В России наблюдается повышенный интерес к гибридным методам, в частности, (18%) организаций используют собственные подходы, разработанные на базе нескольких стандартных методов [8−15]. За рубежом таких организаций существенно меньше (8%). Еще одним существенным отличием является усиление интереса российских компаний к методу Kanban (23%), особенно тех, которые уже давно практикуют Agile-подходы. В мире его доля всего лишь (5%).    Рис. 1. Востребованность Agile-методов управления проектами При анализе использования фреймворков масштабирования Agile в России отмечается высокая популярность собственных разработок (30%), в зарубежных компаниях их доля составила всего лишь (8%) (см. рис. 2). Устойчивым трендом является усиление интереса к SAFe (Scaled Agile Framework) как в российских (с 14 до 26%) , так и зарубежных компаниях (с 30 до 35%). SAFe − самый удобный фреймворк для запуска масштабирования в крупных организациях, «он позволяет перейти к Agile на уровне организации максимально безопасно, эволюционным, а не революционным путем» [3]. Далее следует SoS (Scrum of Scrums), востребованность других фреймворков масштабирования значительно ниже.Рис. 2. Востребованность фреймворков масштабирования AgileДалее были исследованы цели, которые ставят компании, осуществляющие Agile-трансформацию. Было выявлено, что они существенно отличаются в зависимости от сферы деятельности компании (см. табл. 1). Для ИТ-компаний − это возможность управлять меняющимися приоритетами и повышение качества продуктов. Для финансовых компаний − это повышение согласованности работы бизнеса и ИТ-структур, а также ускорение поставки продуктов на рынок. Для телекоммуникационных компаний – это увеличение прозрачности проектов и упрощение управления распределенными командами. Для промышленных и энергетических компаний – это управление изменениями и повышение производительности.Таблица 1Цели Agile-трансформации компаний различных отраслейЦели Agile-трансформацииИТ-компанииФинансовые компанииТелекоммуникационные компанииПромышленные и энергетические компанииВозможность управлять меняющимися приоритетами13 1Увеличение прозрачности проектов  13Ускорение поставки продуктов на рынок 2  Упрощение управления распределенными командами  2 Повышение мотивации команд    Повышение согласованности бизнеса и ИТ31  Повышение производительности    Увеличение предсказуемости поставок    Повышение качества продуктов2 32Улучшение инженерной культуры    Снижение проектных рисков    Сокращение стоимости проектов    Кроме того, следует отметить, что ожидаемые эффекты и статистика улучшений несколько отличаются друг от друга, как в лучшую, так и в худшую сторону. На рис. 3 представлена диаграмма, демонстрирующая это расхождение. Рис. 3. Цели и реальные достижения компаний, внедряющих AgileПо большинству целей реальность превосходит ожидание от Agile, за исключением проектных рисков, затрат и качества продукта. Это объясняется тем, что переход на новые методы ведения проектов − это достаточно затратная процедура, поэтому экономические эффекты наиболее явно проявляются в компаниях, которые уже имеют опыт использования подобных практик. Снижения проектных рисков отдельным организациям не удалось добиться из-за того, что, быстро реагируя на часто меняющиеся приоритеты, непросто уложиться в параметры изначального плана.Рис. 4. Барьеры при внедрении AgileЗаметны также отличия в факторах, препятствующих внедрению Agile в российских и зарубежных компаниях (см. рис. 4).  Наиболее значимыми барьерами при внедрении Agile в зарубежных компаниях являются: корпоративная культура, не приемлющая базовые ценности Agile, слабая поддержка со стороны руководства и сопротивление изменениям организации в целом. В России чаще всего указываются: недостаточный опыт в применении Agile-методов, низкая вовлеченность бизнеса в изменение процессов и неполное, непоследовательное применение Agile методов и практик, что существенно снижает положительные эффекты. Далее на основании проведенного исследования был предложен алгоритм, позволяющий оценить целесообразность использования той или иной методологии управлении проектами, выбрать наиболее подходящие методы и инструменты (см. рис. 5). По мнению автора, при выборе методов управления цифровыми проектами в организации необходимо проанализировать 3 группы факторов, позволяющих учесть: степень неопределённости, характеристики проекта и необходимость масштабирования. Рис. 5. Алгоритм выбора методологии управления цифровыми проектами 1 этап. Учет степени неопределенности в требованиях заказчика и способе реализации проектаДля учета степени неопределенности при выборе метода управления предлагается использовать матрицу Стейси [16, 17] (см. рис. 6). Она имеет две оси, соответствующие степеням определенности в отношении технологий и в отношении результата. Предпосылками для перехода к Agile должны стать высокая неопределенность целей проекта, выраженная в неопределенности требований заказчика, и высокая неопределенность путей достижения поставленных целей. По оси ординат измеряется «неопределенность в реализации». Чем выше, тем труднее найти верный подход к созданию продукта. По оси абсцисс измеряется «неопределенность в требованиях». Объектами являются сами IT-решения. Чем правее, тем сложнее выявить правильные требования клиента. Выделенные на рис. области соответствуют «доменам по теории запутанности, известной как Cynefin Framework. Эта теория делит все системы на четыре домена по степени неопределенности» [18].Упорядоченные простые системы. У команды проекта имеется четкое представление о том, какой продукт и каким способом предполагается разрабатывать. Используется водопадная методология управления проектом.Упорядоченные сложные системы.  Заранее не совсем понятно, как решать проблему. Задача не уникальна, но опыта работы у команды нет. В этом случае используются стандарты Prince2 и PMBoK, P2M и другие лучшие практики.Неупорядоченные сложные системы. В связи с тем, что они включают множество факторов с неоднозначными причинно-следственными связями, изначально достаточно сложно предложить подход к решению подобных задач, поэтому используются гибкие методологии.Хаотичные системы.  Предполагают решение абсолютно новых задач, которые никто никогда ранее не решал. Используются новые методы, которые могут полностью отличаться о ранее известных. Рис. 6. Матрица Стейси Чтобы определиться какие методологии следует использовать для того или иного проекта, необходимо разместить их на данной матрице. Таким образом, гибкие методологии используются, когда: необходимо разработать инновационный продукт; необходимо усовершенствовать и модернизировать процесс с высокой неопределенностью; происходит работа с заказчиком, у которого «размытые» требования.             2 этап. Первичная оценка применимости гибкой методологииВо многих случаях гибкие методы облегчают реализацию проекта, обеспечивая быстрое и прозрачное взаимодействие проектной команды, повышая скорость реализации и удовлетворенность заказчиков. Однако если для применения Agile был выбран неподходящий проект, либо команда является недостаточно подготовленной к новому подходу, использование Agile оборачивается негативным опытом. В связи с этим на следующем этапе целесообразно провести первичную оценку применимости гибких подходов с использованием критериев, представленных в табл. 2, отсеяв те, которые совсем не подходят для использования Agile. Таблица 2Критерии готовности проекта к применению гибких подходовФакторыНужна гибкая разработкаНужны классические методыПродукт Продукт создается в условиях высокой неопределенности, изначально сложно предложить подход к решению поставленной задачиВысокий уровень определенности требований к продукту, отсутствие ценности в поэтапном выпуске версий продуктаИтерации Для продукта возможна итеративная разработка. Выгоден поэтапный выпуск версий продукта в кратчайшие сроки, заказчик готов инвестировать в доработку версий продуктаИмеются причины технологического, организационно-управленческого или финансового характера, а также репутационные или законодательные барьеры, препятствующие поэтапному выпуску продукта, либо невозможно менять созданный продуктКритичность продукта Выпуск новых версий продукта без исчерпывающего тестирования не влечет за собой существенные риски, может быть осуществлена доработкаОтсутствует возможность регулярно, быстро и с должной степенью безопасности вводить в эксплуатацию новые версии готового продукта. Требуется тщательная, всесторонняя проверка на наличие рисков для функционирования компанииКоманда проектаВ компании имеется своя команда специалистов, с необходимыми компетенциями для разработки цифрового продукта, либо специалисты подрядчика работают под оперативным управлением заказчика. Специалисты команды компании или специалисты подрядчика заняты на нескольких проектах одновременно.    3 этап. Разработка Паттерна проектаЕсли проект соответствует первоначальным критериям, то можно переходить к следующему инструменту, позволяющему определить, насколько сложен проект и решить, какая именно из методологий подходит наилучшим образом. На основании анализа источников [19, 20] был разработан методический подход, позволяющий формировать Паттерны цифровых инновационных проектов. Далее выбор методологии зависит от бальной оценки сложности проекта. 4 этап. Оценка целесообразности масштабирования для организацииБывают проекты, которые не могут быть реализованы небольшими командами по 5-9 участников, тогда в них принимает участие сразу несколько рабочих групп и возникает потребность в масштабировании. Наиболее известными фреймворками масштабирования являются SAFe, LeSS, Nexus [21, 22]. Они основаны на структуре Scrum и используют множество его инструментов. Основное различие между фреймворками масштабирования и Scrum заключается в добавлении интеграционной группы, которая занимается организацией и координацией зависимостей и проблем интеграции между командами. В табл. 3 представлено сравнение выбранных методов по ключевым параметрам. Однако следует отметить, что даже в случае, если организация в отдельных подразделениях добилась успеха в использовании Agile-методов, у нее могут возникнуть трудности при попытке масштабировать их на другие подразделения. Таблица 3Сравнительный анализ фреймворков масштабированияПараметры / МетодологииSAFeLeSSNexusМасштабируемостьДоступны различные конфигурации, масштабируемые от уровня команды до портфеля. Ориентирована на крупные предприятияВ зависимости от количества команд доступны два типа фреймворка. LeSS поддерживает 2-8 команд, а LeSS Huge 8 и более командВ основном поддерживает 3-9 команд, но Nexus+ может применяться более чем для 9 командРазмер организацииКрупная Средняя или крупнаяМалая или средняяПоддержка внедренияScrum, Kanban, другие Agile методологии ScrumScrumСтоимость внедренияВысокаяСредняяНизкаяДетализация и уровень поддержкиВысокаяСредняяНизкаяПопулярностьВысокаяСредняяНизкаяНаличие тренингов Многоуров­невые тренинги и сертификацияЕсть сеть тренингов и сертифициро­ван­ных специалистов по внедрениюЕсть тренинги исертификация “Scaled Professional Scrum”РискиДля качественного внедрения чаще всего требуется сертифициро­ван­ный специалист, недостаточно информации об особенностях внедренияРадикальный гибкий метод, который может быть сложно реализовать в организациях с большим количеством уровней структуры и спецификиНовый подход, который развивается и адаптируется. Некоторые части выдаются только на тренингеВоздействие на оргструктуру организацииВоздействует на сложившуюся организационную структуру. Изменяются роли участников, уровни взаимодействия и отдельные процессы.Происходит упрощение организационной структуры, предполагающее ликвидацию определенных ролей и бизнес-процессов.Происходит реструктуризация локальных направлений деятельности, ролей и процессов. Но не затрагивается основная оргструктура. 5 этап. Использование гибридной методологииРеализация гибридного подхода осуществляется как на уровне методологий, так и на уровне конкретных методов и инструментов. Поэтому, в случае если проект является достаточно сложным, целесообразно использование гибридной методологии, синтезированной на основе существующих решений, включающей методы, инструменты и практики, учитывающие особенности конкретной организации, команды, проекта.Примерами методов в рамках гибридной методологии являются Agile/ Waterfall, Scrumban, Scrum/XP, а также различные гибриды, созданные на базе нескольких методов [23, 24]. В частности, Agile/Waterfall позволяет в крупных интеграционных проектах, где представлено несколько направлений работ, осуществлять высокоуровневое планирование, выстраивать иерархическую структуру работ (WBS) в соответствии с водопадной методологией, а отдельные направления WBS, связанные с разработкой и выпуском различных компонентов продукта, реализовывать в соответствии с Agile [25].Как было отмечено ранее, в России наблюдается повышенный интерес к использованию гибридной методологии. Компании разрабатывают собственные методы, базирующиеся на практиках нескольких стандартных методов. Для формирования уникального метода на основе уже существующих решений необходимо сформировать перечень критериев сравнения методов, соответствующий особенностям проекта [26−31]. К таким критериям также можно отнести: степень участия заказчика в процессе разработки; наличие строгого регламента соблюдения условий труда; необходимость тестирования программного продукта; наличие руководителя проекта как роли; размер команды; ограничения по времени; необходимость частой смены версий; степень адаптивности к новым требованиям; необходимость объемного документирования результатов и др. [32, 33].Далее необходимо: формализовать оценку с использованием балльной шкалы; сделать сравнительный анализ методов на основании выбранных критериев; выявить недостатки использования стандартных методов для реализуемого проекта; выбрать те практики и инструменты, которые максимально подходят для решения поставленных задач. ВыводыИспользование представленных инструментов на этапе выбора методологии управления цифровым инновационным проектом позволит сделать этот выбор более обоснованным, исключить дальнейшие финансовые и временные затраты, связанные с применением неэффективных методов и практик, а также повысить эффективность работы проектных команд и качество разрабатываемых цифровых продуктов. Существующие методы и инструменты управления полностью раскрывают свой потенциал только тогда, когда они полностью удовлетворяют требованиям проекта. В противном случае их использование приводит к возникновению издержек, связанных с необходимостью выполнения ряда ненужных практик, применение которых ведет к трате лишних ресурсов и падению эффективности команды. Предложенный алгоритм, а также выводы и рекомендации, полученные автором, могут быть использованы организациями при формировании системы гибкого управления цифровыми инновационными проектами.