Комментарии 4
А вы уверены, что запустили именно MVP?
Судя по описанию - это полновесные проекты, или этапы проектов.
MVP это ведь (как вы пишете), чтобы максимально быстро выдать минимально возможный функционал. Чтобы выйти на рынок, проверить концепцию. Когда требования изначально не ясны, и вдобавок все время меняются..
MVP - это когда бизнес хочет сделать многоосный тягач с прицепом, а мы, вместо того чтобы год его разрабатывать, через две недели даем бизнесу самокат и рюкзак.
И поехали.
А если не поехали - то радуемся, что потеряли две недели, а не год. В случае, когда поехали, и бизнес требует больше - через месяц даем ему мопед с прицепчиком. А через три даем Газель. Через шесть - Камаз. Через год, как и просили - многоосник.
Но это только если бизнес не меняет требования. Вы встречали такие бизнесы? Я - нет. Очень может быть, что в процессе бизнес передумает, и захочет парк Газелей, а не один многоосный тягач. Или его устроит один Камаз. Кто знает.
Да, скорее всего, вам придется выкинуть MVP и переписать продукт. И к этому нужно подготовить заказчиков. Объяснить, что потери будут невелики по сравнению с риском сделать офигенный, но никому не нужный продукт, а потом переделывать уже его.
И в этой связи, ИМХО, микросервисная архитектура - это уже не об MVP. Это когда мы хорошо понимаем как функциональные, так и не функциональные требования.
Ошибешься на старте с границами между микросервисами - и все, здравствуй, распределенный монолит.
Со всем согласен :)
Но есть нюансы. Зачастую, к счастью или нет, к нам клиент приходит с задачами запуска достаточно больших продуктов. И концепция этих продуктов включает в себя достаточно большой пласт задач.
Условно, нельзя создать ecom, в котором будет только перечень продуктов, которые поставляет клиент, без возможности оплаты через экваиринг и интеграцией с логистикой.
Далее, туда же залетают критические фичи, без которых MVP не будет работоспособен - CEO продвижение, рассылка писем, процессы сквозной авторизации, управление товарами и прочее.
В совокупности, набор требуемых фичей просто, чтобы запуститься, становится весьма объемным.
В основном, именно о таких системах и шла речь.
Грубо говоря, если использовать Вашу же метафору, самокат и рюказ не подойдут, если клиент торгует мебелью :)
Касаемо микросервисов, я не буду топить за подход реализации MVP через них. Довольно сложно на старте разделить как раз таки границы каждого. Если эти границы очертить возможно, то профит от них будет - легче заменить целый сервис на нормальный PIM, чем пытаться выкорчевать все процессы из монолита, которые на самописный PIM подписаны. Или же использовать готовые рекомендательные системы, чем развивать свою.
После выхода подобной системы на рынок, начинается процесс осмысления, выстраивания беклога и доработок уже нюансов. Микросервисы обрастают дополнительной логикой, усложняются и расширяются. Появляются побочные процессы, аналитика, укрупняются и добавляются интеграции. Эти процессы стоят дорого, кратно дороже чем реализация целого MVP (ведь нужно не просто сервис написать, но и подготовить внутренние регламенты и процессы бизнеса). Именно их на старте можно отрезать или упростить.
Не пренебрегайте типизацией.
а лучше сделайте ее обязательной и запретите мержиться в мастер без типизации.
Ощущение что 50%+ статьи написал ChatGPT
Как избежать проблем при запуске MVP