لماذا يحتاج فريقك إلى الحوكمة (حتى لو كنت تكره المصطلح)

فريقك ينشر التغييرات أسرع من أي وقت مضى. ما بدأ كبضع عمليات نشر في الأسبوع تحول إلى عمليات نشر متعددة يوميًا. عدد المستخدمين في ازدياد. المنتج يتحسن. الأمور تبدو جيدة.

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

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

هذه هي المعضلة التي تحاول الحوكمة حلها. ليس نوع الحوكمة الذي يضيف بيروقراطية أو يبطئ كل شيء. بل النوع الذي يساعدك في إبقاء التغييرات تحت السيطرة دون التضحية بالسرعة.

فخ المقاس الواحد الذي يناسب الجميع

يقع العديد من الفرق في نمط شائع: يطبقون نفس العملية على كل تغيير. كل طلب سحب يحتاج إلى مراجعة من مهندس أول. كل نشر يحتاج إلى اجتماع. كل تغيير يحتاج إلى موافقة من عدة أشخاص.

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

لا شيء من النتيجتين جيد. الأولى تخلق تغييرات غير خاضعة للحوكمة لم يراجعها أحد. الثانية تخلق عمليات نشر عالية المخاطر يصعب التراجع عنها.

المخاطرة ليست نفسها لكل تغيير

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

تبدأ الحوكمة الجيدة بفكرة بسيطة: كل تغيير له مستوى مختلف من المخاطرة، وهذا المستوى يحدد مقدار التدقيق الذي يحتاجه.

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

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

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

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

كيف تبدو الحوكمة عمليًا

الحوكمة ليست مستندًا يجلس في محرك أقراص مشترك. إنها مجموعة من الإجابات العملية لأسئلة يواجهها فريقك يوميًا:

• أي التغييرات يمكنني نشرها مباشرة؟
• أي التغييرات تحتاج إلى أن ينظر إليها شخص آخر أولاً؟
• أي التغييرات تحتاج إلى موافقة شخص أو فريق معين؟
• ما الفحوصات الآلية التي يجب أن تمر قبل نشر التغيير؟
• ماذا أفعل إذا تسبب التغيير في مشاكل بعد النشر؟

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

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

المهم هو أن هذه القواعد صريحة ومعروفة للجميع. عندما تكون القواعد ضمنية، يتخذ الناس افتراضات مختلفة وتنشأ الصراعات.

الهدف الحقيقي: الثقة والسرعة

الحوكمة ليست حول من لديه السلطة الأكبر. إنها حول كيف يمكن للفريق أن يكون واثقًا من أن التغييرات قد مرت بفحوصات كافية قبل الوصول إلى المستخدمين. عندما يثق الفريق في العملية، يتحركون أسرع. عندما لا يثقون في العملية، إما يبطئون أو يتجاوزونها.

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

قائمة تحقق عملية لفريقك

إذا كنت تقوم بإعداد الحوكمة لأول مرة، ابدأ بهذه الأسئلة:

• ما هي فئات المخاطرة لتغييراتك؟ (منخفضة، متوسطة، عالية)
• ما الفحوصات المطلوبة لكل فئة؟ (اختبارات آلية، مراجعة كود، موافق محدد)
• من يقرر الفئة التي ينتمي إليها التغيير؟ (الكاتب، المراجع، نظام آلي)
• ماذا يحدث عندما يسبب التغيير مشاكل؟ (عملية التراجع، الاستجابة للحوادث)
• كم مرة تراجع وتحدث هذه القواعد؟ (ربع سنويًا، بعد الحوادث)

الإجابة على هذه الأسئلة تعطيك نموذج حوكمة عملي. لا يحتاج إلى أن يكون مثاليًا من اليوم الأول. يحتاج إلى أن يكون واضحًا بما يكفي ليعرف الجميع ما يجب فعله.

الخلاصة

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