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

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

И никакой магии, только ловкость рук.

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

Договоримся о терминологии

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

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

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

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

Предыстория

Когда любая компания стремительно развивается по всем горизонтам, сообразно увеличиваются не только ресурсы всех её отделов, но и появляется совершенно новый вид проблем, которые просто не могут проявиться до определённого момента. В нашем случае этот момент был комплексным явлением, но переломным событием суждено было стать выходу нового релиза нашего флагманского продукта Veeam Backup & Replication, тогда под номером 7.

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

Диспозиция

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

На Хабре уже было несколько статей, посвящённых техподдержке Veeam (ссылка раз, ссылка два), и те, кому интересно узнать больше, могут обратиться к ним, но если кратко, то мы очень гордимся нашим уровнем удовлетворённости клиентов (метрика с неоднозначно переводимым названием Customer satisfaction). По подсчётам, основанным на отзывах, которые могут оставлять клиенты после завершения каждого кейса, у нас этот уровень уверенно держится на уровне 98% — 99%, что для индустрии является очень высоким показателем. На практике это значит, что, в первую очередь, мы работаем с конкретным человеком, а не с обезличенной проблемой. Нам важно послевкусие, которое остаётся у клиента после обращения в техподдержку. Такое отношение даёт клиенту ощущение вовлеченности инженера в его конкретный случай и повышает взаимный комфорт во время разговора, т.к. изначально все клиенты несколько раздражены.

Измерить уровень удовлетворённости клиентов от обращения в международный саппорт — задачка, прямо скажем, не тривиальная. Это не уровень продаж, который можно померить линейкой. Его нельзя измерить количеством положительных отзывов поскольку, например, испанцы, все как один, пишут отзывы, причем им гораздо важнее, о чём говорил инженер, пока сервер перезагружался, чем качество полученной информации. С другой стороны, от IT специалистов пространства СНГ отзывы приходят только в случае неудовлетворённости клиента. Писать положительные отзывы у нас, видимо, всё ещё не принято. Поэтому приходится крутиться и изобретать взвешенный метод оценки.

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

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

Вопреки распространённому мнению, невозможно искусственно повысить мотивацию сотрудника. Если ему надоела его сфера деятельности, то скоро он перестанет этим заниматься, и, если и не полностью, но его производительность упадёт до минимума. Бесполезно повышать ему зарплату, обещать сколь угодно заманчивые бонусы и плюшки. Это всё временные меры. Повышение уровня мотивации технических специалистов через инструменты внешнего тщеславия — это миф, его можно только уронить до плинтуса, поэтому забудьте про повышение мотивации.

С другой стороны, руководству отдела необходим инструмент, позволяющий незаметно подглядывать за активностью своих сотрудников, делать выводы и мягко душить возникающие проблемы в самом зародыше. Традиционные метрики не могут предоставить этих данных, так как дают недостаточно оперативную “среднюю температуру по больнице”. Можно очень дотошно фиксировать все действия инженера, но как сравнить производительность инженера-теоретика, который открывает уйму логов, выдаёт решение и пишет подробное письмо с инструкцией по исправлению, с производительностью инженера-практика, которому проще позвонить и настроить всё самому, чем писать многотомные письма,— науке это не известно. А ведь ещё бывают обращения, сулящие полдня на телефоне, или вопросы по нахождению нужного абзаца в документации. Одним словом — стандартные количественные показатели, которые старательно насаждаются для отделов продаж, для случая саппорта неприменимы.

В начале была идея

Итак, проблема была налицо, и мы должны были её решать. Это было прекрасное время, когда балом правил метод проб и ошибок. Даже самые безумные идеи успешно внедрялись в производственный процесс, а общепризнанные мировые практики оказывались или неприменимы совсем, или просто не работали в силу таких причин, как менталитет.

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

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

Начинаем копать

Сразу встала проблема, обозначенная в самом начале статьи — жуткий дефицит информации. Практически информационный голод. Гуглилось всё, что могло хоть как-то пролить свет на практики внедрения, но довольно скоро стало понятно, что кроме общеописательных статей и азбучных истин, ничего толкового найти не удастся.
Единственное, что было достойно внимания, это запись выступления Алии Ракимгуловой (которую легко можно найти на просторах сети), где она очень хорошо описала реальный пример внедрения.

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

В общей сложности стадия теоретической подготовки заняла около 3-х месяцев.

Средства и цели

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

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

Вторым по важности стало условие получения инженером фидбека об эффективности своего труда в удобном (читай: легко понятном для простого смертного) виде и наличие возможности сравнить свои успехи с другими сотрудниками. Впоследствии это порождает тот самый элемент игры и конкуренции, благодаря которому повышается вовлеченность инженера в выполнение определённых задач. Но недопустимо упускать важный момент — часто неправильно мерить людей абсолютными показателями. Голые цифры (вырванные из контекста задачи) зачастую бесполезны и даже вредны, поэтому надо делать калибровку всех измеряемых метрик с учетом их бизнес-специфики. Смысл затеи в том, что каждый инженер должен решать свои и только свои задачи (и план по ним может быть разный, так как у задач разных инженеров может быть разная сложность), и в конце месяца видеть, что он выполнил план по звонкам на 100%, а его сосед на 90%, а тот факт, что в его плане было установлено принять 10 звонков, а у его соседа — 110, ему знать в общем-то и незачем.

По результатам своей работы, инженер должен получать некие активы— Ачивки (Achievements) и Поинты (Points). Каждое действие приносит определённое количество поинтов, а набор действий, сформированных по некоему признаку (принять 10 телефонных звонков, например),— приносит ачивмент и связанное с ним количество поинтов. Получение некоего набора ачивментов приносит более ценный комплексный ачивмент, который, в свою очередь, приносит ещё большее количество поинтов. В конечном итоге поинты могут быть преобразованы в конкретные материальные и/или нематериальные блага для сотрудников (“вознаграждения”).

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

Поиск исполнителя

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

Исторически сложилось, что мы работаем в CRM Salesforce, и, поскольку одним из фундаментальных принципов была простота для инженера, мы сразу отказались от внедрения новых сторонних приложений. Нашей целью был поиск плагина — модуля, полностью встраиваемого в Salesforce без попапов, иконок в трее и прочей шелухи, которая отвлекает инженеров от работы.

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

Отечественные решения отсеялись быстро за отсутствием опыта работы с Salesforce, которая не получила большого проникновения на территории СНГ по ряду причин. И, честно говоря, осталось ощущение, что эти разработчики просто хотели получить этот новый для них опыт за наши же деньги, не гарантируя результат. Или гарантируя, но только, если в случае неудачи мы станем использовать SharePoint, для которого у них уже всё готово. “Кино и немцы” одним словом.

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

Затем выяснилось, что ряд решений представляют собой нам не нужную корпоративную социальную сеть, где сотрудники компании (за поинты и ачивки) должны будут общаться (в дополнение к Facebook и ВКонтакте), загружать фоточки, посылать друг другу рабочие запросы и заниматься обсуждением новостей. Как я уже сказал выше, нашей целью было сделать геймификацию прозрачной, ненавязчивой, не отвлекающей от работы и органично встроенной в существующий бизнес-процесс. Поэтому идея внедрения новой “социальной сети” для нас не годилась.
Несколько решений так и вовсе крайне озадачили отсутствием какой бы то ни было автоматизации процессов. Чтобы выдать ачивку, менеджер должен зайти в систему и ввести её данные руками. Чтобы построить и разослать отчёт — зайти в систему, указать параметры и нажать кнопку “сформировать”, дождаться окончания процесса и отправить на рассылочный адрес. И все руками! И такие системы, стоит сказать, стоят немалых денег, и, видимо, их покупают, поскольку они присутствуют на рынке. “21 век на дворе!”,- по-другому и не скажешь.

В итоге этого импровизированного тендера осталась только одна компания-разработчик из далекой Америки, которая действительно удивила нас желанием взяться за такую нетривиальную задачу, которая нам требовалась, и, как оказалось позднее, идея отойти от классических канонов жанра настолько захватила всю их фирму (которая далеко не стартап), что в некоторых случаях CEO компании не стеснялся в “прямом эфире” править код системы, во время тестовых запусков и демонстраций. Иными словами, они прекрасно поняли наши идеи и согласились с тем, что практики одного отдела (Sales) никак не могут быть прямо перенесены на другой (Support). Это и заложило фундамент нашего успешного сотрудничества с компанией IActionable.

И грянул бой

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

Затем началась работа непосредственно над внедрением модуля геймификации в существующую бизнес-систему. Я думаю, что большинство хабражителей никогда не сталкивались с Salesforce, поэтому сделаю небольшую ремарку про эту CRM. Фактически, это просто огромная база данных, которая предоставляет гибкий инструментарий для создания своего собственного интерфейса доступа к ней. Таким образом, настройка Salesforce — это не просто “включение набора галочек”- это полноценная разработка, которая, если хотите, схожа с настройкой всем известного бухгалтерского продукта под конкретную компанию. Поэтому нельзя просто принести какой-то код и подключить его в виде модуля к существующей системе. Разработчики модуля, прежде всего, должны довольно плотно пообщаться с разработчиками, кастомизировавшими систему заказчика, и только потом начинать внедрение.

В нашем случае весь процесс занял практически пять месяцев, три из которых ушли на тестирование и доработку. После завершения закрытых тестов, когда все метрики стали обрабатываться необходимым нам образом, был сделан ход конём — система была подключена к боевому продакшену, но только с полностью выключенным интерфейсом — т.е. фактически инженеры уже тогда начали ей пользоваться, только они этого не знали. Это была стадия финальных тестов, отладки и накопления статистики “обычной работы инженеров” для правильной калибровки стоимости ачивок.

Реакция аудитории

Опуская детали презентации системы инженерам, ибо тут всё довольно очевидно, хочу рассказать о вовлечённости инженеров в доработку самой системы. На момент боевого старта наполнение геймификационным контентом оставляло желать лучшего, и ребята сами попросили “доступ к телу” для помощи в наполнении системы ачивками, и было решено позволить им развернуться. В итоге, в названиях и описаниях ачивок можно найти отсылки практически к любой сфере интересов наших сотрудников — от игр и кино, до аниме и книг.

Вот примеры названия ачивок, выдаваемых за решение некоего количества кейсов из определённой страны: Memento Mori, Big in Japan, I Fink U Freeky!, ɐıʃɐɹʇsn∀ sǝsɐƆ 51 ǝsoʃƆ (моя любимая) и т.д. Думаю, не надо объяснять, какие стереотипы от каких стран были взяты. Не были забыты и отраслевые шутки, как, например, каноническое: I Am Putting My Screwdriver Everywhere.

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

Не были забыты и иконки. Все до единой нарисованы инженерами отдела, и процесс их доработки продолжается постоянно.

В целом, внедрение прошло довольно гладко и по ожидаемому сценарию. Заранее выделенная группа самых активных (читай “играющих в игры”) сотрудников успешно создала необходимый “шумовой фон” и помогла освоиться тем, для кого подобная система была в новинку. Небольшая часть людей отнеслась с предсказуемым подозрением, но вскоре и они были ассимилированы системой с различной степенью успешности.

Мы считаем, что была достигнута и еще одна важная цель — никто не остался равнодушным.

Подведение промежуточных итогов

Сейчас, когда с момента начала внедрения прошло 4 месяца, мы готовы сделать некоторые выводы.
• Игрофикация — это не миф, а отличный инструмент для управления бизнес процессами;
• Нельзя проводить внедрение, не имея чётких целей. Необходимо трезво оценить существующие проблемы, и могут ли они быть решены с помощью этого инструмента;
• Создав здоровую конкуренцию среди своих сотрудников (за счет появления общедоступной “доски лидеров”), будьте готовы удивляться возросшей продуктивности;
• Абсолютно неприменимы шаблоны. Ваша конкретная игрофикационная система будет работать только с вашими конкретными людьми. Если из других отделов к вам придут с желанием скопировать готовое решение, то будьте готовы охладить их пыл;
• На пытайтесь насаждать игру калёным железом в принудительном порядке. Начните с самых активных, они заразят остальных;
• Нельзя заменить игрой реальное управление людьми. Всегда должна быть чёткая граница, за которой игра заканчивается и начинается сухой язык бизнеса. Люди должны работать не для игры, а для бизнеса.

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

Ну, а если есть желание присоединиться к нашему дружному коллективу — добро пожаловать на наш карьерный сайт!

Автор: Loxmatiymamont

Источник