Pavel
На этой стадии UX в основном и работает.
как такую работу в одном спринте и одной команде объединить?
Artem
у вас дискавери тоже спринтами?
Artem
ну и даже дискавери спринт окей, проблему все равно не увидел - разработать простой прототип, прогнать на юзерах, сделать выводы - это не влезает в спринт?
Pavel
у вас дискавери тоже спринтами?
По разному. У последнего клиента я рекомендовал спринтами: у них внутренний продукт, интервью с пользователями довольно просто планировать заранее, как и все воркшопы
Pavel
Но чаще вижу канбан.
Pavel
(И не надо сразу становиться в стойку, я имею ввиду неитеративный процесс с рабочими центрами и WIP лимитами)
Artem
спокойно ) я привычек в стойки вставать не имею )
Artem
но в чем трудность ux в обоих случаях мне пока неясна
Artem
встречи с пользователями тут как мешают?
Artem
тем более если график
Artem
учитывайте этот график на планировании, если это спринты
Pavel
В результате. Влияние UX на поставку будет разделено несколькими спринтами: пока он проведет все интервью, сделает все прототипы, сделает валидацию результатов - команда завершит спринт, и, возможно, неодин раз.
Pavel
В итоге вклад в каждом спринте в done у UX будет не в этом спринте, а в каком-то из предыдущих
Pavel
В итоге UX начнет работать с собственным результатом и с собственным Definition of Done
Artem
то есть за спринт он таки не успевает (я там выше спрашивал)
Artem
спринт 2 недели?
Pavel
то есть за спринт он таки не успевает (я там выше спрашивал)
Не успевает. Причем на неуспевание очень тяжело повлиять, в основном изза интервью :)
Pavel
Потому что поймать реального пользователя (а их нужно 3-5) - квест, который не всегда выполним в прдсказуемые сроки.
Pavel
Особено для продукта, который либо еще не вышел, либо не так, чтобы широко известен.
Konstantin
Дискавери тим изучает пользователя, его проблемы и ищет и проверяет потенциальные пути решения. Эти пути решения для проверки она может делать сама (paper and interactive prototypes например) либо использовать решения, поставленные dev team (где уже будет проверка на основе статистики с прода например)
Имхо по логике эта команда должна на "втором" этаже сидеть - на уровне программ. И ее бэклог раскидываться на реализацию девтимам на первый этаж/уровень команд через ПО.
Pavel
Так и сидит, но часто бывает, что на "первом" уровне тоже одна скрам-команда
Sergey
Мы буквально сегодня эту тему обсуждали с маркетологами.
Konstantin
Ну так по любому, имхо, фишки на реализацию/исследование/проработку через PO. А в велосити скрам команды закладываете время на НИОКР. ))))
Sergey
Пробуем сделать фокус группы и ближе общаться командами с пользователями. Пока решили, что интервью будет делать РО вместе с ними. А команды уже пользоваться на PBR и при разработке.
Pavel
Ну так по любому, имхо, фишки на реализацию/исследование/проработку через PO. А в велосити скрам команды закладываете время на НИОКР. ))))
А как в команде working agreement устанавливать и что будет в Definition of Done?
Artem
Потому что поймать реального пользователя (а их нужно 3-5) - квест, который не всегда выполним в прдсказуемые сроки.
попробуйте коридорное тестирование и сами тесты конечно дробить надо как и стори, даже нещадней )
Pavel
Артем, коридорное тестирование очень не всегда даст хороший результат. Выборка, все дела
Pavel
А дробить тесты - да, все ок, но они и так маленькие
Pavel
UX тесты вообще редко сложные, просто обычно их много и их надо запускать на большой выборке
Konstantin
А как в команде working agreement устанавливать и что будет в Definition of Done?
Ну есть KPI, а есть OKR. Имхо здесь второе.
Artem
Артем, коридорное тестирование очень не всегда даст хороший результат. Выборка, все дела
это сложный вопрос который на местах решать надо. Конечно коридорные тесты хуже, но зато и в несколько раз быстрее. Fast try, fast fail ))
Pavel
это сложный вопрос который на местах решать надо. Конечно коридорные тесты хуже, но зато и в несколько раз быстрее. Fast try, fast fail ))
Будет много ложно-отрицательных, если продукт нишевой и, что хуже, будет много ложно-положительных
Pavel
Фиговые интерфейсы и зубодрбительный user journey не зря бич индустрии :)
Pavel
опять же, некоторые сценарии в коридоре можно проверить ровно 1 раз :)
Pavel
Напрмер new user signup
Artem
Будет много ложно-отрицательных, если продукт нишевой и, что хуже, будет много ложно-положительных
это не так страшно, если вы не забываете про резуалт валидейшн
Artem
опять же, некоторые сценарии в коридоре можно проверить ровно 1 раз :)
так несколько ж людей можно поймать )
invariance
Непонятно, это группа про аджайл, или про UX 🤔
Pavel
WIP и инвестиции растут.
Pavel
так несколько ж людей можно поймать )
Так они закончатся. В следующий раз ты можешь не поймать тех, кто все еще new
Pavel
инвестиции на поиск людей зато сильно сокращаются
Они ниже, чем стоимость разработки фичи, которую после валидации придется сильно переделывать (в контексте UX я имею ввиду)
Artem
Так они закончатся. В следующий раз ты можешь не поймать тех, кто все еще new
следующий раз это когда? другая итераци после реализации? ну там уже и реальные пользователи есть
Artem
Они ниже, чем стоимость разработки фичи, которую после валидации придется сильно переделывать (в контексте UX я имею ввиду)
ну это ж не каждый раз, даже не каждый второй. Коридорные тесты не настолько плохи
Konstantin
А как в команде working agreement устанавливать и что будет в Definition of Done?
Так же можно результатом иметь заполнение результатов исследования в базе знаний. Если мы делаем что-то, то главное будет не сделать, рассказать соседу и забыть - а сформировать кейс, описать результаты, +/-, применимость. Что потом можно было вернуться к вопросу или не проходить путь заново...
Pavel
ну это ж не каждый раз, даже не каждый второй. Коридорные тесты не настолько плохи
Ну вот у тебя есть 3-5 гипотез на проверку какого-нибудь сожного signup. Например для покупки страховки.
Pavel
И в коридоре человек 10 всего.
Pavel
А для каждой гипотезы нужно минимум три проверки.
Pavel
Как быстро люди перестанут быть new?
Artem
так
Artem
а на ваших тестах как быстро? вы сколько человек на тесты зовете?
Pavel
а на ваших тестах как быстро? вы сколько человек на тесты зовете?
По разному :) Я сейчас никого не зову :)
Pavel
На последние была группа реальных пользоватеей, обычно 8 человек для проверки близких journeys
Artem
что-то вы там походу перегибаете палку с тестированием. Оно не должно вам давать гарантированно положительный результат. Это же гипотеза
Artem
без реализации вы все равно ее не проверите на 100%
Pavel
что-то вы там походу перегибаете палку с тестированием. Оно не должно вам давать гарантированно положительный результат. Это же гипотеза
Так это проверка гипотезы. Она как раз дает результат или положительный или отрицательный.
Artem
гипотеза после этого остается гипотезой
Pavel
Гипотеза формулируется же "При <journey X> время регистрации сокращается на Y"
Artem
с положительным прогнозом
Pavel
И дальше тест - сокращается, не сокращается.
Pavel
Суть в том, что journey может быть не одно.
Artem
йеп, а потом вы это реализуете и у вас оно растет
Artem
пичаль грусть
Pavel
Вот у тебя есть 5 гипотез с разными Journey. И проверять воплощением - дорого, прочто прототипом.
Pavel
И то, что показало лучший результат - в реальную (и сильно более дорогую) разработку.
Pavel
А после разработки валиадция.
Pavel
Вот чтобы первую проверку для выбора сделать, лучше потратить сильно меньше денег на тестирование.
Artem
ну вот это можно сделать и на 10 людях
Pavel
Но с нормальной выборкой.
Artem
просто с допущениями да
Pavel
Ну так я выше писал - 3-5 человек.
Pavel
И, кстати. это самая простая из гипотез.
Artem
в коридоре было 10, я точно помню )
Pavel
КУда круче "есть гипотеза, что у пользоватея с такими вот характеристиками есть такая проблема" :)
Pavel
А на каждую надо минимум 3 провеки
Artem
Вот чтобы первую проверку для выбора сделать, лучше потратить сильно меньше денег на тестирование.
ну вот не выглядит, что меньше. Несколько спринтов работы ux это недешево
Pavel
И проверяемые должны быть new user :)