تهدف هذه المقالة إلى استكشاف ماهية وثيقة متطلبات المنتج (Product Requirements Document – PRD) كأداة رئيسية يستخدمها مديرو المنتجات في عملهم، إذ تُعدّ أحد العناصر الأساسية في عملية تطوير المنتجات، حيث تعكس رؤية واضحة للمنتج وتُوجِّه العمل في المراحل المختلفة للتطوير والتسويق.
ما هي وثيقة متطلبات المنتج PRD؟
تُعدُّ وثيقة متطلبات المنتج ملخصًا مهمًا يُحدّد متطلبات ومواصفات المنتج المقترح بصورة شاملة ومحدّدة للغاية، ويشمل هذا المستند معلومات حول وظائف المنتج، ومتطلبات الأداء، واحتياجات المستخدم، واعتبارات التصميم، والقيود التقنية، والمواعيد الزمنية المتوقعة، وأي متطلبات قانونية أو تنظيمية أخرى.
تعتبر وثيقة متطلبات المنتج مرجعًا مهمًا لجميع أعضاء فريق التطوير، حيث توفر إرشادات واضحة للعملية العامة وتسهم في تحقيق أهداف المنتج بفعالية، كما تعمل الوثيقة كوسيلة للتواصل بين فِرق المنتج والعملاء والشركات المصنعة الخارجية، إذ تعزز الفهم المشترك وتحقق توافق الأفكار والتوقعات.
بصفة عامة، يتطلب إعداد وثيقة متطلبات المنتج دراسة مستفيضة للسوق والعملاء وتحليل البيانات واستشراف المستقبل. يجب أن تكون الوثيقة شاملة ودقيقة ومحددة بشكل كافٍ لتقديم توجيهات واضحة للفريق التقني وللشركاء المعنيين بالمنتج.
أهمية وثيقة متطلبات المنتج PRD
تُواءم هذه الوثيقة بين أعضاء الفريق مع التأكّد من تحرّك الجميع في الاتجاه ذاته وعملهم على إيجاد حل للمشكلة نفسها. تحدّد الوثيقة بوضوح ما الذي يجري بناؤه والغاية التي يُبنى من أجلها وما الذي يجعل حل هذه المشكلة جديرًا بالاهتمام.
تعمل الوثيقة على إعلام بقية الفريق، سواء في التصميم أو الهندسة أو التسويق أو الدعم، بالعمل الذي يجب عليهم القيام به، وتساعد وثائق متطلبات المنتج الجيّدة في شرح أهمية بناء الأشياء، بالإضافة إلى التنازلات (Tradeoffs) الصحيحة التي يجب تقديمها.
تعمل وثيقة متطلبات المنتج كوثيقة مرنة تستمر في التطوّر في أثناء عمل الفريق وإعادة النظر في المشكلة.
يجب تحديث وثيقة متطلبات المنتج عند اتخاذ القرارات أو حصول الفريق على معلومات جديدة.
فيما يلي مثال عن نموذج بسيط لوثيقة متطلبات المنتج.
- يتمثل القسم الأول بالمعلومات الأساسية Background. حيث لابد من تأطير المشكلة وتقديم أيّ معلومات من شأنها المساعدة في فهم المشكلة بشكل أفضل. يمكن لهذا كذلك أن يشمل الجهود السابقة.
- يُمثّل القسم التالي المشكلة Problem. نود هنا أن نصف الفرصة التي تمثلها المشكلة وأهمية إيجاد حلّ لها. ما الفائدة التي سيحصل عليها المستخدم؟
- بعد ذلك في القسم المعني بالهدف Goals سنكون أكثر وضوحًا حول معايير النجاح.
- في القسم المعني بمقاييس النجاح Success Metrics، سنُحدد طريقة قياس هذا الهدف.
- يُعنى القسم التالي بوصف الميزات والنطاق Key Features & Scope. وهو المكان الذي سنحدد فيه متطلبات الوظيفة التي يجب أن يؤديها المنتج. يُعد هذا أهمّ الأقسام ويشكل مرجعًا للتصميم والهندسة.
- أخيرًا، وجدت أنّ تضمين نماذج محاكاة Mocks في مستند متطلبات المنتج أمر مفيد جدًا للتأكد من توافق الجميع حول الأمور التي تجري مناقشتها. تأكد من العمل على هذا مع مسؤول التصميم.
تُعد وثيقة متطلبات المنتج فائقة الأهمية.
سبق لي أن رأيت فِرق العمل وهي تكابد في ظلّ غياب وثائق متطلبات المنتج أو عدم اكتمالها أو تحديثها، ستحاول عندئذ مجموعة كبيرة من الأشخاص الدفع بالمنتج في اتجاهات مختلفة.
يعني هذا في أغلب الأحيان تشتت عمل أفراد الفريق وانحرافهم عن مسار تحقيق الهدف نفسه، ولن يثمر هذا عن نتائج جيدة وسيبدو كشيء من هذا القبيل.
من ناحية أخرى، يمكن لك من خلال كتابة وثيقة متطلبات المنتج تحقيق التوافق بين أفراد الفريق والتأكّد من فهمهم وإدراكهم المشترك وتحليلهم للمشكلة نفسها.
يجب علينا التأكّد كذلك من امتلاك الجميع للأهداف نفسها. عندئذ سيبدأ الفريق في التحرك في الاتجاه نفسه. وسيبدو الأمر أقرب إلى شيء من هذا القبيل.
في أي وقت يعمل فيه الفريق على حلّ مشكلة منتج، يجب أن يكون هناك دائمًا وثيقة لمتطلبات المنتج حتى وإن كانت مصغرة من صفحة واحدة. وكلما كبرت المشكلة وزاد تعقيدها، استغرقت وثيقة متطلبات المنتج وقتًا أطول لتعكس مستوى التعقيد هذا.
تتوفر لدى معظم الشركات نماذج خاصة بها لوثائق متطلبات المنتج تسهل قراءة وفهم وثائق متطلبات المنتجات المحددة وإبداء الملاحظات حولها.
مكونات وثائق متطلبات المنتج PRD Components
بشكل عام، تعمل جميع وثائق متطلبات المنتج على ما يلي:
- تؤطّر المشكلة وتجيب عن سؤال: لماذا نقوم بحل هذه المشكلة؟
- تعمل على تحديد الأهداف، أهداف المستخدم وأهداف العمل، ومقاييس النجاح
- تصف المتطلبات أيضًا. ماذا الذي يفعله المنتج؟
بالإضافة إلى ذلك، هناك أيضًا مكونات أخرى يمكن أن يكون تضمينها مفيدًا في وثائق متطلبات المنتج، مثل:
- الافتراضات Assumptions، الأشياء التي نعتقد أنها صحيحة دون أن نكون متأكدين من صحتها تمامًا
- الخيارات المدروسة Options Considered الأخرى وسبب اعتبارها خيارات غير منطقية، يمكن لهذا أن يكون مفيدًا حقًا عندما يقوم الأفراد ممن ليسوا على دراية بالمنتج بمراجعة وثيقة متطلبات المنتج
- يمكننا كذلك تحديد الأشياء التي تقع خارج نطاق العمل Out of scope. يعني هذا الأشياء التي نُقرر عدم بيعها صراحةً والسبب وراء ذلك.
- وكما ذكرت، يمكن لاستخدام نماذج واجهة المستخدم UI Mocks أن يكون أمرًا مفيدًا أيضًا، حيث يُعد إيصال بعض الأفكار بشكل مرئي بدلًا من نص مكتوب أمرًا أسهل على الأغلب.
- يمكننا أيضًا تضمين المخاطر وتدابير التخفيف منها Risks & Mitigations. سيدور هذا القسم حول الأشياء التي قد تسير بشكل خاطئ وطريقة تفادي هذه الأمور السيئة أو الحد منها.
- أخيرًا، يمكن أيضًا لوثائق متطلبات المنتج أن تتضمن خطة الدعم Support Plan. ما أهم المشاكل التي قد يواجهها المستخدمون وكيف سنساعدهم على حلّها؟
تذكر أنّك كمدير للمنتج، تجيب عما يفعله المنتج. يجب على فرق التصميم والهندسة معرفة الطريقة التي يؤدي بها المنتج الغاية منه.
سيختلف التنسيق الدقيق لوثيقة متطلبات المنتج بناءً على الشركة التي نعمل بها. إلّا أنّ وثائق متطلبات المنتج دائمًا ما تؤطر المشكلة وتحدد الأهداف وتشرح الميزات المطلوبة. لنأخذ بالحسبان أهمية أن يكون لكل عنصر في خارطة الطريق وثيقة متطلبات منتج خاصة به.
تمرين: قم بكتابة PRD
تخيل أنك مدير المنتج وتعمل على تطبيق المنبه Alarm Clock App. اكتب PRD للإصدار الأولي.
تعليمات التمرين:
- المشكلة Problem: ضع إطارًا للمشكلة: صِف الفرصة. ما هي الفوائد التي تعود على المستخدم؟ ما هي الأفكار الرئيسية؟ ماذا تفعل المنافسة؟ لماذا هذا مهم؟
- الأهداف Goals: ما هي أهداف المنتج: كيف يبدو النجاح؟ كيف يمكنك قياس النجاح؟
- المميزات الرئيسية Key feature requirements: يجب أن يفعل المنتج؟ كيف يجب إعطاء الأولوية لكل ميزة؟
- أخرى Other: قم بتضمين أي مكونات أخرى تعتقد أنها قد تكون مفيدة
حل التمرين
سأقوم الآن بشرح وثيقة متطلبات المنتج التي كتبتها لتطبيق المنبه.
المشكلة Problem
- تكمن المشكلة في عدم قدرة المستخدمين على الاستيقاظ في الوقت المناسب دائمًا. فهم بحاجة إلى شيء يساعدهم على الاستيقاظ أو تنبيههم عندما يحين وقت الاستيقاظ في الصباح.
- يكمن التحدي الآخر الذي يواجهه المستخدمون في احتمال اختلاف أوقات الاستيقاظ باختلاف أيام الأسبوع.
على سبيل المثال، سيستيقظ العديد من المستخدمين خلال الأسبوع في وقت يختلف عن وقت استيقاظهم خلال عطلة نهاية الأسبوع. بالنسبة لهذا المثال بالتحديد، قررت تركيز المشكلة على تنبيهات الاستيقاظ أيضًا.
على الرغم من وجود العديد من الأوقات الأخرى التي قد يحتاج فيها المستخدمون إلى التنبيهات، سيسمح لنا هذا بالبدء بمجموعة ميزات أكثر تركيزًا ولن يمنعنا هذا من التوسع إلى حالات استخدام أخرى في المستقبل.
الأهداف Goals
١- نريد التأكد من استيقاظ المستخدمين في الوقت المحدد
وسنقيس هذا من خلال عدد المرات التي تنطلق فيها التنبيهات. وتكمن الفرضية هنا في أنّه إذا كان منتجنا لا يحقق أهداف مستخدمينا، فإنهم سيتوقفون عن استخدامه.
من المحتمل أن نتمكن أيضًا من القيام بشيء أكثر روعة، مثل البحث فيما إذا تمّ تحريك الهاتف بعد عدد دقيقة أو دقيقتين أو خمس أو عشر دقائق من الوقت الذي توقف فيه المنبه.
٢- نريد أيضًا أن يتمتع المستخدمون بالقدرة على ضبط منبهات مختلفة بناءً على جدولهم الزمني
وسنقيس هذا من خلال عدد التنبيهات المميزة التي تم إنشاؤها وعدد التعديلات التي أجريت على التنبيهات.
تقول الفرضية أنّ المستخدمين لن يضطروا إلى تعديل التنبيهات الموجودة. بدلًا من ذلك، يمكنهم إنشاء تنبيهات مختلفة بناءً على عوامل مثل أيام الأسبوع.
المميزات الرئيسية Key Features
وفيما يلي بعض الميزات التي أعتقد أنها ستكون الأكثر أهمية must have:
- P0: القدرة على الحصول على تنبيهات بحسب أيام الأسبوع
- P0: ودعم ما لا يقل عن عشرة تنبيهات مختلفة
- P0: والقدرة على إدارة التنبيهات يعني هذا تعديل التنبيهات الموجودة وحذفها
- P0: والتأكد من تشغيل المنبه في الوقت المناسب
- P0: وتوفّر ميزة الغفوة للمنبه النشط والقدرة على إيقافه.
هناك أيضًا بعض الميزات الإضافية التي أعتقد أن وجودها سيكون أمرًا جيدًا nice to have:
- P1: مثل القدرة على تخصيص نغمة التنبيه
- P1: وارتفاع مستوى صوت المنبه تدريجيًا بمرور الوقت
- P1: والقدرة على إنشاء التنبيهات تلقائيًا auto alarms قبل الحدث التالي على تقويم المستخدم بفترة محددة
- P1: والقدرة على تعيين منبه صامت silent alarm يعمل على الاهتزاز فقط.
تضيف الميزات ذات الأولوية P1 قيمة لتجربة المنبه وتعززها.
يحتمل أن تكون التنبيهات التلقائية (Auto Alarms) من الأولويات الأساسية P0 بالغة الأهمية في حال اعتقادنا أنها خاصية تُميّز تطبيق منبهنا عن غيره من التطبيقات المشابهة الأخرى وتوفر قيمة كبيرة لمستخدمي التطبيق. يُمثل هذا شيئًا يجب علينا اختباره والبحث فيه بمزيد من التعمّق.
تُعد هذه المتطلبات جميعها متطلبات عامة. عندما نبدأ العمل مع الفريق، يجب التوسع في كلّ من هذه الميزات للحصول على مزيد من التفاصيل حول الوظيفة التي يجب أن تقوم بها، ويبدو هذا المكان جيدًا لبدء النقاش.
الافتراضات Assumptions
لنتحدث قليلًا عن بعض الافتراضات التي قمت بها. بالنسبة إلى هذا المنتج:
- أنا أفترض أنّ هاتف المستخدم سيكون قيد التشغيل
- ما يعني أنّه في حال إطفاء الهاتف أو نفاذ البطارية، فإن التنبيه لن يعمل، ولا مشكلة في ذلك أبدًا.
- لقد افترضت كذلك أنّ التنبيهات ستعتمد على التوقيت المحلي لهاتف المستخدم.
- السبب الذي جعلني أفترض ذلك هو أنّنا لا نريد التعامل مع تغير المنطقة الزمنية، ولذا ذكرت هذا الأمر خارج نطاق العمل.
كيف بدت وثيقة متطلبات المنتج التي كتبتها مقارنة بما كتبتم؟
المصادر:
- دليل شامل من شركة Atlassian “وثائق متطلبات المنتج، تقليص الحجم“
- مقالة “كيفية كتابة وثيقة متطلبات المنتج“
رائع جدًا. استمر 👏