Управление проектами превращает идею в управляемый процесс с целью, задачами, ответственными и сроками. Без системного подхода даже у сильной команды задачи теряются, сроки срываются, бюджет сливается, а виноватого за сорванный результат не найти. Методов управления много, и у каждого своя логика и своя область, где он эффективен. Универсального среди них нет, поэтому важно понимать не только как устроен каждый метод, но и для каких задач он подходит. Разберем основные методы и критерии выбора оптимального.
Какие бывают методы управления проектами
Методов десятки, но почти все их можно условно разделить на две группы. Предиктивный, или жесткий, требует спланировать все заранее и идти строго по плану. Гибкий исходит из того, что план будет меняться в процессе, и встраивает изменения в процесс как норму. Остальные методы либо примыкают к одному из лагерей, либо решают узкую задачу. Разберем пять самых применимых на практике.
Каскадный метод или водопад — Waterfall
Каскадный метод — это последовательность фаз, в которой каждая начинается только после того, как полностью закрыта предыдущая. Классический набор фаз выглядит так:
- сбор требований;
- проектирование;
- разработка;
- тестирование;
- внедрение и поддержка.
Результат каждой фазы становится стартом для следующей.
Метод применим в ситуациях, где требования известны заранее и не будут меняться. Строительство дома — классический водопад, поскольку нельзя делать крышу, пока не готов фундамент, и заказчик не передумает на полпути. По той же причине водопад любят в госконтрактах, производстве и проектах с жесткой документацией, где все согласовано до старта.
Сильная сторона метода — предсказуемость. С самого начала известны объем, сроки и бюджет, по нему легко отчитываться и контролировать. Слабая сторона в том, что готовый результат виден только в конце, и если требования изначально разработали неточно, ошибку обнаруживают на сдаче, когда переделка обходится очень дорого. Поэтому для проектов, где требования на старте туманны, водопад опасен.
Гибкий метод управления — Agile
Agile — это набор подходов к управлению работой, в которых основной акцент сделан на короткие циклы, регулярную проверку результата и быстрые изменения по ходу процесса.
В основе Agile лежат несколько ключевых идей:
- важнее прямое взаимодействие между людьми, чем формальные процедуры;
- важнее готовый и работающий результат, чем подробные документы;
- важнее постоянное взаимодействие с заказчиком, чем жестко зафиксированные условия;
- важнее гибкость и адаптация, чем строгое следование первоначальному плану.
Вместо детального планирования на длительный срок команда делит работу на короткие этапы. По завершении каждого этапа она получает готовый результат и может скорректировать дальнейшие действия на основе обратной связи.
Scrum
Самый известный фреймворк внутри Agile — Scrum. Работа в нем проходит спринтами по одной-четыре недели, и у каждого участника своя роль. Владелец продукта определяет приоритеты, решая, что важнее на текущий момент. Scrum-мастер следит за процессом, устраняя возможные сложности. Команда делает работу.
Все вращается вокруг:
- бэклога продукта, то есть общего списка задач;
- бэклога спринта, то есть задач на текущий отрезок;
- инкремента, то есть готового прироста результата.
Спринт обрамляют события — планирование в начале, короткие ежедневные пятнадцатиминутные планерки, обзор результата с заказчиком и ретроспектива, когда команда решает, что улучшить в следующем спринте.
Kanban
Другой популярный вариант — Kanban. Здесь нет спринтов, работа идет непрерывным потоком через доску с колонками «надо сделать», «в работе» и «готово». Ключевое правило Kanban — лимит на число задач в работе, чтобы команда не хваталась за все сразу и доводила до конца начатое. Основная метрика — время прохождения задачи от попадания на доску до завершения, и его стараются сокращать. Scrum удобнее, когда работу логично резать на фиксированные отрезки, а Kanban — когда поток задач неровный и приоритеты часто меняются.
Agile выигрывает, если требования меняются по ходу, что типично, например, для разработки ПО и запуска новых продуктов. Но он плохо ложится на проекты с жестко зафиксированными объемом, сроком и бюджетом одновременно.
Бережливое управление проектами — Lean
Lean вырос из производственной системы Toyota, и его главная идея — выжимать максимум ценности минимумом ресурсов, убирая буквально все, что эту ценность не создает.
Метод строится на пяти принципах:
- определить, что ценно для клиента;
- выстроить весь поток ее создания;
- обеспечить непрерывное движение без простоев;
- производить по реальному спросу, а не про запас;
- постоянно искать, что улучшить.
В основе лежит борьба с потерями. К потерям в Lean относят перепроизводство, простои и ожидание, лишнюю транспортировку, избыточную обработку, ненужные запасы, лишние движения людей и исправление брака. Команда анализирует поток создания ценности от заявки до результата и вычищает из него шаги, за которые клиент платить не готов. Отдельный принцип Lean — кайдзен, то есть небольшие, но постоянные улучшения силами самой команды.
Lean эффективен в процессах, где много повторяющихся операций, например, в производстве, логистике или обработке однотипных заявок. Там, где каждый проект уникален и не повторяется, отдача от него ниже.
Метод шести сигм — Six Sigma
Six Sigma нацелен на качество и борьбу с разбросом, чтобы результат был стабильным. Метод опирается на цифры и статистику и работает по циклу DMAIC:
- определяют проблему и цель;
- измеряют текущие показатели;
- анализируют причины отклонений;
- улучшают процесс;
- закрепляют результат.
Для совершенно новых процессов применяют родственный цикл DMADV, заточенный под проектирование с нуля.
Название отсылает к планке качества — не больше 3,4 дефекта на миллион операций. Специалистов в методе различают по поясам, как в единоборствах:
- желтый пояс знает основы;
- зеленый вводит улучшения в своей зоне;
- черный руководит сложными проектами;
- мастер черного пояса обучает остальных.
Подход тяжеловат для мелкой разовой задачи, зато незаменим там, где цена ошибки высока и важна повторяемость, например на производстве, в медицине или банковских процессах. Часто Six Sigma совмещают с Lean, и получается Lean Six Sigma — и потери убрали, и разброс снизили.
Метод критического пути — CPM (Critical Path Method)
CPM — инструмент управления сроками. Все задачи проекта выстраивают в сеть с учетом длительности и зависимостей, кто за кем идет, и находят критический путь — самую длинную цепочку связанных задач. Именно она определяет минимальный срок всего проекта, потому что любая задержка на ней сдвигает финал.
Разберем на примере. Допустим, в проекте есть задача А на три дня, за ней Б на пять дней и В на два дня, а параллельно идет независимая задача Г на четыре дня. Цепочка А — Б — В занимает десять дней, и это критический путь, а задача Г со своими четырьмя днями имеет запас в шесть дней. Этот запас называют резервом, и задачи с резервом можно немного двигать без вреда для сроков, а задачи на критическом пути двигать нельзя. CPM сразу показывает руководителю, за чем нужно пристально следить.
У метода есть близкие родственники. PERT добавляет к задачам три оценки времени — оптимистичную, пессимистичную и наиболее вероятную, чтобы учесть неопределенность. Метод критической цепи идет дальше и закладывает буферы времени и ограничения по ресурсам. Если по проекту жесткий дедлайн и много зависимых задач, CPM и его вариации помогают увидеть, когда возникают риски срыва срока.
Как выбрать метод под задачу
Решение принимают по следующим критериям:
- стабильность требований — если объем ясен и не будет меняться, подходит водопад, а если требования будут уточняться по ходу, нужен Agile;
- жесткость рамок — когда срок, бюджет и объем зафиксированы договором одновременно, гибкие методы не подходят;
- характер работы — для уникального разового результата берут проектные методы, а для повторяющегося потока операций сильнее Lean и Six Sigma;
- отрасль и регуляторика — в стройке, госзаказах и производстве используют жесткие методы с документацией, в ИТ и маркетинге — гибкие;
- зрелость команды — Agile требует самостоятельности и дисциплины, и неопытной команде без поддержки он дается тяжело.
В реальной работе компаний чистые методы встречаются редко, и чаще используются их комбинации. Популярный гибрид выглядит так — на верхнем уровне проект ведут водопадом с фиксированным бюджетом, а внутри каждого этапа команда работает гибко, спринтами.
Из каких этапов состоит каждый метод
Через одни и те же этапы проходит любой проект, каким бы методом его ни вели. Разница лишь в том, проходят их один раз подряд, как в водопаде, или повторяют по кругу в каждом спринте, как в Agile. Этих этапов пять.
Инициация
На этом этапе проект обосновывают и решают, стоит ли вообще за него браться. Формулируют цель, прикидывают выгоду и затраты, определяют заказчика, ключевых участников и границы того, что входит в проект, а что нет. Итог этапа — устав, или паспорт проекта, короткий документ, где записаны цель, рамки, бюджет верхнего уровня, сроки и критерии успеха.
Планирование
Цель раскладывают на задачи через декомпозицию — большую цель дробят на все более мелкие куски, пока каждый не станет понятным и оцениваемым. Дальше задачи выстраивают по срокам и зависимостям, считают бюджет и назначают ответственных. Иногда используют матрицу ответственности, в которой по каждой задаче видно, кто исполняет, кто отвечает за результат, с кем советуются и кого держат в курсе.
Здесь же составляют реестр рисков и закладывают запас на непредвиденное. Хороший план отвечает на вопросы, что делать, кто делает, когда и за какие деньги, и чем он тщательнее продуман, тем меньше рисков на этапе выполнения.
Выполнение
Команда делает то, что запланировано. Роль руководителя здесь не выполнять задачи за всех, а обеспечивать людей ресурсами, снимать препятствия, согласовывать спорные моменты и держать фокус на цели. На этот этап приходится большая часть бюджета и времени проекта.
Мониторинг
Контроль осуществляется параллельно выполнению, а не после него. Руководитель сверяет план с фактом по срокам, бюджету и качеству и реагирует на отклонения, пока они маленькие. Для денег и сроков удобен метод освоенного объема, который сравнивает три величины:
- сколько планировали потратить к этой дате;
- сколько потратили на самом деле;
- на какую сумму реально сделали работу.
Расхождение между ними сразу показывает, отстает проект или перерасходует бюджет. Отдельная часть мониторинга — управление изменениями, чтобы новые хотелки заказчика не ломали план, а проходили оценку влияния на сроки и деньги.
Завершение
Результат сдают заказчику, проверяют по критериям из инициации и закрывают проект — подписывают документы, рассчитываются с подрядчиками, передают результат в эксплуатацию. Отдельно проводят ретроспективу, разбирают, что прошло хорошо, а что нет, и фиксируют уроки в общем архиве. Этот разбор полезен, он не дает команде раз за разом наступать на одни и те же грабли.
Советы по управлению проектами
Как правильно управлять проектами:
- Ставьте измеримую цель — «увеличить продажи» это не цель, а «поднять конверсию с 2 до 3% за квартал» уже да, потому что результат можно проверить.
- Дробите крупное на мелкое — задача длиннее двух-трех дней обычно скрывает несколько подзадач, плохо оценивается и так же плохо контролируется.
- Договоритесь, что считать готовым — общий чек-лист готовности избавляет от споров, доделана задача или только кажется доделанной.
- Не планируйте загрузку на сто процентов — без запаса любая мелочь типа болезни сотрудника сдвигает все сроки
- Назначайте одного ответственного за результат, а не за участок.
- Сверяйтесь часто, но по-быстрому — 10-15 минут раз в день полезнее двухчасового совещания раз в неделю.
- Фиксируйте договоренности письменно — устные обещания на словах забываются, порождая конфликты на сдаче.
- Управляйте узкими местами — проект движется со скоростью самого медленного звена, и усиливать надо именно его, а не то, что и так нормально работает.
Подведем итоги
Управление проектами базируется на связке из понятной цели, подходящего метода и постоянного контроля. Но любой метод и любой этап работают, когда руководитель видит, кто чем занят, на что уходит время и в каких процессах может случиться перегрузка. Система БОСС Контроль фиксирует фактические часы, показывает загрузку команды, переработки и простои и сводит все в удобные наглядные отчеты. На такой основе видно, не перегружен ли ключевой сотрудник, укладывается ли проект в запланированные трудозатраты и где ресурс уходит впустую.
Если хотите, чтобы загрузка команды и сроки были под контролем, запросите демонстрацию платформы БОСС Контроль и посмотрите, как она работает на ваших задачах.