Инструменты методики АЦТ, часть 13: гибкая методология (Agile/Scrum), PRINCE2 и свод знаний по управлению проектами (PMBOK)

Это тринадцатая статья цикла по инструментам методики «Аккордная цифровая трансформация». Завершаем подгруппу B1 «Базовые методологии управления» — инструменты B1-05, B1-06 и B1-07.

Статья закрывает подгруппу B1. Разберем три способа вести проект, расположенных в порядке от адаптивности к жесткой структуре. Гибкая методология (B1-05) ведет проект короткими итерациями и подстраивается под меняющиеся требования. PRINCE2 (B1-06) дает противоположное — строгий контроль и документацию на всем пути. Свод знаний PMBOK (B1-07) стоит над методами как общий язык и справочник практик. По трудоемкости это самые тяжелые инструменты подгруппы: 36 часов у Agile/Scrum (сложный), 60 у PRINCE2 и 74 у PMBOK (оба — очень сложные).

B1-05 — Гибкая методология (Agile / Scrum)

Откуда появился инструмент. Само слово «scrum» в управление пришло из статьи 1986 года: японские исследователи Хиротака Такэути и Икудзиро Нонака опубликовали в Harvard Business Review работу «The New New Product Development Game», где сравнили эффективные продуктовые команды в Honda, Canon и Fuji-Xerox с командой регбистов, которая движется к цели единым слаженным составом. Фреймворк Scrum на этой идее построили в начале 1990-х Джефф Сазерленд и Кен Швабер: первое внедрение Сазерленд провел в 1993 году в компании Easel, а в 1995-м вместе со Швабером представил доклад «The SCRUM Development Process» на конференции OOPSLA. Более широкое движение оформилось в феврале 2001 года, когда семнадцать разработчиков собрались в Сноуберде (штат Юта) и подписали Agile-манифест — четыре ценности и двенадцать принципов гибкой разработки. Scrum старше манифеста, но стал его самым известным воплощением.

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

Границы применимости. Agile/Scrum оправдан в проектах с меняющимися или неясными на старте требованиями, где важны скорость и обратная связь, — в разработке ПО, новых продуктах. Там, где требования стабильны, а нужны предсказуемость и документация, ближе водопадная модель (B1-04). По методике это сложный инструмент (36 часов): он требует зрелой, самоорганизующейся команды и вовлеченного заказчика; формальное внедрение по обряду, без культуры, дает имитацию. Для масштабирования Agile на много команд используют отдельные подходы (SAFe, B3-06).

Чек-лист перед применением Agile/Scrum:

• Требования на старте неполны или будут меняться — гибкий подход уместен.
• Заказчик готов участвовать постоянно: давать обратную связь после каждого спринта.
• Сформирована небольшая кросс-функциональная команда, способная к самоорганизации.
• Определены роли и события Scrum (спринты, демонстрации, дейлики) и длина спринта.
• Работа разбита на этапы, каждый из которых дает проверяемый результат.
• Команда готова отсеивать ненужное и менять приоритеты по итогам итераций.

Типовые ошибки:

• Agile по обряду. Внедряют дейлики и спринты, но не дают команде свободы и обратной связи. → Менять не только церемонии, но и культуру: самоорганизация, участие заказчика.
• Заказчик вне процесса. Гибкий подход выбрали, но заказчик не участвует, обратной связи нет. → Обеспечить постоянное участие заказчика после каждого спринта.
• Agile там, где нужен план. Гибкость применяют к проекту с фиксированными требованиями и жесткими сроками. → Для стабильных требований выбирать предсказуемую модель (B1-04).
• Итерации без результата. Спринты идут, но проверяемого приращения нет. → Завершать каждый спринт работающим инкрементом, а не «работой в процессе».

B1-06 — Проекты в контролируемых средах (PRINCE2)

Откуда появился инструмент. PRINCE2 родом из Британии. Его прародитель — метод PROMPT, созданный частной компанией Simpact Systems в 1975 году как ответ на срывы сроков и бюджетов в компьютерных проектах. В 1989 году британское государственное агентство CCTA адаптировало его и переименовало в PRINCE: сначала аббревиатура расшифровывалась как «PROMPT II в среде CCTA», позже ее переосмыслили как «Projects IN Controlled Environments» — проекты в контролируемых средах. Тот PRINCE был заточен под ИТ-проекты и считался слишком жестким. В 1996 году при участии около 150 европейских организаций выпустили PRINCE2 — универсальный метод для проектов любого типа. В 2009 году его доработали, добавив семь новых принципов.

Суть и механика. PRINCE2 — структурированный метод управления проектами, в основе которого постоянный контроль на всем пути от старта до завершения. Проект делят на управляемые этапы, каждый тщательно планируют до начала работ, четко распределяют роли и процессы и быстро реагируют на отклонения от плана. Характерная черта — постоянное документирование: все рабочие процессы фиксируются, отчего возникают большие объемы документации. Метод отвечает на вопросы: кто ответственный и за что, что делается на каждом этапе и как контролируется результат, и силен именно дисциплиной и управляемостью.

Границы применимости. PRINCE2 оправдан на крупных, сложных или регулируемых проектах, где критичны контроль, прозрачность и отчетность, — в госсекторе, ОПК, инфраструктуре. Для небольших и быстрых проектов он избыточен: накладные расходы на документацию и процессы не окупаются. По методике это очень сложный инструмент (60 часов). PRINCE2 описывает, как управлять и контролировать, но не диктует технологию исполнения; его сочетают с гибкими подходами в гибридном варианте (PRINCE2 Agile). По духу он ближе к водопадной логике (B1-04): акцент на структуре и контроле, тогда как Agile (B1-05) делает ставку на адаптивность.

Чек-лист перед применением PRINCE2:

• Проект крупный или регулируемый: контроль, прозрачность и отчетность действительно нужны.
• Проект разбит на управляемые этапы с утверждением плана до начала каждого.
• Четко определены роли: кто принимает решения, кто исполняет, кто контролирует.
• Налажено документирование процессов и решений на всем протяжении.
• Задан порядок реагирования на отклонения: как фиксируют и кто решает.
• Оценено, не избыточен ли метод для масштаба проекта; при необходимости — тейлоринг.

Типовые ошибки:

• PRINCE2 для маленького проекта. Тяжелый метод берут для короткого простого проекта — документация исчерпывает ресурсы. → Соразмерять метод масштабу; для малых проектов упрощать или брать гибкий подход.
• Документация ради документации. Бумаги плодят формально, не используя для контроля. → Вести документы, которые реально нужны для решений и контроля.
• Жесткое следование без тейлоринга. Метод применяют буквально, не адаптируя под проект. → Использовать встроенный в PRINCE2 тейлоринг — подгонять под контекст.
• Контроль без сути. Соблюдают этапы и формы, но не управляют рисками и результатом. → Держать фокус на целях и обоснованности этапов, а не только на процедуре.

B1-07 — Руководство к своду знаний по управлению проектами (PMBOK)

Откуда появился инструмент. PMBOK выпускает американский Институт управления проектами (PMI), основанный в 1969 году. Свод знаний собирали постепенно: работа началась в 1981 году, в 1983-м вышел отчет комитета по этике, стандартам и аккредитации, в 1987-м — черновик свода знаний, а первое полноценное издание «A Guide to the Project Management Body of Knowledge» появилось в 1996 году. Дальше руководство переиздавали каждые четыре-пять лет: 2000, 2004, 2008, 2013, 2017 (шестое издание). Седьмое издание (2021) стало поворотным: PMBOK перешел от описания процессов к принципам и прямо признал гибкие и гибридные подходы наряду с традиционными.

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

Границы применимости. PMBOK полезен как справочник и общий язык в организациях с разнородными проектами и как база для профессии: на нем строится сертификация PMP. Это не пошаговая методология — по нему нельзя «вести проект», из него берут практики под свой подход. По методике это самый трудоемкий инструмент подгруппы (74 часа, очень сложный): объемный профессиональный стандарт. Классический PMBOK тяготел к предсказуемым процессным проектам и критиковался за тяжеловесность; седьмое издание сместило акцент на принципы и включило гибкие подходы (Agile, B1-05). PMBOK задает рамку, внутри которой живут и водопад (B1-04), и Agile, и PRINCE2.

Чек-лист перед применением PMBOK:

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

Типовые ошибки:

• PMBOK как методология. Пытаются вести проект строго по PMBOK, хотя это свод знаний, а не пошаговый метод. → Использовать как справочник: брать практики под свой подход.
• Все и сразу. Применяют все процессы подряд, перегружая небольшой проект. → Выбирать из свода только то, что нужно проекту по масштабу.
• Только традиционный взгляд. Считают PMBOK исключительно «водопадным», игнорируя гибкие подходы. → Учитывать, что седьмое издание включает Agile и гибридные методы.
• Знание без применения. Учат свод ради сертификата, но не используют практики в работе. → Превращать знания в реальные процедуры конкретных проектов.

Резюме

Каждый из трех инструментов силен на своем типе проектов и работает менее эффективно на чужом.

Agile/Scrum раскрывается на изменчивых требованиях и живом участии заказчика, но на фиксированном задании или без обратной связи вырождается в формальное соблюдение процедур без результата.

PRINCE2 дает контроль и прозрачность там, где высоки цена ошибки и требования к отчетности, а на небольшом проекте тонет в собственной документации.

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

У всех трех одна общая уязвимость: метод перестает работать, когда его внедряют формально, не адаптируя под конкретную задачу. Поэтому выбор всегда идет от самого проекта — от стабильности его требований, масштаба и нужного уровня контроля; это и определяет, какой подход сработает. 

В следующей статье цикла перейдем к подгруппе B2 «Визуализация и планирование» — инструментам, которые помогают увидеть проект и спланировать его, от диаграммы Ганта до метода критического пути.