تصميم أنظمة القيادة: هندسة المؤسسات والعمليات
تصميم العمليات الهندسية القابلة للتوسع
العمليات الهندسية هي نظام التشغيل لمؤسستك. عندما تُنفَّذ بشكل جيد، تخلق قابلية للتنبؤ، وتقلل الهدر، وتحرر المهندسين للتركيز على حل المشكلات. عندما تُنفَّذ بشكل سيء، تصبح عبئاً بيروقراطياً يُبطئ الجميع. تختبر مقابلات مدير الهندسة قدرتك على تصميم عمليات تعمل على نطاق واسع -- وليس مجرد اتباع دليل Scrum الكتابي.
تخطيط السبرنت والتقدير
تستخدم معظم الفرق الهندسية شكلاً من التخطيط التكراري، سواء سبرنتات Scrum، أو تدفق Kanban، أو نهجاً هجيناً. المنهجية المحددة أقل أهمية مما إذا كانت تخلق إيقاعاً مستداماً للتسليم.
يجب أن يحقق تخطيط السبرنت ثلاثة أشياء في اجتماع واحد: مواءمة الفريق على هدف السبرنت ("لماذا")، واختيار عناصر العمل من قائمة مهام مرتبة الأولوية ("ماذا")، وتقسيم العناصر إلى مهام بمعايير قبول واضحة ("كيف"). فشل شائع هو ملء السبرنت بشكل مفرط. قاعدة جيدة هي التخطيط لـ 70-80% من السعة النظرية، مع ترك مساحة للمقاطعات ومراجعات الكود والعمل غير المخطط.
التقدير موجود لتمكين التخطيط، وليس لإنشاء عقود مساءلة. نقاط القصة -- تقنية تحجيم نسبية -- تظل النهج الأكثر استخداماً. المبدأ الرئيسي هو أن نقاط القصة تقيس التعقيد وعدم اليقين، وليس الساعات. قصة من 5 نقاط أكثر تعقيداً بنحو الضعف من قصة من 3 نقاط، لكن الوقت الفعلي قد يختلف بناءً على من يتولاها وما المفاجآت التي تظهر. الفرق التي تُقدّر بالساعات غالباً ما تقع في فخ معاملة التقديرات كالتزامات، مما يخلق حوافز ضارة لتضخيم الأرقام أو التقصير.
عند سؤالك عن التقدير في المقابلات، أكّد أنك تستخدم التقدير كـأداة تنبؤ -- تتبع السرعة بمرور الوقت للتنبؤ بقدرة التسليم، وليس كآلية للضغط على المهندسين.
خيارات دورة حياة تطوير البرمجيات
تحدد دورة حياة تطوير البرمجيات (SDLC) كيف يتدفق العمل من الفكرة إلى الإنتاج. اختيارك يعتمد على نضج الفريق ونوع المنتج وتحمل المخاطر. والخطأ الذي ينتبه له المُقابلون هو المرشح الذي لديه نهج مُفضَّل: مدير الهندسة الذي يوصي بنفس العملية بغض النظر عن السياق لم يفهم أن كل واحدة من هذه تشتري قابلية التنبؤ بشيء ما.
أربعة نماذج للتسليم وما تكلّفه كل واحدة فعلاً
Scrum
- الإيقاع نفسه يُعلّم التقدير -- يتعلم الفريق سعته الخاصة في نحو ثلاثة سبرنتات
- الطقوس الثابتة تعني أن لا أحد مضطر لاختراع موعد التخطيط أو الاستعراض
- أسهل نموذج شرحاً لأصحاب المصلحة الذين يريدون تواريخ
- حدود السبرنت تؤخر العمل العاجل، فتستجيب الفرق باختراع مسار سريع غير رسمي يصبح بهدوء معظم العمل
- عبء الطقوس ثابت مهما كان حجم الفريق، فيقع أثقل ما يكون على الفرق الصغيرة
- السرعة تصبح مرئية، وحين تصبح مرئية يبدأ شخص من خارج الفريق بإدارتها
Kanban
- العمل المدفوع بالمقاطعات يتوقف عن تشويه الخطة لأنه لا توجد خطة تُشوَّه
- حدود العمل قيد التنفيذ تُبرز عناقيد الزجاجة مباشرة لا عبر مقياس
- عبء اجتماعات يكاد يكون معدوماً
- الإجابة على "متى سينتهي هذا؟" تتطلب بيانات زمن دورة يجب جمعها بشكل مقصود -- وإلا فلا إجابة لديك على الإطلاق
- بدون فرض حدود للعمل قيد التنفيذ يتحول إلى "كل شيء قيد التنفيذ"، وهذا أسوأ من أسوأ حالات Scrum
- غياب الإيقاع الطبيعي يعني تخطي الاستعراضات وعمل التحسين إلا إذا جدولتها عمداً
Shape Up
- الوقت ثابت والنطاق متغير، وهذا يعكس الفشل المعتاد -- التاريخ يصمد والنطاق ينحني
- دورات طويلة بما يكفي ليصبح العمل الصعب فعلاً ممكناً
- تشكيل العمل قبل المجازفة به يقتل المشاريع السيئة قبل أن تستهلك فريقاً
- يتطلب شخصاً لديه السلطة والمهارة لتشكيل العمل جيداً؛ وبدون ذلك يصبح مجرد سبرنت من ستة أسابيع ويزحف النطاق بلا رقيب
- المجازفة الخاطئة تكلّف ستة أسابيع لا أسبوعين
- ملاءمة ضعيفة للفرق التي تحمل حملاً تشغيلياً غير مخطط كبيراً
التسليم المستمر
- الدفعات الصغيرة تعني إخفاقات صغيرة -- التغيير الذي عطّل الإنتاج يمكن تحديده بسهولة تامة
- يقصّر حلقة التغذية الراجعة بين البناء والتعلم أكثر من أي تغيير آخر في هذه القائمة
- يتوافق مباشرة مع مقاييس الإنتاجية والاستقرار التي تتبعها القيادة أصلاً
- ثقيل المتطلبات المسبقة: بدون أتمتة اختبارات ومراقبة حقيقية، هذا يشحن العيوب أسرع ولا شيء غير ذلك
- المعيار التشغيلي دائم لا هجرة لمرة واحدة -- خط الأنابيب أصبح منتجاً له مالك
- تبنّيه كتكليف لا كقدرة طريقة موثوقة لجعل مقاييس استقرار الفريق أسوأ
عملياً، معظم الفرق تتبنى نهجاً هجيناً. دور مدير الهندسة هو اختيار النهج الذي يناسب سياق الفريق وتطويره مع نضج الفريق -- وأن يستطيع قول أي تكلفة قَبِلها عند اختياره.
إدارة الحوادث والمناوبة
عملية إدارة الحوادث المصممة جيداً لها أربع مراحل:
- الاكتشاف -- تنبيه آلي من خلال أدوات المراقبة والمتابعة. الهدف هو اكتشاف الحوادث قبل أن يبلغ عنها العملاء.
- الاستجابة -- دورة مناوبة محددة مع مسارات تصعيد واضحة. يقوم مهندس المناوبة بفرز التنبيه، وتقييم الخطورة، وإما حله أو تصعيده.
- الحل -- تنسيق الاستجابة، والتواصل بالحالة مع أصحاب المصلحة، واستعادة الخدمة. للحوادث الكبرى، عيّن قائد حادث يمتلك التنسيق بينما يركز الآخرون على التصحيح.
- مراجعة ما بعد الحادث -- استرجاعات بدون لوم تركز على الأسباب النظامية، وليس أخطاء الأفراد. المخرج هو عناصر عمل لمنع التكرار.
يجب أن تكون دورات المناوبة مستدامة. المبادئ الرئيسية تشمل: تعويض وقت المناوبة بشكل عادل (إجازة أو أجر إضافي)، وتحديد نوبات المناوبة بأسبوع واحد مع ثلاثة أسابيع على الأقل بين النوبات، وتتبع حجم التنبيهات لتحديد التنبيهات المزعجة التي يجب إصلاحها أو إسكاتها، والتأكد من أن مهندس المناوبة ليس الشخص الوحيد القادر على الاستجابة لمشكلة حرجة.
إدارة الديون التقنية
تتراكم الديون التقنية عندما تأخذ الفرق اختصارات للشحن بشكل أسرع. وهي ليست سيئة بطبيعتها -- أحياناً تحمّل الدين هو القرار التجاري الصحيح. المشكلة هي عندما يكون الدين غير مرئي وغير مُدار.
نهجان مثبتان لإدارة الديون التقنية:
سجل الديون التقنية. حافظ على قائمة مرئية من عناصر الديون التقنية المعروفة، كل منها مُعلَّم بالتأثير (ما ينكسر أو يتباطأ إذا لم يُعالَج)، والجهد المقدر للإصلاح، ومستوى الأولوية. راجع السجل ربع سنوياً وأعطِ الأولوية للعناصر التي تخلق أكبر عائق على سرعة التسليم.
نهج التخصيص. احجز نسبة ثابتة من سعة السبرنت -- عادةً 20% -- لتقليل الديون التقنية وتحسينات البنية التحتية وعمل تجربة المطور. يضمن هذا النهج تقدماً مستمراً في الدين دون الحاجة لعملية تخطيط منفصلة. عندما تسأل القيادة "لماذا ننفق 20% على عمل غير ميزات؟"، الإجابة هي أنه بدون هذا الاستثمار، تتباطأ الـ 80% المتبقية كل ربع سنة.
عمليات RFC ومستندات التصميم
تضمن عملية RFC (طلب التعليقات) أو مستند التصميم مراجعة القرارات التقنية المهمة قبل التنفيذ. هذا يلتقط عيوب التصميم مبكراً، وينشر المعرفة عبر الفريق، ويخلق سجلاً مكتوباً لسبب اتخاذ القرارات.
تبدو عملية RFC خفيفة كالتالي:
- يكتب المؤلف مستنداً من صفحة إلى ثلاث صفحات يغطي المشكلة والحل المقترح والبدائل المدروسة والمخاطر
- يُشارك المستند مع المراجعين المعنيين (عادةً كبار المهندسين وقادة الفرق المتأثرة وأصحاب البنية التحتية)
- للمراجعين نافذة محددة (3-5 أيام عمل) لتقديم ملاحظات مكتوبة
- يعالج المؤلف الملاحظات وإما يعدّل الاقتراح أو يوثّق لماذا اختار عدم التعديل
- يُسجَّل القرار: موافق عليه، أو موافق عليه مع تعديلات، أو مرفوض
يجب أن يكون عتبة طلب RFC واضحة. المحفزات الشائعة تشمل: خدمات جديدة، وتغييرات مخطط قاعدة البيانات، وتبعيات خارجية جديدة، وتغييرات تؤثر على فرق متعددة، وأي عمل يتجاوز حداً محدداً للحجم (مثلاً، أكثر من أسبوعين من الجهد).
البناء مقابل الشراء
أحد أهم قرارات العمليات التي يواجهها مديرو الهندسة هو ما إذا كانوا سيبنون قدرة داخلياً أو يشترون حلاً من طرف ثالث. إطار هذا القرار يأخذ في الاعتبار:
- الجوهر مقابل السياق -- هل هذه القدرة عامل تمييز جوهري لأعمالك، أم هي سياق (ضروري لكنه غير مُمَيِّز)؟ ابنِ القدرات الجوهرية. اشترِ قدرات السياق.
- التكلفة الإجمالية للملكية -- البناء يشمل ليس فقط التطوير الأولي بل الصيانة المستمرة ودعم المناوبة والتوثيق وتكلفة الفرصة البديلة. الشراء يشمل رسوم الترخيص وجهد التكامل وخطر الارتباط بالمورد وقيود التخصيص.
- خبرة الفريق -- هل لديك المعرفة المتخصصة لبناء هذا وصيانته بشكل جيد؟ فريق بدون خبرة في قواعد البيانات لا ينبغي أن يبني قاعدة بيانات مخصصة.
- الوقت للقيمة -- إذا كانت السرعة مهمة، شراء حل موجود يوصلك للقيمة بشكل أسرع حتى لو لم يكن مثالياً.
في المقابلات، إظهار أنك تتعامل مع قرار البناء مقابل الشراء بإطار منظم بدلاً من افتراض "يجب أن نبنيه" يُظهر نضجاً تشغيلياً.
التالي، سنستكشف أنظمة التسليم والمقاييس -- بما في ذلك مقاييس DORA، وتتبع السرعة، وإنشاء خارطة الطريق، ووضع OKR للفرق الهندسية. :::
سجّل الدخول للتقييم