تطوير المنتج الأولي

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

كيف نعرّف المنتج الأولي

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

كيف نبني منتجا أوليا

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

قص النطاق: أن تقرروا ما لن ينفذ

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

تصميم التحقق: أي سؤال وأي قياس

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

تواصل مستمر وشفافية عبر بيئة ما قبل الإنتاج

نبقى على تواصل مستمر مع العميل طوال المشروع، ويشارَك التقدم في أغلب الأيام التي يمكن فيها ذلك. ونقيم في بداية المشروع بيئة تشبه النظام الحي إلى حد بعيد لكنها لم تُفتح بعد للمستخدمين الحقيقيين، وهذه هي بيئة ما قبل الإنتاج؛ والتغييرات التي تدخل عليها يمكن متابعتها غالبا لحظيا تقريبا. فدليل التقدم ليس لقطة شاشة بل برنامج عامل على عنوان حقيقي، والذي يجعل ذلك ممكنا خط نشر يقام منذ البداية. ففي مشاريع Lextum AI وBiletico وAnneekspres وWorld Summer Schools أقيمت أتمتة التكامل والنشر المستمر عبر أداة Jenkins في كل واحد منها. ولا بد أن يكف النشر عن كونه حدثا حتى تثبت هذه الشفافية.

الفرق بين عرض المستثمر واختبار المستخدم الحقيقي

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

الانتقال من المنتج الأولي إلى التشغيل وقرار الدين التقني

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

الحالات التي يكون فيها المنتج الأولي جوابا خاطئا

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

حزمة تسليم المشروع

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

كيف تحمى الميزانية ويحمى النطاق

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

نطاق القياس لدينا

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

معايير اختيار التقنية لدينا

المنتج الأولي مكان سيئ لتعلم تقنية جديدة، ولذلك يجرى الاختيار من مجموعة ضيقة: أدوات نشغلها فعلا في الإنتاج ويستطيع غيرنا أن يواصل بها بعد التسليم. فحين يغلب تعقيد العمليات وبنية الأدوار والتكامل المؤسسي تكون الخلفية على إطار .NET، كما في مشاريع Lextum AI وWorld Summer Schools وWelldone عندنا. وحين يقع ثقل العمل في نموذج البيانات وشاشات الإدارة تصل لغة Python مع إطار Django إلى النتيجة أسرع، وبهذا بني سوق Anneekspres الإلكتروني. وتحمل الواجهة مكتبتا React وNext.js، ونلجأ إلى Flutter أو React Native حين تلزم قاعدة كود واحدة تصل إلى موظفي الميدان على نظامي iOS وAndroid معا. وثلاثة معايير تحكم الاختيار: من سيتولى الصيانة بعد التسليم، وهل يوجد في السوق من يتقن هذه التقنية، وهل يمكن أن تبقى الاستضافة على حساباتكم.

كيف يبدو هذا على أرض الواقع

الأعمال المذكورة أدناه إما منشورة وإما منجزة، ولكل مشروع منها صفحته الخاصة في قسم قصص النجاح.

• Lextum AI: إنتاج الوثائق ومراجعة العقود والتحرير المتزامن وإدارة النسخ لفرق القانون. نقل إلى التشغيل ببنية خدمات مصغرة مع RabbitMQ ووصول حسب الأدوار ومسار تدقيق كامل.
• Biletico: منصة كان أساسها قائما ولا تكاد ميزة فيها تعمل، فاستلمناها وأعملنا الدفع والبحث والملف الشخصي وإدارة التذاكر، وأضفنا خطة جلوس مبنية على canvas أي لوحة رسم تفاعلية.
• World Summer Schools: مئات برامج المدارس الصيفية جمعت في كتالوج واحد قابل للبحث، وأسرع إدخال المحتوى بتكامل مع OpenAI، وضبط الوصول حسب الأدوار.
• Anneekspres: سوق إلكتروني لمنتجات الأم والطفل بني من الصفر: لوحة البائع، ومسار الدفع والطلبات، وبنية تقوم على قاعدة PostgreSQL وعلى طابور رسائل RabbitMQ يفصل العمليات الثقيلة.
• BiTalih: منصة إنتاج محتوى قائمة على قوالب ثابتة وحقول متغيرة، ومع الوصول حسب الأدوار نزل زمن إنتاج المحتوى من ساعات إلى دقائق.
• Welldone: تطبيق جوال على Flutter ولوحة إدارة على React وخدمات على .NET لعمليات مغسلة صناعية، مع تغليف بمسح رمز QR في الميدان وتقارير لحظية للمديرين.
• Terazzi: عمل على منصة قائمة شمل تحسينات التصميم ولوحة العميل والظهور في محركات البحث وأداء الخلفية.