فكرة المنتج القابل للتطبيق بحدٍّ أدنى (MVP) نصيحة سيئة لأي شخص يبني باستخدام منصة ذكاء اصطناعي في 2026. ليست نصيحة خاطئة تمامًا — بل نصيحة من عالم لم يعد موجودًا، ما زالت تتكرر لأنها تبدو منطقية وتصلح لشريحة عرض تقديمي.
كتب إريك ريس فكرة الـMVP عام 2011 لفرق كانت عقبتها الأساسية هي ساعات عمل المهندسين. إذا كانت الميزة تستغرق بناؤها ثلاثة أسابيع ولم تكن متأكدًا من رغبة أحد فيها، فكان تقليص النطاق هو الخطوة العقلانية الوحيدة — كنت تُقنّن موردًا نادرًا فعلًا. هذا القيد هو سبب أن كلمة "الحد الأدنى" كانت جوهرية في العبارة. لم تكن فلسفة تتعلق بذوق المنتج، بل كانت فرزًا تحت هيكل تكلفة حيث كان البناء مكلفًا والاكتشاف رخيصًا فقط إذا بنيت أقل أولًا.
هيكل التكلفة انقلب
عندما تبني عبر مسار من المحادثة إلى الخطة إلى التنفيذ بدلًا من لوحة سبرنت، لا تكلف الميزة الإضافية ثلاثة أسابيع. بل تكلف موجّهًا وجولة تحقق. الشيء الذي كان مكلفًا سابقًا — كتابة الكود — أصبح الآن شبه مجاني. الشيء الذي ما زال مكلفًا فعلًا هو تحديد ما يجب بناؤه، واستخلاص الإشارة من سلوك المستخدمين المشوش بعد الإطلاق. نظرية الـMVP حُسِّنت للقيد الأول. لا يكاد أحد ممن يبنون على منصة ذكاء اصطناعي مقيدًا به بعد الآن.
لذا عندما يُطلق مؤسس شاشة تسجيل دخول وميزة واحدة ويسميها "منتجًا أوليًا" "للتعلم بسرعة"، فهو عادةً لا يُقنّن شيئًا. إنه يطابق نمطًا لنصيحة كانت منطقية في اقتصاد مختلف، وفي هذه العملية يُطلق شيئًا رقيقًا جدًا بحيث لا يولّد إشارة حقيقية. يجرب خمسة أشخاص تطبيقًا بميزة واحدة، يرتد ثلاثة منهم فورًا، ولم تتعلم شيئًا تقريبًا سوى أن التطبيق المجرَّد يبدو مجرَّدًا. هذا ليس رشيقًا، بل صغير فقط.
| قيد 2011 | قيد 2026 (بانِي بالذكاء الاصطناعي) | |
|---|---|---|
| المورد النادر | ساعات عمل المهندسين لكتابة الكود واختباره | الوقت اللازم لتحديد النطاق الصحيح وقراءة النتائج |
| تكلفة الميزة الإضافية | أيام إلى أسابيع | دورة بناء واحدة، من دقائق إلى ساعتين تقريبًا |
| مخاطرة البناء الزائد | عالية — تكلفة غارقة إذا كان القرار خاطئًا | منخفضة — تكلفة الإزالة أو إعادة البناء تقارب تكلفة الإضافة |
| مخاطرة البناء الناقص | منخفضة — تُطلق مجددًا في السبرنت التالي | عالية — التطبيقات الرقيقة تنتج إشارة رقيقة وغامضة |
| ما كانت "الحد الأدنى" تحميه | وقت فريقك | لا شيء بعد الآن — بل يكلفك الآن جودة البيانات |
اقرأ هذا السطر الأخير مرتين. كان المبرر الكامل للاقتصار على الحد الأدنى هو حماية مورد لم يعد نادرًا بالنسبة لك الآن. أنت تدفع تكلفة القاعدة القديمة — سطح اختبار أضعف، إشارة استبقاء أضعف، مستخدمون يتوقفون لأن التطبيق بدا غير مكتمل لا لأن الفكرة سيئة — دون أن تجني الفائدة التي كانت تلك القاعدة تشتريها.
ماذا يعني "البناء الأوسع" فعليًا
لا أعني بناء كل ما يمكنك تخيله. أعني بناء الشكل الكامل والواضح للمنتج — التهيئة الأولية، الحلقة الأساسية، الميزة المجاورة الواحدة التي يمتلكها الجميع في فئتك، صفحة الإعدادات التي تجعله يبدو كبرمجية حقيقية لا كنموذج أولي — قبل أن تبحث عن المستخدمين. إذا كنت تبني متتبع عادات، فذلك يعني سلاسل الإنجاز والتذكيرات وعرض السجل، وليس السلاسل وحدها. إذا كنت تبني سوقًا متخصصًا، فذلك يعني القوائم والمراسلة وإشارة ثقة (تقييمات، توثيق، أي شيء)، وليس قوائم مرفقة بنموذج تواصل فقط.
الاختبار ليس "إلى أي حد يمكنني تصغير هذا". بل "ما أصغر نسخة قد يظنها الغريب منتجًا مكتملًا". هذا معيار مختلف، وعادة ما يكون بعرض ثلاث أو أربع ميزات، لا ميزة واحدة. على منصة تكون فيها كل ميزة من هذه خطوة تخطيط وجولة تحقق بدلًا من قرار توظيف، فإن بلوغ هذا المعيار في الأسبوع الأول أمر واقعي بشكل لم يكن ممكنًا إطلاقًا في 2011.
هناك نسخة من هذا اكتويت بها مبكرًا. بنيت أداة صغيرة لاستوديو صديق — شاشة واحدة، مهمة واحدة، منجزة بسرعة، منتج أولي جدًا. لم يستخدمها أحد، وأقنعت نفسي أن هذا هو صوت السوق. لم يكن كذلك. كانت المشكلة أن الأداة بدت غير مكتملة مقارنة بالتبويبات الثلاثة التي يمتلكها كل شيء آخر في سير عملهم، فلم يثق بها أحد بما يكفي لجعلها عادة. الفكرة كانت جيدة. الشكل كان الفشل، وأطلقت شيئًا رقيقًا تحديدًا لأنني ظننت أن الرقّة فضيلة.
أين يكون النقاد محقين
الأشخاص الذين سيعترضون على هذا لديهم وجهة نظر حقيقية، وهي لا تتعلق بتكلفة الهندسة — بل بالانتباه. بناء خمس ميزات لم يعد يكلفك أسابيع مطورين، لكنه ما زال يكلفك أسابيع قرارات، ويكلف مستخدميك جهد الفهم. نسخة أولى أوسع تعني سطحًا أكبر للتحقق، أماكن أكثر يمكن أن يختبئ فيها خلل، تهيئة أولية أطول للكتابة، أشياء أكثر يجب على المستخدم الجديد تعلمها قبل أن تنقر الحلقة الأساسية. إذا بنيت واسعًا وكانت الحلقة الأساسية خاطئة، فقد شوّشت إشارتك الآن عبر خمس ميزات بدلًا من واحدة، وفكّ لغز أيها قتل الاستبقاء يستغرق وقتًا أطول مما كان سيستغرقه اختبار نظيف واحد. انضباط النطاق ما زال مهمًا — لكنه موجّه الآن نحو هدف مختلف. الـMVP القديم كان يضبط وقت البناء. النسخة التي تناسب هذا الاقتصاد تضبط وقت القرار: اختر الحفنة من الميزات التي تجعل المنتج يبدو حقيقيًا، واقطع كل ما بعد ذلك بلا رحمة، وقاوم إغراء الاستمرار بالإضافة فقط لأن الإضافة رخيصة. الرخص في البناء ليس نفس الرخص في الصيانة أو الشرح أو التفكير عندما ينكسر شيء ما.
فابنِ أوسع مما تمليه غريزتك، لأن القيد الذي جعل "الحد الأدنى" الكلمة الصحيحة قد اختفى. لكن حافظ على الانضباط الذي جعل فكرة الـMVP فكرة جيدة أصلًا — فقط وجّهه نحو زحف النطاق بعد الإطلاق، لا نحو نسختك الأولى.
