Scrum не хуже — и теперь не только для ИТ-компаний. Мнение Максима Якубовича

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

— Все известные в мире подходы к управлению проектами условно разделяются на две группы: традиционные подходы к управлению проектами и agile.

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

Хорошим примером традиционного подхода к управлению проектами я считаю PMBOK — Свод знаний по управлению проектами (англ. Project Management Body of Knowledge). PMBOK описывает хорошие практики управления проектами, выпускается Американским институтом управления проектами (PMI) — с 1996 года каждые 4 года он разрабатывает и публикует новую версию этого документа. Кстати, очередная, шестая версия PMBOK, ожидается в первом квартале 2017 года.

Я считаю, что к традиционным подходам к управлению проектом относится также и PRINCE2, который популярен в Великобритании, однако его популярность в мире ниже, чем у PMBOK. По крайней мере, об этом говорит исследование PWC, проведенное еще в 2012 году. С того времени, думаю, ничего не изменилось:

В этом же исследовании есть данные о популярности разных подходов из семейства Agile:

Популярность Scrum, как подхода к управлению проектами, растет и в Беларуси.

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

Подход Scrum часто ругают за то, что в нем слишком много «белых пятен» и пробелов относительно таких монументальных подходов к управлению проектами, как PMBOK или PRINCE2.

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

PMBOK vs Scrum

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

В области знаний «управление содержанием проекта» в PMBOK описано 6 процессов, один из которых посвящен созданию Плана управления содержанием (его мы исключаем из сравнения):

Сравним также процессы из области знаний «управление сроками» по PMBOK с соответствующими действиями в Scrum:

И сравним, как выполняется управление стоимостью в PMBOK и Scrum:

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

Значит, несмотря на всю простоту описательной части Scrum (Scrum Guide описан на 18 станицах), он как минимум достойно отвечает на вопросы того, как управлять содержанием, сроками и стоимостью проекта.

Мне часто задают вопрос о том, в каких проектах можно использовать Scrum, а в каких лучше PMBOK?

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

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

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

2. Разработку результатов проекта можно вести через прототипы, проверяя на них, насколько команда угадала ожидания заказчика. При этом стоимость разработки прототипов относительно невелика (в строительстве дома, к примеру, прототипы создавать слишком дорого).

3. Заказчик проекта готов управлять приоритетами требований к результатам проекта и, главное, готов отказаться от части из них, при этом понимая, что без них продукт проекта все равно будет иметь ценность для его потребителей.

4. Заказчик проекта готов участвовать в проекте не менее 2−4 часов каждую неделю.

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

Остались вопросы? Пишите в комментариях, попробую ответить на них.

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Опыт преподавания — с 2005 года. Около 2300 студентов, прошедших обучение на его семинарах. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект» Ведущий блога по управлению проектами.