Классическое проектное управление (Prince2, PMBoK) опирается на качественное планирование, контроль и управление изменениями различных аспектов проекта [1].  Оно требует высокой квалификации и достаточного временного ресурса руководителя проекта, а также следования достаточно тяжелым процессам проектного управления со стороны руководителей и сотрудников организации. Так как такие условия в организации сложно создать, требования к процессам управления проектами часто оказываются избыточными и невыполнимыми на должном уровне качества, что приводит к замедлению принятия решений, бюрократизации без достижения ожидаемого эффекта, слабой вовлеченности и незаинтересованности членов проектных команд в итоговом результате проектов. Вместе с тем, проектное управление обеспечивает высокий уровень управляемости и прозрачность хода работ, качественную работу со сроками и рисками проекта.Методы Agile фокусируют внимание на создании ценности для клиента за счет быстрых итераций, завершающихся поставкой продукта, пригодного к использованию, вовлечение заказчика и команды проекта [2], в том числе за счет интенсивной структурированной коммуникации (SCRUM) [3] и постоянного совершенствования процессов и организации работ (Kanban) [4]. Но при реализации проектов с большим количеством участников, команд, технологически и хронологически связанными блоками работ требуются другие инструменты, например, фреймворки масштабирования Agile (SAFe, Less и др.), которые сложны во внедрении и не гарантируют достижения требуемого результата проектов в нужные сроки. Также гибкие методы могут быть рискованными или недостаточно живучими для временных команд с переменным процентом участия исполнителей на различных этапах проекта. Такой интеграционный подход принято называть гибридным методом.Ключевыми задачами метода являются:– создание ценности для организации и заказчика;– выполнение проектов в срок;– снижение зависимости от квалификации и загрузки руководителя проекта;– проактивная работа с проблемами и рисками;– обеспечение вовлеченности и ответственности за результаты как команды на протяжении всего проекта, так и функциональных руководителей и высшего руководства. Основные положительные и отрицательные стороны интегрируемых методов сведены в табл. 1.Таблица 1 Плюсы и минусы методов управленияМетодыПлюсыМинусыУправление проектамиЦентрализованный контроль.Управление сроками и рисками.Управление по отклонениямБюрократизация и избыточный формализм.Потеря актуальности детальных планов.Невовлеченность команды в дела проектаAgile-методыВысокая вовлеченность команды.Децентрализованное принятие решений.Быстрые итерациии учет обратной связи. Слабое управление сроками и рисками.Потеря контролядля сложных проектов. Низкая эффективность для временных команд и мультипроектного режима работы.Метод может подойти для организаций, которые реализуют организационные, инфраструктурные, технологические и ИТ-проекты, проекты в области операционной эффективности, выводят на рынок новые продукты, оказывают комплексные услуги, например, консалтинговые. При этом проекты необходимо реализовать в заданные сроки в условиях высокой неопределенности и изменчивости требований.Критерии применимости метода включают продукт, требования и команду. При этом продукт и требования – основные критерии, команда – вспомогательный критерий. При выполнении основных критериев метод целесообразно применять. В случае, если выполняется дополнительный критерий, эффект от использования метода будет максимальным. Ограничения по применению для проектов и организаций различного размера отсутствуют. Гибридный метод опирается на известные практики в области управления проектами и Agile, обеспечивает их совместимость, описывает условия применения.Максимальный эффект может быть достигнут при их совместном использовании. Однако, выбор конкретных практик – ответственность руководителя проекта или архитектора системы управления проектами.Критерии применимости метода описаны в табл. 2. Таблица 2 Критерии применимости гибридного управленияКритерийГибридный методAgileУправление проектамиПродуктМасштаб и связиФинальный продукт проекта состоит из нескольких элементарных продуктов. Работы зависимы друг от друга по срокамПродукт охватывает одну предметную область, связи между элементами минимальны, синхронизация работ отдельных подразделений по срокам проста либо непринципиальнаСложный многокомпонентный продукт, есть взаимосвязи между элементами, необходима синхронизация работ по срокам  Делимость(гибкость содержания)Деление продукта на элементы приводит к существенному росту совокупных затрат или снижению ценности для клиентаВысокая делимость продукта на элементы, функции или свойства, поставляемые заказчику без радикального увеличения стоимости продуктаНизкая делимость, резкий рост стоимости либо снижение ценности продукта при делении на элементыРиски, связанные с несовершенством продуктаНеудачный запуск финального продукта крайне опасен для организацииНизкийСредний и высокийТребованияСвоевременностьДостижение целевых сроков и / или снижение сроков получения продукта проекта является критичным условием успеха или выживания Важно делать как можно быстрее, конкретные сроки могут быть желательны, но не принципиальныВажно дать результат в нужные срокиОпределенностьОпределены верхнеуровневые требования к сборному продуктуОпределены верхнеуровневые требования к сборному продукту, требования к элементам продукта определяются по ходу реализацииОпределены, уточняются по ходу проекта, серьезные изменения требуют формализованного управления изменениямиДоступность заказчикаЗаказчик или его представитель ограниченно доступны, но готовы участвовать в проектеЗаказчик доступен для постановки требований и демонстрацийЗаказчик ограниченно доступенКомандаЗрелостьСредняя или высокая ротация членов команды, низкая зрелостьВысокая зрелость, низкая ротацияНепринципиальноВыделенностьПеременное участие, занятость в проекте – 10–50%, выделение сотрудников на полную занятость невозможно или неэффективноВыделенность членов команды – 80–100%НепринципиальноПостоянствоВременная команда, срок жизни от 3 до 18 мес.Стабильная командаВременная команда Гибридный метод предполагает следование следующим принципам:1. Экономическая ценность при разумных рисках. Старт и продолжение проекта должны основываться на постоянной проверке экономической ценности и рисков. 2. Итеративная поставка результата в срок: с периодичностью, заданной длиной итерации. Клиент или его представитель должен получать наглядное подтверждение соответствия продукта проекта его требованиям и его готовности покупать данный продукт или услугу.3. Разумная гибкость требований. Гибкость требований позволяет быстро реагировать на изменение внешней среды или учитывать мнение клиента. В случае, если изменения существенно влияют на результат или параметры проекта, то они должны быть согласованы ключевыми участниками и заинтересованными сторонами или, в крайнем случае, доведены до них.4. Ритмичный процесс и постоянная коммуникация. Процесс управления проектом должен быть построен на ритмичных событиях, позволяющих планировать, контролировать и корректировать действия проектной команды и реагировать на изменения ситуации. 5. Адекватная децентрализация принятия решений. Все решения, которые могут быть делегированы отдельным членам команды, должны быть делегированы. При этом централизованное принятие решений необходимо в ситуациях, связанных с высокими рисками для организации. Таким образом, чтобы усилить плюсы упомянутых методов и компенсировать их недостатки, предлагается сбалансированный набор инструментов и практик. Он должен помочь снизить уровень бюрократии, но при этом сохранить необходимый контроль и вовлеченности команды за счет структурированной коммуникации и системы принятия решений по проектам. Метод позволяет совместить гибкость Agile и системность, предсказуемость и прозрачность, которые дает управление проектами.