مرحبا يا هبر!
نود اليوم أن نتحدث عن الطريقة التي يتبعها فريق منتجاتنا في إعداد المتطلبات الوظيفية للمطورين عند إنشاء منتجات وميزات جديدة.
في مرحلة التطوير ، قد تنشأ العديد من المفاجآت ، خاصةً إذا لم يتم توضيح المهمة بوضوح. يمكن لأعضاء الفريق المختلفين فهم تطوير وأداء نفس الميزة بطرق مختلفة ، بحيث يكون مديرو المنتجات مسؤولين عن إنشاء منتج من تطوير المفهوم إلى الإصدار النهائي. وجزء مهم من هذه العملية هو إعداد المتطلبات الوظيفية.
مسألة وصف المهام للمطورين الذين سبق أن تطرقنا إليها في المقالة "
كيف نتعلم المديرون تعيين المهام للمطورين" ، ولكن تحدثنا فيها أكثر حول المشكلات الإدارية ، واليوم سنتحدث أكثر عن المشكلات الفنية. هذا عنصر مهم للغاية في أي نشاط تجاري يتم بيعه عبر الإنترنت. كل شركة تتطور بنشاط في بيئة الإنترنت ، في الواقع ، تتحول إلى عمل برمجيات. ولكن على الرغم من ذلك ، تميل الكفاءات في مجال إدارة المتطلبات إلى النمو ببطء شديد.
نتيجة لذلك ، غالبًا ما نرى نفس الصورة: تقع مهام الإدارات المختلفة باستمرار في قسم التطوير ، ويتم توضيح المتطلبات في هذه المهام بشكل غامض ، وبمجرد وضع شيء ما في موضع التنفيذ ، فإنه يعود فورًا للمراجعة (لأن المدير لم يصف بشكل كامل ما أردت ، وفعل المطور كما يراه مناسبا). والنتيجة واضحة: مواعيد نهائية لا يمكن التنبؤ بها للمهام التي قد تستغرق عدة أشهر ، وفريق تم إلغاء حمايته ، والتوترات داخل الفريق ، والعملاء غير الراضين ، والتخلف عن المنافسين ، وما إلى ذلك.
مع هذه المقالة نريد أن نقدم وصفة بسيطة تضع الأساس لحل مثل هذه المشاكل. يمكن التوصية به بأمان للدراسة (علاوة على ذلك ، للعمل) لجميع أولئك الذين يقومون بتعيين المهام.
الشركات المختلفة لها طرق مختلفة لكتابة المتطلبات الوظيفية ، لكن في
Retail Rocket استقرنا على هذا الخيار وحتى الآن ليس لدينا أي ندم.
المتطلبات الوظيفية: ما هو ولماذا هم في حاجة إليها
أولاً ، دعونا ننظر إلى المتطلبات الوظيفية.
المتطلبات الوظيفية - هذا هو بيان المشكلة للمطور. كل ما لم يتم الإشارة إليه في المتطلبات يتم وفقًا لتقدير المطور ، والذي يختلف في الغالب عن عرض مدير المنتج حول النتيجة المتوقعة. لذلك ، يجب أن تحتوي المتطلبات على إجابات لجميع الأسئلة الممكنة في المهمة.
المتطلبات الوظيفية تتكون عادة من:
- قصة المستخدم - توضح ما تتوقعه من فريق التطوير
- حالات الاستخدام - إظهار سيناريوهات الاستخدام
- Wireframes - أداة تصور لفكرتك
اليوم سوف نركز على قصة المستخدم وحالات الاستخدام.
قصة المستخدم
تصف قصة المستخدم ما الذي يقوم به المستخدم لدور معين لتحقيق النتيجة ، وما يحتاج المطور إلى القيام به لإنعاش هذه المهمة.
عادةً ما يتم استخدام القالب:
بصفتي <اسم دور> ، أريد أن <الغرض ، الإجراء> ، بحيث <النتيجة المرتقبة> ، أن أفعل <ما يجب على المطور فعله>هناك أمثلة مختلفة لتطبيق هذه المنهجية. على سبيل المثال ، هذه هي الطريقة التي
تعمل بها في Trello:
في Retail Rocket ، نقوم بإنشاء قصص المستخدم في محرّر مستندات Google باستخدام الجداول. يساعد ذلك في تبسيط عملية الاتصال بين الفرق المختلفة ، حيث يمكن للجميع ترك التعليقات وإبداء الرأي.
على سبيل المثال ، هذه هي الطريقة التي تبدو بها مهمة تتبع NPS لمتجر عبر الإنترنت:
بفضل هذا التصور التفاعلي ، تنتقل مهمة المستخدم بسلاسة ومنطقية إلى مهمة المطورين. ثم يأتي دور حالات الاستخدام.
استخدام الحالات
حالات الاستخدام تصف سلوك المستخدم خطوة بخطوة عند التفاعل مع منتج مطور.
مهمة المستخدم هي ما يفعله المستخدم لتحقيق أهداف قصيرة الأجل.
إذا قام المستخدم بحل المشكلة على الصفحة المطورة بعدة طرق ، فيجب أن يكون لكل حل حالة استخدام خاصة به. على سبيل المثال ، إذا كان الوصول إلى الوظيفة المتأثرة موجودًا على عدة صفحات ، فيجب عليك كتابة حالة استخدام منفصلة لكل طريقة ينتقل بها المستخدم إلى الوظيفة.
دعونا نلقي نظرة على مثال لميزتنا التي تم إصدارها مؤخرًا -
معرض الصور والخطوط للمراسلات الجماعية.
هدف المستخدم هو تخزين الصور في نظامنا الأساسي واستخدامها لإنشاء حملات البريد الإلكتروني.
مهام المستخدم:
- تحميل الصور
- تضمين الصور في قالب الرسالة
- حذف الصور
لكل مهمة تحتاج إلى كتابة حالة الاستخدام الخاصة بك - وصف لكيفية تفاعل المستخدم مع الواجهة.
أمثلة لحالات الاستخدام:تحميل الصور:
- البريد الإلكتروني المسوق سجلات في حسابك الشخصي التجزئة الصواريخ
- البريد الإلكتروني المسوق يفتح قسم معرض
- يقوم برنامج التسويق عبر البريد الإلكتروني بتحميل الصور عبر السحب والإفلات أو عن طريق النقر على زر "تحديد الملفات"
- يتم تحميل الصور
- يرى المستخدم إشعارًا بالتحميل الناجح للصور
حذف الصور:
- ينقر المستخدم على الصورة
- الصورة تبرز
- يمكن إزالة التحديد عن طريق النقر فوق المنطقة الموجودة خارج الصورة المحددة.
- ينقر المستخدم على أيقونة النقاط الثلاث
- تظهر قائمة السياق.
- يحدد المستخدم رابط "حذف الملف" فيه. إذا تم اختيار العديد من الصور ، فسيتم حذف كل شيء.
- تم حذف الصورة
يتم رسم جميع سيناريوهات الاستخدام بنفس الطريقة ، مما يمنح التطوير فهمًا واضحًا لكيفية ظهور تفاعل المستخدم مع المنتج أو الميزات ، وما الذي يجب القيام به لهذا الغرض.
لماذا المتطلبات الوظيفية مهمة جدا
باستخدام هذا التنسيق للمتطلبات الوظيفية ، فإنك تزود فريق التطوير بتعليمات واضحة. بالإضافة إلى ذلك ، يمكنك إظهار كيف تبدو الواجهة من جانب العميل وكيف يحل مهامه. يساعد هذا النهج في تقديم فكرتك وتجنب سوء الفهم في الفريق.
عادةً ما تقدم لهم صياغة المشكلة للمطورين الكثير من الأسئلة ، الإجابات التي تعتمد على تعقيد وتوقيت التنفيذ. لتوضيح التفاصيل ، يتعين عليهم قضاء بعض الوقت في التواصل بدلاً من عملهم المباشر - إنشاء ميزات رائعة وتحسين المنتج. وحتى في عملية الاتصال ، لا يتم توضيح جميع التفاصيل الدقيقة دائمًا إذا كان مدير المهام يجيب فقط على الأسئلة التي تنشأ ، لكن المستخدم لا يسير بنفس الطريقة.
خذ مثال معرضنا. إذا توصل مدير المنتج للتو إلى مهمة إنشاء معرض ، عند نقطة واحدة حول حذف الملف ، فسيتعين على المطورين توضيح:
- هل أحتاج إلى حذف الملف على الإطلاق؟
- هل سيكون حذف يدوي أو هل سيتم حذف الملفات الأقدم تلقائيًا عند تنزيل ملفات جديدة ، إذا تم تجاوز حد التخزين؟
- هو الإزالة من قائمة الملفات أو هل تحتاج إلى فتح الملف
- هل تم حذف الملف نهائيًا أم أن هناك سلة للملفات حيث يتم تخزينها لبعض الوقت؟ إذا كنت بحاجة إلى سلة ، فكم عدد الملفات المخزنة فيها؟
- يجب أن يكون هناك حذف ملف دفعي أو يمكن حذف واحد فقط؟
- يتم حذف الملف باستخدام أيقونة منفصلة (كيف تبدو هذه الأيقونة؟) أو من خلال عنصر قائمة (ما الذي سيتم تسميته؟ أين يقع في قائمة الإجراءات؟)
- الخ
بعد كل شيء ، هذه مجرد واحدة من نقاط المهمة ، وهناك بالفعل العديد من الأسئلة. ومعرفة كل منهما يتطلب الوقت والجهد من كلا الجانبين.
تساعد المتطلبات الوظيفية مدير المنتج على التفكير في جميع سيناريوهات تفاعل المستخدم وصياغتها بوضوح من الواجهات داخل المهمة.
كلما تم طرح المهمة بشكل أكثر دقة والمزيد من التفاصيل لدى المطورين قبل بدء العمل ، كان العمل أكثر فعالية. لا يضيع الوقت في التواصل الطويل الذي لا معنى له في بعض الأحيان. في هذه الحالة ، تستفيد جميع الأطراف: يحصل المطورون على فهم واضح لما وكيفية القيام به ، ويقوم موفر المهمة بإنجاز العمل بالضبط بالشكل الذي تخيله فيه.
وكيف تتعامل مع صياغة المهام للمطورين؟
مدير المنتج Gulfiya Kurmangaleeva