كيف تكتب وثيقة متطلبات منتج بالذكاء الاصطناعي (مع قالب مجاني)
وثيقة متطلبات المنتج (PRD) وصف قصير بلغة بسيطة لما تبنيه، ولمن هو، وما الذي يجب أن يفعله، وكيف ستعرف أنه يعمل. يجعل الذكاء الاصطناعي كتابتها أسرع بكثير: تعطيه ملاحظات أولية فيحوّلها إلى أقسام منظمة وقصص مستخدم وحالات استثنائية. دورك أنت أن تقدم القرارات التي لا يستطيع الذكاء الاصطناعي اتخاذها، أي الهدف والنطاق وما يُترك خارجه، وأن تتحقق مما يضيفه.
يغطي هذا الدليل ما يجب أن تتضمنه وثيقة PRD، وطريقة خطوة بخطوة لصياغتها مع أي مساعد ذكاء اصطناعي، وبرومبتات لكل قسم، وقالب جاهز للنسخ والتعبئة.
ما هي وثيقة PRD ولماذا تُكتب؟ (وما ليست عليه)
تجيب وثيقة PRD عن أربعة أسئلة:
- لماذا نبني هذا؟ ما المشكلة، ولمن؟
- ماذا يجب أن يفعل في النسخة الأولى؟
- ماذا لن يفعل بعد؟
- كيف سنعرف أنه نجح؟
هي ليست تصميماً تقنياً. لا تحدد قاعدة البيانات أو الإطار البرمجي الذي تستخدمه، فهذا يخص مواصفة تقنية منفصلة إن احتجت إليها أصلاً. وهي ليست خطة تسويق أو خطة عمل. إبقاء الوثيقة على سلوك المنتج هو ما يجعلها مفيدة لكل من يقرؤها: المصمم، والمطور، والمسؤول الذي يعتمدها، أو أداة بناء التطبيقات بالذكاء الاصطناعي التي تحولها إلى كود.
من يحتاج إليها؟
- المؤسسون الفرديون الذين يريدون منع توسع النطاق قبل أن يبدأ.
- الفرق الصغيرة التي تحتاج إلى مكان واحد يُحفظ فيه ما اتفقوا عليه.
- كل من يوظف مستقلاً أو وكالة، لأن وثيقة واضحة تحصل على عروض أسعار أوضح. راجع توظيف مطور أو البناء بالذكاء الاصطناعي.
- كل من يبني بالذكاء الاصطناعي، لأن قصص المستخدم وقائمة البيانات في الوثيقة تصنع برومبتات أفضل من قائمة أمنيات غير منظمة.
ما الذي يجيده الذكاء الاصطناعي وما الذي لا يجيده؟
| المهمة | ما يجيده الذكاء الاصطناعي | ما تبقى مسؤولاً عنه أنت |
|---|---|---|
| تحويل ملاحظات مبعثرة إلى أقسام | نعم | التأكد من عدم اختلاق أي شيء |
| كتابة قصص المستخدم بصيغة متسقة | نعم | تحديد القصص التي تدخل النسخة الأولى |
| سرد الحالات الاستثنائية (الحالات الفارغة، والأخطاء، والصلاحيات) | نعم، وغالباً أفضل من إنسان مرهق | تحديد الحالات المهمة فعلاً |
| اقتراح مؤشرات النجاح | يقدم خيارات معقولة | اختيار مؤشرات يمكنك قياسها فعلاً |
| معرفة مستخدميك أو سوقك أو ميزانيتك | لا | كل شيء من مسؤوليتك |
| تحديد ما يُستبعد | لا، إنه يميل إلى الإضافة لا إلى الحذف | كل شيء من مسؤوليتك |
أكثر الأخطاء شيوعاً هو عكس الصف قبل الأخير: يملأ الذكاء الاصطناعي الفجوات بتخمينات معقولة الشكل عن مستخدميك. عامل أي شيء يكتبه عن المستخدمين أو حجم السوق أو السلوك على أنه سؤال يجب التحقق منه، لا على أنه حقيقة.
الخطوة 1: أفرغ ما تعرفه
قبل أن تطلب أي شيء من الذكاء الاصطناعي، اكتب ملاحظات أولية. النقاط المختصرة مناسبة. غطِّ ما يلي:
- المشكلة في جملة أو جملتين، من وجهة نظر المستخدم.
- من يعاني منها. كن محدداً: «مسكي دفاتر حسابات مستقلون لديهم من 10 إلى 40 عميلاً»، وليس «الشركات الصغيرة».
- ما الذي يفعله اليوم بدلاً من ذلك (جدول بيانات، أو بريد إلكتروني، أو أداة لا يحبها).
- النتيجة الواحدة التي تجعل النسخة الأولى ناجحة.
- أي شيء تعرف مسبقاً أنك لن تفعله.
- القيود الصارمة: الموعد النهائي، والميزانية، وضرورة العمل على الهواتف، وضرورة التكامل مع أداة تستخدمها بالفعل.
إذا لم تتحدث مع أي شخص يعاني من هذه المشكلة، فابدأ بذلك أولاً. يقدم دليل كيف تتحقق من فكرة التطبيق طريقة عملية لذلك. وثيقة PRD مبنية على التخمين ليست سوى تخمين بتنسيق جيد.
الخطوة 2: اطلب من الذكاء الاصطناعي مسودة أولى
ألصق ملاحظاتك واطلب مسودة بهيكل ثابت. برومبت يعمل جيداً:
هذه ملاحظاتي عن منتج. حوّلها إلى وثيقة متطلبات منتج باستخدام هذه الأقسام بالضبط: الملخص، والمشكلة، والمستخدمون، والأهداف ومؤشرات النجاح، والنطاق (داخل / خارج)، وقصص المستخدم مع معايير القبول، والبيانات، والصلاحيات، والحالات الاستثنائية، والأسئلة المفتوحة. اجعلها أقل من صفحتين. لا تختلق معلومات عن المستخدمين أو السوق، وحين لا تذكر ملاحظاتي شيئاً، اكتب السؤال في قسم الأسئلة المفتوحة بدلاً من ذلك.
التعليمة الأخيرة مهمة. توجيه الذكاء الاصطناعي إلى وضع المجهولات في «الأسئلة المفتوحة» بدلاً من ملئها بنفسه ينتج مسودة أكثر أمانة بكثير.
الخطوة 3: شدّد كل قسم
راجع المسودة قسماً قسماً. تساعد برومبتات المتابعة هذه:
المشكلة والمستخدمون
أعد كتابة بيان المشكلة في جملة أو جملتين من وجهة نظر المستخدم. دون كلمات تتعلق بالحل.
إذا ذكر بيان المشكلة منتجك، فهو يصف حلاً وليس مشكلة.
الأهداف ومؤشرات النجاح
اقترح ثلاثة مؤشرات نجاح للنسخة الأولى يمكنني قياسها خلال الشهر الأول مع عدد صغير من المستخدمين. ولكل منها، اشرح كيف سأقيسه.
اختر واحداً أو اثنين. «عشرون مسكاً لدفاتر الحسابات يستخدمونه أسبوعياً لمدة شهر» قابل للقياس. «تحسين الإنتاجية» غير قابل للقياس.
النطاق
اذكر كل ما في هذه الوثيقة الذي يمكن نقله إلى نسخة لاحقة دون أن يكسر التدفق الأساسي.
تميل أدوات الذكاء الاصطناعي إلى إضافة الميزات. هذا البرومبت يجعلها تفعل العكس. كن صارماً: معظم وثائق PRD للنسخة الأولى كبيرة أكثر من اللازم. يشرح ما هو الحد الأدنى من المنتج القابل للتطبيق (MVP) لماذا تعلّمك النسخ الأولى الصغيرة أكثر.
قصص المستخدم ومعايير القبول
اكتب كل متطلب على شكل قصة مستخدم («بصفتي [مستخدم]، أريد [إجراء] حتى [نتيجة]») مع اثنين إلى أربعة معايير قبول بصيغة Given / When / Then.
معايير القبول هي قائمة التحقق التي ستختبر بها لاحقاً. «عندما يُحجز موعد، وعندما يفتح عميل آخر التقويم، فإن الموعد لا يظهر له» معيار قابل للاختبار. «الحجز يعمل بشكل جيد» ليس كذلك.
الحالات الاستثنائية والصلاحيات
لكل قصة مستخدم، اذكر ما يحدث عند غياب البيانات، أو الإدخال غير الصحيح، أو بطء طلب الشبكة أو فشله، أو عند وصول مستخدم إلى شيء لا يُفترض أن يملك صلاحية الوصول إليه.
هنا يكسب الذكاء الاصطناعي قيمته. فهو سريع في اكتشاف الحالات الفارغة وثغرات الصلاحيات التي ينساها الناس.
الخطوة 4: راجعها بعين المتشكك
اقرأ الوثيقة كاملة مرة أخرى وتحقق مما يلي:
- كل ادعاء عن المستخدمين جاء منك أو من بحث، لا من الذكاء الاصطناعي.
- قسم النطاق «خارج» على الأقل بنفس طول قسم «داخل».
- كل قصة مستخدم لديها معايير قبول يمكن لأي شخص اختبارها دون أن يسألك.
- قسم البيانات يسرد كل نوع من السجلات يحتفظ به التطبيق، ومن يستطيع رؤيته.
- الأسئلة المفتوحة لكل منها مسؤول وتاريخ.
- لا يتسلل أي شيء تقني إلا إذا كان قيداً حقيقياً («يجب أن يعمل دون اتصال» متطلب؛ «استخدم Redis» ليس كذلك).
ثم شارك الوثيقة مع شخص واحد على الأقل سيستخدم المنتج أو يبنيه، واسأله عما هو غير واضح. أسئلته هي الفجوات.
قالب PRD للتعبئة
انسخ هذا في مستند واستبدل ما بين الأقواس. احذف أي قسم لا ينطبق فعلاً.
اسم المنتج: [الاسم] المالك: [الشخص المسؤول عن القرارات] الحالة: [مسودة / قيد المراجعة / متفق عليه] — آخر تحديث: [التاريخ]
1. الملخص
[جملتان أو ثلاث: ما هذا، ولمن، والنتيجة الرئيسية.]
2. المشكلة
[المشكلة من وجهة نظر المستخدم. ماذا يفعل اليوم، ولماذا يؤلمه ذلك.]
3. المستخدمون
| نوع المستخدم | ما يحتاجه | كم مرة سيستخدمه |
|---|---|---|
| [مثال: المالك] | [الحاجة] | [يومياً / أسبوعياً] |
| [مثال: العميل] | [الحاجة] | [أحياناً] |
4. الأهداف ومؤشرات النجاح
- الهدف: [النتيجة التي يجب أن تحققها النسخة الأولى]
- المؤشر: [كيف ستقيسه، والهدف المطلوب]
- ليس هدفاً: [شيء قد يفترضه الناس، وهذه النسخة لا تحاول تحقيقه]
5. النطاق
في النسخة الأولى:
- [ميزة]
- [ميزة]
ليست في النسخة الأولى:
- [ميزة، ولماذا يمكن أن تنتظر]
- [ميزة، ولماذا يمكن أن تنتظر]
6. قصص المستخدم
القصة 1: بصفتي [مستخدم]، أريد أن [إجراء] حتى [نتيجة].
- Given [السياق]، when [الإجراء]، then [النتيجة].
- Given [السياق]، when [الإجراء]، then [النتيجة].
القصة 2: بصفتي [مستخدم]، أريد أن [إجراء] حتى [نتيجة].
- Given [السياق]، when [الإجراء]، then [النتيجة].
7. البيانات
| السجل | الحقول الأساسية | من يستطيع الإنشاء | من يستطيع الرؤية |
|---|---|---|---|
| [مثال: الحجز] | [التاريخ، الوقت، العميل، الخدمة] | [العميل] | [المالك، وذلك العميل] |
8. الصلاحيات
[من يستطيع تسجيل الدخول، وما الأدوار الموجودة، وما الذي يستطيع كل دور رؤيته وتغييره.]
9. الحالات الاستثنائية
- [حالة فارغة: ما الذي يظهر عند عدم وجود أي بيانات بعد]
- [إدخال غير صحيح: ما الذي يحدث مع بريد إلكتروني خاطئ أو حقل ناقص]
- [الوصول: ما الذي يحدث عندما يفتح شخص صفحة لا يحق له فتحها]
10. التكاملات والقيود
[المدفوعات، والبريد الإلكتروني، والأدوات الموجودة، والمواعيد النهائية، والميزانية، والأجهزة التي يجب أن يعمل عليها.]
11. الأسئلة المفتوحة
| السؤال | المسؤول | القرار بحلول |
|---|---|---|
| [السؤال] | [الاسم] | [التاريخ] |
من PRD إلى البرومبتات
وثيقة PRD الجيدة تتحول تقريباً مباشرة إلى برومبتات لأداة بناء تطبيقات بالذكاء الاصطناعي:
- الملخص والمستخدمون وجدول البيانات تصبح برومبتك الأول.
- كل قصة مستخدم تصبح برومبت متابعة واحداً.
- كل معيار قبول يصبح شيئاً تختبره في المعاينة.
- قائمة «ليست في النسخة الأولى» هي ما ترفض طلبه بعد.
بناء قصة واحدة في كل مرة، ومراجعة معايير قبولها قبل الانتقال إلى التالية، أكثر موثوقية بكثير من لصق الوثيقة كاملة وطلب كل شيء دفعة واحدة. يغطي كيف تكتب برومبتات لأدوات بناء تطبيقات الذكاء الاصطناعي الجانب الخاص بكتابة البرومبتات بتفصيل أكبر.
أخطاء شائعة
- كتابة الحل بدلاً من المشكلة. «المستخدمون يحتاجون إلى لوحة معلومات» حل. «المالكون لا يستطيعون معرفة الفواتير المتأخرة دون فتح كل فاتورة» مشكلة.
- غياب قسم «خارج النطاق». بدونه، يُعاد فتح النطاق في كل محادثة.
- ترك الذكاء الاصطناعي يختلق المستخدمين. الشخصيات التي يخترعها الذكاء الاصطناعي تبدو حقيقية وليست كذلك.
- مؤشرات لا يمكنك قياسها. إذا لم تكن لديك طريقة لعدّها، فهي ليست مؤشراً.
- عدم تحديثها أبداً. وثيقة لا تطابق ما تبنيه أسوأ من عدم وجودها. احتفظ بتاريخ «آخر تحديث» وغيّره عندما تتغير القرارات.
استخدام PRD مع Mythex
إذا كنت تبني في Mythex، يمكنك لصق وثيقة PRD مباشرة في المحادثة. وضع Plan مناسب جداً لوثيقة PRD: يقرؤها الوكيل، ويقترح نهجاً وقائمة خطوات تراجعها في تبويب الخطة، ولا يبدأ تعديل الملفات إلا عندما تضغط Build. يمكنك أيضاً حفظ الأجزاء التي يجب أن تنطبق دائماً، مثل الجمهور والعلامة التجارية والقواعد، كمعرفة للمشروع حتى لا تكررها في كل محادثة. تشرح وثائق المحادثة أوضاع Build وPlan وAsk، وتتيح القوالب طريقة سريعة لرؤية شكل النسخة الأولى المحتملة قبل أن تكتب الوثيقة كاملة.
الأسئلة
ما هي وثيقة متطلبات المنتج؟
وثيقة متطلبات المنتج (PRD) وثيقة قصيرة توضح ما الذي يجب أن يفعله منتج أو ميزة، ولمن هي، وكيف ستعرف أنها تعمل. تصف المشكلة والسلوك المتوقع وليس الكود، حتى يتمكن المصممون والمطورون وأدوات الذكاء الاصطناعي من البناء عليها.
هل يستطيع الذكاء الاصطناعي كتابة PRD نيابة عني؟
الذكاء الاصطناعي جيد في تحويل ملاحظاتك إلى مسودة منظمة، وفي اكتشاف الأقسام الناقصة واقتراح الحالات الاستثنائية. لكنه لا يعرف مستخدميك أو قيودك أو أولوياتك، لذلك أنت من يحدد الهدف والنطاق وما يُستبعد، وتتحقق من كل متطلب يضيفه.
ما المدة المناسبة لوثيقة PRD؟
أقصر ما يمكن مع الإجابة على من وماذا ولماذا وكيف ستقيس النتيجة. بالنسبة للنسخة الأولى من تطبيق، تكفي عادةً صفحة إلى ثلاث صفحات. الوثائق الطويلة غالباً لا تُقرأ، وتخفي القرارات القليلة المهمة فيها.
هل أحتاج إلى PRD إذا كنت أبني بأداة ذكاء اصطناعي لتطوير التطبيقات؟
لا تحتاج إلى وثيقة رسمية، لكن PRD قصيرة تجعل أدوات بناء التطبيقات بالذكاء الاصطناعي أكثر موثوقية بكثير. قصص المستخدم وقائمة البيانات في الوثيقة تتحول مباشرة تقريباً إلى برومبتات جيدة، وقسم النطاق يمنعك من طلب كل شيء دفعة واحدة.