20 برومبتات لمدير المنتج تُظهر المفاضلات

01. اكتب وثيقة متطلبات من ملخص فوضوي واسرد الأسئلة المفتوحة

لديك محادثة على Slack وملاحظات مكالمة وموعدًا نهائيًا، لكن لا توجد مواصفات.

حوّل هذا الملخص الفوضوي إلى وثيقة متطلبات منتج.

[الصق الملخص أو المحادثة أو ملاحظات المكالمة أو أي مادة لديك]

الأقسام بهذا الترتيب: المشكلة ومن يعاني منها، والأدلة التي لدينا عليها، والهدف بنتيجة قابلة للقياس، وما يدخل في النطاق، وما يخرج من النطاق، ومسار المستخدم في خطوات مرقّمة، والمتطلبات مع وسم كل منها بـ MUST أو SHOULD، والاعتماديات على الفرق الأخرى.

استخدم فقط ما يقوله الملخص. وحيثما يسكت عن أمر، اكتب [مفتوح: السؤال] بدل أن تملأ الفراغ من عندك.

ثم اسرد في النهاية كل سؤال مفتوح، مجمّعًا حسب من يستطيع الإجابة عنه (أنا، التصميم، الهندسة، الشؤون القانونية، أحد العملاء)، وابدأ بالأسئلة الثلاثة التي تعطّل البناء.

02. قسّم ميزة إلى قصص مستخدم مع معايير القبول

اجتماع تحسين الأعمال المتراكمة غدًا والميزة ما زالت تذكرة واحدة كبيرة.

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

الميزة: [ما تفعله]
المستخدمون: [من يستخدمها وما الذي يحاولون إنجازه]
القيود: [المنصات والمواعيد النهائية وما بُني بالفعل]

لكل قصة:
1. بصفتي [المستخدم]، أريد [الإجراء]، لكي [النتيجة].
2. معايير القبول بصيغة Given / When / Then، من ثلاثة إلى ستة لكل قصة، وكل معيار يمكن اختباره بواسطة شخص لم يكتبه.
3. تقدير للحجم بـ S أو M أو L، والأمر الوحيد الذي يجعله غير مؤكد.

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

03. اكتشف الحالات الحدية التي فاتت وثيقة المتطلبات

تبدو المواصفات مكتملة والهندسة تبدأ الأسبوع القادم.

اقرأ وثيقة المتطلبات هذه بعين المهندس الذي ستصله بلاغات الأخطاء بعد الإطلاق.

[الصق وثيقة المتطلبات أو المواصفات]

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

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

افتح الأوامر الـ17 الأخرى مجانًا

اشترك في نشرة Whizi البريدية لقراءة بقية هذه الحزمة.

4. قيّم قائمة الأعمال المتراكمة بـ RICE واعرض الحساب
5. حوّل ملاحظات المقابلات إلى مهام ومشكلات واقتباسات
6. اكتب دليل مقابلة اكتشاف يركّز على ما فعله الناس لا على ما يريدونه
7. جمّع تذاكر الدعم في مشكلات منتج تستحق الإصلاح
8. اكتب مواصفات من صفحة واحدة يستطيع المهندسون البناء منها
9. اختر مقياس نجاح ومقياسًا مضادًا يبقيه صادقًا
10. صمّم تجربة وأجب عن أسئلة حجم العينة أولًا
11. ابنِ قائمة تحقق للإطلاق مع مسؤول لكل فريق
12. اكتب ملاحظات إصدار يقرؤها المستخدمون فعلًا
13. اكتب تحديثًا لأصحاب المصلحة يبدأ بما تغيّر
14. اكتب سردية لخريطة الطريق تذكر ما لن تفعله
15. ارفض طلب ميزة مع السبب وخطوة تالية
16. أجرِ تحليلًا استباقيًا للفشل قبل أن يصدر الإطلاق
17. فكّك صفحة منتج منافس ادعاءً بادعاء
18. اكتب هدفًا واحدًا للسبرنت من قائمة طويلة من التذاكر
19. حوّل حلًا مطلوبًا إلى المشكلة التي وراءه
20. اجعل نموذجًا ثانيًا يراجع وثيقة المتطلبات التي كتبها الأول