Бизнес по Грефу: как российские компании становятся гибкими
«Те, кто не освоит Agile сегодня в куче бизнес-процессов, будут лузерами завтра» — такое грозное предупреждение сделал глава крупнейшего российского банка Герман Греф на Гайдаровском форуме в январе 2016 года. Почему президент и председатель правления Сбербанка стал горячим приверженцем и главным российским идеологом новой методики управления бизнес-процессами?
Agile в переводе с английского означает «проворный», «гибкий». В бизнес-обиход это слово вошло в феврале 2001 года, когда на лыжном курорте в штате Юта 17 корифеев в области программирования и управления из ведущих IT-компаний подписали «Манифест Agile».
Суть этой методики, ориентированной на гибкость в разработке новых продуктов, такова: в отличие от привычных моделей управления, которые называют «водопадным» или «каскадным», потому что все решения как бы текут сверху вниз, 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 менеджеров, которые вместо того, чтобы встретиться и договориться по спорным моментам, вступали в затяжную переписку.
Организовав работу многофункциональными командами, в которых бок о бок работали сотрудники разных направлений, руководство компании добилось сокращения числа согласований в несколько раз. Также оказалось, что некоторые приложения и функции, которые давно и упорно разрабатывали программисты, уже не нужны пользователям.
В результате стало меняться отношение к подготовке проектов. «Например, компания отводила на разработку корпоративного портала более года, — рассказывает Дмитрий Лобасев. — В итоге мы провели тендер и сделали его всего за три недели. Запустили, протестировали. Обратная связь позволила улучшать портал уже в процессе работы».
Успешно опробованный на IT-направлении подход стал постепенно внедряться во всей компании. Созданный в октябре прошлого года инновационный центр МТС, подчиняющийся напрямую президенту компании, имеет простую структуру: это три команды по десять человек, в аппарате — всего три человека, которые занимаются координацией команд с другими направлениями.
У каждого сотрудника центра только один ключевой показатель успешности — выполнение задачи, над которой сейчас работает его команда. Члены команды сидят в одной комнате, чтобы общаться на короткой ноге и избегать ненужных совещаний. «Теперь мы выпускаем MVP за три месяца и сразу начинаем общаться с клиентом, — говорит Хренков. — Например, в прошлом году решили запустить услугу облачных вычислений и хранения данных для крупных корпоративных клиентов. Быстро запустили ее в самом простом варианте, и первый же клиент сказал: у вас только один центр обработки данных — ЦОД, что будет, если с ним что-то произойдет? Мы создали еще два в Петербурге и Новосибирске, и услуга сразу стала более востребованной». По такой же модели было создано приложение «Телемедицина», позволяющее консультироваться онлайн с врачами разного профиля. Сейчас инновационный центр МТС выпускает приложения по четырем направлениям: облачные технологии, цифровое здоровье, образование, киберспорт.
Существенно упростилась в компании и процедура финансирования проектов: раньше процесс мог тянуться месяцами, теперь вопрос о выделении относительно небольших для компании денег — до 100 млн руб. — может решаться в течение одного дня.
Хренков считает, что причина, по которой у МТC получается извлекать пользу из Agile, заключается в отсутствии фанатизма: «Мы не стали переводить на Agile все 75 тыс. сотрудников: тиражируем успешные подходы очень постепенно, адаптируя под каждое направление. Работа над некоторыми проектами, требующими крупных вложений средств и времени, связанных с большими рисками, останется каскадной».
NPM: «железо» со скоростью Facebook
Новосибирская компания NPM, один из крупнейших в России производителей оборудования для индустрии напитков, несколько лет назад начала поставлять свои аппараты за рубеж и столкнулась с жесткой конкуренцией. «И наши, и зарубежные производители оборудования для розлива пива в среднем готовят новый аппарат около двух лет, но по качеству и дизайну изделий они ушли на десятилетия вперед. Догнать их при равной скорости разработки невозможно», — говорит Agile-директор NPM Сергей Чирва.
В компании Сергей работает почти 20 лет — занимался маркетингом, поднимал продажи. Новую должность придумал себе два года назад, когда увлекся гибкой методологией разработки и, вдохновившись примерами Facebook и Amazon, задумался, можно ли производить новые аппараты путем итераций, то есть выпуская сначала базовую версию, а затем ее обновления. «Продукты в реальном производственном секторе создаются и меняются годами, — говорит Чирва. — Может ли заимствованный из IT подход увеличить скорость и качество в производстве «железа»? Наш опыт доказал, что может».
В качестве пробного камня была выбрана задуманная конструкторами компании интеллектуальная система Craftap Smart, которая могла бы в автоматическом режиме разливать пиво в тару любого объема, подавляя при этом образование пены.
Традиционная схема разработки — маркетологи создают концепт устройства, конструкторское бюро делает прототип, потом другие отделы готовят документацию, тестируют и, наконец, передают в производство. Руководство NPM решило рискнуть и делать новый аппарат так, как делаются программные продукты: поскорее выпустить первый вариант, а потом его дорабатывать.
Руководство компании выделило для работы над устройством специалистов из разных служб. Конструкторы работали в связке с маркетологами и специалистами по производству. «По самым смелым планам мы хотели разработать продукт в два раза быстрее обычного — за 12 месяцев, — говорит Чирва. — В результате сделали за шесть и продали целую партию, в основном за рубеж. Если бы мы разрабатывали Craftap Smart по обычной схеме, то до сих пор были бы далеки от первых поставок, а возможно, не создали бы его никогда».
Разработка и производство первой партии обошлись в 7 млн руб., уже на седьмой месяц с начала разработки было продано устройств на общую сумму 3 млн руб. (один аппарат стоит $3 тыс., или около 180 тыс. руб.), а к концу 2017 года компания планирует продавать Craftap Smart на 10 млн руб. в месяц.
Этот пример не уникален. Сейчас консультант по Agile Лобасев сотрудничает с одной из крупнейших сетей АЗС: помогает оптимизировать строительство новых заправок. «Здесь мы столкнулись с классической проблемой «колодцев». Речь о том, что в компании несколько подразделений, которые сосредоточены на исполнении процессов и выполнении своих KPI: это разведка подходящих площадок, юристы, безопасность, строители, розница, — говорит Лобасев. — С другими направлениями каждый «колодец» общается, переправляя тонны документов по почте. Мы объединили представителей этих «колодцев» в единую Agile-команду и предложили им встречаться несколько раз в неделю по утрам, чтобы совместно обсуждать вопросы по всем объектам».
Когда люди стали общаться на регулярной основе, выяснилось, что отдельные направления могут не ждать друг друга — например, юристы с удивлением узнавали, что могут начать оформлять документы еще до окончания основных работ по проекту, а не через месяц, как планировалось изначально. А главное — быстрее стали выявляться проблемы (со сроками, новыми требованиями от дорожных служб и т.п.), а значит, и быстрее стали обсуждаться пути их решения.
Беспощадный Agile
Если послушать пропагандистов Agile, то можно подумать, что эта методика — панацея, но это далеко не так, уверяет Алексей Спасский. Как правило, адепты этой методики умалчивают о провалах, ссылаясь на неэтичность упоминания компаний, где дело не пошло на лад. Но таких примеров немало.
Когда Сбербанк в 2012 году пригласил Дмитрия Лобасева внедрять Agile, из пяти созданных им команд фактически заработала лишь одна. Методики гибкого проектирования вступили в конфликт с 14-уровневой иерархией банка. «Это то, что принято называть наследием — корпоративная культура, которая сопротивляется изменениям», — говорит Дмитрий. Насколько продвинулось внедрение гибкой методологии разработки, можно судить лишь косвенно. Например, больше недели Сбербанк готовил комментарий к этому материалу РБК, но так и не смог его согласовать.
Если компания следует моде, не слишком хорошо понимая, чего она хочет в итоге достигнуть, внедрение Agile обернется пустой тратой денег, говорят все опрошенные РБК эксперты. И это недешевая ошибка. «Специалисты по Agile в банках и крупных компаниях получают от 100 тыс. до 600 тыс. руб. в день, — говорит Лобасев. — В среднем на начальный этап трансформации компании тратят около 10 млн руб.».
Многие признаются, что на протяжении первых месяцев Agile-трансформации в компаниях царит неразбериха. «Сотрудникам, которые так не работали раньше, это непривычно и дискомфортно, — рассказывает руководитель российской компании — разработчика игр RPF Анти Данилевский. — Кто-то считает, что это трата ценного рабочего времени, и воспринимает негативно». По наблюдениям Хренкова, рядовые сотрудники принимают перемены легче, а вот менеджеры, как правило, недовольны — ведь они теряют возможность использовать сотрудников для решения своих задач. В практике Лобасева были примеры, когда сопротивление менеджеров было столь сильным, что компаниям приходилось выбирать: либо сворачивать реформы, либо увольнять сопротивляющихся.
Гендиректор IT-компании Accera Анатолий Шеин отмечает следующий парадокс: Agile в большинстве компаний внедряется по каскадной методологии. То есть руководитель приказал, отделы потратили деньги и отчитались об успешно проведенной Agile-трансформации. И это показывает, насколько практика все еще далека от теории.