По следам конференции "Команды-2017. Опыт лидеров", которая прошла 29 ноября и на которой побывала Юлия Чемеринская

Самое практическое и конкретное выступление было у Наталии Даниленко, начальника управления по работе с персоналом Сбербанк Технологии. О нем и напишу. Ибо масштаб сберджайлизации абсолютно уникален для России: сейчас в agile--периметре уже более 11000 сотрудников группы компаний Сбербанк, из них более 6000 - это сотрудники ИТ-компании, в которой Наталия является руководителем HR-службы.

Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)

КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ

Манифест - манифестом, его уже все выучили:)
А вот конкретные цели. Чего в компании хотели достичь:

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

Представляете, 1300 команд? 10 тысяч человек? Масштаб вызывает уважение. А представляете, какую гигантскую работу пришлось провести, чтобы это стало возможным? Вот лишь четыре задачи трансформации. Каждая огромна, трудозатратна и с точки зрения перестройки крайне непроста. И самое сложное здесь - это культурная трансформация людей и компании.

Разумеется, возникает вопрос: при размывании роли руководителей как оно все управляется? И что сказали боссы, которых лишили должностей и званий? Сняли, так сказать, погоны? Отвечу сначала на второй вопрос. Разговоров пришлось провести много. Но теперь в подразделениях Сбербанка, перешедших в agile, больше нет отделов, управлений и департаментов в штатном расписании. Бывшие начальники отделов, управлений, департаментов теперь на экспертных должностях без подчиненных. Трайб - это организационный "мешок" в котором нет больше иерархической структуры и начальников.
Кстати, никто из них не уволился! В отличие от, к примеру, переходящего на холакратию Zappos, который потерял 50% своих менеджеров, не согласных с таким поворотом:)

УПРАВЛЕНИЕ В СБЕРДЖАЙЛ

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

1. Владелец продукта.

С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель - сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.

2 и 3. Лидер чаптера и Лидер компетенции

Лидер чаптера - это такой играющий тренер. У него 7 человек. На 50% он является лидером чаптера, а на 50% занимается развитием других. Например, у него 15-летний опыт работы с кредитными картами. Он и создает с командой продукт, и развивает сотрудников в других командах, кто тоже занимается кредитеыми картами.

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

От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.

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

ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ

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

То есть одним человеком на постоянной основе занимаются аж сразу три человека:

• владелец продукта смотрит на него с позиции создания самого продукта - качества и сроков,
• лидер компетенции - на его технические компетенции,
• аgile-коуч отвечает за его развитие в эджайл, его роли в команде, его потенциала.

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

ПРЕМИРОВАНИЕ

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

В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.

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

Ну и в заключении плюсы и минусы.

ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ

МИНУСЫ AGILE-ТРАНСФОРМАЦИИ

В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!

Если вам было интересно, ставьте лайки и делитесь постом, буду писать еще.
Удачи,
Ваша Чемеринская
jc@сайт

«Инфостарт» получил комментарий от «Сбербанка» о запуске масштабной программы 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». Если он соберет необходимое количество голосов, то вы услышите его на мероприятии. Проголосовать за него и любые другие понравившиеся выступления можно .

Герман Греф разбудил политиков и экономистов Гайдаровского форума 2016 года громким заявлением: «Те, кто не освоят Agile сегодня, в текущих процессах, лузеры завтра». Греф утверждает, что Agile выгодно применять в бизнесе. Послушаемся Грефа?

Agile

«Agile - серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированным (либеральным и демократическим) методом.

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки» (Википедия).

Намудрили, что только после трех прочтений доходит о чем речь))

Устареваем раньше запуска

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

Вот что пишет РБК про Сбербанк: «Тема Agile всплыла, когда Сбербанк создал централизованную платформу для своих отделений на основе решений Oracle, Microsoft и других IT-гигантов, но к моменту запуска эта система уже устарела.

Греф это признал и систему пришлось совершенствовать. В 2015 году «Сбербанк-Технологии» провели 27 тыс. изменений IT-платформы, а в 2016 году сделают 41 тыс. изменений. Пять лет назад программисты Сбербанка делали 500–600 изменений системы в год и налицо прогресс, но с передовыми компаниями IT-отрасли им не сравниться - Amazon делает 10 тыс. изменений своей платформы в день».

Amazon 10 тысяч раз в день меняет свою платформу.

Бери пример с маленьких и быстрых

Посмотрите как предприниматели открывают бизнес без денег. Сделали косметический ремонт, подобрали наскоро ассортимент. Корректируют и улучшают коммерческое предложение на ходу. Им не хватает денег, но действует они на удивление современно.

Нельзя бесконечно улучшать продукт и откладывать выход на рынок. Перфекционизм обернется устареванием продукта. Законченный продукт - роскошь в XXI веке.

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

Запускайте проект без перфекционизма и вылизывания.

Сергей Рыжиков, основатель 1С-Битрикс, пишет: «Пример, ставший хрестоматийным: когда в компании «Эльдорадо» решили сделать интернет-магазин, топовые руководители, включая генерального директора, совещались 10 часов - спорили, ругались, смотрели сайты похожих компаний на западе. Это еще на этапе утверждения дизайна. Как вспоминает участник встречи, гендиректору это надоело. Он попросил вывести на экран скриншот интернет-магазина Best buy и приказал магазин скопировать и через три месяца запустить, а если не получится - готовиться к увольнению.

Интернет-магазин «Эльдорадо» скопировали с Best buy. А потом переделали.

Сразу рассосались, интернет-магазин открылся 1 сентября 2006 года с кучей «глюков», но к концу года уже торговал без проблем и на Новый Год окупил затраты. Через полгода после запуска сайта они провели , потом еще и так далее - сайт дорабатывался и дорабатывается до сих пор».

Открывайтесь и доделывайте

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

Запускайте сырую версию и доделывайте продукт в движении. Конкуренты не поспеют, ведь в движущуюся цель попасть труднее.

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

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

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

В закладки

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

Сбербанк существует на рынке уже 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 - минимальная первая версия продукта либо новой крупной функциональности в нём, внедряемая для ранней обратной связи от клиентов.