في بيئة الأعمال السريعة اليوم ، أصبحت كيفية إدارة الطلب بشكل فعال تحديًا كبيرًا لجميع الصناعات.تعمل طريقة موسكو كمهارة ذات أولوية لمساعدة الفرق على التوصل إلى توافق في الآراء مع أصحاب المصلحة وتحديد أهمية الاحتياجات.هذا النهج لا يساعد فريق التطوير على التركيز على أهم الاحتياجات فحسب ، بل يفرز أيضًا المتطلبات بطريقة واضحة وبديهية.
طريقة موسكو ، كنظام تصنيف الأولوية ، مقسمة بشكل أساسي إلى أربع فئات: يجب أن يكون ، يجب أن يكون ، لا يمكن أن يكون لها ، لن يكون لها).
تم تطوير طريقة موسكو لأول مرة بواسطة Dai Clegg في عام 1994 ويهدف إلى استخدامها في عملية تطوير التطبيقات السريعة (RAD).منذ عام 2002 ، تم استخدامه على نطاق واسع في طريقة تطوير النظام الديناميكي (DSDM).هذا النهج مناسب بشكل خاص لبيئات التطوير الرشيقة مثل Scrum و RAD لأنه يساعد على إعطاء الأولوية للاحتياجات الأكثر أهمية في إطار زمني محدود.
بغض النظر عن مدى أهمية الطلب ، من أجل تحقيق القيمة التجارية في أقصر وقت ، يجب إعطاء الأولوية للمتطلبات.سيحاول المطور أولاً تقديم جميع المتطلبات التي يجب ، ويجب أن يكون ، ويمكن أن يكون لها ، ولكن إذا كان وقت التسليم مهددًا ، فسيتم إزالة المتطلبات التي ينبغي أن تكون قد تكون أولاً.
يجب أن تعتبر المتطلبات مفتاح النجاح ضمن الإطار الزمني للتسليم الحالي.إذا لم يتم تضمين أي متطلبات مطلوبة ، فيجب اعتبار تسليم المشروع فشلًا.
ما يلي هو شرح محدد لفئات المتطلبات الأربعة في طريقة موسكو:
تطبيقمن خلال هذه التصنيفات ، يمكن لأصحاب المصلحة أن يفهموا بشكل أوضح التأثير وراء تصنيف الطلبات بدلاً من استخدام التصنيفات العالية والمتوسطة والمنخفضة.
في تطوير المنتجات الجديدة ، غالبًا ما تواجه الفرق مهام ثقيلة وصناديق ووقت غير كافية.يمكن أن يساعد استخدام طريقة موسكو الفرق في تقييم الأولويات ، واختيار المتطلبات الضرورية ، وأي المتطلبات التي يمكن انتظارها حتى وقت لاحق.الحد الأدنى للمنتجات القابلة للحياة (MVPs) هي تلك العناصر التي تم وضع علامة عليها حسب الضرورة.
بعد اختيار MVP أو الحد الأدنى للوظيفة القابلة للحياة (MMF) ، قد لا يزال الفريق يواجه موقفًا يتجاوز فيه عبء العمل السعة المتوقعة.في هذه الحالة ، يمكن استخدام طريقة موسكو مرة أخرى لتحديد أولويات وظائف محددة واختيار تلك الضرورية ، أو يمكن تضمينها ، أو يمكن تضمينها في المرحلة التالية من العمل.
على الرغم من أن طريقة موسكو مفضلة على نطاق واسع في الممارسة ، إلا أنها تلقى أيضًا بعض الانتقادات.أشار بعض المستخدمين إلى أن هذه الطريقة فشلت في اتخاذ القرار بين المتطلبات المتعددة ضمن نفس الأولوية ؛ يجب.بالإضافة إلى ذلك ، هناك معضلة لتوقيت عدم وجود فئة ، وليس من المؤكد ما إذا كانت لن يتم تنفيذها في الإصدار الحالي.
في بعض الحالات ، قد يركز الفريق أكثر على تطوير ميزات جديدة ويتجاهل الحاجة إلى تحسينات تكنولوجية ، مثل عمليات إعادة البناء.
بالإضافة إلى طريقة موسكو ، هناك العديد من طرق تحديد أولويات المتطلبات الأخرى ، مثل نموذج Kano ، وهذه الطرق لها سيناريوهات ومزايا وعيوب مختلفة.
كيفية استخدام طريقة موسكو بفعالية لتصفية الاحتياجات الأكثر أهمية والحفاظ على فريقك في حالة مثالية من التشغيل؟