البناء اللانهائي
هنا محادثة نُجريها مع المؤسّسين كل أسبوع.
"نحن نبني منذ حوالي سنة." "كم مستخدم لديكم؟" "لا أحد بعد. نحن تقريباً جاهزون للإطلاق."
سنة من التطوير. صفر مستخدم. ويعتقدون فعلاً أنّهم يبنون MVP.
ليس كذلك. هم محبوسون في دورة البناء اللانهائية. وحتى يخبرهم أحد بما يحدث، سيستمرّون في البناء.
كيف تبدأ
الدورة دائماً تبدأ بنفس الطريقة. مؤسّس لديه بصيرة مشروعة عن مشكلة حقيقية. يرسم منتجاً. الرسم لديه ربّما 5 ميزات أساسية.
ثم يبدؤون البناء. والميزة الأولى تُولِّد 3 ميزات فرعية. كل ميزة فرعية لها حالة حدّية. كل حالة حدّية تحتاج قرار تصميم. كل قرار تصميم يطرح سؤالاً جديداً عن المنتج.
بعد 3 أشهر، المنتج بـ5 ميزات لديه 40 ميزة. بعد 6 أشهر، لديه 80. المؤسّس لم يشحن شيئاً، لكنّه مستثمر بشكل مفرط لتقليص النطاق. كل ميزة تبدو أساسية. إزالة أيّ شيء تبدو فشلاً.
هذه جاذبية النطاق. كلّما طال البناء دون شحن، أصعب الشحن.
الـMVP ليس أصغر نسخة من منتجكم النهائي. هو أصغر شيء يمكنكم وضعه أمام المستخدمين لاختبار ما إذا كان افتراضكم الأساسي صحيحاً.
كيف يبدو MVP حقيقي
كلمة "الأدنى" في MVP تعني شيئاً. تعني عدم ارتياح متعمَّد. تعني شحن شيء يبدو غير مكتمل. تعني اختيار مستخدم واحد، مشكلة واحدة، حلّ واحد، وتجاهل كل شيء آخر.
MVP حقيقي لسوق قد يكون جدول بيانات ومجموعة WhatsApp. MVP حقيقي لأداة SaaS قد يكون 3 شاشات وعملية يدوية خلف الكواليس. MVP حقيقي لمنصّة حجز قد يكون نموذجاً بصفحة واحدة يرسل لكم بريداً عند حجز شخص ما.
لا أحد منها يبدو منتجات. هذه هي النقطة. هي اختبارات.
الهدف ليس إبهار المستخدمين بالصقل. الهدف معرفة ما إذا كانت قيمة العرض الأساسية تعمل. هل يريد أحد هذا فعلاً؟ هل سيستخدمونه؟ هل سيدفعون مقابله؟
لا يمكنكم الإجابة على هذه الأسئلة بـ80 ميزة وصفر مستخدم.
كلفة البناء اللانهائي
نتتبّع هذا لأنّنا نراه كثيراً. هنا ما تكلّفه دورة البناء اللانهائية عادةً لشركة ناشئة:
الوقت: 12 إلى 24 شهراً من التطوير قبل أي ملاحظات مستخدم. عند الشحن، يكون السوق قد تحرّك، افتراضاتهم قديمة، ومخزونهم قصير.
المال: 60,000 إلى 200,000 دولار أُنفقت على بناء ميزات قد لا تُتحقَّق أبداً. إذا كان الافتراض الأساسي خاطئاً، كلّها مهدورة.
المعنويات: الفريق منهك. المؤسّس "تقريباً جاهز للإطلاق" منذ 6 أشهر. كل أسبوع، يجد أحدهم شيئاً آخر يحتاج العمل عليه قبل الإطلاق. الطاقة التي يجب أن تذهب إلى الاكتساب والنمو تذهب إلى الصقل والحالات الحدّية.
كلفة الفرصة الضائعة: أكبر كلفة غير مرئية. بينما كانت الشركة الناشئة تبني، لم تكن تتحدّث للمستخدمين. لم تكن تكرّر. لم تكن تتعلّم. المعلومات التي كانت ستُنقذ المنتج كانت متاحة قبل 12 شهراً، لكن لا أحد ذهب يبحث عنها.
لماذا يحدث
ثلاثة أسباب.
الخوف من الظهور غير منتهٍ. المؤسّسون يخافون من أن شحن شيء غير مكتمل سيؤذي سمعتهم. العكس صحيح. الشحن مبكراً والتكرار يبني الثقة. المستخدمون يحترمون المؤسّسين الذين يصغون ويُحسِّنون.
لا تعريف واضح للـ"منجَز". بدون عملية منظَّمة تحدّد النطاق قبل بدء البناء، كل فكرة جديدة تُضاف إلى الـbacklog. والـbacklog يصبح المنتج.
المطوّر يقول نعم لكل شيء. حين يبني الشخص أو الفريق نفسه ويحدّد نطاق المنتج، لا احتكاك. كل ميزة تُبنى لأن لا أحد عمله أن يقول "ليس بعد." التصميم الجيد للمنتج يُدخل احتكاكاً. يفرض ترتيب الأولويات. يجعل المؤسّس يختار.
السبرنت يُجبر المؤسّس على تعريف MVP في 30 يوماً. ليس بسؤال "ماذا تريدون؟" بل بسؤال "ماذا يحتاج المستخدم، وما الحدّ الأدنى الذي يمكنكم بناؤه لإثباته؟"
الحلّ في 30 يوماً
سبرنت UI/UX مصمَّم خصيصاً لكسر دورة البناء اللانهائية. في 30 يوماً، نحن:
- نرسم مشكلة المستخدم الفعلية (لا افتراض المؤسّس عنها)
- نحدّد المسار الحرج عبر المنتج (التدفّق الواحد المهمّ عند الإطلاق)
- نصمّم ذلك المسار فقط بدقّة عالية
- نختبره مع مستخدمين حقيقيين
- نسلّمه للهندسة بصفر غموض
النتيجة نموذج يمثّل MVP الحقيقي. لا قائمة أمنيات المؤسّس. لا خارطة طريق ميزات. الشيء الذي يجب أن يكون موجوداً في اليوم الأول ولا شيء آخر.
عند شحن ذلك واستخدام المستخدمين له، يكون لدى المؤسّس بيانات حقيقية. يمكنهم رؤية ما يعمل، ما ينقص، وماذا يبنون لاحقاً. يتّخذون قرارات مبنيّة على دليل، لا افتراضات.
كيف تعرفون أنّكم في الدورة
اسألوا أنفسكم هذه الأسئلة:
- هل تبنون منذ أكثر من 3 أشهر دون إظهار أي شيء لمستخدم حقيقي؟
- هل قائمة الميزات لديكم أطول الآن مما كانت حين بدأتم؟
- هل تشعرون بأنّكم "تقريباً جاهزون" لكن شعرتم بذلك لأشهر؟
- هل تضيفون ميزات لتأخير عدم ارتياح الإطلاق؟
إذا قلتم نعم لاثنين أو أكثر، أنتم في الدورة. الخروج ليس بالبناء أكثر. هو التوقّف، تعريف MVP الحقيقي، وشحنه قبل أن ينفد المخزون.