التعريف: قصة المستخدم هي وحدة صغيرة قائمة بذاتها من أعمال التطوير مصممة لتحقيق هدف محدد داخل منتج ما. عادةً ما تتم كتابة قصة المستخدم من منظور المستخدم وتتبع التنسيق: "بصفتي [شخصية مستخدم] ، أريد [تنفيذ هذا الإجراء] حتى [يمكنني تحقيق هذا الهدف]."
ما هي قصة المستخدم؟
في تطوير البرمجيات الرشيقة ، تكون قصة المستخدم عبارة عن شرح موجز بلغة بسيطة لميزة أو وظيفة مكتوبة من وجهة نظر المستخدم. يصف العديد من خبراء أجايل أيضًا قصة المستخدم على أنها أصغر وحدة في تطوير المنتج يمكن أن تؤدي إلى عنصر كامل من وظائف المستخدم.
تختار فرق المنتج تقسيم أعمال التطوير إلى قصص المستخدمين بدلاً من ميزات المنتج أو متطلبات المنتج لعدة أسباب.
قصص المستخدم:
- من السهل على أي شخص فهمها
- قم بتمثيل مخرجات صغيرة الحجم يمكن أن تتناسب مع سباقات السرعة ، بينما لا يمكن لجميع الميزات الكاملة ذلك.
- ساعد الفريق في التركيز على الأشخاص الحقيقيين ، بدلاً من الميزات المجردة
- بناء الزخم من خلال منح فرق التطوير شعوراً بالتقدم
كيف تبدو قصة المستخدم؟
تستخدم معظم فرق المنتج نموذج قصة مستخدم مشابه ، وعادة ما تكون مجرد جملة أو جملتين مكتوبة وفقًا للصيغة التالية:
بصفتي [ وصفًا للمستخدم ] ، أريد [ وظيفة ] بحيث [ تستفيد ].
أمثلة قصة المستخدم
في الممارسة العملية ، قد تبدو قصص المستخدم كما يلي:
- بصفتي مسؤول قاعدة بيانات ، أريد دمج مجموعات البيانات تلقائيًا من مصادر مختلفة حتى أتمكن من إنشاء تقارير بسهولة أكبر لعملائي الداخليين.
- بصفتي مديرًا للعلامة التجارية ، أرغب في تلقي تنبيهات عندما يعلن البائع عن منتجاتنا بأقل من الأسعار المتفق عليها حتى أتمكن من اتخاذ إجراء سريعًا لحماية علامتنا التجارية.
- بصفتي قائد فريق بعيد ، أريد أن يتضمن تطبيق مراسلة الفريق مشاركة الملفات والتعليقات التوضيحية حتى يتمكن فريقي من التعاون في الوقت الفعلي والاحتفاظ بأرشيف لعملهم في مكان واحد.
كما ترى من المثال الثالث أعلاه ، لا يجب أن تقتصر الشخصية في قصة المستخدم الخاصة بك على المسمى الوظيفي للشخص. يمكن أن يكون " قائد فريق بعيد " مدير قسم ، أو نائب رئيس شركة ، أو الرئيس التنفيذي لشركة صغيرة ناشئة ، أو أي عدد من الأدوار الأخرى في المؤسسة.
ولكن لغرض شرح هذه القصة - السماح للمستخدمين بتحميل ملف إلى تطبيق مراسلة الفريق الخاص بك ثم عمل تعليقات توضيحية أصلية على هذا الملف - فمن المنطقي وصف المستخدم لهذه الميزة بأنه شخص يشرف على فريق من الزملاء العاملين في أماكن مختلفة. قد يكون المستخدمون المتنوعون الموصوفون في القصص التي يكتبها فريقك في بعض الحالات نفس الشخص الذي يحتاج إلى وظائف مختلفة لمهام مختلفة.
من يجب أن يكتب قصص المستخدم؟
في العديد من المؤسسات الرشيقة ، يتحمل مالك المنتج المسؤولية الأساسية عن كتابة قصص المستخدمين وتنظيمها في تراكم المنتج . في الواقع ، هذه مسؤولية مشتركة بين فريق المنتج متعدد الوظائف بأكمله.
في الواقع ، أحد أسباب كتابتها بلغة واضحة - خالية من أي مصطلحات تطويرية أو تفاصيل فنية - هو أن هذا يسمح لأي شخص في الجانب التجاري أو الفني للفريق بالمساهمة بقصة مستخدم للنظر فيها. يحتاج عضو الفريق (مدير المنتج ، مصمم UX ، وما إلى ذلك) فقط إلى فهم مشكلة المستخدم والشخصية المحددة التي يأملون في حلها. لا يحتاجون إلى معرفة كيف سيقوم فريق التطوير بالفعل بترميز هذا الحل.
قصة المستخدم مقابل واقعة الاستخدام: ما الفرق؟
مثل قصص المستخدم ، تصف حالة الاستخدام كيفية تفاعل المستخدم مع منتج لحل مشكلة معينة. لكن الاثنين غير قابلين للتبادل. إنها أدوات مختلفة تستخدم في تطوير المنتجات.
يوضح Ivar Jacobson ، الذي يُنسب إليه الفضل في تطوير مفهوم حالة الاستخدام ، أن حالات الاستخدام توثق كلاً من هدف المستخدم والمتطلبات الوظيفية للنظام . بعبارة أخرى ، تم تصميم حالات الاستخدام لالتقاط تفاصيل أكثر بكثير من قصة المستخدم حول العملية التي يمر بها المستخدم لتحقيق النتيجة المرجوة من التفاعل مع المنتج.
بينما تتم كتابة قصة المستخدم على أنها بيان موجز للغاية يصف الهدف النهائي للمستخدم فقط ، فإن حالة الاستخدام غالبًا ما تصف عدة خطوات إضافية ، بما في ذلك:
- الشروط المسبقة المطلوبة قبل أن تبدأ حالة الاستخدام
- التدفق الرئيسي للأحداث (يسمى أيضًا التدفق الأساسي) يصف مسار المستخدم ، خطوة بخطوة ، لإكمال إجراء مع المنتج
- التدفقات البديلة والاستثناءات ، بمعنى المسارات المتغيرة التي قد يتخذها المستخدم مع المنتج لإكمال نفس الهدف أو هدف مشابه
- ربما رسم تخطيطي مرئي يصور سير العمل بأكمله
كيف تكتب قصة مستخدم؟
إليك عملية بسيطة من ست خطوات لصياغة قصص المستخدم:
الخطوة 1: حدد شكل "تم".
في معظم الحالات ، تصف قصة المستخدم حالة نهائية: عندما يكون المستخدم قادرًا على إكمال المهمة أو تحقيق الهدف الموصوف. يجب أن تضع هذه الحالة النهائية في الاعتبار عندما تكتب حالتك ، حتى يعرف باقي أعضاء فريقك متى يمكنهم وضع علامة على أعمال التطوير المنجزة. (تعرف على المزيد حول تعريف تم .)
الخطوة 2: توثيق المهام والمهام الفرعية.
على الرغم من أن قصة المستخدم الفعلية ستتضمن فقط العبارة القياسية التي وصفناها أعلاه - "بصفتي [شخصية] ، أريد [ميزة] بحيث [السبب]" - ستحتاج أيضًا إلى توثيق التفاصيل المطلوبة لإكمال أعمال التطوير الموضحة في القصة. وهذا يعني تحديد المهام والمهام الفرعية وتعيينها إلى الأشخاص المناسبين.
الخطوة 3: تحديد شخصيات المستخدم الخاصة بك.
من خدم في هذه القصة؟ أي نوع من المستخدم أو العميل؟ تحتاج إلى توثيق هذا مقدما. إذا كان لديك العديد من المستخدمين المختلفين في الاعتبار ، فقد ترغب في تقسيم ذلك إلى أكثر من قصة مستخدم واحدة. بهذه الطريقة يمكن لفريقك الاستمرار في التركيز على مساعدة شخصية معينة في تحقيق هدف محدد لكل قصة.
الخطوة 4: إنشاء قصص كخطوات مرتبة.
يقترح مفهوم تعيين قصة المستخدم أنه يمكنك التفكير في منتجك بالكامل كسلسلة من المهام أو الوظائف التي يساعد المنتج المستخدمين على إكمالها. مع وضع ذلك في الاعتبار ، إذا كنت تحاول هيكلة العمل على عملية أكبر أو مجموعة أكثر شمولاً من وظائف المنتج ، فاكتب كل خطوة قائمة بذاتها كقصة.
الخطوة 5: ابحث عن ملاحظات المستخدم.
لتحسين فرصك في تخصيص الموارد لأعمال التطوير التي سيكون لها صدى في السوق الخاص بك ، تحدث إلى المستخدمين والعملاء حول أولوياتهم ، وتعرف على ما يريدون أكثر من منتجاتك. يجب أن تبدأ في صياغة قصص المستخدمين فقط بعد جمع هذه التعليقات وتحليلها.
الخطوة 6: صياغة القصص التي يمكن إكمالها في سباق واحد.
يجب تقسيم قصص المستخدمين التي تستغرق وقتًا أطول من سباق واحد (عادةً أسبوعين) إلى قصص أصغر. بهذه الطريقة ، يشعر فريقك بالاكتمال في كل سباق ، لأنهم قادرون على إكمال بعض الوظائف الجديدة في كل مرة. كما يتيح لفريقك طرح وظائف جديدة في السوق بشكل متكرر.
فرق المنتج ، لماذا لا تكتب مع المستخدمين لديك؟
بصرف النظر عن حقيقة أنها مصممة لتلائم بطاقات الفهرسة ويمكن لأي شخص فهمها بسهولة ، فإن إحدى أكبر مزايا قصص المستخدم هي أنها يمكن أن تساعدك على عدم الضياع في التفاصيل الفنية للواجهة الخلفية لمنتجك أو من أن تصبح مغرم بتجربة المستخدم التي تعتقد أنها أنيقة ولكن هذا ليس منظمًا في الواقع بالطريقة التي يفضلها المستخدمون للعمل.
تساعد قصص المستخدمين فريقك على تحقيق كل هذا - وبناء منتجات أفضل - من خلال إجبارك على إجراء تغيير بسيط واحد على نهجك في التخطيط للتنمية. بدلاً من كتابة خططك من وجهة نظر المنتج (الميزات التي يجب إنشاؤها) ، تجبرك قصص المستخدمين على صياغة كل فكرة مقترحة لوظيفة جديدة من وجهة نظر الأشخاص الفعليين الذين سيستخدمون هذه الوظيفة.