نموذج متطلبات تطبيق جوال: قالب تملؤه قبل طلب العروض

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

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

القسم 1: الهدف ومقياس النجاح

القسم 2: المستخدمون والأدوار

القسم 3: الرحلات الأساسية

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

القسم 4: المزايا بأولوياتها

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

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

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

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

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

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

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