Lviv Project&Product Management Day 2019 Stream: Product

1. RoadMap
Выбор приоритетов
April 2019
Dov Nimratz
Solution Architect in GlobalLogic

2. 30+ years in R&D
17 years in Israel HighTech
ECI, Telrad, RAD, Audiocodes companies
HW, SW, Mechanical design engineer
Project & Product Manager
Business developer for EMEA & CIS countries
Solution Architect
22 publications, US patent
Counseling & SW development teaching
Обо мне:

3. Как глубока кроличья нора?
● 20 методик приоритезации
● Классификация методик по признакам
● Сведение их в таблицу

4. Внутренние
Внешние
КачественныеКоличественные

5. Внешние и количественные методы

6. Kano model
Удовлетворенность клиента продуктом/сервисом по
категориям (обычно в результате опроса).
Функциональность
Удовлетворенность
Привлекательно
Обязано быть
Безразлично
По каждой функции вопросник с да/нет
Или баллами 1-5:
● Хотелось бы
● Должно быть
● Безразлично
● Пережеву и без
● Не нравиться
https://foldingburritos.com/kano-model/

7. Quality Function Deployment
QFD помогает определить особенности
продукта, рассматривая с разных сторон и от
разных лиц ( в частности, заказчик и
компания)
Дом качества
1 2
3
4
5
6
7
What
(Epic)
Importance T1 T2 T3 T4 T5
Story 1 70 3 1 9
Story 2 34 1 3 1
Story n 15 3 1 3
Row Score 255 34 85 102 709
Prioritizat. rank 2 5 4 3 1
9 - сильно
3 - средне
1 - слабо
https://measuringu.com/qfd-ui/

8. Opportunity Sorting - Клиент не эксперт, но заказчик
Составив список фич мы можем просить клиента
оценить важность и удовлетворяемость по шкале 1-10.
Сортируем фичи по формуле Востребованность
Востребованность =
Важность - max([Важность - Удовлетворяемость], 0)

9. Opportunity Sorting - Analysis
10
9
8
7
6
5
4
3
2
1
1 2 3 4 5 6 7 8 9 10
Важность
Удовлетворенность
Переобслужено
Недообслуженно
Адекватный уровень
Обслуживания
https://www.designative.info/project/product-definition-and-requirements-prioritization/

10. Buy a Feature - Вид Деловой Игры
1. Набор функций, которые должны быть расставлены по приоритетам,
представлен группе покупателей (наших клиентов);
2. Каждый покупатель получает бюджет игровых денег, чтобы потратить на
функции;
3. Каждая функция оценивается по стоимости (сложность, фактическая
стоимость, время, риски)
4. Бюджет каждого игрока должен составлять от трети до половины общей
стоимости всех функций;
5. Играть в игру можно одним из двух способов:
a. Индивидуально - игрокам говорят использовать свой бюджет для покупки наиболее важных для
них функций;
b. Совместно - использование шкалы цен, которая делает некоторые функции слишком дорогими
для отдельных покупатели для покупки. Это заставляет сотрудничество и переговоры между
игроками, чтобы купить функции которые ценятся несколькими игроками.
https://www.innovationgames.com/buy-a-feature/

11. Внешние и Качественные методы

12. Story Mapping
Заменяет одномерный массив BackLog на карту для лучшей приоритезации:
● Горизонтальная ось - последовательность использования:
○ Пользовательские истории (или «задачи») размещаются вдоль этой оси в той
последовательности, в которой они выполняется пользователем
● Вертикальная ось - Приоритет тасков:
○ Допускается (хотя и не желательно) одноуровневые приоритеты
● Связанные истории группируются в Активности:
○ Вертикальные линии отделяют активности - (Средства оплаты)
○ Активности не имеют приоритета - они необходимые компоненты всей системы

13. Story Mapping
Время
Важность
Активности
Истории или
большие
таски
Таски
https://www.jpattonassociates.com/the-new-backlog/
Выгоды:
Заказчики и
разработчики имеют
общее понимание того,
что делает система;
Выявление зависимых
тасков в релизе

14. Story Mapping
Время
Важность
Release 1
Release 2
Release 3
Выгоды:
Заказчики и
разработчики имеют
общее понимание того,
что делает система;
Выявление зависимых
тасков в релизе

15. MoSCoW
● Must have - должно быть включено в продукт иначе провалом. Может
быть понижен, если есть соглашение между Stakeholders.
● Should have- важные задачи, но не важны для релиза. Это первый
уровень «приятно иметь»
● Could have - эти задачи желательны, но необязательны для выпуска.
● Won’t have - наименее критичные задачи
Проблема - борьба интересов между разными Stakeholders.
Хорошо работает в жесткой диктатуре с сильным Оркестратором.
https://en.wikipedia.org/wiki/MoSCoW_method

16. Prune the Product Tree - деловая игра
Продукт - это дерево, которое будет подрезано по нашему вкусу.
● Нарисуйте большое дерево
● Ветви представляют основные области продукта, а листья - доступные в
настоящее время функции;
● Напишите потенциальные новые функции на стикерах;
● Попросите клиентов и заинтересованные стороны разместить желаемые
функции на дереве, определив его следующее фаза роста.
Ответьте на вопросы:
https://www.innovationgames.com/prune-the-product-tree/
● Дерево растет сбалансированным образом?
● Есть области растущие непропорционально больше / или отстают?
● Растут ли ранее слаборазвитые районы сейчас?

17. Speed Boat - деловая игра
Определение наименее понравившихся функций в товаре.
Если говорить о недостатках создается отрицательный настрой беседы.
Задача заменить его на “пусть это все уйдет” фокусом на идеальный продукт
https://www.innovationgames.com/speed-boat/
● Нарисуйте лодку на доске
● Это скоростной катер, и он должен идти очень быстро;
● К сожалению, это сдерживается некоторыми якорями;
● Лодка - это продукт, а якоря - это особенности, которые клиенты
расстраивают;
● Попросите клиентов написать на стикерах, какие функции им не нравятся, и
насколько быстро, по их оценкам, лодка может двигаться без этих якорей;
● Каждый якорь и оценка скорости дают вам показатель «боли», который вы
можете позже расставить по приоритетам для улучшения.

18. Внутренние и количественные методы

19. Financial analysis
Экономическое обоснование для новых функций продукта / разработки
Существует 4 вида финансовых целей, которые мы можем ожидать в
результате развития продукта:
● New Revenue: новый доход, который, по прогнозам, будет получен;
● Incremental Revenue: дополнительный доход от существующих
клиентов, теперь он может взимать плату за обновление или
дополнительные услуги; (Cross Sale)
● Retained Revenue: доход, который не был потерян из-за уменьшения
оттока клиентов;
● Cost Savings: любой тип операционной эффективности, достигнутый
внутри компании.
https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

20. Financial analysis
Проблема в том, что доллар сегодня стоит больше доллара завтра.
Инициатива, которая возвращается $ 10K, $ 20K, $ 30K за три квартала менее
ценны, чем те, у которых те же доходы в обратном порядке.
Необходимы более сложные методы сравнения.
Необходимо рассмотрим 3 метрики, отвечающие на вопросы:
● Сколько сегодняшних денег у нас будет через X, если мы инвестируем в
этот проект?
● Какова отдача от этого проекта в процентах?
● Сколько времени потребуется, чтобы вернуть эти инвестиции?
https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

21. Financial analysis - Net Present Value (NPV)
Сколько денег нужно будет положить в банк, чтобы к концу 1 года у нас было
10 долларов? Это что называется текущей стоимостью и зависит от
процентной ставки банка:
Для 5% процентной ставки нам нужно было бы положить 9,52 доллара в банк
сегодня, чтобы иметь 10 долларов через год.
При оценке альтернативных проектов для инвестиции, учитывают стоимость
возможностей вместо процентной ставки банка.
Это представляет то, что недополучено, как следствие вложений во что-то
другое. Если компания обычно получает 15% прибыли от ее проектов, то это
издержки, с которыми следует сравнивать альтернативный проект.

22. Financial analysis - Net Present Value (NPV)
Создание нового продукта создаст последовательность денежных потоков за
периоды времени (например, месяцы или кварталы).
Каждый из них должен быть дисконтирован до их текущей стоимости (PV)
Этот метод позволяет компании расставить
приоритеты между проектами, предоставив
ответ на этот вопрос:
«Сколько из сегодняшних денег у нас будет в
X раз, если мы инвестируем в проект А или
проект? B?»

23. Financial analysis - Internal Rate of Return (IRR)
Доходность проекта в процентах. Другими словами, это показывает, как
быстро инвестиции будут увеличиваться в стоимости.
IRR определяется как процентная ставка, при которой NPV равна нулю.
Из этого значения вы получаете доход от
проекта и можете сравнить его с другими.
Тем не менее, это не должно быть взятые
в отдельности для принятия решений,
поскольку общая NPV или время
инвестирования, которое требуется, могут
быть важными факторами принятия
решения.

24. Financial analysis - Discounted Payback Period
Сколько времени потребуется, чтобы вернуть инвестиции.
Это число не говорит нам, сколько
заработаем. Полезно для
измерения уровень риска,
связанного с проектом.
Чем дольше возвращаются деньги,
тем рискованнее.
В зависимости от финансовых
условий компании и толерантности
к риску, это может быть решающим
фактором.

25. Ian McAllister’s Framework
1. Определите важные темы для продукта или бизнеса. Выберете 3
2. Расставьте абсолютные и относительные приоритеты. Какие ресурсы?
3. Создайте абстракцию идеи основываясь на прежних идеях. Помните про
принцип Pareto - 20% продукта дает 80% прибыли.
4. Оцените потенциальное влияние каждого проекта на результат.
(Количество кликов до покупки)
5. Оцените стоимость каждого продукта
6. Выберите - Больше, Быстрее, Дешевле
https://www.quora.com/What-are-the-best-ways-to-prioritize-a-list-of-product-features/answer/Ian-
McAllister

26. Impact on Business Goal - Что вы улучшаете?
5 этапов жизненного цикла работы клиента:
Пользователи заходят на сайт / товар;
Пользователям нравится 1-й визит, регистрация;
Пользователи возвращаются несколько раз;
Активность пользователей приводит к популярности
продукта;
Пользователям нравиться продукт настолько, чтобы
рекомендовать его другим.
https://en.wikipedia.org/wiki/Validated_learning
Цель - увеличить число клиентов переходящих с следующему этапу.
Acquisition
Activation
Retention
Revenue
Referral

27. Value vs. Risk - Метод Сравнения
Виды рисков:
● Schedule risk (например, «это может быть сделано не тогда, когда нам это нужно»)
● Cost risk (например, «реализация дороже, чем позволяет экономическое обоснование»)
● Functionality risk (например, «мы не можем сделать это, как требуется»)

28. Value vs. Cost / Quality / Complexity
Цель - максимизировать выход продукта во времени.
https://www.productplan.com/glossary/value-vs-complexity/
“If you use time-to-build to prioritize what to build next,
you’ll end up with a product full of easy solutions.”

29. Scorecard
1. Начните с четкой стратегии, которая была проверена пользователями;
2. Выберите функции, которые больше всего связаны с общей стратегией
для следующего релиза;
3. Определить критерии и веса для оценки;
4. Встретьтесь с заинтересованными сторонами и отрегулируйте критерии
и веса;
5. Просмотрите все возможности / альтернативы и присвойте баллы
(например, от 1 до 100) по влиянию на каждый критерий.
https://danielelizalde.com/product_management_scorecard/

30. Theme Screening
1. Определить критерии, по которым следует оценивать задачу;
2. Для каждого критерия выберите «базовый» элемент. Хорошая базовая
задача, которую можно (но не гарантированно) выбрать для следующего
выпуска;
3. Для каждой функции / задачи оцените ее по сравнению с базовой линией:
«+», если она оказывает более сильное воздействие, чем базовая линия, «0»,
если она нейтральная, и «-», если она оказывает меньшее воздействие;
4. Для каждого признака / задачи и критерия оценки рассчитайте его чистый вес
и оцените характеристики по этому значению.
https://www.mountaingoatsoftware.com/tools/theme-screening#

31. Внутренние и Качественные методы

32. Classification Ranking
Одним из самых простых способов. Полезен для маленьких и внутренних
проектов.
Каждая фича классифицируется в какую-то категорию, а затем производится
ранжирование.
Категории должны быть сортируемыми каким-либо образом, например 1-2-3-
4-5, High-Medium-Low.
Похож на MoSCoW, но основан на личных оценках

33. Systemico Model
Эта модель связана с Story Mapping, поскольку она также создает
двумерную сетку, которая позволяет легко визуализировать сферу действия
продукта и различные уровни приоритета.
Стремится обеспечить рамки для приоритезации с точки зрения ценности
для клиента и рассматривать этот процесс как нечто целостное.
https://barryoreilly.com/the-systemico-model/

34. Systemico Model
User Engagement - взаимодействие с пользователем. Есть 4 степени (в порядке
убывания):
○ Основные: функции для удовлетворения основных потребностей пользователей. Это базовые
ожидания для пользователей в этом продукте;
○ Использование: новые и улучшенные функции для повышения удобства использования
продукта. Без них продукт имеет минимальную привлекательность для пользователя;
○ Вовлечение: функциональность, привлекающая пользователя, чтобы больше
взаимодействовать с продуктом и желанием вернуться в будущем;
○ Исследуйте: функции, которые создают более прочную связь между пользователем и
продуктом, способствуют выходу за рамки простых взаимодействий.
https://barryoreilly.com/the-systemico-model/
User Goals - Продукт определяется не с точки
зрения того, что он делает, но с точки зрения
почему некоторые функции необходимы.

35. Systemico Model
https://barryoreilly.com/the-systemico-model/
Затем пользовательские истории
помещаются в соответствующие
уровни Цели / Связи.

36. Systemico Model
https://barryoreilly.com/the-systemico-model/
Как и в Story Mapping, можно
создать план релизов, который дает
большее понимание для клиента,
для того чтобы собрать отзывы,
прежде чем вкладывать
значительные средства в данный
набор функций.
https://www.intercom.com/blog/prioriti
sing-features-wholl-use-it-how-often/

37. Stacked Ranking
Типичный Backlog - одномерный список тасков.
Однако в большинстве случаев это приоритезирование основанное на
собственном «экспертном» мнении Product Owner. В других случаях этот
список основан на разговорах и беседах со Stakeholders.

38. Feature Buckets
Техника Адам Неша. Он считает, что приоритизация функций сильно
варьируется в зависимости от типа продукта и отрасли, и вот почему он
подчеркивает, что этот метод был разработан специально для
потребительских интернет-продуктов.
Задачи разработки должны быть сортированы в 4 сегмента.
Хорошо сбалансированный выпуск продукта, как правило, должен включать
функции всех этих групп.
https://adamnash.blog/2009/07/22/guide-to-product-planning-three-feature-buckets/

39. Feature Buckets - 4 сегмента
● Metrics Movers - Функции, которые будут перемещать целевые показатели
бизнеса и продукта значительно. Должны быть конкретные цели и стратегии,
стоящие за решением инвестировать. AARRR - Startup Metrics for Pirates
● Customer Requests - функции, которые были запрошены непосредственно
клиентами. Oни обычно являются постепенными улучшениями, но важно
учитывать их, иначе существует риск оттолкнуть пользователя
● Delight - инновационные функции, на основе идеи дизайна или технология.
Работа над новыми функциями важна, чтобы радовать клиентов и создать
дифференцированную позицию на рынке (модель Kano);
● Strategic - функции, которые включены по стратегическим причинам,
связанным с обучением или будущими целями (например, PoC и сбор
данных.)
https://adamnash.blog/2009/07/22/guide-to-product-planning-three-feature-buckets/

40. KJ Method
Быстро дает «объективный групповой консенсус из набора субъективных,
мнений».
Инструменты:
● Стикеры 2х цветов
● Большая комната
● Фасилитатор
● Доска для записей
https://articles.uie.com/kj_technique/

41. KJ Method
1. Определить центральный вопрос. Центральный вопрос определяет результаты. У каждой
сессии будет свой основной вопрос (например, «Кто наши пользователи?», «Какие цели
преследуют пользователи, когда они заходят на наш сайт?»)
2. Организовать группу. Люди в группе должны быть из разных частей организации, чтобы
охватить более полные стороны вопроса.
3. Записать мнения на стикеры. Помещая один элемент на один стикер в каждой группе.
Каждая группа проводит мозговой штурм как можно большего количества предметов.
4. Стикеры размещаются на доске. Участники видят сикеры всех групп. Можно дописывать.
5. Однотипные стикеры группируются.
6. Используя стикеры другого цвета группы именуются.
7. Голосование за наиболее важные группы. Участникам предлагается индивидуально оценить,
какие группы он/она считает наиболее важными для ответа на основной вопрос.
8. Ранжирование наиболее важных групп. Это последний и самый важный шаг. Все
индивидуальные стикеры размещаются на доске в порядке количества голосов. Участники
могут объединить аналогичные группы, тогда голоса складывают и продвигают их вверх по
рейтингу. Если 3-4 группы иметь гораздо более высокий рейтинг, чем остальные, ведущий
прекращает упражнение.
https://articles.uie.com/kj_technique/

42. Внутренние
Внешние
КачественныеКоличественные

43. Качественные
Количественные
Внутренние Внешние

44. Выводы
1. Все техники приоритезации работают на высоком уровне абстракции:
a. Цель - удовлетворить пользователя, а не решить что сначала и что потом
b. Сократить время потерь, если/когда стратегия меняется
c. Приоритеты в стратегией, а команда ищет путь реализации
2. Установить цели, установить критерии оценки - Цель не состоит в том, чтобы
установить приоритеты и отправить их. Цель состоит в том, чтобы постоянно быть в курсе,
действительно ли то, что мы делаем, добавляет ценности и работает так, как ожидалось;
когда это не так, у нас будет по крайней мере некоторые подсказки относительно того, что
нуждается в корректировке.
3. Не делайте это в одиночку. - Расстановка приоритетов не должна быть сольной. За
исключением очень простых методов, почти все они вовлекают кого-то еще в процесс. Будь
то клиенты, заинтересованные стороны или члены команды, это очень редко, когда менеджер
по продукту сам устанавливает общие приоритеты. Мы просто отвечаем за процесс,а продукт
принадлежит команде

45. Выводы
4. Quantitative vs. Qualitative. Количественный не значит лучше качественного (и
наоборот). Например, распространенной ошибкой при использовании количественных
методов определения приоритетов является то, что люди связывают числа с точностью и
уверенностью. Просмотр формул, соотношений и рейтингов, как правило, позволяет нам
чувствовать себя более уверенными в надежности и объективности анализа определенного
типа, но они могут быть подвергнуты сомнению. Вы должны помнить об этом как для себя,
так и при представлении результатов другим людям - это руководящие принципы, а не
безошибочные результаты.
5. External vs. Internal. Шкала показывала как много внешних факторов в принятии
решения. Решение должно базироваться примерно так
Вы <- Команда <- Заинтересованные стороны <- Клиенты.

46. Выводы
6. Значение внешних методик. В общих чертах, внешние методы наиболее полезны,
когда вы пытаетесь перемещаться по большому набору возможностей-кандидатов, обращая
внимание на:
a. Определите наиболее ценные для ваших клиентов - знание их базовых и ожидаемых
результатов, а также того, что их радует;
b. Получение поддержки и консенсуса от группы Stakeholders
c. Определение того, какие функции не приносят пользы или что вызывает активное
недовольство клиентов, так что вы можете решить, стоит ли их улучшать или
отбрасывать;
d. Привлечение клиентов к консалтинговым проектам для участия в формировании
RoadMap

47. Выводы
7. Значение внутренних методик. Привлекая внутреннюю команду, которая ближе к
продукту и технологии, используем методы для определения проблем более низкого уровня.
Те, которые менее изучены, так как конечные пользователи менее вовлечены (если вообще).
Таким образом, они работают лучше всего, когда вам нужно:
a. Дальнейшее уточнение результатов, полученных с помощью одной из более
ориентированных на внешность технологий;
b. Определить приоритетность готового набора функций и идей, которые, как вы уверены,
соответствуют стратегии продукта и ожиданиям клиентов;
c. Работа над внутренними проектами без особого контакта с рынком (Например
внутренняя оптимизация);
d. Быстрая расстановка приоритетов низкоуровневых функций и требований. (Баг
фиксинг)

48. Методики приоритезации
Или как глубока кроличья нора