المنصة المخصصة أصل تشغيلي طويل الأجل، وليست مشروعاً ينتهي عند إطلاق النسخة الأولى. قبل اعتمادها، يحتاج صاحب الشركة إلى معرفة من سيتخذ القرارات، ويعالج الأعطال، ويحمي الصلاحيات، ويحافظ على فائدة النظام مع تغير العمل. تساعد شركة أبجد أصحاب الشركات على فحص هذه المسؤوليات قبل تثبيت المعمارية والبدء في التطوير.
أهم النقاط
- حدد ملكية الشيفرة والحسابات والبيانات والقرارات التقنية قبل بدء العمل.
- اطلب توثيقاً وخطة تشغيل يستطيع فريق مؤهل آخر استخدامها.
- اختبر طريقة التعامل مع تغييرات الصلاحيات والأعطال والتحديثات.
- اختر نموذج دعم يتناسب مع أهمية المنصة في التشغيل اليومي.
1. من يملك قرار التغيير بعد الإطلاق؟
السؤال الأول ليس من يكتب الشيفرة، بل من يملك صلاحية القرار عندما تحتاج المنصة إلى تعديل أو إصلاح عاجل أو استجابة أمنية. إذا بقيت هذه الصلاحية غامضة، تصبح النقاشات التقنية بطيئة ومكلفة، وترتبط بشخص واحد أو مورد واحد.
اكتب اسم المسؤول عن كل مجال من المجالات التالية:
- تحديد أولويات العمل والموافقة على المزايا الجديدة.
- المعمارية التقنية والتكاملات وقرارات الإطلاق.
- الحوادث الأمنية ومراجعة الوصول والتعامل مع البيانات.
- اعتماد ميزانية الصيانة والتحسينات المستقبلية.
لا يشترط أن يكون المسؤول مبرمجاً، لكنه يحتاج إلى رؤية كافية لفهم المفاضلات ومعرفة الفرق بين الخطر الحقيقي والتفضيل الشخصي. توصي أبجد بإعداد خريطة مسؤوليات قصيرة، تتضمن الأسماء ومسارات التصعيد وحدود الموافقة، قبل بدء التطوير.
2. هل يستطيع فريق آخر استلام المنصة دون تخمين؟
المنصة القابلة للصيانة يجب أن تكون مفهومة لمن لم يبنها. اطلب رؤية هيكل التوثيق قبل توقيع اعتماد المشروع، ولا تكتفِ بوعد عام بأن التوثيق سيأتي لاحقاً. الهدف هو استمرارية العمل؛ فلا ينبغي أن تفقد الشركة السيطرة إذا تغير المورد أو غادر أحد أفراد الفريق.
اطلب مواد التسليم التالية:
- معمارية النظام والبيئات والاعتماديات الأساسية.
- مستودع الشيفرة وتعليمات النشر.
- نموذج البيانات وخريطة التكاملات وطريقة إدارة مفاتيح الوصول.
- دليل المدير وأدوار المستخدمين وخطوات معالجة الأعطال الشائعة.
- سجلات النسخ الاحتياطي والاستعادة والإصدارات.
اطلب من شخص لم يشارك في التطوير اتباع الدليل داخل بيئة مضبوطة. ستكشف أسئلته المعلومات الناقصة أفضل من مراجعة المستندات وحدها. تكون معرفة المنصة جزءاً من التسليم الحقيقي، لا محفوظة في ذاكرة شخص واحد.
3. ماذا يحدث عندما تتغير الصلاحيات؟
ينضم الموظفون ويغادرون، وتتغير مسؤولياتهم، وقد يحتاج أحدهم إلى وصول مؤقت. لذلك يجب أن تجعل المنصة هذه التغييرات مقصودة وقابلة للمراجعة. تجنب نموذج مشاركة كلمة مرور المدير أو تعديل الصلاحيات بشكل غير رسمي كلما طلب مستخدم ذلك.
قبل الإطلاق، تأكد من أن المنصة تدعم ما يلي:
- صلاحيات مبنية على الأدوار للموظفين والمديرين والموردين والمديرين التقنيين.
- اعتماد الوصول المميز وتسجيل الشخص الذي وافق عليه.
- إلغاء الوصول أو تخفيضه عند تغيير الدور أو مغادرة الموظف.
- حسابات منفصلة لفريق الدعم ووصول طوارئ محدد بالاسم.
- مراجعة الحسابات غير المستخدمة وحسابات الخدمات ومفاتيح التكامل.
اختبر هذه الحالات باستخدام مستخدمين حقيقيين، لا باستخدام حساب المدير فقط. التصميم الجيد يقلل التعرض للمخاطر دون تعطيل العمل الطبيعي. وتتعامل شركة أبجد مع الصلاحيات كجزء من تصميم النظام، لأنها تؤثر في الأمن والمساءلة وسرعة التشغيل معاً.
4. كيف ستتم الصيانة دون تعطيل العمل؟
الصيانة ليست إصلاح العيوب الظاهرة فقط. فهي تشمل تحديث الاعتماديات، وتطبيق التصحيحات الأمنية، ومراقبة التكاملات، وتحسين الأداء، وتكييف المنصة مع تغير احتياجات الشركة. اسأل كيف ستُخطط هذه الأعمال وتُختبر ويُبلّغ عنها للمستخدمين.
يجب أن توضح خطة الصيانة العملية ما يلي:
- المكونات التي ستتم مراجعتها وتحديثها بانتظام.
- طريقة انتقال التغييرات من التطوير إلى الاختبار ثم الإنتاج.
- من يوافق على الإصلاح العاجل وكيف يُسجل القرار.
- طريقة إبلاغ المستخدمين بالانقطاعات أو تغير السلوك.
- الحالات التي تستدعي مراجعة تقنية أو إعادة تصميم.
افصل الصيانة الدورية عن طلبات المزايا الجديدة. خلطهما يجعل من الصعب معرفة ما إذا كانت المنصة تُحافظ على سلامتها أو تتوسع فقط. وإذا كانت المنصة تؤثر في رحلة العميل، فأشرك
