Agile или PMBOK: что выбрать для вашего IT-проекта

Выбор подхода к управлению проектом – первый шаг к успеху. Сегодня пытаются противопоставлять классический PMBOK и гибкий Agile и их вариации, но это неверно. Почему их нельзя сравнивать и можно ли их сочетать в одном IT-проекте, рассказывает эксперт в области Agile и управления проектами Luxoft Training Сергей Шарпак.

Исторический путь PMBOK и Agile в IT

Разобраться в особенностях PMBOK и Agile и определиться с выбором поможет понимание исторического пути этих подходов. Рассмотрим, как они создавались и откуда пришли в сферу информационных технологий.

PMBOK (от англ. Project Management Body Of Knowledge) буквально расшифровывается как "свод знаний по управлению проектами". По сути, он предлагает систему координат. В самом наименовании подчеркивается, что объем знаний по управлению проектами бесконечен. Чтобы в нем не запутаться, нужен навигатор. И PMBOK – не все знания, которые нужны для управления проектами, а всего лишь подробная "карта".

Идею создания "системы координат" заложили строительная, оборонная и аэрокосмическая отрасли. Изначально руководство к своду знаний готовилось под проекты инженерного характера, в которых что-то (здания, вооружения, ракеты) возводится в реальном физическом мире. В организации управления такими проектами были замечены повторяющиеся действия. Их можно описать в виде структурированного набора шагов. Первая версия PMBOK была опубликована в 1996 году, а в августе 2021 года американский (по происхождению, международный – по факту) Институт управления проектами должен выпустить седьмую редакцию издания.

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

Но в IT-проектах базовая аксиома, заложенная в PMBOK, о том, что можно заранее договориться, спланировать, зафиксировать и перейти к его реализации, не работает. В самом начале мы пытаемся договориться с заказчиками продукта, а затем выстроить план реализации проекта. Но позже сталкиваемся с тем, что эти договоренности постоянно меняются. Оказывается, что не так поняли клиента / пользователя, и в итоге вынуждены менять представление об IT-продукте.

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

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

Так появилось и само понятие Agile. До принятия манифеста практики назывались lightweight. Но термин Agile лучше раскрывает суть - быть гибким и юрким. Другими словами, в практиках Agile отражены идеи, позволяющие непрерывно пересматривать представление о создаваемом продукте и при этом двигаться в процессе разработки быстро. Все, что вредит гибкости и скорости, отсекается.

Преимущества и недостатки PMBOK и Agile

Если говорить строго, то PMBOK и Agile нельзя сравнивать, поскольку их инструменты предназначены для решения разных задач. Выбор зависит от степени понятности результата или способа его получения. Более того, хорошее знание классического проектного подхода помогает понять Agile-практики. А вот разобраться в них без структуры в голове, которую дает PMBOK, сложнее. В этом случае какие-то области управления могут просто выпасть из внимания. Но это не значит, что у этих подходов нельзя увидеть преимущества и недостатки. О них и поговорим далее.

Главное преимущество PMBOK – возможность предвосхитить значительную долю проблем в проекте, решить их на бумаге дешево и быстро еще до выхода в производство. В некоторых IT-задачах можно предусмотреть путь решения и подводные камни на этом пути, а значит подготовиться к ним. К примеру, при строительстве ЦОДа может возникнуть проблема, когда в результате каких-то внешних работ будет перебит канал связи. Значит, нужно заранее продумать второй резервный канал.

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

Одной из самых привлекательных черт в Agile-практиках является отношение к человеку. Оно отличается от классического проектного подхода, где людей считают ресурсом. И в этом – серьезный недостаток PMBOK. Так как он исторически зародился в строительной отрасли, поэтому исходит из того, что в задачах, связанных с физическим трудом, работает мотивация "кнута и пряника".

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

Как понять, что лучше подойдет для вашего IT-проекта

В своей практике я столкнулся с тем, что практически про любой IT-проект нельзя однозначно сказать, является ли он полностью понятным и соответствующим рекомендациям PMBOK или на 100% непонятный, поэтому для его решения подходят только Agile-практики.

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

С другой стороны, для этих проектов на всех этапах можно использовать Agile-практики. Соответственно, у них будет отсутствовать первоначальный план, а реализация проходить путем постоянных экспериментов и изменений. И здесь есть риск столкнуться с тем, что во-первых, он затянется по времени. Во-вторых, из-за постоянных изменений что-то будет упущено, а в итоге пострадает качество решения. В-третьих, стоимость работы по такому проекту получится выше. Выходит, что использование только Agile-подхода в неоднородных проектах – не самый оптимальный вариант.

Решением здесь может стать сочетание Agile и PMBOK. Гайд по тому, какие инструменты применять и в какой последовательности, как их правильно комбинировать, пока не создан. Учиться приходится самостоятельно.

Рассмотрим несколько случаев, как в гибридных IT-проектах можно сочетать Agile и PMBOK.

1. Проект, в котором стадия неизвестности сменяется классической с понятным решением.

Пример: разработка флагманской модели мобильного телефона.

Начало такого проекта – задача с непонятным решением. Необходимо изучить последние достижения техники, придумать оригинальную начинку телефона. Берем на вооружение Agile-практики, применяем научный метод, экспериментируем и находим какую-то "формулу". В нашем случае – конкретный вариант модели телефона со значительными отличиями от существующих решений. А это значит, проект прошел стадию неизвестности.

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

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

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

Пример: прокладка IT-инфраструктуры в новом бизнес-центре.

Такой проект в целом является понятным. Он подходит под классический PMBOK. По нему уже отработан перечень мероприятий и есть четкая последовательность действий. Но внутри проекта также может встретиться некий запутанный участок. Там лучше будет применить экспериментальный подход из Agile-практик – выдвинуть ряд гипотез и проверить их на практике.

3. Проект с высокой степенью неопределенности и отдельными понятными участками.

Пример: разработка компьютерной игры.

В проектах по разработке решений для высококонкурентных рынков со множеством игроков использовать классический подход, опираясь на прошлый опыт, не стоит. Здесь нужно создать новый оригинальный продукт и обыграть конкурентов. В это же время они будут пытаться переиграть вас. В подобных проектах не может быть готового решения: это задача с высокой степенью неопределенности. Более того, ее понимание по ходу производства игры будет постоянно меняться. Под решение такой задачи подходят Agile-практики.

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

4. Проект по типу "партизанский agile".

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

При выборе подхода для решения какой-то конкретной задачи по IT-проекту нужно отталкиваться от общего критерия – ясности. Применить его можно к конечному результату проекта (продукту) либо к способу его достижения (процессу получения этого продукта). Если у вас есть ясность в отношении обоих моментов, лучше использовать классический PMBOK.

Если нет ясности по продукту (а у большинства IT-решений на конкурентных рынках конечный результат изначально непонятен), подключаем Agile-практики. Например, с продуктовой неопределенностью помогает разобраться Scrum.

Но непонятность может быть и в отношении процесса. Например, у службы поддержки на обслуживании находятся CRM или ERP-системы клиентов из разных часовых поясов. Задача ясна – обрабатывать инциденты и закрывать их в максимально короткие сроки с высоким качеством. Но при организации процесса могут возникнуть трудности. Организатор может не понимать, как сделать его четким, стабильным и предсказуемым. Эту процессную запутанность можно решить при помощи Agile-практик, например, Канбан-метода или иных.

По моему мнению, постепенно искусственная оппозиция между Agile и PMBOK станет не такой напряженной. Все поймут, что это просто разные подходы для решения разных задач. А в проектных командах нормой станет сочетание этих практик.