إدارة المنتج: ماذا يفعل مدير المنتج Product Manager؟

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

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

• ماذا يفعل مدير المنتج فعلاً، وكيف يختلف عن مدير المشروع وعن مالك المنتج في Scrum، مع جدول يقارن بينهم.
• الفرق بين المخرجات Outputs والنتائج Outcomes، ولماذا تقيس الفرق الجيدة الثانية.
• الرؤية Vision والاستراتيجية Strategy وخارطة الطريق Roadmap دون وعود بتواريخ لا يعرفها أحد.
• ترتيب الأولويات Prioritization بطريقتي RICE وتكلفة التأخير Cost of Delay، والتعامل مع أصحاب المصلحة Stakeholders.
• أدوات وتقنيات إدارة المنتج مفتوحة المصدر، والأخطاء التي تحول فريق المنتج إلى مصنع للميزات Feature Factory.

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

ماذا يفعل مدير المنتج Product Manager؟

أبسط تعريف عملي أن مدير المنتج مسؤول عن أن يكون ما يبنيه الفريق يستحق البناء، أي أن يحل مشكلة حقيقية لمستخدمين حقيقيين بطريقة تنفع العمل أيضاً. ويكتب Marty Cagan من شركة SVPG، وهو من أكثر من كتب عن هذا الدور، في مقاله Behind Every Great Product سنة 2016 أن الدور أقرب ما يكون إلى دور المدير التنفيذي للمنتج CEO of the Product، وأن على مدير المنتج أن «يضمن نتيجة للعمل، لا أن يضمن فقط أن المنتج تم تعريفه» (ensure a business outcome, not just ensure a product gets defined). ولذلك يحتاج إلى أن يعرف المستخدمين والبيانات والسوق وطريقة عمل الشركة نفسها، من المبيعات إلى التكلفة.

ويصف دليل الخدمات الحكومية البريطاني GOV.UK Service Manual نفس الدور بلغة أبسط: مدير المنتج يتأكد أن الخدمة تلبي احتياجات المستخدمين، وأنها تتوافق مع أولويات الجهة، وبجانبه دور آخر اسمه مدير التسليم Delivery Manager مسؤول عن إزالة العوائق وتهيئة طريقة العمل للفريق، أي أن الدليل نفسه يفصل بين «ماذا ولماذا» و«كيف نصل إليه».

وفي العمل اليومي يقضي مدير المنتج وقته في أشياء لا يراها المطور غالباً:

• الحديث مع المستخدمين والعملاء، وقراءة تذاكر الدعم Support Tickets، ومراجعة ما يقوله فريق المبيعات عن أسباب خسارة الصفقات.
• قراءة البيانات: كم مستخدماً جرب الميزة الجديدة، وكم منهم عاد إليها، وأين يتوقف المستخدمون في التسجيل Sign-up.
• كتابة المشكلة والهدف بوضوح قبل أن يتحدث أحد عن الحل، وهذا ما شرحناه في بيان المشكلة.
• ترتيب الأولويات وقول «لا» أو «ليس الآن» لأغلب الطلبات، مع السبب.
• العمل مع المصمم والمهندسين على اكتشاف الحل Product Discovery، وهو موضوع المقال التالي في هذه المرحلة.

إدارة المشروع Project Management وإدارة المنتج Product Management

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

والجدول التالي يضع الفروق في نقاط محددة:

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

ومالك المنتج Product Owner؟

مالك المنتج ليس وظيفة ثالثة بالمعنى نفسه، وإنما مسؤولية Accountability في إطار Scrum، ويقول دليل Scrum إنه مسؤول عن تعظيم قيمة المنتج الناتجة عن عمل فريق Scrum، وعن إدارة قائمة المنتج Product Backlog وهدف المنتج Product Goal، وإنه شخص واحد وليس لجنة. وقد شرحنا المسؤوليات الثلاث في Scrum وما يعنيه كل منها في مقال Agile بلا شعارات، فلن نكررها هنا.

والعلاقة العملية بين الاسمين كما يلي: في كثير من الشركات التي تعمل بScrum يحمل مدير المنتج مسؤولية مالك المنتج لفريق أو فريقين، فيكون «مدير المنتج» هو المسمى الوظيفي Job Title و«مالك المنتج» هو المسؤولية داخل Scrum. والمشكلة تبدأ عندما يكون مالك المنتج شخصاً يكتب التذاكر ويرتبها فقط، ولا يتحدث مع مستخدم ولا يقرأ رقماً، وعندها يصبح مدير قائمة Backlog Administrator، وهذا من الأخطاء التي سنعود إليها في آخر المقال.

المخرجات Outputs والنتائج Outcomes

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

وقد يبدو هذا الفرق نظرياً، ولكنه يغير طريقة العمل كلها، والسبب أن الفريق الذي يقاس بالمخرجات سوف يسلم أكبر عدد ممكن من الميزات، والفريق الذي يقاس بالنتائج سوف يسأل قبل كل ميزة: ما الذي يجب أن يتغير، وكيف سنعرف؟ ويصف Cagan في مقال Product vs. Feature Teams سنة 2019 نوعين من الفرق: فريق الميزات Feature Team الذي تعطيه الإدارة قائمة ميزات وتواريخ فيسلمها، ومدير المنتج فيه أقرب إلى مدير مشروع، وفريق المنتج المخول Empowered Product Team الذي تعطيه الإدارة مشكلة ونتيجة مطلوبة، ويقرر هو كيف يصل إليها، ويحاسب على النتيجة. والاختبار الذي يقترحه بسيط: هل يعطى فريقك مشكلات أم ميزات؟ وهل خارطة الطريق فيها تواريخ ميزات أم نتائج؟

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

الرؤية Vision والاستراتيجية Strategy وهدف المنتج Product Goal

الرؤية Product Vision هي الصورة التي يتجه إليها المنتج بعد سنوات، وتكتب في جملة أو جملتين يفهمها الجميع، ولا تذكر تقنية ولا ميزة. والاستراتيجية Product Strategy هي الاختيارات التي تقربك من الرؤية في السنة القادمة: أي مستخدمين تخدم أولاً، وأي مشكلة تحلها أولاً، وما الذي لن تفعله. أما هدف المنتج Product Goal في دليل Scrum فهو هدف واحد قريب يعمل عليه الفريق الآن، وتتبعه قائمة المنتج كلها. ولنأخذ مثال العيادة:

الرؤية:
  أن يحجز أي مريض موعده في أي وقت ومن جواله، وأن يعرف كل طبيب يومه
  دون مكالمة واحدة من الاستقبال.

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

هدف المنتج للربع القادم:
  أن تنخفض نسبة المواعيد التي لا يحضر أصحابها في العيادات التجريبية
  من القيمة التي نقيسها الآن إلى النصف.

في الإعداد أعلاه لاحظ التالي:

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

خارطة الطريق Roadmap دون وعود بتواريخ

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

والطريقة الأنسب التي انتشرت في السنوات الأخيرة هي خارطة Now Next Later، وتقول شركة ProdPad في مقال I invented the Now-Next-Later roadmap إن Janna Bastow بدأت بها في حدود سنة 2012، وفكرتها أن تقسم العمل إلى أفق زمني بدل تواريخ: «الآن» لما يبنى الآن بتفاصيله، و«التالي» لما سيأتي بعده وشكله واضح وتفاصيله ليست كاملة، و«لاحقاً» لمشكلات وأفكار نعرف أنها مهمة ولم نقرر حلها. والصورة التالية تبينها على مثال العيادة:

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

ترتيب الأولويات Prioritization: RICE وKano وتكلفة التأخير Cost of Delay

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

الأولى RICE، ونشرها Sean McBride من شركة Intercom في مقال RICE: Simple prioritization for product managers سنة 2018، وهي أربعة عوامل:

• الوصول Reach: كم شخصاً سيتأثر في فترة محددة، مثل عدد المرضى في الربع.
• الأثر Impact: كم سيؤثر على كل شخص، بمقياس ثابت: 3 أثر كبير جداً، و2 كبير، و1 متوسط، و0.5 قليل، و0.25 قليل جداً.
• الثقة Confidence: كم أنت واثق من تقديراتك: 100% عالية، و80% متوسطة، و50% منخفضة، وما تحتها تخمين.
• الجهد Effort: كم شهر عمل لشخص واحد Person-months يحتاج.

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

والطريقة الثانية تكلفة التأخير Cost of Delay، وهي من أعمال Don Reinertsen في اقتصاديات تطوير المنتجات، وتشرحها صفحة Black Swan Farming بأنها أثر الوقت على النتائج المتوقعة، أي كم تخسر كل أسبوع لا تكون فيه الميزة عند المستخدمين. وعندما تقسم تكلفة التأخير على مدة العمل تحصل على ما يسمى CD3، وترتب العمل من الأعلى إلى الأقل. والصورة التالية تبين الطريقتين، الأولى على مثال العيادة والثانية على مثال الصفحة نفسها:

في الصورة أعلاه لاحظ التالي:

• الدفع الإلكتروني أخذ أقل نتيجة رغم أن العميل طلبه، والسبب أن الثقة منخفضة لأن أحداً لم يسأل المرضى عنه، والجهد كبير بسبب التكامل مع بوابة الدفع.
• في مثال CD3 من Black Swan Farming، العمل A أكبر عمل وأقل تكلفة تأخير، فإذا بدأت به لأنه وصل أولاً، فإن العملين الأغلى ينتظران خمسة أسابيع، ومجموع التكلفة 69 ألفاً، وإذا رتبت بحسب CD3 تصبح 27 ألفاً.
• في الطريقتين أغلب الأرقام تقدير، وقيمتها الحقيقية أنها تجبر الحاضرين على أن يقولوا افتراضاتهم بصوت عال، فإذا قال أحدهم إن أثر الدفع الإلكتروني 3، فسوف يسأله الآخرون: كيف عرفت؟

أصحاب المصلحة Stakeholders: قل «لا» مع السبب

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

• كل طلب يتحول إلى مشكلة قبل أن يدخل القائمة، فإذا قالت المبيعات «نريد تصدير Excel» فإن السؤال هو: ماذا يفعل العميل بالملف بعد تصديره؟ وقد تكون الحاجة تقريراً أسبوعياً يرسل تلقائياً.
• الرفض يكون مع السبب ومع الاستراتيجية المكتوبة، فعبارة «لا نبني الفواتير هذه السنة كما في الاستراتيجية، وهذا ما نفعله بدلاً منها» أسهل على الطرفين من «ليس لدينا وقت».
• الشفافية في الترتيب، أي أن تكون خارطة الطريق والقائمة مفتوحة لمن يطلب، ومعها سبب الترتيب، والسبب أن أصحاب المصلحة يقبلون «ليس الآن» عندما يرون ما الذي جاء قبل طلبهم ولماذا.

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

أدوات وتقنيات إدارة المنتج مفتوحة المصدر Open Source

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

الأدوات بحسب الغرض

قرأنا ملف الترخيص في المستودع الرسمي لكل أداة في أكتوبر 2026، ولاحظ أن عدداً منها يجمع بين ترخيص مفتوح للجزء الأساسي وترخيص تجاري لمجلد الميزات المؤسسية:

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

تقنيات تربط العمل بالهدف

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

• خريطة قصص المستخدم User Story Mapping: يصفها Jeff Patton في صفحته وفي كتابه User Story Mapping بأنها حديث عن مسار المستخدم في المنتج ببناء نموذج بسيط يحكي قصته، فتضع الأنشطة الكبيرة في صف علوي يسمى العمود الفقري Backbone، وتحت كل نشاط القصص الصغيرة، ثم ترسم خطاً أفقياً يحدد أول إصدار Release يعمل من البداية إلى النهاية. والفائدة أنها تمنعك من بناء نشاط واحد بالكامل قبل أن يعمل المسار كله.
• خريطة الأثر Impact Mapping: من كتاب Gojko Adzic الصادر في أكتوبر 2012، وتبدأ كما في موقعها الرسمي بسؤال لماذا Why أي الهدف، ثم من Who يمكنه أن يؤثر عليه، ثم كيف How يجب أن يتغير سلوكه، ثم ماذا What نبني لندعم هذا التغيير. والفائدة أن كل ميزة في الأسفل لها سلسلة سببية مكتوبة إلى الهدف، فالميزة التي لا تتصل بشيء تحذف.
• شجرة الفرص والحلول Opportunity Solution Tree: من Teresa Torres وكتابها Continuous Discovery Habits، وتبدأ كما في صفحتها بنتيجة واحدة، ثم الفرص Opportunities وهي احتياجات المستخدمين ومشكلاتهم، ثم الحلول لكل فرصة، ثم اختبار الافتراضات لكل حل. وسوف نستخدمها في مقال اكتشاف المنتج.
• خارطة Now Next Later: شرحناها أعلاه، وهي الطبقة التي تعرض نتيجة هذه الخرائط على الإدارة.
• الأهداف والنتائج الرئيسية OKRs: بحسب موقع What Matters بدأها Andy Grove في Intel ونقلها John Doerr إلى Google سنة 1999، وفيها هدف Objective يصف ما تريد الوصول إليه، ومعه من ثلاث إلى خمس نتائج رئيسية Key Results قابلة للقياس. وفي إدارة المنتج يكون الهدف قريباً من هدف المنتج، والنتائج الرئيسية نتائج Outcomes لا قائمة ميزات، فإذا كتبت «إطلاق التذكير» كنتيجة رئيسية فقد رجعت إلى المخرجات.

أخطاء شائعة تحول فريق المنتج إلى مصنع ميزات Feature Factory

نشر John Cutler في نوفمبر 2016 مقالاً بعنوان 12 Signs You're Working in a Feature Factory، وأخذ التسمية من مطور قال له إنه يجلس في المصنع يخرج الميزات ويرسلها إلى خط الإنتاج. ومن العلامات التي ذكرها: أن الفريق لا يقيس أثر ما يسلمه، وأنه يحتفل بالإطلاق لا بالنتيجة، وأنه نادراً ما يحذف ميزة أو يعترف بأن شيئاً فشل، وأن خارطة الطريق قائمة ميزات لا نتائج، وأنه لا يعود إلى الميزة بعد إطلاقها لتحسينها، وأن الميزات تبنى لإغلاق صفقات بدل قيمة العملاء. وفيما يلي الأخطاء التي نراها أكثر من غيرها، مع ما تفعله بدلاً منها:

• مدير المنتج كمدير قائمة Backlog Administrator: يكتب التذاكر ويرتبها ويحضر الاجتماعات، ولا يتحدث مع مستخدم ولا يقرأ رقماً. والعلاج أن يكون في أسبوعه وقت ثابت للمقابلات وقراءة البيانات، وأن يتعلم الفريق كله من هذا الوقت.
• الطلبات تدخل القائمة كما هي: «العميل طلب» ليس سبباً، والعلاج أن يتحول كل طلب إلى مشكلة ونتيجة قبل أن يرتب.
• خارطة طريق بتواريخ بعيدة: كل تاريخ بعد ربع سنة تقريباً تخمين، والعلاج Now Next Later كما شرحنا.
• الرقم يتخذ القرار: RICE أو أي طريقة أخرى أداة للنقاش، والعلاج أن تكتب بجانب الترتيب سبباً بالكلمات يفهمه من يقرؤه.
• لا أحد يعود بعد الإطلاق: الميزة تطلق ثم ينتقل الفريق إلى التالية، والعلاج أن يكون في تعريف الإنجاز Definition of Done سطر يقول إن الفريق سيقرأ المقياس بعد أسبوعين أو أربعة ويقرر.
• مدير المنتج يكتب الحل والمهندسون ينفذون: هذا يضيع معرفة المهندسين بما هو ممكن ورخيص، والعلاج أن يشترك المهندسون في الاكتشاف من البداية، وهذا ما يسميه البعض هندسة المنتج Product Engineering، وهو موضوع مقال مستقل في هذه المرحلة.

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

قائمة تحقق Checklist لمن يبدأ إدارة المنتج

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• مدير المنتج مسؤول عن أن يكون ما يبنى يستحق البناء، ومدير المشروع مسؤول عن أن يسلم ما اتفق عليه في وقته، ومالك المنتج مسؤولية في Scrum لترتيب القائمة لأكبر قيمة، وقد يحملها مدير المنتج نفسه.
• المخرج ما تسلمه والنتيجة ما يتغير عند المستخدم، والفريق الذي يقيس المخرجات فقط يتحول إلى مصنع ميزات.
• الرؤية والاستراتيجية وهدف المنتج تكتب بالنتائج، والاستراتيجية الجيدة فيها ما لن تفعله.
• خارطة Now Next Later تعطي التواريخ لما يبنى الآن فقط، وطرق مثل RICE وCD3 تجعل الافتراضات مكتوبة ولا تتخذ القرار بدلاً منك.
• الأدوات مفتوحة المصدر تكفي لكل جزء من العمل، من لوحة الاقتراحات إلى التحليلات والتجارب، وتقنيات مثل خريطة القصص وخريطة الأثر وشجرة الفرص تربط كل عمل بهدف.

وفي المقال التالي في هذه المرحلة سوف نتحدث بإذن الله عن اكتشاف المنتج Product Discovery: كيف تعرف أن المشكلة حقيقية وأن الحل يعمل قبل أن يكتب الفريق سطراً واحداً من الكود.

دليلماذا تبني قبل أن تبنيه؟ اكتشاف المنتج Product Discoveryكيف تتحقق من المشكلة والحل بمقابلات ونماذج أولية Prototypes وتجارب رخيصة قبل أن يكتب فريقك سطراً واحداً من الكود.دليلمهندس المنتج Product Engineer يملك النتيجة لا المهمةماذا تعني هندسة المنتج Product Engineering كما تصفها الشركات التي تعمل بها، وكيف ينتقل المطور من تنفيذ المهام إلى امتلاك نتيجتها.دليلمقاييس المنتج Product Metrics وكيف تعرف أن الميزة نجحتكيف تختار مقياساً رئيسياً North Star لمنتجك، وتبني قمع التحويل Funnel وجدول العودة Retention من أحداث تطبيقك بأدوات تستضيفها على سيرفرك.دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.دليلAgile بلا شعارات: Scrum وKanban كما يطبقان فعلاًمن أين جاءت Agile، وكيف تعمل Scrum وKanban كما تصفها أدلتها الرسمية، وما الأخطاء التي تحولها إلى اجتماعات بلا فائدة.دليلFeature Flags: انشر الكود وفعل الميزة لاحقاًكيف يفصل ال Feature Flag بين نشر الكود وإطلاق الميزة، وكيف تطلقها لجزء من المستخدمين أولاً وتوقفها فوراً إذا تعطلت.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من دليل Scrum 2020، ومقالات SVPG، وتعريفات APM ودليل GOV.UK، ومقالات Intercom وBlack Swan Farming وJohn Cutler وProdPad، مع جدول إدارة المشروع وإدارة المنتج، وجدول أدوات مفتوحة المصدر قرأنا تراخيصها من مستودعاتها، وخمس رسومات على مثال العيادة.