الحد الأدنى من المنتج (MVP): كيف تقرّر ما يدخل النسخة الأولى وما يُؤجَّل

أمامك قائمة ميزات طلبتها بنفسك أو كتبها لك مبرمج، وميزانية تكفي جزءاً منها. سؤالك الآن هو أي جزء تبنيه أولاً، وعلى أي أساس تختاره.

النسخة الأولى في جوهرها أداة لتقليل المخاطر قبل أن تكون نسخة مصغّرة من المنتج النهائي. لديك افتراض واحد على الأقل لم يُختبر بعد: أن العملاء سيطلبون من التطبيق بدل الاتصال، أو أن المندوبين سيسجّلون الزيارات على الموبايل بدل الورق، أو أن الناس ستدفع مقابل الاشتراك. النسخة الأولى أقصر طريق لمعرفة إن كان هذا الافتراض صحيحاً، قبل أن تنفق بقية الميزانية على بنائه بالكامل.

وللأمر شاهد في الأرقام. حلّلت CB Insights ملابسات إغلاق 431 شركة مدعومة باستثمار جريء توقّفت منذ 2023، وحدّدت أسباب الفشل في 385 منها. جاء «نفاد رأس المال» على رأس القائمة بنسبة 70%، لكن الشركة نفسها تصفه بأنه سبب الوفاة الأخير لا المشكلة الأصلية، والسبب الأكثر دلالةً تحته هو ضعف ملاءمة المنتج للسوق بنسبة 43%. عيّنة كهذه لا تُسقَط على محل في طنطا أو شركة توزيع في جدة؛ هي شركات مدعومة باستثمار جريء ولها ظروفها الخاصة. لكن نمطها يستحق الانتباه: المال يخلص أثناء بناء شيء لم يتأكّد أحد أن السوق يريده.

ما يلي قاعدة فرز تطبّقها على قائمتك اليوم، والحدّ الذي لا يجوز النزول تحته مهما ضاقت الميزانية، والإشارات التي تقول إنك صرت جاهزاً للتوسعة.

«الحد الأدنى» ليس عدّ ميزات

المفهوم الشائع في السوق العربية أن الـMVP يعني «أرخص وأصغر نسخة ممكنة». صاحب المصطلح في صورته المتداولة، إريك ريس، يقول العكس صراحةً. في دليله المنشور سنة 2009 يعرّف الحد الأدنى من المنتج بأنه النسخة التي تتيح للفريق جمع أكبر قدر من التعلّم المتحقَّق عن العملاء بأقل مجهود، ثم يضيف تحذيراً في السطر التالي: «الـMVP، رغم اسمه، ليس المقصود به صناعة منتجات صغيرة». ويقول في الفقرة نفسها إن الأمر «ليس معادلة على الإطلاق. يحتاج اجتهاداً لمعرفة أي MVP يناسب كل سياق». ثم يضرب مثالاً من شركته: أول نسخة من IMVU استغرقت ستة أشهر حتى وصلت السوق. ستة أشهر ليست نسخة سريعة بأي مقياس، وهذا هو المقصود: المعيار ليس عدد الأسابيع ولا عدد الشاشات، وإنما مقدار ما تتعلّمه مقابل ما تنفقه.

الفرق العملي بين «صغير» و«ناقص» يشرحه مارتي كاجان بدقة أكبر. يعرّف الحد الأدنى من المنتج بأنه أصغر منتج تتوفّر فيه ثلاث خصائص معاً: يختاره الناس ويشترونه، ويستطيعون معرفة كيفية استخدامه، وتقدر أنت على تسليمه في موعده بمواردك المتاحة. وفي مقال لاحق يفصل بين «المنتج الأدنى» و«المنتج القابل للحياة»: الأول يعمل ويمكن استخدامه، والثاني يختاره الناس فعلاً ويقيم عملاً قائماً. الفرق بينهما، كما يصوغه، هو الفرق بين سؤال «أتقدر أن تستخدمه؟» وسؤال «أكنت لتستخدمه؟».

الخطر الذي يقلق صاحب النشاط يقع هنا بالضبط: أن ينزل بالنطاق فيخرج بشيء يعمل تقنياً ولا يختاره أحد.

عمود «منتج ناقص» هو ما يُفسد السمعة، ولا علاقة لذلك بصغر النطاق. النسخة الأولى الجيدة تفعل أقل، لكنها تفعله كاملاً.

ابدأ من الافتراض الذي يسقط المشروع لو سقط

قبل فرز الميزات، اكتب جملة واحدة: ما الشيء الذي لو تبيّن أنه غير صحيح، لما كان لهذا المشروع معنى؟

لصاحب سلسلة صيدليات صغيرة قد تكون: «الزبون سيطلب دواءه من التطبيق بدل الاتصال بالفرع». لموزّع أغذية: «المندوب سيسجّل الطلب على الموبايل أثناء الزيارة بدل تدوينه ورقاً وإدخاله مساءً». لمالك مركز تعليمي: «ولي الأمر سيدفع أونلاين بدل الحضور للمكتب».

كل افتراض من هذه يمكن اختباره بأقل بكثير من المنتج الكامل. ريس يروي في حوار نُشر سنة 2009 أنهم بنوا مرة ميزة كاملة كان يكفي قبلها صفحة هبوط واحدة وإعلان يقيس هل يضغط أحد أصلاً. وصاغ الدرس هكذا: «صفر بالمئة من الناس كانوا ليضغطوا، ما يعني أنه لا يهم ما في الصفحة الثانية».

ليست كل فكرة تُختبر بصفحة هبوط. لكن السؤال نفسه ينفع دائماً: ما أرخص طريقة تعرف بها أنني مخطئ؟ أحياناً تكون مكالمة مع عشرة عملاء، أو تشغيل الخدمة يدوياً لشهر عبر واتساب قبل برمجة أي شيء، أو بيع عشرة اشتراكات مسبقة. ما تتعلّمه من هذه الخطوة يغيّر قائمة الميزات نفسها، فيصير الفرز أسهل.

سؤال واحد يفرز قائمتك

الآن افتح القائمة. أمام كل بند اسأل السؤال الذي تعتمده وثيقة إطار DSDM المنشورة لدى Agile Business Consortium في قواعد ترتيب الأولويات MoSCoW: ماذا يحدث لو لم يُنفَّذ هذا المتطلب؟ إن كان الجواب أن المشروع يُلغى لأنه لا معنى لحلٍّ لا يحقّق هذا المتطلب، فهو ضرورة. غير ذلك فهو مرغوب أو مؤجَّل.

الوثيقة تضيف اختباراً ثانياً أصعب على المجاملة: تخيّل أنني جئتك ليلة الإطلاق وقلت لك إن هذه الميزة لن تكون جاهزة. هل توقف الإطلاق؟ إن كان جوابك لا، فالميزة ليست ضرورة مهما بدت مهمة في الاجتماع.

اختبار البديل اليدوي

هذا هو الاختبار الأهم لصاحب نشاط قائم بالفعل، وهو صريح في الوثيقة نفسها: إن وُجد حل بديل، «ولو كان يدوياً ومرهقاً»، فالميزة ليست ضرورة في هذا الإصدار.

في واقع السوق المصري والخليجي، البديل اليدوي غالباً موجود وتستعمله بالفعل اليوم:

• تقارير المبيعات الشهرية: تصدير إلى إكسل وترتيبها بنفسك ساعة في الشهر.
• إشعار العميل بحالة الطلب: رسالة واتساب يرسلها موظف الطلبات.
• استرجاع المنتجات: مكالمة ونموذج ورقي في الفرع، كما يحدث الآن.
• كوبونات الخصم: كود واحد ثابت تعلنه وتتحقّق منه يدوياً عند التحصيل.
• لوحة صلاحيات تفصيلية لكل موظف: حسابان اثنان ومسؤولية واضحة، إلى أن يكبر الفريق.

كل بند من هذه يحتمل التأجيل لأن غيابه يُكلّف وقتاً، لا يُوقف العمل. في المقابل، إن كان النشاط يتعامل مع مئة طلب يومياً فإن «رسالة واتساب يدوية» تتوقّف عن كونها بديلاً معقولاً وتنتقل إلى خانة الضرورات. القاعدة واحدة والحكم يختلف بحجمك، وهذا هو الاجتهاد الذي تحدّث عنه ريس.

سقف الضروريات

بعد الفرز ستكتشف على الأرجح أن كل شيء صار ضرورة. الوثيقة نفسها تعلّق على هذا بجملة مفيدة: الاعتقاد بأن كل شيء ضروري هو في العادة عرَض لعدم تفكيك المتطلبات بما يكفي. «إدارة الطلبات» ليست متطلباً واحداً؛ داخلها إنشاء الطلب وتعديله وإلغاؤه وتتبّعه وتقاريره، ولكلٍّ أولوية مختلفة.

ويضع الإطار نفسه سقفاً رقمياً: ألّا يتجاوز مجهود الضروريات 60% من مجهود المشروع، مع مجموعة معقولة من البنود الأقل أولوية تقارب 20%. وتجاوز الـ60%، بحسب الوثيقة، يرفع خطر الفشل إلا حين تكون البيئة والتقنية مفهومة تماماً والفريق مستقراً والمخاطر الخارجية محدودة. المنطق وراء السقف بسيط: ما ليس ضرورياً هو احتياطيّك حين يتأخّر شيء ما، وهو يتأخّر دائماً. مشروع كله ضروريات مشروع بلا احتياطي.

قاعدة أخيرة من الوثيقة تنقذ الكثير من الخطط: الضرورة لا يصحّ أن تعتمد على غير ضرورة. إن كانت الميزة التي صنّفتها ضرورية لا تعمل إلا بميزة أجّلتها، فأحد التصنيفين خطأ.

آخر بند في الجدول مأخوذ من مثال الوثيقة نفسها، وهو يشرح مبدأً يغيب عن كثيرين: الأولوية تتحرّك مع الزمن. ما هو مؤجَّل في الإصدار الأول قد يصير ضرورة قبل نهاية المشروع. تأجيل الميزة ليس إلغاءها.

ما الذي لا يُؤجَّل مهما ضاقت الميزانية

قائمة التأجيل لها قاع. تحته يصير ما تبنيه منتجاً ناقصاً بالمعنى الذي شرحناه، وبعض هذا القاع ليس رأياً بل نصّاً مكتوباً تُرفض على أساسه.

المتاجر ترفض الناقص، لا الصغير

إن كانت النسخة الأولى تطبيق موبايل، فأنت تمرّ على مراجعة لها شروط منشورة. إرشادات مراجعة التطبيقات لدى Apple تنصّ في بند اكتمال التطبيق (2.1) على رفض الحزم الناقصة والنسخ التي تنهار أو تُظهر مشاكل تقنية واضحة. وينصّ بند الحد الأدنى من الوظائف (4.2) على أن التطبيق يجب أن يتضمّن «خصائص ومحتوى وواجهة ترفعه فوق كونه موقعاً أُعيد تغليفه»، ويضيف البند 4.2.2 أن التطبيقات لا يصحّ أن تكون في جوهرها مواد تسويقية أو قصاصات ويب أو مجرّد مجموعة روابط.

سياسة Google Play للوظائف والمحتوى وتجربة المستخدم تقف في الموضع نفسه: لا تُقبل التطبيقات محدودة الوظائف والمحتوى (والمثال المضروب في نصّ السياسة تطبيق نصّي أو تطبيق لعرض ملف PDF)، ولا التطبيقات التي لا تُثبَّت، أو تُثبَّت ولا تفتح، أو تفتح ولا تستجيب.

اقرأ الشرطين معاً: المتجران لا يعترضان على قلة الميزات. يعترضان على الانهيار، وعلى الفراغ، وعلى تطبيق لا يضيف شيئاً فوق موقعك. نسخة أولى تفعل شيئاً واحداً وتفعله بثبات تمرّ؛ نسخة تفعل عشرة أشياء نصف تنفيذ تتعثّر.

وما لا بديل يدوي له عندك

بجانب شروط المتاجر، ثلاثة أنواع تسقط من اختبار البديل اليدوي بطبيعتها.

أوّلها كل ما يمسّ المال: استقبال مبلغ وتسجيله وربطه بالطلب. الخطأ هنا لا يُصلَح لاحقاً بسهولة، ولن تستطيع أن تطلب من عميل أن يدفع مرة ثانية لأن نظامك لم يسجّل الأولى.

والثاني البيانات التي لن تستطيع تجميعها بأثر رجعي. إن لم تسجّل من أي مصدر جاء العميل، أو تاريخ تغيّر حالة الطلب، فهذه معلومات ضاعت ولن تعود حين تحتاجها بعد ستة أشهر. لاحظ الفرق: تسجيل البيانات ضرورة، أما التقارير المبنية عليها فتحتمل التأجيل شهوراً.

والثالث ما يلزمك به نظام أو جهة رقابية بحسب نشاطك. الالتزامات المرتبطة بالفوترة أو الضرائب أو حماية بيانات العملاء ليست ميزات تُدرج في خطة الإصدار الثاني؛ هي شروط تشغيل. راجعها مع محاسبك أو مستشارك القانوني قبل تحديد النطاق، لا بعده.

وهناك صنف رابع لا تفرضه جهة خارجية، وإنما هندسة المشروع، وهو رأينا المهني لا قاعدة منشورة: بنية البيانات والصلاحيات. تغيير شكل جدول الطلبات بعد ستة أشهر من التشغيل الحقيقي أغلى بكثير من ضبطه في الأسبوع الأول، لأن التغيير يجرّ معه البيانات الموجودة. لا نعني بناء نظام صلاحيات معقّد في النسخة الأولى، بل ألّا تُبنى البيانات بشكل يستحيل التوسّع فيه.

ميزة تبدو مجانية: الحساب وتسجيل الدخول

كثير من أصحاب المشاريع يدرجون تسجيل الدخول تلقائياً لأن «كل التطبيقات فيها لوجين». إرشادات Apple تقول شيئاً مختلفاً في بند جمع البيانات وتخزينها (5.1.1): إن لم يتضمّن تطبيقك خصائص جوهرية قائمة على الحساب، فدع الناس يستخدمونه بلا تسجيل دخول. وفي الجملة التالية مباشرةً التزام يغفل عنه الجميع عند التقدير: إن دعم تطبيقك إنشاء الحسابات، فعليك أيضاً أن توفّر حذف الحساب من داخل التطبيق.

أي أن «شاشة لوجين بسيطة» ليست شاشة واحدة. هي تسجيل وتحقّق واستعادة كلمة مرور وحذف حساب وما يترتّب على الحذف من معالجة للبيانات المرتبطة. لو كانت نسخة أولى لمتجر يبيع بالدفع عند الاستلام، فربما يكفي رقم هاتف مع الطلب، ويؤجَّل الحساب كاملاً إلى أن يصير له سبب واضح.

هذا المثال ينطبق على بنود أخرى في قائمتك. قبل أن تصنّف ميزة، اسأل عمّا يجرّه إدراجها معها.

كيف تقطع من غير أن ينكسر المنتج

الخطأ الشائع عند تقليص النطاق هو التقليص الأفقي: تبقي كل الشاشات وتنفّذ نصف كل واحدة. النتيجة منتج يبدو كاملاً في العرض التقديمي ويتوقّف في أول استخدام حقيقي.

البديل هو القطع الرأسي: اختر رحلة واحدة كاملة لنوع مستخدم واحد، ونفّذها من أولها لآخرها، واترك ما عداها.

خذ مثالاً افتراضياً لشركة توزيع أغذية في المنصورة تريد نظاماً للمندوبين. الرحلة الكاملة الواحدة: المندوب يفتح التطبيق، يرى عملاء اليوم، يسجّل طلباً عند أحدهم، يصل الطلب إلى لوحة المخزن، يؤكّده موظف المخزن. هذه سلسلة تعمل من طرفها إلى طرفها، ويمكن تشغيلها فعلياً غداً مع خمسة مندوبين. خارجها يبقى كل شيء كما هو اليوم: التحصيل نقداً بالإيصال الورقي، والمرتجعات بمكالمة، والتقارير بتصدير إكسل.

ما يميّز هذا القطع أنه يترك لك منتجاً يعمل في نطاق معلن، لا هيكلاً مثقوباً. وهو معنى المبدأ المكتوب في مبادئ بيان أجايل: «البساطة — فن تعظيم كمية العمل غير المُنجَز — جوهرية»، وإلى جانبه مبدأ آخر يستحق أن يُقرأ كمعيار قبول: البرنامج العامل هو المقياس الأساسي للتقدّم.

شرطان يجعلان هذا القطع ناجحاً:

1. أن تُعلن حدود النطاق للمستخدم. «الدفع نقداً عند الاستلام» مكتوبة بوضوح ليست نقصاً؛ الدفع الإلكتروني المعطّل بلا تفسير هو النقص.
2. أن يكون لكل حافة مخرج. زر «تواصل معنا» أو رقم واتساب في كل موضع قد يحتاجه المستخدم لشيء خارج النطاق. هذا الزر نفسه سيصير أفضل مصدر لمعرفة ما يجب بناؤه بعد ذلك.

متى تعرف أنك جاهز للتوسعة

بعد الإطلاق يبدأ سؤال مختلف عن الأساس الذي تُبنى عليه الموجة الثانية. الإجابة السهلة والخاطئة هي «لمّا يبقى عندنا وقت وفلوس».

كاجان يضع الشرط بوضوح: لا يكفي أن تظن أنك وصلت لملاءمة المنتج للسوق، وهذا ما يفعله أغلب أصحاب المنتجات حين يقدّمون رأيهم؛ أنت تحتاج دليلاً. والدليل هنا عملي لا شعوري.

الاستخدام المتكرّر من المستخدم نفسه. الرقم الذي يعنيك هو كم شخصاً عاد في الأسبوع التالي، لا عدد التحميلات ولا عدد التسجيلات. العودة هي الشيء الوحيد الذي لا يُشترى بإعلان.

رأي المستخدمين بصيغة قابلة للقياس. شاع في هذا الباب سؤال صاغه شون إليس: كم نسبة المستخدمين النشطين الذين سيصيبهم «إحباط كبير» لو لم يعد بإمكانهم استخدام المنتج؟ اعتبر إليس 40% عتبةً لملاءمة المنتج للسوق، لكنه قال في الجملة نفسها ما لا تنقله عنه أغلب المقالات: «لا أنكر أن هذه العتبة اعتباطية بعض الشيء، لكنني حدّدتها بعد مقارنة نتائج ما يقارب خمسين شركة ناشئة». خذها كإشارة لا كقانون، وانتبه إلى أن نسبة مئوية محسوبة على 20 مستخدماً لا تعني شيئاً.

مشكلات الاستخدام التي رأيتها بعينك. تقول مجموعة نيلسن نورمان إن أول اختبار مع خمسة مشاركين يكشف نحو 85% من مشكلات قابلية الاستخدام في التصميم، وإن ثلاث جولات من خمسة أفضل من جولة واحدة من خمسة عشر، لأن الهدف إصلاح التصميم لا توثيق عيوبه. وتضيف الجملة التي تلخّص الباب كله: صفر مستخدمين يعطون صفر معلومات. خمسة عملاء حقيقيين يجرّبون أمامك أرخص وأسرع من أي نقاش داخلي عن الشاشة التالية.

قائمة الطلبات المتكرّرة. بعد شهرين من التشغيل ستجد ثلاثة أو أربعة طلبات تتكرّر من عملاء مختلفين. هذه قائمتك التالية، وقد جاءت من السوق لا من اجتماع.

إذا اجتمعت هذه الإشارات فابدأ الموجة الثانية، وأعد ترتيب ما أجّلته بالقاعدة نفسها. بعض ما كان مؤجَّلاً في الإصدار الأول صار الآن ضرورة، وبعضه لم يسأل عنه أحد طوال شهرين، وهذا في ذاته نتيجة تستحق أن تُحتسب.

وماذا لو كانت الإشارة معاكسة

احتمال قائم يستحق أن يُقال بصراحة: أن تُطلق، وتصلح، وتُطلق ثانيةً، ويظل التجاوب باهتاً. وصف ريس هذه اللحظة بأنك بعد عدد من التكرارات بلا أي إقبال قد تقول لنفسك إنك تجاوزت حدّ المنتج الأدنى، وأن هذا ببساطة ليس منتجاً قابلاً للحياة.

معرفة ذلك بعد نسخة أولى محدودة أرخص كثيراً من معرفته بعد منتج كامل. هذه هي الفائدة التي تجعل الفرز يستحق العناء من الأساس.

بعد أن يستقرّ النطاق

حين تستقرّ على ما يدخل وما يؤجَّل، تبدأ أسئلة أخرى لها إجابات مختلفة: كم تستغرق مدة التنفيذ فعلياً، وكم تكلّف برمجة التطبيق، وما خطوات البناء من الفكرة حتى المتجر، وهل تشتري نظاماً جاهزاً أصلاً بدل أن تبني. وقبل أي منها، حوّل النطاق الذي اخترته إلى مستند مكتوب تتفق عليه مع من ينفّذ؛ فالنطاق الذي لا يُكتب يتمدّد وحده أثناء التنفيذ.

طريقة عملية تساعد على تثبيت القرار: اجعل التسليم والدفع على مراحل مقابل ما يُسلَّم فعلاً، كما نعمل في سنابل. حين ترتبط كل دفعة بجزء قابل للتشغيل، يصير تأجيل الميزات قراراً تجارياً واضحاً بدل أن يكون تنازلاً غامضاً.

وإذا كنت تحدّد نطاق نظام أو منتج رقمي هذه الأيام، ابعث بقائمتك كما هي إلى فريق سنابل عبر صفحة الأنظمة المخصّصة. نقرأها معك ونرد خلال يوم عمل واحد بتصوّر لما يستحق أن يدخل النسخة الأولى، ومعه تقدير لمدته وكلفته، بلا مقابل ولا ارتباط بعده.

المصادر

كل الروابط اطُّلع عليها في 20 سبتمبر 2026.

• Minimum Viable Product: a guide، بقلم Eric Ries في Startup Lessons Learned، 3 أغسطس 2009.
• حوار Eric Ries مع Venture Hacks حول المنتج الأدنى القابل للحياة، 23 مارس 2009.
• Minimum Viable Product وViable Product vs. Minimal Product، بقلم Marty Cagan في Silicon Valley Product Group.
• MoSCoW Prioritisation ضمن إطار DSDM الصادر عن Agile Business Consortium.
• App Review Guidelines من Apple، البنود 2.1 و4.2 و4.2.2 و5.1.1.
• Functionality, Content, and User Experience ضمن سياسات Google Play.
• Principles behind the Agile Manifesto، 2001.
• Jakob Nielsen عن سبب كفاية خمسة مستخدمين في الاختبار، Nielsen Norman Group.
• The sultans of startup marketing في Venture Hacks، نوفمبر 2009، نقلاً عن كتابة Sean Ellis.
• The top reasons startups fail من CB Insights.