Шквал перемен, с которым столкнулись российские компании за последние несколько лет, учит бизнес быстро меняться в такт окружающей среде — нестабильной, конкурентной и не всегда предсказуемой.
Адаптивность к условиям рынка, скорость принятия решений и реализации изменений стали ключевыми факторами выживания и роста. Именно поэтому в ходе трансформации бизнес‑процессов компании все чаще рассматривают гибкие методы управления проектами, одним из которых является Agile.
Однако переход от традиционных, линейных моделей к гибким методологиям — не просто смена инструмента. Это принципиально иной подход к управлению изменениями, который предполагает не только введение новых принципов разработки инновационных продуктов, но и смену ментальности, в частности, существенно большего доверия команде проекта со стороны заказчика.
Waterfall: предсказуемо, строго, прозрачно
В классическом − «олдскульном» подходе к управлению проектами (Waterfall) сначала полностью проектируется решение. и каждая новая задача решается на основании результатов предыдущих. Все результаты описаны и зафиксированы. Это старая добрая классика: здесь все строго и даже жестко, и у такого подхода есть очевидные плюсы:
Никаких сюрпризов: заранее понятно, что именно мы делаем, зачем, в какие сроки и какими ресурсами.
Предсказуемый бюджет: можно чётко посчитать ROI до начала проекта, что особенно важно в компаниях с формализованным инвестиционным процессом.
Высокий уровень контроля: есть график, бюджет, этапы приёмки. Ожидаемый результат прозрачен.
Но, когда внешняя среда меняется быстрее, чем согласуется ТЗ, первоначальные цели и планы могут потерять свою актуальность еще до утверждения. В результате проект «срывается» не потому, что команда работала плохо, а потому что условия, в которых должно работать решение, радикально изменились.
В отличие от классических моделей при использовании гибких методов управления проектами решение проектируется и создается частями. Требования к решению, планы и результаты переоцениваются непрерывно, при этом часть задач может не выполняться или выполняться частично, например, документирование. Проект превращается в живой организм, в котором изменения — норма, а не сбой. План, бюджет, ROI становятся не директивой, а ориентиром;
Такой подход позволяет адаптироваться к переменам на ходу − переосмысливать цели, учитывать обратную связь и выбирать оптимальные решения. Это особенно актуально для проектов трансформации бизнес‑процессов, напрямую зависимых от изменений внешней среды, например процессов бизнес‑планирования (IBP, S&OP).
Цена гибкости: от чего придется отказаться, выбирая Agile?
Как известно, за все в этой жизни приходится платить. Чем приходится жертвовать за скорость и адаптивность? Выбирая гибкие методы, мы сознательно отказываемся от целого ряда привычных компонентов, без которых ранее невозможно было представить реализацию проекта: нет подробного ТЗ (формулируются только цель и ключевые требования), нет детального проектирования (проектируем лишь ближайший этап), нет подробной документации, а значит затруднена смена подрядчика и переход к этапу эксплуатации решения. Это первая «жертва».
Вторая — это цена. В ситуации, когда применим классический подход, использование гибких методов обойдется дороже. По сути, Agile — это новый вид контракта, в рамках которого, бизнес доверяет команде не только исполнение и ресурсы, но также целеполагание и управление требованиями. Исполнитель должен не просто действовать по шаблону, но регулярно проверять цель и решение на актуальность и обеспечивать требуемый результат при отсутствии части проектных артефактов, к примеру сценариев тестирования. Такой команде нужен иной набор и уровень компетенций, а значит и стоить она будет дороже.
Доверие как точка опоры
В российских реалиях нередко возникает парадокс: заявляя о переходе на гибкие методы, заказчик продолжает мыслить категориями Waterfall и в результате оказывается в ловушке неисполнимых ожиданий:
Формального ТЗ нет, но «в рамках тендера все зафиксировано».
Решение детально спроектировано только на первый спринт, но все равно ожидаются «точный прогноз» и «фиксированная стоимость» до конца проекта.
Проектная команда не уполномочена принимать решения по отказу от реализации бизнес‑требований или замене их новыми, но ожидаются идеальное соответствие решения всем требованиям и эргономика.
Получается на вывеске написано «Agile», но без доверия любой гибкий метод останется лишь иллюзией гибкости, основой для несбывшихся ожиданий, триггером для конфликтов, срыва проекта, смене исполнителей.
Не доверяешь — иди классическим путем, управляя изменениями, каждый раз перепроектируя и переделывая решение. По крайней мере, вероятность завершения проекта с результатом будет выше.
Как перейти на гибкие методы управления проектом: 3 практических совета
Примите неопределенность как норму. Все начинается с признания новой реальности: внешняя среда меняется стремительно, а точный расчет ROI теряет актуальность. Вместо попытки «запереть» изменения в рамки планов — будьте готовы гибко адаптироваться.
Создайте свой гибкий метод управления проектами, который соответствует реалиям вашего бизнеса. Методология управления проектами должна соответствовать темпам изменений в вашей отрасли, уровню компетенций проектного управления, степени доверия между заказчиком и проектной командой, свойственными вашей компании.
Определяя метод, имеет смысл идти от полного состава артефактов проекта по классике, сокращая их, жертвуя второстепенными и анализируя риски, которые неизбежно растут, когда мы от чего‑то отказываемся.
Дайте себе право на ошибку. Может потребоваться более одного проекта…
Вывод прост: универсальных 100% подходящих решений не существует. Не мода или чужие кейсы должны определять выбор. Зрелость проявляется в умении мыслить системно и формировать свой подход к управлению изменениями, соответствующий реалиям именно вашего бизнеса.
