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

Привет!

Ниже по тексту предлагаю ознакомится с подходом, который я применяю для определения функциональности, которая должна войти в 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.