Прогибаться под
изменчивый мир

Технологии в корне меняют мировую экономику и проникают во многие сферы бизнеса. Автоматизация производства, большие данные и искусственный интеллект обеспечивают компаниям впечатляющие результаты. Но сегодня огромное значение имеет скорость вывода продукта на рынок — важно не только придумать идею, но и в сжатые сроки реализовать ее. Разработчикам продуктов и сервисов приходится считаться с изменчивой средой: если проект выполняется долго, он может оказаться уже ненужным заказчику. Сегодня во многих отраслях тратить на реализацию идеи год или больше — непозволительная роскошь.

Решить эти проблемы помогает адаптивная модель, или agile (см. статью «Рецепт инноваций: модель agile»). Она предполагает, что людей нужно вырвать из изолированных отделов и включить в самоуправляемые группы, ориентированные на клиентов. Модель изначально применяли в ИТ-компаниях, а затем и в других отраслях, где в процессе создания продукта могут меняться рыночные условия или требования заказчика и, соответственно, требуется гибкость. Философия agile выражена в четырех ценностях и двенадцати принципах, которые изложены в «Манифесте гибкого подхода к разработке программных продуктов».

В России agile (в частности, методологию scrum) начали активно применять 5—6 лет назад. Есть удачные примеры внедрения, еще больше компаний находятся в начале пути. Но многие пока размышляют, как лучше двигаться.

Традиционный подход — основательно подготовиться к применению scrum, пригласить консультантов, обучить персонал на тренингах. Так поступил, например, Райффайзенбанк (на 1 сентября 2017 года занимает 13-е место в России по активам). Это затратный путь, однако он дает необходимую базу для трансформации. Другой подход — когда компания действует интуитивно, но в итоге приходит к тем же самым организационным принципам, которые сформулировали авторы адаптивной модели. Такова практика крупнейшего онлайн-ритейлера России Wildberries (оборот компании в 2016 году, по данным Data Insight и Ruwards, составил 45,6 млрд руб.). И в том, и в другом случае можно получить осязаемый результат. Главное, чтобы изменения действительно назрели и топ-менеджмент стал их движущей силой.

Первые эксперименты

Команда Райффайзенбанка прошла три стадии погружения в agile. Все началось в 2012 году в виде эксперимента в ИТ-департаменте. «До сих пор программисты работали по каскадному принципу, но мы хотели ускорить разработку. И пригласили автора книги “Канбан. Альтернативный путь в agile” Дэвида Андерсона», — рассказывает руководитель управления стратегического управления, организации и контроля ИТ Райффайзенбанка Сергей Щербинин. Но улучшения были локальными: одна команда разработчиков стала работать более предсказуемо, и только.

Через какое-то время эксперимент решили провести на новом уровне — наняли консультантов, работающих по методологии scrum, а затем предложили командам по их желанию присоединиться к проекту. На этом этапе пришлось пробиваться сквозь скепсис сотрудников. «Разработчики — люди дотошные, они хотели, чтобы им на цифрах доказали, что новая система работы эффективнее прежней, — вспоминает Щербинин. — Но фокус в том, что никто не может это доказать математически. Есть хорошие кейсы, но другие компании работают в других условиях. Вывод — надо пробовать на себе».

На тот момент около 30 ИТ-команд банка занимались продуктовой разработкой, из них 7 включились в проект. Но результаты по-прежнему не впечатляли. Команда, которая разрабатывала фронт-офисную систему (в ней работают сотрудники банка в отделениях) смогла ускорить выпуск релизов примерно в два раза. Но остальные участники скатились в карго-культ. «Люди просто формально ходили на встречи. Разработчики не понимали и не принимали идею agile. Как, впрочем, и бизнес-подразделения», — говорит Сергей Щербинин.

Тем не менее в компании увидели, что agile позитивно влияет на вовлеченность сотрудников. Работая по методу scrum, люди не стали писать код лучше, но осознали цель — что и зачем они делают. Например, команда, которая занималась рублевыми платежами, поняла, что не просто разрабатывает формочки с полями, а выполняет определенные требования ЦБ. И что банки бьются за скорость проведения платежей, то есть работа команды поможет Райффайзенбанку обогнать конкурентов. Такой подход вдохновляет больше, чем простое рисование формочек, люди стараются делать меньше ошибок.

Новый этап внедрения agile в Райффайзен­банке начался в 2016 году. Правление поставило цель — существенно расширить клиентскую базу, и председатель правления Сергей Монин предложил решение — стать agile-организацией. Его, в частности, вдохновили успехи компании Spotify и банка ING, о которых писала пресса. Гибкая организация может быстрее выводить банковские продукты на рынок, что очень важно для наращивания конкурентного преимущества. Кроме того, это скажется на росте NPS (Net Promoter Score, индекс потребительской лояльности), который отражает качество сервиса.

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

Согласно методологии scrum, все члены команды должны сидеть вместе. Часть программистов — удаленные сотрудники из Омска, их это не касалось, но уговорить остальных поменять рабочее место оказалось непросто. Представители бизнеса поначалу отказывались покидать свой девятый этаж и переезжать к разработчикам на пятый — мол, наверху и кабинеты больше, и вид из окна лучше. Но когда переезд состоялся, для всех стало настоящим открытием, что рабочие вопросы можно решать быстро, без утомительной переписки.

Новый рекорд производительности поставила команда, которая перезапускала ипотечный конвейер (ИТ-технологии, обеспечивающие выдачу банком ипотечных кредитов) — первый работающий продукт она выдала через два месяца. Это серьезное достижение, потому что раньше программисты на той же ИТ-платформе разрабатывали автомобильный и потребительский конвейер, но скорость оставляла желать лучшего. Проект по автокредитованию они выполняли два с половиной года, но когда релиз был готов, случился кризис, и выдачу автокредитов пришлось свернуть. А конвейер потребительского кредитования готовили год и потом еще основательно дорабатывали.

Сейчас внедрение agile идет в банке по нарастающей — сначала к пяти командам, участвующим в проекте, присоединились еще пять, а сегодня их 17. Список участников пока решили не расширять, потому что надо серьезно проанализировать результаты работы. Часть команд серьезно увеличила скорость вывода продуктов на рынок (ипотека, веб-сайт, рублевые платежи и др.), однако у некоторых участников скорость работы замедлилась.

Осмысление и погружение

Анализируя причины неудач 2012—2015 годов, Сергей Щербинин пришел к выводу, что на энтузиазме далеко не уедешь: людей нужно было основательно обучать. Он взял на вооружение японский принцип обучения Сю Ха Ри. Стадия «Сю» подразумевает строгое следование правилам, на стадии «Ха» от канонов уже можно отступать. Наконец, на стадии «Ри» учащийся становится мастером и может импровизировать. «Российские компании в 90% случаев начинают с “Ри” и пытаются придумать что-то свое. Мы тоже сразу перешли к третьей стадии, это была ошибка», — говорит Щербинин.

Поначалу в банке посчитали, что достаточно отобрать 3—4 толковых сотрудника из каждой команды, отправить их изучать методологию scrum, и затем они смогут передать знания коллегам. Но подход не сработал. ИТ-менеджеры — не преподаватели и не умеют объяснять, как профессиональные тренеры. А главное, информация искажается при передаче. Гораздо полезнее обучать команду целиком, причем у одного провайдера, иначе придется тратить время на согласование терминов и понятий. В 2016 году все участники проекта, в том числе правление Райффайзенбанка, отправились изучать scrum.

После перехода на новую систему нередко возникает разочарование — качество и скорость работы могут упасть, так как люди выходят из зоны комфорта. Разработчикам-интровертам теперь приходится контактировать с другими людьми, и это выбивает их из колеи. А еще команды, работающие по методологии scrum, планируют свою нагрузку самостоятельно, но не у всех получается. В Райффайзенбанке некоторые команды ставили перед собой слишком много задач, но не выполняли и половины. «К этому нужно нормально относиться — команды нащупают свою производительность за 3—4 месяца»,  — говорит Сергей Щербинин.

Наконец, в команде появляются новые выделенные роли. Во-первых, скрам-мастер (своего рода фасилитатор). Компании часто назначают на эту роль продакт-менеджеров или лидеров команд. Но в Райффайзенбанке поняли: лучше, если скрам-мастер не имеет отношения к ИТ — он должен проявлять эмпатию, а не лидерские качества, не руководить, а подсказывать. Проще найти людей извне с подходящим психотипом и их обучить. В итоге наняли выпускников психологических факультетов, и сейчас в банке почти 25 подготовленных скрам-мастеров.

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

Правление банка раз в две-три недели обсуждает ход проекта, и уже сейчас есть идеи, как развивать agile дальше. Например, в крупных компаниях финансовый план обычно принимают на год. Но было бы неплохо сделать бюджетирование более гибким, чтобы приспосабливаться к меняющимся условиям. Эту задачу предстоит решать в  ближайшие 3—5 лет.

Естественный отбор

«Мы никогда не обращались к консультантам и не изучали методологию agile. Но формат работы, к которому мы пришли, вполне соответствует agile-манифесту», — говорит ИТ-директор компании Wildberries Андрей Ревяшко.

До недавних пор ИТ-департамент Wildberries работал как служба единого окна — задачи, которые поступали от заказчиков, ставили в очередь. 120 сотрудников занимались сайтом, разрабатывали мобильное приложение, CRM-систему, портал поставщиков и т. д. Поток задач увеличивался, поэтому чьи-то интересы неизбежно страдали. Между заказчиком и непосредственными исполнителями стояло несколько руководителей, на прояснение технического задания и переписку мог уйти месяц. Чтобы сгладить конфликты, компания набрала аналитиков, которые понимали бизнес-задачи и могли переформулировать требования для программистов. Но возник эффект бутылочного горлышка, процесс стал тормозить еще больше.

Работе также мешали «пустые» задачи. Заказчики могли дать задание, не особо просчитав его перспективы. В результате, как говорит Андрей Ревяшко, если проект выстреливал, лавры доставались заказчику, а если нет — шишки сыпались на программистов.

Финансовый департамент чаще других конфликтовал с разработчиками, и в 2015 году они собрались вместе, чтобы выяснить отношения. Решили, что если финансистов не устраивает скорость выполнения задач, пусть 10 программистов 1C поступают непосредственно в их подчинение. Программистов это не обрадовало, и руководителю пришлось каждого убеждать. Но три человека вскоре ушли.

Через несколько месяцев стало понятно, что новый формат прижился. Программисты общались с заказчиком напрямую, стали ненужными промежуточные звенья в лице проджект-менеджеров и аналитиков. Финансисты прислушивались к рекомендациям программистов и принимали всю ответственность по проектам на себя.

В итоге компания решила переформатировать ИТ-департамент и всех разработчиков ПО перевести в профильные подразделения (колл-центр, служба логистики, отдел работы с поставщиками и др.). По сути, каждый бизнес-департамент получил собственный ИТ-отдел, или ИТ-спецназ, как его называли в Wildberries. С самыми неуживчивыми программистами (семь человек) пришлось расстаться.

Один из новых менеджеров, нанятых в Wildberries, случайно оказался специалистом по scrum, он рассказал коллегам о методологии, познакомил с некоторыми процедурами и т. п. В частности, в компании стали использовать визуализацию результатов. «В центре нашего офиса висят два больших монитора, на которых обозначены задачи всех подразделений — кто что делает, что уже сделано, что еще нет», — говорит Андрей Ревяшко. На сегодняшний день 20 команд разработчиков способны осилить решение около 1500 задач в месяц со сроком исполнения до трех дней, а также около 850 задач со сроком исполнения до 14 дней.

В новой системе работы Андрей Ревяшко видит следующие плюсы.

• «Пустые» задачи исчезли. Если новый проект по каким-то причинам не выстреливает, никто ни на кого не перекладывает ответственность.
• Улучшилось взаимопонимание. После того как ИТ-специалисты рассредоточились по разным отделам, люди поняли, что работают в одной команде. Программисты теперь не просто делают то, что им говорят, а отвечают за часть общего проекта и сами предлагают решения.
• Заметно возросла скорость разработки. Реализация проектов, которые могут приносить дополнительную прибыль, не затягивается. «Пилоты» запускают быстро, и если результат устраивает — немного дорабатывают.
• Практически не бывает ситуаций, когда программисты доводят продукт до финала, а потом получают указание все переделать. Раньше такие случаи были, и они всегда демотивировали сотрудников.

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

Почти так же быстро на сайте Wildberries запустили прием онлайн-платежей. У карточных систем серьезные требования к безопасности — описание занимает целый талмуд. Кроме того, сертификация платная, поэтому важно пройти аудит с первого раза. «Мы потратили на разработку платежного шлюза 2—3 месяца и получили сертификат соответствия. В прежнем формате работы все наверняка затянулось бы на год или больше», — говорит Андрей Ревяшко.

Впрочем, у новой системы Wildberries есть и минусы.

• Количество разработчиков выросло со 120 до 200 человек. Правда, возросло и количество задач, так как бизнес растет. Компании пришлось набирать и обучать стажеров.

• ИТ-специалистам важно общаться не только с бизнесом, но и друг с другом, иначе каж­дая команда будет изобретать велосипед. Были моменты, когда несколько отделов пытались одновременно делать один и тот же функционал.

Несмотря на то что новый формат работы программистов вполне устраивает Wildberries, компания открыла вакансию и сейчас ищет профессионала, владеющего методологией scrum. Пришло время осваивать agile более углубленно.

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