الغرض من الوثيقة، وكم ينبغي أن يكون طولها
وُجدت الوثيقة ليستطيع الفريق أن يقدّر العمل، ويبني الشيء الصحيح، ويثبت أنه اكتمل. يقرؤها المصممون والمهندسون ومختبرو الجودة، ثم من يتولى صيانة التطبيق لاحقاً. وكل جملة لا تفيد أحداً منهم لا مكان لها فيها.
الطول يتبع التطبيق. فتطبيق حجوزات بنوع واحد من المستخدمين قد تكفيه ثماني صفحات، أما سوق إلكترونية تجمع العملاء ومقدمي الخدمات وفريق الإدارة فتحتاج إلى أكثر. والوثيقة الواضحة القصيرة خير من وثيقة شاملة لا يقرؤها أحد. وكل ما لست متأكداً منه مكانه قائمة الأسئلة المفتوحة، لا الحذف.
الأقسام التي تتضمنها الوثيقة
| القسم | السؤال الذي يجيب عنه | مثال |
|---|---|---|
| الغرض والنجاح | لماذا يوجد هذا التطبيق، وكيف سنعرف أنه نجح؟ | يحجز المرضى مواعيدهم ويغيّرونها دون الاتصال بالعيادة |
| المستخدمون والأدوار | من يستخدمه، وما الذي يحق لكل دور أن يفعله؟ | المريض، وموظف الاستقبال، ومدير العيادة |
| مهام المستخدم | ما الذي يحتاج كل مستخدم إلى إنجازه؟ | بصفتي مريضاً، أستطيع أن أنقل موعدي إلى وقت آخر متاح |
| الشاشات والمسارات | كيف تترابط المهام من شاشة إلى أخرى؟ | تسجيل الدخول، ثم الرئيسية، ثم اختيار العيادة، ثم اختيار الموعد، ثم التأكيد |
| البيانات والربط | ما المعلومات المحفوظة، وما الأنظمة المعنية؟ | تأتي المواعيد من نظام العيادة، ولا تُحفظ أبداً على الهاتف وحده |
| ظروف الجوال | كيف يتصرف التطبيق على هاتف حقيقي في ظروف حقيقية؟ | يمكن قراءة المواعيد القادمة دون اتصال |
| متطلبات الجودة | ما مستوى السرعة والأمان وإمكانية الوصول المطلوب؟ | تلتزم كل النصوص بحجم الخط الذي اختاره المستخدم في هاتفه |
| الإطلاق والمتاجر | أي المنصات، وأي المتاجر، وأي المناطق؟ | على iOS وعلى Android، في المتاجر العامة، وفي بلدين |
| خارج النطاق | ما الذي نتعمد ألا نبنيه الآن؟ | الدفع ومطالبات التأمين مؤجلة إلى إصدار لاحق |
اكتب المتطلبات في صورة مهام، لكل منها طريقة لاختبارها
أنفع عادة أن تكتب كل متطلب على أنه شيء يفعله المستخدم، ثم تضيف الشروط التي تجعلك تقبله منجزاً. هذه الشروط تُسمّى معايير القبول، وهي تمنع كثيراً من الخلافات التي تظهر عادةً في نهاية المشروع.
متطلب واحد، بثلاث صيغ
متطلب في تطبيق افتراضي لعيادة، يتحسن على خطوتين.
- صيغة مبهمةيستطيع المستخدمون إدارة المواعيد.
- في صورة مهمةبصفتي مريضاً، أستطيع أن أنقل موعداً قادماً إلى وقت آخر متاح في العيادة نفسها.
- مع معايير القبوللا تُعرض إلا الأوقات المتاحة. ويصبح الموعد القديم متاحاً لغيره فوراً. ويرى المريض تأكيداً ويصله إشعار. ولا يُسمح بالتغيير بعد انقضاء المهلة التي تحددها العيادة، ويعرض التطبيق عندها رقم هاتف العيادة. ويظهر التغيير في نظام العيادة.
الصيغة الثالثة يمكن تقدير عملها وتصميمها وبناؤها واختبارها. كما أنها تكشف قرارين على الإدارة أن تتخذهما: قاعدة المهلة، وما يحدث بعد انقضائها.
أعطِ كل متطلب معرّفاً قصيراً مثل BK-04، لتشير إليه التصاميم وحالات الاختبار وطلبات التغيير اللاحقة، فلا يضيع شيء حين تتغير الصياغة.
تفاصيل الجوال التي تغفلها معظم الوثائق
الوثائق التي يكتبها من اعتادوا المواقع الإلكترونية تميل إلى وصف الشاشات ونسيان الهاتف. وكل بند مما يلي يغيّر التصميم والتقدير، فاحسمه قبل أن تطلب عرض سعر.
قائمة التحقق من متطلبات الجوال
0 من 10 منجزةرتّب الأولويات: ضروري، ومهم، ولاحقاً
- 01
صنّف كل متطلب
«ضروري» يعني أن التطبيق لا يمكن إطلاقه دونه. و«مهم» يعني أن له قيمة، ويمكن أن يأتي بعد الإطلاق بقليل. و«لاحقاً» يعني أنه مسجّل حتى لا يغلق التصميم الباب أمامه.
- 02
اختبر كل «ضروري» بسؤال واحد
هل نؤجل الإطلاق من أجله؟ فإن كانت الإجابة الصادقة لا، فهو «مهم» لا «ضروري».
- 03
راجع النسب
إذا كان كل شيء تقريباً «ضرورياً»، فترتيب الأولويات لم يحدث بعد.
- 04
أبقِ قائمة «لاحقاً» ظاهرة
فالمهندسون يتخذون قرارات أفضل في بنية النظام حين يعرفون ما هو قادم.
وإن كانت هذه النسخة الأولى من منتج جديد، فيبيّن دليل تخطيط النسخة الأولى من تطبيق الجوال (MVP) كيف تختصر قائمة «الضروري» إلى ما يثبت صحة الفكرة.
نموذج لوثيقة المتطلبات تستطيع نسخه
وثيقة متطلبات تطبيق الجوال
Template1. الغرض والنجاح
المشكلة التي يحلها التطبيق، ولمن
كيف سنقيس النجاح بعد الإطلاق
2. المستخدمون والأدوار
كل دور، وما يستطيع رؤيته، وما يستطيع فعله
3. مهام المستخدم
المعرّف، والمهمة بصيغة: «بصفتي صاحب هذا الدور، أستطيع أن أفعل كذا»
الأولوية: ضروري، أو مهم، أو لاحقاً
معايير القبول لكل مهمة
4. الشاشات والمسارات
المسارات الرئيسية، في صورة قائمة بالشاشات بترتيبها
حالات الشاشة الفارغة والتحميل والخطأ لكل شاشة
5. البيانات والربط
ما الذي يُحفظ، وأين، وإلى متى
كل نظام يتصل به التطبيق، وما يتبادلانه
6. ظروف الجوال
العمل دون اتصال، والإشعارات، والأذونات، والأجهزة، وإصدارات الأنظمة
طرق تسجيل الدخول واستعادة الحساب
7. متطلبات الجودة
التوقعات في الأداء والأمان والخصوصية وإمكانية الوصول
8. الإطلاق والمتاجر
المنصات، والمتاجر، والدول، واللغات
من يملك حسابات المتاجر
9. خارج النطاق
ما لن يتضمنه هذا الإصدار
10. الأسئلة المفتوحة
القرارات التي لم تُتخذ بعد، ومن سيتخذها
أخطاء شائعة
- وصف الشاشات بالتفصيل دون ذكر ما يحاول المستخدم فعله
- إغفال جانب الإدارة، مع أن أحداً سيضطر إلى بنائه
- كتابة «مثل تطبيق المنافس» على أنها متطلب
- الاكتفاء بالمسار الذي يسير فيه كل شيء كما ينبغي، دون أخطاء أو شاشات فارغة أو حالات رفض
- التعامل مع الوثيقة على أنها مكتملة، بينما يجب أن تتغير كلما تعلمت شيئاً
- خلط القرارات بالأمنيات، فلا يعرف أحد أي السطور متفق عليه
ماذا تفعل الآن
املأ الأقسام من 1 إلى 3 في النموذج أولاً. فهي وحدها تكفي لحديث أول مفيد مع شركة تطوير، ويشرح دليل كيف تختار شركة لتطوير تطبيقات الجوال ما تسأل عنه في هذا الحديث.
وإن أردت مساعدة في تحويل ملاحظاتك إلى وثيقة يبني منها الفريق، فهذا هو الغرض من ورشة استكشاف المنتج. ويمكنك أيضاً أن ترسل إلينا ما لديك، وسنخبرك بما ينقصه قبل أن تطلب عرض سعر من أحد. وتشرح صفحة تطوير تطبيقات الجوال كيف ننتقل بوثيقة كهذه إلى التصميم والبناء.
أسئلة شائعة
ما الفرق بين وثيقة متطلبات المنتج (PRD) ومواصفات متطلبات البرمجيات (SRS)؟
وثيقة متطلبات المنتج تبيّن ما ينبغي أن يقدمه المنتج لمستخدميه ولماذا. أما مواصفات متطلبات البرمجيات فأكثر رسمية، وتضيف متطلبات وظيفية ومتطلبات جودة مفصلة للمهندسين ومختبري الجودة. وفي معظم التطبيقات، تكفي وثيقة واحدة تبدأ بالمستخدمين ومهامهم وتزيد التفصيل حيث تكون المخاطر عالية، فتؤدي المهمتين معاً.
هل أحتاج إلى مخططات هيكلية للشاشات في وثيقة المتطلبات؟
لا. فالرسوم السريعة قد تساعد على شرح مسار ما، ولا بأس بها. أما المخططات الهيكلية المكتملة التي تُرسم قبل الاتفاق على المتطلبات، فتميل إلى تثبيت تخطيط الشاشات في وقت مبكر جداً. اكتب قائمة بالشاشات وما يجب أن تتيحه كل منها، ودع مرحلة التصميم تُنتج المخططات.
ما قدر التفصيل المطلوب في الوثيقة قبل أن أطلب عرض سعر؟
قدر يكفي لأن تصف لك شركتان التطبيق نفسه حين تعيدان شرحه. والحد الأدنى: الأدوار، والمهام الضرورية، والربط مع الأنظمة، وظروف الجوال. وحيث لا تستطيع الحسم بعد، فقل ذلك صراحة. فالشركة الجيدة ستسعّر مرحلة استكشاف تحسم النقاط المفتوحة أولاً.
من ينبغي أن يكتب وثيقة المتطلبات؟
صاحب المنتج، مع من يعرفون العمل اليومي، مثل فرق الدعم أو العمليات أو المبيعات. وينبغي أن يراجعها مهندس أو مصمم بحثاً عن الثغرات. وإن لم يكن لدى أحد في الداخل الوقت الكافي، فمرحلة استكشاف مع فريق خارجي تُنتج الوثيقة نفسها معك.
كيف أتعامل مع المتطلبات التي تتغير أثناء المشروع؟
توقّع التغيير، وحدّد له مساراً. فكل تغيير يُكتب مقابل المتطلب الذي يمسّه، مع أثره في التكلفة والجدول الزمني، ثم يعتمده أو يرفضه شخص يملك الصلاحية. وتُحدَّث الوثيقة حتى تصف دائماً التطبيق كما اتُّفق عليه.
