قالب وثيقة متطلبات المنتج (PRD) + مثال عملي كامل يمكنك نسخه

قالب وثيقة متطلبات المنتج (PRD) + مثال عملي كامل يمكنك نسخه

آخر تحديث: 28 يوليو 2026.

معظم صفحات قالب وثيقة متطلبات المنتج تعطيك نموذجًا فارغًا وتتركك وحدك. قالب Atlassian أربعة أقسام من التعليمات ملتفة حول جدول مقاييس نجاح فارغ. قالب Product School يحمل عبارة "(with Example)" في العنوان ولا يحتوي على أي مثال فعلي. كتلة الماركداون المكوّنة من 12 قسمًا أدناه هي القالب كاملًا، متاحة مجانًا وبلا نموذج تسجيل بريد إلكتروني، وجاهزة للنسخ مباشرة. يملأ القسم الرابع بعد ذلك كل قسم من تلك الأقسام الاثني عشر بمثال بناء كامل: بوابة فواتير لعميل تقرأ ملفات PDF باستخدام نموذج LLM وتوجّه الحالات المشكوك فيها إلى مراجعة بشرية. انسخ الفارغة. اقرأ المعبأة. اكتب وثيقتك أنت.

أبرز النقاط

• وثيقة PRD تجيب عن ما الذي يجب بناؤه ولماذا؛ أما وثيقة التصميم التقني فتجيب عن كيف.
• الأقسام الاثنا عشر تناسب أي حجم مشروع. وثيقة الصفحة الواحدة هي نفس القالب بعدد أقل من الصفوف.
• يجب تدوين الأهداف المستبعدة كتابةً. وكيل الذكاء الاصطناعي المبرمج لا يستطيع استنتاج حدود النطاق من الإغفال.
• يجب أن تكون معايير القبول قابلة للتحقق آليًا: "p95 under 400ms"، لا أبدًا "سريع".

أي شكل من PRD يناسبك؟

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

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

تطرح فرق Agile هذا السؤال كثيرًا أيضًا، وعادةً بصيغة: هل تصمد وثيقة PRD أمام backlog فعلي؟ الجواب نعم، بشكل وثيقة صفحة واحدة: تحتفظ PRD بالسبب والحدود، وتحتفظ التذاكر بالعمل.

قالب PRD (ماركداون جاهز للنسخ)

إليك القالب كاملًا بصيغة ماركداون، متاح مجانًا وبلا نموذج تسجيل بريد إلكتروني. الصقه في Notion أو Confluence أو Google Docs أو Linear أو Word، أو ادفعه إلى GitHub باسم PRD.md ودعه يُرقَّم بالإصدارات جنبًا إلى جنب مع الكود. يطلب الناس هذا القالب بتسع صيغ مختلفة؛ الماركداون هي الصيغة التي تصمد بعد اللصق في جميعها، وهي الوحيدة التي يقرأها وكيل الذكاء الاصطناعي المبرمج بلا مشاكل.

# PRD: [اسم المنتج أو الميزة]

## 1. الترويسة
- المالك (المنتج):
- قائد الهندسة:
- قائد التصميم:
- الحالة: مسودة | قيد المراجعة | معتمدة | تم الإطلاق
- آخر تحديث:
- سجل التغييرات: التاريخ / الكاتب / ما الذي تغيّر

## 2. بيان المشكلة
فقرة واحدة. من يتضرر، وبأي معدل، وما التكلفة الحالية. بلا لغة حلول.

## 3. الأهداف ومقاييس النجاح
| الهدف | المقياس | خط الأساس | الهدف المستهدف | طريقة القياس | التاريخ |
|---|---|---|---|---|---|

## 4. الأهداف المستبعدة
تُكتب بصياغة إيجابية: "لا تشمل هذه المرحلة X."

## 5. المستخدمون والشخصيات النمطية
من يستخدمها، وما الذي يعرفونه مسبقًا، وعلى أي جهاز، وبأي معدل.

## 6. قصص المستخدم ومعايير القبول
بصفتي [الشخصية النمطية]، أريد [الإجراء]، لكي [النتيجة].
- Given [السياق]، when [الحدث]، then [النتيجة الملحوظة].

## 7. المتطلبات الوظيفية
مرقّمة. متطلب واحد في كل سطر. قابلة للاختبار. بلا جملة تحتوي على "و".

## 8. المتطلبات غير الوظيفية
الأداء / الأمان والعزل بين المستأجرين / موقع البيانات والاحتفاظ بها / إمكانية الوصول / التوافر.

## 9. التبعيات والتكاملات
الأنظمة الخارجية، وواجهات API، وبيانات الاعتماد، ومن يملك صلاحية الوصول، والمهلة الزمنية.

## 10. المعالم والتقسيم إلى مراحل
| المرحلة | النطاق | معايير الإنهاء | التاريخ المستهدف |
|---|---|---|---|

## 11. الأسئلة المفتوحة والمخاطر
| السؤال أو الخطر | المالك | الموعد المطلوب | الأثر إن بقي بلا إجابة |
|---|---|---|---|

## 12. الملحق والروابط
التصاميم، والأبحاث، وملاحظات المنافسين، والتذاكر السابقة، والعقود.

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

ما الذي يجب أن تتضمنه PRD؟ الأقسام الاثنا عشر، والنسخة الضعيفة من كل واحد

يجب أن تتضمن وثيقة متطلبات المنتج بيان مشكلة، وأهدافًا قابلة للقياس، وأهدافًا مستبعدة صريحة، وشخصيات نمطية، وقصص مستخدم مع معايير قبول، ومتطلبات وظيفية وغير وظيفية، وتبعيات، ومعالم، وأسئلة مفتوحة لها مالكون، وسجل تغييرات. كل ما عدا ذلك ملحق. المعيار لكل سطر هو نفسه الذي يطبّقه معيار ISO/IEC/IEEE 29148:2018 على المتطلبات عمومًا: قابل للتحقق، غير غامض، ومفرد.

تفشل معظم وثائق PRD في هذا الاختبار في الأماكن الثلاثة نفسها دائمًا.

قسمان يستحقان اهتمامًا أكبر مما يحصلان عليه عادةً.

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

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

المثال العملي: PRD بوابة فواتير معبّأة بالكامل

إليك مثالًا عمليًا كاملًا، بأقسامه الاثني عشر معبّأة جميعًا. البناء: بوابة فواتير لعميل من قطاع اللوجستيات متوسط الحجم. يرفع العملاء فواتير بصيغة PDF، ويستخرج نموذج LLM بنود الفاتورة، ويكتشف النظام التباينات مقارنة بسجل الطلب، وأي حالة غير مؤكدة تذهب إلى طابور مراجعة بشرية. المكدس التقني: Next.js، وSupabase/Postgres، وخطوة استخراج واحدة بنموذج LLM. انسخه، أو اطبعه، أو صدّره كـ PDF، أيًا كان ما تحتاجه.

# PRD: بوابة فواتير العميل، المرحلة 1

## 1. الترويسة
- المالك (المنتج): مدير العمليات، جهة العميل
- قائد الهندسة: قائد التسليم، Techsy
- قائد التصميم: مصمم المنتج، Techsy
- الحالة: معتمدة للبناء
- آخر تحديث: 2026-07-28
- سجل التغييرات:
  - 2026-07-14 / المنتج / المسودة الأولى
  - 2026-07-21 / الهندسة / إضافة قاعدة عتبة الثقة إلى 6.2
  - 2026-07-28 / المنتج / نقل الكتابة العكسية إلى ERP ضمن الأهداف المستبعدة

## 2. بيان المشكلة
يستلم موظفو العمليات فواتير العملاء كملفات PDF عبر البريد الإلكتروني، ثم
يعيدون إدخالها يدويًا في نظام الطلبات. يتجاوز الحجم 300 invoices a week،
ومتوسط وقت المعالجة نحو 6 minutes لكل فاتورة، وتحمل نحو 4% منها خطأ إدخال
لا يُكتشف إلا عند التسوية الشهرية. كل تصحيح يكلّف جولة معالجة إضافية ومكالمة.

## 3. الأهداف ومقاييس النجاح
| الهدف | المقياس | خط الأساس | الهدف المستهدف | طريقة القياس | التاريخ |
|---|---|---|---|---|---|
| خفض المعالجة اليدوية | متوسط وقت المعالجة | 6 min | under 90 sec | لوحة عمليات، الوسيط الأسبوعي | 2026-11-01 |
| خفض أخطاء الإدخال | الفواتير المصححة عند التسوية | 4% | under 1% | تقرير المالية الشهري | 2026-12-01 |
| ضبط حجم المراجعة | نسبة الحالات المُوجَّهة للمراجعة البشرية | n/a | under 25% | مقاييس طابور البوابة | 2026-11-01 |

## 4. الأهداف المستبعدة
لا تدعم هذه المرحلة الفواتير متعددة العملات، ولا الكتابة العكسية إلى ERP،
ولا إشعارات الدائن الذاتية للعميل، ولا تطبيق جوال. يقتصر الاستخراج على PDF
فقط. الصور الفوتوغرافية للفواتير الورقية والمسح الضوئي بدقة أقل من 200 DPI
تُرفض عند الرفع مع رسالة توضح السبب.

## 5. المستخدمون والشخصيات النمطية
- موظف عمليات (أساسي، 6 أشخاص): يعمل على طابور الاستثناءات طوال اليوم،
  معرفة عميقة بالمجال، سطح مكتب فقط.
- جهة اتصال حسابات العميل (خارجي، ~140 حسابًا): يرفع الفواتير، تحمّل منخفض
  لأي تعقيد في إعداد الحساب.
- مدير مالي (ثانوي): يسحب تقرير نهاية الشهر، يحتاج مسارًا تدقيقيًا لكل فاتورة.

## 6. قصص المستخدم ومعايير القبول
6.1 بصفتي جهة اتصال حسابات العميل، أريد رفع فاتورة بصيغة PDF، لكي لا أضطر
لإرسالها بالبريد والانتظار.
- Given ملف PDF أقل من 20 MB وبدقة 200 DPI أو أعلى، when أرفعه، then تُعيد
  البوابة رقمًا مرجعيًا خلال 5 ثوانٍ وتعرض "قيد المعالجة".

6.2 بصفتي موظف عمليات، أريد حجب عمليات الاستخراج منخفضة الثقة، لكي لا يُعتمَد
شيء خاطئ تلقائيًا.
- Given فاتورة تم تحليلها، when تنخفض ثقة الاستخراج لأي بند عن 0.85، then
  تُوجَّه الفاتورة إلى طابور المراجعة ولا تُعتمَد تلقائيًا أبدًا.

6.3 بصفتي موظف عمليات، أريد رؤية التباين في مكان واحد، لكي أستطيع حله دون
فتح نظام الطلبات.
- Given فاتورة مطابَقة لطلب، when تختلف أي كمية أو سعر وحدة عن سجل الطلب،
  then تعرض البوابة القيمتين جنبًا إلى جنب وتُبرز الفارق.

6.4 بصفتي مديرًا ماليًا، أريد تصفية الفواتير، لكي أستطيع إقفال الشهر.
- Given قائمة الفواتير، when أصفّي حسب المورّد والنطاق الزمني والحالة، then
  تظهر النتائج خلال أقل من 400ms عند p95 وتعرض الحالة الفارغة إجراء "مسح
  عوامل التصفية".

## 7. المتطلبات الوظيفية
1. الرفع يقبل PDF فقط، بحد أقصى 20 MB، ملف واحد لكل عملية إرسال.
2. الاستخراج يُعيد المورّد، ورقم الفاتورة، والتاريخ، والعملة، وبنود السطر
   مع الكمية وسعر الوحدة والإجمالي.
3. كل بند سطر يحمل درجة ثقة بين 0 و1.
4. المطابقة تقارن الفاتورة المستخرجة بالطلب المفتوح عبر PO number.
5. الاستثناءات تدخل طابورًا مرتَّبًا من الأقدم إلى الأحدث، قابل للإسناد
   لموظف واحد.
6. كل تغيير حالة يكتب سجل تدقيق يتضمن actor، وtimestamp، والقيمة السابقة.
7. الفواتير المعتمدة تُصدَّر كدفعة CSV لنظام المالية.

## 8. المتطلبات غير الوظيفية
- الأداء: زمن استجابة قائمة الفواتير عند p95 أقل من 400ms. يكتمل الاستخراج
  خلال 90 seconds من الرفع عند p95.
- الأمان والعزل بين المستأجرين: عزل مفروض على مستوى صفوف قاعدة البيانات
  لكل مستأجر. لا يمكن لعميل قراءة فاتورة عميل آخر أبدًا. يُتحقَّق منه
  باختبار آلي في كل إصدار.
- موقع البيانات والاحتفاظ بها: تُخزَّن المستندات داخل الاتحاد الأوروبي.
  تُحفَظ النسخ الأصلية 7 years، وبيانات الاستخراج 90 days.
- إمكانية الوصول: الطابور قابل للتشغيل بالكامل عبر لوحة المفاتيح، وتباين
  WCAG 2.2 AA.
- التوافر: 99.5% شهريًا، مع دعم خلال ساعات العمل.

## 9. التبعيات والتكاملات
- سجلات الطلبات: نسخة Postgres للقراءة فقط. صلاحية الوصول تخص تقنية
  معلومات العميل، وبيانات الاعتماد مطلوبة بحلول 2026-08-15.
- مزوّد استخراج LLM: يجب توقيع العقد واتفاقية معالجة البيانات قبل بدء البناء.
- إشعارات البريد الإلكتروني: مزوّد المعاملات الحالي، ونطاق المُرسِل مُتحقَّق
  منه من قِبل العميل.

## 10. المعالم والتقسيم إلى مراحل
| المرحلة | النطاق | معايير الإنهاء | التاريخ المستهدف |
|---|---|---|---|
| P1 | الرفع، الاستخراج، توجيه الثقة | 50 real invoices من البداية للنهاية، أقل من 25% في الطابور | 2026-09-19 |
| P2 | مطابقة الطلبات وعرض التباين | التباين مُبرَز بشكل صحيح على 20 seeded cases | 2026-10-10 |
| P3 | سجل التدقيق، تصدير CSV، التقارير | المالية تُقفل شهرًا واحدًا داخل البوابة | 2026-11-01 |

## 11. الأسئلة المفتوحة والمخاطر
| السؤال أو الخطر | المالك | الموعد المطلوب | الأثر إن بقي بلا إجابة |
|---|---|---|---|
| أي PO number هو المعتمَد حين تُظهر الفاتورة رقمين؟ | مدير عمليات العميل | 2026-08-08 | منطق المطابقة معطَّل |
| هل يرسل أكبر 12 عميلًا ملفات PDF ممسوحة أم أصلية؟ | قائد التسليم | 2026-08-08 | قد تكون عتبة الثقة غير صحيحة |
| هل الاحتفاظ لمدة 7 years مؤكَّد مع مستشار العميل القانوني؟ | مدير مالي العميل | 2026-08-22 | تصميم التخزين وتكلفته يتغيران |
| تكلفة الاستخراج لكل فاتورة عند 300/week | قائد التسليم | 2026-09-05 | اقتصاديات الوحدة غير معروفة |

## 12. الملحق والروابط
مجموعة فواتير نموذجية مجهولة الهوية (40 files)، مخطط جدول الطلبات، دراسة
وقت المعالجة الحالية، تدفقات Figma للرفع والطابور، بيان عمل موقَّع.

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

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

القسم 4، الهدف المستبعد. انتقلت الكتابة العكسية إلى ERP إلى الأهداف المستبعدة في 2026-07-28، بعد أن افتُرض وجودها ضمنًا خلال مكالمة مراجعة. تدوينها كهدف مستبعد كلّف سطرًا واحدًا ووفّر نقاش نطاق كامل.

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

القسم 11، المالكون. لكل سؤال مفتوح اسم وتاريخ. هذا العمود هو الفرق بين وثيقة وقائمة مهام لا يملكها أحد.

تخبرك PRD بالـ"ماذا". لا تخبرك بالمدة أو التكلفة، وهو تمرين منفصل: راجع تحديد نطاق البناء لذلك النصف. والهدف المستبعد الذي لم تدوّنه هو ميزة سيبنيها أحدهم لاحقًا.

كيف تكتب PRD يستطيع وكيل ذكاء اصطناعي مبرمج البناء منها فعليًا؟

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

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

2. قسّم العمل حسب حجم كل مرحلة. وثيقة واحدة ضخمة من 40 صفحة تُنتج طلب سحب (pull request) واثقًا ومتضخمًا ونصف صحيح. قسّم PRD إلى مراحل ينهيها الوكيل في تشغيل واحد محدود، ولكل مرحلة معايير إنهاء خاصة بها.

3. اجعل معايير القبول قابلة للتحقق آليًا. "سريع" ليست متطلبًا، إنها مجرد انطباع. أما "p95 under 400ms على مسار قائمة الفواتير" فهو اختبار يستطيع الوكيل كتابته قبل أن يكتب الميزة نفسها.

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

إليك بوابة الفواتير، مقسّمة إلى مرحلة واحدة يستطيع الوكيل تنفيذها في تشغيل واحد.

# مهمة البناء: رفع الفواتير واستخراجها (المرحلة 1 من 3)

## قيود المكدس التقني (لا تستبدلها)
Next.js 15 App Router، TypeScript، Supabase Postgres مع row-level security،
النشر عبر Vercel. لا تُضف أي تبعيات جديدة دون السؤال أولًا.

## الملفات التي يمكنك إنشاؤها أو تعديلها
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## لا تلمس
- lib/auth/*  (المصادقة تُشحن في المرحلة 2؛ لا تُضف تدفقات تسجيل الدخول الآن)
- أي شيء تحت app/(marketing)/
- مخطط الطلبات الحالي. اقرأه. لا تُرحّله أبدًا.

## معايير القبول (اكتبها كاختبارات أولًا)
1. POST /api/invoices يرفض الملفات غير PDF برمز 415 والملفات التي تتجاوز
   20 MB برمز 413.
2. بند سطر بثقة أقل من 0.85 يضبط invoice.status = 'review'،
   ولا يضبطه أبدًا على 'approved'.
3. كل عملية إدراج تكتب صف تدقيق يتضمن actor_id وaction وcreated_at.
4. GET /api/invoices?vendor=&from=&to=&status= يُعيد النتائج خلال أقل من
   400ms على 10,000-row seed.

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

ثلاثة أشياء تغيّرت مقارنة بالنسخة الموجَّهة للبشر: ظهرت مسارات الملفات، وظهرت قائمة "لا تلمس"، وتحوّلت معايير القبول من جمل إلى تأكيدات قابلة للاختبار. الوكيل الذي تسلّمها إليه أقل أهمية مما يعتقد الناس، مع أن مقارنة وكلاء البرمجة تستحق القراءة قبل أن تلتزم بواحد. احتفظ بالمتطلبات وقواعد المشروع في ملفات منفصلة: قواعد Cursor وCLAUDE.md تحمل الأعراف والأدوات، وPRD تحمل ما يجب بناؤه. وإذا أردت مساعدة الذكاء الاصطناعي في إنتاج النطاق نفسه بدلًا من مجرد استهلاكه، فتلك سير عمل مختلف. أما بالنسبة لخطوة الاستخراج نفسها، فاختيار النموذج وحلقة التقييم هما عمل تكامل ذكاء اصطناعي قائم بذاته.

ما الذي يتغيّر حين تُسلَّم PRD إلى فريق خارجي

حين تُسلَّم PRD إلى وكالة أو متعاقد خارجي، تتوقف عن كونها وثيقة توافق وتصبح لغة تعاقدية. الغموض الذي يحلّه فريق داخلي بمحادثة مدتها دقيقتان يتحوّل إلى طلب تغيير له سعر. وجد تقرير Pulse of the Profession الصادر عن PMI أن 47% من المشاريع الفاشلة تفوّت أهدافها بسبب إدارة غير دقيقة للمتطلبات. وهذا هو السبب الكامل لوجود هذه الوثيقة أصلًا.

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

السطر الذي شاهدناه يفشل أكثر من مرة هو نسخة ما من عبارة "يمكن للمستخدمين تصدير بياناتهم". لا أحد يدوّن الصيغة. النسخة المكلفة من ذلك، بالنسبة لنا، شُحنت كتصدير CSV بينما كان العميل يقصد حزمة فواتير PDF منسَّقة تحمل علامته التجارية، وإعادة العمل استهلكت نحو أسبوع هندسي لم يخطط له أحد. القراءة الصادقة أن الخلل كان في الوثيقة، لا في التسليم. معيار قبول واحد كان سيكتشف المشكلة خلال خمس دقائق: given طلب تصدير، when يُنشَأ الملف، then يكون بصيغة PDF مطابقة للتخطيط المُزوَّد. وسطر أهداف مستبعدة كان سيكتشفها أيضًا من الاتجاه الآخر. لذا أصبحت هذه الآن قاعدة في مرحلة الاستكشاف لدينا: أي متطلب معلَّق على اسم مثل "تصدير" أو "تقرير" أو "إشعار" يحصل على صيغة، ومحفّز، ومثال عملي مرفق قبل توقيع بيان العمل.

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

ماذا يقول مجتمع r/ProductManagement فعليًا عن قوالب PRD؟

ابحث عن product requirements document template reddit وستجد الشكوى نفسها تتكرر في r/ProductManagement: تضخم القوالب. وثائق PRD لا يقرأها أحد. أقسام مُعبَّأة فقط لأن القالب يحتوي على عنوان لها، لا لأن أحدًا احتاج إلى محتواها. وثائق تتقادم في اليوم التالي لانطلاق المشروع وتُستبدَل بصمت بمحادثة Slack. هذا نقد منصف لمعظم القوالب، بما فيها عدة قوالب من أفضل عشر نتائج لهذا البحث.

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

الأسئلة الشائعة

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

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

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

ابدأ ببيان المشكلة وامتنع عن استخدام لغة الحلول فيه. أضف أهدافًا قابلة للقياس بخط أساس وتاريخ مستهدف، ثم اكتب الأهداف المستبعدة. عبّئ الشخصيات النمطية، وقصص المستخدم بمعايير قبول بصيغة Given/When/Then، والمتطلبات الوظيفية وغير الوظيفية، والتبعيات، والمعالم، والأسئلة المفتوحة مع مالكيها.

ما الذي يجب أن تتضمنه PRD؟

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

كم يجب أن يكون طول PRD؟

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

هل PRD هي نفسها BRD؟

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

هل ما تزال فرق Agile تكتب وثائق PRD؟

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

هل يمكن كتابة PRD بصيغة ماركداون؟

الماركداون هي أفضل صيغة لها. تُلصَق بشكل نظيف في Notion وConfluence وGoogle Docs وLinear، وتُرقَّم بالإصدارات في Git بجانب الكود باسم PRD.md، وتظهر الفروقات بشكل صحيح في طلب السحب، وهي الصيغة الوحيدة التي يقرأها وكيل الذكاء الاصطناعي المبرمج دون أن يفقد البنية. القالب أعلاه بصيغة ماركداون لهذه الأسباب بالذات.

كيف تكتب PRD لوكيل ذكاء اصطناعي مبرمج؟

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

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

وثيقة PRD تجيب عن الـ"ماذا" والـ"لماذا": المشكلة، والمستخدمون، والسلوك، ومعايير القبول، والأهداف المستبعدة. أما وثيقة التصميم التقني فتجيب عن الـ"كيف": البنية المعمارية، ونموذج البيانات، وعقود API، والمفاضلات التي أُخذت بعين الاعتبار. المنتج عادةً يملك الأولى، والهندسة تملك الثانية، ويجب أن تُقرَأ وثيقة التصميم كردّ على PRD.

من يملك PRD: المنتج، أم الهندسة، أم العميل؟

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

في الختام

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

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