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

تحليل الأنظمة والمنتجات

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

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

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

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

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

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

قصص المستخدمين User Story

هي أحد الأساليب المرنة الأكثر انتشارا في تحليل الأنظمة والأعمال اليوم والتي تساعد على جمع ودراسة متطلبات الأنظمة والمنتجات بواقعية اكثر وسرعة اعلى وبتكلفة اقل.

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

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

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

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

احكي حكاية منتجك

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

وهنا نحن لا نتحدث عن التفاصيل إنما صورة شاملة لما سيكون عليه النظام أو المنتج عندما يكتمل وكأنها خريطة طريق توضح لك الرؤيا التي تسير نحو تحقيقها.

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

ولكتابة تلك الحكاية علينا ان نعرف بدقة من هم المستخدمين الرئيسين للمنتج ولماذا يحتاجون استخدام هذا المنتج وما هي المنافع او النتائج التي سيخرجون منها بعد استخدامها النظام.

وبالتالي فهناك ثلاثة عناصر ينبغي التركيز عليها في حكاية المنتج:

1- الهدف:

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

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

وهنا نحن نتحدث عن هدف واحد فقط فوجود أهداف متعددة يعني ببساطة عدم وضوح الغاية التي أنشئ المنتج من أجلها.

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

2- المستخدمين:

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

وللمساعدة في تحديد المستخدمين بشكل دقيق فيمكن رسم شخصية لكل مستخدم متوقع للنظام وكأنها شخصية حقيقية بحيث يتم تحديد اسم رمزي للشخصية والجنس والعمر المفترض والسلوكيات التي يتبعها في يومه والمهارات التي يتمتع بها والاهتمامات التي تثيره والأهداف التي يسعى لتحقيقها والبيئة التي يعيشها.

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

3- النشاطات:

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

هذه النشاطات هي التي سترسم لنا تلك المزايا التي ينبغي أن يتمتع بها المنتج لتلبي المهام التي يحتاج أن يقوم بها كل مستخدم.

من أفضل الطرق للمساعدة في نمذجة تلك المهام أو النشاطات التي يتفاعل فيها المستخدم مع النظام هو مخطط حالة الاستخدام Use Case  والذي يتم فيه رسم حدود النظام وأدوار المستخدمين من حوله والنشاطات أو المهام التي يقوم فيها كل مستخدم مع النظام.

يساعد مخطط حالة الاستخدام على الوصول للوظائف الرئيسية التي سيقوم بها النظام الجديد وبما يتفق مع حاجة المستخدم الحقيقية والتي تؤدي في النهاية لتحقيق الهدف الذي تم وضعه.

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

خريطة المنتج

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

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

يتم بعد ذلك ربط تلك الخطوات مع بعضها البعض من خلال  مخطط عملية Process Map والذي يوضح الخطوات الأساسية التي يتكون منها الإجراء الرئيسي للمنتج والتي ستؤدي لتحقيق القيمة المقدمة منه للمستخدم ضمن مخطط مرئي مرتبة من اليمين لليسار.

وفي أسفل كل خطوة رئيسية في مخطط العملية يتم تحديد المزايا أو الوظائف التي ينبغي أن تتوفر في المنتج لتحقيقها بحيث يتم ترتيب تلك الوظائف من الأعلى للأسفل تحت كل خطوة رئيسية حسب الأولوية وهنا يتم ذكر اسم المهمة أو الوظيفة فقط دون تفاصيل.

هنا يتكون لدينا مخطط كامل المنتج يتضمن الخطوات والمزايا العامة التي تكونه والفوائد الأساسية التي سيوفرها للمستخدم.

لاحظ أن هذا المخطط ليس ثابتا أو جامد الحركة بل هو متغير وديناميكي حيث يتم نقاش تلك الخطوات والمزايا المرتبطة مع كل خطوة والتعديل عليه بشكل مستمر طوال فترة بناء المنتج.

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

الحد الأدنى من المنتج Minimum Viable Product MVP

وهنا تأتي لفكرة الحد الأدنى من المنتج وهو مفهوم هام جدا عند تحليل وتصميم الأنظمة خصوصا في ظل العمل المرن واستخدام قصص المستخدمين.

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

فبدلا من توفير كل مزايا المنتج أو النظام من البداية ومرة واحدة فيمكن توفير المزايا الجوهرية فقط والتي لا يقوم النظام أو المنتج إلا بها.

أي أننا عندما نتحدث عن الحد الأدنى فنحن نتحدث عن منتج يعمل ويوفر الحاجات الأساسية التي تم التفكير بإنتاج المنتج من أجلها وليس مجرد منتج للعرض أو التجربة.

وهذا يعني انه ينبغي عند بناء خارطة المنتج العمل على تحديد تلك المزايا الجوهرية التي لا يمكن الخروج بالمنتج إلا بها. المزايا التي تبرر وجود المنتج وتلبي حاجة المستخدم الأساسية منه.

هذه المزايا ينبغي أن تكون واضحة جدا ومتفق عليها بين جميع من لهم مصلحة وتمثل أقل تكلفة يمكن بناء الإصدار الأول من المنتج من خلالها.

ستكون حكاية المنتج بعناصرها الثلاثة أهم عنصر مساعد في تحديد تلك المزايا الجوهرية التي سيوفرها الإصدار الأول من المنتج.

تطوير قصص المستخدمين User Story

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

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

تتكون قصة المستخدم من ثلاثة عناصر أساسية:

• العنوان

وهو في العادة نفس اسم الميزة التي تعبر عنها قصة الاستخدام او مشتق منها.

• القصة:

والتي تعبر في جملة واحدة عن مستخدم القصة وحاجته والسبب خلف تلك الحاجة. ويتم كتابتها وفق النموذج التالي:

ك (مستخدم)، أريد/ارغب/أتمنى، أن افعل/أقوم ب/ (____)، وذلك لكي أتمكن/استطيع أن (_____).

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

امثله على ذلك:

أنا كمعلم أرغب بعرض علامات طلابي بشكل تفصيلي وبذلك أتمكن من تقييم الطالب بشكل أوضح.

أنا كمدير أرغب في إسناد المهمة لأكثر من موظف في ذات الوقت حتى أتمكن من متابعة المهام الجماعية.

• معايير القبول:

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

يتم مناقشة تلك القصص مع أصحاب المصلحة الذين لهم علاقة بالمشروع وعند الوصول لفهم مشترك لاي قصة يتم إضافتها لمستودع القصص تمهيدا للبدء بالتنفيذ.

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

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

لكن من المهم ان تحقق أي قصة استخدام خمسة شروط أساسية:

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

تنفيذ قصص المستخدمين

بمجرد أن يتم الإنفاق على أي قصة استخدام، يتم إضافتها الى مستودع القصص Backlog بهدف القيام بتنفيذها من قبل فريق التنفيذ.

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

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

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

في حال رفض قصة استخدام من قبل مدير المنتج فيتم إعادتها الى مستودع القصص ليتم استكمالها أو العمل عليها من جديد حتى تكتمل.

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

وأخيرا…..تطبيقات ذات قيمة

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