Yandex for Products

💞 Мы ждали целый год, чтобы снова позвать вас на главный фестиваль Яндекса для продактов! Если вы думаете о будущем продуктов, AI и технологиях — вам на Product : Fest! Встречаемся 25 июля в Москве. ▶️ В этот раз обсудим космическую скорость, которая стала новой нормой Сверим подходы и поймём, как создавать крутые продукты, когда MVP собираются за считаные дни, решения принимаются динамичнее, а изменения происходят раньше, чем мы успеваем к ним привыкнуть. Будут реальные кейсы, хардовые доклады, нетворкинг, метрики и честные разговоры о том, что не взлетело. И конечно, куда же без AI — обязательно погрузимся в эту тему 😋 А ещё вас ждёт атмосфера летнего фестиваля, активности на свежем воздухе, музыка и угощения. 🎙 На сцену выйдут эксперты, которые постоянно превращают идеи в запуски: 🟣 Валера Стромов, CEO Алисы и Умных устройств Яндекса; 🟣 Марина Перескокова, СРО роботизированной доставки Яндекса; 🟣 Никита Кожуханов, CPO SuperApp Яндекс GO; 🟣 Иван Стельмах, СРО Центрального университета, профессор РЭШ; 🟣 Александр Капустин, СЕО Unirest IT (Rostics IT); 🟣 Анна Ковалева, Коуч ICF, Hogan, предпринимательница; 🟣 Кирилл Гурбанов, основатель sfer.аi. 🔸 Это только часть программы — скоро продолжим знакомить вас с другими спикерами и активностями. Регистрация уже открыта, ждём вас! Подписывайтесь: 💬 @Yandex4Products 📹 @YandexforProducts

💞 Про любовь: как люди и компании строят отношения в современном мире Приглашаем на What’s next meetup — онлайн-встречу для специалистов по HR-бренду, маркетингу и PR, а также для руководителей больших команд. Это пространство для живого общения и возможность посмотреть на культуру компаний и коммуникации с профсообществами через международные тренды, искусство и философию. 📆 На встрече 16 июня будем говорить про любовь. Эту тему редко затрагивают в профессиональных дискуссиях. Тем интереснее будет узнать, как любовь влияет на проекты, мотивацию и лояльность команды. Вместе с экспертами из разных сфер попробуем разобраться, почему одни рабочие отношения оказываются мимолётными, а другие длятся годами и выдерживают масштабные перемены. 🐚 Обсудим, как измерить любовь сотрудников к компании, что такое полиамория в контексте корпоративной карьеры и в чём настоящий секрет лидерства в больших системах. А все подробности о докладах ищите в карточках выше. 🔸 Регистрируйтесь, чтобы поговорить с нами о любви! Мы пришлём вам ссылку на трансляцию. Подписывайтесь: 💬 @Yandex4Products 📹 @YandexforProducts

Решить боль исполнителей ❗ Квест принят Всем привет, на связи Лиза Фёдорова и Аня Кожевина. Мы руководим курьерским и операционным продуктом в Яндекс Доставке. Наш основной «клиент» — это курьеры. Каждый день они помогают тысячам пользователей: доставляют еду и посылки. При этом к курьерам есть важные требования: укладываться в рассчитанное время и принимать заказы. Если исполнители не принимают или отменяют их, они теряют приоритет. Когда этот внутренний показатель падает слишком сильно, аккаунт курьера может быть временно заблокирован. На дашбордах всё выглядит красиво: высокая доля принятых и выполненных заказов, счастливые заказчики. Но система работает не идеально — курьер может потерять приоритет из-за несправедливости. Например, если заведение закрыто, заказа нет или сломался автомобиль. Мы обратили внимание на эту проблему и начали искать возможности для её решения. 🆚 Справедливость требует компромисса Мы хотели найти баланс между доверием к курьеру, метриками бизнеса и качеством сервиса. Начали с глубокого погружения: всей командой ходили в поля, собирали жалобы и комментарии из поддержки и размечали проблемы с помощью LLM, а ещё прочли и вручную разобрали десятки реальных кейсов. Так получилась динамичная бизнес-логика. Основной задачей было выделить кейсы, в которых исполнитель не мог повлиять на преждевременную отмену. Таких ситуаций вышло несколько: например, заказ уже доставляет кто-то другой, потому что клиент отдал его собственному курьеру, или заказ негабаритный и не помещается в термокороб, или заведение вообще закрыто. Но это может быть и любой другой форс-мажор. Для решения мы натренировали LLM на всех релевантных кейсах, собрали бота и в формате MVP добавили его в приложение Яндекс Про. Это работает так: если курьер сталкивается с несправедливостью, он может отправить модели конкретный кейс. В зависимости от ситуации мы запрашиваем фотографии, дополнительные описания и другую информацию, которая поможет разобраться в проблеме. Модель внимательно всё разбирает, проверяет данные о заказе и точке получения (например, часы работы, указано ли требование термосумки и так далее), а также внутренние метрики и параметры курьера. Затем мы принимаем решение, возвращать ли баллы приоритета. 🆚 В конце декабря мы запустили бота в тест Уже при первом запуске мы получили положительный отклик и в курьерских чатах, и в метриках. Качество вывоза осталось неизменным: исполнители не стали чаще прерывать заказы. При этом доля жалоб на конкретные причины отмен существенно снизилась, а впечатления от работы поддержки улучшились. 🆚 Это только начало создания более справедливого опыта для исполнителей. Сейчас мы: 🟣 Внедрили дополнительную VLM, которая помогает лучше считывать фотодоказательства от курьеров 🟣 Тестируем формат, при котором сбор вводных от курьера находится во флоу отмены в продукте, чтобы не списывать приоритет сразу 🟣 Продолжаем работу над механиками, которые помогут модели убедиться, что курьер не виноват в отмене За хорошими метриками бизнеса часто стоит нерешённая боль, которая не красит показатели, но влияет на восприятие сервиса. Поэтому важно регулярно оглядываться по сторонам и прислушиваться к отзывам пользователей. Так мы сможем создавать не только успешные, но и любимые пользователями и исполнителями продукты. Подписывайтесь: 💬 @Yandex4Products 📹 @YandexforProducts

🤔 Почему вам нужно измерять не Time to Market Меня зовут Дима Алдунин, я заместитель руководителя проектного офиса Райдтеха. В этом посте расскажу про метрику, которая показывает изнанку разработки честнее, чем привычный всем Time to Market. Метрика TTM пришла к нам из времён, когда главным риском было опоздать к рыночному окну. Стартапы её подхватили: в условиях полной неопределённости и отсутствия DevOps-практик каждый релиз в продакшен был для них событием. 🆚 Но большие IT-компании сейчас работают иначе Здесь выстроен тщательный отбор при найме и отлажены CI/CD-пайплайны, поэтому мы почти никогда не сомневаемся в качестве работы определённого этапа — разработки, тестирования, выкатки и так далее. ➰ Наши проблемы чаще всего существуют на стыке функций: при передаче из продуктовой проработки в техническую, из разработки в тестирование, между релизом в прод и запуском эксперимента. И в таких условиях Time to Market перестаёт быть полезным. Эта метрика показывает проблему, но не объясняет, что именно и насколько нужно улучшить. Поэтому нам больше подходит Flow Efficiency. 🆚 Что такое Flow Efficiency Давайте представим обычный путь тикета в продуктовой разработке: требования → код → тестирование → запуск эксперимента. В реальности значительную часть «жизни» тикет проводит не в работе, а в ожидании. Например, продакт передал тикет разработчикам, они проверили его по Definition of Ready, но сразу взять в работу не смогли: до конца спринта ещё 2 дня. Когда разработка была завершена, тикет нужно было протестировать. Но у QA накопилась очередь, и тестировщик подключился только через 3 дня. В итоге задача провела 5 дней в ожидании. Допустим, всё Cycle Time составило 14 дней. Тогда активная работа заняла оставшиеся 9 дней. ➰ Flow Efficiency считается так: Flow Efficiency = время активной работы / всё Cycle Time. В нашем примере: 9 / 14 ≈ 0,64, то есть 64%. Это значит, что чуть больше половины времени задача действительно двигалась вперёд, а остальное время ждала следующего участника процесса. И это мы ещё не брались посчитать, сколько ждали смежников с уточнениями и сколько заняли правки, когда аналитик обнаружил, что ему не хватает логов для проведения эксперимента. Ну вы знаете. 🆚 У Flow Efficiency нет универсального «хорошего» значения Казалось бы, целиться нужно в стопроцентную эффективность и отсутствие простоев. На практике это возможно только для задач, которые «нужны были вчера» и к которым команда подключается, бросая всё (в канбане это тактично называют «класс обслуживания expedite»). Но если FE стабильно упирается в потолок, скорее всего, люди простаивают — в команде всегда скучает кто-то, готовый мгновенно подхватить задачу. Так что нужно искать нормальное для конкретной команды значение FE и реагировать на значимые отклонения. Например, случившееся отклонение в тренде может быть хорошей темой на ретроспективе. Только не забывайте, что FE может шуметь и лучше мерить её скользящим средним. 🆚 Диагностическая ценность Если проводить аналогии: 🟣 Time to Market — это термометр. Он выдаёт абсолютное значение и не говорит, хорошее оно или плохое 🟣 Flow Efficiency — это рентген. Он показывает, как и что у вас срастается Кроме того, FE как относительная метрика гораздо менее чувствительна к разнице размера задач. 🔸 А на какие метрики смотрите вы, когда хотите понять, всё ли хорошо с процессами? Делитесь в комментариях! Подписывайтесь: 💬 @Yandex4Products 📹 @YandexforProducts

🤔 Как найти оптимальную цену для своего продукта Привет, это снова Иван Меркурьев, старший менеджер продукта в ПромоСтраницах. Сегодня я хочу поговорить о цене. Именно она определяет, кому доступен ваш продукт, как пользователи воспринимают его ценность и какую экономику в итоге получает бизнес. 🎀 Поэтому хороший продакт должен уметь грамотно конвертировать создаваемую продуктом ценность в business value. И не брать сумму с потолка просто на основе интуиции или веры. 🕵️‍♂️ В карточках я рассказал про два инструмента, которые помогут оценить воспринимаемую ценность продукта. Я думаю, что их должен уметь использовать каждый продакт. А подробнее про оба метода можно прочитать в моём личном телеграм-канале: 🟣 Лестница цен (Price Ladder) 🟣 Метод ван Вестендорпа (Price Sensitivity Meter) Подписывайтесь: 💬 @Yandex4Products 📹 @YandexforProducts