sbergile периметр что это значит
Agile в Сбере: как понять, что происходит?
В декабре 2020 мы провели Sbergile Talks (да, давно это было), нашу первую онлайн-конференцию про Agile в Сбере. Три потока, 31 доклад, спикеры из крупнейших отечественных и иностранных компаний, которые так или иначе связаны с Agile. Нас слушало порядка 10 тысяч человек. Я хочу пробежаться по основным моментам и рассказать, что же там было.
Давно не секрет, что Сбер провёл одно из самых масштабных Agile-преобразований в мире. Об этом неоднократно рассказывали топ-менеджеры в различных СМИ. Итак, что важного в Сбере произошло за эти четыре года? Мы радикально ускорились. А скорость — это один из ключевых факторов развития для Сбера. И он жизненно необходим технологическим компаниям для успешного достижения поставленных целей. Особенно таким крупным компаниям, как наша. И да, Agile действительно ускоряет разработку продукта и даёт возможность компании быть в целом гибче. Поэтому многие так или иначе пытаются внедрить похожие практики у себя, но не у всех получается успешно. Мы и другие игроки рынка каждый год открыто рассказываем о возможных ошибках, накопленном опыте и практических примерах изменений.
Так почему же Agile так интересен российскому рынку?
Agile в России
Ещё пять-семь лет назад в России следовали ценностям, озвученным в Agile-манифесте, в основном ИТ-компании. Перестраивать mindset, тем более в крупных организациях, как наша, никто не спешил.
Тогда решения в Сбербанке принимались медленно, а ИТ-архитектура была монолитной. Это абсолютно нормально для компаний такого размера. И это не российский подход или какие-то особенности менталитета: плюс-минус так выглядят крупные игроки в большинстве отраслей экономики во всём мире. При этом Сбербанк был коммерчески успешным банком.
Но, чтобы стать успешным ИТ-игроком и конкурировать не только с банками, но и с международными технологическими гигантами, необходимо было ускориться. Поиск инструментов и подходов, которые бы помогли достичь столь амбициозной цели, привёл нас к Agile.
По нашему мнению, Agile — это работающие практики, которые способны запустить процесс изменений в компании. А в бизнесе успешны те компании, которые готовы меняться и подстраиваться под запросы рынка.
Где смотреть доклады?
Какие доклады стоит посмотреть и почему?
В направлении «Организация» — взгляд бизнеса на управление в целом.
Что такое Sbergile и чем он отличается от Agile
Сбербанк работает по Agile. Точнее по Sbergile. Но даже опытные специалисты не всегда улавливают разницу, а новички вообще склонны впадать в ступор. Мы попросили Agile-коучей Сбербанка Анну Родионову и Максима Зотова на пальцах объяснить, что все это значит и зачем нужно.
Много лет сфера IT спокойно жила без Agile. Но со временем программ стало больше, кодовые базы сложнее, пользователи избирательнее, а мир стал меняться так быстро, что цикл разработки в несколько лет перестал быть актуальным. Поэтому в 2001 году был принят манифест гибкой разработки. Он описывает ценности и принципы, которыми руководствуются команды и люди в своей работе.
Agile не включает методов, советов, описаний или точно определенных процессов и ролей. В Agile-манифесте всего 4 ценности и 12 принципов.
Ценности звучат так:
То есть, не отрицая важности того, что написано в каждом пункте справа, мы всё-таки больше ценим то, что слева. Например, последняя ценность о готовности к изменениям не означает, что нужно работать по принципу «на месте разберусь» и не планировать вовсе. Agile не про хаос. Просто при первоначальном планировании большого проекта сложно учесть всю нюансы и непредвиденные обстоятельства. И Agile за то, чтобы вносить адекватные изменения в план, а не просто следовать «духу и букве» плана любой ценой.
C Agile немного разобрались. Теперь давайте о Sbergile.
Для работы команды нужны организационные рамки и описание процесса работы. Для совместной работы нескольких команд должны быть договоренности внутри команд и правила взаимодействия с другими командами. Для большой организации таких договоренностей должно быть ещё больше. Эти наборы договоренностей можно назвать фреймворком.
В отличии от Agile в Sbergile гораздо больше описаний, советов, рекомендаций, процессов и инструментов.
То есть фреймворк — это свод правил, договоренностей и методик, по которым взаимодействуют люди и команды. В отличии от Agile в Sbergile гораздо больше описаний, советов, рекомендаций, процессов и инструментов. Но каждый шаг они не описывают — иначе получился бы многотомник вроде Оксфордского словаря.
Agile-трансформация Сбербанка — одна из самых масштабных в мире, и она была постепенной. В 2016 году первые 600 человек начали работать по Agile. Специально для Сбербанка был разработан свой фреймворк работы — Sbergile. Он основывается на ценностях и принципах Agile, дополненных правилами, которые описывают основные моменты взаимодействия, синхронизации и сотрудничества.
За основу был взят известный фреймворк работы команды — Scrum. О нем мы расскажем в следующий раз, пока можно посмотреть описание.
Суть в том, что каждая команда работает над своим продуктом и старается сделать всю связанную с ним работу сама. Команды объединяются в трайбы, которые отвечают за свою область бизнеса, например, call-центр. Трайбы, в свою очередь объединяются в блоки, например, розничный. А они, в свою очередь, вместе и территориальными подразделениями образуют Сбербанк.
Фреймворк Sbergile развивается с учетом пожеланий сотрудников и отражает изменения в банке, в мире, технологиях и на рынке. С 2016 года количество сотрудников, работающих в соответствии с Agile-принципами, выросло с 600 человек до 25 000. Это позволяет банку выпускать продукты быстрее, делать их более клиентоориентированными и быть хорошим работодателем.
Отметим еще, что Sbergile используется только для изменений в существующих продуктах и создания новых. А территориальные подразделения работают по стандартным процессам с существующими продуктами.
И ещё раз коротко: Agile — это общие рекомендации, Sbergile — конкретные правила, основывающиеся на этих рекомендациях.
HR-СТАТЬИ
Agile-трансформация в Сбербанке
По следам конференции «Команды-2017. Опыт лидеров», которая прошла 29 ноября и на которой побывала Юлия Чемеринская
Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)
КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ
УПРАВЛЕНИЕ В СБЕРДЖАЙЛ
1. Владелец продукта.
С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель – сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.
2 и 3. Лидер чаптера и Лидер компетенции
Лидер области компетенций, к примеру, мастер 80-го уровня в IOS, занимается только развитием этой техкомпетенции у 24 сотрудников, за которых он отвечает. Грубо говоря, учит писать и проверяет их IOS-коды.
4. Agile-коуч
От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.
Кто же принимает решения и несет ответственность?
Решения принимает вся команда, результаты оцениваются общие.
Есть правила работы частично на основании методологии, частично создаются свои законы.
ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ
Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.
Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.
ПРЕМИРОВАНИЕ
До недавнего времени, а именно до октября этого года, в Сбербанке была квартальная система премирования, основанная на целой многоступенчатой системе KPI. С октября от нее отказались, потому что в понимании Наталии (я, кстати, тоже очень поддерживаю) материальное стимулирование не работает на сотрудниках, от которых мы ждем интеллектуального продукта, креативности и инновационности. Оценка по KPI превращается в профанацию, все пытаются «обмануть систему» или «прогнуться» под нее, убивая инновации, риск и творчество.
В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.
Кстати, если вы хотите научиться разрабатывать эффективные схемы оплаты, в том числе для айтишников, добро пожаловать к нам на курс Менеджер по компенсациям и льготам.
Ну и в заключении плюсы и минусы.
ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ
МИНУСЫ AGILE-ТРАНСФОРМАЦИИ
В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!
SBERGILE КАК СЕРВИС, ИЛИ ОПЫТ РЕШАЕТ ВСЁ
За последние пять лет Сберу удалось невероятное — провести одну из самых масштабных Agile-трансформаций в мире. После многочисленных запросов Сбер стал делиться своим опытом с государственными и коммерческими организациями. Рассказываем о том, как развивается новое консалтинговое направление Сбера — Sbergile как сервис.
Масштаб крупнейшей Agile-трансформации Сбера лучше всего оценивать сквозь призму цифр.
Уже пять лет Agile-трансформация Сбера в фокусе внимания других компаний на рынке. В течение этого времени в Agile Home Сбера с визитами приезжали лидеры крупнейших компаний. Несмотря на то, что экспертов Сбера постоянно просили поделиться опытом и помочь с трансформацией других компаний, потребовалось время, чтобы накопленные знания оформить в полноценный консалтинговый продукт.
Ситуация начала меняться в 2020 году, и этому поспособствовало два основных фактора.
Во-первых, Agile-трансформацией был охвачен уже весь периметр change-деятельности Сбера. Это позволило высвободить ресурсы, чтобы переосмыслить пройденный Сбером путь: объединить в продукт успешный опыт и реально сработавшие практики.
Во-вторых, появился серьезный запрос на цифровизацию и использование гибких способов проектирования и разработки ИТ-решений со стороны государства и крупных корпораций.
Появился сервис Agile-консалтинга «Sbergile как сервис», который занимается комплексными Agile-трансформациями для клиентов
«Наша задача — не просто открыть клиентам мир гибкого создания продуктов, не просто провести обучение, а, прежде всего, превратить эти знания в реально используемые навыки. Мы показываем компаниям новый способ работы, помогаем найти, где в их индустрии Agile максимально полезен, а затем «за руку» проводим их по пути первых месяцев работы продуктовых команд» (Антон Савельев, лидер “ Sbergile как сервис”)
Как Сбер запускает Agile в других компаниях
Этап 1
На старте проводится «диагностику», чтобы понять запрос и актуальную ситуацию в компании. Для проведения серии интервью с руководителями и подготовки отчёта с рекомендациями, требуется около двух недель.
Этап 2
На следующем этапе один из распространённых запросов клиентов – быстро «попробовать Agile», чтобы понять, действительно ли им подходит гибкая методология управления. Особенно это актуально для индустрий, в которых применение гибких практик еще не стало нормой.
Этап 3
На следующем этапе проводится обучение сотрудников в формате онлайн и очных мероприятий. Тренинги адаптируются под заказчика с учётом результатов диагностики. Прежде всего, обучение проводят для владельцев продуктов и участников команд – людей, которые в первую очередь будут использовать гибкие практики.
Этап 4
Пришло время определить состав команд, их цели, сформировать бэклог, построить USM (user story map). Только после этого команды готовы к работе в новом подходе. В Сбере, где в короткий срок появилось около 3000 продуктовых команд, уже есть готовые алгоритмы по запуску и выстраиванию процесса.
Этап 5
На этом этапе Agile-коучи помогают настроить рабочие ритмы, заполнить календарь регулярных событий, выбрать Scrum-мастера, составить план обучения и прочее. Главная задача коучей – способствовать тому, чтобы все ранее полученные знания превратились в устойчивые навыки.
ДНК (Деление на команды) – визуализация взаимосвязей людей и команд
На рисунке – граф, визуализирующий межкомандное взаимодействие в Дивизионе развития и сопровождения производственного процесса (SberWorks) Сбера
Мы решили разобраться, как выглядит общение участников команд в цифровых каналах Сбера, а точнее, в трех ключевых инструментах производственного процесса:
Изучив связи, мы присвоили веса самому источнику данных, конкретным видам связи и на базе данных построили граф взаимодействий. При формировании графа по источникам, которые были упомянуты выше, все-таки принимается во внимание, что сотрудники обсуждают именно рабочие вопросы, а не котиков.
В итоге, получили следующую визуализацию коммуникаций:
Поиск точки отсчёта
Основа командной работы – общение. Можно было бы подумать, что, как людей объединили, так они и будут взаимодействовать друг с другом, но есть нюансы.
Как «читать» ДНК?
ДНК рассказывает нам, как фактически работают люди, как они взаимодействуют друг с другом в рабочем процессе, в том числе и за пределами Sbergile-периметра.
Например, при создании нового трайба (группы взаимосвязанных команд, сформированных вокруг определенного продукта и бизнес-цели, отвечающих за общий бизнес-результат) мы сможем понять по цифровым следам уже сложившиеся связи и использовать эту информацию при создании оптимальной структуры.
С другой стороны, появилась новая задача – «нарезать» команды так, чтобы улучшить lead time (LT), то есть время от начала разработки до вывода продукта в ПРОМ. LT делится на два этапа: непосредственное время команды и время ожидания. Последнее, в свою очередь, зачастую свидетельствует о зависимостях между командами.
Когда же мы визуализируем взаимосвязи таким образом, то можно задаться вопросом: а как нам синхронизировать эти команды, как лучше объединять людей, чтобы сделать минимальным количество внешних (по отношению к команде) связей?
Можно увидеть, что участники команды не общаются друг с другом, при этом активно взаимодействуют с внешними контрагентами и экспертами, то есть выходят за рамки своего круга.
Встречаются «песочные часы» – так мы называем сотрудника, который в равной степени взаимодействует с двумя командами. И нет однозначного решения, в какую из них его нужно поместить. Он может быть владельцем продукта, который пилят обе команды, а может быть уникальным экспертом – «узким горлышком». Такую связь нужно как-то разрывать: «размножать эксперта», пересматривать подход, но это решается уже за пределами нашего продукта.
Есть еще «люди-снежинки». Это, когда группа людей, которая между собой никак не общается, объединена через центр – конкретного специалиста, с которым они взаимодействуют.
Интересно наблюдать, как участники команд разбиваются на несколько групп, при этом не взаимодействуя друг с другом. Хороший повод пообщаться с командой и понять, что им мешает работать сплочённо.
Можно увидеть и «одиночек», которые пока не обзавелись связями. Ничего страшного, скорее всего, это всего лишь новички, и у них всё впереди.
Выявляя подобные исключения, мы получаем возможность изменить ситуацию, подключить административный ресурс, чтобы помочь командам эффективно решать свои задачи.
Что под капотом?
В бэке стандартно – ELK-Stack (Elasticsearch, Logstash и Kibana).
На React мы написали приложение, которое умеет забирать из индекса в Elastic через самописное API данные, к которым был применен алгоритм кластеризации, тем самым отсекая слабые (незначимые) связи и визуализировать эти данные в виде плотных сообществ.
Вы спросите, как мы отсекаем незначимые связи? По результатам предварительного исследования мы определили два самых сильных алгоритма.
ACY – алгоритм от Яндекса. Агломеративная кластеризация. Подробнее в статье тут.
MCL – марковский процесс, случайные блуждания по Маркову.
Весь алгоритм описан на следующих страницах Марковский алгоритм кластеризации и MCL — a cluster algorithm for graphs. В итоге применяем именно его.
Алгоритм кластерного анализа основан на потоке (случайном блуждании) в графе. Изначально разработан для выделения кластеров в простом графе, однако может быть применен к любым объектам, для которых задана матрица сходства/различия. MCL является быстрым и масштабируемым алгоритмом кластеризации. В нашем случае мы доуточнили его пятью модификациями.
Мы запускаем его для того, чтобы выделить части плотно связанных между собой членов мини сообществ. Например, у нас есть граф на 100 человек. Мы хотим выделить группы не более 12 человек, состоящие из тех, кто наиболее плотно друг с другом взаимодействует при решении рабочих задач.
Алгоритм продукта даёт возможность минимизировать количество внешних зависимостей между группами, найти узкие места и предложить варианты для дальнейшей оптимизации структуры команд и трайбов.
Какие планы по развитию?
Мы в стадии пилотирования продукта: вовлекаем команды в изучение ДНК и собираем обратную связь, чтобы понять, куда двигаться дальше, какие фичи реализовать в первую очередь.
Но даже сейчас это работающий инструмент, который можно использовать, когда требуется подготовить и спланировать оптимальную организационную структуру. Он позволяет снизить административную нагрузку на Agile-коучей и всех тех, кто задействован в процессе «нарезки» команд, за счет полуавтоматического получения данных о коммуникациях или существующих зависимостях по тому или иному продукту или процессу.
В перспективе мы постараемся еще глубже погрузиться в наши источники, чтобы обогатить данные о связях. Хотя и сегодня открываются интересные вещи, которые могут быть полезны как существующим командам, так и их руководителям.
Спасибо Сергею Артюхову, исполнительному директору, лидеру кластера «Аналитика и визуализация данных производственного процесса» в Сбере и его коллегам за то, что поделились рассказом о новом продукте для кластеризации команд.