Шутки, код и продуктивность: кто и как создает r_keeper Loyalty

О том, как шутки влияют на продуктивность и почему важна нулевая толерантность к ошибкам, рассказывают product owner сервиса Алексей Клоц, product owner системы отчетности Ксения Дергунова и техлид команды Сергей Устимов.

Как работает команда сервиса r_keeper Loyalty и как философия продукта помогает создавать «машину лояльности»  

• r_keeper Loyalty — профессиональная платформа для создания программ лояльности в ресторанной индустрии. За три года продукт стал лидером рынка по количеству клиентов: его используют более 1000 ресторанов, чтобы привлечь новых гостей и сохранить лояльность постоянных посетителей. А еще повысить продажи: внедрение программы лояльности на 32% увеличивает средний чек и добавляет 20% к выручке заведения.

Как собиралась команда

Команда, которая делает r_keeper Loyalty, сформировалась летом 2017 года. Изначально она состояла из трех backend- и одного frontend-разработчика, QA-тестировщика и product owner. Но постепенно выросла — вместе с продуктом. Сейчас в команде r_keeper Loyalty работает 20 человек. «У команды есть своя философия, химия. В компании r_keeper около 20 команд, и наша отличается по культуре общения: постоянные шутки, смех. Но при этом все работают на высоком уровне — получается такая крепкая синергия хорошей производительности и теплых взаимоотношений в команде», — рассказывает Алексей Клоц.

В r_keeper Loyalty минимальная текучка кадров. Некоторые новички отсеиваются в первые три месяца испытательного срока: не выдерживают слишком жесткого ритма, в котором им некомфортно работать. Остальные продолжают развивать продукт, если не уходят реализовывать собственные проекты, — сильным специалистам, которых «выращивают» в  r_keeper Loyalty, это по силам. 

«Онбординг новых членов команды строится по принципу менторства: мы назначаем человека, который помогает новому сотруднику адаптироваться в команде. Он отвечает на вопросы, настраивает среду разработки, помогает справляться с первыми задачами».  Техлид команды и главный инженер программы лояльности Сергей Устимов

Задача, чтобы новый сотрудник влюбился в команду и проект, ставится еще на этапе собеседования: соискателей глубоко погружают в продукт и его цели. «Мы рисуем будущее нашего продукта. Неважно, разработчик это или менеджер, мы всегда объясняем, ради чего мы здесь, чего мы хотим, какая у нас экстраидея», — добавляет Алексей Клоц.

Одно из ключевых требований к кандидатам — амбициозность.

«Чтобы поддерживать высокую производительность системы, мы работаем не только над решением тривиальных задач, например багфиксов. У нас очень амбициозные, в хорошем смысле безумные разработчики, которых каждый раз впечатляют разговоры о том, что мы планируем запускать».  Product owner системы отчетности Ксения Дергунова

Поэтому чаще всего в команду попадают разработчики с богатым опытом. Например, у QA Lead сервиса r_keeper Loyalty Татьяны Прозоровой есть опыт тестирования систем, работающих в авиастроительной компании Airbus. «Это крутой опыт, и основательность такого специалиста очень помогает команде — она передает опыт более молодым QA-инженерам, что придает зрелости команде», — говорит Алексей Клоц.

Вообще в r_keeper Loyalty полное гендерное равенство: девушек-разработчиц в команде не меньше, чем мужчин. Одна из них, Евгения Котович, пришла из Microsoft, и не раз помогала команде выходить из сложных ситуаций. «Будучи совсем новым игроком в команде, в момент непонятного сбоя в системе она взяла лидерство на себя, применила опыт работы в службе поддержки Microsoft, разобралась и нашла проблему. После этого она возглавляла сложные интеграционные проекты», — рассказывает Алексей Клоц. 

Как выглядит союз «физиков и лириков»

Особенность r_keeper Loyalty — то, что техническим продуктом управляют не только IT-специалисты. Product owner Алексей Клоц — бывший директор по маркетингу Traveler’s Coffee, одной из трех крупнейших сетевых кофеен России, объединяющей более 100 ресторанов. Product owner системы отчетности Ксения Дергунова — бывший руководитель программы лояльности одной из ресторанных сетей Приволжского федерального округа. И по их словам, они «пришли в IT создавать продукт для ресторанных маркетологов».  

«У нас очень хорошо организована работа разработчиков с руководителями проектов на внутреннем уровне: технические специалисты помогают плотно погружаться в продукт, понимать его и грамотно транслировать вовне. Это позволяет нам не выглядеть дураками на каких-нибудь технических встречах».  Product owner сервиса Алексей Клоц

Возможно, такая синергия жизнеспособна из-за отсутствия в команде профессионального снобизма в общении друг с другом. По словам Алексея Клоца, тимлид команды Сергей Устимов может буквально на пальцах объяснять сложные вещи. «Он мне рассказывал, как будет работать репортинговая система. Говорил, что у нас будет баночка, в которую мы будем собирать данные. Потом баночек станет несколько. А в какой-то момент мы сможем построить отчет, где для каждого столбца будет сделан запрос в определенную баночку. Так понятно даже гуманитарию», — вспоминает Алексей Клоц.

Какие правила работают в команде

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

Правило № 2: высокая скорость работы и продуктивность. Недавно команда закрыла первые 10 тысяч тикетов разной сложности за три года работы — от микроправок в пользовательском интерфейсе до «эпических» задач по доработке сервиса. В коллективе вообще принято оглядываться назад и смотреть, сколько всего сделано: это вдохновляет и придает сил для новых свершений. 

Правило № 3: правильная адаптация новичков в команде. При погружении новых сотрудников, особенно разработчиков, в специфику продукта используется принцип quick wins.

Первая задача всегда достаточно легкая с точки зрения реализации. Но это не “иди, почитай техническую документацию”, а реальная доработка, которая ощутимо улучшает продукт. И при ее релизе мы рассказываем всей команде, какую классную вещь “запилил” новичок, как она помогает клиенту, — это очень окрыляет».  Product owner сервиса Алексей Клоц

Правило № 4: команда играет вдолгую: готова тратить время на качественную разработку на старте продукта, распределяя задачи между сильными разработчиками, а не применять костыльные решения.

«Мы тащим с собой “чемодан” с кодом, накопленным за много лет. Как любое легаси (старый код), система иногда дает сбои, так что нам приходится “тушить пожары”. Но для новых разработок мы стараемся создавать качественные решения: например, активно используем автотесты — как юнит, так и интеграционные».  Техлид команды Сергей Устимов

Долгосрочный подход распространяется и на членов команды. Например, Дмитрий Фролов, один из бэкенд-разработчиков r_keeper Loyalty, пришел в компанию еще будучи третьекурсником МГТУ имени Баумана. Он начал как автотестер, но мечтал стать разработчиком. «Все команды отказались от него, а мы взяли — джуниором. Первые несколько месяцев он отнимал много времени у техлида, так что эффект был, скорее, негативным. Но зато спустя год, когда мы должны были сделать доработки продукта под одного из крупнейших клиентов компании, вся команда r_keeper Loyalty ушла в долгую разработку. И Дима почти квартал в одиночку закрывал все остальные доработки — так качественно, что никто из клиентов и не заметил временного перераспределения ресурсов», — рассказывает Алексей Клоц.

Правило № 5: помешанность на оптимальном time to market, но без ущерба качеству.

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

«Мы фанаты этого подхода. Все время думаем, как сократить время на тестировании или поменять задачи местами в очереди, — пытаемся менеджерскими инструментами ускорить выход продукта на рынок».  Product owner сервиса Алексей Клоц

Такая концепция заразительна и становится частью ДНК команды. «Например, наш PM даже после ухода из r_keeper Loyalty возвращалась, чтобы помочь протестировать продукт — понимая, что у команды завал и нужны лишние руки. А еще одна коллега через полгода после рождения ребенка вернулась на полставки. Это говорит о том, что людям просто хочется работать», — рассказывает Алексей Клоц.

Правило № 6: высокий уровень эмпатии к задачам клиентов

Команда r_keeper Loyalty понимает, что за продуктом стоят b2b-клиенты, которые доверяют ей свой бизнес. Это большая ответственность, которую осознает каждый. «Например, наш фронтенд-разработчик Андрей Логвинов, теперь ставший фронтлидом компании, как-то почти неделю работал из отпуска: просто сидел в номере турецкого отеля и занимался разработкой. Не должен был, но делал, так как понимал, что это ценно и клиенты ждут», — рассказывает Алексей Клоц. 

Как организована поддержка клиентов

Для r_keeper Loyalty саппорт (как b2b-, так и b2c-клиентов) — в приоритете: для продукта выстроены три линии поддержки. 

Первая — колл-центр, который обрабатывает вопросы гостей по использованию программы лояльности, реже — запросы от самих ресторанов. 

Вторая — специалисты службы поддержки, которые работают в режиме 24/7, с графиком дежурств по ночам, в праздники и выходные. У них хорошая экспертиза по продукту: сотрудники второй линии способны решить  бо́льшую часть типовых заявок на своем уровне. Они никогда не уйдут с площадки, пока не устранят проблему. «Пару лет назад 1 января в 12 ночи у нас “лег” сервис. И наш тогдашний техлид Александр Югов сидел и разбирался, в чем причина — при том, что он не был дежурным, а поломка не была связана с продуктом, за который он отвечал. Он просто пришел и докопался до сути проблемы. А наш QA Алексей Воробьев помогал команде удаленно, даже когда у него были проблемы со здоровьем, потому что понимал, что без него мы не выпустим релизы для клиентов. Мы очень гордимся, что он прошел этот сложный для себя путь вместе с нами», — вспоминает Алексей Клоц.

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

В r_keeper Loyalty работает система двойного мониторинга: технический и бизнес-мониторинг, который наблюдает за основными пользовательскими сценариями. Он анализирует общее количество выполнений сценария, количество успешных попыток и ошибок, время отклика. Система предупреждений, интегрированная в мониторинг, автоматически сигнализирует о сбоях в работе: например, если ошибок стало больше допустимого лимита или время обработки операции превысило заданный порог. «Такая схема позволяет на ранней стадии обнаруживать проблемы и ошибки в системе и устранять их еще до того, как о них узнает клиент или служба поддержки. А результаты бизнес-мониторинга позволяют владельцу продукта делать выводы о востребованности тех или иных функций продукта», — рассказывает Сергей Устимов.

Как «машина» от r_keeper Loyalty поможет ресторанным маркетологам

Важное условие конкурентоспособности проекта — знание актуальных потребностей рынка. У команды r_keeper Loyalty есть пул активных клиентов и группа маркетологов из ресторанного бизнеса, от которых приходит обратная связь по необходимому функционалу и оперативным доработкам. «Обратная связь от клиентов, экспертное мнение и знание конкурентного рынка — в этой синергии рождаются новые фичи. Например, отчет “Тренды” мы создали потому, что он был необходим клиентам, а у конкурентов не было аналогов», — говорит Ксения Дергунова.

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

Функционал автоматического ведения программы лояльности уже находится в разработке, и на этом этапе в продукт r_keeper Loyalty будет встроен искусственный интеллект. Он будет анализировать покупательские привычки гостей и самостоятельно управлять настройками программы. Все, что останется маркетологу, — нажать кнопку «Да, запустить программу лояльности», а через месяц — проверить ее результаты и посчитать экстраприбыль. «Мы считаем, что сможем сделать “машину”, которая закроет 30% от хорошего маркетолога. А 30% от хорошего маркетолога — это гораздо лучше, чем 100% от плохого», — убежден Алексей Клоц.

R_keeper Loyalty единое решение для запуска программы лояльности в ресторане или всей сети. По данным аналитиков  r_keeper, использование сервиса в заведении приносит до 25% дополнительной выручки, увеличивает средний чек на 30% и поднимает показатель окупаемости маркетинговых вложений (ROMI) до 300-1000%.

Подробнее об условиях подключения к сервису тут: http://rkeeper.ru/products/loyalty