Комментарии 4
Как раз в реальной коммерческой разработке ориентированной на массовые рынки слабо применимо, поскольку требует быстрой оценки у клиента каждого! требования по двум осям (реализовано/нет) с выбором одного из пяти варианта оценки. Застрелитесь клиентские опросы проводить…
Как вы видете, например, приоретизацию требований по KANO, для новой фичи в Firefox? Чисто для примера feature это — автоматическое включение Private Browser на нужных сайтах…
Как вы видете, например, приоретизацию требований по KANO, для новой фичи в Firefox? Чисто для примера feature это — автоматическое включение Private Browser на нужных сайтах…
В дополнение к нижнему ответу на ваш комментарий хочу уточнить, что я под клиентом понимаю «заинтересованные лица» от решения которых зависит успех вашего продукта. Ни что не мешает автоматизировать проведение опроса. Все же клиент косвенно тоже часть команды, ведь в этом случае он совершил сознательный выбор в пользу вашей программы, и нужно показать ему, что для вас очень важен этот выбор.
Как бы это не казалось удивительным, но клиенты вполне себе способны ответить даже на такие продолжительные опросы с минимальном потерей в качестве ответов. По моему опыту в финансовой сфере до 30% клиентов, которым предложили пройти опрос онлайн, завершать его прохождение полностью. Тут так же важно понимать что результаты ответов следует где-то использовать и бросаться на те идеи, которые показали потенциал не всегда самый лучший вариант. Но зато можно с легкостью отсеять те идеи, которые вашей аудитории не интересны.
Если у кого-то возникнет возможность в реальности попробовать данный подход: можете воспользоваться бесплатным калькулятором для сбора результатов по модели Кано: https://kartashev.me/kano-calculator/
Для решения вашей проблемы можно организовать фокус-группу (в российской схеме — это может называться рабочей группой, где кстати могут быть и тестировщики) для которой будет демонстрироваться ваш продукт, и от её коллегиального решения будет зависеть выход изделия (продукта, релиза ПО) на рынок. В статье описана технология, а способов её применения множество. Даже если продукт инновационный, то у него все равно должны быть заинтересованные лица (клиенты). В крайнем случае, главным потребителем может быть вы сами, если продукт разрабатывается для себя. Категоризация — это не планирование, а только определение спорных моментов в рамках требований, моментов требующих проработки и возможность команде быстро показать прототип на базе типовых требований. Приведу пример, у вас существует так называемая приёмочная шкала, с её помощью вы пытаетесь расписать свои контрактные обязательства, если произвести сортировку требований по этой шкале, то может так получится, что в списке окажутся требования из категории "I" с абстрактной важностью >100. Команда потратит на них время, и даже, может быть реализует, но не сможет продемонстрировать продукт заказчику, потому, что у него в приоритете будут типовые требования и он как раз им и установит приемочную шкалу >100. Обычно типовые требования в ТЗ явно не указаны, поэтому с приоритетами так можно играть до бесконечности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Информационная поддержка изделия: спецприём KANO