бэклог тикетов что это

Из рутины в приятный процесс: что такое бэклог продукта и как им управлять?

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

Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.

Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.

Бэклог продукта vs бэклог спринта

Эти два компонента Scrum несут разный смысл, но их часто путают.

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

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

Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.

В чем смысл бэклога продукта?

Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.

Обычный бэклог продукта включает следующие пункты:

Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.

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

Обычно команда добавляет нужные детали и оценки в элементы бэклога во время специального проекта, который называется backlog grooming или refinement.

Для чего нужен backlog refinement?

Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.

Чем бэклог продукта в Agile отличается от простого списка дел?

У бэклога продукта есть определенные свойства:

Что делать, если бэклог неустанно растет?

Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?

Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:

Структурирование бэклога

В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:

Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.

Оценка идей

В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.

Backlog Priority Chart

Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:

Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.

Источник

Backlog в управлении продуктом: что делать, когда идеи нарастают «как снежный ком»

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

В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).

Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).

Однако вернемся к большому скоплению идей и инициатив.

Определяем проблему

Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.

Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.

Находим решение

Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:

Структурирование бэклога

Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.

Например, колонками на этой Kanban доске могут быть этапы работы над идеями:

Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.

С помощью Swimlanes вы можете разделить идеи. Например, так:

Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замечая их, пользователи чувствуют заботу о них и больше доверяют.

Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.

Оценка идей по Value и Effort

Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.

Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:

Процесс оценки идей по Value в компании такой:

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

У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.

Выбор идей с помощью визуального инструмента Backlog Priority Chart

Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:

График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.

Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.

Заключение

Подводя итог, кратко выделим главное:

Источник

Бэклог продукта — совершенный список задач

Бэклогу продукта, как и человеку, нужны уход и внимание. А еще он должен быть открыт для других.

Просмотр тем

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

Что такое бэклог продукта?

Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).

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

Два столпа бэклога продукта

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

Веб-сайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.

Владелец продукта составляет из этих пользовательских историй единый список для команды разработчиков. Владелец продукта может упорядочить истории так, чтобы команда сначала выполнила один эпик полностью (слева). Как вариант, может быть важнее сначала протестировать бронирование билетов со скидкой, а для этого нужно реализовать истории из нескольких эпиков (справа). Оба варианта представлены ниже.

Что может повлиять на то, как владелец продукта расставляет приоритеты?

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

Правильное ведение бэклога

После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить расстановку приоритетов и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога в кругах специалистов по Agile часто называют «грумингом» или «ведением бэклога» (некоторые используют термин «уточнение бэклога»).

Когда бэклог становится достаточно большим, владельцам продукта приходится выделять в нем группы краткосрочных и долгосрочных задач. Краткосрочные задачи нужно досконально проработать, прежде чем присвоить им этот статус. Для этого нужно составить полноценные пользовательские истории, обсудить все детали совместной работы с дизайнерами и разработчиками и оценить сложность разработки. Долгосрочные задачи могут быть продуманы не до конца, однако если команда разработчиков даст им приблизительную оценку, это поможет расставить приоритеты. Ключевое слово здесь — «приблизительная». Оценки поменяются, когда команда получит полное понимание долгосрочных задач и приступит к их выполнению.

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

Когда бэклог становится слишком большим, чтобы на него хватало ресурсов команды даже в долгосрочной перспективе, задачи, до которых никогда не дойдет очередь, можно закрывать. Помечайте такие задачи специальной меткой, например «Вне объема работ», в трекере задач команды, чтобы изучить их позднее.

Плохие примеры, которые лучше не повторять

Бэклоги продукта и верность команды принципам agile

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

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

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

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

Источник

Как подготовить бэклог продукта с большим количеством зависимостей и не потратить время впустую

Привет, меня зовут Макс, я продакт команды Self-Service в мобильном приложении Тинькофф. У моей команды три основные цели по созданию сервиса: contactless, proactive и self-service.

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

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

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

Представим, что вы всё записываете в заметки или блокнотик. У здорового продакта возникает логичный вопрос: какие задачи решать в первую очередь?

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

Раньше я использовал классическую ICE-методику, но в Тинькофф пришлось ее адаптировать. Сейчас расскажу как.

Мои пункты оценки бэклога

Название идеи — краткое название и суть того, что хочется сделать.

Основная гипотеза — как фича повлияет на пользователей и бизнес. Например: если мы добавим фичу «Изменить номер в МБ», то сократим обращения к оператору, время до целевого действия и количество касаний. То есть, количество шагов нужное пользователю, чтобы решить вопрос, сократится: мобильное приложение — бот — первая линия — бэк-офис и т. д. Форматы описания гипотезы есть в свободном доступе, их перечислять я не буду. Главное, чтобы вы и команда понимали, что делаете и зачем.

Ожидаемый результат — что должно получиться в итоге. Описание должно содержать критерии приемки задачи, а результат — конкретику. Например, «после реализации фичи пользователь может изменить контактный номер телефона без обращения в банк».

Вариант MLP/MVP. MVP — уже знакомое понятие, но недавно появилось еще одно — MLP: minimal loveable product. Уверен, вы и раньше использовали MLP, просто не называли его так. Важно подумать про то, как мы проверим нашу гипотезу и получим первые инсайды до того, как потратим ресурсы на целевое решение. Стоит использовать MLP, если финальное решение не зависит от результатов А/В-теста, есть возможность отдельно реализовать сценарий в MLP и вы уже сейчас можете поставить основной сценарий на прод без потери качества.

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

Критерии хорошего бэклога

Для определения приоритетов я использую ICE-метод. В ICE мы оцениваем идеи по трем параметрам: impact, effort и confidence.

Impact показывает, насколько идея положительно повлияет на ключевой показатель, который хотим улучшить.

Effort — оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.

Confidence демонстрирует, насколько мы уверены в оценках влияния и легкости реализации.

Подробнее об impact

Чтобы определить влияние на метрики — составляем справочник. Мне нравится подход, в котором за единицу impact берется 1% от значения основных продуктовых метрик. Например, ваша основная продуктовая метрика — это CAC, и она равна 1500 ₽. Impact в этом случае будет равен 15 (1% от 1500).

Хорошо, если продуктовые метрики будут соответствовать трем основным критериям:

Показывать ценность продукта для потребителя.

Пересекаться с целями компании.

Понятно влиять на деньги.

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

Метрика верхнеуровневая и нечувствительная. Она не подходит для составления справочника, оценки работы результатов команды и отслеживания результатов эксперимента. Поэтому декомпозирую ее на более приземленную: доля активных клиентов мобильного приложения, которые не обращаются в поддержку по определенной тематике. За значение impact 1 я беру 10 000. Топ обращений не волатилен в течение года в относительных величинах. Под значениями 1—10 можно подразумевать что угодно — главное, чтобы значения были согласованы между собой.

Оценивая гипотезу, я выбираю соответствующее значение. Например, фича «изменение номера» в мобильном приложении сократит обращения к оператору по тематике «изменение данных» на N в месяц. Подставляем соответствующее значение impact.

В данном кейсе определить это число просто. Нам известно поведение пользователей. Сколько человек пишут в чат, чтобы изменить номер; сколько заходят на экран профиля, перед тем как обратиться; у какой доли обратившихся есть мобильное приложение и т. д. Но так бывает не всегда. Если вы хотите побольше погрузиться в то, как считать потенциальный impact, рекомендую книгу «Как измерить все, что угодно» Дугласа Хаббарда.

Позже каждая фича проходит через A/B-тест, где основные метрики для оценки эффективности — количество/доля обращений по тематике, время до целевого действия и количество касаний.

Подробнее о том, как выбрать основные продуктовые метрики, расскажу в следующей статье.

Подробнее о confidence

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

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

Подробнее про effort

Собираемся с теми, кто будет участвовать в разработке фичи, и пишем ожидаемое время разработки в часах/днях/неделях. Главное — использовать одну единицу измерения. Чем больше у вас будет информации по задаче к этому времени, тем точнее будет оценка.

С ICE все — дальше только ссылка на трекер с задачей: с подробным описанием идеи, дизайном, ссылкой на исследование и т. д.

В чем подвох описанного выше метода в реалиях нашей команды? Хороший продукт — это всегда сто один компромисс и умение управлять ими.

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

Допустим, для оценки effort желательно иметь подробное описание задачи и дизайн, а это как минимум ресурс продакта, аналитика, дизайнера, коллег с бэка и других бизнес-линий. Их время можно потратить впустую, потому что может оказаться, что задача нереализуема в ближайшие полгода или год. Дизайн и аналитика устареют — работа проделана зря.

Из-за этого мои гипотезы проходят некий прескоринг перед тем, как попасть в бэклог. Его задача — быстро найти ограничения, постараться понять, где нужно решать проблему, и отправить на оценку в бэклог реализуемые задачи, а не мысли «звездочета».

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

Мой прескоринг

Расскажу, что включает в себя мой прескоринг.

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

Технические ограничения. Нужно убедиться, что фича реализуема в ближайшие 3—6 месяцев. При выборе периода исходим из скорости движения вашей команды. Это нужно для того, чтобы правильно определить приоритеты и делать то, что не заблокируется другими системами.

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

Поиск заинтересованных сторон aka бизнес-возможности. У наших задач много зависимостей от бэка, они затрагивают больше 10 команд. У этих систем много заказчиков и свои приоритеты. Чтобы задача попала в их бэклог с правильным приоритетом, нужно комплексно оценить ее. Возможно, вашей фичей вы положительно повлияете не только на метрики вашей команды, но и — о чудо! — на метрики других команд. Это очень важно, потому что поможет правильно оценить value и заручиться поддержкой других продактов.

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

Пример прескоринга фичи «изменение контактного номера в мобильном приложении»

Бизнес-ограничения. Явных ограничений нет, но нужно понаблюдать за метриками других продуктов, чтобы выяснить, как мы на них влияем.

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

Требуемые доработки в бэке:

Метод смены контактного номера телефона в сервисе изменения клиентских данных Person Profile.

Доработка сброса кэшей в API.

Рефакторинг многошаговой конфирмации в API.

Доработка сервиса лицевой биометрии.

Доработка конфирмации в core-компоненте.

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

Требуемые доработки в чат-боте. Для разных типов клиентов нужен свой, особенный ответ чат-бота: одних ведем на экран в МП, вторых в КЦ.

Дизайн-ограничения. Планируется редизайн экрана другой командой, где будет точка входа в фичу — синк с командой, ответственной за экран.

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

Команда origination: изменение контактного номера в мп может заэффектить долю клиентов с актуальным номером телефона, что повлияет на скорость обработки заявки и конверсию из заявки в открытие продукта.

Команда person profile: чем выше доля актуальных контактов, тем ниже расходы на их дедупликацию.

Команда Tинькофф Мобайла: один из продуктов экосистемы Тинькофф — мобильный оператор Тинькофф Мобайл. Как правило, контактный номер телефона в банке основной для клиента. NPV основного номера выше на X. Фича «изменить контактный номер в МП» поможет промотировать, сделать номер Тинькофф Мобайла контактным в банке, увеличить NPV Мобайла и не увеличить расходы на обработку обращений.

Экосистема: с фичей появится возможность делать новые рекомендации. Сейчас в тесте два кейса: клиенту не придется вводить новый контактный номер, так как мы уже его знаем, и клиенту не придется даже искать фичу «изменить номер», так как мы знаем, что он пришел его изменить (онлайн-триггеры), и можем предложить это раньше, чем он начнет искать, как это сделать, или задаст вопрос в чате.

Заключение

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

Если ваш бэклог не отвечает на вопросы «Что, зачем и в каком порядке мы делаем?» — это не бэклог. Вам и членам вашей команды должно быть сразу понятно, почему вы делаете фичу А после фичи Б.

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

Гайды и статьи в интернете — не истина в последней инстанции. Исходите из особенностей вашего продукта и той среды, где находитесь.

Источник