تطوير برمجيات MVP: النطاق والتكلفة والجدول الزمني

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

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

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

ما الغرض الحقيقي من تطوير برمجيات MVP

يوجد المنتج الأولي للإجابة عن سؤال واحد بمستخدمين حقيقيين بدلًا من الآراء. وعادةً يكون السؤال: هل سيدفع أحد مقابل هذا، أو هل سيستخدمه أحد بتكرار كافٍ ليصبح ذا قيمة؟

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

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

ما الذي يدخل وما الذي ينتظر

يدخل: مسار القيمة الأساسي، والحد الأدنى من المصادقة الذي يتطلبه هذا المسار، ووسيلة لتحصيل المدفوعات إذا كان السؤال هو هل سيدفع الناس، وقياسات كافية لرؤية ما يفعله المستخدمون فعلًا.

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

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

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

تكاليف واقعية في المملكة المتحدة

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

التنفيذ الخارجي بسعر £100 أو £200 لليوم يغيّر هذه الحسبة ويجلب معه تكلفة التنسيق التي نتناولها في تعهيد تطوير البرمجيات . ويشرح تفصيل تكلفة تطوير البرمجيات المخصصة ما الذي يدفع كل شريحة إلى أعلى.

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

الخطأ الذي يحوّل ثلاثة أشهر إلى تسعة

البناء لحجم لا تملكه بعد.

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

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

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

كيف تحدد النطاق في فترة بعد الظهر

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

ثم اقتطع ثلث القائمة على أي حال. كل فريق يبالغ في النطاق من المحاولة الأولى، والثلث الذي تحذفه الآن هو تقريبًا الثلث نفسه الذي كنت ستحذفه بعد الإطلاق.

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

تحدد Mecanik نطاق المنتجات الأولية وتبنيها عبر فريق تطوير البرمجيات لدينا، بما في ذلك الجزء الذي يقنعك فيه أحدهم بالتخلي عن لوحة الإدارة. وإذا كانت لديك قائمة مزايا بلا تاريخ، فهذا هو المكان الذي تبدأ منه.

تدوينات ذات صلة: تطوير البرمجيات المخصصة في المملكة المتحدة - دليل المشترين ، تطوير برمجيات التقنية المالية في المملكة المتحدة: FCA وrails والتكلفة ، كيفية بناء تطبيق ويب في 2026 - دليل المطور البريطاني ، تطوير الويب بالعلامة البيضاء للوكالات .

الأسئلة الشائعة

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

كم تبلغ تكلفة تطوير برمجيات MVP في المملكة المتحدة؟ تطبيق ويب بمسار واحد ونوع مستخدم واحد يكلّف عادةً £15,000 إلى £35,000 خلال ستة إلى عشرة أسابيع. ونوعان من المستخدمين مع الدفع والإدارة الأساسية يكلّفان £35,000 إلى £75,000 خلال ثلاثة إلى خمسة أشهر. أما المنتجات متعددة الأطراف ذات التكاملات أو متطلبات الالتزام التنظيمي فتبدأ من نحو £75,000 وتستغرق خمسة أشهر أو أكثر.

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

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

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