Рассказ о том, как устроена разработка в Сбербанке, и первый фоторепортаж из нового офиса.

В закладки

Офис Сбербанка в Москве

Сбербанк существует на рынке уже 176 лет. В нём обслуживаются 140 млн физических лиц и 2 млн корпоративных клиентов. Компания представлена в 22 странах, в ней трудятся более 300 000 специалистов.

В банке продолжается масштабная реформа, одной из ключевых частей которой было переосмысление и изменение подхода к развитию продуктов. Изучив опыт иностранных финансовых институтов и успешных компаний Кремниевой долины, банк построил собственную модель работы, учитывающую основные принципы гибкой разработки Agile - в банке её называют Sbergile.

В отличие от технологических гигантов и финтех-компаний, Сбербанк не был компанией, функционирующей по принципам Agile, с самого начала. Однако мы продемонстрировали, что эту философию управления 21 века можно успешно внедрить. И пользоваться её преимуществами для компании и клиентов - независимо от количества работающих сотрудников.

Благодаря этому подходу мы значительно повысили скорость работы: например, путем сокращения времени вывода продукта на рынок до нескольких недель по сравнению с несколькими месяцами ранее. И смогли помочь нашим клиентам сохранить самый драгоценный ресурс - время.

Герман Греф, глава Сбербанка

На Давосском форуме 2018

С тех пор топ-менеджмент лидирует Agile-трансформацию, а Сбербанк стремится стать ИТ-компанией с банковской лицензией. Продуктовая линейка должна быстро адаптироваться под запросы рынка.

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

Коллектив поделили на племена

Наблюдательный совет Сбербанка утвердил стратегию до 2020 года, в которой указаны ключевые приоритеты развития. Среди них - лучший клиентский опыт и экосистема, технологическое лидерство и люди нового качества в эффективных командах.

Agile-трансформация в Сбербанке сконцентрирована в трех основных областях: удовлетворенность клиентов, продуктивность сотрудников и улучшение ключевых показателей: таких как время, необходимое для принятия решений, вывода продукта на рынок и поставки продукта клиентам.

Герман Греф

Более 11 000 сотрудников, работающих в Sbergile, поделены на трайбы (от английского tribe - племя). Каждый трайб - это агломерация команд, объединенных вокруг какой-то общей бизнес-цели, например, развития карточных продуктов. И «карточные» в данном случае - условное обозначение, потому что в зону ответственности этого направления входят любые способы оплаты, включая эквайринг, смартфоны, NFC-кольца и другие. Цели каждого трайба вытекают из стратегии развития банка и формируются лидерами трайбов при участии топ-менеджмента банка.

Каждый квартал кураторы трайбов вместе с лидерами трайбов обсуждают цели на ближайшие три месяца. На этой же встрече лидеры трайбов синхронизируются между собой, обсуждают результаты предыдущего квартала и планы на следующий. После этого команды декомпозируют эти цели на конкретные задачи в бэклоге и делят на спринты (такт работы команды, в ходе которого создаётся новая версия продукта).

Примеры трайбов, в каждом из которых работает от сотни до нескольких сотен человек (сейчас более 20 трайбов): «Эквайринг и банковские карты», «Платежи и переводы», «Занять и сберегать» - названия говорят сами за себя, Digital business Platform - «Сбербанк Онлайн», веб- и мобильное приложение для различных устройств. Это одновременно и самостоятельные продукты, и канал для других продуктов.

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

Внутренний двор офиса, который занимает 16 этажей и обозначается в Сбербанке как дом Agile

Вид из окон на Кутузовский проспект

Племена состоят из команд

А команды, в свою очередь, из специалистов. В каждой команде работает от 9 до 12 человек, которые в разных пропорциях делятся на категории - бизнес и ИТ. Прямая коммуникация между ними сама по себе ускоряет работу.

Но объединение разработчиков и бизнеса - недостаточное условие для повышения скорости и качества разработки. Все сотрудники, переходящие на систему гибкой разработки, проходят обязательное обучение по специальной программе «Основы Sbergile», которую проводят Agile-коучи. После этого коучи запускают команды и сопровождают их в дальнейшем. На данный момент в Сбербанке на постоянной основе работают более 60 коучей.

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

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

Совещание, на котором присутствует Agile-коуч - сидит в правом углу переговорной комнаты

Все встречаются на церемониях

Команды могут отличаться друг от друга в зависимости от целей и продукта, но в целом все играют по одинаковым правилам. Эти правила - в том числе обязательные для всех команд церемонии - дисциплинируют и помогают командам двигаться быстрее:

Планирование спринта . Команда вместе с владельцем продукта расставляет приоритеты, формирует бэклог, чтобы через две недели показать результат.

Ежедневный стендап . Команда обсуждает планы на день. Каждый участник отвечает на три вопроса:

1. Что я делал вчера для достижения цели спринта?

2. Что я буду делать сегодня?

3. С какими проблемами и препятствиями я столкнулся?

Демонстрация . Презентация результатов двухнедельного спринта, на которой команда собирает независимую обратную связь по своему MVP (Minimum Viable Product - минимальный жизнеспособный продукт). На встрече присутствует лидер чаптера - человек, который контролирует работу специалистов одной области знаний в разных командах.

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

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

Portfolio marketplace . Синхронизация команд и выявление взаимозависимостей на уровне трайба. Присутствуют владельцы продуктов, лидер трайба, лидеры чаптеров, коучи.

Квартальный обзор результатов трайбов . Синхронизация между трайбами, расставление приоритетов. Встречаются лидеры трайбов, руководители ИТ- и бизнес-подразделений.

Культура непрерывно подпитывается

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

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

У каждого трайба свои особенности - они как отдельные субкультуры. Организовывают свои мероприятия, ездят вместе в горы, путешествуют. Некоторые трайбы ежемесячно проводят тематические завтраки, например, «Кем я хотел быть в детстве». Это лишний повод пообщаться друг с другом и сблизиться.

Коммуникация строится не только линейно, то есть на уровне трайбов, но и между ними - люди объединяются в сообщества на почве личных и профессиональных интересов. Такие сообщества называются «гильдиями», где люди, помимо общего досуга, делятся знаниями и обсуждают общие задачи.

Ежедневно в офисе проходят митапы на разные темы: от дизайна до блокчейна. Их инициируют и проводят сами сотрудники.

Пространство офиса подчинено культуре

Всё устроено так, чтобы люди как можно больше общались лично, обменивались знаниями, договаривались и быстрее принимали решения, а не тратили время на длинные совещания.

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

Чаптер - группа специалистов одной области компетенций.

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

Участник команды - специалист, непосредственно участвующий в создании продукта команды в пределах своих компетенций.

Лидер трайба - сотрудник, отвечающий за управление продуктом или группой продуктов и достижение бизнес-целей этого трайба. Отвечает за ключевые показатели эффективности трайба в зависимости от его задач (например, P&L, NPS, доля рынка, надежность систем (uptime, количество инцидентов) и так далее).

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

Бэклог команды - приоритизированный владельцем продукта перечень всех требований к стриму трайба или программы, переданных в команду либо созданных внутри нее.

Спринт - такт работы команды, в ходе которого создаётся новая версия продукта. Жёстко фиксирован по времени в одну либо в две недели.

Релиз - выпуск готовой версии продуктов трайба.

Minimum Viable Product - минимальная первая версия продукта либо новой крупной функциональности в нём, внедряемая для ранней обратной связи от клиентов.

«Туту.ру»: естественная эволюция

Гибкая разработка пришла из 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-трансформации. И это показывает, насколько практика все еще далека от теории.

Колонка руководителя проектного офиса компании Phobos

В закладки

Руководитель проектного офиса компании Phobos Алексей Прокопенко написал для сайт колонку о том, почему он перестал руководить ИТ-проектами в «Сбербанк-технологиях» и ушел работать по Agile на аутсорсе. Автор также рассказал, почему система Agile не приживется в крупных банках.

Герман Греф съездил на экскурсию в Калифорнию и привез картошку Agile в Россию. Стоит заметить, что Россия идет с большим отставанием в вопросе разработки, внедрения и эксплуатации технологий. Причины очевидны - климат для бизнеса и инноваций в стране отсутствует. Но одна из главных причин - это непонимание скорости развития технологий.

Мы знаем много случаев создания революционных продуктов небольшой группой людей. Например, команда , создавшая первую версию OS Android, состояла из пяти человек. Dropbox и вовсе придуман одним Дрью Хьюстоном в автобусе. Для появления инноваций на западе есть развитая инфраструктура - хакатоны, акселераторы, инкубаторы, бизнес-ангелы, венчурные инвесторы, фонды, крупные компании и прочее, которые удовлетворяют спрос на технологии мира.

Сейчас технологии развиваются с фантастической скоростью. Количество научных статей за месяц только по data science превосходит человеческие возможности по их изучению. Это приводит к тому, что действительно прорывные технологические компании находятся в состоянии самой жесткой в мире конкуренции. Чтобы поддерживать свое лидерство, они должны быть быстрыми и мобильными. В современном мире невозможно стимулировать рост технологий, увеличивая количество людей и затрачиваемого капитала.

Мы строили, строили…

Я руководил ИТ-проектами в составе «Сбербанк-технологии». При его создании руководство «Сбербанка» имело четкую цель - централизовать ИТ-команду в отдельном подразделении. Банку нужно было делать разработку продуктов быстрой, а систему гибкой. Но работая в «Сбертехе», мы подчинялись самому «Сбербанку» и вынуждены были согласовывать каждый свой шаг.

Бесконечные заполнения документов, отправка их на согласование и ожидание ответа - все это замедляло процесс создания проекта и не давало стимула работать. Даже самого сильного специалиста с крутой идеей погубит осознание того, что эту идею не донести. Бюрократический ад не позволяет создавать продукт быстро. Государственный банк - большая неповоротливая монополия, которой трудно «перевернуться».

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

В итоге мы все подготавливаем, а показать не можем. Документы ждут одобрения неделю, две - так проходят три месяца. Сроки, бюджеты, планы теряют актуальность. Их требуется переделывать, пересогласовывать. А создание проекта так и не сдвинулось с мертвой точки.

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

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

На примере «Сбербанк-технологий» «Альфа-банк» создал свое подразделение - «Альфа-лабораторию», где отделили разработчиков приложений, мобильного банка, онлайн-сервисов и остальных. Но, как говорил и сам менеджер проектов «Альфа-лаба» Вячеслав Акулов: «Альфа-лаборатория» - это часть «Альфа-банка», сильно интегрированная с ним. Основной наш фокус - это фронт и обслуживание клиентов, однако есть огромная часть бэк-офиса банка. Безопасность, юристы, ИТ-системы и прочее - без них банк существовать не может". Поэтому, несмотря на появление отдельного подразделения, создание того или иного ИТ-проекта вынуждено проходить через всю систему банка, описанную выше.

Большие проекты и маленькие команды

Для меня очевидно, что каждое отделение компании должно быть обособлено. Если банк решил создать свое ИТ-подразделение, то его нужно сделать гибким. Оно не должно быть единой кирпичной стеной. Необходимо сделать так, чтобы после извлечения одного кирпича стена не разрушилась, а стала еще лучше.

Тот Agile, который хочет ввести Греф в «Сбербанк-технологии» (Sbergile) по щелчку пальца, не может быть гибким из-за самой структуры банка. Руководство государственного банка никак не может понять того, что для быстрого создания продукта нужна не только методология, но и разработка небольшими компаниями. Agile - это методология, которую нельзя надеть на всю структуру банка, как шапку на голову.

Хороший пример: для создания проекта «Сбербанк-онлайн» на Android компания наняла отдельную команду дизайнеров. Специалисты работали обособленно от остальных и смогли сделать действительно хороший продукт. Им просто никто не мешал. Команде не мешали внутренние согласования, подписание бумаг, ожидание комиссии. Дизайнерам не нужно было лезть во всю структуру банка. Благодаря этому они смогли создать проект быстро и качественно.

Мир уже давно начал поворот от количества в сторону качества - это естественный процесс развитых стран, которым требуется технологический фактор для роста их экономик. Лучшие решение для крупных компаний - это выделить spin-off или купить отдельную группу разработчиков, изолировать их от своей внутренней системы и дать быстро и направленно сделать продукт. Это станет возможным, только если компания сможет сделать всю систему гибкой.

Поработав в крупных компаниях, я увидел большую разницу в том, какой подход применялся для реализации той или иной поставленной цели. Я понял, что создание реальных проектов быстро возможно лишь при помощи гибкой Agile-системы, и ушел в Phobos. Это agile-outsource компания, которая специализируется на подборе проектной команды для реализации конкретной задачи. Команды, у которой есть опыт в реализации продуктов, а не написания документаций и согласования процессов.

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

Каким будет аутсорс завтра

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

В итоге нет ничего: ни плана, ни команды, ни проекта. Срок создания был большой, и руководство не было в курсе, на какой он стадии. Так как команда разработчиков тоже была большая, то таким сотрудникам было легко спрятаться за спинами своих коллег. Ведь никто не узнает, кто в итоге был виноват.

В маленьких аутсорс-компаниях все иначе. Не за кого прятаться. Если ты что-то не сделал, то будет понятно, кто подвел команду. Кроме того, если это Agile-аутсорс, то на согласование не затрачиваются месяцы, а разработчики могут показать результат работы очень быстро. Если в проекте будут неточности, например, со сроками - их легко изменить.

Мне очень нравится Agile таким, каким он был создан. Это очень простая методология, подробное описание которой умещается в шесть строк. К сожалению, тот Agile, о котором мы сейчас часто читаем - это очень сложное и непонятное порождение маркетологов и консультантов, которое не имеет ничего общего с методологией, созданной когда-то группой практикующих разработчиков ПО.

Зачем Сбербанку Agile? Это действительно важно или просто следование моде? Владимир Стасевич, руководитель сервисов «Сбербанк Онлайн», рассказывает в колонке для FutureBanking, чего удалось добиться департаменту с помощью этого подхода.

Agile для нас, «Банка XXI», - жизненно важная необходимость. Мы не можем работать по-другому. Кроме нас за внимание пользователей цифровых устройств борются ведущие интернет-гиганты. При этом они работают не так, как банки. Прежде всего, скорость вывода продуктов на рынок у них гораздо выше. Для нас это вызов, мы должны ответить ему, иначе потеряем клиентов.

Что нам мешает быстрее выводить продукты на рынок? Мой ответ - недоверие и барьеры в командах. Откуда берется бюрократия? Зачем она нужна? В случае, когда члены команды не доверяют друг другу, бюрократия - это способ быстро понять и «показать пальцем», кто был неправ. Так строится взаимодействие между IT и бизнесом, внутри команды IT, между разработкой и поддержкой и т.д. Если бы существовало доверие, то в идеале все, что нам нужно было бы, - это просто сидящие рядом люди, делающие продукт, запускающие их для клиента и собирающие обратную связь.

Почему в IT-компаниях вроде Google нет барьеров такого рода? В банке, в отличие от интернет-компаний, существуют ярко выраженные барьеры между IT и бизнесом - это разные департаменты. В технологических компаниях такого разделения нет, там это одна продуктовая команда, поэтому там нет соответствующих преград.

В 2013 году мы в «Банке XXI»начали переходить на Agile. Для нас это было критически важно, потому что существующее тогда положение дел не устраивало нас, не устраивало клиента - рынок уже продвинулся дальше, чем мы.

Изначально, когда мы пытались менять подходы, нас воспринимали как детей в песочнице, которые, вместо того чтобы делать свою работу, продумывать максимально детальное ТЗ, придумывают способы обойти процедуру.

Agile нам нужен совершенно по другой причине. Мобильный банкинг стремительно развивается. Но пока мы не покажем массовому клиенту продукт, мы не узнаем, правильно ли мы сделали или нет. Ответ появляется в конце процесса, а не в начале. Нельзя делать процесс слишком долгим. Работая по «водопаду», выход продукта происходит слишком редко, чтобы отслеживать реакцию пользователей и оперативно вносить изменения.

В 2013 году мы начали внедрять гибкие практики, и в середине 2014 года завершили процесс. У нас появились Jira, Scrum, все артефакты и процедуры, которые нам были нужны. Сейчас процесс полностью запущен, и мы проводим регулярные ретроспективы, вносим изменения, чтобы его регулярно совершенствовать.

Как мы решили вопрос с недоверием? В самом начале мы договорились между бизнесом и IT, что у нас больше нет бизнеса и IT. Теперь есть единая продуктовая команда, которая либо добивается результатов вместе, либо совершает ошибки, но тоже вместе. Если один этап не был отработан (например, есть баги или было сделано что-то лишнее), вся команда принимает это как свою ответственность. Для внешнего мира команда добивается успеха или совершает ошибки как единое целое.

Так мы создали доверие, горизонтальную команду равных партнеров. Это важно, потому что помогает уйти от контрактов, бюрократии, согласования через бумажки.

Очень важный этап: изначально мобильный «Сбербанк Онлайн» разрабатывался вендором. Мы поняли, что это нас существенно ограничивает. В Сбербанке это особенно сложная история, потому что это закупка, выбор и утверждение вендора - сложная процедура. На стороне вендора ситуация часто непрозрачная, мы не можем влиять на его команду.

В итоге было принято решение перейти на собственную разработку, задействовав «Сбербанк Технологии». Так у нас появилась возможность управлять людьми, построить нужную нам структуру, убрать барьеры и лишние сложности, которые появляются в случае закупочной процедуры. Минусы при этом подходе - есть множество вертикалей управления, действующих по своим процедурам, и свести разрозненных представителей этих вертикалей в единую команду становится сложнее.

Как один из инструментов мы создали культуру - взаимопомощь, ответственность, доверие. И это оказалось самым важным. Это то, что помогает добиться успеха, потому что как только люди перестают доверять друг другу в команде, мы начинаем двигаться к жесткому «водопаду» с трехсотстраничными ТЗ, и тогда о скорости вывода на рынок можно забыть.

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

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

Мы выделили отдельную практику дизайна - наравне с продуктологами и инженерами - как один из углов треугольника, который обязательно должен быть. Мы считаем, что у нас хороший дизайн, и это подтверждают отзывы и рейтинги. Как мы его сделали? Это, опять же, история про доверие. Очень часто нет взаимопонимания между разработчиками и дизайнерами. Разработчики показывают пальцами на дизайнеров и говорят: «Вы нарисовали космос». Дизайнер отвечает: «Я сделал красоту, они ее запрограммировали не так». Мы преодолели эту проблему, создав доверие, сделали так, что люди, которые занимаются дизайном и программированием, совместно разрабатывали дизайн-гайдлайны для «Сбербанк Онлайн». На выходе мы получили доверие между дизайнерами и разработчиками и продукты нового уровня.

У продукта есть несколько срезов. Первый срез - это функциональность, то есть полный набор функций, необходимых клиентам. Второй - удобство, эргономика, юзабилити. Мы выявили, что есть и третий срез. Он характеризуется такими словами, как «приятный в использовании», «эмоциональный». Людям, особенно в кризис, очень не хватает положительных эмоций. Казалось бы, какое банк имеет отношение к этому? Мы начали добавлять эмоциональные элементы и получили положительную обратную связь. Людям это нравится. Хочешь на море? Загружаешь к цели фото моря, надписи автоматически окрашиваются в его цвет. В зависимости от времени суток приложение при входе показывает «Добрый день», «Добрый вечер» и т.д. А ночью у некоторых иногда падает звезда.

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

Как в принципе можно решить подобную задачу? На нее невозможно написать ТЗ. Это работает благодаря тому, что мы собираем команду талантливых людей, даем им автономию, даем им поддержку, не критикуем без конструктива, создаем правильную среду. Тогда начинает рождаться что-то новое. Без Agile это невозможно. В «водопаде» все жестко и нет места свободным предложениям, не предусмотренным ТЗ.

Чего нам получилось добиться, в чем нам помогли гибкие практики и преодоленные барьеры доверия? Мы стали работать быстрее. У нас теперь четыре крупных релиза в год (раньше был один-два). Аудитория активных пользователей выросла до 12 млн для мобильных приложений. Рейтинг в App Store у нас сейчас 4,5 звезд из 5. В Android нас сейчас 600 тысяч оценок. Люди честно дают нам фидбэк. Удовлетворенность команды выросла, согласно опросу, с 4 до 9 баллов из 10. Agile помог нам стать лучше, делать качественный продукт и убрать лишнее из процесса.

Но пока все, что мы сделали, - подошли к переднему краю. Стали работать так, как работают лидеры. А задача стоит шире - как запрыгнуть за переднюю границу, делать то, на что будут равняться другие. У нас в Сбербанке именно такие цели. Мы очень много работаем над этой задачей, пытаемся нащупать будущее, которого пока не существует, придумать его с помощью креатива нашей команды.

«Инфостарт» получил комментарий от «Сбербанка» о запуске масштабной программы Sbergile, которая позиционируется как самое значимое событие в истории банка.

«Agile – может быть, самая радикальная трансформация в нашей истории, за все 175 лет нашего с вами развития», – сообщил глава «Сбербанка» Герман Греф на выступлении перед сотрудниками компании, видеозапись которого была опубликована на днях.

Термин agile происходит от Agile software development («Гибкая методология разработки») – это набор подходов к разработке ПО, который строится на принципах командного взаимодействия, быстроты, отсутствия формализма в общении с заказчиком и гибкости в изменении первоначального плана действий. Рабочий процесс разбит на короткие циклы, которые длятся обычно 2-3 недели. По окончании каждого из них подводятся промежуточные итоги, команды мотивируются на дальнейшую работу в том же темпе. Главным критерием результативности является работоспособный продукт, полученный в заданные сроки.

С момента появления манифеста agile было создано множество конкретных методик – Scrum (с англ. – «схватка»), XP («экстремальное программирование»), FDD (функционально-ориентированная разработка) и т.д. Они используются в ИТ-гигантах Google и Amazon, финансовых корпорациях Bank of America и HSBC и многих других компаниях-лидерах мировой экономики. Фредерик Лалу в книге «Открывая организации будущего» назвал такие компании «бирюзовыми организациями».

В России пионером в этой сфере среди крупных компаний является «Сбербанк». Его руководитель Герман Греф, считающий книгу Лалу одной из главных в бизнесе на сегодняшний день, рассказал в упоминавшемся выше видеоролике и более ранних выступлениях, как это будет выглядеть на практике.

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

Ранее принципы agile эпизодически использовались в «Сбербанке» – например, при разработке мобильных приложений. Весной этого года известная международная консалтинговая компания McKinsey проводила обучение топ-менеджмента банка, а в июне она же выиграла тендер на осуществление полноценного перехода, который получил название Sbergile (Sberbank + agile). Стоимость составляет около 350 млн рублей.

Редакция информационно-аналитического центра «Инфостарт» обратилась за дополнительной информацией в пресс-службу «Сбербанка», и там ответили следующее: «Вопрос действительно очень интересный, но вы рановато обратились. Пока что этот процесс находится на самой ранней стадии и, к сожалению, ничего к тому, о чем говорил Герман Оскарович, мы добавить не можем. Но если вы будете периодически обращаться к нам по этому вопросу, мы обязательно будем держать вас в курсе».

А мы, в свою очередь, будем держать в курсе наших читателей, поскольку подобных agile-проектов в России еще не было. Отметим, что в целом этой тематике уделяется внимание на наших ежегодных конференциях. Так, в 2013 году состоялся отдельный круглый стол по теме «Agile для внутренней разработки».

А на конференции INFOSTART EVENT 2016 DEVELOPER , которая пройдет совсем скоро – с 27 по 29 октября – предложен доклад бизнес-тренера и консультанта Ирины Шишкиной «Управление проектами по SCRUM». Если он соберет необходимое количество голосов, то вы услышите его на мероприятии. Проголосовать за него и любые другие понравившиеся выступления можно .