طراحی سیستم برای MVP: تعادل بین ساده‌سازی بیش از حد و بیش‌مهندسی

بخش بزرگی از اشتباهات در ساخت MVP از یک سؤال ساده شروع می‌شود:

«ساده بودن دقیقاً یعنی چه؟»

بعضی تیم‌ها MVP را آن‌قدر ساده می‌کنند که بخش‌هایی از زیرساخت را که از همین حالا می‌دانند در آینده به آن نیاز خواهند داشت، کاملاً نادیده می‌گیرند.

در طرف دیگر، بعضی تیم‌ها می‌خواهند قبل از ورود اولین کاربر واقعی، برای تقریباً همه‌چیز آماده باشند: بهترین معماری، کامل‌ترین سیستم Analytics، سئوی بی‌نقص، سطح‌بندی دسترسی پیچیده، مانیتورینگ کامل و زیرساختی که بتواند میلیون‌ها کاربر را مدیریت کند.

هر دو رویکرد می‌توانند پرهزینه باشند.

یک MVP خوب باید از نظر دامنه محصول کوچک باشد، اما این الزاماً به این معنی نیست که پایه‌های آن هم باید ضعیف و موقتی باشند.

در عین حال، داشتن پایه‌های درست هم به این معنی نیست که باید تمام قابلیت‌هایی را که شاید دو سال دیگر نیاز داشته باشیم، همین امروز پیاده‌سازی کنیم.

سؤال بهتر این است:

کوچک‌ترین محصول قابل استفاده‌ای که امروز می‌توانیم بسازیم، بدون اینکه فردا خودمان را وارد یک بن‌بست غیرضروری کنیم، چیست؟

سادگی با ساده‌سازی بیش از حد فرق دارد

یکی از برداشت‌های اشتباه از MVP این است که فکر کنیم برای هر تصمیم فنی باید سریع‌ترین و ابتدایی‌ترین راه ممکن را انتخاب کنیم.

فرض کنید محصولی می‌سازید که کاربران در آن فایل آپلود می‌کنند.

سریع‌ترین راه ممکن این است که فایل‌ها را مستقیماً روی همان سروری که اپلیکیشن اجرا می‌شود ذخیره کنید.

برای ۱۰ یا ۲۰ کاربر اول احتمالاً هیچ مشکلی هم پیش نمی‌آید.

اما اگر از همین ابتدا می‌دانید که فایل و فضای ذخیره‌سازی بخش مهمی از محصول شما خواهد بود، این تصمیم می‌تواند خیلی زود دردسرساز شود.

کم‌کم مسیر فایل‌های محلی وارد دیتابیس می‌شوند، بخش‌های مختلف برنامه مستقیماً به File System وابسته می‌شوند، Workerها انتظار دارند فایل روی همان سرور وجود داشته باشد و ساختار Deploy شما به فضای ذخیره‌سازی محلی وابسته می‌شود.

بعد محصول رشد می‌کند و نیاز دارید به Object Storage مهاجرت کنید.

حالا یک تصمیم که در ابتدا «ساده» به نظر می‌رسید، تبدیل شده به مهاجرت دیتابیس، تغییر کد، انتقال فایل‌ها، تغییر زیرساخت و تست بخش‌های مختلف سیستم.

این دیگر لزوماً سادگی نیست.

گاهی فقط داریم پیچیدگی‌ای را که از همین امروز می‌شناسیم به آینده منتقل می‌کنیم.

یک راه منطقی‌تر می‌تواند این باشد که از ابتدا از یک رابط S3-compatible استفاده کنیم و مثلاً در نسخه اولیه از یک راهکار سبک مثل MinIO استفاده کنیم.

قرار نیست برای میلیون‌ها کاربر زیرساخت بسازیم.

فقط یک abstraction درست انتخاب کرده‌ایم که بعداً امکان رشد داشته باشد.

اصل مهم اینجاست:

MVP لازم نیست برای بیشترین مقیاس ممکن طراحی شود؛ فقط نباید رشد منطقی آینده را بی‌دلیل سخت کند.

قابلیت زیرساخت با امکانات محصول یکی نیست

Authentication مثال خوبی برای این موضوع است.

ممکن است MVP شما فقط به ایمیل و پسورد نیاز داشته باشد.

اما این الزاماً به این معنی نیست که باید یک سیستم احراز هویت ساده و سفارشی از صفر بنویسید.

Authentication در آینده می‌تواند شامل موارد زیادی شود:

بازیابی رمز عبور
مدیریت Session
تأیید ایمیل
ورود با Google یا سایر سرویس‌ها
MFA
نقش‌ها و سطح دسترسی
حساب سازمانی
SSO

طبیعتاً MVP شما به همه این موارد نیاز ندارد.

اما می‌توانید از یک سیستم احراز هویت成熟 و قابل اعتماد استفاده کنید و فقط قابلیت‌هایی را که امروز لازم دارید فعال کنید.

مثلاً نسخه اول فقط شامل این موارد باشد:

ثبت‌نام، ورود، خروج و بازیابی رمز عبور.

تأیید شماره تلفن؟ فعلاً غیرفعال.

Social Login؟ فعلاً لازم نیست.

MFA؟ بعداً.

Permissionهای پیچیده؟ هنوز نه.

زیرساخت شما ممکن است قابلیت پشتیبانی از این امکانات را داشته باشد، اما محصول فعلی نیازی ندارد همه آن‌ها را ارائه دهد.

این تفاوت بسیار مهم است:

قابلیت رشد داشتن با بزرگ بودن Scope محصول یکی نیست.

اما «آینده‌نگری» خیلی راحت تبدیل به بیش‌مهندسی می‌شود

وقتی یک تیم متوجه خطر ساده‌سازی بیش از حد می‌شود، ممکن است در جهت دیگری افراط کند.

تیم شروع می‌کند به فکر کردن درباره تمام مشکلات احتمالی آینده.

و ناگهان MVP باید همه‌چیز داشته باشد:

سئوی کامل.

Analytics کامل.

Dashboardهای پیشرفته.

سیستم Permission پیچیده.

چندین روش Authentication.

مانیتورینگ کامل.

Admin Panel جامع.

زیرساختی آماده برای ترافیکی که هنوز وجود ندارد.

هرکدام از این تصمیم‌ها به‌تنهایی منطقی به نظر می‌رسند.

مشکل زمانی شروع می‌شود که همه آن‌ها را کنار هم قرار می‌دهیم.

محصولی که می‌توانست در دو ماه منتشر شود، شش ماه در Development باقی می‌ماند.

و در تمام این مدت یک چیز بسیار مهم نداریم:

کاربر واقعی.

یکی از رایج‌ترین اشتباهات: تلاش برای اندازه‌گیری کامل همه‌چیز

یکی از دلایل اصلی بیش‌ازحد بزرگ شدن MVP، Analytics است.

منطق تیم معمولاً این است:

هدف MVP یادگیری است. پس اگر از همان ابتدا همه‌چیز را اندازه‌گیری کنیم، می‌توانیم رفتار کاربران را دقیق تحلیل کنیم و سپس محصول واقعی را بر اساس داده بسازیم.

در نگاه اول کاملاً منطقی است.

بعد شروع می‌کنیم به Track کردن همه‌چیز.

هر Button.

هر Page View.

هر Form.

هر Click.

هر Funnel.

هر مرحله از Onboarding.

هر Traffic Source.

هر نوع رفتار کاربر.

و بعد Dashboardهای مختلف، Segmentation، Heatmap، Session Replay و ده‌ها Metric دیگر وارد پروژه می‌شوند.

اما یک مشکل وجود دارد:

برای تحلیل رفتار کاربران، اول باید کاربر داشته باشید.

یک محصول با Analytics فوق‌العاده و ۲۰ کاربر ممکن است اطلاعات کمتری نسبت به محصولی با Analytics ساده و ۲۰۰۰ کاربر به شما بدهد.

هدف Analytics جمع‌آوری بیشترین میزان داده ممکن نیست.

هدف این است که عدم قطعیت را کاهش دهد.

در نسخه اولیه شاید فقط نیاز داشته باشید چند سؤال را پاسخ دهید:

آیا کاربران ثبت‌نام می‌کنند؟

آیا به قابلیت اصلی محصول می‌رسند؟

آیا فرآیند اصلی را کامل می‌کنند؟

آیا دوباره برمی‌گردند؟

آیا حاضر هستند برای محصول پول پرداخت کنند؟

اگر ۵ یا ۱۰ Event بتواند پاسخ این سؤال‌ها را بدهد، Track کردن ۱۰۰ Event دیگر الزاماً MVP شما را داده‌محورتر نمی‌کند.

شاید فقط Launch را عقب بیندازد.

بنابراین:

MVP باید قابل اندازه‌گیری باشد، اما لازم نیست همه‌چیز را اندازه‌گیری کند.

SEO هم می‌تواند به همین تله تبدیل شود

SEO مثال دیگری است.

قبل از Launch، تیم ممکن است بخواهد همه‌چیز کامل باشد:

Metadata بی‌نقص، Structured Data کامل، Internal Linking حرفه‌ای، Sitemap پیچیده، Open Graph Image خودکار، Canonical Ruleهای کامل، Landing Pageهای مختلف و ده‌ها Optimization دیگر.

هیچ‌کدام از این موارد بد نیستند.

سؤال این است:

آیا همه آن‌ها قبل از Launch لازم هستند؟

برای نسخه اولیه شاید همین موارد کافی باشند:

URLهای تمیز
Title و Description مناسب
صفحات قابل Crawl
Sitemap سالم
Performance قابل قبول

بعد محصول را منتشر کنید.

ببینید کاربران واقعاً به کدام صفحات می‌روند.

ببینید چه عبارت‌هایی Search می‌شوند.

ببینید چه Featureهایی واقعاً مهم هستند.

ببینید کاربران از چه اصطلاحاتی برای توضیح مشکلشان استفاده می‌کنند.

آن زمان تصمیم‌های SEO دیگر فقط بر اساس حدس نیستند.

بر اساس داده واقعی هستند.

هدف این نیست که SEO را نادیده بگیریم.

هدف این است که به اندازه مرحله فعلی محصول روی SEO کار کنیم.

همه تصمیم‌ها ارزش یکسانی ندارند

یکی از بهترین روش‌ها برای تصمیم‌گیری در MVP این است که بپرسیم:

تغییر این تصمیم در آینده چقدر سخت خواهد بود؟

تغییر متن یک Button؟

آسان.

اضافه کردن یک Event جدید به Analytics؟

معمولاً آسان.

تغییر Layout یک Dashboard؟

قابل مدیریت.

اما مهاجرت میلیون‌ها فایل از یک ساختار Storage نامناسب؟

خیلی سخت‌تر.

انتقال هزاران کاربر از یک سیستم Authentication دست‌ساز و ضعیف؟

بسیار پرریسک‌تر.

تغییر یک Data Model که در ده‌ها API و بخش مختلف سیستم استفاده شده؟

ممکن است بسیار هزینه‌بر باشد.

پس لازم نیست برای تمام قسمت‌های MVP یک سطح از مهندسی را در نظر بگیریم.

برای تصمیم‌هایی که تغییرشان در آینده گران است، بیشتر فکر کنید.

برای تصمیم‌های قابل بازگشت، سریع‌تر حرکت کنید.

معماری MVP باید برای تغییر بهینه شود

وقتی درباره System Design صحبت می‌کنیم، معمولاً مفاهیمی مثل این‌ها مطرح می‌شوند:

Scalability، Performance، Availability، Throughput و Reliability.

همه آن‌ها مهم هستند.

اما در یک محصول اولیه، یک ویژگی دیگر حتی می‌تواند مهم‌تر باشد:

Changeability — قابلیت تغییر سریع.

در مراحل اولیه ممکن است هر هفته Requirements تغییر کنند.

مدل قیمت‌گذاری تغییر کند.

Target Customer تغییر کند.

Onboarding عوض شود.

یک Feature کاملاً حذف شود.

یک قابلیت که فکر می‌کردید بسیار مهم است، تقریباً استفاده نشود.

و چیزی که انتظارش را نداشتید تبدیل به مهم‌ترین بخش محصول شود.

پس معماری MVP فقط نباید بپرسد:

«آیا این سیستم می‌تواند کاربران بیشتری را تحمل کند؟»

باید بپرسد:

«اگر فردا متوجه شویم فرض ما اشتباه بوده، چقدر سریع می‌توانیم سیستم را تغییر دهیم؟»

سیستمی که می‌تواند میلیون‌ها Request را پاسخ دهد اما تغییر یک Feature در آن سه هفته زمان می‌برد، الزاماً معماری خوبی برای یک Startup اولیه نیست.

در این مرحله، سرعت توسعه هم بخشی از Performance سیستم است.

به‌جای پیش‌بینی آینده، Boundaryهای خوبی بسازید

هیچ‌کس دقیقاً نمی‌داند محصول موفق سه سال دیگر چه شکلی خواهد بود.

تلاش برای پیش‌بینی تمام نیازهای آینده معمولاً به Overengineering منجر می‌شود.

روش بهتر این است که مرزهای منطقی ایجاد کنیم.

Storage مسئول Storage باشد.

Authentication از Business Logic جدا باشد.

Billing مسئولیت مشخصی داشته باشد.

Analytics از طریق Eventهای معنادار انجام شود، نه اینکه کد مربوط به چند Analytics Provider در تمام پروژه پخش شود.

قرار نیست آینده را دقیق پیش‌بینی کنیم.

فقط می‌خواهیم تغییرات آینده unnecessarily سخت نباشند.

به‌جای «ده میلیون کاربر»، سؤال دیگری بپرسید

به‌جای اینکه در روز اول بپرسید:

این سیستم را چطور برای ده میلیون کاربر طراحی کنیم؟

بپرسید:

اگر MVP موفق شود، اولین چیزی که احتمالاً مشکل ایجاد می‌کند چیست؟

ممکن است Storage باشد.

ممکن است یک Job سنگین باشد که به‌صورت Synchronous اجرا می‌شود.

ممکن است یک Query دیتابیس باشد.

ممکن است Search باشد.

ممکن است Authentication باشد.

لازم نیست آن مشکل را همین امروز به‌طور کامل حل کنید.

فقط مطمئن شوید معماری امروز، حل کردن آن در آینده را غیرضروری سخت نمی‌کند.

این نگاه بسیار کاربردی‌تر از تلاش برای طراحی یک سیستم عظیم بر اساس ترافیکی است که هنوز وجود ندارد.

پس «Minimum» در MVP واقعاً یعنی چه؟

Minimum به معنی کمترین مقدار کد ممکن نیست.

به معنی معماری ضعیف نیست.

به معنی نادیده گرفتن Security یا Scalability نیست.

و Viable هم به معنی کامل بودن همه Featureها نیست.

یک تعریف بهتر می‌تواند این باشد:

MVP کوچک‌ترین محصول مفیدی است که بتواند مهم‌ترین فرضیات ما را آزمایش کند و در صورت درست بودن آن فرضیات، مسیر منطقی برای رشد داشته باشد.

برای بخش‌هایی که تغییر آن‌ها در آینده بسیار گران است، پایه مناسبی انتخاب کنید.

Featureهای اطراف آن پایه را کوچک نگه دارید.

Analytics داشته باشید، اما فقط چیزهایی را اندازه بگیرید که به تصمیم‌گیری کمک می‌کنند.

SEO را رعایت کنید، اما Launch را برای رسیدن به SEO بی‌نقص ماه‌ها عقب نیندازید.

به Scale فکر کنید، اما برای ترافیکی که ندارید زیرساخت نسازید.

و مهم‌تر از همه:

محصول را به دست کاربر واقعی برسانید.

چون از یک نقطه به بعد، معماری بیشتر، Analytics بیشتر و Optimization بیشتر دیگر ریسک را کاهش نمی‌دهند.

فقط رسیدن به اطلاعات واقعی را به تأخیر می‌اندازند.

به اندازه‌ای بسازید که بتوانید یاد بگیرید.

به اندازه‌ای طراحی کنید که بتوانید رشد کنید.

و اجازه دهید کاربران واقعی مشخص کنند کدام بخش محصول واقعاً ارزش پیچیده‌تر شدن دارد.