المنتج الأولي القابل للتطبيق MVP

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

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

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

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

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