أهمية أدوار المُمكّنين وحراس البوابة في فرق التطوير التقني

مقدمة: القيم المحورية في فرق التطوير

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

المُمكّنون: محرك الابتكار والإنتاجية

لطالما ترددت كلمة «التمكين» (enablement) بكثرة في مسيرتي المهنية في هندسة البرمجيات. ورغم أن تمكين شخص ما للقيام بشيء قد يحمل دلالات إيجابية وسلبية في سياقات مختلفة، إلا أنه في قطاعنا التقني، يُنظر إليه غالباً كقيمة إيجابية ومحفزة. فما الذي يميز فريق «التمكين» (enablement team)؟

عادةً، يعني ذلك تطوير وصيانة مكونات برمجية أو أنظمة تستفيد منها الفرق الأخرى. على سبيل المثال، إذا كانت شركتك تقوم بشحن برمجيات للعملاء، فمن المرجح أنك تعتمد بشكل كبير على نظام التكامل المستمر (continuous integration system). إذا تعطل هذا النظام، فإن عملية التطوير تتوقف تماماً. هنا يأتي دور فريق أو أفراد مسؤولين عن صيانته وتشغيله على مدار الساعة تقريباً. هل يمكنك تخيل شركتك تقوم بشحن منتجاتها الآن دون نظام الـ CI الخاص بها؟ إذا كانت الإجابة لا، فإن الفريق الذي يمتلك هذا النظام ويحافظ عليه هو من يُمكّنك من إنجاز عملك بفعالية.

حراس البوابة: صمام الأمان والجودة

كلمة «حارس البوابة» (gatekeeper) قد لا تكون شائعة بنفس القدر، ولكن دورها حيوي. حارس البوابة هو الشخص أو الفريق الذي تكمن وظيفته في عدم السماح لأي شخص بالدخول إلى ما يحميه، إلا وفق شروط محددة. في سياق فريق الـ CI الذي ذكرناه، فإن هذا الفريق مسؤول عن توفره، وتحديثه دورياً، وتطبيق الميزات الجديدة، وإصلاح الأخطاء، وتطبيق تصحيحات الأمان، وما إلى ذلك.

بالنظر إلى أن الجميع في الشركة يعتمد على عملهم، فمن الطبيعي أن نتوقع أن يكون لديهم دائماً الكثير من العمل المخطط له. من الشائع في العديد من الشركات أن يهتم المطورون من فرق أخرى بالمساعدة، حتى لو لم يكن ذلك جزءاً من وظيفتهم الأساسية. هنا يبرز التساؤل: هل يجب أن يكون الفريق مُمكّناً أم حارساً للبوابة؟

الموازنة بين التمكين وحراسة البوابة: سيناريوهات عملية

تخيل أنك شغوف بأنظمة الـ CI وتلاحظ مشكلة في إعدادات شركتك. إنها مشكلة تعرف كيفية إصلاحها، فتقرر المضي قدماً وتنفيذ الحل. بعد إعداد التصحيح الخاص بك (patch) للتقديم، هناك سيناريوهان مختلفان قد يحدثان، وهما مرتبطان بالقيم التي تتبناها الفرق. دعنا نرى كيف ستتطور الخطوات التالية بالنظر إلى فريقين مختلفين تماماً، الفريق أ و الفريق ب، اللذين يتمسكان بقيم مختلفة:

الفريق أ: نموذج التمكين والتعاون

• تتحدث إلى الفريق أ ويوافقون على مراجعة التصحيح الخاص بك (patch).
• يقترحون بعض التحسينات بناءً على خبرتهم، ويعملون معك لتسليمها.
• تكتسب المزيد من الرؤى حول ما يعنيه أن تكون جزءاً من الفريق فعلياً.
• فاتتك حالة حافة (edge-case) ويشيرون إليها. تعود وتصلحها وتعيد التقديم، ويتم قبول التصحيح الخاص بك أخيراً.
• يُطلعونك أيضاً على ما هو قادم في الأشهر القادمة في حال عثرت على مشكلات أخرى.

الفريق ب: نموذج حراسة البوابة الصارم

• ترسل التصحيح الخاص بك إلى الفريق ب.
• لا تسمع أي رد لعدة أيام، فتقرر التواصل شخصياً.
• يخبرونك أنهم غارقون في العمل وليس لديهم وقت للنظر في اقتراحك.
• تستمر في محاولة إقناعهم بأنها إصلاح صغير يحسن بشكل كبير تجربة المطورين (developer experience)، لكنهم لا يرغبون في الاستماع ويخبرونك في النهاية صراحة أنه ليس من وظيفتك التفكير في الـ CI.
• تستسلم وتعود إلى عملك. بعد ستة أشهر، يقومون بإصلاح المشكلة ولكنك تكتشف ذلك بالصدفة فقط.

الفريق ب هو ما أسميه فريق حراسة البوابة، على الرغم من أن مهمتهم الرسمية هي التمكين، تماماً مثل الفريق أ. إنهم لا يسمحون للناس بالدخول إذا لم يكن عليهم ذلك. هذا الفريق نادراً ما يستفيد من خبرات الغرباء. إنه يشبه إلى حد كبير مقارنة البرمجيات الاحتكارية (proprietary software) بالمفتوحة المصدر (open source). ولكن بينما أنا متأكد من أنك تفضل التفاعل مع الفريق الأول، قد يكون من المفيد النظر في وجهة نظرهم أولاً قبل إصدار الحكم.

متى تكون حراسة البوابة مبررة؟

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

كما هو الحال في جميع أمور البرمجيات، الأمر يعتمد على السياق. ماذا لو كان الفريق ب يقوم بصيانة مكون برمجي حرج لنظام مصرفي؟ إذا كنت في مكانهم، فهل ستكون متحمساً للسماح للمساهمين الخارجيين بالدخول؟ ماذا لو كان تحسينك يحتوي على خطأ؟ إذا حدث ذلك، فهي ليست مسؤوليتك، فأنت لست في الفريق. هم من يتعين عليهم إصلاحه. أو ربما تكون برمجياتهم معقدة للغاية لدرجة أنه لا توجد طريقة لأي شخص خارجي أن يكون قادراً على المساهمة دون عملية إعداد طويلة (on-boarding process).

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

هذه بالتأكيد مواقف متطرفة وقد جعلتها تبدو كذلك لتسهيل الفهم. في الواقع، الفرق تكون مُمكّنة وحارسة للبوابة في آن واحد، اعتماداً على الموقف. لكن القيم تسود دائماً، ومن المهم فهم ذلك عندما تحتاج إلى العمل مع فرق أخرى.

الخلاصة التقنية

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