نظامنا القديم عمره 12 سنة ويحتاج تجديدًا — نجدده تدريجيًا أم من الصفر؟

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

عند التخطيط لانتقال تدريجي، هذا هو المسار الذي يجب اتباعه: 1) ارسم خريطة العلاقات في قاعدة البيانات القديمة وحدد المجالات المستقلة، 2) ضع موجّهًا أمام النظام لإدارة الحركة، 3) انقل أولًا الخدمات غير الحرجة المعتمدة على القراءة، 4) اترك التدفقات الرئيسية مثل الطلبات والدفع للخطوة الأخيرة.

في تجربتي الاستشارية، 4 من 5 أنظمة مؤسسية كُتبت من الصفر تجاوزت موعد التسليم الموعود بـ6 أشهر على الأقل. في المقابل، بقيت انحرافات الميزانية في الأنظمة المحوّلة تدريجيًا عند مستوى متوسط، ولم يشهد أي منها انقطاعًا حرجًا في الطلبات. اقتراح مطوّرك يقدّم أرضية أكثر واقعية بكثير.

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

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

الوكالة اللي بتدّعي إنها رح تعيد كتابة نظام ERP معقد عمره 12 سنة كامل خلال 8 أشهر، يعني لسا ما شافت خصومات العملاء الخاصة وقواعد المحاسبة غير الموثقة داخل النظام؛ ويوم الانتقال للحيّ رح تتفرج كيف الـ 8 أشهر صارت 20 شهر.

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

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

لدي رأي مختلف. إذا لم تُكتب معايير القبول، فإن وقت انتهاء العمل يبقى مفتوحاً للنقاش.

المسألة ليست الرقم، بل الأساس الذي بُني عليه. اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

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

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

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

انظروا أولاً إلى البيانات المتاحة لديكم عند اتخاذ القرار. اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

لدي سؤال، ولا أريد الخروج عن صلب الموضوع. إذا لم ينص العقد على ملكية الكود، تفقد قوتك التفاوضية عند المغادرة.

محاولة فعل هذا بمفردك هي أغلى الطرق. إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

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

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

لدي رأي مختلف. تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط. مثبت بالتجربة.

وكيف حللتم هذه النقطة؟ عندما تحاول تغيير كل شيء دفعة واحدة، لا يستقر أي شيء.

هذا كل شيء، أرجو المعذرة إذا أطالت.

تشتت النقاش، دعني ألخصه. القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

دعني أتركها كملاحظة، قد تكون مفيدة.

تم الحفظ.