Подавляющее большинство компаний в современном мире сталкиваются с необходимостью решать задачи, характер которых не вписывается в рамки операционной деятельности. В случае с операционкой понятно, какого результата требуется достичь и каким образом это сделать. С задачами, имеющими признаки проектной деятельности, не все так очевидно.
Достаточно обнаружить признаки неочевидности в формате конечного результата (рис. 1) либо методологии решения (рис. 2), и они подлежат изъятию из пула задач, решения которых описаны и задокументированы в разного рода бизнес-процессах, технологических картах, регламентах и прочей внутренней нормативной документации.
Как только становится понятно, что задачу не решить стандартизованными способами, возникает проблема выбора способов ее решения. Поскольку возник фактор неочевидности (а может, и сразу два), менеджмент компании совершенно справедливо приходит к выводу о необходимости решения задачи проектными способами.
Происходит обращение к существующим проектным методологиям, и вдруг обнаруживается, что таких методологий на сегодня насчитывается не менее пяти. Это популярные и подчас конкурирующие между собой Agile и Waterfall, а также методологии, которые не на слуху, но которые известны в специализированных кругах пользователей, такие как PRINCE2, Метод экстремального программирования, «Шесть сигм» и др.
В таком многообразии проектных методологий легко запутаться, начинается мучительная проблема выбора. Иногда (автору приходилось с этим сталкиваться, работая с заказчиками) компания «вспоминает» о своей современности и решает жить и работать в среде Agile. Ведь классический Agile появился только в 2001 году. В сравнении с ним Waterfall, может показаться чем-то устаревшим и не соответствующим духу времени.
Кто-то в топ-менеджменте компании, наоборот, может оказаться старой закалки и откажется принимать что-то новое, не проверенное временем и не доказавшее эффективности. Следствием этого становится резолюция руководителя о выборе классической каскадной методологии Waterfall.
Речь в этой статье пойдет о выборе именно между двумя данными подходами как наиболее известными при решении проектных задач. Итак, какую методологию выбрать?
Прибыль. Кто первый?
Любая компания, если это не общественная организация, основной целью своего существования ставит получение прибыли. Чем больше, тем лучше. Если исходить из этого критерия, то выбор автоматически падает на Agile. Ведь именно этот подход позволяет еще до появления конечного решения выводить на рынок отдельные работающие функции. Иными словами, уже появляется минимально жизнеспособный продукт – MVP (minimum viable product) – который уже начнет генерировать прибыль.
ROI (return on investment, показатель возврата инвестиций) таких проектов выше в сравнении с проектами, реализуемыми традиционным каскадным методом.
В Waterfall же генерирования прибыли не произойдет, пока не будет создано и предоставлено заказчику конечное решение с абсолютно всеми функциями, заложенными в техническое задание.
Казалось бы, очевидно, что экономика проекта подсказывает о необходимости склонения чаши весов именно в сторону Agile. Ведь если, например, мы создаем мобильное приложение по вызову такси, то, по большому счету, заказчику достаточно на первых порах лишь самых необходимых функций: геолокация пассажира и автомобиля, способа оплаты и кнопки вызова автомобиля.
Всевозможные сервисы вроде привязки дополнительных способов оплаты, разного рода семейных аккаунтов, всевозможных акций и пр. на старте проекта необязательны. Это можно добавить уже в процессе работы сервиса. А сам сервис, работая с минимально необходимыми опциями, между тем уже приносит прибыль заказчику.
Весомый аргумент, не правда ли? Но давайте смотреть на разницу подходов дальше.
Выдержит ли проект испытание временем?
Проектные задачи при правильном управлении проектом всегда реализуются на стыке трех компонентов:
Если представить ситуацию, когда реализуется долгосрочный проект, то пока он достигнет финальной стадии в версии с применением Waterfall, может получиться, что на выходе окажется уже никому не нужным. Да-да, все вложенные ресурсы будут с нулевым ROI.
Почему так может получиться? Просто потому, что проект не обладал высокой степенью гибкости и не мог адаптироваться под изменяющиеся условия, в том числе за счет изменения макроэкономической и геополитической ситуаций.
Автор стал свидетелем, как однажды во время подготовки проектной команды силами Консалтинговой группы BITOBE для известного оператора железных дорог, один из участников привел интересное сравнение с термозазором, применяемым при укладке рельсошпального полотна. И действительно, итеративный подход в Agile способствует тому, что реализуемые в данной среде проекты могут быть своевременно адаптированы под изменяющиеся условия.
К сожалению, реализуемый в течение достаточно длительного срока и без должной гибкости проект по окончании работ может оказаться невостребованным заказчиком или получить обратную связь от конечных пользователей, что это устарело еще до выхода конечного решения в свет. И даже если в проекте будут выполнены условия триады «бюджет, качество, сроки», несоответствие рыночным реалиям перечеркнет и сведет на нет все усилия проектной команды.
Один за всех, или принцип универсального солдата
Цель этой статьи – не показать все плюсы или минусы каждой из методологий. Скорее речь идет о том, чтобы на этапе выбора проектной методологии не уйти в крайности и не начать руководствоваться выбором, подверженным влиянию трендов. К примеру, в одном из российских банков, входящих в топ-10, Agile если не насаждается, то априори является средой, в которой пытаются найти решение для большинства проектных задач.
И вот здесь следует вспомнить о не менее важном аспекте среды Agile. К одной из ролей скрам-проекта относится команда разработки. Так вот, эта команда разработки «сосредоточена на одном проекте и является кросс-функциональной; это означает, что каждый ее участник, несмотря на свои особые профессиональные качества, может выполнять различные виды проектных работ»1.
Работает ли данный принцип на практике? Если вспомнить историю возникновения Agile, то стоит упомянуть, что данная методология возникла из недр разработки программного обеспечения. Вероятно, именно в IT-проектах обеспечить принцип кросс-функциональности оказалось несколько проще, чем в других отраслях. Архитекторы, аналитики, проектировщики оказались более подходящими под категорию взаимозаменяемости.
Но можно ли такое реализовать в компаниях из других отраслей? Едва ли. Например, сфера бурения скважин для добычи углеводородов совершенно точно потребует дифференциации труда – и это уже не будет классический Agile.
И если взять многие другие отрасли, не связанные с разработкой IT-решений, то во многих таких отраслях совершенно точно будет прослеживаться типология участников проектной команды – «универсальных солдат» там обучить и наладить их рабочий процесс не получится.
И это уже первый признак, указывающий на то, что создать классическую среду Agile в реальном секторе экономике может быть проблематично.
Самоорганизующиеся проектные команды: миф или реальность?
Один из принципов Agile гласит, что самые лучшие архитектурные и технические решения рождаются у самоорганизующихся команд. То есть данный принцип предлагает равноправие всех участников команды. Проектная команда не имеет руководителя.
Возможно, команда, способная самоорганизоваться, выработать принципы взаимодействия и начать строго их соблюдать – это лучшее решение в духе team spirit. Но вот только такая команда рискует остаться именно мечтой, не нашедшей реального воплощения в жизни, поскольку роль руководителя проектной команды была, есть и будет актуальной как в операционной деятельности, так и в проектной.
Даже если решение внутри проектной команды будет приниматься коллегиально всеми ее участниками, ключевые функции управления (организация, планирование, мотивация и контроль) не должны размываться. Их следует закреплять в полномочиях руководителя проектной команды.
Waterfall и Agile: взболтать, но не смешивать? А почему бы и… да!
Итак, какую проектную методологию выбрать: каскадный Waterfall или итерационную среду Agile? Практика управления показывает, что все лучшее всегда находится где-то посередине, подобно истине. Всегда можно взять что-то лучшее от каждого из подходов и вывести гибридную методологию. Ведь главное при реализации любого проекта –соблюсти ключевую триаду проекта (сроки, качество, бюджет).
Кстати, именно о гибридной технологии говорил еще в 1970 году в своей статье ученый в области информатики Уинстон Ройс2.
По словам Ройса, «если компьютерная программа разрабатывается с нуля, то спланируйте задачи так, чтобы версия, предоставляемая заказчику для внедрения, фактически являлась второй версией программы в таких важных аспектах, как архитектура или эксплуатация».
С этого момента фактически была выдана индульгенция на применение там, где это возможно и, главное, обусловлено особенностями проекта и спецификой сферы его реализации, гибридного подхода. Представляется, что именно такой взвешенный подход поможет унять споры сторонников и противников каждого из вида проектных методологий.
1«Просто об Agile», Марк Лейтон. Библиотека Сбербанка
2Winston W. Royce Архивная копия от 15 марта 2016 на Wayback Machinein: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.
