SlideShare a Scribd company logo
RoadMap
Выбор приоритетов
April 2019
Dov Nimratz
Solution Architect in GlobalLogic
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
Обо мне:
Как глубока кроличья нора?
● 20 методик приоритезации
● Классификация методик по признакам
● Сведение их в таблицу
Внутренние
Внешние
КачественныеКоличественные
Внешние и количественные методы
Kano model
Удовлетворенность клиента продуктом/сервисом по
категориям (обычно в результате опроса).
Функциональность
Удовлетворенность
Привлекательно
Обязано быть
Безразлично
По каждой функции вопросник с да/нет
Или баллами 1-5:
● Хотелось бы
● Должно быть
● Безразлично
● Пережеву и без
● Не нравиться
https://foldingburritos.com/kano-model/
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/
Opportunity Sorting - Клиент не эксперт, но заказчик
Составив список фич мы можем просить клиента
оценить важность и удовлетворяемость по шкале 1-10.
Сортируем фичи по формуле Востребованность
Востребованность =
Важность - max([Важность - Удовлетворяемость], 0)
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/
Buy a Feature - Вид Деловой Игры
1. Набор функций, которые должны быть расставлены по приоритетам,
представлен группе покупателей (наших клиентов);
2. Каждый покупатель получает бюджет игровых денег, чтобы потратить на
функции;
3. Каждая функция оценивается по стоимости (сложность, фактическая
стоимость, время, риски)
4. Бюджет каждого игрока должен составлять от трети до половины общей
стоимости всех функций;
5. Играть в игру можно одним из двух способов:
a. Индивидуально - игрокам говорят использовать свой бюджет для покупки наиболее важных для
них функций;
b. Совместно - использование шкалы цен, которая делает некоторые функции слишком дорогими
для отдельных покупатели для покупки. Это заставляет сотрудничество и переговоры между
игроками, чтобы купить функции которые ценятся несколькими игроками.
https://www.innovationgames.com/buy-a-feature/
Внешние и Качественные методы
Story Mapping
Заменяет одномерный массив BackLog на карту для лучшей приоритезации:
● Горизонтальная ось - последовательность использования:
○ Пользовательские истории (или «задачи») размещаются вдоль этой оси в той
последовательности, в которой они выполняется пользователем
● Вертикальная ось - Приоритет тасков:
○ Допускается (хотя и не желательно) одноуровневые приоритеты
● Связанные истории группируются в Активности:
○ Вертикальные линии отделяют активности - (Средства оплаты)
○ Активности не имеют приоритета - они необходимые компоненты всей системы
Story Mapping
Время
Важность
Активности
Истории или
большие
таски
Таски
https://www.jpattonassociates.com/the-new-backlog/
Выгоды:
Заказчики и
разработчики имеют
общее понимание того,
что делает система;
Выявление зависимых
тасков в релизе
Story Mapping
Время
Важность
Release 1
Release 2
Release 3
Выгоды:
Заказчики и
разработчики имеют
общее понимание того,
что делает система;
Выявление зависимых
тасков в релизе
MoSCoW
● Must have - должно быть включено в продукт иначе провалом. Может
быть понижен, если есть соглашение между Stakeholders.
● Should have- важные задачи, но не важны для релиза. Это первый
уровень «приятно иметь»
● Could have - эти задачи желательны, но необязательны для выпуска.
● Won’t have - наименее критичные задачи
Проблема - борьба интересов между разными Stakeholders.
Хорошо работает в жесткой диктатуре с сильным Оркестратором.
https://en.wikipedia.org/wiki/MoSCoW_method
Prune the Product Tree - деловая игра
Продукт - это дерево, которое будет подрезано по нашему вкусу.
● Нарисуйте большое дерево
● Ветви представляют основные области продукта, а листья - доступные в
настоящее время функции;
● Напишите потенциальные новые функции на стикерах;
● Попросите клиентов и заинтересованные стороны разместить желаемые
функции на дереве, определив его следующее фаза роста.
Ответьте на вопросы:
https://www.innovationgames.com/prune-the-product-tree/
● Дерево растет сбалансированным образом?
● Есть области растущие непропорционально больше / или отстают?
● Растут ли ранее слаборазвитые районы сейчас?
Speed Boat - деловая игра
Определение наименее понравившихся функций в товаре.
Если говорить о недостатках создается отрицательный настрой беседы.
Задача заменить его на “пусть это все уйдет” фокусом на идеальный продукт
https://www.innovationgames.com/speed-boat/
● Нарисуйте лодку на доске
● Это скоростной катер, и он должен идти очень быстро;
● К сожалению, это сдерживается некоторыми якорями;
● Лодка - это продукт, а якоря - это особенности, которые клиенты
расстраивают;
● Попросите клиентов написать на стикерах, какие функции им не нравятся, и
насколько быстро, по их оценкам, лодка может двигаться без этих якорей;
● Каждый якорь и оценка скорости дают вам показатель «боли», который вы
можете позже расставить по приоритетам для улучшения.
Внутренние и количественные методы
Financial analysis
Экономическое обоснование для новых функций продукта / разработки
Существует 4 вида финансовых целей, которые мы можем ожидать в
результате развития продукта:
● New Revenue: новый доход, который, по прогнозам, будет получен;
● Incremental Revenue: дополнительный доход от существующих
клиентов, теперь он может взимать плату за обновление или
дополнительные услуги; (Cross Sale)
● Retained Revenue: доход, который не был потерян из-за уменьшения
оттока клиентов;
● Cost Savings: любой тип операционной эффективности, достигнутый
внутри компании.
https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
Financial analysis
Проблема в том, что доллар сегодня стоит больше доллара завтра.
Инициатива, которая возвращается $ 10K, $ 20K, $ 30K за три квартала менее
ценны, чем те, у которых те же доходы в обратном порядке.
Необходимы более сложные методы сравнения.
Необходимо рассмотрим 3 метрики, отвечающие на вопросы:
● Сколько сегодняшних денег у нас будет через X, если мы инвестируем в
этот проект?
● Какова отдача от этого проекта в процентах?
● Сколько времени потребуется, чтобы вернуть эти инвестиции?
https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
Financial analysis - Net Present Value (NPV)
Сколько денег нужно будет положить в банк, чтобы к концу 1 года у нас было
10 долларов? Это что называется текущей стоимостью и зависит от
процентной ставки банка:
Для 5% процентной ставки нам нужно было бы положить 9,52 доллара в банк
сегодня, чтобы иметь 10 долларов через год.
При оценке альтернативных проектов для инвестиции, учитывают стоимость
возможностей вместо процентной ставки банка.
Это представляет то, что недополучено, как следствие вложений во что-то
другое. Если компания обычно получает 15% прибыли от ее проектов, то это
издержки, с которыми следует сравнивать альтернативный проект.
Financial analysis - Net Present Value (NPV)
Создание нового продукта создаст последовательность денежных потоков за
периоды времени (например, месяцы или кварталы).
Каждый из них должен быть дисконтирован до их текущей стоимости (PV)
Этот метод позволяет компании расставить
приоритеты между проектами, предоставив
ответ на этот вопрос:
«Сколько из сегодняшних денег у нас будет в
X раз, если мы инвестируем в проект А или
проект? B?»
Financial analysis - Internal Rate of Return (IRR)
Доходность проекта в процентах. Другими словами, это показывает, как
быстро инвестиции будут увеличиваться в стоимости.
IRR определяется как процентная ставка, при которой NPV равна нулю.
Из этого значения вы получаете доход от
проекта и можете сравнить его с другими.
Тем не менее, это не должно быть взятые
в отдельности для принятия решений,
поскольку общая NPV или время
инвестирования, которое требуется, могут
быть важными факторами принятия
решения.
Financial analysis - Discounted Payback Period
Сколько времени потребуется, чтобы вернуть инвестиции.
Это число не говорит нам, сколько
заработаем. Полезно для
измерения уровень риска,
связанного с проектом.
Чем дольше возвращаются деньги,
тем рискованнее.
В зависимости от финансовых
условий компании и толерантности
к риску, это может быть решающим
фактором.
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
Impact on Business Goal - Что вы улучшаете?
5 этапов жизненного цикла работы клиента:
Пользователи заходят на сайт / товар;
Пользователям нравится 1-й визит, регистрация;
Пользователи возвращаются несколько раз;
Активность пользователей приводит к популярности
продукта;
Пользователям нравиться продукт настолько, чтобы
рекомендовать его другим.
https://en.wikipedia.org/wiki/Validated_learning
Цель - увеличить число клиентов переходящих с следующему этапу.
Acquisition
Activation
Retention
Revenue
Referral
Value vs. Risk - Метод Сравнения
Виды рисков:
● Schedule risk (например, «это может быть сделано не тогда, когда нам это нужно»)
● Cost risk (например, «реализация дороже, чем позволяет экономическое обоснование»)
● Functionality risk (например, «мы не можем сделать это, как требуется»)
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.”
Scorecard
1. Начните с четкой стратегии, которая была проверена пользователями;
2. Выберите функции, которые больше всего связаны с общей стратегией
для следующего релиза;
3. Определить критерии и веса для оценки;
4. Встретьтесь с заинтересованными сторонами и отрегулируйте критерии
и веса;
5. Просмотрите все возможности / альтернативы и присвойте баллы
(например, от 1 до 100) по влиянию на каждый критерий.
https://danielelizalde.com/product_management_scorecard/
Theme Screening
1. Определить критерии, по которым следует оценивать задачу;
2. Для каждого критерия выберите «базовый» элемент. Хорошая базовая
задача, которую можно (но не гарантированно) выбрать для следующего
выпуска;
3. Для каждой функции / задачи оцените ее по сравнению с базовой линией:
«+», если она оказывает более сильное воздействие, чем базовая линия, «0»,
если она нейтральная, и «-», если она оказывает меньшее воздействие;
4. Для каждого признака / задачи и критерия оценки рассчитайте его чистый вес
и оцените характеристики по этому значению.
https://www.mountaingoatsoftware.com/tools/theme-screening#
Внутренние и Качественные методы
Classification Ranking
Одним из самых простых способов. Полезен для маленьких и внутренних
проектов.
Каждая фича классифицируется в какую-то категорию, а затем производится
ранжирование.
Категории должны быть сортируемыми каким-либо образом, например 1-2-3-
4-5, High-Medium-Low.
Похож на MoSCoW, но основан на личных оценках
Systemico Model
Эта модель связана с Story Mapping, поскольку она также создает
двумерную сетку, которая позволяет легко визуализировать сферу действия
продукта и различные уровни приоритета.
Стремится обеспечить рамки для приоритезации с точки зрения ценности
для клиента и рассматривать этот процесс как нечто целостное.
https://barryoreilly.com/the-systemico-model/
Systemico Model
User Engagement - взаимодействие с пользователем. Есть 4 степени (в порядке
убывания):
○ Основные: функции для удовлетворения основных потребностей пользователей. Это базовые
ожидания для пользователей в этом продукте;
○ Использование: новые и улучшенные функции для повышения удобства использования
продукта. Без них продукт имеет минимальную привлекательность для пользователя;
○ Вовлечение: функциональность, привлекающая пользователя, чтобы больше
взаимодействовать с продуктом и желанием вернуться в будущем;
○ Исследуйте: функции, которые создают более прочную связь между пользователем и
продуктом, способствуют выходу за рамки простых взаимодействий.
https://barryoreilly.com/the-systemico-model/
User Goals - Продукт определяется не с точки
зрения того, что он делает, но с точки зрения
почему некоторые функции необходимы.
Systemico Model
https://barryoreilly.com/the-systemico-model/
Затем пользовательские истории
помещаются в соответствующие
уровни Цели / Связи.
Systemico Model
https://barryoreilly.com/the-systemico-model/
Как и в Story Mapping, можно
создать план релизов, который дает
большее понимание для клиента,
для того чтобы собрать отзывы,
прежде чем вкладывать
значительные средства в данный
набор функций.
https://www.intercom.com/blog/prioriti
sing-features-wholl-use-it-how-often/
Stacked Ranking
Типичный Backlog - одномерный список тасков.
Однако в большинстве случаев это приоритезирование основанное на
собственном «экспертном» мнении Product Owner. В других случаях этот
список основан на разговорах и беседах со Stakeholders.
Feature Buckets
Техника Адам Неша. Он считает, что приоритизация функций сильно
варьируется в зависимости от типа продукта и отрасли, и вот почему он
подчеркивает, что этот метод был разработан специально для
потребительских интернет-продуктов.
Задачи разработки должны быть сортированы в 4 сегмента.
Хорошо сбалансированный выпуск продукта, как правило, должен включать
функции всех этих групп.
https://adamnash.blog/2009/07/22/guide-to-product-planning-three-feature-buckets/
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/
KJ Method
Быстро дает «объективный групповой консенсус из набора субъективных,
мнений».
Инструменты:
● Стикеры 2х цветов
● Большая комната
● Фасилитатор
● Доска для записей
https://articles.uie.com/kj_technique/
KJ Method
1. Определить центральный вопрос. Центральный вопрос определяет результаты. У каждой
сессии будет свой основной вопрос (например, «Кто наши пользователи?», «Какие цели
преследуют пользователи, когда они заходят на наш сайт?»)
2. Организовать группу. Люди в группе должны быть из разных частей организации, чтобы
охватить более полные стороны вопроса.
3. Записать мнения на стикеры. Помещая один элемент на один стикер в каждой группе.
Каждая группа проводит мозговой штурм как можно большего количества предметов.
4. Стикеры размещаются на доске. Участники видят сикеры всех групп. Можно дописывать.
5. Однотипные стикеры группируются.
6. Используя стикеры другого цвета группы именуются.
7. Голосование за наиболее важные группы. Участникам предлагается индивидуально оценить,
какие группы он/она считает наиболее важными для ответа на основной вопрос.
8. Ранжирование наиболее важных групп. Это последний и самый важный шаг. Все
индивидуальные стикеры размещаются на доске в порядке количества голосов. Участники
могут объединить аналогичные группы, тогда голоса складывают и продвигают их вверх по
рейтингу. Если 3-4 группы иметь гораздо более высокий рейтинг, чем остальные, ведущий
прекращает упражнение.
https://articles.uie.com/kj_technique/
Внутренние
Внешние
КачественныеКоличественные
Качественные
Количественные
Внутренние Внешние
Выводы
1. Все техники приоритезации работают на высоком уровне абстракции:
a. Цель - удовлетворить пользователя, а не решить что сначала и что потом
b. Сократить время потерь, если/когда стратегия меняется
c. Приоритеты в стратегией, а команда ищет путь реализации
2. Установить цели, установить критерии оценки - Цель не состоит в том, чтобы
установить приоритеты и отправить их. Цель состоит в том, чтобы постоянно быть в курсе,
действительно ли то, что мы делаем, добавляет ценности и работает так, как ожидалось;
когда это не так, у нас будет по крайней мере некоторые подсказки относительно того, что
нуждается в корректировке.
3. Не делайте это в одиночку. - Расстановка приоритетов не должна быть сольной. За
исключением очень простых методов, почти все они вовлекают кого-то еще в процесс. Будь
то клиенты, заинтересованные стороны или члены команды, это очень редко, когда менеджер
по продукту сам устанавливает общие приоритеты. Мы просто отвечаем за процесс,а продукт
принадлежит команде
Выводы
4. Quantitative vs. Qualitative. Количественный не значит лучше качественного (и
наоборот). Например, распространенной ошибкой при использовании количественных
методов определения приоритетов является то, что люди связывают числа с точностью и
уверенностью. Просмотр формул, соотношений и рейтингов, как правило, позволяет нам
чувствовать себя более уверенными в надежности и объективности анализа определенного
типа, но они могут быть подвергнуты сомнению. Вы должны помнить об этом как для себя,
так и при представлении результатов другим людям - это руководящие принципы, а не
безошибочные результаты.
5. External vs. Internal. Шкала показывала как много внешних факторов в принятии
решения. Решение должно базироваться примерно так
Вы <- Команда <- Заинтересованные стороны <- Клиенты.
Выводы
6. Значение внешних методик. В общих чертах, внешние методы наиболее полезны,
когда вы пытаетесь перемещаться по большому набору возможностей-кандидатов, обращая
внимание на:
a. Определите наиболее ценные для ваших клиентов - знание их базовых и ожидаемых
результатов, а также того, что их радует;
b. Получение поддержки и консенсуса от группы Stakeholders
c. Определение того, какие функции не приносят пользы или что вызывает активное
недовольство клиентов, так что вы можете решить, стоит ли их улучшать или
отбрасывать;
d. Привлечение клиентов к консалтинговым проектам для участия в формировании
RoadMap
Выводы
7. Значение внутренних методик. Привлекая внутреннюю команду, которая ближе к
продукту и технологии, используем методы для определения проблем более низкого уровня.
Те, которые менее изучены, так как конечные пользователи менее вовлечены (если вообще).
Таким образом, они работают лучше всего, когда вам нужно:
a. Дальнейшее уточнение результатов, полученных с помощью одной из более
ориентированных на внешность технологий;
b. Определить приоритетность готового набора функций и идей, которые, как вы уверены,
соответствуют стратегии продукта и ожиданиям клиентов;
c. Работа над внутренними проектами без особого контакта с рынком (Например
внутренняя оптимизация);
d. Быстрая расстановка приоритетов низкоуровневых функций и требований. (Баг
фиксинг)
Методики приоритезации
Или как глубока кроличья нора

More Related Content

PDF
FeatureOwner
PDF
Impact mapping: от пользовательских историй к роадмапу
PPTX
PPTX
Kano Model for EBS alumni club
PPTX
Иван Константинов
PDF
Илья Трегубов
PDF
Артур Арсёнов
PDF
14 project-mistakes
FeatureOwner
Impact mapping: от пользовательских историй к роадмапу
Kano Model for EBS alumni club
Иван Константинов
Илья Трегубов
Артур Арсёнов
14 project-mistakes

What's hot (20)

PDF
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...
PDF
Вспомните о Пользователях
PPTX
Andrii mandrika
PDF
Как получать максимум от вложений в ИТ-разработку e-commerce продуктов?
PDF
Дернов Григорий
PPTX
Аркадий Рушкевич
PDF
Scrum в Заказной разработке
PPTX
Как превратить User Story в историю успеха
PPTX
Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать клас...
PPT
Andrey Petrov P D P
PDF
Useful JTBD seminar @ RF
PDF
КАК УПРАВЛЯТЬ ДИЗАЙН-ПРОЕКТОМ (для заказчиков и исполнителей)
PDF
Lean UX, Уровни UX, UXD процесс
PDF
How to create successful robotics startup
PPT
Работа с требованиями в Agile
PPTX
Дизайн успешных продуктов
PDF
Customer Development
PPTX
Product development. Founder Institute
PPT
Работа с требованиями в Agile - Part 3
PPTX
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...
Вспомните о Пользователях
Andrii mandrika
Как получать максимум от вложений в ИТ-разработку e-commerce продуктов?
Дернов Григорий
Аркадий Рушкевич
Scrum в Заказной разработке
Как превратить User Story в историю успеха
Продуктсорсинг - меняем аутсорсинг или как вместе с заказчиком создавать клас...
Andrey Petrov P D P
Useful JTBD seminar @ RF
КАК УПРАВЛЯТЬ ДИЗАЙН-ПРОЕКТОМ (для заказчиков и исполнителей)
Lean UX, Уровни UX, UXD процесс
How to create successful robotics startup
Работа с требованиями в Agile
Дизайн успешных продуктов
Customer Development
Product development. Founder Institute
Работа с требованиями в Agile - Part 3
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...
Ad

Similar to Dov Nimratz "Roadmap - selection of priorities" (20)

PPTX
Как сделать SaaS новым бизнесом для вашей компании и не разориться (Сергей Ры...
PPT
Kicking Off A Scrum Startup
PPTX
11 ключевых ошибок в разработке интернет-проектов
PPTX
В.Денисенков - Семь раз отмерь. Все что надо знать о выборе подрядчиков, прог...
PPTX
В.Денисенков Семь раз отмерь. Все что надо знать о выборе подрядчиков, прог...
PPTX
!как сделать эффективный сайт страховой компании. студия боровоо
PPTX
Сергій Марцинюк "A kind of Magic." Lviv Project Management Day 2017
PDF
Никита Михеенков. Контент и продажи. РИФ-Воронеж 2016
PDF
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
PDF
Errmakov Rit10 Prefinal
PPT
экономика Agile проекта
PPTX
ИКТ 03 Проектирование интерфейсов
PPTX
Осознанное развитие бизнеса в интернете. Что нужно ЗНАТЬ, чтобы не ошибиться ...
PDF
Макс Гапонов. Тактическое управление продуктами: все еще недостающее звено
PDF
Бизнес-девелопмент для Saas-сервисов: дизайн-проектирование стратегии / Серге...
PDF
DUMP-2013 Проектирование интерфейсов - Как коню из вакуума не попасть в черну...
PDF
Artsofte для dump2013
PPT
CodeFest 2010. Погребняк А. — Проблемы оценки труда программистов
PDF
Проектирование интернет-сайтов и систем в Redsoft
PDF
Интернет-маркетинг: инструкция по эксплуатации
Как сделать SaaS новым бизнесом для вашей компании и не разориться (Сергей Ры...
Kicking Off A Scrum Startup
11 ключевых ошибок в разработке интернет-проектов
В.Денисенков - Семь раз отмерь. Все что надо знать о выборе подрядчиков, прог...
В.Денисенков Семь раз отмерь. Все что надо знать о выборе подрядчиков, прог...
!как сделать эффективный сайт страховой компании. студия боровоо
Сергій Марцинюк "A kind of Magic." Lviv Project Management Day 2017
Никита Михеенков. Контент и продажи. РИФ-Воронеж 2016
10 лет развития продукта: чему можно научиться (Сергей Рыжиков)
Errmakov Rit10 Prefinal
экономика Agile проекта
ИКТ 03 Проектирование интерфейсов
Осознанное развитие бизнеса в интернете. Что нужно ЗНАТЬ, чтобы не ошибиться ...
Макс Гапонов. Тактическое управление продуктами: все еще недостающее звено
Бизнес-девелопмент для Saas-сервисов: дизайн-проектирование стратегии / Серге...
DUMP-2013 Проектирование интерфейсов - Как коню из вакуума не попасть в черну...
Artsofte для dump2013
CodeFest 2010. Погребняк А. — Проблемы оценки труда программистов
Проектирование интернет-сайтов и систем в Redsoft
Интернет-маркетинг: инструкция по эксплуатации
Ad

More from Lviv Startup Club (20)

PDF
Maksym Vyshnivetskyi: PMO KPIs (UA) - LemBS
PDF
Oleksandr Ivakhnenko: LinkedIn Marketing і Content Marketing: розширений підх...
PDF
Maksym Vyshnivetskyi: PMO Quality Management (UA)
PDF
Oleksandr Ivakhnenko: Вступ до генерації лідів для ІТ-аутсорсингу (UA)
PDF
Oleksandr Osypenko: Поради щодо іспиту та закриття курсу (UA)
PDF
Oleksandr Osypenko: Пробний іспит + аналіз (UA)
PDF
Oleksandr Osypenko: Agile / Hybrid Delivery (UA)
PDF
Oleksandr Osypenko: Стейкхолдери та їх вплив (UA)
PDF
Rostyslav Chayka: Prompt Engineering для проєктного менеджменту (Advanced) (UA)
PPTX
Dmytro Liesov: PMO Tools and Technologies (UA)
PDF
Rostyslav Chayka: Управління командою за допомогою AI (UA)
PDF
Oleksandr Osypenko: Tailoring + Change Management (UA)
PDF
Maksym Vyshnivetskyi: Управління закупівлями (UA)
PDF
Oleksandr Osypenko: Управління ризиками (UA)
PPTX
Dmytro Zubkov: PMO Resource Management (UA)
PPTX
Rostyslav Chayka: Комунікація за допомогою AI (UA)
PDF
Ihor Pavlenko: Комунікація за допомогою AI (UA)
PDF
Maksym Vyshnivetskyi: Управління якістю (UA)
PDF
Ihor Pavlenko: Робота зі стейкхолдерами за допомогою AI (UA)
PDF
Maksym Vyshnivetskyi: Управління вартістю (Cost) (UA)
Maksym Vyshnivetskyi: PMO KPIs (UA) - LemBS
Oleksandr Ivakhnenko: LinkedIn Marketing і Content Marketing: розширений підх...
Maksym Vyshnivetskyi: PMO Quality Management (UA)
Oleksandr Ivakhnenko: Вступ до генерації лідів для ІТ-аутсорсингу (UA)
Oleksandr Osypenko: Поради щодо іспиту та закриття курсу (UA)
Oleksandr Osypenko: Пробний іспит + аналіз (UA)
Oleksandr Osypenko: Agile / Hybrid Delivery (UA)
Oleksandr Osypenko: Стейкхолдери та їх вплив (UA)
Rostyslav Chayka: Prompt Engineering для проєктного менеджменту (Advanced) (UA)
Dmytro Liesov: PMO Tools and Technologies (UA)
Rostyslav Chayka: Управління командою за допомогою AI (UA)
Oleksandr Osypenko: Tailoring + Change Management (UA)
Maksym Vyshnivetskyi: Управління закупівлями (UA)
Oleksandr Osypenko: Управління ризиками (UA)
Dmytro Zubkov: PMO Resource Management (UA)
Rostyslav Chayka: Комунікація за допомогою AI (UA)
Ihor Pavlenko: Комунікація за допомогою AI (UA)
Maksym Vyshnivetskyi: Управління якістю (UA)
Ihor Pavlenko: Робота зі стейкхолдерами за допомогою AI (UA)
Maksym Vyshnivetskyi: Управління вартістю (Cost) (UA)

Dov Nimratz "Roadmap - selection of priorities"

  • 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 методик приоритезации ● Классификация методик по признакам ● Сведение их в таблицу
  • 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/
  • 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/ ● Нарисуйте лодку на доске ● Это скоростной катер, и он должен идти очень быстро; ● К сожалению, это сдерживается некоторыми якорями; ● Лодка - это продукт, а якоря - это особенности, которые клиенты расстраивают; ● Попросите клиентов написать на стикерах, какие функции им не нравятся, и насколько быстро, по их оценкам, лодка может двигаться без этих якорей; ● Каждый якорь и оценка скорости дают вам показатель «боли», который вы можете позже расставить по приоритетам для улучшения.
  • 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#
  • 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/
  • 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. Методики приоритезации Или как глубока кроличья нора

Editor's Notes

  • #11: Конец - когда закончились или деньги или фичи Метод применим и для наших задач
  • #30: Критерии: Привлечение клиентов, Опытность клиента, воронка продаж, Операционная эффективность Фичи: Автоматизация платежей, Уведомления, Анализ ошибок