Как настроить сквозной и бесшовный процесс перехода задач из discovery в delivery 

В прямом эфире в Telegram-канале The Tech Product Director Ride-Hailing в inDrive рассказал о переходе от discovery к delivery. Делимся самыми интересными мыслями в текстовом формате.

Никита Лебедев, RH Product Streams Director в inDrive 

О себе 

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

После попал в Авито на позицию аналитика корпоративных финансов и стратегии. Проработал там некоторое время, прикоснулся к продукту и понял, что это мое. Затем работал в компании Qlean и в Яндексе. А теперь занимаю позицию в InDrive, отвечая за райд-хейлинг.

О деятельности 

Роль продуктового директора может сильно отличаться в зависимости от компании. К примеру,  inDrive активно растет и развивается в сфере mobility-as-a-service. Помимо поездок, inDrive предоставляет растущий перечень городских услуг, включающий междугородние и грузовые перевозки, вызов мастера, курьерскую и  B2B доставку. Основное направление и продукт, за который я отвечаю, — это перевозки пользователей.

На данный момент мы работаем в 46 странах, более чем в 750 городах, и ежедневно выполняем миллионы поездок. Для нас важно сосредоточиться на трех ключевых вещах:

1. Выход на новые страны и рынки, где мы еще не представлены.

2. Удержание лидерских позиций в тех странах, где мы уже занимаем значительное место

3. Завоевание новых позиций в тех странах, где мы пока не на первых ролях

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

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

Моя работа оценивается по эффективности команд в достижении целей, что влияет на бизнес-метрики компании.

Про discovery и delivery 

Термины discovery и delivery давно известны и используются в разных сферах.

Discovery — это процесс понимания проблем бизнеса и пользователей, и определения необходимых действий для достижения результата. Результат может быть выражен в различных метриках, финансовых или продуктовых.

Delivery — это реализация найденного решения, доставление его до пользователей с максимальным качеством и в срок. Это включает в себя воплощение идеи в жизнь и обеспечение ее наличия на продакшене.

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

Почему важен быстрый и эффективный переход задач между этапами

Суть бесшовного перехода — это не просто концепция, а реальный процесс. Важно, чтобы переход от идеи к разработке был эффективным и завершенным, а не просто записан в backlog и забытым. Это важно, потому что, если команда понимает и реализует проблемы, выявленные на этапе discovery, появляется реальная ценность в продакшене. 

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

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

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

Проблемы выявляются через качественные интервью, исследования, запросы и эвристические подходы. Иногда достаточно экспертного анализа, если проблема очевидна.

Решения разрабатываются на основе выявленных проблем. Важно, чтобы они не терялись в инструментах вроде Miro или mind-map, а попадали в бэклог команды разработки с ясным объяснением их происхождения.

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

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

Переход от Discovery к Delivery в InDrive

Пять шагов, которые я советую для улучшения взаимодействия между Discovery и Delivery:

1. Выделите Discovery-тему.

2. Формализуйте процесс. 

3. Вовлеките участников Discovery и Delivery.

4. Проводите Greenlight, интегрируйте результаты Discovery в планирование и Agile-процессы.

5. Документируйте и фиксируйте milestones, передавайте их команде Delivery в понятном виде, чтобы инженеры знали, что делать.

Подход постепенный: не пытайтесь внедрить все сразу. Разделите его на части, выявите проблемные области и начните с них. Обсудите с коллегами, проконсультируйтесь и исправляйте конкретные проблемы, будь то отсутствие Discovery или улучшение описания задач в Delivery.

Советы и рекомендации

В InDrive мы придаем большое значение обоснованности действий продакт-менеджера. Неприемлемо, когда продакт не может объяснить, почему делает ту или иную задачу, отвечая лишь: «потому что так сказали».

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

Иногда нужно сказать «стоп» и действовать, даже если не все идеально. Важно вернуться к вопросам позже, когда это действительно нужно. Возможно, стоит остановиться, если ветка не так важна. Задавайте себе вопросы о своей работе, и все будет в порядке.