В теме 2 ответа, и 2 участника, последнее обновление сделано пользователем 
Андрей Беняш 9 г, 8 мес. назад.
-
Сообщения
-
У Джеффа Паттона в книге «User story mapping» описана интересная модель по приоритезации требований.
» Differentiator
A feature that set them apart from their competition
Spoiler
A feature that is moving in on someone else’s differentiator
Cost reducer
A feature that reduces the organization costs
Table stakes
A feature necessary to compete in the marketplace»Что думаете?
Контекста маловато : )Приоритет показывает, какие требования будут отдаваться в разработку первыми?
И какие из перечисленных требований надо реализовывать первыми ?Ну конечно, контекст из книги.Методика описывает выбор требований для формирования Minimum viable product. При этом, требования представлены в виде понятном бизнес-пользователям. Ценность продукта возрастает по мере насыщения его требованиями которые имеют признак одной из категорий, требования не отнесенные к одной из категорий в MVP попадать не должны.
Методика не показывает порядок реализации требований. Следовательно, если предположить что методика описанная выше (методика №1) была использована, следом за ней нужно приоритезировать требования (использовать методику №2), чтобы показать порядок реализации (например MoSCoW). Однако, методика №2 нужно не только для того, чтобы разработчики знали чем будут озадачены в первую очередь, но для того чтобы дать PM пространство для маневров (выделить требования которыми можно будет пожертвовать, например, в случае ухудшения международной обстановки :)).
Можно ли объединить методики №1 и методику №2, чтобы и MVP сформировать и выстроить требования по порядку запуска?
Вы должны авторизироваться для ответа в этой теме.
