اتصل بنا العميل ظهر أحد أيام الثلاثاء. نظام إدارة الطلبات لديه تعطّل للمرة الثالثة ذلك الأسبوع. كل انقطاع استمر بين ساعتين وأربع ساعات، وكل ساعة توقف كلّفتهم ما يقارب €12,500 في الطلبات المفقودة والموظفين المعطلين. استخدموا هذا النظام 15 عاماً. شركة التطوير الأصلية انحلّت. المطوّر الوحيد الذي كان لا يزال يفهم قاعدة الكود تقاعد قبل 18 شهراً. كانوا في حاجة ماسة إلى مسار للمضي قدماً، وبسرعة.
أخبرناهم بـ 90 يوماً لاستبدال كامل. ظنّوا أننا إما واثقون جداً أو مخطئون تماماً. إليك رواية صادقة لكيفية سير ذلك المشروع فعلاً.
ما وجدناه خلال أسبوع التقييم
قبل الالتزام بأي جدول زمني، أمضينا أسبوعاً مدمجين مع فريقهم — جلسنا مع موظفي المستودع خلال وردية الصباح، وراقبنا فريق المبيعات يتعامل مع الواجهة، وسحبنا مخطط قاعدة البيانات الفعلي وسجلات الخادم.
الصورة التقنية كانت أسوأ مما أشار إليه الموجز الأولي:
- خادم Windows Server 2008 يشغّل تطبيق ASP.NET WebForms بدون أي سجل للتحكم بالإصدار
- قاعدة بيانات SQL Server 2008 تضم 847 إجراءً مخزناً، كثير منها غير موثق
- متوسط وقت تحميل الصفحة من 5 إلى 8 دقائق لشاشة إدخال الطلب الرئيسية
- لا إمكانية وصول من الجوال — النظام كله يتطلب Internet Explorer 11 في الموقع
- أكثر من 8 ساعات من التوقف غير المخطط شهرياً خلال الربع السابق
- عقد صيانة سنوي بـ €185,000 سنوياً مع مورّد لا يفعل أكثر من إبقاء الخادم حياً
الصورة البشرية كانت بنفس القدر من الأهمية. طوّر فريق المستودع حلولاً بديلة: أوراق احتياطية ورقية، جدول بيانات شخصي أحد المشرفين يحتفظ به على هاتفه، مجموعة WhatsApp يُعلن فيها عن تغييرات الطلبات. لم يكن النظام بطيئاً فحسب — بل توقفوا عن الوثوق به.
قرار الهندسة المعمارية
كان هناك مساران واقعيان: تحديث تدريجي لقاعدة الكود الموجودة، أو إعادة بناء كاملة على حزمة تقنية حديثة مع تشغيل متوازٍ حتى التحويل. أوصينا بإعادة البناء، وكان منطقنا واضحاً.
قاعدة الكود الموجودة لم تكن تحتوي على اختبارات ولا توثيقاً ولا أحداً يفهم تبعيات الإجراءات المخزنة بالكامل. تعديلها تدريجياً يعني العمل في الظلام. كان خطر كسر شيء حرج أثناء محاولة تحسينه مرتفعاً. إعادة البناء الموازية سمحت لنا بتحديد النطاق بوضوح، والاختبار مقابل الاستخدام الفعلي، والتحويل في تاريخ نتحكم فيه.
الحزمة التقنية التي اخترناها:
- الواجهة الأمامية: Vue.js 3 مع TypeScript — سريع التطوير، سهل الصيانة من قبل فريقهم، دعم ممتاز للجوال منذ البداية
- الخلفية: .NET Core 8 Web API — الفريق لديه خبرة .NET، والتحسن في الأداء من WebForms إلى Core كان جذرياً
- قاعدة البيانات: SQL Server على Azure SQL — تعقيد هجرة بيانات أدنى، مخطط مألوف، نسخ احتياطية مُدارة وتعافٍ تلقائي
- البنية التحتية: Azure App Service مع التوسّع التلقائي — لا نقطة فشل واحدة على خادم قديم يتهالك
- الفريق: 4 مطورين، مهندس DevOps واحد، مدير مشروع واحد، مهندس أتمتة ضمان جودة واحد
التنفيذ في 90 يوماً
الأسبوعان 1–2: الاستكشاف والهندسة المعمارية
رسمنا خريطة لكل مسار عمل يدعمه النظام القديم عبر مراقبة المستخدمين لا قراءة المواصفات. لم تكن هناك مواصفات حديثة. تبيّن أن الأوراق الاحتياطية الورقية لمشرف المستودع كانت أدق توثيق لكيفية تدفق الطلبات عبر الأعمال. استخدمناها كأساس لمتطلباتنا وكمّلناها بورشتي عمل رسميتين مع رؤساء الأقسام.
الأسابيع 3–6: البناء الأساسي
غطّت الأسابيع الأربعة الأولى مسارات العمل الأعلى أولوية: إدخال الطلبات، والبحث في المخزون، وعملية الانتقاء والتوزيع اليومية. أجرينا عروضاً أسبوعية مع فريق المستودع، اكتشفنا خلالها عدة افتراضات خاطئة حول مسارات العمل. كان في النظام القديم تفصيل يقضي بأن الطلبات من شريحة عملاء محددة تحظى بأولوية معالجة مختلفة — شيء لم يكن في أي وثيقة لكنه راسخ في عادات الفريق اليومية. كنا سنغفل عنه لولا العروض الأسبوعية.
الأسابيع 7–9: هجرة البيانات والتكامل
هجرة البيانات كانت الجزء الذي توخّينا فيه أكبر الحذر. خمسة عشر عاماً من سجلات الطلبات وبيانات العملاء وكتالوج المنتجات — بعضها بتنسيقات غير متسقة، وبعضها يشير إلى سجلات لم تعد موجودة. بنينا نصوص الهجرة في الأسبوع السابع وشغّلناها مقابل نسخة تجريبية من بيانات الإنتاج ثلاث مرات قبل الوثوق بالنتائج. أبقينا النظام القديم يعمل خلال هذه المرحلة حتى يتمكن الموظفون من الرجوع إلى السجلات إذا بدا أي شيء غريباً.
كان التكامل مع برنامج المحاسبة الخاص بهم (Sage) أكثر الأجزاء استهلاكاً للوقت في المشروع — بشكل رئيسي لأن توثيق واجهة برمجة Sage كان ناقصاً وكان علينا الاختبار مقابل مثيل حي لفهم سلوكه الفعلي. بنينا هامشاً احتياطياً أسبوعاً لذلك، وهو ما احتجناه تماماً.
ما كاد يُعيقنا
في الأسبوع الثامن، اكتشفنا أن النظام القديم كان يحسب تكاليف الشحن وفق جدول رسوم لم يُحدَّث منذ 2019. النظام الجديد استخدم الأسعار الحالية. لم يكن هذا خطأً برمجياً — بل كان نقطة قرار. أبلغنا العميل فوراً، وحصلنا على قراره خلال 24 ساعة، وحدّثنا الإعداد. اكتشاف هذا قبل الإطلاق لا بعده أنقذنا من شهر محتمل من الفوضى في الفواتير.
الأسابيع 10–12: التشغيل الموازي والتحويل
لأسبوعين، عمل النظامان في آن واحد. أُدخلت الطلبات الجديدة في كلا النظامين. يبدو هذا غير كفء وهو كذلك — لكن لشركة تصنيع حيث يمكن أن يعني خطأ في معالجة الطلب تفويت التزام تسليم، كان هذا القرار الصحيح. أعطى الفريق ثقةً في النظام الجديد قبل إيقاف القديم، وأعطانا خطاً أساسياً للمقارنة لاكتشاف أي فروق في الحسابات.
نفّذنا التحويل يوم الجمعة بعد الظهر الساعة 3:00 — بتوقيت مدروس ليكون بعد آخر رحلة توزيع في الأسبوع وقبل استقبال الطلبات يوم الاثنين التالي. التحويل نفسه استغرق 45 دقيقة. بقي الخادم القديم في حالة جاهزية لأسبوعين بعد التحويل ولم يُحتَج إليه قط.
الأرقام بعد 90 يوماً
قسنا مقابل الخط الأساسي الذي وضعناه في أسبوع التقييم:
- وقت تحميل صفحة إدخال الطلب: من 5-8 دقائق إلى أقل من ثانيتين
- وقت تشغيل النظام: من ~95% إلى 99.9% (نافذة صيانة مخططة واحدة مدتها 23 دقيقة خلال أول 90 يوماً بعد الإطلاق)
- إمكانية الوصول من الجوال: من 0% إلى 100% — أي جهاز، أي متصفح
- تذاكر الدعم المتعلقة بالنظام لفريق تقنية المعلومات: انخفاض 62% في الشهر الأول
- التكلفة السنوية للبنية التحتية والصيانة: من €185,000 سنوياً إلى €38,000 سنوياً
تخلّص مشرف المستودع من أوراقه الاحتياطية الورقية في الأسبوع الثالث من النظام الجديد. شعرنا أن هذا مقياس نجاح أكثر أمانةً من أي من الأرقام أعلاه.
ما جعل الجدول الزمني لـ 90 يوماً ممكناً
هذا النوع من تحديث الأنظمة القديمة لا ينجح دائماً. رأينا مشاريع مماثلة تستغرق 18 شهراً أو تُلغى. بعض الأشياء صنعت الفارق هنا:
نطاق ثابت مع خطوط فصل واضحة. اتفقنا مسبقاً على أن الإصدار 1 سيطابق وظيفة النظام القديم، لا يتجاوزها. طلبات الميزات خلال المشروع ذهبت إلى الجدول الزمني لما بعد الإطلاق، لا إلى السبرنت الحالي. هذا الانضباط أصعب مما يبدو — العملاء بطبيعتهم يريدون تحسين الأشياء أثناء إعادة بنائها. لكن زحف النطاق هو ما يحوّل مشاريع 90 يوماً إلى مشاريع 9 أشهر.
مستخدمون حقيقيون في العملية أسبوعياً. البرمجيات المبنية بدون مدخلات منتظمة من المستخدمين أثناء التطوير تميل إلى أن تكون صحيحة تقنياً لكن خاطئة عملياً. العروض الأسبوعية مع موظفي المستودع والمبيعات الفعليين اكتشفت المشاكل مبكراً بما يكفي لإصلاحها دون إعادة عمل جوهرية.
أساس DevOps من اليوم الأول. أنشأنا خطوط CI/CD والاختبار الآلي والبنية التحتية ككود قبل كتابة أول سطر من كود التطبيق. هذا يعني أن عمليات النشر كانت آلية وموثوقة طوال المشروع، مما أزال فئة من المخاطر تقتل الزخم في كثير من جهود تحديث الأنظمة القديمة.
اختيار تقنية مجربة وناضجة. Vue.js و.NET Core ليسا أحدث ما هو متاح. لكنهما ناضجان وموثقان جيداً ولديهما مجتمعات دعم كبيرة. حين واجهنا مشاكل — وقد واجهنا — كان إيجاد الحلول سريعاً. اختيار التقنية المستقرة بدلاً من الأحدث هو في الغالب القرار الصحيح لمشروع مقيّد بالوقت.
ما حدث بعد 90 يوماً
بعد ستة أشهر من الإطلاق، أجرى العميل أول مراجعة ما بعد التنفيذ. الوفورات المُحددة كمياً — تكاليف البنية التحتية، وتقليص عقد الصيانة، ومكاسب الإنتاجية من معالجة الطلبات أسرع — بلغت €247,000 في السنة الأولى. تكلفة إعادة بناء النظام كانت €148,000. منذ ذلك الحين أضافوا وحدتين جديدتين (بوابة العملاء ولوحة التقارير) لم تكن ممكنة على الإطلاق مع البنية القديمة.
الأهم من ذلك، فريق العمليات بات يثق بنظامه مجدداً. يصعب وضع ذلك في جدول بيانات، لكنه يغيّر طريقة عمل الشركة.
إذا كان عملك يعمل على برمجيات تتعطل بشكل متكرر، أو بطيئة بشكل مؤلم، أو لا تستطيع دعم الطريقة التي تحتاج إلى العمل بها اليوم، فالسؤال في الغالب ليس ما إذا كان يجب التحديث — بل متى وكيف. استبدال نظام قديم بنطاق محدد بدقة مع خيارات تقنية صحيحة ونهج منضبط في النطاق قابل للتحقيق في 90 يوماً. ليس دائماً. لكن في أغلب الأحيان أكثر مما تفترض معظم الشركات.
