12 методов управления проектами

Ниже — 12 подходов, в одном порядке, с практическими подсказками, как их прикрутить к реальной работе. Если хочется расширить базу, в блоге 101 есть опорные материалы: «Основы управления проектами для предпринимателя» и «Как выбрать систему управления проектами».

1. Agile

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

Для планирования короткого цикла заранее определите, какой законченный результат команда покажет к его концу. Например, можно обсудить результат на ближайшую неделю и условия его проверки. Приёмка, оплата и запуск в работу зависят от вида проекта и договорённостей; сами по себе они не определяют, используется ли Agile.

Важная деталь: Agile держится на дисциплине прозрачности. Что сделано, что в работе, что блокирует движение, какие изменения в объеме согласованы, какие еще обсуждаются. Для стройки и ремонта можно отдельно обсудить применимость коротких циклов к конкретному объекту с учётом технологии работ и договорённостей об изменениях. Про это есть отдельный материал «Agile в строительстве».

2. Waterfall (Водопад)

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

При выборе Waterfall проверьте, насколько заранее определены требования и какова цена поздних изменений. Инженерный объект, регламентированный проект или внедрение с фиксированным объёмом можно рассматривать как примеры для такой оценки. До начала работ согласуйте требования и порядок пересмотра плана.

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

3. Scrum

Scrum — фреймворк из Agile-семейства, где команда работает спринтами фиксированной длительности — не более одного месяца. На входе есть бэклог задач, в конце спринта команда показывает инкремент — законченный кусок продукта или сервиса.

В Scrum важны роли. Product Owner отвечает за приоритеты и ценность результата, Scrum Master держит процесс и помогает убирать препятствия, команда делает работу и отвечает за качество. Еще важны события: планирование спринта, ежедневная синхронизация, обзор результата, ретроспектива.

Scrum дает эффект, когда команда умеет резать работу на маленькие проверяемые результаты и реально приносит поставку каждую итерацию. Если спринт закрывается «почти готово», Scrum становится ритуалом отчетности.

4. Канбан

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

Ключевой принцип — ограничение WIP (work in progress): сколько задач можно держать в работе одновременно. Это срезает параллельность, которая часто выглядит как «все заняты», при этом сроки сдвигаются, качество проседает.

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

5. Scrumban

Scrumban сочетает элементы Scrum и Канбана. Конкретный набор правил команды различается: важно заранее согласовать ритм планирования, порядок приоритизации, визуализацию потока и ограничения незавершённой работы.

Для команды с проектными задачами и срочными запросами можно обсудить такой рабочий вариант: сохранить регулярное планирование и приоритизацию, а порядок принятия новых задач согласовать через явные правила и WIP-лимиты. Это пример адаптации для обсуждения; он не задаёт единственную обязательную форму Scrumban.

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

6. PRINCE2

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

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

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

7. Шесть сигм

Шесть сигм — подход к улучшению процессов через снижение вариативности и дефектов. Его часто связывают с производством, при этом в сервисных компаниях он тоже работает: там дефектом становится ошибка в данных, срыв SLA, повторная работа, перерасход времени на согласования.

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

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

8. Метод критического пути

Метод критического пути (CPM) — техника календарного планирования, которая помогает найти цепочку задач, определяющую расчётную длительность проекта. В рассматриваемой сетевой модели критические работы имеют нулевой резерв времени. При неизменных остальных условиях увеличение длительности такой работы сдвигает расчётную дату окончания проекта.

CPM начинается с сетевой модели: задачи, длительности, зависимости. После расчета видно, какие работы имеют резерв (float), а какие находятся на критическом пути. Это мощно в стройке, монтажах, запуске объектов, где много связей и ожиданий.

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

9. Управление проектами по методу критического пути

Когда CPM становится методом управления, он перестает быть разовым расчетом и превращается в рабочий цикл: план → расчет критического пути → контроль факта → пересчет → управленческие решения. Тут важно, кто обновляет план, кто подтверждает факт выполнения, кто принимает решения по перепланированию.

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

Базовая схема внедрения может выглядеть так:

1. Разбить проект на работы и результаты (WBS) так, чтобы факт выполнения можно было принять.
2. Проставить зависимости и оценить длительности, сразу отмечая допущения.
3. Посчитать критический путь и резервы, выделить узкие места.
4. Задать ритм обновления факта (по дням или по неделям) и правила перепланирования.
5. Фиксировать изменения объема и их влияние на сроки и деньги.

10. Методология рационального управления (Lean)

Lean — подход про ценность для клиента и устранение потерь: лишних перемещений, ожиданий, переделок, лишних согласований, запасов «на всякий случай». В проектах Lean проявляется в попытке выстроить поток без пробок и пересборок.

Типовые ремонты, серийные объекты, регулярные услуги и запуск филиалов по шаблону можно взять как примеры процессов для поиска потерь. Исследуйте, где возникают ожидания, переделки или лишние согласования, и проверяйте изменения на фактических данных.

Риск Lean в проектной среде — перегнуть в оптимизацию там, где нужна вариативность. Если задача творческая или исследовательская, часть «лишних действий» дает обучение и снижает вероятность промаха. Lean тут требует аккуратности: резать хаос, сохранять обучение.

11. Руководство PMBOK® Института управления проектами

PMBOK® — не «метод, который внедрил и полетел», это свод знаний и практик по управлению проектами. Он помогает структурировать управление через области: сроки, стоимость, риски, закупки, качество, коммуникации, стейкхолдеры.

В PMBOK® ценна идея адаптации (tailoring): выбирать практики под контекст проекта. Проект на 3 недели и проект на год требуют разной глубины планирования, контроля и документации, при этом управленческие вопросы одинаковые: цель, объем, сроки, бюджет, риски, приемка.

Если хочется «приземлить» PMBOK® на ежедневную работу, начните с базовых артефактов: устав/цель проекта, структура работ, календарный план, бюджет, реестр рисков, процесс управления изменениями. Это дает скелет, дальше наращивается мясо.

12. Экстремальное программирование (XP)

XP — набор инженерных практик разработки, заточенных под быстрые изменения и стабильное качество. Это подход из софта, при этом полезная мысль применима шире: качество надо строить в процесс, а не ловить в финале.

В XP много практик про короткую обратную связь: разработка через тесты (TDD), частая интеграция изменений, рефакторинг, парное программирование, маленькие релизы. В итоге команда снижает риск «мы месяц делали, потом все сломалось».

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

Как выбрать метод под задачу?

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

Пара практичных проверок, которые помогают быстро сузить выбор:

• Если успех зависит от точной цепочки зависимостей — смотрите в сторону CPM/Ганта и регулярного пересчета плана.
• Если успех зависит от частой поставки результата — пригодятся Agile/Scrum и короткие итерации.
• Если успех зависит от стабильного потока входящих задач — начинайте с Канбана и WIP-лимитов.
• Если успех зависит от управленческого контроля и отчетности — присмотритесь к PRINCE2 и PMBOK® как базе процессов.

Для практической работы полезно связать план проекта с данными о деньгах и документах. В 101 для этого есть проектный финансовый контур: поступления, расходы, подтверждения, отчеты, аналитика. Для погружения можно начать со статей «Проектный учёт без узкого горлышка» и «Как управлять бюджетом проекта в Приложении 101».

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

Когда проектов становится больше, руководителю важно отдельно рассматривать сравнение объектов, общие расходы и устойчивость бизнеса в течение сезона. Для работы с финансами компании в PRO+ предусмотрены «Фонд компании» и инструменты распределения прибыли между участниками; детали зависят от действующих условий сервиса.