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

Question

Accepted Answer

**وثيقة متطلبات المنتج (PRD)** توضح *ماذا* ستبني، *ولماذا*، و*كيف ستعرف أنها نجحت* — بحيث يمكن لفريق الهندسة والتصميم بناء الشيء الصحيح دون توضيحات مستمرة. وثيقة PRD جيدة هي أداة تفكير وأداة محاذاة، وليست ورقة بيروقراطية.

## خطوط عريضة قوية لـ PRD

```text
1. PROBLEM / CONTEXT → what problem, for whom, why now
2. GOALS & SUCCESS METRICS → what outcome, how measured
3. NON-GOALS → what this explicitly does NOT cover
4. USER STORIES / REQUIREMENTS → what it must do
5. UX → flows, wireframes, key states
6. EDGE CASES → errors, empty states, limits
7. DEPENDENCIES & RISKS → what could block or break this
8. OPEN QUESTIONS → known unknowns to resolve
```

## ابدأ برسم الصورة الكاملة

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

## الأهداف المستبعدة مقيمة بأقل من قيمتها الحقيقية

وضع النطاق المستبعد بشكل صريح يمنع زحف النطاق و"بينما نحن بصدد ذلك..." الفخ. إنها قيمتها تساوي المتطلبات ذاتها.

## المشاكل الشائعة

```text
✗ Over-specifying the HOW → boxes in engineering's better ideas
✗ No success metric → you can't tell if it worked
✗ Writing it alone → involve eng/design early to catch issues
✗ Treating it as fixed → a PRD is a living doc
```

## لماذا هذا مهم

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

وثيقة واضحة من PRD تكشف تلك الفجوات *قبل* أن يكتب أي شخص كوداً.

كما أنه يجبرك *أنت* على التفكير في المشكلة بعمق.

إذا لم تتمكن من كتابة الهدف والمقياس الناجح بوضوح، فأنت لا تفهم المشكلة بشكل كافٍ لبنائها حتى الآن.