Pull to refresh
9
0
Андреi@iPR

Аналитик

Send message
В дополнение к нижнему ответу на ваш комментарий хочу уточнить, что я под клиентом понимаю «заинтересованные лица» от решения которых зависит успех вашего продукта. Ни что не мешает автоматизировать проведение опроса. Все же клиент косвенно тоже часть команды, ведь в этом случае он совершил сознательный выбор в пользу вашей программы, и нужно показать ему, что для вас очень важен этот выбор.
Для решения вашей проблемы можно организовать фокус-группу (в российской схеме — это может называться рабочей группой, где кстати могут быть и тестировщики) для которой будет демонстрироваться ваш продукт, и от её коллегиального решения будет зависеть выход изделия (продукта, релиза ПО) на рынок. В статье описана технология, а способов её применения множество. Даже если продукт инновационный, то у него все равно должны быть заинтересованные лица (клиенты). В крайнем случае, главным потребителем может быть вы сами, если продукт разрабатывается для себя. Категоризация — это не планирование, а только определение спорных моментов в рамках требований, моментов требующих проработки и возможность команде быстро показать прототип на базе типовых требований. Приведу пример, у вас существует так называемая приёмочная шкала, с её помощью вы пытаетесь расписать свои контрактные обязательства, если произвести сортировку требований по этой шкале, то может так получится, что в списке окажутся требования из категории "I" с абстрактной важностью >100. Команда потратит на них время, и даже, может быть реализует, но не сможет продемонстрировать продукт заказчику, потому, что у него в приоритете будут типовые требования и он как раз им и установит приемочную шкалу >100. Обычно типовые требования в ТЗ явно не указаны, поэтому с приоритетами так можно играть до бесконечности.

Information

Rating
Does not participate
Registered
Activity