Модная бизнес-методика Agile по замыслу позволяет компаниям быстрее создавать новые продукты на основе обратной связи с клиентом. На практике нередко получается «как всегда» — ведет к бессмысленным баснословным расходам
«Те, кто не освоит Agile сегодня в куче бизнес-процессов, будут лузерами завтра» — такое грозное предупреждение сделал глава крупнейшего российского банка Герман Греф на Гайдаровском форуме в январе 2016 года. Почему президент и председатель правления Сбербанка стал горячим приверженцем и главным российским идеологом новой методики управления бизнес-процессами?
Agile в переводе с английского означает «проворный», «гибкий». В бизнес-обиход это слово вошло в феврале 2001 года, когда на лыжном курорте в штате Юта 17 корифеев в области программирования и управления из ведущих IT-компаний подписали .
Суть этой методики, ориентированной на гибкость в разработке новых продуктов, такова: в отличие от привычных моделей управления, которые называют «водопадным» или «каскадным», потому что все решения как бы текут сверху вниз, Agile предполагает эффективное и тесное взаимодействие сотрудников разных уровней. Они сами определяют, над какими продуктами и как надо работать. Вместо строгой иерархии и профильных отделов — временные межфункциональные команды (объединяющие, например, программиста, дизайнера и маркетолога), где все равны и ориентированы на конечный результат. Вместо планерок и цепочек согласований — быстрое решение проблем в ходе назначаемых по необходимости встреч. Вместо долгосрочной стратегии и детального календарного плана — постоянная трансформация продукта под меняющиеся нужды потребителя.
Идеология Agile увлекла многих, среди компаний, которые ее применяют, — Google, PayPal, Acrolinx, Moody’s, Facebook и другие мировые гиганты. В России после выступления Грефа тоже, кажется, только ленивый не говорит о переходе на гибкие бизнес-технологии. «Agile — это не мода, это борьба за здравый смысл, стремление сделать хороший продукт, а не выполнить формальный план», — говорит Agile-коуч компании OnAgile Дмитрий Лобасев.
Но как эта модель работает в российской реальности?
«Туту.ру»: естественная эволюция
Гибкая разработка пришла из IT, и опрошенные РБК эксперты сходятся во мнении, что именно для компаний этой отрасли внедрение Agile более чем логично. «IT не та сфера, где допустимы тонны бумажек и бесконечные согласования, — считает Алексей Спасский, гендиректор IT-компаний Phobos и Deimos. — Рынок технологий — самый конкурентный и динамичный, он не растет простым масштабированием. У небольших и быстрых команд здесь все преимущества. Android, например, разработали восемь человек».
Софтверные компании часто сами приходят к Agile. Так получилось у российского туристического онлайн-сервиса «Туту.ру». С управленческими проблемами компания столкнулась, когда переживала бурный рост, в 2013 году штат отделов разработки и тестирования достиг 40 человек, рабочие процессы стали запутанными, менеджеры, ответственные за разработку разных продуктов, вели постоянную битву за опытных специалистов, нагружая их одновременно десятками задач. А разработчики софта жаловались, что ничего не успевают довести до ума. Решение созрело само. «Мы разделили людей на небольшие команды по семь—девять человек и сосредоточились на том, чтобы делать полезные для клиента функции сайта, а не просто выполнять задачи в рамках своей роли, — вспоминает технический директор «Туту.ру» Вадим Мельников. — Уже через месяц полноценно заработали пять команд».
Менеджеры, которые сами не программировали, а контролировали решение задач, смогли сосредоточиться на изучении потребностей аудитории и отслеживать большее количество проектов. И хотя число команд разработчиков удвоилось, это не потребовало увеличения штата менеджеров.
Использование практик Agile на всех уровнях позволило «Туту.ру» всего за три месяца разработать новый продукт «Автобусы», позволяющий покупать в онлайне билеты на междугородные автобусные рейсы, быстрее конкурентов среагировать на появление новой линейки тарифов у авиакомпаний (билеты по сниженным ценам для пассажиров без багажа) и добавить опцию поиска таких билетов.
Мельников убежден, что полноценно внедрить Agile в компании удалось именно потому, что общий стиль управления в компании всегда был неформальным и гибким: «Наш Agile — это в первую очередь мировоззрение руководителей и владельцев компании, признающих лучшим способом решения конфликтов на стыке компетенций коммуникацию, а не иерархию». Впрочем, он подчеркивает, что никакого революционного ускорения процессов внедрение Agile не дало: «Не было такого, чтобы было плохо — и вдруг стало хорошо, хотя в среднем все улучшилось».
Для небольшой компании, разрабатывающей онлайн-приложения, Agile — естественное решение. Куда труднее отказываются от иерархии в пользу скорости в крупных корпорациях.
Фото: Владислав Шатило / РБК">

Владимир Хренков
Фото: Владислав Шатило / РБК
МТС: без фанатизма
В МТС об Agile задумались, когда компания стала выходить на новый для себя рынок — стала предлагать решения на стыке IT и телекоммуникаций. «Здесь очень важны сроки разработки продуктов: если будешь долго делать, то либо конкуренты опередят, либо спрос может пропасть, — рассказывает директор центра инноваций МТС Владимир Хренков. — Поменялся подход к производству: оказалось выгоднее не сосредоточиваться на долгой разработке больших и сложных продуктов, а в сжатые сроки выпускать так называемый минимально жизнеспособный продукт (MVP) и тут же начинать улучшать его, получая обратную связь от клиентов».
Agile-методики внедрялись в компании постепенно. В конце 2015 года директор департамента развития МТС Галина Ильчук пригласила консультанта по Agile Дмитрия Лобасева помочь улучшить работу одного из IT-направлений. Компанию не устраивала скорость, с которой разрабатывались новые программные продукты (в среднем 1,5–2 года), а также постоянные срывы календарных сроков. Проведенный Лобасевым аудит выявил несколько проблем, типичных для крупных компаний. Менеджеры не заботились об удовлетворенности клиентов, считая, что главное — подписать акты, и совсем не стремились иметь обратную связь по уже сделанным приложениям. Начальство приняло — и хорошо. Все решения по разработке новых программ требовали согласования 15–20 менеджеров, которые вместо того, чтобы встретиться и договориться по спорным моментам, вступали в затяжную переписку.
Организовав работу многофункциональными командами, в которых бок о бок работали сотрудники разных н