В мае этого года передо мной была поставлена нетривиальная задача. После слияния сервиса заказа еды Eda.ua с группой компаний Foodout (Латвия, Литва, Эстония) нужно было объединить 4 сервиса в один.

Задача: объединить 4 сервиса в один. Включает в себя переезд каждой из стран Прибалтики со своих старых платформ на новую, основанную на Eda.ua. Колл-центр, логистика, отделы маркетинга и коммерции – все получают новый инструмент для работы (админки), новый сайт, новые мобильные приложения.

Ядром для будущего сервиса должна была стать адаптированная версия украинского сайта. Я присоединился к команде на этапе запуска второй из четырех стран – Латвии. Это история не о том, КАК создавать софт. Мы поговорим о том, КАКОЙ софт создавать и как сделать этот процесс прозрачным для всей организации.

Когда имеешь дело со зрелым продуктом (более 4 лет), необходимо брать во внимание много переменных. У тебя есть наследие –  функциональность, продуктовые решения, принятые другими людьми, и не всегда задокументированный код. В то же время есть сформировавшаяся команда, которой нужна ясность в постановке задач и время на их реализацию. Есть борд, требования и интересы которого нельзя игнорировать; есть вектор движения продукта, который был задан до тебя и который нужно актуализировать. Но самое главное – есть пользователи: сотрудники отделов коммерции, логистики, колл-центра и маркетинга, курьеры и рестораны. Это внутренние пользователи, а также сегменты внешних юзеров, на которых и необходимо ФОКУСироваться бизнесу. Нужно сделать так, чтобы все участники процесса получили необходимые от продукта фичи. Google-таблиц здесь недостаточно.

Самое страшное, что может делать продакт-менеджер – в одностороннем порядке ставить задачи на разработку без должной коммуникации.

Не учитывать методологию и процессы, темп разработки и скорость работы команды (велосити). Не общаться с бизнесом и не общаться с разработчиками. Говорить “да” на каждый запрос о функциях и вести беклог с позиции must-have.

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

Productboard – это инструмент, позволяющий организовать продуктовый беклог, грамотно выстроить роадмап и коммуникацию с инвесторами.

Неважно, создаете ли вы новый жилой комплекс, театральное представление или сложную систему для частного кредитования, самые фундаментальные требования к вашему продукту везде одинаковы. Продукт должен быть полезным, удобным и целесообразным в реализации. Только последний критерий относится к бизнесу, первые два касаются пользователей. Поэтому фреймворк развития потребителей, предложенный Стивом Бланком, оказался настолько востребованным. Он обязывал бизнес выйти из офиса (не обязательно физически) и установить прочную линию коммуникации с целевой аудиторией продукта. Эрик Райс говорил о том же: любой продукт важно дать попробовать потенциальным юзерам как можно раньше, получить фидбек и внести коррекции.

Productboard является практическим воплощением этой философии.

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

Первый шаг – создаем структуру продуктов

У вас может быть и один продукт, тогда это гораздо проще – нужно только определить компоненты, из которых он состоит. В нашем случае продуктов больше. Ниша доставки еды требует слаженной работы сразу нескольких систем: клиентские приложения и веб-сайт, CMS (Admin panel) и бекенд, кабинет ресторана (для приема и работы с заказами из наших агрегаторов) и логистическая система (дешборд + приложения для курьеров). А теперь умножаем все это на 4 страны и становится очевидным, почему так важна иерархия.

Кайдзен (японская модель управления) никто не отменял и всегда есть что оптимизировать. Но когда структура продуктов и компонентов вашего беклога более-менее ясна, можно приступать к наполнению.

Productboard (далее – PB) поддерживает двустороннюю синхронизацию с JIRA, Trelo, GitHub и Pivotal Tracker. Это полезно не только для того, чтобы новые задачи автоматически появлялись в уже используемых инженерами программах. Это важно и потому, что уже созданные там задачи важно отобразить в вашем беклоге.

Вот как выглядит наша интеграция с Джирой:

Главная сущность внутри PB – фича. Все, кто имел дело с наполнением беклога прекрасно понимают, что хорошо описанная фича – это мини-ТЗ. Важно сделать так, чтобы и участники проекта (стейкхолдеры) и разработчики имели единое понимание того, что разрабатывается. Любой достойный восхищения b2b софт является гибким – потребности и важные критерии организации часто довольно специфичны. Но есть и универсальные параметры. В нашем случае полезной оказалась следующая настройка фичи:

0 – Самое главное – описание пользовательской истории и требований к реализации. С этого все начинается и здесь нам пока не нужны были инновации. Используем фреймворк от jobs-to-be-done и максимально тщательно описываем требования к реализации там, где это применимо.

1 – к какому подкомпоненту какого компонента в каком продукте относится данная фича. Иерархия крайне полезна, это первый шаг в организации беклога.

2 – для фичей мы стараемся использовать минимальное кол-во тегов, ведь в PB можно настраивать кастомные дропдауны, о чем несколько позже.

3 – работаем по скраму, один спринт равняется одному релизу, поэтому здесь указываем спринт с его дедлайном.

4 – сложность технической реализации, которую мы оцениваем в стори-поинтах. Таким образом можно оценивать реальную скорость работы команды (после пяти спринтов станет понятно) и корректно планировать спринты. Используем шкалу Фибоначчи.

5 – нередактируемое поле, в котором отображается средневзвешенная оценка фичи. Бизнес-ценность (драйверы, о них ниже) делится на техническую сложность – получаем значение от 0 до 100, которое крайне полезно в приоритизации беклога. Этот подход называется скоринг и о нем уже много всего написано.

6 – ссылка и текущий статус задачи в джире. Цвет статуса можно настроить для пущей наглядности, нам это помогает.

7 – здесь мы указываем степень важности фичи для сегментов пользователей. В нашем случае у нас есть 7 внутренних сегментов и 4 внешних. В вашем случае картина будет другая, но понять то, для кого это создается, крайне важно. Как и важна возможность потом отфильтровать беклог на основе этих данных.

8 – совершенно потрясающая концепция, к которой организация должна созреть. Ее суть в том, что помимо операционной деятельности здоровый бизнес никогда не прекращает улучшения. Их масштаб может быть относительно небольшим и тогда реализация требует только создания корректных операционных или девелоперских задач. Но когда масштаб предлагаемого улучшения значительно больше (автоматизация работы колл-центра с помощью Intercom, например), парой задач не обойтись.

Для того, чтобы этот процесс был системным мы придумали алгоритм описания, оценки и утверждения инициатив. Утвержденные с бордом инициативы часто требуют участия не только отдела разработки, но и других отделов организации. Тогда мы создаем проект в Асане. PB же позволяет определить, к какой инициативе относится фича и, опять же, отфильтровать беклог на основе этих данных. Когда у тебя около 1000 задач в очереди, важность подобной фильтрации трудно переоценить.

9 – те самые драйверы – то, на что фича должна повлиять в позитивную сторону. Для каждого бизнеса эти критерии отличаются, но в нашем случае мы выбрали следующие: Automation & Logistics; AOV & LTV; Conversion & Retention; Customer Service и UX. Во время создания или груминга фичи мы проставляем предполагаемые баллы по каждому из параметров от 0 до 5. Это не точная наука, здесь важно слушать бизнес и полагаться на продуктовое чутье. У каждого из параметров есть свой вес. Полученная путем сложение цифра затем делится на effort и получаем средневзвешенную оценку (пункт 5). Вот вам и скоринг беклога.

10 – здесь начинаются кастомные настройки, специфичные для нашей организации. В вашем случае это будет выглядеть иначе, но может и наша модель пригодится. Мы находим полезным возможность настраивать свои дроп-дауны – это добавляет ясности и ускоряет процесс груминга. А поскольку для каждого спринта необходимо отгрумить от 50 до 150 задач, фича крайне полезна. Первый дропдаун – тип задачи. В нашем случае мы делим все задачи на фичи, просьбы, баги и хотфиксы.

11 – здесь мы указываем тип улучшения. Он может быть направлен на улучшение фичи для существующих пользователей (deliberate), рост пользовательской базы (adoption) и увеличение частотности пользования продуктом (frequency). Поле применимо только для фичей, само собой.

12 – срочность задачи – нужная / важная / срочная

13 – страна для которой делаем – ALL / UA / LT / LV / EE

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

15 – здесь мы указываем автора фичи (обязательно должен иметь админские права или права редактора) и фолловеров фичи (наши любимые стейкхолдеры, у которых права вкладчика). Эти люди будут получать уведомления об изменениях в фиче и комментариях к ней.

16 – здесь мы указываем текущий статус фичи в PB.

Это все здорово, но откуда брать идеи для развития продукта?

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

Есть хорошие новости: PB создан для того, чтобы помочь нам строить продукты, которые нужны пользователям. Если требования бизнеса и технологий требуют подхода “сверху-вниз”, то для того, чтобы восхищать внутренних и внешних юзеров, важно уметь слушать. Это подход “снизу-вверх” и далеко не каждый бизнес способен оценить его по достоинству. Вот, как это работает у нас.

Подобный процесс имеет 4 участников, где ключевым является стейкхолдер, внутренний пользователь системы. Одна из ключевых интеграций PB –  c Intercom. Она позволяет вам собрать в одном месте фидбек от внешних пользователей. Саппорт или сейлз вашей команды может выделить запросы на разработку из переписки с любым пользователем, просто пометив сообщение отдельным тегом. Это крайне полезно в тех случаях, когда фундамент продукта уже создан и наступило время развивать его в сторону конечных пользователей.

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

Последний критерий – структурированное описание – является ключевым. Без него невозможно достичь общего понимания между бизнесом и разработчиками. Если вам повезет, ваши коллеги будут иметь высокую степень осознанности и ответственности, что проявится в детальных описаниях. Вот шаблон для предложения фичи, который я создал для 38 стейкхолдеров в 4 странах нашей группы компаний:

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

  1. Соответствует фича ли Нашему Продуктовому Видению?
  2. Будет ли важно через 5 лет?
  3. Будет ли полезно всем?
  4. Улучшит, дополнит или заменит существующий воркфлоу?
  5. Поможет ли росту бизнеса?
  6. Поможет ли осмысленно вовлечь пользователей?
  7. Если будет успешной, сможем ли мы поддерживать?
  8. К какому сегменту cost / benefit относится?
  9. Можем ли мы сделать хорошо?
  10. Четко ли определен скоуп?

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

Процесс понятен, теперь немного об инструменте. В PB можно импортировать фичу из JIRA, можно создать с нуля, а можно создать из заметки стейкхолдера. Для этого пригодится модуль Insights:

Здесь создаются текстовые заметки со вложениями, в которых описаны запросы. Точно так же, как и с фичами: есть теги, комментарии и фолловеры.

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

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

Итак, мы обработали запросы пользователей, структурировали беклог, детализировали каждую из фичей на 4 спринта вперед. Что дальше?

Для стейкхолдеров важно понимать что и когда будет сделано. Высокоуровневый роудмап корректнее строить в других тулзах (мы используем productplan). А вот чтобы показать? какие фичи для каких компонентов будут релиснуты когда, внутри PB есть модуль роудмапа. Вот пример того, как это выглядит для одного из наших продуктов:

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

Подытожим:

  • Беклог любого софтового продукта важно структурировать (PB здесь необязателен, лишь бы вам и вашей команде, а также стейкхолдерам было ясно что, для кого, где, как и зачем вы строите)
  • Шаг №0 – научиться говорить нет.
  • Первый шаг – навести порядок в уже существующем беклоге – настроить иерархию и нужные вам поля таким образом, чтобы они отражали приоритеты бизнеса.
  • Второй шаг – установить такой алгоритм работы над фичами, при котором новые идеи проходят обязательную проверку на прочность.
  • Дальше – учитывать фидбек конечных пользователей при формировании роадмапа. Логировать пользовательские истории максимально полно, тем самым избавиться от необходимости в отчетности.

Конечно, это далеко не все, что можно рассказать о нашем опыте продуктового менеджмента в Eda.ua. Но надеюсь, что мне удалось ответить на вопрос – Как решать, что делать дальше?

В этой колонке многое сказано об инструменте. Вполне возможно, что для вас «Джиры» будет достаточно – тем лучше. Дело не в инструменте, а в подходе и я надеюсь, у вас получится создавать продукты, которые нужны людям. В нашем случае такой подход (снизу вверх + сверху вниз) оказался крайне полезным – за 3 месяца навели порядок в беклоге и коммуникации, запустили Латвию на новой системе, выкатили приложение для Эстонии, в течение этого месяца запускаем Литву, сейчас заканчиваем работы по автоматизации логистической системы, редизайним админку, к концу года запускаем абсолютно новое мобильное приложение для всех стран и новый веб. Работы еще тонна, но без описанного здесь подхода, по моим субъективным подсчетам, было бы сделано в три раза меньше.

Автор: Роман Плекан, Chief Product Owner сервиса заказа еды Eda.ua