كانت الساعة الخامسة عصرًا، والهدوء يسبق العاصفة…
أذكر ذلك اليوم جيدًا، كان يوم ثلاثاء عادي في مكتبنا المزدحم. الأكواب الفارغة من القهوة متناثرة، وأصوات نقر الكيبورد تملأ المكان كأنها سيمفونية إنتاجية. كنت أراجع بعض الـ Pull Requests لمشروع ضخم نعمل عليه، مشروع يعتمد بشكل شبه كلي على نظام معقد لإدارة البيانات الضخمة. فجأة، وصل إيميل إلى كل الفريق. العنوان: “خطواتي التالية”.
المرسل كان “سامر”، مهندسنا العبقري والوحيد الذي يفهم “بالزبط” كيف يعمل ذلك النظام المعقد. هو من بناه من الصفر، وهو الوحيد الذي يعرف خباياه وأسراره. فتحت الإيميل وقلبي مقبوض، وبكلمات مهذبة ومختصرة، أعلن سامر عن استقالته وأنه سينتقل لفرصة أفضل في الخارج. آخر يوم عمل له بعد أسبوعين.
ساد صمت رهيب في المكتب. نظرنا إلى بعضنا البعض، نظرات تحمل مزيجًا من الصدمة والهلع. لم تكن المشكلة في رحيل سامر كشخص، فنحن نتمنى له كل التوفيق، بل كانت الكارثة في المعرفة التي سيأخذها معه. كان سامر هو “الصندوق الأسود” للمشروع.
في تلك اللحظة، أدركنا حجم الكارثة. لم نكن فريقًا، بل كنا مجموعة أفراد يعتمدون على بطل واحد. لو أن حافلة – لا سمح الله – صدمت سامر في طريقه إلى العمل، لكان مصير المشروع هو نفس مصير سامر. وهذا يا جماعة، هو تعريف “عامل الحافلة”.
في الأسبوعين التاليين، عشنا في جحيم. حاولنا استخلاص كل ما في عقل سامر في جلسات متفرقة وغير منظمة. كانت المعلومات تتدفق كالسيل، لكنها كانت مشتتة وغير قابلة للاستيعاب. بعد رحيله، قضينا شهورًا طويلة نحاول فك شيفرة الكود الذي تركه، وكل خطأ صغير كان يكلفنا أيامًا من البحث والتصحيح. ومن رحم تلك المعاناة، وُلد قرار غيّر طريقة عملنا إلى الأبد: لن نسمح بحدوث هذا مرة أخرى.
ما هو ‘عامل الحافلة’ (Bus Factor)؟ ولماذا هو عدوك الصامت؟
ببساطة، “عامل الحافلة” أو الـ “Bus Factor” هو مصطلح (سوداوي بعض الشيء) في عالم إدارة المشاريع يقيس عدد أفراد الفريق الأساسيين الذين إذا “صدمتهم حافلة” (أي غابوا فجأة عن المشروع لأي سبب: استقالة, مرض, إجازة طويلة)، سيتوقف المشروع أو ينهار.
إذا كان الـ Bus Factor لفريقك هو “1”، فهذا يعني أن هناك شخصًا واحدًا فقط يحمل معرفة حرجة، ورحيله المفاجئ يعني كارثة محققة. وهذا بالضبط ما حصل معنا مع سامر. الهدف دائمًا هو رفع هذا الرقم قدر الإمكان. فريق بعامل حافلة “5” هو فريق أكثر أمانًا واستمرارية من فريق بعامل حافلة “1”.
أعراض ارتفاع ‘عامل الحافلة’ في فريقك (إشارات الخطر)
كيف تعرف أن فريقك يعاني من هذه المشكلة؟ ابحث عن هذه الأعراض:
- ظاهرة “المهندس البطل”: هناك دائمًا شخص واحد فقط يمكنه الإجابة على الأسئلة الصعبة أو حل المشاكل في جزء معين من النظام. الجميع يقول: “اسأل فلان، هو الوحيد اللي بعرف”.
- الخوف من الإجازات: عندما يأخذ “المهندس البطل” إجازة، يشعر الفريق بالقلق والارتباك. وقد يتم الاتصال به أثناء إجازته لحل مشكلة طارئة.
- التوثيق الضعيف أو المعدوم: الاعتماد على الذاكرة البشرية بدلًا من التوثيق المكتوب والمنظم. “الكود يوثق نفسه” هي أكبر كذبة في تاريخ البرمجة!
- جُزر المعرفة (Knowledge Silos): كل فرد أو مجموعة صغيرة من الأفراد يعملون في عزلة تامة عن الآخرين، ولا أحد يعرف ماذا يفعل الآخر.
- بطء انضمام الأعضاء الجدد: يحتاج الموظف الجديد لشهور طويلة ليصبح منتجًا، لأنه لا يوجد مسار واضح لنقل المعرفة إليه.
الحل المنقذ: ‘جلسات مشاركة المعرفة’ (Knowledge Sharing Sessions)
بعد أزمة سامر، جلسنا كفريق وقررنا أن الحل ليس في إجبار الناس على كتابة توثيق لا يقرأه أحد، بل في جعل مشاركة المعرفة جزءًا حيويًا وممتعًا من ثقافتنا اليومية. وهكذا ولدت “جلسات مشاركة المعرفة”.
ما هي هذه الجلسات بالضبط؟
هي اجتماعات دورية (أسبوعية في حالتنا) ومنظمة، يقوم فيها أحد أعضاء الفريق بتقديم عرض عن موضوع معين هو خبير فيه. الهدف ليس فقط تقديم المعلومة، بل فتح باب النقاش والأسئلة، وتوزيع المعرفة المحصورة في عقل شخص واحد على عقول الفريق بأكمله.
أنواع جلسات مشاركة المعرفة التي طبقناها
لم نلتزم بنوع واحد، بل نوّعنا ليبقى الأمر ممتعًا ومفيدًا:
- الجلسات العميقة (Deep Dives): جلسة طويلة (ساعة مثلاً) يقدم فيها مهندس شرحًا تفصيليًا عن جزء من النظام. مثلاً، “كيف يعمل نظام الـ Caching لدينا من الألف إلى الياء”، مع كود وأمثلة حية.
- جلسات كيس الغداء (Brown Bag Sessions): جلسات غير رسمية وقت الغداء. تكون أقصر (20-30 دقيقة) وتتناول مواضيع أوسع، مثل “مكتبة جديدة جربتها الأسبوع الماضي” أو “أفضل 5 إضافات لـ VS Code”.
- استعراض الكود الجماعي (Group Code Walkthrough): نختار جزءًا معقدًا أو مهمًا من الكود، ويقوم صاحبه بشرحه سطرًا بسطر أمام الفريق. هذه الجلسات كنز حقيقي لفهم منطق العمل.
- جلسات ما بعد الحادث (Post-Mortem Sessions): عندما تحدث مشكلة كبيرة في الإنتاج، بعد حلها، نعقد جلسة ليس للوم، بل لتحليل ما حدث، وكيف تم حله، وماذا تعلمنا لنمنع تكراره.
دليل أبو عمر العملي لتطبيق جلسات مشاركة المعرفة
إذا أعجبتك الفكرة وتريد تطبيقها، إليك خطوات عملية من خبرتي الشخصية:
- الخطوة الأولى: حدد مناطق الخطر: اجلس مع الفريق وحددوا الأجزاء من النظام أو العمليات التي تعتمد على شخص واحد. هذه هي المواضيع الأولى التي يجب أن تبدأوا بها.
- الخطوة الثانية: احصل على دعم الإدارة: اشرح للإدارة مفهوم “عامل الحافلة” وكيف أن ساعة واحدة أسبوعيًا لمشاركة المعرفة ستوفر عليهم شهورًا من الألم والتكلفة في المستقبل. هذه ليست “ساعة ضائعة”، بل هي استثمار في استمرارية العمل.
- الخطوة الثالثة: ابدأ صغيرًا وبسيطًا: لا تحاول أن تفعل كل شيء مرة واحدة. ابدأ بجلسة واحدة كل أسبوعين، لمدة 30 دقيقة. اختر موضوعًا سهلاً ومقدمًا مثيرًا للحماس.
- الخطوة الرابعة: أنشئ جدولًا وقائمة مواضيع (Backlog): استخدم أداة بسيطة مثل Trello أو حتى Google Sheet لإنشاء قائمة بالمواضيع المقترحة. دع الجميع يضيف أفكارًا ويصوت على ما يهمه. هذا يخلق شعورًا بالملكية لدى الفريق.
- الخطوة الخامسة: سجّل كل شيء!: هذه أهم نصيحة. قم بتسجيل الجلسات (فيديو)، واطلب من المقدم مشاركة العرض التقديمي (Slides) وأي أمثلة كود. أنشئ صفحة مركزية على Confluence أو Notion أو حتى GitHub Wiki تحتوي على كل هذه المواد. هذا يبني لديكم كنزًا معرفيًا لا يقدر بثمن للمستقبل وللموظفين الجدد.
نصيحة من القلب: لا تجعلها إلزامية بشكل صارم في البداية. اجعلها ممتعة ومفيدة لدرجة أن الناس سيرغبون في الحضور من تلقاء أنفسهم. قدم بعض الوجبات الخفيفة، وخلق جوًا من الأمان حيث لا يخشى أحد طرح “سؤال غبي”.
مثال على توثيق جلسة
لجعل الأمر عمليًا، هذا هو القالب البسيط الذي نستخدمه لتوثيق كل جلسة على صفحة الويكي الداخلية لدينا:
# عنوان الجلسة: مقدمة إلى نظام الدفع الإلكتروني
**التاريخ:** 2023-10-26
**المقدم:** أبو عمر
**الحضور:** [قائمة الحضور]
## ملخص الجلسة
شرح مبسط لكيفية عمل دورة الدفع في نظامنا، بدءًا من إنشاء الطلب وحتى تأكيد الدفع من البوابة. تم التركيز على المكونات الرئيسية والـ APIs التي نتفاعل معها.
## تسجيل الفيديو
[رابط إلى تسجيل الفيديو على Google Drive]
## العرض التقديمي
[رابط إلى الـ Slides على Google Slides]
## نقاط النقاش والأسئلة المهمة
- سؤال من 'علي': كيف نتعامل مع فشل عملية الدفع؟
- الجواب: لدينا آلية إعادة محاولة (Retry Mechanism) مع
Exponential Backoff. التفاصيل في الدقيقة 25 من الفيديو.
- ...
## إجراءات المتابعة (Action Items)
- [ ] (أبو عمر) إضافة توثيق مفصل لآلية إعادة المحاولة في الـ Wiki.
- [ ] (الفريق) مراجعة كود وحدة الدفع بعد فهم آلية عملها.
الخلاصة: من ثقافة البطل الأوحد إلى قوة الفريق الواحد
رحيل سامر كان مؤلمًا ومكلفًا، لكنه كان أيضًا أفضل شيء حدث لفريقنا. لقد أجبرنا على مواجهة حقيقة أن اعتمادنا على الأفراد “الأبطال” هو وصفة لكارثة مؤجلة. التحول إلى ثقافة مشاركة المعرفة لم يحل مشكلة “عامل الحافلة” فحسب، بل أدى إلى فوائد لم نكن نتوقعها: أصبح أعضاء الفريق أكثر ثقة، وتحسنت جودة الكود لأن الجميع أصبح يفهم الصورة الكبيرة، وأصبح انضمام الأعضاء الجدد أسرع وأكثر سلاسة.
تذكروا يا جماعة، المعرفة المحبوسة في عقل شخص واحد هي نقطة ضعف، أما المعرفة الموزعة بين أفراد الفريق فهي قوة حقيقية. ابدأوا اليوم، لا تنتظروا “حافلتكم” القادمة. ابدأوا بجلسة واحدة، بموضوع واحد، وشاهدوا كيف يمكن لهذه العادة البسيطة أن تحول فريقكم إلى قوة لا يمكن إيقافها. 😉
