# إثبات المفهوم خلال أسبوعين: ما الذي تختبره؟ | ThorOps

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


إثبات المفهوم الجيد ليس نسخة مصغّرة من المنتج. إنه تجربة تجيب عن سؤال واحد مكلف قبل أن تلتزم بميزانية حقيقية.


## ابدأ بالسؤال، لا بقائمة المزايا


قبل أي سطر كود، اكتب الشيء الوحيد الذي سيجعلك توقف المشروع لو كان جوابه «لا». وغالبًا ما يكون واحدًا من هذه:



- هل يمكن تنفيذه؟ التكامل، أو البيانات، أو الأداء، أو الجهاز الذي تعتمد عليه، يتصرّف فعلًا كما تفترض.

- هل سيستخدمه الناس؟ مسار العمل يناسب كيف يعمل فريقك أو عملاؤك حقًا، لا كما تقول شريحة في عرض.

- هل يستحق؟ تكلفة بنائه وتشغيله ضمن النطاق الذي تحتاجه دراسة الجدوى.



إن لم تستطع تسمية السؤال، فأنت لست جاهزًا لإثبات مفهوم. أنت جاهز لجلسة استكشاف.


## ابنِ الجزء الأخطر أولًا، ولا شيء غيره


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


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


## قرّر مسبقًا كيف تبدو «نعم»


اكتب معايير النجاح في اليوم الأول، وبالأرقام حيث أمكن:



- يُولَّد التقرير في أقل من خمس ثوانٍ لبيانات سنة كاملة.

- خمسة أشخاص من الفريق الحقيقي ينجزون المهمة الأساسية دون مساعدة.

- التكلفة السحابية الشهرية للحمل المتوقّع تبقى تحت ميزانية محدّدة.



في النهاية، يُقاس العرض على تلك القائمة، لا على مدى إبهاره.


## ما الذي يجب أن يكون بين يديك بعد أسبوعين



- عرض يعمل للجزء الأخطر، على بيانات حقيقية أو واقعية.

- جواب واضح عن السؤال الذي بدأت به.

- خطة قصيرة لما يلي: ابنِه، أو غيّر الاتجاه، أو توقّف.



التوقّف بعد أسبوعين نتيجة جيدة. قد يجنّبك خطأً أعلى تكلفة بكثير.


هذه هي الفكرة كلها. تنفق القليل لتتجنّب إنفاق الكثير على الشيء الخطأ.