Всем привет! Меня зовут Ртищев Евгений, в Сбертехе я работаю руководителем по развитию ИТ-систем на проектах Единой Фронтальной Системы. 24 сентября я выступал на конференции Saint Teamlead Conf 2018 в Санкт-Петербурге. Мой доклад был о проведённой в команде игре, которая сильно облегчила мою головную боль как руководителя, помогла с мотивацией и дисциплиной. Публика очень тепло приняла тему и задала много интересных и ценных вопросов.

Мне показалось, что некоторые моменты в докладе были упущены. Поэтому в статье я решил ещё раз рассказать о своём эксперименте и поделиться результатами. Кто не был на конференции и хочет прочитать рассказ об альтернативном инструменте быстрого Performance Review, управлении командой через игру, повышении вовлеченности в развитие продукта, а также о том как совмещать понятия «геймификация» и бюрократию в больших компаниях – welcome.

Интро

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

Проблемы и боль

Когда я пришёл в Сбертех, стартовала новая внутренняя программа, и необходимо было быстро собрать команду мобильной разработки. Спустя месяц после моего выхода мой руководитель (принимавший меня на работу) уволился, и все его задачи и проблемы стали моими. Честно признаюсь, до этого у меня был небольшой опыт в руководстве командой из двух человек в течение года. Скорее это было похоже на техническое менторство и наставничество разработчиков-новичков. Коллектив достаточно быстро увеличился до 11 человек, я полностью ушёл от написания кода, проработки архитектуры и других хард-задач. Я стал подвержен эмоциям и мои принципы управления соответствовали ситуационному менеджменту, а нужно было смотреть более долгосрочно, развивать людей в команде, растить новых лидеров, отмечать и поощрять тех, кто хорошо тянет, а также идентифицировать и наказывать «плохишей» и лентяев.

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



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

Первым шагом была смена языка, на котором мы общались на agile-церемонии – мы стали проводить стендап на английском. Решениезашло на «ура»: многие готовили текст заранее, длительность сократилась (английский язык лаконичнее и все стремились сконцентрироваться только на сути).

И тогда я понял, что нужно экспериментировать

Формулируем проблемные зоны

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

Ранжирование участников команды

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

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

Поощрения за помощь в развитии продукта

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

И мне, как владельцу продукта, очень хотелось, чтобы участники команды не только исполняли поставленные задачи, но и помогали продукту расти, приносили новые свежи идеи, забирали часть моих обязанностей и головной боли. Например, много времени уходило на сбор требований, их проработку и декомпозиции на конкретные логичные и последовательные задачи. Другой проблемной стороной были поддержка продукта и общение с пользователями. Наш продукт – это внутренняя библиотека для разработки мобильных iOS-приложений (об этом уже есть целая серия статей на Хабр). И наши потребители – это другие прикладные команды. В какой-то момент количество наших пользователей достигло примерно 120 разработчиков, дизайнеров и менеджеров.  И мне не хватало даже 12 часов в день, чтобы вести коммуникацию со всеми. Мне очень хотелось, чтобы команда начала активно в этом помогать.

Точность планирования и определение тайм-киллеров

Долгое время наши показатели Story Point-ов (далее SP) сильно прыгали из спринта в спринт. Каждый раз подобная ситуация происходила либо из-за прилетающих дефектов с ПРОМа, либо
каких-то незапланированных сверх-важных задач напрямую от руководства. Ребята регулярно жаловались и сами были недовольны, потому что не могли понять, куда ушло время, была ли вновь полученная задача важнее спринтовой, какое значение она принесёт продукту. Добавлял сложности и общепринятый подход оценивать дефекты в 0 SP – я всегда добавлял в спринт
определённое количество дефектов, чтобы их можно было обменять с критичными, которые прилетали прямо во время спринта.

Что-то свежее и новое

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

Немножко о команде

Хочется немножко больше рассказать о команде: владелец продукта, аналитик (он же скрам-мастер) и 9 iOS-разработчиков. Понимаете теперь, почему так хотелось понимать расстановку сил в такой однородной команде?



Немного социальных данных: у нас было две девочки, а возраст участников находился в
диапазоне от 22 до 33. Сферы интересов были различными, но мы старались устраивать
общие командные активности: регулярные настольные игры, мини-корпоративы,
совместные походы на конференции и т.д.

Теперь все майнят MotC

Я всегда испытывал огромный интерес к гейм-индустрии. В детстве я выстраивал целые миры из лего-кубиков, рисовал на бумажке простенькие настольные игры, постарше увлёкся 3D Max, потом начал осваивать простые инструменты для создания компьютерных игр – типа Dark Basic или Game Factory. Много времени я провёл в ММО, а из самого странного – я сделал собственную версию игры Диабло 2 в редакторе карт для Warcraft 3 (она даже пользовалась успехом в городской локальной сети).

Как вы поняли, в очередной раз мне захотелось создать игровой мир и погрузить
участников команду в real-time challenge



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

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


Львиная доля моего доклада на Saint Teamlead Conf была посвящена как раз созданию игры и выполнению всех необходимых пунктов (геймплей, проблемы баланса, психология игроков 4-х типов и т.д.). Не буду транслировать всю ту информацию в текст – надеюсь, что заинтересованные читатели подождут полгода, когда olegbunin сделает записи публичными (или напишите мне в приват). А еще можно прийти послушать на тимлид-конференции 2 ноября.

Как получить MotC?

Если коротко, то получить виртуальные монеты можно за выполнение определённых действий:
1. Закрытие спринтовых задач. Это важно и нужно поощрять, ведь это то, что приносит business value. 1 Story Point приносил 1.2 MotC. Почему не ровное значение? Да просто: во-первых, magic-число уже говорит о том, что есть какой-то коэффициент, а обозначив его наличие, всегда можно будет аккуратно его поменять (для корректировки баланса). Плюс MotC – целочисленные, т.е. это ещё и дополнительный стимул для того, чтобы закрывать большее количество сторипоинтов. За 3 вы получите 3 Motc, а за 5 уже 6.

2. Исправление дефектов. Раз нет оценки в SP, так пусть будет в MotC. Разный уровень критичности имел разный вес в плане MotC. Но опять же для поощрения к исправлению дефектов (что не всем разработчикам придётся по душе) один закрытый баг приносит всегда дробное количество монет, которое могло бы округлиться в меньшую сторону, если не закрыть ещё один дефект.

3. Исправление внеспринтовых задач. Помимо дефектов были и другие срочные задачи: сломался билд-сервер, упали UI-тесты, прилетела срочная и важная задача от руководства и многое другое. Теперь за них человек получал MotC и тем самым компенсировал недобор SP в спринт.

4. Рейтинги и звания. Было придумано аж 4 категории: чемпион SP, максимизатор вклада (максимальное количество MotC), герой спринта и командная награда. Принцип первых двух, думаю, должен быть понятен из названия, с остальными – интереснее. Герой спринта выбирался командным голосованием на ретро, и это была одна из самых почётных наград в коллективе как и по количеству MotС, так и с точки зрения престижности и значимости. Наличие общекомандной награды – ключевая, т.к. она показывает, что важен не только личный результат, но и общий результат всей команды. Было придумано три градации: обычный спринт, топ-спринт и провальный спринт. Обычным считался спринт, если закрывалось больше 78% бэклога спринта, если было 100% – то это топ-спринт. В случае топ-спринта вся команда получала щедрый прирост. Но была и обратная сторона монеты – это провальный спринт.

Майнинг отрицательных MotC

MotC имеют значение. Поэтому можно было получить и монеты с отрицательным значением. Какие анти-заслуги приводили к этому:

1. Провальный спринт. В случае выполнения менее 78% бэклога спринта вся команда получала отрицательный майнинг.
2. Вскрытие дефекта. Если был однозначный дефект по влитой задаче, то отрицательные MotC зарабатывал разработчик, вливший Pull Request, а также его ревьюверы.
3. 3. Была ещё дополнительно придумана накопительная система за опоздания на стендап или невнимательность к коллегам. Действовала она по принципу «3 в ряд». 3 одинаковых значка схлопывались в новый, при котором происходил отрицательный майнинг. Действовало правило амнистии: при получении в спринте более 25 MotC, схлопывание не приводило к отрицательному майнингу, но обнуления значков не происходило.

Как потратить MotC?

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

Что было в магазине?

1. Возможность уйти с работы пораньше или прийти попозже. Самый главный ходовичок.
2. День удалённой работы.
3. Возможность приоритетного выбора задачи на планировании.
4. Рекомендация в LinkedIn.
5. Выбор модуля для разработки на Swift. Весь код был на Objective-C, а ребята очень хотели бы развиваться в Swift.
6. Билеты на конференции (при их наличии).

Были и другие позиции, но здесь самое важное правило – гарантировать возможности их покупки, иначе произойдёт подрыв доверия.

Корректировки по ходу игры

В ходе эксперимента в определённые моменты стали заметны проблемы первичного баланса.
Какие именно?

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

2. Обесценивание задач. Со временем определённые повторяемые задачи становятся проще в выполнении. Например, у нас была процедура по выпуску новой версии фреймворка (наш продукт) – которая занимала приблизительно 1.5-2 часа чистого времени. С развитием DevOps её временные затраты сократились до 30 минут. Соответсвенно упало и вознаграждение в MotC. Или периодически возникали задачки по подготовки новых форм отчётов или статусов. Сложно делать это в первый раз, но повторно выполнять проще – поэтому и оценка в монетах уменьшалась. Команда воспринимала такие корректировки адекватно.

3. Двойные очки за дефекты. Пример, чтобы показать что в каждой команде будут непредвиденные ситуации, и правила нужно «тюнить». Мы долгое время сидели на automatic cascade merge (т.е. при вливании hotfix возникали автоматические мерджи в вышеидущие release-версии и develop). В какой-то момент мы решили прекратить эту порочную практику из-за постоянно висящих merge-конфликтов на develop-e и перешли к идее дублирования задач по всем версиям куда нужно разлить изменения. Это привело к появлению множественных однотипных задач в JIRA:



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

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

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

Результаты и наблюдения

Весь эксперимент длился 9 спринтов (4 месяца). Всего было замайнено 968 MotC, а потрачено 262. Было 3 топ-спринта, один и тот же человек становился героем спринта 4 раза, распределение MotC по команде выглядело следующим образом:

	MotC	MotC+
Игрок 1	104	86
Игрок 2	203	203
Игрок 3	148	128
Игрок 4	65	47
Игрок 5	172	92
Игрок 6	58	40
Игрок 7	68	68
Игрок 8	95	77
Игрок 9	55	55

Вот он – тот единственный индикатор, который я так хотел создать.

Кстати вся база хранилась в Numbers (xls для MacOS) и рассылалась по участникам раз в неделю (в момент эмиссии MotC на ретро). Было 5 страничек со сквозными формулами: история майнинга, история покупок, магазин предложений, детализация майнига и сводная таблица.

Мне задавали вопрос на конференции – не уходило ли много времени на её ведение.
Ответ – нет. Наоборот, я стал меньше тратить времени на заведение задач в JIRA по
каждой мелочи и на синхронизацию с блокнотиком, в который я исправно записывал
все делегированные задачи. Таблица под названием «Детализация» как раз являлась
новым вида блокнота, в которой я мог записывать поручения, а при их исполнении
записывать награду. Ниже пример за один спринт на одного игрока:

MotC	Майнинг
1	Предложение задачи Х
1	Помощь Макову с обновлением иконки библиотеки для демо
2	Подготовка репозитория с boilerplate для ИС (демо для руководства)
2	Подготовка XSD-схемы для примера ИС, а также консультация по boilerplate
3	Закрытие дефектов
16	Конвертация 14 SP
4	Максимизатор SP

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


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

Я не пытаюсь доказать, что это правильный вариант менеджмента или идеальный инструмент – это всего лишь пример как разнообразить свой стиль управления и в хорошем смысле «взбодрить» команду. Не бойтесь экспериментировать, а главное, всегда стремитесь оптимизировать свои процессы, создавать новые правила и методики. С удовольствием бы послушал ваши примеры или подходы к Performance Review и мотивации команды.

Спасибо за прочтение!

P.S. Вы можете добавляться мне в друзья в Facebook или LinkedIn, а также прийти послушать выступление по этой теме на ближайшей тимлид-конференции 2 ноября.