Русский
Русский
English
Статистика
Реклама

Backlog

Discovery бэклог как не упустить важное

18.09.2020 12:15:01 | Автор: admin
Всем привет! Меня зовут Юля, я отвечаю за развитие продукта Social Trading в Exness. Немного обо мне. Работаю в продуктовой разработке восемь лет в роли продакта. Начинала заниматься этим, когда эта роль в российских компаниях так даже и не называлась. Сейчас мы вместе с командой делаем продукт, который позволяет трейдерам с небольшим опытом инвестировать на финансовом рынке. Если кратко, суть в том, что эти трейдеры копируют понравившиеся стратегии более опытных трейдеров.

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



Итак, какая важная часть работы продакта? Конечно, ведение продуктового discovery бэклога. В discovery бэклог мы фиксируем и систематизируем все идеи и гипотезы по достижению продуктовых целей. Этот же бэклог есть источник для формирования delivery бэклога, то есть списка идей, которые мы передаем в разработку. Если задача delivery бэклога сформулировать то, что несет максимальную ценность в данный момент, то задача discovery бэклога фиксировать все, что может быть полезно сейчас или в будущем.

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

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

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

Теперь расскажу, какие источники используем мы. Итак, поехали.

image

Первый пункт плана послушать клиента


Пожалуй, самый очевидный источник, но это не уменьшает его ценность.

Клиенты непрерывно делятся фидбеком: оставляют отзывы в сторах, комментарии в соцсетях и на форумах, пишут сообщения в службу поддержки. Может, проще оставить их без внимания, это ведь работа саппорта разбираться с обращениями клиентов? Или все-таки лучше выжать максимум из ситуации и взглянуть на это как на массовый, бесплатный канал получения идей в режиме 24х7? В Exness мы постоянно читаем, что пишут клиенты в сторах и в письмах в службу поддержки (стоим в копии переписки), имеем чат с саппортом и сразу фиксируем все идеи.

На а как получить фидбек клиентов по конкретному вопросу? Здесь помогут исследования лично, по телефону или online; глубинное интервью, опрос, UX-тестирование. Все зависит от задачи и наличия времени. Исследование можно легко провести самому online: множество сервисов вам в помощь или же попросить саппорт, продажи. Последние с радостью примут предложение, ведь какой sales откажется от позитивного повода для контакта с клиентом?

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

Так, одним из самых популярных пожеланий инвесторов было добавление Stop Loss и Take Profit (автоматическое закрытие инвестиции при достижении определенной суммы). Мы запустили эту фичу в августе. Посмотрим, как отразится это на общем уровне NPS, и какое пожелание будет в топе в сентябре.
Там же запускаем быстрые опросы инвестиционный профиль, предпочтения по рынкам и так далее.

image

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

Интервью проводим по фреймворку Job to be done, он позволяет получить максимум инсайтов юзера. Каждый раз узнаем массу нового, так как продукт развивается, а клиенты все разные, и они также развиваются вместе с нами.

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

Данные не умеют говорить, но задают вопросы


У продуктов обычно существуют целевые метрики, по которым измеряется его успех. Если метрик нет, то лучше сделать так, чтобы они появились. Метрики и цели по ним часто являются результатом каскадирования метрик компании, измерителями достижения цели продукта (например, в виде OKR, Objectives and Key Results) или же синтезом этих двух вещей. Например, число активных пользователей, время, проводимое в приложении одним пользователем за период, доход на одного пользователя, NPS.

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

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

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

Покажу на примере. Наша цель в 5 раз увеличить число активных пользователей (активный пользователь имеет открытую инвестицию на 7 день после регистрации и позднее). Мы смотрим на конверсию скачивания в первую инвестицию, сравниваем с аналогичным показателем в другом продукте Exness (мобильное приложение для самостоятельного трейдинга). Видим, что там конверсия в полтора раза выше, хотя по идее наш продукт более простой и направленный на массового потребителя. Начинаем смотреть глубже: для разных стран, разных типов трафика разница почти везде есть, особенно большая для рекламного трафика. Берем самую популярную страну и рекламный трафик, строим воронку по каждому шагу и видим, что самое большое отличие на шаге пополнения баланса. Встречаемся с коллегами, просим поделиться секретом успеха, и все оказывается просто. Все мы изначально внедрили стандартный процесс: клиент кликает в Сделать депозит, заполняет анкету о себе, прикрепляет документы, потом выбирает платежное средство. Коллеги сделали A/B тест, где просто поменяли местами эти шаги и сначала дали выбрать платежное средство. Пользователь на первом шаге видит, что есть удобный для него способ пополнения (клиентам это очень важно, так как в разных странах распространены совершенно разные способы). И дальше он уже готов потратить время на заполнение анкетных данных. А/В тест показал свой эффект, коллеги раскатали на всех. Уже через неделю мы запустили аналогичный тест у себя, который также показал статистически значимый прирост в конверсии.

Конкуренты формируют ожидания, или куда движется рынок


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

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

А что в это время делают ведущие digital-сервисы?


Ведущие локальные и мировые digital-сервисы также формируют привычный клиентам опыт и ожидания, даже если работают на другом рынке. Если клиент смог оплатить в Интернет-магазине одежды покупку через Apple Pay, он захочет оплатить также и бронирование отеля. Ну и не зря эти ведущие сервисы ведущие. У них можно черпать идеи по стандартным юзер-сценариям, таким как регистрация, онбординг, каталоги товаров/ услуг, платежные сервисы и так далее.

О чем могут рассказать коллеги


image

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

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

Стратегия компании


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

А что за продукт мы вообще строим


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

Сотрудничество внутри компании


Продукт чаще всего не существует отдельно и сам по себе. Есть другие подразделения в компании, которые оказывают влияние на продукт и/ или зависят от него: поддержка, маркетинг, продажи, антифрод, финансы. У этих подразделений есть свои цели и свои проекты, для реализации которых нужны доработки в продукте. Часто вижу, что такие задачи воспринимаются продакт менеджерами негативно: Вот снова пришли со своими идеями/ запросами. Да, это они авторы этих идей, но это не значит, что эти идеи бесполезные. Они могут принести в результате больше пользы продукту, чем ваши самые классные (потому что ваши) идеи.

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

Продуктовой команде тоже есть, что добавить


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

Подытожим


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

Ну и небольшие заметки по тому, как фиксировать идеи наилучшим образом:

  • Ориентироваться в списке из 200 идей сложно, поэтому лучше сразу систематизировать их по темам, инициативам, каким-то крупным логическим кускам;
  • Если изначально идея была сформулирована как проблема, то лучше зафиксировать наиболее четко смысл проблемы и рядом вариант решения в виде гипотезы. Когда начинаешь заниматься этой проблемой, может оказаться, что есть лучшее решение;
  • Любая задача делается не просто так, а чтобы, как мы уже говорили выше, прокачать какую-то метрику или в рамках стратегических инициатив. Мы прямо в документе сделали соответствующий раздел, где перечислили их. Он позволяет при добавлении идеи или проблемы заматчить ее с целями. И те идеи, которые не матчатся, сохраняются, но отдельно.

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

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

Если эта тема вам интересна, откликается, то об этом можно будет поговорить в отдельной статье. Желаю всем найти свои источники и сделать продуктовую разработку максимально эффективной!
Подробнее..

Из песочницы Приоритизация фичей

17.10.2020 16:19:19 | Автор: admin
Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритизируем. Голова лопается, мы не знаем, что делать с этими идеями. В вашем листе идей какой-то ад творится Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами.

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

Для начала рассмотрим переменную таблицу методов приоритизаций:



Исходя из данной таблицы, можно сделать вывод.

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

Если же принимают участие пользователи, то соответственно это внешние.

По вертикали, то сколько данных есть для принятия решений.

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

Внешние методы применяются:
Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя.

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

Внутренние методы применяются:

Когда есть история какая функциональность меняет метрики, можно сделать приоритизация внутри команды.

Уточнение результатов полученных из внешних методов;

Мы рассмотрели основные различия внутренних и внешних методов.

Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная.

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

Быстрые методы


Метод Reach/Frequency


Reach охват аудитории. Сколько людей готовы воспользоваться фичей.

Frequency частота использования фичи.



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

Метод Poker planning


Идея взята из Agile методологий. (Оценка производится внутри команды.)

Оценка пользы фичи

Команде ставится условие: 1 палец фича не очень, 2 пальца фича норм, 3 пальца фича просто бомба.

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

Оценка затрат

Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец быстро сделают. 2 пальца разработка будет не сложной. 3 пальца разработка будет очень сложной и долгой.

Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.



Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритизаций. Фича 2 имеет самый низкий процент мы точно выкидываем из нашего бэклога.

Медленные методы


RICE


Разработан компанией intercom.

Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритизации фич:



Reach охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу.

Impact влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 очень плохо, 0.5 плохо, 1 средне, 2 хорошо, 3 отлично)

*** Некоторые считают что impact это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи.

Confidence Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже)

Effort Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5)

Приоритизация по ROI


Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.



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


Пример приоритизаций из иерархии метрик




С командой мы расставляем вес фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года.

Пример приоритизации по ROI




У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей.

Я прикидываю, что внедрение фичи принесет компании 4% от прибыли.

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

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

Имея эти данные мы можем посчитать ROI ((доходы расходы) / расходы * 100%) фичи.
Таким образом, мы можем посчитать все фичи из бэклога и приоритизировать его.

*** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными.

Плюсы:

Ты получаешь оценку в деньгах. Люди любят деньги.

Люди верят числам.

Минусы:

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

Нюансы:

Считать прибыль, а не выручку.

Типичные ошибки Product managerов


1. Оценивать в одиночку.

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

2. Не учитывают влияние одной части на другие части продукта.

Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;

3. Повестись на хейтеров.

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

4. Количественная оценка не всегда лучше, чем качественная.

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

5. Закопаться в мелочах. Смотрите на продукт сверху!

Итог


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

Спасибо за уделенное время.
Подробнее..

Риски сами с собой не управятся, да и бэклог сам себя не сделает

22.12.2020 10:22:28 | Автор: admin
Риски сами с собой не управятся, да и бэклог сам себя не сделает. Если хотите узнать, как со всем этим справиться на практике добро пожаловать под кат.

В сегодняшнем выпуске 2 видео от наших менеджеров проектов. Всего 30 минут за чашечкой горячего чая или кофе, и вы в курсе в рабочих методик. А не это ли самое главное?



Как управлять рисками проектов и не скатываться при этом в формализм


Иван Зверев, менеджер проектов
Есть определенная точка, с которой нужно начинать управлять рисками. И ни в одном PMBОK-е о таком не пишут. Когда управлять рисками? Как привлечь команду? Какой алгоритм? Какая практическая польза? Ваня расскажет, как разобрался в этом сам.

1:18 О чем будет доклад? Границы
3:15 Моделируем ситуацию про пиэма Петра
5:31 Какие вопросы нужно задать себе?
7:30 Формат управления рисками
8:34 Когда нужно управлять рисками?
11:47 Кого привлечь?
13:37 Как преодолеть сопротивление и убедить команду участвовать?
15:50 Как подготовиться к сессии по управлению рисками?
19:05 Алгоритм проведения сессии
26:45 Типовые ошибки
28:05 Выводы коротко о главном






Автоскоринг бэклога


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

0:47 О продукте и команде
2:41 Споры в команде что разрабатывать дальше?
5:54 Система приоритетов. Критерии модели
7:10 Reach
8:30 Confidence
10:53 Impact to tech
12:52 Impact to money
14:35 Impact to user
17:32 Effort
18:12 Модель скоринга
18:37 Пример сравнения двух багов
19:48 Как устроен процесс автоскоринга бэклога
23:25 Как привить такую модель команде?
27:04 Какие профиты можно получить от модели?





Все доклады с большой ИТ-конференции ЮMoneyDay. На подходе материалы про PM, тестирование и мобильную разработку.

Подробнее..

Recovery mode Техника определения MVP

02.07.2020 12:23:15 | Автор: admin

Привет!


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


Для всех кто готов мирится с сыроватостью идеи, добро пожаловать под кат)


Введение


Задача определения функциональности MVP появляется еще на этапе планирования разработки продукта и требует обновленного решения по мере развития продукта, вплоть до окончания разработки MVP.


Сама концепция MVP предполагает как можно более быструю доставку продукта конечным пользователям для получения от них обратной связи, однако собственники продуктов (Product Owner) зачастую превышают минимальную функциональность стремясь сделать продукт лучше, что влечет за собой срывы сроков, превышение бюджетов, а в худших случаях и вовсе развитие продукта в неправильном направлении.


Для нивелирования вышеупомянутых рисков предлагается использовать конкретный подход, основанный на математических принципах, для регламентирования процесса определения функциональности MVP.


Критерии


Критериями для задачи определения MVP функциональности являются критерии, взятые из методологии WSJF а также дополнительная декомпозиция Job Duration на составляющие:


Cost of delay


  • User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
  • Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
  • Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
  • Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Job Duration


  • Job Duration Оценка времени на реализацию, производится по предварительному анализу Features с участием Тех Лидера команды разработки или Архитектора. Выполняется верхнеуровнево, без декомпозиции Features на более низкие уровни
  • Job Complexity- Оценка сложности реализации, выполняется совместно с Тим Лидером команды разработки индивидуально, с учетом опыта и навыков команды, которая работает над данным продуктом. Данная оценка также включает в себя оценку степени неопределенности Features, которая в свою очередь прямо пропорционально влияет на сложность этих самых Features.
  • Job Cost Оценка стоимости реализации, высчитывается исходя из необходимых человеко-часов на определенную задачу, и перемножения его на стоимость человеко-часа в команде. Данная оценка является относительной и не подлежит для использования в расчетах стоимости реализации продукта, и нужна только для приоритизации бэклога.

Процесс оценки


Оценка выполняется с помощью числового ряда Фиббоначи от 1 до 21. (1, 3, 5, 8, 13, 21). Данный способ оценки универсален с точки зрения использования его при оценке задач в Story Points при планировании, и для групповой оценки критериев также возможно использования Scrum-poker.


Также, оценка с помощью ряда Фиббоначи обусловлена тем, что каждый шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 и 21 Story Points.
Оценки по критериям из группы Jobs Duration выполняются командой разработки, а оценки по группе критериев Cost Of Delay только с привлечение бизнес-заказчика и Владельца Продукта.


Итогом оценки будет матрица следующего вида:




Сведение задачи определения MVP к решению задачи многокритериальной оптимизации.


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


Для свертывания критериев в суперкритерий необходимо также проставить весовые коэффициенты:



Для бизнес критериев и критериев разработки необходимо устанавливать отдельные весовые коэффициенты.


Таким образом свертывание критериев будет выглядеть следующим образом:


Cost Of Delay = User-Business Valuek11+ Time Criticalityk12+ Risk Reductionk13+ Opportunity Enablementk14
Jobs Duration = Job Durationk21+ Job Complexityk22+ Job Cost*k23
K11+K12+K13+K14=1
K21+K22+K23=1
Общий критерий оптимизации (Mutual Criteria) = Cost of Delay/Jobs Duration.


Таким образом мы получаем матрицу следующего вида:



Итоговой целевой функцией является Максимизация по Mutual Criteria.


Определение MVP Функциональности с помощью ABC анализа.


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


ABC-анализ анализ бэклога (набора Features) путём деления на три категории:


А наиболее ценные, 20% от количества; 80% удовлетворения потребностей
В промежуточные, 30% от количества; 15% удовлетворения потребностей
С наименее ценные, 50% от количества; 5% удовлетворения потребностей


Группа А является группой функциональности входящей в MVP.


По сути, ABC-анализ это ранжирование бэклога по разным параметрам. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.


АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой. Таким образом, 20% функциональности, закрывают 80% потребностей. Исходя из данного принципа, производим АВС анализ для бэклога, для определения MVP.


Для этого:


  1. Определяем цель анализа Ранжирование Бэклога для определения первых 20% функциональности, из которой будет сформирован MVP.
  2. Объект анализа Набор Features из бэклога.
  3. Берем перечень функциональности, ранжированный по многокритериальной модели (MC).
  4. Разделяем ранжир на 2 класса первые 20% (A), оставшиеся 80% (B+C).
  5. Первый класс (A) определяет MVP.

Важное замечание: Необходимо также учитывать CORE функциональность. Группа А может совпадать c CORE, но в случае не совпадения, результаты АВС анализа должны быть дополнены Core функциональностью.


CORE функциональность это основа функционирования продукта, которая состоит из функциональности, без которой функционирование продукта невозможно. (Например, авторизации).


Выводы


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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru