ماذا تفعل لمنع الفريق من الاعتماد بشكل مفرط على شخص واحد؟

Question

Accepted Answer

**الـ bus factor المنخفض خطر أُديره عمداً، بالطريقة نفسها التي أُدير بها أي نقطة فشل وحيدة.** إذا كان شخص واحد فقط يستطيع الـ deploy، أو تصحيح خدمة المدفوعات، أو لمس الوحدة القديمة، فالفريق على بُعد استقالة أو إجازة واحدة من أزمة. الهدف نشر المعرفة دون إبطاء الجميع إلى الزحف.

## آليات عملية

- **code review بنيّة واضحة.** المراجعات ليست مجرد بوابات؛ إنها نقل معرفة. أتأكّد ألا تُراجَع أي منطقة من قِبل من كتبها فقط.
- **pairing وتدوير على الأنظمة الحرجة.** أُسند العمل في المناطق عالية المخاطر عمداً لشخص ثانٍ، حتى عندما يستطيع الخبير فعله أسرع. كلفة قصيرة المدى، تأمين طويل المدى.
- **توثيق يستحق وجوده.** ليس wikis شاملة لا يقرؤها أحد، بل الأشياء الحامِلة للأحمال: runbooks، قرارات معمارية، "كيف تعمل deploy"، "ماذا تفعل عندما يتعطّل X".
- **دورة on-call.** لا شيء ينشر المعرفة التشغيلية أسرع من تناوب الجميع على مسؤولية production.
- **محادثات داخلية / brown bags.** مالك نظام فرعي صعب يشرحه للفريق.

## كيف أجد الخطر

- ارسم خريطة الملكية بصدق: لكل نظام حرج، اسأل "من غيره يستطيع التعامل مع هذا لو غاب X لأسبوعين؟". إذا كانت الإجابة "لا أحد"، فذلك خطر مُعلَّم.
- راقب **نمط البطل** — الشخص الذي يُستدعى دائماً، وهو الجواب دائماً. تلك علامة تحذير، لا قوة.

## مزالق

- **الاكتناز كأمان وظيفي.** بعض المهندسين (وبعض المديرين) يحبّون أن يكونوا لا غنى عنهم. أُعيد صياغة ذلك: كونك عنق الزجاجة يعيق ترقيتك الخاصة وإجازتك.
- الإفراط في التصحيح إلى "الجميع يفعل كل شيء"، ما يدمّر العمق. الهدف عدم وجود نقطة فشل وحيدة، لا انعدام التخصص.
- كتابة التوثيق مرة وتركه يتعفّن؛ التوثيق القديم أسوأ من لا شيء.

## لماذا يهم

تقليل الـ bus factor يحمي التسليم ضد المرض والإجازات والاستقالات، ويحرّر أقوى أفرادك لينموا بدل أن يبقوا محاصرين في صيانة الشيء الذي يفهمونه وحدهم. كما يجعل الفريق أكثر صحة: الملكية المشتركة تهزم البطولات الهشة.