رسم متطلبات تطوير الميزات: دورة "إنشاء منتج برمجي وإدارة تطويره".

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

جدول محتويات الدورة

1.

2.

3.

4.

5.

6.

7. < —

8. - -

9.

—



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







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

كيف يتم بناء المتطلبات

عند صياغة متطلبات التطوير ، تحتاج إلى فهم المستخدم الذي نعمل على تطوير منتج له. هذا هو المكان الذي تكون فيه User Persona في متناول اليد (تحدثنا عنها بالفعل هنا ). User Persona هو ما يسمى الفاعل في النظام ، ولكل فاعل نحدد مجموعة من القواعد والإمكانيات.



على سبيل المثال ، يمكن تحديد الجهات الفاعلة التالية في تطبيق منتدى الويب:

• يمكن للمسؤول فعل كل شيء ، حرفيًا كل شيء - بما في ذلك تعيين الأدوار (الأشخاص) للمستخدمين الآخرين.
• يمكن للمستخدم العادي ترك الرسائل فقط.
• يمكن للمنسق ترك الرسائل وحذف رسائل الآخرين وحظر المستخدمين العاديين.

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







لصياغة مطلب مناسب ، تحتاج إلى إعداد مستند نسميه وصف الميزة. ولهذا عليك الإجابة على الأسئلة التالية:

• لاجل ماذا؟ ما هو الغرض؟ ما هي فوائد العمل؟
• لماذا ا؟ ما هي المخاطر؟ ماذا سنخسر إذا لم نفعل؟ ماذا يحدث لو فعلنا؟
• ماذا؟ ما المشكلة التي نريد حلها؟ لمن؟
• كيف؟ المتطلبات الوظيفية وحالة الاستخدام (تسلسل الإجراءات).

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



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

المقاييس المساعدة

عند العمل مع المتطلبات ، تساعد المقاييس الإضافية في تحقيق التنفيذ الدقيق للمهمة ، فضلاً عن تقليل الوقت المستغرق في التحقق من الامتثال.

• تعريف تم هو وصف موجز لكيفية معرفة ما إذا كانت الميزة تعمل أم لا.
• المتطلبات غير الوظيفية - متطلبات المعلمات التقنية مثل استجابة واجهة المستخدم وتحميل الواجهة الخلفية وقيود وحدة المعالجة المركزية وذاكرة الوصول العشوائي. هذه نقطة مهمة للغاية ، لأنه إذا لم تعبر عن المتطلبات ، يمكنك الحصول على فوتوشوب مدمج وحش بدلاً من مجرد اختيار لون السيارة.
• متطلبات الأمان - التشفير وتخزين البيانات الشخصية وما إلى ذلك.
• حافظة الزاوية - اختبار حالات الحافة. ماذا يحدث إذا كان سعر المنتج هو 0؟ كم عدد سيارات الأجرة التي يمكن للشخص طلبها في نفس الوقت؟
• — , . , , , , — Visa, MasterCard, , .
• . , , , , . , , . , .
• . , “ ”, “ ”.

المتطلبات الوظيفية وغير الوظيفية ، حالات الاستخدام

دعنا نتحدث قليلاً عن المتطلبات الوظيفية وغير الوظيفية. توضح







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



المتطلبات غير الوظيفية الظروف التي يجب أن يظل الحل فعالًا بموجبها ، أو الصفات التي يجب أن يمتلكها الحل. الأمثلة الأكثر شيوعًا للمتطلبات غير الوظيفية هي:

• قابلية التوسع،
• الموثوقية ، أقل وقت تعطل ،
• طرق الدعم.

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



تحتوي البرامج النصية للمستخدم عادةً على الأقسام التالية:



القسم: السياق

يجيب على السؤال: أي مكون؟ ما هو الشرط؟

مثال: المستخدم غير مصرح له.



القسم: ممثل

يجيب على سؤال: أي شخص؟

مثال: مستخدم عادي.



القسم: الشروط المسبقة

يجيب على السؤال: ما هي الميزات؟

مثال: هناك دعوة لاستلام حالة VIP.



الجزء:الغرض

يجيب على السؤال: ما الذي ينوي المستخدم فعله / الحصول عليه؟

مثال: تسجيل الدخول.



القسم: السيناريو الرئيسي

يجيب على السؤال: ما هي الإجراءات التي يجب اتخاذها لتحقيق النتيجة؟

مثال: أدخل اسم المستخدم وكلمة المرور ، اضغط على زر "دخول".



القسم: مخطوطات سيئة

يجيب على السؤال: ما الخطأ الذي يمكن أن يحدث ، قائمة الأخطاء ، بما في ذلك نص رسائل الخطأ للمستخدم.

مثال: لا يتم الضغط على الزر ، ولا تتغير اللغة ، ولا يمكن إنشاء الاتصال عبر بروتوكول https ، وما إلى ذلك ...



القسم: التخطيطات

يجيب على السؤال: التخطيطات المحتملة أو النماذج الأولية لتصميم واجهة المستخدم.

مثال: ارسم فيجما أو رسم.



في شكل مبسط ، قد تبدو البرامج النصية المخصصة كما يلي:

كيف تتم قراءة وصف الميزة؟

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

• المطورون - من المهم بالنسبة لهم معرفة سبب الحاجة إلى الميزة ، وما المشكلة التي تحلها. حتى لا تضيع الوقت في الإصلاحات لاحقًا ، يحتاج المطورون إلى تقديم قائمة كاملة بجميع السيناريوهات ، بالإضافة إلى الانتباه إلى حالات الزاوية. إذا أبلغت المطور في الوقت المناسب بما سنضيفه لاحقًا ، على سبيل المثال ، المدفوعات باستخدام بطاقة MIR ، فسيكون قادرًا على توقع هذا الاحتمال على مستوى الهندسة المعمارية. وبالتالي ، يمكن تخفيض التكاليف بشكل كبير عن طريق تجنب إعادة العمل.
• , QA — , . Corner Cases. , — , .. ( , , ) . , . .
• DevOps Datacenter Operations— , , , . DevOps , , , .
• — , , . , , .

إذا كتبت متطلبات التطوير ، فتأكد من طرح السؤال - من هو المستخدم الخاص بك ، وماذا يفعل (أو يمكنه القيام به) ، وفي أي ظروف يكون. قم بإنشاء رسم تخطيطي لسلوكه ، وسوف يساعد في وصف جميع جوانب المتطلبات.



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



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



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

خاتمة

في المقالة التالية ، سنتحدث عن خطة العمل والتسعير للمنتج الجديد.



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



← تسجيل فيديو لجميع محاضرات الدورة متاح على موقع يوتيوب



محاضرة حول خارطة الطريق ومتطلبات التطوير: