Как команда Лавки организовала межсервисную стройку, чтобы доставлять из дарксторов и аптек в одном заказе
Никита Пятаков — руководитель группы бекенд-разработки экосистемных проектов интеграции в Лавке. Он расскажет, как сегодня меняется доставка и почему заказывать из Лавки лекарства теперь удобнее.
Расширяем Лавку
Фишка Лавки в том, что курьеры работают в радиусе одного даркстора и доставляют от 15 минут. А раз они уже находятся в районе, почему бы не заехать по пути ещё куда-то? Забрать аскорбинку в аптеке у дома, захватить продукты и доставку из Маркета.
Курьеры Лавки доставляют заказы в радиусе одного района от 15 минут
Всё это ведь уже есть в Яндекс Еде
Курьеры Еды работают на более длинных маршрутах — соответственно, доставка дольше и дороже для пользователя. Почему бы не оптимизировать?
Мы нативно интегрировали каталог и поиск в WebView Лавки за счёт back2back интеграции с Едой. Научили нашу корзину работать с разными товарами.
На самом деле при создании заказа под капотом приложения создается два — и в Лавке, и в Еде. Из заказа Еды, конечно же, пришлось убрать шаг с поиском и назначением курьера. Заработало, но сложностью стала как раз синхронизация таких заказов.
Главный вызов — синхронизация двух заказов
Если отменяется один, что делать со вторым? Как учитывать изменения в процессе? Мы написали отдельный микросервис, который и выполняет функцию синхронизации. Больше 70 тысяч строк кода и больше 200 выполненных задач, чтобы обрабатывать объёмы данных из разных систем, анализировать и мэтчить их между собой. Так, подключение новых городов стало вопросом настройки конфигураций.
Написано строк кода
> 70 тысяч
Закрытых задач
> 200
По данным о заказах в Москве и Санкт-Петербурге, покупатели, которые заказывают в Лавке лекарства, в 85% случаев добавляют в корзину и продукты и с готовой едой
Большое количество заказов из Лавки уже включают лекарства. Это один из первых настолько масштабных и успешных проектов для нашей команды, который делает сервис реально удобнее для пользователей. Сегодня мы не останавливаемся и продолжаем исследовать и тестировать гипотезы новых сценариев «по пути».
Почему Лавка — классное место для работы?
Лавка — один из самых молодых продуктов из всех, и когда я пришёл, здесь царила атмосфера стартапа. За несколько лет мы выросли, но вайб сохранился. Заряженные люди работают над прорывными проектами, предлагают решения и реально кайфуют от своих идей. Здесь будет классно всем, кто хочет создавать большое и новое, а не копаться в легаси.
Заряженные люди, прорывные проекты и кайф от каждой идеи
— это Лавка
Следующая история
1 / 6
Как команда Яндекс Go запустила выгодный сценарий для межгорода в сложной структуре микросервисов
Лёша Агеев — техлид команды iOS-разработки Межгорода. Он расскажет, как возник, живёт и куда сейчас развивается Межгород.
Надо было понять, чем конкретно мы отличаемся от Такси
Межгород возник как альтернатива тарифу Эконом в Такси. Люди отказывались от комфорта такси из-за высокой стоимости при поездках между городами. Единственная альтернатива — переполненный общественный транспорт. А водители неохотно брали заказы из-за того, что обратно едут без заказа.
Протестировали гипотезу, подтвердили метриками — погнали делать!
Мы начали с того, что предлагали водителям ненадолго задержаться в городе назначения, чтобы у нас было больше времени на поиск пассажира на обратный путь. Гипотеза, что спрос на межгородские поездки на такси имеется и их можно сделать более привлекательными для водителей и пассажиров, подтвердилась — мы заметили рост метрик.
Нельзя выбрать точку А, точку Б, нажать кнопку и поехать
Главная продуктовая задача — направить пользователя по удобному и выгодному для всех пути. Мы развивали предзаказ, потому что поездка по межгороду — это скорее заранее известная необходимость, нежели спонтанное решение. Водители могли составить удобный им график на день. Так, у некоторых водителей могут быть дела в другом городе, и им может быть неинтересно сразу возвращаться обратно. Например, в середине дня, когда большинство уходит с линии, водители могут выходить на Межгород, а к вечеру возвращаться в город к пиковому спросу в Такси.
Водители могли составить удобный им график на день.
Утром и вечером — в городе, днём — на Межгород
Межгород влияет на все сценарии Такси
На старте Межгороду требовались изменения как на главном экране супераппа Яндекс Go, так и на экранах заказа и поездки такси. За каждый из них в приложении отвечают разные команды, поэтому сроки реализации могли затянуться.
Так собралась команда Межгорода — чтобы вносить изменения во все сценарии Яндекс Такси, в которых нуждается Межгород
Мы использовали SwiftUI для более быстрой разработки нативных интерфейсов, но довольно быстро перешли на BDUI-подходы. Чтобы относительно быстро и практически без новых релизов клиентов разворачивать новый функционал в приложении.
Разработка основной логики происходит на бэкенде, а задача мобильных разработчиков сводится к разработке наиболее гибких и адаптируемых решений. Это даёт бэкенду ещё больше возможностей для конфигурации пользовательского сценария.
Мы до сих пор исследуем, что нужно пользователю
Яндекс Такси уже больше 13 лет — за это время мы научились предсказывать поведение пассажиров и водителей внутри города. Межгородское перемещение от него сильно отличается — мы можем тестировать новые гипотезы и искать точки роста. В городе они могли показать себя плохо, а в Межгороде — наоборот.
Больше 13 лет
Прошло с запуска Яндекс Такси
Межгород — пространство для постоянного исследования
Нечто маленькое внутри Яндекс Go может стать очень большим
Как и многие новые фичи, например, в Яндекс Доставке, Межгород начинался как тариф в Такси, а теперь это самостоятельный сервис. Я вижу, как это происходит в реальном времени: после запуска новых фичей растут метрики. Например, количество поездок и пассажиров, среднее количество поездок пассажиров или водителей в Межгороде за месяц.
Всё это — результат внедрения новой логики на бэкенде или создания более удобного и приятного интерфейса в мобильных приложениях. У нас в команде много людей с нестандартным мышлением.
Вместе мы превращаем идеи в проекты для миллионов пользователей.
Следующая история
2 / 6
Как команда Маркета ускорила выдачу заказов клиенту до 1 минуты
Лёша Остриков, руководитель отдела разработки логистики последней и средней мили, расскажет, как устроена разработка в Маркете и за что её можно полюбить.
От 10 курьеров до 14 тысяч пунктов выдачи
Больше 6 лет мы создаём логистику Маркета и сегодня работаем для бесчисленного количества курьеров, 14 тысяч ПВЗ и десятков сортировочных центров. Чтобы тут работать, нужно это по-настоящему любить!
Любить новые задачи, обратную связь и новые опыты снова и снова.
Заметить места для улучшений можно только спустя десяток итераций, а где-то — вообще спустя сотню.
Не просто пикнуть
На пунктах выдачи заказов десятки процессов со своими точками входа и нюансами. Наш основной челлендж — снижать сложность, стирать отличия между разными процессами и объединять похожие флоу в один.
Идеальный софт для ПВЗ это тот, в котором всё интуитивно понятно
Логистика меняется, а компетенции команды расширяются
«Под капотом» у нас несколько десятков микросервисов, и их количество только растёт. За 3 года работы нам пришлось овладеть всеми прелестями разработки микросервисной архитектуры: синхронизацией распределённого стейта, поддержанием отказоустойчивости всей системы при падении одного из узлов и умением держать нагрузку, балансируя трафик между дата-центрами.
«Под капотом» у нас несколько десятков микросервисов, и их количество только растёт.
Работать в поле и решать задачи на месте — особенное удовольствие
Один из последних наших проектов — возможность сведения десятка флоу к одной странице со штрих-кодом. Подумаешь, нет чего проще! Но на деле ты начинаешь распутывать клубок сложных цепочек процессов, и одна простая страница обрастает списками, селекторами, статусами… Если вам нравятся сложные задачи — приходите в Маркет!
Победа прошлого года — новая система выдачи заказов.
От парадигмы «выдаём заказ один, потом выдаём заказ два» мы перешли к тому, что выдаём все заказы клиента за раз. Это был совершенно безумный по сложности разработки и раскатки проект, который мы дорабатывали и совершенствовали в течение 3 месяцев после релиза. Чтобы всё работало как часы.
А так как нам нужно было внедрить в момент покупки возможность оплаты картой, привязанной к Маркету… Мы удостоились двойной порции приключений.
И стоит всё это таких нервов?
Работа в Маркете стоит вложений сил и времени на все сто, ведь ты видишь, как твой код работает и приносит пользу сотням людей.
Нужен только особый подход. Здесь учишься любить нескончаемый поток обратной связи и возникающих вызовов. Но когда заходишь в ПВЗ и слышишь, как тебя хвалят… Ну что может быть лучше?
Работа в Маркете стоит вложений сил и времени
на все сто!
Следующая история
3 / 6
Как команда Еды связала вертикали через прокси-сервис и реализовала мультизаказ
Влада Вакуленко, iOS-разработчик и руководитель кросс-функциональной команды в Яндекс Еде, рассказывает, как один прокси-сервис помог запустить большую фичу — мультизаказ.
Первым шагом к мультизаказу была мультикорзина
Мы начали с мультикорзины — когда пользователь собирает товары в разных магазинах и все они отображаются вкладками в корзине. Однажды к нам пришёл продакт с такой мыслью:
Бывает так, что друзья заказывают вместе, но каждый хочет разное — один мясное, другой вегетарианское.
Нужно, чтобы они могли сделать два заказа одновременно, а его привёз один курьер без двойной платы за доставку.
Так зародилась идея мультизаказа.
Прокси-сервис ускорил разработку
Мультизаказ требует работы сразу с несколькими корзинами, а стандартная логика Еды работала только с одним заказом. Нужно было адаптировать код и продумать множество нюансов: от отображения апселл-подборок до удаления товаров только из одной корзины.
Переписывать бэкенд всех сервисов — нет. Сделать прокси-сервис, который соединит всё вместе — конечно!
Переписывать бэкенд всех сервисов — слишком, поэтому мы сделали прокси-сервис, который параллельно ходит за корзинами, рассчитывает скидки и отдаёт клиенту связанные корзины. Чтобы пользователю было проще, и он думал, что это один заказ.
В мультизаказе ты потрогаешь всё
Проект нельзя было просто включить как небольшую фичу — сначала его нужно было довести до MVP-состояния. Это классный вызов для разработчика: приходится работать и с фронтом, и с бэком, адаптировать экраны, продумывать архитектуру. Сейчас в планах улучшать и расширять флоу мультизаказ для пользователей, чтобы всё в интерфейсе было понятно.
Мультизаказ — классный вызов для разработчика
Еда — это и удобство, и забота
В больших городах день пролетает за работой, и хочется оставить время на вкусную еду без походов в магазин. Еда и её новые фичи помогают в этом, и я рада быть частью сервиса.
За три года в Яндексе я прокачалась от разработчика до лида, собрала сильную команду и работаю над такими масштабными проектами
— это круто!
Следующая история
4 / 6
Как команда Доставки написала алгоритм для создания идеальных курьерских маршрутов
Паша Иванцов, ведущий разработчик группы продуктового развития диспатча, расскажет, как сделать один алгоритм, учитывающий десятки параметров, и оптимизировать всю цепочку доставки курьерами.
Заказов больше, чем курьеров. Поэтому мы собираем несколько заказов в единый маршрут
Клиентам хочется, чтобы курьер находился на заказ как можно быстрее
Мы живём в таком мире, когда заказов всегда больше, чем курьеров. Чтобы это решить, мы собираем заказы в маршруты. Если курьер может по пути захватить и доставить что-то ещё — супер! И даже если рядом с новым заказом нет свободных курьеров, найдём того, кто только едет в нашу сторону.
В Такси работает, почему нельзя запустить в Доставке
Когда водитель такси подъезжает к месту назначения, он уже видит новые заказы в этом районе и может взять следующего пассажира. При этом он точно знает, сколько метров до нового заказа и сколько времени он потратит, чтобы доехать.
В Доставке больше переменных. Например, в трёх соседних домах в радиусе 500 метров есть три заказа. Первая доставка на 12 этаже со сломанным лифтом. Вторая — в соседнем доме, лифт работает, но клиент недоступен в ближайшие полчаса. Третья — на другой стороне шоссе, где рядом нет ни одного места для парковки!
Так три заказа в радиусе 500 метров превратились в пару часов занятости курьера.
Курьер может доставлять несколько заказов в радиусе 500 метров. Только в этом радиусе ему нужно заехать в 3 разных дома и на 3 разных этажа
Решаемся на стремительный эксперимент без лишних сложностей
Нашей задачей стало создание алгоритма, который будет добавлять курьеру заказы по пути. Не просто последовательно ставить задачи «в конец списка», а решать — куда оптимальнее и быстрее доехать, что можно взять по пути, какие и сколько доставок можно брать одновременно. Ведь горячее с холодным, документы с напитками и еду с одеждой вместе не повезёшь.
Менять и без того непростой код мы не стали и написали лаконичный алгоритм для поиска освобождающихся курьеров. В разработке приняли участие многие команды, и первый прототип был готов всего через 3 недели. Его уже запустили в тесты!
Добавлять заказы курьеру по пути можно, но нельзя складывать ему в сумку всё подряд
Сценарий стал важной частью сервиса — 20% заказов назначается по новому алгоритму
А решать возникающие здесь задачи — настоящий челлендж для любого разработчика.
Доставка — это сервис, где алгоритмы, математика и ML делают жизнь людей удобнее
Сразу наблюдаешь эффект от каждой новой строчки кода
Здесь сразу наблюдаешь эффект от каждой новой строчки кода: благодаря алгоритму и ML‑предсказаниям, и курьеров стали назначать быстрее, и приезжают они за меньшее время. Хоть мы и видим всё это на графиках и в беспристрастных числовых результатах, но внутри знаем, что где-то в городе люди получили свою доставку чуть быстрее и чуть удобнее, чем раньше.
5 / 6
Как команда Техплатформы оптимизировала и ускорила работу поддержки с помощью LLM
Коля Пономаренко — тимлид команды SupportAI — расскажет, зачем разработчикам городских сервисов Яндекса нужна Техплатформа и как внедрение LLM оптимизирует работу поддержки.
Мой путь в Яндексе — сложный и тернистый
Свой рост я начинал со стажировки в бригаде поиска смысла и создавал болталку для Алисы. Сейчас это команда элаймента в Алисе — ребята, которые напрямую делают YandexGPT.
Затем я поменял команду на TaxiML, внутри которого занимался задачами автоматизации поддержки (SupportAI). Именно эта небольшая команда впоследствии переросла в большой продукт, ставший частью Техплатформы.
Техплатформа делает общие технологии для всех городских сервисов
Зачем команде Лавки, Маркета, Доставки держать отдельные команды, если можно сделать универсальные инструменты? С их помощью можно, во-первых, эффективнее использовать ресурсы, во-вторых, дать пространство внутри команд сервисов для исследования и прокачки.
В этом суть работы Техплатформы — создать и оптимизировать общие для всех сервисов инструменты и решения. Чтобы разработчикам было кайфово делать своё дело!
Техплатформа помогает эффективнее распределять ресурсы и давать простор для исследования внутри команд сервисов
Сгенерированные ответы против десятков тысяч макросов
Сегодня мы специализируемся на генеративных сетях — LLM, YandexGPT. За последние полгода мы взлетели: сделали suggest’ы операторам поддержки в Маркете.
Раньше оператору, чтобы ответить в чате, нужно было выбрать подготовленный шаблон. Соответственно, ты приходишь в чат, тебе нужно понять проблему, а потом выбрать из десятков тысяч шаблонов! Неудобно и суперсложно.
А давайте возьмём и будем с помощью LLM генерировать варианты ответов оператору и вставлять их прямо в поле ввода. И вместо того, чтобы долго и нудно выбирать макрос, с которым ещё и ошибиться можно, ты можешь чуть-чуть подкорректировать сгенерированный текст и отправить пользователю. При этом сэкономив кучу времени!
Но на этом мы тоже не останавливаемся.
Сейчас мы в Маркете и в Такси запускаем автоответы. Мы уже не дожидаемся оператора и отвечаем исключительно с помощью LLM
Генеративные технологии в большинстве своём неокупаемые, но…
Использование LLM в сервисе поддержки для автоматизации — одна из самых крутых идей, как эти технологии на данный момент можно окупить. В поддержку приходят десятки обращений в секунду, и вместо человеческого ресурса мы тратим вычислительный. И мы видим, что зачастую ответ нейросети не только не уступает ответу человека, но и иногда оказывается лучше.
Автоматизация полезная и для компании, и для человека, работающего в поддержке. Мы снижаем затраты времени оператора на общение в одном чате — сейчас это примерно 15%. Соответственно, человек может в среднем отвечать на большее число обращений и больше зарабатывать.
Использование LLM в сервисе поддержки для автоматизации — одна из самых крутых идей, как эти технологии на данный момент можно окупить
Мы снижаем затраты времени оператора на общение в одном чате — сейчас это примерно 15%
Заменяет ли LLM настоящего оператора
У нас работают десятки тысяч людей. Инструменты автоматизации помогают увеличить их продуктивность и облегчить сложные ежедневные задачи.
Но заменять всех в поддержке на ИИ мы никогда не будем — есть обращения, с которыми LLM до сих пор не может справиться и вряд ли сможет. Например, на обращения линии urgent будет отвечать оператор. Так как иногда оперативная помощью от человека может быть критически важной.
Поддержка городских сервисов — одна из самых больших во всей России
6 / 6
Следующий воркфлоу
Ребята из команды классные — как с профессиональной точки зрения, так и пообщаться в пятницу вечером