Как правильно выстроить коммуникацию IT-отдела с участниками команды. Опыт Eda.ua
Chief Product Owner сервиса заказа еды Eda.ua Роман Плекан поделился опытом и рассказал, почему важно слушать реальных пользователей и как настроить процесс коммуникации между отделом разработки и участниками команды таким образом, чтобы не терялись ценные инсайты, а запросы были сформированы максимально понятно. То есть, как достичь общего понимания задач.
В мае этого года передо мной была поставлена нетривиальная задача. После слияния сервиса заказа еды 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. Создали для себя чек-лист и следуем ему при оценке запросов:
- Соответствует фича ли Нашему Продуктовому Видению?
- Будет ли важно через 5 лет?
- Будет ли полезно всем?
- Улучшит, дополнит или заменит существующий воркфлоу?
- Поможет ли росту бизнеса?
- Поможет ли осмысленно вовлечь пользователей?
- Если будет успешной, сможем ли мы поддерживать?
- К какому сегменту cost / benefit относится?
- Можем ли мы сделать хорошо?
- Четко ли определен скоуп?
Само собой реалии бизнеса таковы, что не всегда получается пропустить запрос через все необходимые фильтры. Иногда от борда поступают требования в одностороннем порядке. Таких немного, поэтому те запросы, которые успешно проходят проверку, заносятся в беклог.
Процесс понятен, теперь немного об инструменте. В PB можно импортировать фичу из JIRA, можно создать с нуля, а можно создать из заметки стейкхолдера. Для этого пригодится модуль Insights:
Здесь создаются текстовые заметки со вложениями, в которых описаны запросы. Точно так же, как и с фичами: есть теги, комментарии и фолловеры.
Важно: заметка еще не является задачей. Для того, чтобы создать из нее фичу, просьбу, багфикс или хотфикс продукт-менеджер должен принять решение — да или нет.
Всем, кому доводилось выполнять эту функцию в команде, прекрасно знаком негатив. Он исходит от людей, которым вам пришлось сказать “нет”. Это неизбежная часть работы и если вы не можете не угождать окружающим, рекомендую пересмотреть карьерный выбор.
Итак, мы обработали запросы пользователей, структурировали беклог, детализировали каждую из фичей на 4 спринта вперед. Что дальше?
Для стейкхолдеров важно понимать что и когда будет сделано. Высокоуровневый роудмап корректнее строить в других тулзах (мы используем productplan). А вот чтобы показать? какие фичи для каких компонентов будут релиснуты когда, внутри PB есть модуль роудмапа. Вот пример того, как это выглядит для одного из наших продуктов:
Вертикальные столбцы показывают релиз, в который планируем включить фичу. Здорово то, что с помощью фильтров можно создать сколько-угодно роудмапов для любого из продуктов вашей организации. Стейкхолдерам это нравится, довольно наглядно.
Подытожим:
- Беклог любого софтового продукта важно структурировать (PB здесь необязателен, лишь бы вам и вашей команде, а также стейкхолдерам было ясно что, для кого, где, как и зачем вы строите)
- Шаг №0 — научиться говорить нет.
- Первый шаг — навести порядок в уже существующем беклоге — настроить иерархию и нужные вам поля таким образом, чтобы они отражали приоритеты бизнеса.
- Второй шаг — установить такой алгоритм работы над фичами, при котором новые идеи проходят обязательную проверку на прочность.
- Дальше — учитывать фидбек конечных пользователей при формировании роадмапа. Логировать пользовательские истории максимально полно, тем самым избавиться от необходимости в отчетности.
Конечно, это далеко не все, что можно рассказать о нашем опыте продуктового менеджмента в Eda.ua. Но надеюсь, что мне удалось ответить на вопрос — Как решать, что делать дальше?
В этой колонке многое сказано об инструменте. Вполне возможно, что для вас «Джиры» будет достаточно — тем лучше. Дело не в инструменте, а в подходе и я надеюсь, у вас получится создавать продукты, которые нужны людям. В нашем случае такой подход (снизу вверх + сверху вниз) оказался крайне полезным — за 3 месяца навели порядок в беклоге и коммуникации, запустили Латвию на новой системе, выкатили приложение для Эстонии, в течение этого месяца запускаем Литву, сейчас заканчиваем работы по автоматизации логистической системы, редизайним админку, к концу года запускаем абсолютно новое мобильное приложение для всех стран и новый веб. Работы еще тонна, но без описанного здесь подхода, по моим субъективным подсчетам, было бы сделано в три раза меньше.
Автор: Роман Плекан, Chief Product Owner сервиса заказа еды Eda.ua
Комментарии | 6
Спасибо за статью. Очень полезна. Есть один вопрос: как Вы находите баланс минимального выпуска фичи между тем, когда она вроде запущена, но при этом запущена насколько минимально, что пользователи ее не могут должным образом оценить, и тем, чтобы не потратить на выпуск минимальной фичи больше ресурса, чем это необходимо для понимания ее перспективности?
Спасибо, что читаете, Виктор! Хороший вопрос. Для начала нужно ответить на вопрос — что такое «должным образом оценить»? И зачем вам подобная оценка пользователей на этапе выпуска MVF (minimal viable feature)? Если фича не решает проблему пользователей, неважно насколько она будет полирована и наоборот — если у пользователей острая проблема и ваша фича ее решает, даже будучи сырой, значит ваш эксперимент удался. Юзеры готовы мириться со многими несовершенствами сырых фичей, если они решают боль. Здесь помогает пройти воркфлоу пользователя самостоятельно и трезво ответить на вопрос — «Фича минимально жизнеспособна или нужно доработать?».
Здесь помогает пройти воркфлоу пользователя самостоятельно и трезво ответить на вопрос — «Фича минимально жизнеспособна или нужно доработать?».
Я понял. Это по сути и есть ответ на мой вопрос.
Но тогда есть другой вопрос — вы каст дев делаете для того, чтобы понять воркфлоу, или сами думаете? Потому что пользователь, есть такой опыт, не всегда и сам понимаем, как для него было бы лучше сделать то, что ему вроде как надо )
Виктор, опять крутой вопрос. Смотри, кастдев — процесс абсолютно необходимый для продуктов в новых нишах или для тех команд, которые пытаются ресегментировать существующие. В нашем случае для основного продукта eda.ua мы скорее вывели новый продукт на существующий рынок. В этой категории самые ленивые даже не парятся кастдевом — рынок уже исследован, юзеры тоже, конкуренты проложили дорогу. Нюансом нашего случая стала модель аггрегатора. В остальном лицевой продукт — скорее industry standard. Вокркфлоу заказа еды онлайн сложно называть революционным, мы его не открывали. В то же время очень сложно выкатить стандартное решение для внутренних пользователей. Поэтому здесь мы полагаемся на кастомер интервью и стори маппинг, используем для этого realtimeboard. Однако, даже для внешних пользователей проводим кастдев, ибо нюансов великое множество. Согласен, что пользователь часто сам не знает своих истинных потребностей. Здесь помогает 5 Whys ну и предложить беслпатный кофе незнакомцу за те самые 15 мин озарений не так уж трудно. Буквально позавчера мне посчастливилось провести интервью с девушкой из России, которая никогда не заказывала еду онлайн в Украине — получил тонну инсайтов и вам рекоммендую.
Поделись секретом, как настроить Риалтаймборд, чтобы для каждой задачи можно было подключить свою задачу из Трелло. Я тут попытался и создал две интеграции с Трелло (одна интеграция — одна как бы доска). И вот что оно мне теперь предлагает: http://joxi.ru/zAN9zy4CBX1lV2
У нас пока что небольшой стартап и мы релизы в Трелло досках раскидываем (задачи собираем в одну доску и это релиз). А с Риалтаймбордом получается, что надо отказаться от релизов в Трелло, так как все карточки как бы в куче, и релизы только в Риалтаймборде вести. Ну, то есть надо менять устоявшееся, но не факт, что на лучшее )
Виктор, по-моему ты сейяас говоришь про Продактборд. У них есть штатный эксперт по интеграциям, с которыми советуется саппорт. Напиши им в Интерком — они отреагируют в тот же день и помогут с твоим вопросом. Сам я Трелло жутко не люблю и вряд ли дам объективный совет.