Я создаю проект электронной коммерции, и я хотел определить его MVP, чтобы я мог построить его итеративным способом в гибкой манере, чтобы я мог сократить цикл обратной связи с клиентами и адаптироваться как можно скорее. Проблема заключается в том, что для электронной коммерции для запуска в производство потребуются следующие функции, которые являются стандартными на рынке:
Если я создам все эти функции, у меня уйдет 6 месяцев на первый выпуск, где петля обратной связи огромна, и, вероятно, существует огромный риск провала.
Есть ли у вас какие-либо идеи, как подойти к такой проблеме, чтобы я мог построить проект максимально гибко?
Если я создам все эти функции, у меня уйдет 6 месяцев на первый выпуск, где петля обратной связи огромна, и, вероятно, существует огромный риск провала.
Проблема в том, что вы в корне неправильно поняли как цель, так и объем того, что такое «минимально жизнеспособный продукт», и что он должен делать. Это распространенная проблема, и вы, конечно, не одиноки в ее неправильном понимании, но вам нужно переосмыслить то, что вы делаете (что больше похоже на разработку, достаточную для альфа- или бета-тестирования), в которую вы не готовы инвестировать, или переключиться. к настоящему подходу MVP. В любом случае вы должны отклониться от того, что вы делаете в настоящее время, и использовать радикально другой подход.
То, что вы описываете, вовсе не является «минимально жизнеспособным продуктом». Вы описываете готовый к продаже продукт, а это совсем другое. MVP — это инструмент для подтвержденного обучения, и на самом деле он предназначен для того, чтобы быть минимумом, необходимым для проверки рыночной гипотезы. В длинном перечне вещей, которые вы описываете как важные, большинство из них просто не соответствуют определению «минимум», и при этом большинство из них не обеспечивают четкого пути к подтвержденному изучению вашего целевого рынка.
Если вы действительно стремитесь к MVP, вы должны выбросить свой длинный список функций и заменить его наименьшим объемом работы, который вы можете сделать, чтобы получить полезную обратную связь от рынка и ваших целевых клиентов. Это может иметь форму:
MVP, который создает подтвержденное обучение, позволяет вам узнать, жизнеспособно ли то, что вы планируете создать, на рынке, и говорит вам, находитесь ли вы на правильном пути или вам нужно изменить направление. Другими словами, вы хотите получить знания или рано потерпеть неудачу; это не имеет абсолютно никакого отношения к тому, является ли продукт функциональным или пригодным для использования в его нынешнем состоянии, и имеет отношение к тому, будут ли люди заинтересованы вкладывать средства в него сейчас или платить за него позже, если бы это было так .
У вас есть большой проект без определяющих уникальных характеристик, без поэтапных или повторяющихся швов и без возможности для проверенного обучения, кроме как построить все это от носа до кормы. На рынке уже есть множество платформ и программных систем для электронной коммерции; создание еще одного может быть проектом, но само по себе не является коммерческим оправданием для этого.
Если вы все равно решите пойти по этому пути, то вам следует определить набор минимальных вертикальных срезов, которые вы можете предоставить быстро, чтобы как можно быстрее получить максимальный UX/UI и бизнес-отзыв об этих срезах. Например, и, вероятно, в таком общем порядке:
То же самое и со всем остальным в этом списке. Если вам нужны преимущества гибкости, а также преимущества проверенного обучения и жестких циклов обратной связи, тогда вы должны внедрить процесс разработки, который включает в себя небольшие приращения функциональности, итеративную разработку, тесные циклы обратной связи и, прежде всего, безусловное использование YAGNI . принцип .
Посмотрите на это с другой стороны:
В любом случае, хотя вам могут понадобиться все эти функции для работающего сайта электронной коммерции, приносящего прибыль для дальнейшего развития компании, они вам не нужны (возможно, вообще) для MVP и, конечно, не все сразу как часть возникающий процесс проектирования, такой как Scrum.
Для каждой из перечисленных функций хорошо подумайте, действительно ли она вам нужна для ваших первых потребителей, если да, то можете ли вы получить функциональность от чего-то другого, что уже создано, если нет, то можете ли вы подделать ее, выполнив ручной процесс в короткий срок.
Например: Перечисляя продукты, вам это нужно, и вы, вероятно, создадите это. Для регистрации пользователя, входа в систему, забытого пароля вам это нужно, но не могли бы вы использовать «Зарегистрироваться в Google/Facebook», а не создавать его. Платежи. Посмотрите на такие вещи, как Stripe или что-то еще, что легко интегрировать. Рейтинговая система. Такое ощущение, что это может появиться позже. Уведомления - притворяйтесь, отправляйте уведомления вручную. Если вы получаете много трафика, создайте его.
Поскольку цель состоит в том, чтобы получить минимально жизнеспособный продукт, это означает наличие минимального количества функций. Идея проста: когда клиенты начнут использовать продукт, они оставят вам ценную обратную связь, которая может изменить ход развития вашего проекта. Как уже говорилось ранее, лучше использовать существующую функцию, а не жестко кодировать. Примером является использование плагина для регистрации. Таким образом, вам не нужно тратить так много времени, и эти существующие функции могут быть удалены позже и жестко закодированы, если вы хотите.
Одна вещь, которую стоит рассмотреть, — это создание группы бета-тестирования продукта. Это будет группа пользователей, которые заинтересованы в продукте, не против увидеть его, пока он еще не завершен, и готовы подписать соглашение о неразглашении.
Ценность группы бета-тестирования заключается в том, что она позволяет вам выпускать релизы итеративно, даже до того, как вы доберетесь до стадии MVP.
Богдан