لماذا يصبح فريقك الهندسي أبطأ (حتى مع استمرارك في التوظيف)
منذ بضع سنوات، كان فريق منتج عملت معه يضم خمسة عشر مهندسًا. كانوا يُطلقون ميزات جديدة كل أسبوعين. قررت الإدارة مضاعفة حجم الفريق لتسريع الإطلاق. بعد ستة أشهر، ومع ثلاثين مهندسًا، أصبحوا يُطلقون الميزات كل ثلاثة أسابيع. الجميع كان في حيرة. المهندسون لم يكونوا كسالى. لم يكونوا أقل مهارة. شيء غير مرئي كان يُبطئهم.
هذا الشيء غير المرئي هو ما نسميه الآن العبء المعرفي (Cognitive Load). وهو السبب الرئيسي لظهور هندسة المنصات (Platform Engineering).
العمل الخفي قبل كتابة الكود
تخيل أنك مطور تم تكليفك ببناء ميزة جديدة. قبل أن تكتب سطرًا واحدًا من منطق الأعمال، تحتاج إلى:
- إعداد مستودع جديد بقواعد حماية الفرع (branch protection rules) الصحيحة
- إنشاء خط أنابيب بناء (build pipeline) وخط أنابيب اختبار (test pipeline)
- تكوين بيئة تطوير تتصل بقاعدة بيانات تطوير
- معرفة كيفية النشر إلى بيئة الاختبار (staging)
- تعلم عملية النشر إلى الإنتاج في الشركة
- فهم كيفية التراجع (rollback) إذا حدث خطأ ما
- إعداد المراقبة (monitoring) وتسجيل الأحداث (logging) لخدمتك
كل واحدة من هذه المهام تتطلب تبديل السياق (context switching). عليك أن تتذكر الأداة التي يستخدمها الفريق للتكامل المستمر (CI)، ومزود السحابة الذي يستضيف بيئة الاختبار، وإصدار قاعدة البيانات المتوافق، ومن تطلب منه الوصول إلى الإنتاج.
بالنسبة لمطور يريد التركيز على بناء ميزات يراها المستخدمون فعليًا، هذا مرهق. ولا يتعلق الأمر بالمهارة. حتى المهندسون الكبار يتباطؤون عندما يضطرون إلى التوفيق بين معرفة البنية التحتية ومنطق الميزات.
التكلفة الحقيقية: العبء المعرفي
العبء المعرفي هو مقدار الجهد الذهني المطلوب لإكمال مهمة. عندما تكتب ميزة، يعالج دماغك منطق الأعمال، وتدفق البيانات، والحالات الحدودية. هذا بالفعل كثير. أضف الآن أوامر النشر، ومتغيرات البيئة، وتكوين خط الأنابيب، وإجراءات التراجع. أصبح دماغك الآن يقسم سعته بين مجالين مختلفين تمامًا.
النتيجة متوقعة: تستغرق الميزات وقتًا أطول، وتحدث الأخطاء بشكل متكرر، ويشعر المهندسون بالإرهاق في نهاية اليوم. ليس لأنهم سيئون في وظائفهم، ولكن لأنهم مجبرون على الاحتفاظ بالكثير من الأشياء في رؤوسهم في وقت واحد.
تتفاقم هذه المشكلة مع نمو الشركة. فريق من ثلاثة إلى خمسة أشخاص يمكنه مشاركة المعرفة بشكل غير رسمي. الجميع يعرف كيف ينشر الآخرون. ولكن عندما يكون لديك عشرة فرق منتج، لكل منها تفضيلاتها الخاصة، تتضاعف الفوضى. فريق يستخدم Jenkins. وآخر يستخدم GitLab CI. وثالث يستخدم GitHub Actions. فريق ينشر مباشرة إلى الإنتاج. وآخر يتطلب ثلاثة مستويات من الموافقة اليدوية. فريق يدير Kubernetes. وآخر يستخدم أجهزة افتراضية عادية.
الآن فريق المنصة أو DevOps مرهق لأن كل فريق يحتاج إلى مساعدة بإعداد مختلف. وفرق المنتج لا تزال بطيئة لأنها تقضي نصف وقتها في البنية التحتية.
هندسة المنصات ليست أداة أخرى
هنا تدخل هندسة المنصات إلى الصورة. لكن من المهم فهم ما هي وما ليست.
هندسة المنصات ليست بناء لوحة تحكم فاخرة أو شراء أداة جديدة. إنها تحول في العقلية: البنية التحتية وخطوط الأنابيب لم تعد مشاريع جانبية تتعامل معها الفرق عندما يتوفر لديها الوقت. بل تصبح منتجات داخلية يجب تصميمها وبناؤها وصيانتها بنفس الدقة التي تُصمم بها المنتجات التي يستخدمها عملاؤك.
الفكرة الأساسية بسيطة: بدلاً من أن يبني كل فريق خط الأنابيب الخاص به من الصفر، يوفر فريق المنصة مسارًا جاهزًا للاستخدام. بدلاً من أن يتعلم كل فريق كيفية النشر إلى الإنتاج، توفر المنصة آلية نشر مختبرة وآمنة. تركز فرق المنتج على الكود والميزات. تتعامل المنصة مع عبء البنية التحتية وخطوط الأنابيب.
هذا يقلل العبء المعرفي بشكل كبير. لم يعد المطورون بحاجة إلى تذكر كيفية إعداد البيئات، أو كيفية تكوين المراقبة، أو كيفية التعامل مع التراجعات. المنصة تقوم بذلك. هم فقط يكتبون الكود ويشغلون خط الأنابيب الموجود بالفعل.
فخ المقاس الواحد الذي يناسب الجميع
ولكن هنا تفشل العديد من جهود المنصات. يحاولون فرض نفس سير العمل على جميع الفرق. هذا لا ينجح لأن الفرق لها احتياجات مختلفة. بعضها يحتاج دورات نشر سريعة. بعضها يحتاج بوابات موافقة صارمة. بعضها يستخدم قواعد بيانات أو لغات برمجة محددة تتطلب معالجة خاصة.
إذا كانت المنصة جامدة جدًا، ستتجاوزها الفرق. سيبنون حلولهم البديلة، وتعود إلى المشكلة الأصلية المتمثلة في البنية التحتية المجزأة والعبء المعرفي العالي.
المنصة الجيدة تستوعب الاختلافات دون دفع الفرق إلى إدارة كل شيء بأنفسهم. توفر مسارًا قياسيًا يغطي الحالات الشائعة، ولكنها تسمح للفرق باتخاذ الخيارات حيثما يهم الأمر. هذا هو المكان الذي يأتي فيه مفهوم المسار الذهبي (Golden Path)، والذي سنستكشفه بالتفصيل لاحقًا.
ماذا يعني هذا لفريقك
إذا كان فريقك الهندسي ينمو ولكن سرعة التسليم لا تزيد، انظر إلى العمل الخفي. اسأل مطوريك: ما الذي تحتاج إلى معرفته أو فعله قبل أن تبدأ في كتابة ميزة؟ الإجابات ستخبرك أين يكون العبء المعرفي في أعلى مستوياته.
الهدف من هندسة المنصات ليس السيطرة على الفرق. بل هو إزالة الاحتكاك الذي يُبطئهم. عندما يتم ذلك بشكل جيد، فإنه يسمح للمطورين بالبقاء في حالة التدفق (flow state)، وبناء الميزات المهمة، بينما تتعامل المنصة مع الباقي.
قائمة مراجعة عملية
قبل أن تبدأ في بناء منصة، اطرح هذه الأسئلة:
- ما المهام التي يكررها المطورون عبر كل ميزة أو خدمة؟
- ما مهام البنية التحتية التي تستغرق معظم الوقت للتعلم أو استكشاف الأخطاء وإصلاحها؟
- أين تنشئ الفرق حلولها البديلة لأن العملية الحالية لا تناسبها؟
- ما الذي سيحتاج المطور إلى معرفته لنشر خدمة جديدة من الصفر اليوم؟
- أي أجزاء من خط الأنابيب تسبب أكبر قدر من القلق أو التأخير أثناء الإصدارات؟
الخلاصة
فريقك لا يصبح أبطأ لأنهم سيئون في وظائفهم. إنهم يصبحون أبطأ لأنهم يحملون وزنًا غير مرئي. هندسة المنصات تدور حول إزالة هذا الوزن، وليس إضافة المزيد من الأدوات. ابدأ بفهم ما يعاني منه مطوروك حقًا، ثم ابنِ المسار الذي يجعل هذه المعاناة تختفي.