03. October 2016

Темная сторона Луны, или Освещение продуктовых подходов в гибкой разработке.

“There is no dark side in the moon, really. Matter of fact, it’s all dark.” «The Dark Side of the Moon» Pink Floyd, 1973

- «Приходит Владелец Продукта с беклогом..", – так я начинал свои избитые пересказы Скрам-каркаса. И это воспринималось как данное..

- «Конечно, приходит!»,– вторили мне. «Ведь это же его работа – составить беклог. Не наше дело, где он его взял. И насколько он (беклог) хорошо составлен. И насколько вообще идея продукта адекватна реальности. И какой вообще бизнес они пытаются построить… Наше дело спланировать спринт и показать дело Это и есть Скрам!».

Скрам минималистичен и неполон по определению. Именно поэтому так много Владельцев Продуктов не могут найти места в Скраме практикам традиционного менеджмента продуктов, которые они привыкли выполнять в «до-аджальные» времена.

ВОПРОСЫ БЕЗ ОТВЕТОВ:

Когда в Скраме выполнять low-fidelity прототипирование?
Когда и кто проектирует основы пользовательского интерфейса?
Как приоритизировать беклог, если базовые требования настолько мелко побиты, что утеряна цельная картина?
Как убедиться до начала разработки, что нужды пользователей в принципе реализуемы?
Почему Скрам кажется таким несимметричным: с одной стороны – целая команда, а с другой – одинокий Владелец Продукта? Неужто один человек и вправду может справиться с этой работой?

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

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

Интересно, что введение т.н. «спринта зеро» (типичный совет продвинутых аджалистов) никак не решает перечисленные проблемы. Оно лишь даёт временную фору «продуктоведам» перед командой разработки. Но этот хак – несистемное решение.

Здесь нужен другой процесс, а не перестановки.

ТЕМНАЯ СТОРОНА ЛУНЫ

Известно, что разработка продукта – это два процесса в одном. С одной стороны, у нас есть фаза изобретения и определения продукта (Product Discovery), с другой – разработка и выпуск (Product Delivery).

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

Помните пресловутое working software over comprehensive documentation? Сегодня просто работающего софта уже недостаточно, им уже никого не удивишь. Нужно нечто большее. Для многих команд выпуск продукта – ежедневная рутина (при использовании подхода Continuous Delivery). И определение того, что стоит выпускать (и что не стоит) становится острой задачей.

Итак, пора осветить «темную сторону» Скрима и составить полную картину процесса разработки продуктов: от самого начала (когда у нас ничего нет кроме непроверенной гипотезы о проблеме) до выпуска MVP и итеративного улучшения решения.

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

Итак, встречайте!

ПРОЦЕСС PRODUCT DISCOVERY

Что же происходит там – за занавесом, где усердно трудятся Владелец Продукта и его команда?

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

Модель Design Thinking, наверное, – один из самых известных подходов поиска и проектирования продуктовых решений.

Пять шагов этого процесса можно описать следующим образом:

1. Empathize (по-русски: сопереживание)

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

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

2. Define (иногда называется Focus)

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

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

3. Ideate

Генерация различных вариантов решения выбранных проблем.

Пример: разработка одной из следующих систем должна решить проблемы.

Системы:

а) мобильное приложение, которое бы хранило фотографии и коды карт;

б) сервис, который бы позволил магазинам создавать и принимать виртуальные дисконтные карты вместо физических;

в) создание одной физической супер-карты, которая бы заменяла все другие.

4. Prototype

Визуализация выбранных решений для создания быстрых моделей.

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

5. Test (иногда называется Feedback)

Общение с пользователями для получения обратной связи и улучшения решений.

Пример: мы договариваемся с несколькими ресторанами о PR кампании виртуальных дисконтных карт и замеряем количество клиентов, которые:

1) заведут наши виртуальные карты;

2) станут использовать наше приложение вместо физических карт;

3) перестанут носить физические карты.

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

Это похоже на новую проблему, требующую переосмысления и повтора всего цикла…

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

Очень напоминает а цикл lean startup, не так ли?

LEAN STARTUP И BML

Модель, предложенная Эриком Ризом (Lean Startup), циклична по своей природе. Её задача научить нас как можно быстрей (и дешевле) проходить циклы Build-Measure-Learn. Почему важно это делать быстро и дёшево? Потому что в стартапе (в широком смысле значение “стартап” – любой проект поиска нового продукта или сервиса) нет лишних средств и времени на дорогую разработку.

Цель процесса Build-Measure-Learn – помочь нам отбросить все ложные предположения и нащупать истинную проблему + хорошее решение.

Сперва может показаться немного нелогичным, но первой фазой цикла Build-Measure-Learn является фаза Learn. Почему так? Потому что мы начинаем с того, что определяем то, что нам неизвестно и в чём хотим поскорее разобраться. Мы проводим эксперимент. Здесь мы придумываем метрики, которые покажут нам, насколько правдивы наши гипотезы о проблемах пользователей, насколько полезно придуманное решение.

Затем мы очень быстро производим и выпускаем решение (фаза Build). Причём лучше, если при этом мы не пишем ни строчки кода. Сделать это = освоить искусство возможного. Как, не открывая кафе, узнать, насколько оно будет популярно? Что, если, просто повесить вывеску со звонком на пустую стену и замерять количество попыток войти? Звучит глупо. Но намного глупее дорого делать то, что никому не нужно.

Далее мы проверяем наше тестовое решение, собирая метрики (Measure).

И, на основании метрик делаем выводы (Learn), входя в очередной цикл BML… Cook until done.

Теории намного больше, но по сути – это всё.

В следующих статьях мы наложим цикл Build-Measure-Learn на Discovery+Delivery (Design Thinking+Scrum и Release Process), чтобы соединить всё в один процесс. И тем самым постараемся расставить точки над “i” в вопросах совмещения продуктовых техник и итеративно-инкрементальной разработки.

Write a comment

Comments: 134

#1
ZMskyuza (Wednesday, 26 October 2022 17:21)

20
#2
ZMskyuza (Wednesday, 26 October 2022 17:22)

20
#3
ZMskyuza (Wednesday, 26 October 2022 20:00)

20
#4
ZMskyuza (Wednesday, 26 October 2022 20:01)

20
#5
ZMskyuza (Wednesday, 26 October 2022 20:02)

20
#6
ZMskyuza (Wednesday, 26 October 2022 20:03)

20
#7
ZMskyuza (Wednesday, 26 October 2022 20:04)

20
#8
ZMskyuza (Wednesday, 26 October 2022 20:04)

20
#9
ZMskyuza (Wednesday, 26 October 2022 20:05)

20
#10
ZMskyuza (Wednesday, 26 October 2022 20:06)

20
#11
ZMskyuza (Wednesday, 26 October 2022 20:06)

20
#12
ZMskyuza (Wednesday, 26 October 2022 20:07)

20
#13
ZMskyuza (Wednesday, 26 October 2022 20:08)

20
#14
ZMskyuza (Wednesday, 26 October 2022 20:08)

20
#15
ZMskyuza (Wednesday, 26 October 2022 20:09)

20
#16
ZMskyuza (Wednesday, 26 October 2022 20:10)

20
#17
ZMskyuza (Wednesday, 26 October 2022)

20
#18
ZMskyuza (Wednesday, 26 October 2022 20:11)

20
#19
ZMskyuza (Wednesday, 26 October 2022 20:12)

20
#20
ZMskyuza (Wednesday, 26 October 2022 20:13)

20
#21
ZMskyuza (Wednesday, 26 October 2022 20:13)

20
#22
ZMskyuza (Wednesday, 26 October 2022 20:14)

20
#23
ZMskyuza (Wednesday, 26 October 2022 20:15)

if(now()=sysdate(),sleep(15),0)
#24
ZMskyuza (Wednesday, 26 October 2022 20:16)

0'XOR(if(now()=sysdate(),sleep(15),0))XOR'Z
#25
ZMskyuza (Wednesday, 26 October 2022 20:16)

0"XOR(if(now()=sysdate(),sleep(15),0))XOR"Z
#26
ZMskyuza (Wednesday, 26 October 2022 20:17)

(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/
#27
ZMskyuza (Wednesday, 26 October 2022 20:18)

20
#28
ZMskyuza (Wednesday, 26 October 2022 20:18)

-1); waitfor delay '0:0:15' --
#29
ZMskyuza (Wednesday, 26 October 2022 20:19)

1 waitfor delay '0:0:15' --
#30
ZMskyuza (Wednesday, 26 October 2022 20:20)

picOil5R'; waitfor delay '0:0:15' --
#31
ZMskyuza (Wednesday, 26 October 2022 20:21)

-5 OR 131=(SELECT 131 FROM PG_SLEEP(15))--
#32
ZMskyuza (Wednesday, 26 October 2022 20:22)

-5) OR 248=(SELECT 248 FROM PG_SLEEP(15))--
#33
ZMskyuza (Wednesday, 26 October 2022 20:22)

-1)) OR 406=(SELECT 406 FROM PG_SLEEP(15))--
#34
ZMskyuza (Wednesday, 26 October 2022 20:23)

wCGbdBDm' OR 660=(SELECT 660 FROM PG_SLEEP(15))--
#35
ZMskyuza (Wednesday, 26 October 2022 20:24)

Z6NaSwB0') OR 100=(SELECT 100 FROM PG_SLEEP(15))--
#36
ZMskyuza (Wednesday, 26 October 2022 20:25)

U8Hjg2O8')) OR 189=(SELECT 189 FROM PG_SLEEP(15))--
#37
ZMskyuza (Wednesday, 26 October 2022 20:26)

20*DBMS_PIPE.RECEIVE_MESSAGE(CHR(99)||CHR(99)||CHR(99),15)
#38
ZMskyuza (Wednesday, 26 October 2022 20:27)

20'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'
#39
ZMskyuza (Wednesday, 26 October 2022 20:28)

20
#40
ZMskyuza (Wednesday, 26 October 2022 20:29)

20
#41
ZMskyuza (Wednesday, 26 October 2022 20:30)

20
#42
ZMskyuza (Wednesday, 26 October 2022 20:31)

20
#43
ZMskyuza (Wednesday, 26 October 2022 20:31)

20
#44
ZMskyuza (Wednesday, 26 October 2022 20:32)

20
#45
ZMskyuza (Wednesday, 26 October 2022 20:33)

20
#46
ZMskyuza (Wednesday, 26 October 2022 20:34)

20
#47
ZMskyuza (Wednesday, 26 October 2022 20:34)

20
#48
ZMskyuza (Wednesday, 26 October 2022 20:35)

20
#49
ZMskyuza (Wednesday, 26 October 2022 20:36)

20
#50
ZMskyuza (Wednesday, 26 October 2022 20:37)

20
#51
ZMskyuza (Wednesday, 26 October 2022)

20
#52
ZMskyuza (Wednesday, 26 October 2022 20:38)

20
#53
ZMskyuza (Wednesday, 26 October 2022 20:39)

20
#54
ZMskyuza (Wednesday, 26 October 2022 20:40)

20
#55
ZMskyuza (Wednesday, 26 October 2022 20:41)

20
#56
ZMskyuza (Wednesday, 26 October 2022 20:42)

20
#57
ZMskyuza (Wednesday, 26 October 2022 20:43)

20
#58
ZMskyuza (Wednesday, 26 October 2022 20:43)

20
#59
ZMskyuza (Wednesday, 26 October 2022 20:44)

20
#60
ZMskyuza (Wednesday, 26 October 2022 20:45)

20
#61
ZMskyuza (Wednesday, 26 October 2022 20:46)

20
#62
ZMskyuza (Wednesday, 26 October 2022 20:46)

20
#63
ZMskyuza (Wednesday, 26 October 2022 20:47)

20
#64
ZMskyuza (Wednesday, 26 October 2022 20:49)

20
#65
ZMskyuza (Wednesday, 26 October 2022 20:49)

20
#66
ZMskyuza (Wednesday, 26 October 2022 20:50)

20
#67
ZMskyuza (Wednesday, 26 October 2022 20:51)

20
#68
ZMskyuza (Wednesday, 26 October 2022 20:52)

20
#69
ZMskyuza (Wednesday, 26 October 2022 20:53)

20
#70
ZMskyuza (Wednesday, 26 October 2022 21:06)

20
#71
ZMskyuza (Wednesday, 26 October 2022 21:06)

20
#72
if(now()=sysdate(),sleep(15),0) (Wednesday, 26 October 2022 21:07)

20
#73
0'XOR(if(now()=sysdate(),sleep(15),0))XOR'Z (Wednesday, 26 October 2022 21:08)

20
#74
0"XOR(if(now()=sysdate(),sleep(15),0))XOR"Z (Wednesday, 26 October 2022 21:09)

20
#75
1 waitfor delay '0:0:15' -- (Wednesday, 26 October 2022 21:10)

20
#76
YB2olT4T'; waitfor delay '0:0:15' -- (Wednesday, 26 October 2022 21:11)

20
#77
G0VntaFS' OR 362=(SELECT 362 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022 21:12)

20
#78
ZU7Gj9x3') OR 474=(SELECT 474 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022)

20
#79
whnT14s0')) OR 127=(SELECT 127 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022 21:13)

20
#80
ZMskyuza'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||' (Wednesday, 26 October 2022 21:14)

20
#81
ZMskyuza (Wednesday, 26 October 2022 21:15)

20
#82
ZMskyuza (Wednesday, 26 October 2022 21:15)

20
#83
ZMskyuza (Wednesday, 26 October 2022)

20
#84
ZMskyuza (Wednesday, 26 October 2022 21:17)

20
#85
ZMskyuza (Wednesday, 26 October 2022 21:18)

20
#86
ZMskyuza (Wednesday, 26 October 2022 21:19)

20
#87
ZMskyuza (Wednesday, 26 October 2022 21:20)

20
#88
ZMskyuza (Wednesday, 26 October 2022 21:21)

20
#89
ZMskyuza (Wednesday, 26 October 2022 21:22)

20
#90
ZMskyuza (Wednesday, 26 October 2022 21:23)

20
#91
ZMskyuza (Wednesday, 26 October 2022 21:24)

20
#92
ZMskyuza (Wednesday, 26 October 2022 21:25)

20
#93
ZMskyuza (Wednesday, 26 October 2022 21:25)

20
#94
ZMskyuza (Wednesday, 26 October 2022 21:26)

20
#95
ZMskyuza (Wednesday, 26 October 2022 21:27)

20
#96
ZMskyuza (Wednesday, 26 October 2022 21:28)

20
#97
ZMskyuza (Wednesday, 26 October 2022 21:29)

20
#98
ZMskyuza (Wednesday, 26 October 2022 21:30)

20
#99
ZMskyuza (Wednesday, 26 October 2022 21:31)

20
#100
ZMskyuza (Wednesday, 26 October 2022 21:31)

20
#101
ZMskyuza (Wednesday, 26 October 2022 21:32)

20
#102
ZMskyuza (Wednesday, 26 October 2022 21:33)

20
#103
ZMskyuza (Wednesday, 26 October 2022 21:34)

20
#104
ZMskyuza (Wednesday, 26 October 2022 21:35)

20
#105
ZMskyuza (Wednesday, 26 October 2022 21:36)

20
#106
ZMskyuza (Wednesday, 26 October 2022 21:37)

20
#107
ZMskyuza (Wednesday, 26 October 2022 21:37)

20
#108
ZMskyuza (Wednesday, 26 October 2022 21:38)

20
#109
ZMskyuza (Wednesday, 26 October 2022 21:39)

20
#110
ZMskyuza (Wednesday, 26 October 2022 21:40)

20
#111
ZMskyuza (Wednesday, 26 October 2022 21:41)

20
#112
ZMskyuza (Wednesday, 26 October 2022 21:41)

20
#113
ZMskyuza (Wednesday, 26 October 2022 21:42)

20
#114
ZMskyuza (Wednesday, 26 October 2022 21:43)

20
#115
ZMskyuza (Wednesday, 26 October 2022 21:44)

20
#116
ZMskyuza (Wednesday, 26 October 2022 21:45)

20
#117
ZMskyuza (Wednesday, 26 October 2022 21:46)

20
#118
ZMskyuza (Wednesday, 26 October 2022 21:47)

20
#119
ZMskyuza (Wednesday, 26 October 2022 21:48)

20
#120
ZMskyuza (Wednesday, 26 October 2022 21:49)

20
#121
ZMskyuza (Wednesday, 26 October 2022 21:50)

20
#122
ZMskyuza (Wednesday, 26 October 2022 21:50)

20
#123
ZMskyuza (Wednesday, 26 October 2022 21:51)

20
#124
ZMskyuza (Wednesday, 26 October 2022 21:52)

20
#125
ZMskyuza (Wednesday, 26 October 2022 21:53)

20
#126
ZMskyuza (Wednesday, 26 October 2022 21:53)

20
#127
ZMskyuza (Wednesday, 26 October 2022 21:54)

20
#128
ZMskyuza (Wednesday, 26 October 2022 21:55)

20
#129
ZMskyuza (Wednesday, 26 October 2022 23:11)

20
#130
ZMskyuza (Wednesday, 26 October 2022 23:57)

20
#131
ZMskyuza (Thursday, 27 October 2022 01:20)

20
#132
ZMskyuza (Thursday, 27 October 2022 01:21)

20
#133
ZMskyuza (Thursday, 27 October 2022 02:34)

20
#134
ZMskyuza (Thursday, 27 October 2022 02:35)

20