تخيّل أن فريق مبيعات وعد عميلاً كبيراً بإضافة تصدير خاص قبل نهاية الشهر. يسأل مدير المنتج: «هل ننفذ الوعد؟» قبل الإجابة، يحتاج إلى فصل ثلاثة أشياء. **النتيجة** هي تغير قابل للملاحظة في حياة المستخدم أو أداء المنتج، مثل تقليل وقت إعداد تقريره. **المخرج** هو الشيء الذي يبنيه الفريق، مثل زر التصدير. **النشاط** هو العمل الذي يستهلك الوقت، مثل كتابة المواصفة أو عقد اجتماع. قد ينجز الفريق النشاط ويسلّم المخرج ولا تتحقق النتيجة؛ ربما يحتاج العميل إلى صلاحيات مشاركة مختلفة لا إلى ملف جديد. لهذا لا يبدأ قرار المنتج من قائمة الطلبات وحدها.
إدارة المنتج هنا مسؤولية تنسيق القرارات حول المشكلة والقيمة والأولوية والتعلم، ضمن صلاحية تمنحها المؤسسة. ليست رخصة لفرض الحل على المصمم أو اختيار بنية تقنية نيابة عن المهندس أو إعطاء التزام تجاري منفرد. في فريق يستخدم Scrum ، يحدد دليل Scrum مسؤولية Product Owner عن تعظيم قيمة المنتج وإدارة Product Backlog ، لكنه لا يقول إن كل مؤسسة توزع كل صلاحيات المنتج بالطريقة نفسها. إذا كان الفريق لا يعمل وفق Scrum ، فلا ننقل اللقب آلياً إلى شخص آخر. نبدأ بسؤال عملي: من يملك قرار النتيجة المطلوبة، ومن يقرر طريقة الحل، ومن يوافق على المخاطر والعقود والتكلفة؟
مثال
ارسم للقرار أربع خانات على ورقة واحدة. الخانة الأولى «المشكلة والدليل»: ماذا يحاول المستخدم إنجازه، وما شاهدناه فعلاً، وما هو مجرد طلب أو تفسير؟ الثانية «البدائل»: إصلاح تدفق قائم، تغيير سياسة أو شرح، بناء ميزة، أو عدم التدخل الآن. الثالثة «حدود القرار»: ما الذي يستطيع مسؤول المنتج اعتماده، وما الذي يحتاج موافقة قانونية أو أمنية أو مالية أو تعاقدية؟ الرابعة «الإشارة التالية»: ما الدليل الذي سيجعلنا نستمر أو نغيّر المسار؟ هذا الرسم يمنع أن تتحول كلمة «أولوية» إلى توقيع ضمني على حل أو موعد.
لنطبق ذلك على الوعد التجاري. لدى المنتج 800 مؤسسة نشطة. العميل المعني يمثل 12% من الإيراد السنوي، لكن ثلاثة فقط من 30 مستخدماً جرت مقابلتهم طلبوا تصدير الملف، وكلهم يعملون لدى المؤسسة نفسها. سجلات الدعم تظهر أن 18 مؤسسة تواجه صعوبة في مشاركة التقرير داخلياً؛ 13 منها تستخدم رابط المشاركة الحالي لكن المستلم لا يرى أحدث نسخة. طلب التصدير قد يكون حلاً اقترحه العميل لمشكلة أوسع: وصول موثوق إلى نسخة حديثة. لا نستنتج من هذه العينة أن 18 مؤسسة تحتاج زر التصدير، ولا نتجاهل قيمة العميل الكبير. نضع مسارين للتحقق: مقابلة مستخدمين من مؤسسات مختلفة حول مهمة المشاركة، وفحص سبب رؤية النسخ القديمة في الرابط الحالي. إذا تبين أن الرابط يقدّم نسخة مخزنة قديمة، فإن إصلاحه قد يحل المشكلة لعدد أكبر بكلفة أقل. إذا كانت لدى العميل حاجة موثقة إلى أرشيف قابل للتنزيل لأغراض داخلية، يبقى التصدير خياراً مستقلاً يحتاج تقدير أثره الأمني والتشغيلي.
القرار المحلول ليس «نرفض المبيعات» ولا «نبني الزر فوراً». يقدّم مسؤول المنتج للمبيعات صياغة دقيقة: سنفحص مهمة المشاركة خلال أسبوع، ونعود بخيار ومجال زمني بعد تقدير الفريق؛ لا نعِد بميزة محددة اليوم. يطلب من الهندسة تشخيص النسخة القديمة وتقدير بديل التصدير، ومن التصميم اختبار ما إذا كان المستخدم يميّز الرابط الحي من الملف الثابت. يصعّد الوعد التجاري السابق إلى صاحب صلاحية العقود أو الحساب، لأن التزاماً قُدم بالفعل وقد يحتاج معالجة علاقة العميل. يحتفظ بقرار أولوية العمل المنتجية ضمن التفويض، لكنه لا يغيّر عقداً منفرداً.
كيف نعرف أن هذا تصرف مهني؟ يمكن مراجعة أثر القرار في ثلاثة مستويات: هل عُرّفت المشكلة بلغة مهمة المستخدم؟ هل سُجلت الفرضيات المنفصلة عن الملاحظات؟ وهل عرف كل طرف ما سيقرره ومتى؟ في المثال، الناتج المطلوب بعد أسبوع ليس عدد الاجتماعات، بل تقرير قصير يذكر سبب مشكلة الرابط، وما سمعناه من عينات متنوعة، والبدائل مع أثرها ومخاطرها، ثم قراراً معللاً أو سؤالاً محدداً يمنع القرار. إذا أصلحنا الرابط ثم انخفضت تذاكر «النسخة القديمة» ولم تتحسن مشاركة التقارير، نعيد فتح فرضية الوصول بدلاً من إعلان نجاح المنتج لمجرد إغلاق التذاكر.
ثمة حد مهم بين **المساءلة عن القرار** و**الاستئثار بالعمل**. حين يطلب مسؤول المنتج من المهندس تقدير مخاطر التصدير، لا يطلب منه مجرد رقم أيام؛ يسأله إن كان الملف سيحتوي بيانات لا يحق لكل مستلم رؤيتها، وهل يمكن سحب الوصول بعد تنزيله، وما تكلفة الدعم والصيانة. وحين يناقش المصمم، لا يختار لون زر، بل يشرح مهمة المستخدم والالتباس بين الرابط الحي والنسخة الثابتة. بهذه الطريقة يدخل كل اختصاص في القرار من موضع خبرته. إذا تعارضت الأدلة، تُسجل نقطة الخلاف وقرار التجربة أو التصعيد بدلاً من تحويل الاجتماع إلى تصويت بالألقاب.
قد تتغير الأولوية حتى إن بقيت المشكلة نفسها. لنفترض أن فحص الهندسة كشف تسرباً محتملاً لبيانات مؤسسة إلى أخرى عبر الرابط. يصبح احتواء الخطر مسار استجابة عاجلاً بصلاحيات الأمن والتشغيل، ولا ينتظر دورة المفاضلة الاعتيادية للميزات. أما إذا كان الخلل مجرد نسخة متأخرة بخمس دقائق لا تؤثر في مهمة حرجة، فيمكن مقارنة إصلاحه بعمل آخر وفق أثر المستخدم والجهد. هذه ليست درجات ثابتة؛ هي مثال على أن نوع الخطر يغير صاحب القرار وتسلسل الخطوات. سجل القرار الجيد يذكر سبب التغيير لا النتيجة الأخيرة وحدها، لكي يفهم الفريق لاحقاً لماذا لم يُنفذ الوعد الأول حرفياً.
تمرين
لديك تطبيق للمواعيد. طلب المدير التنفيذي شاشة جديدة تعرض كل المواعيد؛ يرى فريق الدعم 40 تذكرة شهرياً عن تأخر التذكير، ويقول فريق الهندسة إن خدمة الرسائل تفشل في 8% من المحاولات. اكتب قراراً أولياً من أربع خانات، وحدد ما تستطيع تقريره وما تصعّده.
تحقّق من إجابتك المشكلة المرصودة هي تأخر أو غياب التذكير؛ الشاشة الجديدة فرضية حل منفصلة. البدائل هي إصلاح فشل الإرسال، تحسين إعادة المحاولة، أو لوحة متابعة إذا ثبت أن المستخدم يحتاج مراقبة يدوية. يحتاج الفريق تعريف نافذة «متأخر»، وحجم المواعيد الكلي، وتقسيم الفشل حسب القناة قبل تقدير الأثر. يستطيع مسؤول المنتج ترتيب التشخيص مع الفريق وتوصية أولوية الإصلاح. يصعّد أي تغيير في التزام تعاقدي بشأن وصول الرسالة، وأي أثر خصوصية للشاشة الجامعة. الناتج التالي تقرير بمعدل إرسال ناجح، وزمن وصول، وتذاكر الدعم بعد الإصلاح؛ لا يكفي عدّ الشاشات المسلّمة.
