Рассчитать индекс счастья: как разработчики проверяют, что сервисом удобно пользоваться

Летом 2021 года я техлидил проект «Доставка в узкий слот», когда курьер привозит товар в небольшом промежутке времени, например с 14 до 15. Первый заказ мы тестировали на коллеге из команды, потом стали подключать яндексоидов из московских офисов.

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

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

Индекс счастья пользователей считают по всему Маркету. То есть берут все заказы и смотрят общую оценку — довольны люди или нет. Я подумал, что неплохо бы посмотреть этот индекс в разрезе только нашего проекта, когда выбирают доставку в узкий слот. Задача для меня оказалась нетривиальной, потому что пришлось свести большие объёмы данных из разных систем. По сути, у меня получилась новая метрика по проекту. Вот что я сделал:

И вот передо мной кривая счастья пользователя. Интуиция не подвела: наш проект оценивали хуже, чем в среднем по Маркету.

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

В итоге нашли проблемы, которые до этого не видели. Часть из них касалась самого приложения:

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

• Дата доставки переносилась автоматически, и время не всегда подходило пользователям. Поэтому они отменяли заказы.
  → Сделали заказ по клику, чтобы человек мог сам выбрать, когда должен приехать курьер.

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

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

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

Тогда я заказал чайник, но он так до меня и не доехал. Сначала менеджер говорил, что его привезут через 4 дня. Когда прошла уже неделя, мне предложили подождать ещё столько же. В итоге заказ отменили, а я понял, что в сервисе есть над чем поработать, и пошёл в Яндекс. Потом Беру стал частью Маркета, в котором я продолжаю заниматься мобильной разработкой.

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

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

Потом я проверял, как работает новый способ получения заказа в постамате. Мы разработали сложный сценарий в приложении:

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

Маркет не единственное приложение, которым я пользуюсь. Когда я пришёл в Яндекс, то стал его фанатом и установил себе Драйв, Еду, Такси, Лавку. Захожу в них как обычный пользователь и одновременно замечаю, что нового сделали другие команды. Так, мне очень нравится функция «Радар» в Драйве, которая ищет машину к конкретному времени. Она выручила меня, когда я прилетел вечером в пятницу в Москву и огромному количеству людей надо было добираться до дома. Пока я оформлялся в аэропорту, «Радар» забронировал мне машину.

А анимированный пин в Такси вдохновил меня реализовать подобное в Маркете. Коллеги сделали так, чтобы он красиво подъезжал, когда на карте выбирается адрес. Мы реализовали эту идею у себя. Сейчас дизайн у нас в Маркете поменялся: пин поднимается над картой и как бы лавирует в воздухе. Мелочь, но наблюдать за анимацией приятно.