وثيقة نطاق النسخة الأولى: كيف تكتب متطلبات تطبيقك وأنت مو مبرمج؟

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

ابدأ بجملة المشكلة، مو بقائمة الميزات

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

اكتب قصص مستخدم بدل الميزات

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

قائمة «ليس الآن» أهم من قائمة الميزات

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

• نظام نقاط وولاء قبل ما يكون عندك عملاء يرجعون.
• لوحة تقارير متقدمة قبل ما يكون عندك بيانات تستاهل التحليل.
• تسجيل دخول بخمس طرق؛ طريقة وحدة تكفي للبداية.
• دعم عدة لغات لو جمهورك الأول يتكلم لغة وحدة.
• محادثة داخل التطبيق لو واتساب يؤدي الغرض مؤقتاً.

ارسم الشاشات على ورقة

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

معايير القبول: متى نقول «خلصت»؟

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

أسئلة لازم تجاوبها قبل ما ترسل الوثيقة

• من يدير المحتوى أو الطلبات بعد الإطلاق؟ أنت أو موظف؟
• هل فيه دفع إلكتروني في النسخة الأولى، أو الدفع يدوي مؤقتاً؟
• تطبيق جوال، أو موقع، أو الاثنين؟ وليش؟
• وش المقياس الوحيد اللي بتحكم فيه على نجاح النسخة الأولى؟

مثال مختصر لوثيقة حقيقية

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

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

لاحظ إن الوثيقة ما تقول «Flutter» ولا «قاعدة بيانات». هذا شغل المنفّذ. شغلك أنت إنك تكون واضحاً في من، ووش، وليش — والمنفّذ الجيد يقترح أبسط طريقة تقنية تحقق ذلك.

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

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

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