قرأت مؤخرًا مقالًا بعنوان صادم نوعًا ما، يتكلم عن ان الـ Product Owner قد يكون أحيانًا أحد أكبر أسباب فشل Scrum داخل الفريق.
العنوان بدا هجوميًا في البداية، لكن مع القراءة المتأنية اتضح أن المقصود ليس كل الأشخاص في هذا المكان، بل الطريقة التي يفهمها ويمارسها الشخص لدوره في بيئة العمل.
المقال يرى أن المشكلة ليست في المنهجية، بل في سوء وضعنا للدور او ممارسته داخل الفريق والمنظمة.
وأنا أرى أن الطرح مهم، لكنه يحتاج إلى تفكيك أعمق، لأن ما يظهر كسلوك فردي غالبًا ما يكون انعكاسًا لبنية تنظيمية غير متوازنة.
المشكلة الأولى: غياب الرؤية الواضحة وتحول الـ Backlog إلى قائمة طلبات (وخلاص)
المقال يرى أن أول وأخطر انحراف يحدث عندما يتحول الـ Product Owner من مالك رؤية إلى مدير قائمة مهام Tasks List.
ثم يصبح الـ Backlog مجموعة Features متراكمة (كركبة وخلاص) دون رابط استراتيجي واضح او رؤية واضحة (احنا ليه بنعمل ال feature ديه)، وكل Sprint يصبح استجابة سريعة لطلب جديد، دون دراسة او متابعة للرؤية (يعني نعمله علشان نرضي حد وخلاص دون مراعاة للرؤية). الفريق يعمل (وشكرا)، لكن لا يعرف إلى أين يتجه المنتج فعليًا.
أنا أرى أن هذه المشكلة لا تتعلق فقط بوضوح الرؤية، بل بقدرة الـ PO على ربط كل عنصر بقيمة قابلة للقياس (يعني هل بيربط دايما الرؤية مع المهام ولا عبيلو واديلو).
فالرؤية ليست جملة ملهمة تُعلق على الحائط، بل إطار و قرار يُستخدم يوميًا.
الحل هنا ليس كتابة Vision Statement فقط، بل بناء نظام يربط كل Feature بنتيجة واضحة، سواء كانت زيادة Retention أو تقليل Churn أو تحسين تجربة محددة. بدون هذا الربط، يتحول المنتج إلى مشروع مستمر لا نهاية ولا هدف له.
المشكلة الثانية: محاولة إرضاء جميع أصحاب المصلحة (رييح الزبون)
المقال يشير إلى أن الـ Product Owner كثيرًا ما يقع في فخ إرضاء الجميع (اربط الحمار مطرح ما يقولك صاحبه)، فيستجيب لكل طلب ويضيف كل اقتراح، فيتضخم الـ Backlog ويتشتت الفريق. النتيجة أن الأولويات تتغير باستمرار، ويختفي التركيز (وكل حاجة والله).
من وجهة نظري، هذه ليست فقط مشكلة شخصية في قول “لا”، بل مشكلة غياب إطار واضح لتحديد الأولويات. عندما لا توجد معايير شفافة، يتحول النقاش إلى جدل سياسي (وفي الاخر هو انا هالبس لوحدي؟)
الحل لا يكمن في الصرامة فقط، بل في بناء آلية موضوعية لتقييم الأولويات (الصح فين جدعان)، مثل استخدام معايير Impact مقابل Effort، أو ربط كل طلب بهدف استراتيجي محدد. فعندما تصبح المعايير واضحة، يصبح رفض الطلب قرارًا مهنيًا لا شخصيًا(افهمو لا ليه).
المشكلة الثالثة: التدخل في التنفيذ وفقدان استقلالية الفريق (مدير وخلاص)
المقال ينتقد تحول الـ Product Owner إلى مدير تفصيلي يتدخل في “كيف” بدل التركيز على “ماذا” و”لماذا”. فهذا السلوك، حتى لو كان بدافع الحرص، يقلل من استقلالية الفريق ويقتل الإبداع (ويقتل اي حاجة حية)
أنا أرى أن هذه المشكلة غالبًا ما تظهر عندما لا يثق الـ PO في قدرة الفريق، أو عندما يُحاسب هو وحده على النتائج دون مشاركة حقيقية في المسؤولية. في هذه الحالة، يبدأ بالتدخل لحماية نفسه.
الحل هنا مزدوج: تمكين الفريق فعليًا، وتوزيع المسؤولية بشكل واضح. الـ PO مسؤول عن القيمة، لكن التنفيذ مسؤولية جماعية. وعندما يكون هناك وضوح في هذا التوازن، يقل التدخل تلقائيًا (كلنا في الهوا سوا).
المشكلة الرابعة: التركيز على Output بدل Outcome (كام كيلو؟)
المقال يسلط الضوء على نقطة معاصرة جدًا، وهي قياس النجاح بعدد الـ Features المنفذة بدل تأثيرها الحقيقي. الـ Sprint ينجح لأن القصص أُغلقت (الدنيا حلوة اهيه)، لكن لا أحد يسأل إن كانت قد أحدثت فرقًا فعليًا (لماذا مهمة جدا هنا).
في رأيي، هذه واحدة من أخطر الانحرافات في بيئة المنتجات الحديثة. لأن التركيز على Output يخلق وهم الإنتاجية، بينما القيمة قد تكون ثابتة أو حتى متراجعة (ومحدش واخد باله).
الحل يبدأ بتغيير طريقة القياس. بدل الاحتفال بعدد القصص، يجب ربط كل مبادرة بمؤشر أداء واضح قبل تنفيذها، ثم قياس أثرها بعد الإطلاق. المنتج ليس مصنع Features، بل منظومة تأثير مستمر.
المشكلة الخامسة: تحول الـ Product Owner إلى عنق زجاجة في اتخاذ القرار (هنضحي بيك علشان نخلص ونجيب حد غيرك)
المقال يشير إلى أن بعض الـ Product Owners يصبحون نقطة توقف دائمة للفريق، إما بسبب عدم التفرغ، أو بطء القرار، أو الرغبة في مراجعة كل تفصيلة. هذا يؤدي إلى فقدان الإيقاع الذي تعتمد عليه Scrum.
أنا أرى أن هذه المشكلة غالبًا نتيجة سوء تصميم الدور داخل المنظمة (هو تايه يا ولداه). إذا كان الـ PO يحمل عدة مسؤوليات، أو لا يمتلك صلاحيات واضحة، فمن الطبيعي أن تتباطأ القرارات.
الحل هنا تنظيمي بقدر ما هو فردي. يجب أن يكون الدور مُمكَّنًا بصلاحيات حقيقية، وأن تكون آليات اتخاذ القرار واضحة، وأن يُمنح الفريق مساحة للتحرك دون انتظار دائم.
خلاصة في العميق
المقال يرى أن الـ Product Owner قد يكون عدو Scrum عندما يسيء فهم دوره. وأنا أرى أن المسألة ليست صراعًا بين شخص ومنهجية، بل مسألة توازن بين رؤية، تمكين، وصلاحيات.
الدور في جوهره ليس إدارة مهام، بل إدارة قيمة. وليس نقل طلبات، بل خلق اتجاه. وليس التحكم في الفريق، بل تمكينه.
عندما يفهم الـ Product Owner أن مهمته الأساسية ليست إغلاق أكبر عدد من القصص، او ال features ببسرعة، بل التأكد أن كل قصة تستحق أن يتم وضعها من الأساس، عندها فقط يتحول من عنق زجاجة إلى بوصلة حقيقية للفريق.
