MVP в моем понимании - это работающий сервис с минимальным функционалом, которым могут воспользоваться люди, чтобы решить свою задачу/проблему/боль и готовы за это заплатить. "Готовы заплатить" - это очень важный момент.
Бывает что сервис с базовым функционалом есть, но платить за него не хотят, потому что он решает надуманную задачу/проблему/боль основателя, а не аудитории, которая будет пользоваться сервисом.
ТЗ в проектировании подобных сервисов как такового обычно нет (его могут в основном написать только программисты, но они обычно сами пилят свой сервис и проектирование не заказывают), ТЗ пишется уже на основании прототипов для программистов, когда известен весь функционал, взаимосвязи и тд.
В проектировании обычно проходят интервью с основателем, чтобы понять что он хочет в формате "кто", "что", "как" будет делать в сервисе, а также "зачем" и "для чего" чтобы понять процесc, цели, боли, задачи. Когда, из какого места, с какого устройства, в каком эмоциональном состоянии, с какими ожиданиями и мыслями человек будет проходить весь процесс. Выясняется как текущие задачи решаются сейчас, что не устраивает и как хотелось бы. Проектировщик из всего этого делает документ с функциональными требованиями, на основе которого уже дальше проектируется архитектура сайта, прописываются сценарии пользователей и тд. Это если очень кратко.
Мне кучу раз скидывали ТЗ написанное для программистов, спроектировать интерфейс по нему очень проблемно, гораздо лучше живое общение с основателями, сотрудниками, потенциальными пользователями в формате как я описал выше.
В моей практике работы с посредниками это - некое подобие сайта на плагинах-костылях, которое, если удалось убедить заказчика, что лучше решений не бывает, обеспечивает гармонию с самим собой тем, кто рассуждает на досуге о сэкономленных бабках... не всем же дается талант писать собственный код, а вот возможность приобщиться так сказать, запихнув чужой готовый код - всем.
Комментарий недоступен
Minimum viable product.
Не прототип, а продукт с базовыми возможностями. Очень базовыми.
MVP в моем понимании - это работающий сервис с минимальным функционалом, которым могут воспользоваться люди, чтобы решить свою задачу/проблему/боль и готовы за это заплатить. "Готовы заплатить" - это очень важный момент.
Бывает что сервис с базовым функционалом есть, но платить за него не хотят, потому что он решает надуманную задачу/проблему/боль основателя, а не аудитории, которая будет пользоваться сервисом.
ТЗ в проектировании подобных сервисов как такового обычно нет (его могут в основном написать только программисты, но они обычно сами пилят свой сервис и проектирование не заказывают), ТЗ пишется уже на основании прототипов для программистов, когда известен весь функционал, взаимосвязи и тд.
В проектировании обычно проходят интервью с основателем, чтобы понять что он хочет в формате "кто", "что", "как" будет делать в сервисе, а также "зачем" и "для чего" чтобы понять процесc, цели, боли, задачи. Когда, из какого места, с какого устройства, в каком эмоциональном состоянии, с какими ожиданиями и мыслями человек будет проходить весь процесс. Выясняется как текущие задачи решаются сейчас, что не устраивает и как хотелось бы. Проектировщик из всего этого делает документ с функциональными требованиями, на основе которого уже дальше проектируется архитектура сайта, прописываются сценарии пользователей и тд. Это если очень кратко.
Мне кучу раз скидывали ТЗ написанное для программистов, спроектировать интерфейс по нему очень проблемно, гораздо лучше живое общение с основателями, сотрудниками, потенциальными пользователями в формате как я описал выше.
В моей практике работы с посредниками это - некое подобие сайта на плагинах-костылях, которое, если удалось убедить заказчика, что лучше решений не бывает, обеспечивает гармонию с самим собой тем, кто рассуждает на досуге о сэкономленных бабках... не всем же дается талант писать собственный код, а вот возможность приобщиться так сказать, запихнув чужой готовый код - всем.