المال الذي صرفته على برنامج فاشل ضاع، مهما كان قرارك القادم. فلا يمكن أن يكون سببًا لمواصلة الدفع.
السؤال الوحيد المتبقّي هو ماذا ستشتري الدفعة القادمة. أعطِ الكود الحالي أسبوعين: إذا استطاع زبون حقيقي إتمام العملية الأساسية، فأصلحه. وإلّا فأعد بناء نسخة صغيرة.
يشرح هذا الدليل لماذا يواصل أصحاب المشاريع الدفع لكود ميّت، ويعطيك اختبار الأسبوعين. ويبيّن أيضًا شكل إعادة البناء الصغيرة، وما يجب تأمينه قبل أن تقرّر.
كيف يبدو فخّ التكلفة الغارقة في البرمجيات؟
تخيّل حالة شائعة. صاحب مشروع دفع لوكالة لأكثر من سنة. التطبيق يتعطّل عند تسجيل الدخول، والدفع لا يعمل، ولم يستعمله أيّ زبون حقيقي.
طلبه: "دفعنا الكثير أصلًا، نحتاج فقط من يُكمله."
هو لا يحتاج من يُكمله. يحتاج من يقول له إنّ المال ضاع سواء واصل أم لا، وإنّ السؤال الوحيد هو ماذا ستشتري الدفعة القادمة.
مثل البقاء في قاعة السينما لمشاهدة فيلم سيّئ لأنّك دفعت التذكرة. التذكرة مصروفة في الحالتين. الخيار الوحيد هو هل تصرف أيضًا الساعتين القادمتين.
ما هي مغالطة التكلفة الغارقة؟
مغالطة التكلفة الغارقة هي مواصلة الاستثمار في شيء بسبب ما صرفته عليه. والسؤال الصحيح هو ما سيعيده من الآن.
إنّها من أكثر الانحيازات توثيقًا في الاقتصاد السلوكي. سنة 1985، أظهرها Hal Arkes وCatherine Blumer بتذاكر المسرح. من دفعوا السعر الكامل لاشتراك الموسم حضروا مسرحيات أكثر ممّن حصلوا على تخفيض عشوائي، رغم أنّ الطرفين دفعا مسبقًا (Arkes وBlumer، 1985).
وتحتها يقبع النفور من الخسارة: الخسارة تؤلم نحو ضعف ما تُفرح ربحٌ مساوٍ لها (Tversky وKahneman، 1992). شطب مشروع فاشل لا يبدو قيدًا محاسبيًا، بل خسارة شخصية، ودليلًا على أنّك اخترت الوكالة الخطأ.
فيحمي صاحب المشروع كبرياءه بدل ماله. ويسمّي الدفعة القادمة "إكمالًا" لأنّها تبدو استرجاعًا. وفي الحقيقة هي نفس الرهان من جديد، بمال أقلّ في البنك.
أغلى كود في أيّ مشروع ناشئ هو الكود المكتوب لتبرير خطأ سابق.
ما علامات مشروع برمجي ميّت؟
- دفعات شهرية دون ميزة مُسلَّمة. المال مربوط بالوقت، لا بشيء يعمل أمام مستخدمين حقيقيين.
- تصميم جميل وواجهة خلفية فارغة. النماذج تبدو جاهزة، فيظنّ صاحب المشروع أنّ المنتج شبه منتهٍ. وقاعدة البيانات فيها ثلاثة جداول بلا قواعد أمان.
- إعادة كتابة حدثت مرّة. الوكالة غيّرت التقنية في المنتصف، فنصف الميزانية دُفع لكود لم يعد موجودًا.
- لا أحد في جهة صاحب المشروع يقرأ الكود. كل تحديث وعد، لا رابط.
لا شيء من هذا يعني أنّ صاحب المشروع ساذج. كان يشتري الجهد بينما كان يجب أن يشتري الدليل.
هل تصلح البرنامج أم تعيد بناءه؟
لإعادة الكتابة سمعة سيّئة، وجزء منها مستحقّ. مقال Joel Spolsky الشهير عن Netscape يحذّر من أنّ رمي كود يعمل يرمي معه سنوات من الأخطاء المصلَحة والدروس (Spolsky، 2000). إذا كان برنامجك يعمل وله مستخدمون وصار فقط فوضويًا، فأصلحه قطعة قطعة.
لكنّ هذا التحذير يفترض أنّ الكود يعمل. مشروع بلا مستخدمين لم يتعلّم شيئًا. لا يوجد ما يُحفظ سوى الفاتورة.
فاستعمل قاعدة بسيطة. أعطِ مهندسًا متمرّسًا أسبوعين مع الكود، وسؤالًا واحدًا يجيب عنه.
هل يستطيع زبون حقيقي إتمام العملية الأساسية، من أوّلها إلى آخرها، في الإنتاج، مع نهاية هذين الأسبوعين؟
| ما تراه بعد أسبوعين | ماذا يعني | القرار |
|---|---|---|
| العملية الأساسية تعمل، والكود فوضوي | الأصل حقيقي، والجودة لا | أصلح في مكانه |
| العملية الأساسية تكاد تعمل، وجزء واحد معطوب | البنية سليمة، وجزء واحد ليس كذلك | استبدل ذلك الجزء فقط |
| لا شيء يعمل كاملًا، ونموذج البيانات خاطئ | لا يوجد أصل، بل إنفاق فقط | أعد بناء نسخة صغيرة |
| لا أحد يستطيع حتى نشره | الوكالة كانت الطريقة الوحيدة لتشغيله | أعد بناء نسخة صغيرة، وامتلك استضافتك |
الأسبوعان يكلّفان شيئًا. لكنّهما أرخص معلومة ستشتريها هذه السنة.
كيف تبدو إعادة بناء سريعة وصغيرة؟
يجب أن تكون إعادة البناء صغيرة بما يكفي حتى لا تصبح التكلفة الغارقة التالية. قاعدتي: ثلاث شاشات، وقاعدة بيانات واحدة، وطريقة دفع واحدة.
| الجزء | ماذا يعني |
|---|---|
| ثلاث شاشات | ما هو المنتج، ماذا تبيع، والفعل المطلوب. إذا احتجت أكثر لتثبت أنّ أحدًا سيدفع، فالنطاق يخفي قرارًا لم تتّخذه |
| قاعدة بيانات واحدة | Postgres مُدارة مثل Supabase، بقواعد وصول من اليوم الأول لتبقى الصلاحيات داخل قاعدة البيانات |
| طريقة دفع واحدة | في الجزائر، الدفع عند الاستلام أوّلًا. والدفع بالبطاقة عبر مزوّد مثل Chargily يأتي لاحقًا، حين تُثبت الطلبات الحاجة |
أشرح منطق التكاليف كاملًا في معادلة الـ 50.000 دج، ولماذا الخفّة ليست كسلًا في منتج صالح بحدّه الأدنى، لا جهد بحدّه الأدنى.
إعادة بناء كهذه تُطلَق في أسابيع، لا في فصول. وتُطلق شيئًا يستطيع الزبون استعماله، وهو الشيء الوحيد الذي يخبرك إن كان صرف المزيد يستحق.
لماذا فخّ التكلفة الغارقة أشدّ في الجزائر؟
المال غالبًا مال العائلة. شطبه ليس خسارة مالية فقط، بل حديث على مائدة العشاء، فتصبح تكلفة الكبرياء أكبر من الرقم.
استرجاع المال صعب. النزاع حول تطبيق غير مكتمل نادرًا ما ينتهي باسترداد، فيبدو "الإكمال" الطريقة الوحيدة لاسترجاع شيء.
الكود غالبًا ليس ملك صاحب المشروع. كثيرون لم يستلموا مستودع الكود، ولا كلمات سرّ الخادم، ولا حسابات المتاجر. قبل أيّ قرار، المهمّة الأولى هي الملكية: الكود المصدري، والنطاق، والاستضافة، وقاعدة البيانات، وحسابات Play Store وApp Store، كلّها باسمك.
ما الأخطاء الشائعة مع مشروع برمجي فاشل؟
- دفع الفاتورة القادمة "للإكمال" دون اختبار. أجرِ اختبار الأسبوعين أوّلًا.
- خلط سؤالين. "هل كان هذا خطأ؟" سؤال عن الماضي. "ماذا ستشتري الدفعة القادمة؟" سؤال عن المستقبل. والثاني وحده له حقّ التصويت.
- قبول تقارير التقدّم بدل الروابط. كل دفعة يجب أن ترتبط بشيء تفتحه على هاتفك.
- إعادة بناء نفس الخطّة الكبيرة. إعادة بناء بأربع عشرة شاشة هي التكلفة الغارقة التالية.
- القرار قبل امتلاك الكود والحسابات. لا تستطيع إصلاح ما لا تتحكّم فيه.
ماذا تفعل هذا الأسبوع؟
- اليوم: اكتب كل ما لا تملكه بعد: الكود، والاستضافة، والنطاق، وقاعدة البيانات، وحسابات المتاجر. واطلبها كلّها كتابيًا.
- هذا الأسبوع: اطلب من مهندس مستقلّ إجراء اختبار الأسبوعين.
- من الآن: اربط كل دفعة بميزة تعمل وتستطيع فتحها بنفسك.
- إذا كان الجواب إعادة البناء: قلّص إلى ثلاث شاشات وارفض كل ميزة لا تساعد غريبًا على الدفع لك.
- بعدها: دع الطلبات الحقيقية تقرّر ما تبنيه.
لماذا تنتهي المشاريع المكلفة هنا أصلًا؟ أشرح ذلك في لماذا تموت التطبيقات المكلفة قبل إطلاقها.