دور صاحب المنتج في المشروع البرمجي حين تسند التطوير لشركة

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

موقفي لا يعجب بعض العملاء: يمكنك إسناد البرمجة لغيرك، لكن لا يمكنك إسناد قرارات المنتج، والمشاريع التي تحاول ذلك تفشل في الغالب مهما كانت جودة الشركة المطوّرة. الشريك الجيد يبني وينصح ويعترض. لكن الأولويات والمفاضلات وقواعد العمل وقبول العمل المنجز ملك لمن يملك النتيجة التجارية. وهذا هو دور صاحب المنتج في المشروع البرمجي (Product Owner)، الدور الذي لا يستغني عنه أي تطوير مُسنَد لجهة خارجية. فإن لم يشغله العميل بقي شاغراً، لأن الشركة المطوّرة لا تستطيع أن تشغله عنه بشكل مشروع.

القرارات التي لا يمكن تفويضها

بعض القرارات ملك للعميل لأنه وحده يملك السياق أو الصلاحية أو المسؤولية اللازمة لاتخاذها.

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

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

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

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

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

الإطلاق أو التأجيل. توقيت الإطلاق، ومدى تقبّل المخاطرة، وما المقبول في اليوم الأول، كلها قرارات تجارية لها عواقب تجارية.

ما الذي يحق للشركة المطوّرة أن تقرره

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

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

كيف يظهر فراغ القرار

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

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

تمدد النطاق. دون مالك واحد للأولويات، يُعامل كل طلب من كل طرف كأنه عاجل بالقدر نفسه، فتنمو قائمة المهام أسرع مما يستطيع الفريق تسليمه. وقد تناولنا تكلفة ذلك في مقال طلبات التغيير وتمدد النطاق.

عمل متوقف. يسأل الفريق عن قاعدة من قواعد العمل وينتظر الإجابة أسبوعاً. فإما أن يتوقف المطوّرون، وإما أن يخمّنوا، والتخمينات تتحول إلى إعادة عمل.

مفاجآت متأخرة. يجري اختبار القبول في النهاية، بمشاركة أشخاص لم يُستشاروا أثناء البناء، فيتبين أن المنتج لا يطابق ما توقعوه.

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

وكثير من الأنماط في مقالنا عن لماذا تفشل مشاريع البرمجيات المخصصة، وخاصة المتطلبات التي لم تكن متطلبات حقيقية، يبدأ كفراغ في القرار.

دور صاحب المنتج الذي يحتاجه أي تطوير مُسنَد

العلاج شخص مسمى في جهة العميل يملك قرارات المنتج. ومنهجيات Agile صريحة في ذلك. ينص دليل Scrum على أن صاحب المنتج «شخص واحد لا لجنة»، وأنه مسؤول عن تعظيم قيمة المنتج، وأن نجاحه يتطلب أن تحترم المؤسسة كلها قراراته. ويذكر دليل الخدمات لدى الحكومة البريطانية من مسؤوليات مدير المنتج ترتيب أولويات قصص المستخدم في كل دورة عمل واعتمادها عند اكتمالها. ومن المبادئ التي يقوم عليها بيان Agile: «يجب أن يعمل أهل الأعمال والمطوّرون معاً يومياً طوال المشروع».

وعملياً، يحتاج الحد الأدنى من صاحب المنتج إلى:

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

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

متى تعيّن صاحب منتج أو توظفه

إن كنت مؤسساً تملك الوقت والصلاحية، فالدور لك. وإن لم تكن متاحاً بما يكفي، فهناك ثلاثة خيارات واقعية.

عيّن شخصاً من داخل المنشأة وامنحه صلاحية حقيقية لا مسؤولية فقط. مدير العمليات أو رئيس القسم الذي يعرف النشاط كثيراً ما يكون صاحب منتج أفضل من مسؤول تنفيذي كبير لا يملك وقتاً.

وظّف مدير منتج أو صاحب منتج بدوام جزئي يعمل في صفك من الطاولة. يجب أن يرفع تقاريره إليك لا إلى الشركة المطوّرة.

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

أقوى الاعتراضات

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

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

ما الذي تفعله الشركات الجيدة لحماية العميل

لا تستطيع الشركة المطوّرة شغل دور صاحب المنتج، لكنها تستطيع تسهيله وكشف الفجوات مبكراً:

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

هذا هو نهجنا في مشاريع تطوير البرمجيات المخصصة، ومن المفيد أن تسأل عن هذه الممارسات أي شركة تتعامل معها.

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

يمكنك إسناد البرمجة لغيرك، لكن لا يمكنك إسناد قرارات المنتج