الدين التقني: التكلفة المؤجلة التي تتراكم بفائدة

ما هو الدين التقني، كيف يتراكم، ومتى يجب سداده قبل أن يشلّ قدرتك على التطوير.

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

علامات تراكم الدين

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

كيف تديره

• خصص نسبة ثابتة من كل دورة تطوير لسداده.
• وثّق الديون المعروفة وأولوياتها بدل تجاهلها.
• ابدأ بالأجزاء الأكثر تعديلاً لا الأسوأ كوداً.
• أضف اختبارات قبل إعادة الهيكلة لا بعدها.
• اربط السداد بأثر ملموس على سرعة التطوير.

المشروع التقني يفشل إدارياً قبل أن يفشل تقنياً

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

• اعتمد وثيقة نطاق مكتوبة قبل البدء لا بعده.
• عيّن مالك قرار واحداً بصلاحية اعتماد.
• اطلب تسليماً على دفعات قصيرة تجرّبها فعلياً.
• اتفق على آلية مسعّرة لطلبات التغيير مسبقاً.
• قِس التقدم بما يعمل لا بما اكتمل في القائمة.

أسئلة تحسم القرار قبل الإنفاق

• ما المشكلة المحددة التي أحلّها، وكم تكلفني اليوم بالساعات أو بالريالات؟
• من الشخص الذي سيستخدم هذا يومياً، وهل شاركته الرأي؟
• ما أصغر نسخة تثبت الجدوى قبل الاستثمار الكامل؟
• ما الذي سأقيسه بعد ثلاثة أشهر لأعرف أنه نجح؟
• ماذا يحدث لو لم أفعل شيئاً هذا العام؟

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

كيف نتعامل مع هذا في دوميرا

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

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

خطة تطبيق عملية

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

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

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