كمؤسس ساس، لديك مشكلة في قول «لا»

أنت تقترح شيئًا.

والمدير التقني يقترح شيئًا.

والعميل يقترح شيئًا.

والبحث يقترح شيئًا.

والمنافسون يطلقون خاصية جديدة.

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

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

إليك كيف تتجسد كل فئة داخل منتج ساس حقيقي.

يجب أن يكون

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

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

ينبغي أن يكون

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

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

يمكن أن يكون

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

لن يكون، هذه المرة

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

مثال تطبيقي

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

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

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

تشغيل التمرين بشكل صحيح

يفشل MoSCoW حين يوزّع شخص واحد الفئات وحده على مكتبه. وينجح حين يُدار كجلسة قصيرة منظّمة تجمع المنتج والهندسة وصوتًا تجاريًا واحدًا في الغرفة نفسها.

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

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