تطوير MVP مبني ليصمد أمام النجاح.

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

ما ليس هو

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

وما هو

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

كل قرار في MVP يجيب عن السؤال نفسه: ما الذي نحتاج تعلّمه بعد ذلك، وما أصغر شيء حقيقي يعلّمنا إياه.

هناك طريقتان لجعل البناء أصغر. الأولى أن تفعل أشياء أقل. والثانية أن تفعل الأشياء نفسها بجودة أسوأ. الأولى وحدها تنجح، والفرق بينهما هو كل حرفة بناء MVP.

قلّص بلا تردد

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

ولا تقلّص

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

والحدّ بسيط بما يكفي لتطبيقه في اجتماع. قلّص ما هو غالي البناء الآن ورخيص الإضافة لاحقًا. وأبقِ ما هو رخيص الآن وغالي الإصلاح.

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

الترتيب الذي نتبعه

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

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

الـ MVP موجود لينتج أدلة، والدليل يحتاج شخصًا حقيقيًا على الطرف الآخر. فعشرة مستخدمين جاؤوا من مكان ما وفعلوا شيئًا أثمن من مئة حساب تجريبي واجتماع جيد.

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

والخطة تترك وقتًا لذلك. فالـ MVP الذي ينفق ميزانيته كلها قبل الإطلاق يكون قد اشترى برنامجًا وتخطّى الجزء الذي كان يُفترض أن يجعله ذا قيمة.

Dextra منتجنا نحن — صمّمناه وبنيناه ونشغّله. وهو المرجع الصادق لطريقتنا في العمل، بدل حكاية عن مشروع شخص آخر.

• تطبيق ويب للتدريب الرياضي، يعمل على dextra.tn، بالعربية والفرنسية والإنجليزية — ما يجعل التخطيط من اليمين إلى اليسار حالة من الدرجة الأولى لا فكرة لاحقة.
• مستخدمون حقيقيون، ومدربون معتمدون يقدّمون برامج من خلاله.
• مدفوعات حقيقية عبر Flouci وD17، وهما المزوّدان اللذان يستعملهما الناس في تونس فعلًا، بما في ذلك أعمال المطابقة وإعادة المحاولة والدعم التي تصل مع المال.
• تطبيقان أصليان للجوّال أُرسلا إلى App Store وGoogle Play، وهما قيد المراجعة حاليًا وغير منشورين للعموم بعد.

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

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

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

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

وهذه سلسلة زيادات مقصودة على الشيفرة نفسها. وإن تعذّر فعلها إلا بإعادة كتابة، فقد بُني الـ MVP خطأً — وهذا موضوع القسمين التاليين.

يُفترض في الـ MVP أن يحمل دَينًا. فالدَّين قرض مقابل السرعة، والسرعة هي كل الغرض من MVP. والمهم أي القروض يمكن سداده وأيها لا يمكن.

مقبول في هذه المرحلة

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

غير مقبول في أي مرحلة

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

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

نادرًا ما يكون إطار العمل سبب إعادة الكتابة. السبب نظام لم يعد أحد يستطيع تغييره بأمان، والأسباب متكررة بما يكفي لتُسرَد.

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

وما يمنع ذلك

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

والسؤال الذي يحسم أكثر من كل ما سبق: من يملكه. المستودع وحسابات البنية التحتية والنطاقات لك منذ أول commit. وإن واصلت معنا فينبغي أن يكون ذلك لأن العمل جيد.

يبدأ الـ MVP بمحادثة لتحديد النطاق، لا بقالب عرض. أخبرنا بالمستخدم، وبالمهمة، وبالافتراض الذي يقلقك، وتعود إليك بنطاق وخطة مراحل وتقدير تستطيع مجادلته.

• نطاق مكتوب قبل البناء. والتغيير قرار له تقديره الخاص، لا إضافة صامتة.
• دورات من أسبوعين مع عرض في نهاية كل دورة، فتوجّه المشروع ببرنامج يعمل.
• تطوير قريب (nearshore) من تونس على UTC+1: يوم عمل أوروبي كامل يتداخل مع يومك. نعمل بالإنجليزية والفرنسية والعربية.
• الدعم يستمر بعد الإطلاق، لأن الأسابيع التالية للإصدار تنتج التغذية الراجعة التي كانت الغاية من الأمر كله.

نطاقات الميزانية لتطبيق أو منتج أولي، وما الذي يحرّكها، منشورة في ما التكلفة. أما كيف يجري العمل فعلًا — تحديد النطاق والدورات والتسليم — ففي كيف نعمل.