من يقرر ما يصل فعليًا إلى مستخدميك

لديك خط أنابيب يعمل. الاختبارات ناجحة. مراحل البناء خضراء. زر النشر أمامك مباشرة، ينتظر. لكن لا أحد يضغط عليه.

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

هناك دوريان يتوليان هذا القرار: مدير المنتج ومدير الإصدار. ليسا نفس الشخص، ولا يؤديان نفس المهمة. لكن معًا، يجيبان على السؤال الذي لا يستطيع نظام CI/CD الخاص بك الإجابة عليه: "هل يجب أن يخرج هذا الآن؟"

مدير المنتج يقرر ما سيُبنى

مدير المنتج لا يكتب كودًا ولا يدير خطوط الأنابيب. وظيفته هي فهم ما يحتاجه المستخدمون والأعمال فعليًا، ثم ترجمة ذلك إلى عمل لفريق الهندسة. في سياق CI/CD، هذا الدور مهم قبل كتابة سطر واحد من الكود.

يقرر مدير المنتج أي ميزة تدخل في السباق التالي، وأيها تُؤجل، وأيها تُسقط بالكامل. هذا القرار يؤثر بشكل مباشر على سلاسة تسليمك.

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

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

مدير الإصدار ينسق موعد الخروج

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

ما الذي ينسقه مدير الإصدار فعليًا؟

أولاً، جدول الإصدار. هل يستخدم الفريق جدولًا ثابتًا، مثل كل خميس الساعة 2 ظهرًا؟ أم أنهم يصدرون بمجرد اكتمال الميزة؟ كلا النهجين يعملان، لكن مدير الإصدار يتأكد من أن الجميع يعرف أي منهما ساري المفعول.

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

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

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

كيف يعمل هذان الدوران مع فريق الهندسة

مدير المنتج ومدير الإصدار لا يعملان بمعزل عن الآخرين. يتفاعلان مع فريق الهندسة باستمرار.

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

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

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

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

هذان الدوران ليسا حراس بوابة

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

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

يمنع مدير المنتج السيناريو الأول بالتأكد من أن الفريق يبني الشيء الصحيح. يمنع مدير الإصدار السيناريو الثاني بالتأكد من أن المؤسسة جاهزة لاستقبال الإصدار الجديد.

قائمة تحقق عملية لمديري المنتج والإصدار

إذا كنت تتولى أيًا من هذين الدورين، أو إذا كنت تعمل مع أشخاص في هذه الأدوار، إليك قائمة تحقق قصيرة للحفاظ على سلاسة التسليم:

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

الخلاصة

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