بعد التحول من مطور برمجيات إلى مدير مشاريع خلال سنة 2009 م ، كان التحدي هو فهم المشروع من أكثر من جهة من ناحية تطوير الأعمال ومن ناحية المشاكل التقنية ودراسة المخاطر المتعلقة بالمشروع ..
أكثر نقطة كانت تعتبر خطر مهم ومهمل غالبا هي تدشين الخدمة نفسه ولا أخفيكم أن أكثر المشاكل التي واجهتها متعلقة بالتدشين.
هناك عدة أنواع من آليات تدشين المشاريع ، وأتكلم هنا عمليا ..
1 – تدشين الخدمة بشكل متوازي بحيث تمكن المستخدم من استخدام النسختين القديمة والحديثة بنفس الوقت حتى يتم إيقاف الخدمة القديمة بشكل كامل.
2 – تدشين الخدمة بإيقاف الخدمة القديمة وتشغيل الخدمة الجديدة مباشرة ولعل هذه من أخطر الآليات لعدة اسباب سأتحدث عنها.
3 – تدشين الخدمة بشكل متتابع بحيث تقسيم النسختين إلى عدة مكونات ويتم تدشين مكون مكون حتى يتم اكتمال تدشين كل مكونات النسخة الجديدة.
أود التنبيه إلى أن المشاريع تختلف ، تدشين خدمة إدخال بيانات تختلف عن تدشين خدمة بريد الكتروني ، تختلف عن تسجيل مخالفات
وحسب اعتقادي هي مرتبطة بشكل كبير إلى نقطتين :
- عدد مستخدمي النظام.
- إمكانية إعادة تنفيذ العملية وإلغاء العمليات السابقة “Rollback”.
أعود إلى الآليات :
تدشين الخدمة بشكل متوازي
أتذكر عندما قامت ياهو بتحديث بريدها الالكتروني بإضافة تقنية الاجاكس على جميع العمليات الخاصة بالتحكم بالبريد الالكتروني ، كان المستخدم يتمتع بخيارين ، استخدام النسخة الجديدة أو استخدام النسخة القديمة ، بحيث تكون النسخة الحديثة عبارة عن نسخة تجريبية تقوم ياهو بحل جميع مشاكلها بارتياح ودون تعجل نظرا لوجود خيار آخر للمستخدم. على الرغم من ذلك يستوجب على الجهة المطورة متابعة جميع العمليات المنفذة في النسخة الحديثة ومدى ترابطها وتكاملها مع النسخة القديمة بحيث إمكانية إلغاء العمليات المنفذة في النسخة الحديثة من النسخة القديمة والعكس .!
ربما نجحت ياهو في العملية لعدم وجود تغير في backend في نظام البريد الالكتروني .. لكن ماذا لو تم اضافة حقل جديد في النسخة الحديثة؟!
تغير طفيف في عمليات الخدمة من الممكن أن ينهي التفكير في هذه الآلية.
تدشين الخدمة بإيقاف الخدمة القديمة
تعقيبا على آخر نقطة في الآلية السابقة ، في حالة تغير طفيف في حقول أو عمليات الخدمة يجعل خيار تدشين الخدمة بإيقاف الخدمة القديمة وتدشين الخدمة الحديثة خيار منطقي ومناسب ولكن تستوجب هذه الآلية الكثير الكثير الكثير من العمل.
بحيث يتم تجربة الخدمة الحديثة في أكثر من بيئة مع التأكد من عدم تجاهل أعقد الحالات الممكنة.
أتذكر حالة من حالات التدشين التي قمنا بها بنفس الآلية. بحيث تم إيقاف الخدمة القديمة تماما وتفعيل الخدمة الجديدة. كان التغيير في إحدى حقول الخدمة بإضافة رقم جوال .، المهم ..
عند طباعة المستند الرسمي الخاص بالخدمة ، تتم الطباعة بشكل جميل وبدون مشاكل … عند محاولة الطباعة مرة أخرى !! تحصل المشكلة ..
ليه ، كيف ، لماذا ؟ خصوصا أن المكون أو العنصر الخاص بالطباعة لم يتم لمسه مطلقا. كان الخطأ في تدشين الخدمة الحديثة ، لم يتم رفع ملف وحيد في نظام الملفات الواجب رفعها على النظام.
بخلاف في حالة وجود مستخدمين كثر ، دائما .. لا تحتفل مبكرا .. يستوجب عليها متابعة العمليات المنفذة بشكل دقيق.
تدشين الخدمة بشكل متتابع
ربما تختص آلية التدشين هذه في حالة وجود نظام قائم ومحاولة تحديث مكونات داخل هذا النظام مثل اضافة خدمة جديدة أو تعديل خدمة قائمة.
وأيضا سأعود إلى ياهو في هذه النقطة ، عندما تم تحديث نظام البريد الالكتروني من أهم مكونات النظام هو الأسماء “Contacts” تخيل تم تدشين الخدمة ولم يتم تحديث نسخة الأسماء ستجد الاسماء أمامك جميعهم في النظام الحديث ولكن في حالة القيام بتعديل بسيط يستوجب عليك العودة إلى النظام القديم. من مميزات هذه الآلية أن حجم المتابعة و التحكم سيكون مرتبط فقط في التغيير نفسه فقط بدلا من متابعة النظام بشكل كامل.
الخلاصة
من المهم جدا إعطاء التدشين أهمية قصوى ، بحيث يتم التأكد من تحديد الوقت المناسب والمكان المناسب عند القيام بتدشين خدمة واختيار الالية الصحيحة المناسبة لنظامك أنت. ويجب القيام بدراسة العملية بشكل مستمر وأكثر جدية.










