Сбер: геймификация в сообществе практики по автоматизации DevOps CI/CD

Комментарий эксперта

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

Если говорить про классификации геймификации, то перед нами явно "серьёзная" геймификация, где акценты делаются не на игровых элементах и уж точно не на наградах. Акценты расставлены на факторах реального вовлечения мотивированных сотрудников, таких как вызов, признание, ощущение прогресса и развития собственных навыков. Единственный, слегка развлекательный элемент – это ранги, похожие на классификацию предметов в ролевых играх – Rare, Mythical, Legendary. Хорошо, что есть ясные критерии "прокачки" для сотрудника, что дает ему ясную систему карьеры в сообществе (например, написать 2 статьи, выступить один раз на митапе). К сожалению, здесь нет информации о том, как это выглядело для сотрудников – это ещё одна сложная неочевидная задача и от неё сильно зависит успех внедрения. 

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

Илья Курылев, эксперт в области геймификации, CEO студии Gamification Now!

Сбер — российский финансовый конгломерат, крупнейший универсальный банк России и Восточной Европы. По итогам 2019 года у Сбербанка 96,2 млн активных частных клиентов и 2,6 млн активных корпоративных клиентов. Среди крупнейших банков мира по размеру активов находится в восьмом десятке.

Задача

Создать сообщество инженеров-практиков.

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

Ключевые проблемы

  • Много разрозненных источников информации с разными how-to-статьями, CookBook-ами, инструкциями под каждый продукт и команду;
  • Команды состоят из сотрудников, имеющих разный уровень инженерной зрелости;
  • Нет единого места для обмена опытом и знаниями. В результате у команд низкая осведомленность о формальных требованиях и существующих лучших практиках;
  • В процессе активной работы люди не могут посвятить достаточное количество времени на обмен опытом, своими наработками, практиками друг с другом;
  • Длительная адаптация и высокий порог входа для новых сотрудников;
Если понравится кейс, можем сделать для вас геймификацию не хуже. От сбора требований и написания ТЗ до разработки решения и загрузки на наши или ваши сервера.
Назначить встречу

Комментарий эксперта

Решение

О решении рассказывает Рашид Галиев – руководитель группы развития методологии DevOps и внедрения инженерных практик CI/CD, эксперт команды ядра сообщества DevOps в Сбере:

После осмысления этих ключевых проблем возникло понимание необходимости создания площадки для обмена опытом, через которую сотрудники получат возможность меняться практическими наработками и вместе успешно решать возникающие проблемы и вопросы. Данная площадка, в нашем понимании, должна быть представлена сообществом практики в домене экспертизы DevOps CI/CD, главной целью которого является обмен практическими наработками. Эксперты и участники из каждой команды и трайба могут войти в сообщество, чтобы внести свой вклад в его развитие.

Факторы вовлечения участников

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

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

Другими словами, участник должен прозрачно ощущать свой прогресс и чувствовать, что сообщество обеспечивает его определенным признанием.

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

Когда мы создавали свое сообщество в Сбере, мы пошли по трайбам и командам, начали искать экспертов, желающих участвовать на старте сообщества, придумали концепцию, определили ряд ключевых задач - Рашид Галиев – руководитель группы развития методологии DevOps и внедрения инженерных практик CI/CD, эксперт команды ядра сообщества DevOps в Сбере.

Геймификация и достижения

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

Здесь мотивацию можно подразделить на материальную и нематериальную:

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

Есть система достижений и система рангов, за которые предусмотрена какая-то награда.

Система достижений может выглядеть, например, следующим образом: Ambassador занимается привлечением новых людей в сообщество, Wikinist пишет статьи, Spokesman участвует в митапах и т. д.

Говоря же о возможных рангах, их можно представить следующим образом:

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

Источники:

  • Создана площадка для обмена профессиональной информацией и опытом;
  • Появилась "единая точка правды";
  • Разработаны подробнейшие how-to (step-by-step) по реализации CI/CD;
  • Появилось место для получения оперативной помощи в решении возникающих проблем;
  • Был снижен временной порог входа для новых сотрудников и команд в 3 раза.

Характеризуя участников сообщества на текущем этапе, можно привести следующую диаграмму:

Результаты

Результаты

Используемые механики

Похожие кейсы