Содержание
Метрик и тестирования не всегда хватает, чтобы понять, что в сервисе сделано хорошо, а что стоит улучшить. Иногда надо, как Николай, свести гигабайты данных из разных систем. Или, как Рустам, после работы проверить, правильно ли приложение соединяется с постаматом. Ребята рассказывают, как оценивают удобство своих сервисов.
Николай Колесниченко: «Мне хотелось понять, совпадают ли ожидания пользователей с тем, что мы сделали»
Летом 2021 года я техлидил проект «Доставка в узкий слот», когда курьер привозит товар в небольшом промежутке времени, например с 14 до 15. Первый заказ мы тестировали на коллеге из команды, потом стали подключать яндексоидов из московских офисов.
Конечно, иногда от ребят падали отзывы, что курьер не приходил или доставлял не то. Но в целом проект был рабочим: метрика попадания доставки в слот и количество доставленных заказов были на нужном уровне. Казалось, вот он момент, чтобы запустить проект уже не только для сотрудников. Но меня не покидало ощущение, что в офлайне есть проблемы, которые метрики не показывают. И разовое «Курьер до меня не доехал» в реальности выглядит масштабнее.
Тогда я решил рассчитать индекс счастья пользователей по заказам нашего проекта
Мне было интересно самому вникнуть в аналитику, подтвердить свои ощущения цифрами и прийти к коллегам с фактами. И я стал думать, как ещё оценить ожидания пользователей.
Индекс счастья пользователей считают по всему Маркету. То есть берут все заказы и смотрят общую оценку — довольны люди или нет. Я подумал, что неплохо бы посмотреть этот индекс в разрезе только нашего проекта, когда выбирают доставку в узкий слот. Задача для меня оказалась нетривиальной, потому что пришлось свести большие объёмы данных из разных систем. По сути, у меня получилась новая метрика по проекту. Вот что я сделал:
Написал несколько запросов, чтобы выгрузить историю заказов из одной системы, информацию по логистике и статусам — из второй, а все отзывы — из третьей. Я учитывал не только оценки, но и смотрел, что люди писали о нас.
Подготовил скрипт, который работал по полтора часа каждый день, «переваривал» много разных данных и на выходе давал простую табличку.
Построил график, который показывал оценку заказов в узкий слот каждую неделю.
И вот передо мной кривая счастья пользователя. Интуиция не подвела: наш проект оценивали хуже, чем в среднем по Маркету.
«Коллеги, у нас есть проблема…»
Поскольку над проектом работали команды Маркета и Go, то я пошёл к бизнесу обоих сервисов и сказал: «Вот смотрите, у нас оценки ниже среднего». Коллеги заинтересовались метрикой, активно подключились разработчики из Go, и мы стали думать, что с этим делать. Поняли, что нужна глубокая обратная связь от пользователей, поэтому собрали небольшой колл-центр для проекта. Менеджеры звонили людям, которые поставили низкую оценку, и спрашивали, что им не нравилось.
В итоге нашли проблемы, которые до этого не видели. Часть из них касалась самого приложения.
| Курьеры не понимали, как менять статус заказа. Например, они могли случайно отметить, что доставили товар, хотя по факту было не так. | Мы изменили интерфейс приложения, чтобы таких ошибок было меньше. |
| Дата доставки переносилась автоматически, и время не всегда подходило пользователям. Поэтому они отменяли заказы. | Сделали заказ по клику, чтобы человек мог сам выбрать, когда должен приехать курьер. |
Технические проблемы мы быстро пофиксили. Но были и другие сложности, на которые мы, к сожалению, повлиять не могли. Например, когда продавец ошибался и курьер привозил не тот товар.
Примерно через месяц пользовательские оценки заказов в узкий слот выросли до средних по Маркету. Люди стали приносить больше положительного фидбэка, а я был рад, что смог найти проблему и улучшить проект. Этот опыт я использую и сейчас, потому что в любом проекте надо понимать, насколько мы близки к достижению целей бизнеса.
Рустам Кенджаев: «Мне интересно смотреть, как код, который я пишу, перекладывается на реальный мир»
Я пришёл в Яндекс в 2019 году, когда он развивал Беру. Увидел, что в сервис набирают мобильных разработчиков, и решил сперва его потестить, прежде чем откликаться на вакансию.
Тогда я заказал чайник, но он так до меня и не доехал. Сначала менеджер говорил, что его привезут через 4 дня. Когда прошла уже неделя, мне предложили подождать ещё столько же. В итоге заказ отменили, а я понял, что в сервисе есть над чем поработать, и пошёл в Яндекс. Потом Беру стал частью Маркета, в котором я продолжаю заниматься мобильной разработкой.
Пришёл забирать заказ по штрихкоду, а в пункте выдачи нет сканера
Нагрузочное тестирование, проверка макетов side-by-side — это всё у нас есть. Но мне интересно проверять запуск новых фич в реальности и смотреть, удобно ли вообще пользоваться теми штуками, которые мы пилим. Ведь между онлайном и офлайном много скрытых моментов, которые не учтёшь, сидя в офисе. Поэтому, как только мы делаем что-то новое, я проверяю, как это работает в жизни. Иногда получается забавно.
Помню, коллега сделал фичу, чтобы получать заказ по штрихкоду: нажимаешь на кнопку в приложении, оператор сканирует код и выдаёт товар. Никаких номеров называть не надо. Я как раз заказал компостер для травы на дачу и решил потестить фичу. Прихожу в пункт выдачи, показываю штрихкод, а мне говорят, что сканера нет, потому что собственник ПВЗ решил его не покупать. Тогда это было опционально, поэтому пришлось называть номер заказа.
Потом я проверял, как работает новый способ получения заказа в постамате. Мы разработали сложный сценарий в приложении:
Надо подойти к постамату и нажать в приложении «Я у постамата».
Телефон находит его и устанавливает блютус-соединение.
В приложении появляется код, который надо ввести на экране постамата.
Ячейка открывается, и можно забрать заказ.
Помню, что постоянно кайфовал, когда проходил флоу открытия ячейки в постамате
Здесь была возможность потестить разные пользовательские сценарии. Например, однажды я выбрал для доставки постамат, который стоял в подвале. Связь там была не очень, а значит, код мог не прийти, но всё прошло гладко.
В другой раз я забирал заказ вместе с женой. Открывать ячейки одновременно два человека не могут: постамат коннектится с каждым устройством последовательно. Мне хотелось посмотреть, что отобразится у жены в приложении, пока я получаю заказ. Поэтому сначала подключился я, а потом она. Её приложение выдало, что постамат занят и надо подождать — как мы и реализовали эту функцию с командой.
Рустам Кенджаев
тимлид мобильной разработки
Баги отношу коллегам в чаты, а классными идеями вдохновляюсь
В Яндексе принято фидбэчить, и у меня за время работы в Маркете скопилось много контактов. Поэтому баги я обычно скриню, описываю и скидываю тем, кто отвечает за функцию. Бывает, просто передаю информацию об ошибке в чат, который смотрят ребята из поддержки.
Маркет не единственное приложение, которым я пользуюсь. Когда я пришёл в Яндекс, то стал его фанатом и установил себе Драйв, Еду, Такси, Лавку. Захожу в них как обычный пользователь и одновременно замечаю, что нового сделали другие команды. Так, мне очень нравится функция «Радар» в Драйве, которая ищет машину к конкретному времени. Она выручила меня, когда я прилетел вечером в пятницу в Москву и огромному количеству людей надо было добираться до дома. Пока я оформлялся в аэропорту, «Радар» забронировал мне машину.
А анимированный пин в Такси вдохновил меня реализовать подобное в Маркете. Коллеги сделали так, чтобы он красиво подъезжал, когда на карте выбирается адрес. Мы реализовали эту идею у себя. Сейчас дизайн у нас в Маркете поменялся: пин поднимается над картой и как бы лавирует в воздухе. Мелочь, но наблюдать за анимацией приятно.
Каждая проверка в офлайне для меня — это даблчек. Так я ещё раз убеждаюсь, что всё работает и пользователям будет удобно. А значит, я не зря кодил и приношу пользу.
