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

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

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

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

قصص المستخدمين الفضفاضة للغاية: فخ التفاصيل المفقودة

عندما تكون قصص المستخدمين فضفاضة أو عامة جدًا، فإنها غالبًا ما تفقد المعلومات الجوهرية المتعلقة بالإجراء المتوقع والاحتياج الحقيقي للمستخدم. إذا لاحظت كثرة استخدام كلمات مثل “and” (و)، أو “or” (أو)، أو “that” (التي) في قصص المستخدمين الخاصة بفريقك، فهذه إشارة واضحة إلى أنها واسعة النطاق وتحتاج إلى إعادة صياغة. في كثير من الأحيان، قد تكون قصة المستخدم الفضفاضة في الواقع “ملحمة” (epic) تتطلب تقسيمها إلى قصص أصغر وأكثر تحديدًا.

لنأخذ مثالاً لقصة مستخدم فضفاضة:

As a user, I would like to continue reading the article later when I’m on my way home, without needing to sign up and find the exact spot where I left off.

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

As a user, I would like to continue reading the article later without having to sign up.

As a user, I want to continue reading from where I left off, so that I don't have to find the last paragraph I finished reading.

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

قصص المستخدمين المفرطة في التفصيل: الابتعاد عن منظور المستخدم

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

إليك مثال لقصة مستخدم مفصلة للغاية لدرجة أنها تتطرق إلى تفاصيل التنفيذ:

Define a scalable, relational database structure so that I can use it to implement any possible future use case.

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

قصص المستخدمين غير القابلة للتفاوض: المرونة هي المفتاح

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

إليك مثال لقصة مستخدم غير قابلة للتفاوض:

As a user, I want to have a clear all button in the notifications tab, so I can remove old notifications.

من الواضح أن المستخدم يرغب في القدرة على إزالة الإشعارات القديمة. بينما يُعد زر “clear all” حلاً واحدًا، يمكن أيضًا مسح الإشعارات تلقائيًا بعد قراءتها! هذا يفتح الباب لحلول بديلة قد تكون أكثر كفاءة أو أفضل لتجربة المستخدم.

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

تكرار قصص المستخدمين في معايير القبول: تحديد المعايير بوضوح

كثيرًا ما نلاحظ أن معايير القبول (Acceptance Criteria) تكرر قصة المستخدم، ولكن بكلمات مختلفة فقط. هذا يفرغ معايير القبول من قيمتها الحقيقية.

إليك مثال على هذا التكرار:

قصة مستخدم مكررة في معايير القبول

• قصة المستخدم:

  As a user, I want to add pop-up forms to my blog, so I can capture the visitor's email id before they leave the site.

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

  Given a reader visits a blog, when they try to leave, then the pop-up form should come asking them to subscribe to the blog.

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

إليك مثال أفضل يوضح كيفية صياغة معايير قبول فعالة:

مثال على معايير قبول محسّنة

• لقصة المستخدم:

  As a user, I want to receive notifications when others add comments so that I am up-to-date.

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

  Given I have the app open when I am writing on the doc then the bell icon should update to show unread notifications with count.

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

قصص المستخدمين ذات المستخدم غير المحدد: أهمية تحديد الشخصية

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

إذا كنت ترغب في أن يكون فريقك أكثر توافقًا مع النتيجة المتوقعة منهم، فيجب أن يعرفوا من هم المستخدمون النهائيون وما الفائدة التي سيحصلون عليها من الميزة. كلما بدأت قصة مستخدم بعبارات عامة مثل “As a user...” (كمستخدم…)، أو “As a visitor...” (كزائر…)، أو “As a reader...” (كقارئ…)، فإنك تترك مجالًا للغموض.

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

As a writer, I want to receive notification when others add comments within the Google Docs app, so I don't have to refresh the page every now-and-then.

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

قصص المستخدمين ذات السياق الضعيف: البحث عن القيمة الحقيقية

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

إليك مثال على قصة مستخدم ذات سياق ضعيف:

As a content manager, I want a text editor so that I can edit text.

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

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

الخلاصة التقنية

في الختام، على الرغم من أن استخدام قالب قصص المستخدمين (user story template) يمكن أن يكون مفيدًا كإطار عمل، إلا أن العملية أبعد ما تكون عن مجرد ملء الفراغات في أداة الأجايل الخاصة بك. فخطأ واحد في صياغة قصة المستخدم غالبًا ما يؤدي إلى سلسلة من الأخطاء المتتالية كمنتج ثانوي. حتى لو تمكنت من كتابة قصص المستخدمين بشكل صحيح، فهذه ليست سوى البداية.

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