Методология управления проектами: как выбрать подход

В статьях о методологиях управления проектами обычно десять-двенадцать пунктов: Waterfall, Agile, Scrum, Kanban, Lean, PRINCE2, шесть сигм, метод критического пути, диаграмма Ганта. Читатель честно пытается выбрать из двенадцати и не может, потому что выбирать между диаграммой Ганта и Scrum — как выбирать между линейкой и планом дома. В списке вперемешку стоят вещи разного уровня. Если их разложить, выбор сужается до трёх подходов и их сочетания, и делается по двум вопросам, а не по моде.

Методология, фреймворк, стандарт и метод — не одно и то же

Подход отвечает на главный вопрос: планируем всё сразу или по частям. Фреймворк — конкретный набор правил, как работать внутри подхода: роли, встречи, артефакты. Стандарт описывает, что вообще входит в управление проектом, и подходит к любому подходу. Метод планирования — инструмент, которым считают срок или рисуют план.

Когда говорят «методология управления проектами», почти всегда имеют в виду первые две строки, иногда с фреймворком: «у нас Scrum». Дальше речь о подходах.

Три подхода и их сочетание

Каскадный

План составляют целиком до начала работы: что делаем, в каком порядке, к какому сроку, за какие деньги. Этапы идут один за другим, результат заказчик видит в конце. Изменения возможны. Но дороги: каждое требует пересмотреть план, смету и срок. Подходит, когда результат известен заранее и меняться не будет: строительство по проекту, сайт по утверждённому макету, внедрение по готовому техническому заданию. Каскадную модель управления проектами ещё называют водопадной.

Итеративный

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

Поток задач

Циклов нет. Задачи приходят по одной, встают в очередь на доске и проходят по колонкам от «Новая» до «Готово». Главное правило — не брать в работу больше, чем команда успевает закончить. Подходит для поддержки, сопровождения и любой работы, где задачи непредсказуемы и мелкие. Канбан-доска — инструмент этого подхода.

Гибридный

На практике чаще всего встречается сочетание: верхний план с этапами и сроками по каскаду, а внутри этапов — короткие циклы. Или итерации с жёстким лимитом бюджета сверху. Гибридное управление проектами — нормальный выбор, а не компромисс от неумения выбрать: так устроено большинство заказных проектов.

Agile и Waterfall: в чём на деле разница

Спор «Agile или Waterfall» обычно идёт о вкусах, хотя разница простая и про деньги. При каскадном подходе фиксируют объём работ, а срок и бюджет из него вычисляют. При итеративном фиксируют срок цикла и бюджет, а объём каждый раз решают заново. Заказчик в первом случае знает, что получит, и платит за риск ошибки в оценке. Во втором — знает, сколько потратит за месяц, и решает, на что.

Отсюда и то, когда заказчик видит результат. При каскаде — в конце этапа или проекта, при итерациях — каждые одну-четыре недели. Если заказчику важно увидеть результат рано и поправить курс, каскад его разочарует, даже если план будет выполнен точно.

Как выбрать: два вопроса

Можно ли описать результат заранее? Не «хотим удобный сайт», а макеты, список функций, техническое задание, которое заказчик готов подписать. Если да, план целиком реален. Если результат будет уточняться, подробный план на полгода устареет через месяц.

За что платит заказчик? За результат по смете или за часы работы. Фиксированная цена требует зафиксированного объёма, иначе каждое изменение превращается в спор. Оплата по часам совместима с итерациями: заказчик решает, на что потратить следующий цикл.

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

Пример: два подхода в одной практике

В начале 2023 года наш руководитель проекта два месяца вёл три интернет-магазина digital-агентства. Магазины развивались по заявкам клиентов, и результат каждой недели становился понятен только к её началу. Работали недельными спринтами: по пятницам руководитель проекта с клиентом решал, что брать дальше, с тимлидом оценивал спринт в часах. Клиенты платили за часы, у каждого проекта был месячный порог, и когда работа подходила к нему, клиент решал, продолжать или отложить. Это гибрид: итерации внутри, лимит бюджета сверху.

У агентства RedLoft мы с мая 2024 года ведём, среди прочего, поддержку сданных сайтов. Там нет ни спринтов, ни плана на месяц: задачи приходят по одной, проходят по доске со статусами, задача в тестировании сама назначается на тестировщика. Время отмечают в трекере, и клиент каждый месяц получает отчёт с часами по направлениям. Это поток задач в чистом виде, и спринты здесь только мешали бы: нельзя планировать на неделю то, что сломается в среду.

Одна методология на компанию?

Нет. И пытаться не стоит. Разработка сайта, развитие магазина и поддержка в одной компании идут по разным подходам, потому что у них разные договоры и разная предсказуемость. Общими должны быть другие вещи: как проект запускают, в каком виде отчитываются, как принимают изменения и как закрывают. Об этих договорённостях — в статье о процессах управления проектами и в хабе направления. Сами правила работы удобно записать регламентом.

Если подход нужно выбрать для конкретного проекта и некому его вести, это можно сделать с руководителем проекта со стороны: он начинает с того, как устроены договор и команда, и только потом предлагает правила.

Как понять, что подход не работает

При каскадном план переписывают каждую неделю. Значит, результат на самом деле не был описан, и неясную часть лучше перевести на итерации.

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

При потоке задач доска растёт быстрее, чем пустеет, и срочное вытесняет всё остальное. Не хватает лимита на работу в процессе или приоритетов.

При любом изменения происходят без решения: срок сдвинулся сам, бюджет вырос сам. Методология тут ни при чём: не хватает договорённости об изменениях, и её придётся завести при любом подходе.