غالبًا ما تكون المتطلبات/قصص المستخدمين أقل عددًا على مستوى البرنامج أو المحفظة منها على مستوى المشروع. وبنفس الطريقة، عادة ما تكون قصص المستخدم ذات المستويات القابلة للتأمل من القيم وتأثير الاحتياجات أقل منها على مستوى المشروع من حيث النسبة المئوية. إجمالاً، ما يعنيه هذا هو أنه على مستوى البرنامج أو المحفظة، سيكون نطاق الأدوات التي ستكون قابلة للتطبيق أصغر.
في اللحظة التي يكون لديك بالفعل مجموعة من قصص المستخدمين في تراكمات المنتج (بالإضافة إلى الميزات والمتطلبات والتحسينات والتغييرات والتصحيحات وغيرها)، تحتاج إلى تعيين أولويتها. إذا كنت تعمل مع Scrum، في اللحظة التي يكون لديك بالفعل مجموعة من قصص المستخدمين في تراكمات المنتج الخاصة بك، بالإضافة إلى الميزات والمتطلبات والتحسينات والتغييرات والتصحيحات وغيرها، فأنت بحاجة إلى تعيين أولويتها بالترتيب والتقدير والقيمة بحيث يمكن تحديدها في سبرينت التالي.
يجب أن يكون هدفك بصفتك مالك المنتج أولاً هو تقديم القصص الأكثر قيمة للمستخدمين أو عملك. كما قد تعلم بالفعل، فإن كل قصة تتضمن قيمة للمستخدم، ولكن قد يكون من الصعب تحديد أولوية القصة بناءً على هذه الفكرة فقط، والتي تكون أحيانًا غير واضحة وأحيانًا واضحة جدًا.
تحديد أولويات قصص المستخدم
إذا كنت تتساءل في كثير من الأحيان عن كيفية تحديد أولويات قصص المستخدمين في أجايل، فلا تقلق، فلدينا جميع الإجابات لك! بالطبع، لتحديد الأولويات بشكل صحيح، يجب على مالك المنتج استخدام عدد كبير من المتغيرات والأساليب والأدوات. سنستعرض في الصفحات التالية بعضاً من أكثر طرق تحديد الأولويات استخداماً واحتراماً: MoSCoW، وKano، والمقارنة بين الأزواج، وطريقة 100 نقطة، وتخطيط القصة. بعد ذلك، سنشرح بدقة كيفية عمل كل طريقة وكيف ستساعدك على تحديد أولويات قصص المستخدمين في مشاريعك.
طريقة موسكو لتحديد الأولويات
اكتسبت هذه الطريقة الأولى اسمها كطريقة اختزال. وهي تستخدم الأحرف الأولى من الكلمات “يجب أن يكون” و”يجب أن يكون” و”يمكن أن يكون” و”لن يكون”. يوصى بهذه الطريقة لأنها عادة ما تعمل بشكل أفضل من أي طريقة بسيطة أخرى. يعتمد الترتيب التنازلي لهذه الطريقة للمستويات المختلفة على الأولوية. وبهذه الطريقة، تعتبر قصص المستخدم “يجب أن يكون” حيوية؛ فعدم وجودها يعني أن المنتج ليس له قيمة. قصص المستخدم “لن يكون لها” هي تلك التي حتى لو كان من الجيد وجودها، إلا أنه ليس من الضروري تضمينها.
موسكو هي طريقة متوسطة المدى لتحديد الأولويات. وتتكون من فرز قصص المستخدمين إلى فئات مختلفة:
م – يجب أن يكون: يجب تطوير ما هو موصوف في قصة المستخدم بشكل إلزامي.
S – يجب أن يكون: يجب تطوير قصة المستخدم إن أمكن.
ج – يمكن أن يكون: يمكن تطويرها، لكنها ليست ضرورية للمستخدمين أو فرق العمل.
W – W – W won’tave: لن يتم تضمينها على المدى المتوسط، ولكن يمكن أن تكون مفيدة في إصدار لاحق.
يمكن أن يكون تنظيم مجموعة عمل MoSCoW مع أصحاب المصلحة من مختلف المجالات طريقة رائعة للبدء في تحديد أولويات الأعمال المتراكمة، ولكن هذه الطريقة تأتي مع بعض القيود. على سبيل المثال، غالبًا ما يعتقد المشاركون أن “كل شيء مهم”، لذلك عادةً ما ينتهي الأمر بجميع القصص في مجموعات “يجب أن يكون” أو “يجب أن يكون”. ويحدث هذا غالبًا لأن كل شخص لديه وجهة نظر مختلفة، وكل قصة مهمة لشخص ما بشكل ملموس.
ويحدث ذلك أيضًا في الشركات التي لديها توقعات غير واقعية أو عندما لا يعرف مديرو المنتجات أو مديرو المشاريع كيف يقولون “لا”. في هذه الثقافات، يكون المشاركون مقتنعين بأن أي شيء يوضع في “كان يمكن أن يكون” أو “لن يكون” يمكن أن ينتهي به المطاف في سلة المهملات.
مالك المنتج هو المسؤول عن تعزيز العقلية الإيجابية والتركيز على خلق قيمة للمستخدم والأعمال وتجنب التنافس بين الأقسام أو الأشخاص فيما يتعلق بما يجب أن يتم بناؤه.
2. المقارنة في أزواج
تتكون هذه التقنية الثانية بشكل أساسي من إعداد قائمة بجميع قصص المستخدمين في قائمة تراكمات المنتج ذات الأولوية. بعد ذلك، يتم النظر في كل قصة مستخدم على حدة ويتم وضعها مقابل قصة مستخدم أخرى في القائمة، واحدة تلو الأخرى. بهذه الطريقة، يتم وضع قصص المستخدمين جنبًا إلى جنب من أجل تحديد أيهما أكثر أهمية من الأخرى، مما يسمح لك بتعداد قصص المستخدمين ذات الأولوية، مما ينتج عنه قائمة مفيدة للغاية.
3. طريقة 100 نقطة
طور دين ليفينجويل ودون ويدريج هذه الطريقة التالية في عام 2002. وهي تتألف من 100 نقطة يجب تخصيصها للزبون للتصويت معهم على قصص المستخدم الرئيسية. والهدف من ذلك هو إعطاء أهمية أكبر لقصص المستخدمين ذات الأولوية القصوى مقارنة بالقصص الأخرى المتاحة. يقوم كل عضو في المجموعة بتعيين قيمة (معبراً عنها بالنقاط) لقصص المستخدمين المختلفة. وبالطبع، بهذه الطريقة، سيعطون درجة أعلى للقصص التي يعتقدون أنها أكثر أهمية. وبمجرد الانتهاء من إجراء التصويت هذا، يقومون بحساب مجموع النقاط التي تم تخصيصها لكل قصة ومن ثم إنشاء قائمة الأولويات.
4. تحليل كانو
تم ابتكار هذه الطريقة من قبل نورياكي كانو في عام 1984، وهي مستوحاة من عدم تناسق رضا المستخدم وعدم رضاه عن ميزة ما. قد تقدم بعض الميزات القليل من الرضا عند وجودها، لكن غيابها قد يسبب بدوره عدم رضا كبير.
عندما يكون تراكم المنتج المتراكم قديمًا وشاملًا بشكل خاص، ستسمح لك طريقة كانو بتحديد أولويات الميزات الرئيسية التي تريد تضمينها في منتجك. هذه الطريقة تعاونية أيضاً وينبغي تنفيذها في مجموعة عمل من أربع خطوات مع عدة مشاركين
الخطوة 1: حدد الميزات التي تحتاج إلى تحديد أولوياتها. ضع في اعتبارك أنه ليس من الضروري أن تكون الميزة معادلة لقصة مستخدم، بل لمجموع عدة ميزات؛ وسيتم تحديد ذلك بناءً على منتجك ومدى تحديد قصص المستخدمين الخاصة بك.
الخطوة 2:اطرح هذه الأسئلة على كل عضو من أعضاء مجموعة العمل:
يتضمن المنتج هذه الميزة. ما رأيك؟ (المنظور الوظيفي).
لا يتضمن المنتج هذه الميزة. ما رأيك؟ (المنظور المختل).
الخطوة 3: يقارن التناقضات بين المنظور الوظيفي والمنظور المختل ويصنف الميزات إلى هذه الأنواع:
الميزات الأساسية أو الإلزامية (O): هذه هي الميزات الرئيسية لمنتجك التي لا يمكن استبعادها.
الوظائف الخطية (L): تسمى هذه الوظائف الخطية لأن إضافة المزيد من الوظائف الخطية ستزيد من قيمة منتجك بشكل متناسب.
الميزات المثيرة (E): وهي ليست أساسية، لكنها قد تكون إضافة رائعة وتسعد المستخدمين. وهي ميزات جديدة أو ذات قيمة كبيرة للعميل.
وظائف متناقضة (C): في الحالات التي يوجد فيها اختلاف كبير في الرأي بين المشاركين في مجموعة العمل، قد تتطلب المزيد من البحث.
الوظائف المشكوك فيها (س): هي الخصائص التي قد تتسبب في عدم إعجاب العميل بالمنتج إذا لم تكن موجودة، ولكنها لا تؤثر على مستوى الرضا إذا كانت موجودة. عليك أن تحاول معرفة سبب إعجابهم بهذه الخصائص كثيراً أو قليلاً. نأمل ألا يحدث هذا كثيرًا.
غير مبالٍ (I): لن تؤثر هذه الميزات على العميل بأي شكل من الأشكال ويجب إزالتها. عادةً ما يكون الناس غير مبالين بهذه الميزات، ومنطقياً، لا ينبغي أن تكون أولوية. نأمل أن تتمكن من تكرارها لوضعها في الفئات O أو E أو L.
الخطوة 4: تصور نتائجك في رسم بياني
الخطوة الأخيرة هي رسم نتائجك بيانيًا لتتمكن من تصورها بطريقة أسهل وأسرع. نجد هذه الطريقة مثيرة للاهتمام بشكل خاص لأنها تستند إلى تصور المستخدمين للمنتج وغالباً ما تكشف عن توقعات مفاجئة من بعض أصحاب المصلحة.
5. تخطيط القصة
الطريقة الأخيرة هي تخطيط القصة. إن الجانب المرئي لهذا الأسلوب جيد جدًا للمساعدة في بناء تراكمات المنتج وأيضًا لمساعدتك في تحديد أولوياته. إنها طريقة رائعة لك ولفريقك لتصور أولوية الميزات الرئيسية عالية المستوى لمنتجك بشكل صحيح.
هناك جانب آخر مفيد للغاية في خرائط القصص وهو قدرتها على ملاحظة الترابط بين الميزات عالية المستوى ورؤية الأولويات من منظور المستخدم. كما أنها تعطي رؤية واضحة للميزات التي قد تكون أقل أولوية أو تقنية بحتة.
الاستنتاجات
من المثير للاهتمام أنه عادةً ما تتحرك الميزات بمرور الوقت إلى أسفل قائمة الترتيب. سيفترض العملاء وجود ميزات وستتحرك هذه الميزات من كونها مثيرة/محببة إلى مُرضية، وفي نهاية المطاف، غير مرضية.
تحتاج مستويات المحفظة والبرنامج عادةً إلى متطلبات أو قصص مستخدمين أقل من مستويات المشروع. على مستوى المشروع، عادةً ما تكون قصص المستخدم ذات النسبة المئوية للقيمة/التأثير على الأعمال أصغر بكثير. وهذا يعني في النهاية أنه على مستوى المحفظة أو البرنامج، سيكون عدد الطرق الفعالة أقل.
إن مفتاح تحديد أولويات الأعمال المتراكمة بشكل صحيح هو القيام بذلك من خلال التعاون مع مختلف أصحاب المصلحة وفهم قيمة المنتج، بالإضافة إلى نقاط قوته وضعفه، من وجهات نظر مختلفة وباستخدام عدد من المعايير المختلفة.
نحن في SPOTO ندرك أهمية تحديد أولويات قصص المستخدمين ونقدم تدريباً ودعماً شاملاً لمساعدة الأفراد والمؤسسات على تعزيز ممارساتهم الرشيقة. سجّل في دوراتنا اليوم لاكتساب المهارات والمعرفة اللازمة للتفوق في تطوير المنتجات الرشيقة
