كيفية كتابة PRD يمكن للمطورين الشحن منه

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

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

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

هذا هو التنسيق الذي نستخدمه فيسافيخلال لدينامرحلة الاكتشاف و PRD. لقد قمنا بشحن منتجات معقدة من هذه المستندات، بما في ذلكفينادو آي، منصة وكيلة تحول المطالبات النصية إلى تطبيقات ويب عاملة، وتخدم الآن 50000 مستخدم.

الأقسام السبعة التي تحتاجها PRD

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

1. بيان المشكلة

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

• من لديه هذه المشكلة؟قم بتسمية الشخصية. يعد "مديرو العمليات في شركات الخدمات اللوجستية الذين لديهم 50-200 سائق" مفيدًا. "المستخدمين" ليست كذلك.
• كم هو مؤلم؟تحديد التكلفة. الوقت الضائع، المال المفقود، الأخطاء التي تم إنشاؤها. "يقضي المرسلون 3 ساعات يوميًا في تعيين المسارات يدويًا" وهي مشكلة تستحق الحل. "يمكن تحسين تخصيص المسار" لا يخبر المهندسين بأي شيء.
• ماذا يفعلون الآن؟وصف الحل البديل الحالي. يقوم الأشخاص بحل هذه المشكلة اليوم، حتى لو كان حلهم بطيئًا أو يدويًا أو عرضة للخطأ. إن فهم الحل البديل يخبر المهندسين كيف يبدو "جيد بما فيه الكفاية" وأين يقع الشريط.

بيان المشكلة هو الأساس. إذا فهم المهندسون المشكلة جيدًا، فسوف يقومون بمقايضات تصميمية أفضل دون تصعيد القرارات. إذا لم يفعلوا ذلك، توقع رسالة Slack لكل غموض في المواصفات.

2. مقاييس النجاح

حدد شكل "تم" بأرقام محددة. من المستحيل قياس الأهداف الغامضة مثل "تحسين تجربة المستخدم" ومن المستحيل البناء عليها. قارن بين هذين:

• غامض:"اجعل عملية الانضمام أسرع"
• محدد:"تقليل مدة إعداد المستخدم الجديد من 3 أيام إلى ساعتين عن طريق إلغاء خطوة استيراد البيانات يدويًا"

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

3. قصص المستخدم مجمعة حسب الشخصية

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

مثال محدد لحجز سيارة أجرة SaaS:

• راكب:"بصفتي أحد الركاب، أريد الحصول على تقدير للسعر قبل الحجز حتى أتمكن من مقارنة الأسعار."
• السائق:"بصفتي سائقًا، أريد رؤية موقع الالتقاء على الخريطة حتى أتمكن من التنقل دون الاتصال بالراكب."
• المشغل:"باعتباري مشغل أسطول، أريد رؤية جميع الرحلات النشطة في عرض واحد حتى أتمكن من إعادة تعيين السائقين عندما يقوم شخص ما بإلغاء الرحلة."

ثلاثة أشخاص مختلفين، وثلاثة احتياجات مختلفة، وثلاث واجهات مختلفة. يمنع التجميع حسب الشخصية الخطأ الشائع المتمثل في بناء شاشة واحدة تحاول خدمة الثلاثة جميعًا ولا تخدم أيًا منهم بشكل جيد.

4. حدود النطاق (ما لا تقوم ببنائه)

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

اكتب الاستثناءات الصريحة:

• "لا يوجد تطبيق جوال في الإصدار الأول. الويب فقط مع تصميم سريع الاستجابة."
• "لا يوجد دعم متعدد اللغات حتى المرحلة الثانية."
• "المدفوعات التي تتم معالجتها عن طريق إعادة توجيه Stripe Checkout؛ لا يوجد تدفق دفع مخصص."
• "لوحة الإدارة داخلية فقط، ولا يوجد تصنيف أبيض للمستأجرين."

يمنع كل استبعاد محادثة كانت ستحدث في منتصف السباق عندما يقول شخص ما "انتظر، اعتقدت أننا كنا نبني ذلك أيضًا". ضع القرارات الصعبة في المستند مقدمًا، وليس في الموقف بعد ثلاثة أسابيع من الآن.

5. القيود الفنية

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

• التكامل:"يجب سحب بيانات المخزون من نظام SAP الحالي الخاص بالعميل عبر RFC." يحتاج المهندسون إلى معرفة تبعيات الطرف الثالث قبل تصميم طبقة البيانات.
• أداء:"يجب تحميل لوحة المعلومات في أقل من ثانيتين مع 10000 صف من البيانات." يؤدي هذا القيد إلى اتخاذ القرارات المتعلقة بالتخزين المؤقت والتقسيم إلى صفحات وما إذا كان سيتم تجميع البيانات مسبقًا أم لا.
• امتثال:"يجب تشفير جميع بيانات المريض أثناء وقت الراحة وأثناء النقل. ويتطلب الامتثال لقانون HIPAA." هذه الجملة الواحدة تغير نهج البنية التحتية بأكمله.
• مكان إقامة البيانات:"يجب أن تظل بيانات المستخدم داخل مراكز بيانات الاتحاد الأوروبي." يؤدي هذا إلى استبعاد بعض موفري الخدمات السحابية والمناطق.

تحمي القيود الفنية الهندسة من بناء شيء يعمل في مرحلة التشغيل ويفشل في الإنتاج لأنه لم يذكر أحد تكامل SAP حتى الأسبوع السادس.

6. الإطارات السلكية أو تدفقات المستخدم

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

قم بتضمين الحد الأدنى:

• المسار السعيد لكل شخصية (التدفق المتوقع عندما لا يحدث أي خطأ)
• حالات الخطأ وحالات الحافة (ماذا يحدث عند فشل الدفع، عند فقدان البيانات، عندما يفقد المستخدم الاتصال)
• نقطة الدخول (كيف يواجه المستخدم هذه الميزة لأول مرة؟)

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

7. المعالم ومعايير القبول

قم بتقسيم المشروع إلى مراحل رئيسية تتراوح مدتها من 2 إلى 4 أسابيع. يقدم كل معلم زيادة عمل يمكن لأصحاب المصلحة رؤيتها واختبارها. لكل حدث رئيسي، اكتب معايير القبول الثنائية: النجاح أو الرسوب، إنجاز أو عدم إنجاز.

• الحدث الرئيسي 1 (الأسابيع 1-2):يمكن للمستخدم التسجيل وتسجيل الدخول ورؤية لوحة التحكم الفارغة. القبول: يعمل تدفق المصادقة مع البريد الإلكتروني/كلمة المرور وGoogle OAuth. يتم عرض لوحة المعلومات مع رسائل الحالة الصفرية.
• الحدث الرئيسي 2 (الأسابيع 3-4):يمكن للمستخدم إنشاء وتحرير المشاريع. القبول: تعمل عمليات CRUD. يقوم التحقق من صحة النموذج بالتقاط الحقول الفارغة والأسماء المكررة. تستمر البيانات عبر الجلسات.
• الحدث الرئيسي 3 (الأسابيع 5-6):يمكن للمستخدم دعوة أعضاء الفريق وتعيين الأدوار. القبول: يتم إرسال الدعوة بالبريد الإلكتروني خلال 30 ثانية. يمكن للمستخدم المدعو قبول المشروع والوصول إليه بالأذونات الصحيحة.

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

الأخطاء الشائعة التي تكسر PRD

كتابة 40 صفحة لا أحد يقرأها

إذا كان ملف PRD الخاص بك أطول من 10 صفحات، فسيقوم المهندسون بإزالته. سوف يقرأون القسم الأول، وينتقلون إلى الجزء المتعلق بسباقهم السريع، ويفتقدون السياق الذي يربط عملهم بأهداف المنتج. يتفوق المستند الموجز الذي يتم قراءته على المستند الشامل الموجود في Google Drive. استهدف من 5 إلى 10 صفحات تحتوي على روابط للمواد التكميلية (الإطارات السلكية، وبيانات البحث، والتحليل التنافسي) للأشخاص الذين يريدون العمق.

تحديد تفاصيل التنفيذ

يجب أن يصف PRD ما يفعله المنتج ولماذا. لا ينبغي أن يحدد أن الواجهة الخلفية تستخدم PostgreSQL بمخطط محدد، أو أن الواجهة الأمامية تستخدم React with Redux. تلك هي القرارات الهندسية التي تخص الفريق الهندسي. عندما يحدد مدير المنتج تفاصيل التنفيذ، يحدث أمران: يشعر المهندسون بالإدارة الدقيقة، ويتم تقييد المنتج في القرارات الفنية المتخذة دون سياق تقني كامل. حدد القيد ("يجب التعامل مع 10000 مستخدم متزامن") واترك للمهندسين اختيار الأدوات.

لا حدود للنطاق

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

سرد الميزات دون توضيح السبب

"يجب أن يحتوي النظام على مركز إعلام." لماذا؟ من يتم إخطاره؟ عن ما؟ ما مدى إلحاح هذه الإخطارات؟ هل يحتاج المستخدم إلى التصرف بناءً عليها أم أنها معلوماتية؟ الميزة التي لا تحتوي على "لماذا" يتم تصميمها وفقًا لتفسير المهندس، والتي قد لا تتوافق مع احتياجات المستخدم. ربط الميزات بقصص المستخدم ومقاييس النجاح. إذا لم يتم تعيين الميزة إلى قصة مستخدم، فتساءل عما إذا كانت تنتمي إلى هذه المرحلة.

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

انسخ هذا القالب واملأه لمشروعك التالي. يتضمن كل قسم مطالبات لتوجيه كتابتك.

كيف يستخدم سافي أجهزة PRD في مرحلة الاكتشاف و PRD

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

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

إليك ما تغطيه عملية الاكتشاف وPRD الخاصة بنا:

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

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

كتابة PRD هو القرار الهندسي الأول

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

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

إن تقرير PRD المكون من خمس صفحات والذي يجيب على الأسئلة الصحيحة سوف يتفوق على تقرير PRD المكون من أربعين صفحة والذي يجيب على الأسئلة الخاطئة.

الأسئلة المتداولة