تصميم العمليات الهندسية القابلة للتوسع

العمليات الهندسية هي نظام التشغيل لمؤسستك. عندما تُنفَّذ بشكل جيد، تخلق قابلية للتنبؤ، وتقلل الهدر، وتحرر المهندسين للتركيز على حل المشكلات. عندما تُنفَّذ بشكل سيء، تصبح عبئاً بيروقراطياً يُبطئ الجميع. تختبر مقابلات مدير الهندسة قدرتك على تصميم عمليات تعمل على نطاق واسع -- وليس مجرد اتباع دليل Scrum الكتابي.

تخطيط السبرنت والتقدير

تستخدم معظم الفرق الهندسية شكلاً من التخطيط التكراري، سواء سبرنتات Scrum، أو تدفق Kanban، أو نهجاً هجيناً. المنهجية المحددة أقل أهمية مما إذا كانت تخلق إيقاعاً مستداماً للتسليم.

يجب أن يحقق تخطيط السبرنت ثلاثة أشياء في اجتماع واحد: مواءمة الفريق على هدف السبرنت ("لماذا")، واختيار عناصر العمل من قائمة مهام مرتبة الأولوية ("ماذا")، وتقسيم العناصر إلى مهام بمعايير قبول واضحة ("كيف"). فشل شائع هو ملء السبرنت بشكل مفرط. قاعدة جيدة هي التخطيط لـ 70-80% من السعة النظرية، مع ترك مساحة للمقاطعات ومراجعات الكود والعمل غير المخطط.

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

عند سؤالك عن التقدير في المقابلات، أكّد أنك تستخدم التقدير كـأداة تنبؤ -- تتبع السرعة بمرور الوقت للتنبؤ بقدرة التسليم، وليس كآلية للضغط على المهندسين.

خيارات دورة حياة تطوير البرمجيات

تحدد دورة حياة تطوير البرمجيات (SDLC) كيف يتدفق العمل من الفكرة إلى الإنتاج. اختيارك يعتمد على نضج الفريق ونوع المنتج وتحمل المخاطر:

النهج	الأفضل لـ	المفاضلات
Scrum (سبرنتات أسبوعين)	الفرق التي تتعلم الأجايل، المنتجات بقوائم مهام واضحة	يوفر هيكلاً لكنه قد يبدو جامداً؛ حدود السبرنت قد تؤخر العمل العاجل
Kanban (تدفق مستمر)	الفرق كثيفة العمليات، أعمال الصيانة، فرق الدعم	مرونة قصوى لكنه يتطلب انضباطاً في حدود العمل قيد التنفيذ؛ أصعب في التنبؤ
Shape Up (دورات 6 أسابيع)	الفرق المدفوعة بالمنتج مع تحديد نطاق قائم على الشهية (طُوّر في Basecamp)	دورات أطول تسمح بعمل أعمق؛ خطر زحف النطاق بدون تشكيل قوي
التسليم المستمر	الفرق الناضجة مع CI/CD قوي وأتمتة اختبارات	أقصى إنتاجية لكنه يتطلب استثماراً في البنية التحتية وتميزاً تشغيلياً

عملياً، معظم الفرق تتبنى نهجاً هجيناً. دور مدير الهندسة هو اختيار النهج الذي يناسب سياق الفريق وتطويره مع نضج الفريق.

إدارة الحوادث والمناوبة

عملية إدارة الحوادث المصممة جيداً لها أربع مراحل:

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

يجب أن تكون دورات المناوبة مستدامة. المبادئ الرئيسية تشمل: تعويض وقت المناوبة بشكل عادل (إجازة أو أجر إضافي)، وتحديد نوبات المناوبة بأسبوع واحد مع ثلاثة أسابيع على الأقل بين النوبات، وتتبع حجم التنبيهات لتحديد التنبيهات المزعجة التي يجب إصلاحها أو إسكاتها، والتأكد من أن مهندس المناوبة ليس الشخص الوحيد القادر على الاستجابة لمشكلة حرجة.

إدارة الديون التقنية

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

نهجان مثبتان لإدارة الديون التقنية:

سجل الديون التقنية. حافظ على قائمة مرئية من عناصر الديون التقنية المعروفة، كل منها مُعلَّم بالتأثير (ما ينكسر أو يتباطأ إذا لم يُعالَج)، والجهد المقدر للإصلاح، ومستوى الأولوية. راجع السجل ربع سنوياً وأعطِ الأولوية للعناصر التي تخلق أكبر عائق على سرعة التسليم.

نهج التخصيص. احجز نسبة ثابتة من سعة السبرنت -- عادةً 20% -- لتقليل الديون التقنية وتحسينات البنية التحتية وعمل تجربة المطور. يضمن هذا النهج تقدماً مستمراً في الدين دون الحاجة لعملية تخطيط منفصلة. عندما تسأل القيادة "لماذا ننفق 20% على عمل غير ميزات؟"، الإجابة هي أنه بدون هذا الاستثمار، تتباطأ الـ 80% المتبقية كل ربع سنة.

عمليات RFC ومستندات التصميم

تضمن عملية RFC (طلب التعليقات) أو مستند التصميم مراجعة القرارات التقنية المهمة قبل التنفيذ. هذا يلتقط عيوب التصميم مبكراً، وينشر المعرفة عبر الفريق، ويخلق سجلاً مكتوباً لسبب اتخاذ القرارات.

تبدو عملية RFC خفيفة كالتالي:

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

يجب أن يكون عتبة طلب RFC واضحة. المحفزات الشائعة تشمل: خدمات جديدة، وتغييرات مخطط قاعدة البيانات، وتبعيات خارجية جديدة، وتغييرات تؤثر على فرق متعددة، وأي عمل يتجاوز حداً محدداً للحجم (مثلاً، أكثر من أسبوعين من الجهد).

البناء مقابل الشراء

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

• الجوهر مقابل السياق -- هل هذه القدرة عامل تمييز جوهري لأعمالك، أم هي سياق (ضروري لكنه غير مُمَيِّز)؟ ابنِ القدرات الجوهرية. اشترِ قدرات السياق.
• التكلفة الإجمالية للملكية -- البناء يشمل ليس فقط التطوير الأولي بل الصيانة المستمرة ودعم المناوبة والتوثيق وتكلفة الفرصة البديلة. الشراء يشمل رسوم الترخيص وجهد التكامل وخطر الارتباط بالمورد وقيود التخصيص.
• خبرة الفريق -- هل لديك المعرفة المتخصصة لبناء هذا وصيانته بشكل جيد؟ فريق بدون خبرة في قواعد البيانات لا ينبغي أن يبني قاعدة بيانات مخصصة.
• الوقت للقيمة -- إذا كانت السرعة مهمة، شراء حل موجود يوصلك للقيمة بشكل أسرع حتى لو لم يكن مثالياً.

في المقابلات، إظهار أنك تتعامل مع قرار البناء مقابل الشراء بإطار منظم بدلاً من افتراض "يجب أن نبنيه" يُظهر نضجاً تشغيلياً.

التالي، سنستكشف أنظمة التسليم والمقاييس -- بما في ذلك مقاييس DORA، وتتبع السرعة، وإنشاء خارطة الطريق، ووضع OKR للفرق الهندسية. :::