ما هو Agile Product Owner الدليل الكامل لقادة المنتجات الرقمية

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

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

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

هناك العديد من الأدوار في فريق Scrum. دور واحد، Agile Product Owner (PO)، مسؤول عن إدارة Product Backlog لتحقيق النتيجة المرغوبة للفريق. دور PO هو مهم عندما يتعلق الأمر بالجودة. هذا هو العضو الوحيد في الفريق الذي يتم تفويضه لقبول أي قصة كما هي.

بالنسبة لمعظم الشركات التي تتحول إلى العملية Agile، دور PO هو دور جديد وحيوي. تقوم معظم الشركات بتوظيف Product Owner بدوام كامل لدعم فريق Agile. علاقات ومسؤوليات PO ليست فقط مهمة ولكن تمتد وراء الفريق المحلي. كما يعملون مع باقي فريق إدارة المشروع، والعملاء، وأصحاب المصلحة.

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

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

يقضي Product Owner الكثير من الوقت مع الفريق، موضحًا عناصر Product Backlog وقرار العناصر التي يجب القيام بها، استنادًا إلى تفاصيل المنتج."

الأخطاء الشائعة

قد يكون من الصعب على شخص القيام بوظيفة product owner. يجب عليهم اتخاذ جميع القرارات بشأن المنتج، ومعرفة احتياجات الأعمال للمنتج، وقضاء وقت كبير مع Scrum Team.

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

النسبة المثلى لـ Product Owner إلى Scrum Team هي 1:1 - Product Owner واحد لـ Scrum Team واحد. تتعرض النسبة للانتهاك إذا كان أكثر من فريق واحد يعمل على نفس المنتج في نفس الوقت. ينتهي الأمر بـ product owner بالعمل مع فرق متعددة.

المشكلة في هذا النموذج هي أن فريقًا واحدًا غالبًا ما يتم تجاهله من قبل الـ PO.

إذا كان لدى product owner الكثير من المسؤوليات، فهم ليسوا متاحين بسهولة لـ Scrum Team. يمكن أن يسبب ذلك العديد من المشكلات والتأخيرات للفريق لأنهم لا يستطيعون الحصول على إجابات لأسئلتهم أو اتخاذ القرارات في الوقت المناسب. وهذا معروف باسم product owner غائب.

الفرق التي تجد نفسها بحاجة إلى product owner أكثر مما يمكن للـ PO تقديمه، يمكنها تعيين product owner بديل. يمكن تعيين الوكيل من قبل product owner الحالي أو الفريق.

ومع ذلك، العديد من الفرق لا تحب هذا النهج لأن product owner يمكنه تجاوز قرارات الوكيل في أي وقت. غالبًا ما يتجاوز الـ PO الفعلي الوكيل في الوقت الذي يكون فيه الأمر أكثر إزعاجًا للفريق."

مسؤوليات Agile Product Owner

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

هناك سبع مسؤوليات شائعة لكل Product Owner:

التوافق على الرؤية

Product Owner مسؤول عن تحديد الأهداف وإنشاء رؤية الفريق. يجب أن يتم التواصل بوضوح مع الرؤية مع جميع الأشخاص المعنيين في المشروع بما في ذلك Scrum Team، وأصحاب المصلحة، وفريق إدارة المشروع. تُستخدم الرؤية لتحديد الأولويات وتوجيه قرارات الفريق.

إدارة Product Backlog

Product Owner يولد ويدير قائمة الأعمال التي يجب القيام بها من قبل Scrum Team. يجب عليهم كتابة عناصر product backlog ومعايير القبول لكل منها، ثم ترتيب العمل لضمان تحقيق رؤية المنتج.

يجب أن يتم جعل product backlog مرئيًا حتى يتمكن الجميع من الاطلاع عليه. بهذه الطريقة، يمكن لـ product owner تحسين أداء العمل والتأكد من أن أصحاب المصلحة يفهمون بوضوح الاستراتيجية وخريطة التطوير.

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

 ملكية المالية

Product owner مسؤول عن توفير أفضل عائد على الاستثمار. هم مسؤولون عن جميع القرارات الاقتصادية خلال إصدار الsprint ومستوى المنتج. يمكن تعديل المثلث الحديدي للنطاق - الميزانية، الوقت، والجودة - وفقًا للحاجة. يمكن أيضًا استخدام التكلفة والفائدة لكل product backlog لتحديد ترتيب العمل.

مسؤوليات الفريق

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

تحديد القيود

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

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

تحديد الأولويات للمهام

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

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

مشاركة في أحداث التطوير

Product owner يلعب دورًا مهمًا في أحداث التطوير مثل الخطط، التنقيح، المراجعات، والاستعراضات الخاصة بالsprint والscrum اليومية.

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

خلال جلسات التنقيح الأسبوعية، يعمل PO مع Scrum Team لتحديد، وتوضيح، وتقدير، وترتيب، وحذف عناصر product backlog.

يتعاونون مع الفريق لتحديد الإجراءات التالية المطلوبة لتحسين العمل. خلال الsprint، يعمل PO مع Scrum Team؛ الإجابة على الأسئلة وقبول product backlog المكتملة.

ومع ذلك، product owner هو الوحيد الذي لديه السلطة لإضافة أو إزالة العمل، أو إلغاء الsprint، أو إيقاف تطوير المشروع. يمكنهم حضور الscrum اليومية لتنسيق والتعاون مع الفريق حول العمل الذي يتم القيام به في الsprint.

خصائص Product Owner

Product Owners يشتركون في خمس خصائص مشتركة:

متاح ومشارك

Product owner مشارك بشكل كامل في المشروع. يعملون مع Scrum Team يوميًا؛ يجيبون على الأسئلة، وهم متاحون عندما تظهر مشكلات قد تؤخر المشروع.

مفوض له

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

حازم

يجب على product owner الإجابة على أسئلة الفريق بسرعة وبصلاحية. يمكن أن تؤدي التأخيرات إلى منع العمل من الانتهاء في الوقت المحدد. سيؤدي عكس القرارات السابقة إلى خلق نقص في الثقة.

Product owner هو في أفضل دور لاتخاذ القرارات استنادًا إلى معرفة العميل ودعم أصحاب المصلحة.

معرفة جيدة بالمجال

Product owner يفهم احتياجات العميل المستهدف. لديهم المعرفة التجارية القوية لقيادة تطوير المنتج للفريق بينما يتنسقون مع جميع أصحاب المصلحة. لديهم شبكة دعم قوية داخل المنظمة ويمكنهم تطوير علاقات جيدة مع العملاء وموردي الأطراف.

تواصل رائع

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

7 مهارات لـ Product Owner رائع

مسرور العملاء

Product owners ليسوا مجرد مسؤولين إداريين، ولكنهم أيضًا يسعون لإسعاد العملاء. بينما من المهم الاستماع إلى أصحاب المصلحة وتغيير الباكلوج وفقًا لذلك، من المهم أيضًا الاستماع إلى العميل واكتشاف احتياجاتهم.

الروائي

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

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

المفوض

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

"يجب على الفرق تفويض المهام وبناء فريق غير رسمي مفيد إذا أرادوا البقاء والازدهار. انتظر، هل يبدو ذلك مثل Scrum Team؟ نعم ولا. يمكنك اختيار تضمين Scrum Master وأعضاء Scrum Team المختلفين إذا كنت ترغب في ذلك. ولكن فريق product owner غير الرسمي سيساعدك في مسؤوليات متنوعة، خاصة إذا لم تكن خبيرًا في بعض المجالات.

المطور

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

كـ product owner، من السهل التفكير "أنا أمتلك product backlog. أمتلك قصص المستخدمين. أعطيهم لـ Scrum Team وهم يطورونها." قد يكون هذا صحيحًا، ولكنك لا تزال جزءًا من فريق؛ ليس فقط قائد الفريق.

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

وسيط المعرفة

بينما أنت مطور، أنت أيضًا وسيط للمعرفة. قد تمثل product backlog، وتعمل كواجهة بين Scrum Team وأصحاب المصلحة، ولكن هذا لا يعني أنك خبير في المنتج. إذا كان المطورون يكتبون الكود، قد لا يحصلون على الكثير من خلال التحدث إليك.

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

حل النزاعات

أي شخص لا يستطيع التعامل مع النزاع لا يجب أن يكون product owner. في تطوير المنتج، ستتعامل مع مواقف مليئة بالنزاعات، خاصة عندما يتقاتل الناس بسبب الموارد والسياسات. امتلاك مهارات قوية في حل النزاعات مهم لوقف التصاعد.

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

التصعيد الفعال

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

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

بحلول الوقت الذي تحدث فيه المشكلات الكبيرة، ستكون جاهزًا ومرتاحًا للتعامل معها. هناك العديد من المهارات التي يمكنك زراعتها كـ product owner. ولكن هذه الصفات السبع ستمنحك تقدمًا في دورك.

التحول Agile: Product Owner مقابل Agile Business Analyst

"تعد واحدة من أولى التحديات التي تواجه الشركات عند التحول إلى Agile هي فهم الأدوار الجديدة التي تحتاج إلى دعم مبادرتهم. دور Product Owner هو الأكثر أهمية، ولكنه أحدث مفهوم للشركات لفهمه. السؤال الشائع الذي تسأله الشركات غالبًا هو: "ما الذي يجعل هذا الدور Product Owner مختلفًا عن Agile Business Analyst؟" الاختلافات بين الدورين مهمة. فهم هذه الاختلافات أمر بالغ الأهمية لنجاحك.

دور Product Owner هو تجميع لعدة أدوار - ممثل الأعمال، محلل الأعمال، مدير المشروع، وأدوار أخرى. يتم دمج الأدوار في دور واحد لدعم نهج Scrum. تم تصميمه لتوفير مستوى معين من المسؤولية التي لا توجد وإلا.

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

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

إذاً، لماذا تدريب Product Owner على كتابة القصص وتحديد معايير القبول عندما يكون لديك بالفعل Business Analyst الذي لديه نفس المهارات؟ الإجابة هي المسؤولية. عندما يمتلك مورد الأعمال المحتوى من كل sprint، لا يوجد أحد للعب لعبة اللوم، لذا هناك احتكاك أقل بين IT ومديري المشاريع.

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

في Scrum، شخص واحد فقط هو المسؤول عن تحديد وقبول القصص. ولا يمكنني التأكيد بما فيه الكفاية على أهمية عدم تقسيم تلك المسؤوليات.

بالإضافة إلى المسؤولية، الاتصال أيضًا مهم. عندما يأتي product owner من الأعمال، هناك فرصة أفضل أن يكون الاتصال بين Product Owners ومديري المنتج أكثر طبيعية وسلاسة."

سيجعل هذا من الأسهل على الفريق حل المشكلات مع الحفاظ على التوافق مع أهداف الأعمال. سيكون هناك أيضًا مفاجآت أقل خلال عروض sprint. يمكن لـ Product Owner حرفيًا "الجلوس" مع فريق Scrum ثم الإبلاغ بفعالية إلى Product Manager؛ مما يسد الفجوة بين قسم الأعمال وقسم IT.

عندما تعمل الشركة مع كل من Product Owner و Agile Business Analysts، يمكنهم أخذ وجهة نظر شاملة في حل المشكلات. يوفر Product Owner نهجًا مركزًا على المستخدم بينما يستخدم Business Analyst نهجًا مركزًا على النظام. يكتشف Product Owner ما يريده المستخدم، ثم يقرر أفضل طريقة لتقديم أفضل قيمة، بينما يحدد Business Analyst الحالات، وشروط الخطأ، والتبعيات، والتأثيرات على مناطق أخرى من النظام أو أنظمة أخرى.

لا شك في أن Business Analyst يوفر قيمة كبيرة للفريق، ولكن يجب على Product Owner الاحتفاظ بحقوق حصرية في قبول القصص وإدارة الأولويات للحفاظ على المسؤولية.

في الختام

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

بمجرد تحديد الشخص المناسب، أوصي بإرسال المرشح للتدريب المبدئي، وتدريب على الأدوات، والتوجيه المستمر.

لنجاح هذا الدور الجديد، يجب أن تحترم المنظمة بأكملها قرارات Product Owner. يجب أن تكون جميع القرارات واضحة في المحتوى وترتيبات Product Backlog.

آمل أن يكون هذا المنشور قد أظهر لك المسؤوليات والمهارات الواضحة لـ Product Owner.

هل أعجبك هذا المقال؟

نمكّن القادة من أن يصبحوا ذوي قيمة عالية ومعترف بهم من خلال تكييف شركتهم المركزة على المشروع إلى شركة موجهة نحو المنتج، تغيرت المجتمع ويحتاج القادة إلى دعم لتكييف شركاتهم للعصر الرقمي، هذا هو السبب في خلق ADAPT Methodology®!

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

إذا كنت تريد معرفة كيف يمكننا مساعدتك في بدء التحول الخاص بك، يرجى مراجعة: تدريب المشروع إلى المشروع.

إذا كنت مهتمًا في إجراء تحول في شركتك، يرجى مراجعة: الاستشارات من المشروع إلى المنتج.