О плюсах работы в продуктовой компании рассказано уже много, и здесь сложно быть оригинальным. А вот о том, как поддерживать «здоровье» продукта и чем можно заниматься в продуктовой компании, кроме разработки функциональности, знают далеко не все. Мы расскажем, как мы в Juno оперируем продуктом, и как в этом задействованы операционный отдел и технические специалисты.

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

О нас: Компания Juno — райдхейлинг сервис, работающий на рынке США и являющийся частью группы компаний Gett.

В Juno пишут код на языках Go, Swift, Kotlin, Python, React.js в составе команд мобильных приложений, Backend, Frontend, Data Science, Technical Operation Support, создающих сервис, который стал частью повседневной жизни десятков тысяч водителей и сотен тысяч жителей Нью Йорка.

Из чего состоит управление продуктом

Давайте разберемся в процессе оперирования в Juno и попробуем разложить его на составные части.
Мы для себя выделили три ключевых компонента:

1. Операционный офис
   
2. Метрики и мониторинг
   
3. Расследование инцидентов
   

Цель оперирования продуктом заключается в своевременном реагировании на возникающие проблемы и изменения независимо от их природы.
Для этого нужно:

• Определить показатели «здоровья» системы
  
• Понимать, как изменения внутри системы влияют на показатели
  
• Понимать, как изменения на рынке влияют на показатели
  
• Понимать, когда изменение перерастает в проблему
  

При таком подходе бизнес-решения основываются на данных. Наша команда оперирования работает в Нью-Йорке, так как сервис Juno пока доступен только жителям этого мегаполиса.
Ежедневный список дел команды выглядит так:

• Отслеживать и оперативно реагировать на изменения регуляторов. К распространенным изменениям относятся появление новой платной дороги и перенос зоны ожидания для водителей в аэропорту. Как только мы получаем информацию о подобных событиях, сотрудник выезжает на место, чтобы правильно обновить карту и проанализировать список возможных проблем. Когда команда разработки обновляет карту на серверах, сотрудник тестирует изменения в “полевых условиях” и удостоверяется в корректной работе.
  
• Проводить «полевые» исследования. Когда мы запускали сервис в Нью-Йорке, план был сначала набрать определенное количество водителей для стабильной работы сервиса в любом районе города. По этой причине пару месяцев водители, которые присоединились к нам первыми, ездили без пассажиров и только иногда получали поездки от бета-тестеров. Для сбора необходимой информации этих поездок было недостаточно. Тогда мы приняли решение отправить команду оперирования в “поля”, чтобы оценить качество сервиса и узнать жалобы водителей на работу приложения. Данный подход оказался полезным и мы постоянно его используем при выпуске существенных изменений или для проверки гипотез.
  
• Вести «Календарь Событий» — список мероприятий, праздников и погодных явлений, способных повлиять на количество и качество поездок. Это помогает понять и предвидеть изменения ключевых показателей (например, количество поездок или количество водителей онлайн), которые для команды разработки из Минска не очевидны. Некоторые события можно загуглить (погодные условия, финал SuperBowl, марафон, велогонка и т.д.), но есть и такие, с которыми сложнее. К примеру, в первый год работы для нас стало сюрпризом, что Рамадан сильно влияет на количество водителей, готовых принять заказ. Дело в том, что в США много мусульман работают водителями, и в праздник на работу они не выходят. Сложно учесть такой факт, находясь в Минске.
  
• Отслеживать изменение бизнес метрик. На третий месяц после запуска Juno и бурного роста количества поездок мы обнаружили, что в онлайн вышло недостаточно водителей, что сказалось на времени подачи автомобиля и на желании пассажиров ездить с нами. Выяснилось, что конкурент запустил акцию, гарантирующую водителям повышенную оплату на поездки в утренние и вечерние часы пик. Информация была быстро передана в Минск, и в сжатые сроки у нас тоже появилась возможность предлагать такие условия. Этот шаг помог нам вернуть водителей и продолжить расти.
  

Метрики и мониторинг

В Juno у всех команд есть метрики, которые мы условились разделять на:

• Бизнес-метрики.
  
• Технические метрики.
  

Бизнес-метрики — ряд показателей, которые позволяют оценить “здоровье” продукта. Условно разделим их на две части:

• Онлайн. К очевидным отнесем количество водителей и пассажиров онлайн, количество поездок по статусам. К менее очевидным — количество новых пользователей, конверсия перехода от экрана с предварительной ценой поездки до заказа поездки, среднее время ожидания автомобиля в конкретном районе, скорость движения очереди в аэропорту и т.д.
  
• Оффлайн. Далеко не всю информацию можно быстро получить и обработать в реальном времени, да и не всегда это нужно. Когда мы планируем акции для водителей или новые функции, то нам интересны долгосрочные тренды или реакция пользователей на A/B эксперимент, будь то новый дизайн, новая функция или дополнительная скидка.
  

Для создания аналитических отчетов на базе собранных метрик используем Tableau. За такие отчеты у нас отвечает команда Business Intelligence (BI). Они работают в Тель-Авивском офисе рядом с продуктовой командой. Обе команды тесно сотрудничают с коллегами в Нью Йорке, что позволяет на основе BI аналитики оценить успех предпринятых действий, сформулировать гипотезы для проверки в “полях” и откорректировать план развития продукта.

С другой стороны, есть целый ряд технических метрик, которые так или иначе влияют на систему в целом.

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

• Дашборд — отображает значимые показатели жизнедеятельности системы. Каждая команда разработки составляет свой набор метрик, которые помогают им понять, как повлияло то или иное изменение на ввереные им микросервисы. Так, например, одна команда следит за метриками, связанными с выплатами денег водителям и платежами пассажиров, а другая смотрит за метрикой, отвечающей за время поиска водителя или количеством полученных координат.
  

• Логи. Мы логируем события с мобильных устройств и микросервисов бэкенда. В 2017 они занимали 400-500 гигабайт в неделю, к 2018 эта цифра удвоилась. Нас интересуют следующие события: обращения микросервисов во внешние источники информации, в другие микросервисы, принятые и отправленные запросы на клиенты, всякого рода ошибки (бизнес и технические). Стоит отметить, что информация анонимизирована: персональные данные, такие как пароли и банковская информация, не логируются.
  

Для наблюдения за показателями мы используем Grafana и Prometheus. При разработке нового сервиса или добавлении новой функции разработчики добавляют нужные метрики в сервис, а дальше каждая команда настраивает себе оповещения.

Благодаря настроенным оповещениям команда технической поддержки делает первичный анализ и эскалирует проблему в разработку или в бизнесовые команды для  дальнейшего решения.
В случае, если проблема носит технический характер и угрожает нормальному оперированию сервиса, команда технической поддержки создает продакшн инцидент (production issue). Благодаря автоматизированному процессу, сразу оповещаются заинтересованные стороны, в том числе и команда поддержки пользователей (Customer service aka Helpdesk aka L1 support), которая подготавливается к возможному наплыву звонков.

Расследование инцидентов

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

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

Разбираться приходится как с продакшн инцидентами, так и с любой другой ситуацией, когда невозможно быстро ответить «что произошло». И здесь помогает команда технической поддержки (TechSupport aka L2 support).

Какие вопросы решаются в техподдержке? Есть мнение, что это скучная работа, как в сериале IT Crowd, где три ботаника в подвале только и делают,  что говорят: «попробуйте выключить и включить компьютер». В действительности вопросы возникают сложные и неоднозначные.

Первый уровень поддержки (customer service) организован по принципу «следуй за солнцем» (follow the sun). При таком подходе круглосуточная поддержка пользователей возможна без ночных смен. В европейское время работает офис в Тель-Авиве, а в американские часы — в Портленде. Задача этой команды выслушать и понять «боль» водителя или пассажира, успокоить, по возможности помочь. Ребята, которые там работают, отвечают за вопросы, касающиеся работы сервиса. При этом команда не «техническая», и как только наступает момент, когда требуется погружение глубже в технические нюансы, запрос перенаправляется в команду технической поддержки. Эта команда работает в Минске и входит в состав центра разработки. Ребята  решают исключительно технические вопросы и не общается с водителями и пассажирами напрямую. Задача команды: расследование происшествий и автоматизация процессов.

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

• Повреждены ли данные, не нарушена ли их целостность?
  
• Как это происшествие повлияло на пользователей?
  
• Все ли пользователи пострадали?
  
• Что можно исправить?
  

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

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

Если запрос приходит неоднократно, то он автоматизируется силами команды техподдержки и предоставляется команде поддержки пользователей в виде веб приложения. Такой подход позволяет сократить время на обработку обращения пользователя и не «раздувать» команду техподдержки. Тем не менее вакансия инженера техподдержки у нас открыта постоянно, так как ребята растут и переходят в другие команды разработки.

Все дороги ведут в Рим

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

Это не значит, что команда техподдержки — главное звено в управлении продукта оперирования, ведь продуктовая компания — живой организм: все органы важны и нужны. Невозможно выбрать, что важнее для человека — мозг или сердце, легкие или кровеносная система. Только гармоничное развитие и взаимодействие всех органов гарантирует здоровое функционирование организма или IT компании.

Здоровья вам и вашим продуктам!