انتقل إلى المحتوى
Nodary
ابدأ مجانًا

قالب وثيقة متطلبات المنتج (PRD)

ست وثائق مترابطة تأخذ ميزة من المشكلة إلى الإطلاق: لمن هي، وما الذي يجب أن تفعله، وكيف يسير مسارها، وكيف تعرف أنها نجحت، وكل قرار على الطريق. نزّلها ملفات Markdown: تفتح في أي محرر، وتعرض مخططها على GitHub وفي Obsidian، وتُستورد إلى Nodary على شكل خريطة.

نزّل القالبافتح العرض التجريبي

6 ملفات Markdown في ملف .zip، 9 كيلوبايت

مجاني، بلا حساب وبلا بريد إلكتروني. استخدمه وعدّله وشاركه.

وثيقة متطلبات المنتجالمستخدمون والأدلةالمتطلباتالتصميم والمساراتالإطلاق والمؤشراتالقرارات والأسئلة المفتوحة

اقرأ كل صفحة قبل التنزيل

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

المستندات

الملف قالب PRD/وثيقة متطلبات المنتج.md

وثيقة متطلبات المنتج

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

باختصار

الحقلهذه الميزة
الميزة[الاسم]
في جملة[ما يستطيع المستخدم فعله بعد صدورها]
مالك المنتج[الاسم]
القائد التقني[الاسم]
قائد التصميم[الاسم]
الحالة[مسودة، قيد المراجعة، معتمدة، صادرة]
الإصدار المستهدف[التاريخ أو الإصدار]

المشكلة

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

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

[المشكلة في جملتين أو ثلاث]

الأهداف وغير الأهداف

الأهداف تقول ما الذي يتغير للمستخدم، لا ما يبنيه الفريق. وغير الأهداف هي القرارات التي تمنع النطاق من الاتساع بصمت.

  • هدف: [ما يستطيع المستخدم فعله، أو ما لم يعد مضطرًا لفعله]
  • هدف: [...]
  • غير هدف: [ما يتركه هذا الإصدار عمدًا]
  • غير هدف: [...]

النجاح في سطر

المؤشر الواحد الذي يخبرك، بعد شهر من الإطلاق، إن كان الأمر قد نجح. القائمة الكاملة في الإطلاق والمؤشرات.

[المؤشر] ينتقل من [القيمة الأساسية] إلى [الهدف] بحلول [التاريخ].

بقية الوثيقة

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

هذا القالب حر الاستخدام والتعديل والمشاركة. وهو من Nodary، حيث تُستورد هذه الملفات خريطةً من المستندات المترابطة.

نزّل القالب6 ملفات Markdown في ملف .zip، 9 كيلوبايت

كيف تستخدمه

  1. اكتب المشكلة قبل الحل

    املأ أولًا المشكلة والأهداف وغير الأهداف في النظرة العامة مع المهندس والمصممة اللذين سيبنيان الميزة. إن لم تتفقوا ثلاثتكم على المشكلة، فتوقفوا عندها.

  2. اجعل كل متطلب إلزامي قابلًا للاختبار

    أعطِ كل متطلب إلزامي معايير قبول يستطيع شخص آخر التحقق منها. المتطلب الذي لا يستطيع أحد اختباره مجرد أمنية.

  3. اطلب المراجعة ثم أبقِه صحيحًا

    اطلب مراجعة حين تجهز المتطلبات، وحدّث الوثيقة حين يغيّرها قرار. وثيقة توقفت عند الانطلاق تصبح خاطئة يوم الإطلاق.

  4. سجّل ما تغيّر ولماذا

    يدخل كل قرار سجل القرارات مع اسم من اتخذه. وحين يسأل أحد لماذا تعمل الميزة هكذا، يكون الجواب على بُعد رابط واحد.

استورده إلى Nodary خريطةً

Nodary مساحة عمل مبنية للذكاء الاصطناعي، تترابط فيها مستندات الفريق بدل أن تتكدس. استورد ملف .zip فتصل الوثيقة وأجزاؤها الخمسة تحتها، وتبقى الروابط بين الصفحات، ويُرسم المخطط. اجعلها قيد المراجعة واطلب اعتمادها من مالك مساحة العمل أو المشروع أو من أحد مسؤوليهما، وشاهد ما تغيّر منذ زيارتك الأخيرة، ودع وكلاء الذكاء الاصطناعي المتصلين عبر MCP يقرؤون المتطلبات قبل أن يكتبوا الشيفرة.

  1. افتح خريطة مشروع واختر «استيراد».
  2. اختر تبويب «مجلد أو ZIP»، ثم «اختيار ملف ZIP».
  3. حدّد الملف الذي نزّلته، وتحقق من الشجرة، ثم استورد.

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

Nodary لفرق المنتج والتطوير
عرض لوحة مباشر في Nodary يجمع المستندات حسب الحالة (مسودة، قيد المراجعة، منجز، معطّل)، وعلى كل بطاقة المسؤول والموعد النهائي؛ والمشروع النموذجي المعروض لعبة.

كتابة وثيقة متطلبات يستخدمها الفريق فعلًا

تفشل وثيقة المتطلبات بطريقتين: تصف حلًا لم يسائله أحد، أو يتوقف تحديثها بعد الانطلاق. هذه العادات تمنع الاثنتين.

ابدأ من المشكلة

اكتب من يعاني المشكلة وكم تكلّفه قبل أي حل. الفرق المتفقة على المشكلة تتجادل أقل حول الشاشات.

قل ما لن تفعله

غير الأهداف قرارات أيضًا. وكتابتها هي ما يمنع الميزة من أن تكبر أسبوعًا بعد أسبوع.

اجعل المتطلبات قابلة للاختبار

«سريع» و«سهل» لا يمكن التحقق منهما. أما «يتوقف الرابط عن الفتح خلال دقيقة من تاريخ انتهائه» فيمكن بناؤه واختباره.

رتّب الأولويات: إلزامي، مهم، اختياري

يصدر الإصدار حين يتحقق كل متطلب إلزامي. أما المهم والاختياري فهما ما تتنازل عنه حين يقترب الموعد.

اربط الأدلة

كل قول عن المستخدمين يربط بالمقابلة أو التذكرة أو البيانات التي يستند إليها، كي يتحقق المراجع منه بدل أن يصدّقه.

أبقِها حية

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

أسئلة عن وثيقة متطلبات المنتج

ما وثيقة متطلبات المنتج (PRD)؟

وثيقة متطلبات المنتج (product requirements document أو PRD) تصف ميزة أو منتجًا قبل بنائه: المشكلة التي يحلها، ولمن هو، وما يجب أن يفعله، وكيف يُقاس النجاح، وما يقع خارج النطاق. يتولاها عادة مدير منتج، ويقرؤها المهندسون والمصممون والدعم، وعلى نحو متزايد وكلاء البرمجة بالذكاء الاصطناعي.

ماذا يجب أن تتضمن؟

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

كم يجب أن يكون طولها؟

بالقدر الذي يكفي الفريق ليبني الميزة ويختبرها دون أن يسألك السؤال نفسه مرتين. يجب أن تتسع النظرة العامة لشاشة واحدة؛ وتنمو المتطلبات مع القرارات لا مع الأفكار.

ما الفرق بينها وبين وثيقة التصميم التقني؟

وثيقة المتطلبات تقول ما يجب أن تفعله الميزة ولماذا. ووثيقة التصميم التقني تقول كيف سيفعله النظام: البنية والبيانات والواجهات والمخاطر. اكتب وثيقة المتطلبات أولًا، ثم اربط بينهما.

هل يستطيع وكلاء الذكاء الاصطناعي استخدامها؟

نعم. وثيقة متطلبات مكوّنة من مستندات مترابطة تعطي الوكيل السياق الذي يحتاجه. وفي Nodary يقرأ الوكلاء المتصلون عبر MCP، مثل Claude أو ChatGPT أو Cursor، المتطلبات وسجل القرارات بصلاحياتك قبل أن يكتبوا.

هل أستطيع استخدام القالب خارج Nodary؟

نعم. الملفات بصيغة Markdown عادية: يفتح Obsidian المجلد بعد فك ضغطه خزنةً تعمل كل روابطها، ويعرض GitHub الملفات مع مخططها. والأدوات التي تستورد Markdown ملفًا ملفًا تحتفظ بالنص والجداول؛ تحقّق من طريقة تعاملها مع الروابط بين الملفات.

اقرأ أيضًا

أبقِ المتطلبات حيث يعمل الفريق.

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

ابدأ مجانًاافتح العرض التجريبينزّل القالب