هندسة المنتجات: هل أصبح مدير المنتج أقل أهمية؟
لفترة طويلة، كان بناء المنتجات الرقمية قائمًا على تقسيم واضح للعمل:
مدير المنتج يحدد ما يجب بناؤه، ثم يسلّم المتطلبات إلى فريق الهندسة لتنفيذها.
هذا النموذج لا يزال موجودًا في كثير من الشركات.
لكن طريقة بناء المنتجات الحديثة بدأت تتحرك في اتجاه مختلف.
لم يعد المهندس مجرد شخص يحوّل المتطلبات إلى كود. ولم يعد فريق المنتج يعمل فقط على تسليم مجموعة من المزايا في الموعد المحدد.
التركيز أصبح أكبر على النتائج التي يحققها المنتج، وليس فقط على ما يتم إطلاقه.
وهنا يظهر مفهوم هندسة المنتجات (Product Engineering).
ما المقصود بهندسة المنتجات؟
لا يوجد تعريف واحد متفق عليه عالميًا لمصطلح Product Engineering، لذلك من الأفضل عدم التعامل معه باعتباره مسمى وظيفيًا جديدًا أو بديلًا لإدارة المنتجات.
المقصود به في سياق بناء المنتجات الرقمية هو توسيع دور الهندسة ليكون أكثر ارتباطًا بالمنتج والمستخدم والنتائج التجارية.
أي أن المهندس لا يبدأ فقط بالسؤال:
"ماذا نريد أن نبني؟"
بل يمكن أن يسأل أيضًا:
ما المشكلة التي نحاول حلها؟
لماذا نعتقد أن هذه المشكلة مهمة؟
كيف يمكن بناء حل أبسط؟
كيف نختبر الفكرة قبل استثمار وقت كبير فيها؟
كيف سنقيس نجاح الحل؟
ما البيانات التي نحتاج إليها؟
وما المخاطر التقنية أو التشغيلية التي يجب أن نعرفها مبكرًا؟
هذا لا يحوّل المهندس إلى مدير منتج.
لكنه يجعله جزءًا حقيقيًا من عملية صناعة المنتج.
من تنفيذ المتطلبات إلى المشاركة في صناعة الحل
في النموذج التقليدي، قد يحصل المهندس على وثيقة تحتوي على تفاصيل الميزة، ثم يبدأ في تنفيذها.
المشكلة هنا أن بعض القرارات المهمة تكون قد حُسمت قبل أن يصل النقاش إلى الهندسة.
قد يكون الحل المقترح صعب التنفيذ.
أو قد تكون هناك طريقة أبسط.
أو قد يستطيع الفريق اختبار الفكرة بتكلفة أقل.
أو قد تكشف القيود التقنية أن الفرضية الأصلية تحتاج إلى تغيير.
في فرق المنتجات الأكثر نضجًا، تحدث هذه المناقشات في وقت مبكر.
مدير المنتج يأتي بفهم المشكلة والسوق والمستخدم وأهداف العمل.
المصمم يساهم في فهم تجربة المستخدم وتصميم الحل.
والمهندس يساهم في فهم الإمكانات والقيود التقنية وطريقة بناء الحل وقياسه.
هذا قريب من نموذج الفرق المُمكّنة (Empowered Product Teams)، حيث لا يحصل الفريق على قائمة جاهزة من المزايا لتنفيذها فقط، بل يحصل على مشكلة أو هدف واضح، ثم يشارك في تحديد أفضل طريقة للوصول إلى النتيجة.
لماذا أصبحت الهندسة أقرب إلى المنتج؟
هناك سبب عملي وراء هذا التغيير.
البرمجيات الحديثة أصبحت قابلة للتجربة والقياس بشكل أكبر.
يمكن للفريق إطلاق ميزة لمجموعة صغيرة من المستخدمين.
ويمكن استخدام Feature Flags للتحكم في ظهورها.
ويمكن إجراء A/B Testing لمقارنة أكثر من تجربة.
ويمكن مراقبة مؤشرات الاستخدام والاحتفاظ والتحويل.
هذا يعني أن الهندسة أصبحت قادرة على المشاركة في دورة كاملة:
بناء → إطلاق → قياس → تعلم → تحسين.
وليس فقط:
تحليل المتطلبات → برمجة → إطلاق.
مثال بسيط
لنفترض أن شركة SaaS تريد زيادة عدد المستخدمين الذين يكملون عملية التسجيل.
في النموذج التقليدي قد تكون المهمة:
"أضف شاشة جديدة أثناء التسجيل."
أما فريق المنتج الحديث فقد يبدأ بالسؤال:
"لماذا لا يكمل المستخدمون التسجيل؟"
قد تكشف البيانات أن المستخدمين يتركون العملية عند خطوة معينة.
هنا قد يكون الحل الأفضل ليس إضافة شاشة جديدة، بل حذف خطوة، أو تبسيط نموذج، أو تحسين سرعة الصفحة، أو تغيير ترتيب المعلومات.
المهندس الذي يفهم المشكلة يمكنه المشاركة في الوصول إلى هذه الخيارات بدلًا من تنفيذ الحل الأول كما هو.
هل هذا يعني أن مدير المنتج لم يعد ضروريًا؟
لا.
وهذه نقطة مهمة جدًا.
زيادة مشاركة المهندسين في قرارات المنتج لا تعني اختفاء دور مدير المنتج.
في نموذج الفريق المُمكّن، لا تختفي التخصصات.
بل تصبح أكثر تكاملًا.
مدير المنتج يظل مسؤولًا بدرجة كبيرة عن فهم قيمة المنتج وجدواه التجارية (Value & Viability).
المصمم يهتم بدرجة كبيرة بقابلية الاستخدام وتجربة المستخدم.
والهندسة مسؤولة عن الجدوى التقنية (Feasibility).
لكن الوصول إلى حل جيد يحتاج إلى تعاون هذه الأدوار معًا، وليس إلى عمل كل تخصص بمعزل عن الآخر.
وهنا يوجد فرق مهم بين:
المسؤولية عن مجال معين
و
المشاركة في القرار.
المهندس يمكنه أن يشارك في قرار متعلق بالمنتج دون أن يصبح مدير منتج.
ومدير المنتج يمكنه فهم القيود التقنية دون أن يصبح مهندسًا.
ما الذي تغير إذن في دور مدير المنتج؟
التغيير الحقيقي ليس أن مدير المنتج أصبح غير مهم.
بل أن تعريف وظيفته أصبح أكثر ارتباطًا بالمشكلة والنتيجة وأقل ارتباطًا بكتابة قائمة طويلة من المتطلبات.
في الفرق التي تعمل وفق نموذج المنتج، لا يكون الهدف الأساسي هو:
"إطلاق 20 ميزة هذا الربع."
بل يمكن أن يكون الهدف مثل:
"زيادة نسبة المستخدمين الذين يكملون الإعداد الأولي للمنتج من 35% إلى 50%."
الفرق بين الهدفين كبير.
الأول يقيس المخرجات (Outputs).
الثاني يقيس النتيجة (Outcome).
والفرق المُمكّنة تكون مسؤولة عن الوصول إلى النتيجة، وليس فقط عن تنفيذ قائمة من المزايا.
المشكلة ليست في مدير المنتج أو المهندس
أحيانًا يتحول النقاش حول Product Engineering إلى سؤال من نوع:
هل سيحل المهندسون محل مديري المنتجات؟
وهذا في رأيي سؤال غير دقيق.
السؤال الأفضل هو:
كيف نبني فريقًا يستطيع اتخاذ قرارات أفضل بشأن المنتج؟
لأن وجود مهندس ممتاز لا يعوض عن غياب فهم المستخدم والسوق.
وبالمثل، وجود مدير منتج ممتاز لا يعوض عن غياب الفهم التقني.
المنتج الجيد يحتاج إلى الاثنين.
بل يحتاج أيضًا إلى التصميم، والبيانات، وفهم المبيعات والدعم والسوق، بحسب طبيعة المنتج.
ولهذا توصف فرق المنتجات الحديثة بأنها متعددة التخصصات (Cross-functional).
من "ماذا نبني؟" إلى "ما المشكلة التي نحاول حلها؟"
ربما يكون هذا هو التغيير الأهم.
في النموذج التقليدي:
مدير المنتج: هذه هي الميزة التي نحتاج إلى بنائها.
المهندس: حسنًا، سأبنيها.
أما في النموذج الأكثر نضجًا:
مدير المنتج: هذه هي المشكلة، وهذه البيانات التي نملكها، وهذا الهدف الذي نريد الوصول إليه.
الفريق: دعونا نبحث عن أفضل حل.
وهنا يصبح النقاش أكثر إنتاجية.
قد يقترح المهندس حلًا تقنيًا أبسط.
وقد يقترح المصمم تجربة مختلفة.
وقد يكتشف مدير المنتج أن المشكلة ليست في المكان الذي كان يعتقده.
وقد تكشف البيانات بعد الإطلاق أن الفرضية الأصلية كانت خاطئة.
وهذا طبيعي.
لأن تطوير المنتجات ليس عملية تنفيذ لخطة ثابتة، بل عملية مستمرة لاكتشاف ما الذي يعمل وما الذي لا يعمل.
لكن هناك خطر آخر
الانتقال إلى هذا النموذج لا يعني أن نعطي الجميع صلاحية اتخاذ كل القرارات.
التمكين بدون وضوح في المسؤوليات قد يتحول إلى فوضى.
يحتاج الفريق إلى:
هدف واضح.
مشكلة محددة.
بيانات كافية لاتخاذ القرار.
مسؤوليات واضحة.
صلاحيات مناسبة.
مؤشرات نجاح يمكن قياسها.
وسياق تجاري يساعد الفريق على فهم سبب اتخاذ القرار.
بدون ذلك، قد يتحول مفهوم "الجميع مسؤول عن المنتج" إلى حالة لا يكون فيها أحد مسؤولًا فعليًا عن أي شيء.
لذلك، نجاح النموذج لا يعتمد فقط على تغيير المسميات.
يعتمد على طريقة تشغيل الفريق بالكامل.
كيف تبدو العلاقة الصحية بين مدير المنتج والهندسة؟
يمكن تلخيصها بهذه الصورة:
مدير المنتج يساعد الفريق على فهم:
لماذا هذه المشكلة مهمة؟
لمن نحلها؟
ما القيمة المتوقعة؟
ما الأولويات؟
كيف نعرف أننا نجحنا؟
الهندسة تساعد الفريق على فهم:
ما الذي يمكن بناؤه؟
ما التكلفة والمخاطر؟
ما القيود التقنية؟
ما البدائل الممكنة؟
كيف نبني الحل بطريقة قابلة للتوسع والصيانة؟
والفريق معًا يقرر:
ما الحل الذي يستحق التجربة؟
كيف نختبره؟
كيف نطلقه؟
وكيف نقيس أثره؟
هذا هو جوهر التعاون الحقيقي.
الخلاصة
هندسة المنتجات لا تعني أن مدير المنتج انتهى.
كما أنها لا تعني أن المهندس أصبح مدير منتج.
ما يحدث هو تحول أكبر في طريقة بناء المنتجات.
الفرق الحديثة تتحرك تدريجيًا من نموذج يعتمد على:
متطلبات → تنفيذ → إطلاق
إلى نموذج يعتمد أكثر على:
مشكلة → فرضية → حل → تجربة → قياس → تعلم.
وفي هذا النموذج، يصبح المهندس شريكًا في صناعة المنتج، ويصبح مدير المنتج قائدًا لفهم المشكلة والسياق والأهداف، وليس مجرد كاتب للمتطلبات.
والنتيجة التي نبحث عنها ليست أن يكون لدينا أفضل مدير منتج أو أفضل مهندس بشكل منفصل.
بل أن يكون لدينا فريق يستطيع معًا بناء منتج يحبه المستخدم ويحقق قيمة حقيقية للشركة.
وهذا هو الفارق بين فريق هدفه تسليم المزايا وفريق هدفه تحقيق النتائج.