كيف أحول عبارة أريد تطبيقاً إلى نطاق عمل قابل للتسعير والتنفيذ؟
«أريد تطبيقاً مثل التطبيق الفلاني» بداية محادثة مفيدة، لكنها ليست نطاق عمل. الصورة المرجعية تخبرني عن شكل ظاهر، ولا تخبرني عن من يملك البيانات، أو ماذا يحدث عند الفشل، أو كيف يقبل صاحب المشروع التسليم.
النطاق الجيد لا يحول الفكرة إلى وثيقة ضخمة. يحولها إلى قرارات قابلة للاختبار ويترك المجهول ظاهراً بدلاً من إخفائه داخل سعر سريع.
ابدأ بالنتيجة، لا بالشاشات
بدلاً من «نريد شاشة طلبات»، اكتب:
يستطيع العميل إرسال طلب مكتمل، ويستطيع الموظف المسؤول مراجعته وتغيير حالته، ويستطيع المدير معرفة الطلبات المتأخرة دون الرجوع إلى WhatsApp أو Excel.
هذه النتيجة تكشف ثلاثة مستخدمين ومساراً وبيانات وقياساً أولياً.
الخطوة 1: سمّ المستخدمين الحقيقيين
لا تستخدم كلمة «المستخدم» للجميع. اكتب أدواراً مثل:
- عميل جديد.
- عميل لديه طلب قائم.
- موظف تشغيل.
- مدير فرع.
- مدير نظام.
- خدمة خارجية ترسل أو تستقبل بيانات.
ثم اسأل لكل دور: ماذا يرى؟ ماذا يغير؟ ما الذي يجب أن يرفضه النظام؟
الخطوة 2: اكتب المهمة الأساسية كقصة قابلة للملاحظة
استخدم هذا القالب:
عندما [تحدث حالة]
يريد [دور محدد]
أن [ينفذ مهمة]
حتى [تحدث نتيجة]
ونعرف نجاحها عندما [دليل قابل للملاحظة]مثال:
عندما يصل طلب صيانة جديد
يريد مشرف الورشة
إسناده إلى فني متاح مع المركبة والموعد
حتى يبدأ العمل دون اتصال جانبي
ونعرف نجاحه عندما يظهر الإسناد للفني ويسجل وقت البدايةالخطوة 3: ارسم الحالات لا الصفحات
قد يكون الطلب:
مسودة > مرسل > قيد المراجعة > مقبول > قيد التنفيذ > مكتمل
\> مرفوض مع سببلكل انتقال، حدد:
- من يستطيع تنفيذه؟
- ما البيانات المطلوبة؟
- ما الإشعار الناتج؟
- هل يمكن التراجع؟
- ماذا يسجل التدقيق؟
هنا تظهر صعوبة المشروع أكثر من تصميم بطاقة جميلة.
الخطوة 4: حدد البيانات ومصدر الحقيقة
اكتب كل كيان رئيسي: عميل، طلب، منتج، فرع، دفعة، مستند. ثم أجب:
- من ينشئه؟
- ما الحقول الإلزامية؟
- أين يعيش الآن؟
- هل يتكرر بين الأنظمة؟
- من يحق له تغييره؟
- ما مدة الاحتفاظ؟
إذا كانت البيانات في Excel، لا تكتب «استيراد Excel» فقط. أرفق عينة منزوعة الأسرار واحصر الاختلافات والتكرار.
الخطوة 5: افصل النسخة الأولى عن قائمة الأمنيات
أستخدم ثلاث طبقات:
| الطبقة | معناها |
|---|---|
| ضروري للإطلاق | لا تعمل المهمة الأساسية بدونه |
| يثبت التشغيل | نضيفه بعد اختبار المسار الحقيقي |
| توسع لاحق | لا نحتاجه لإثبات القيمة الأولى |
هذه ليست حيلة لتصغير المشروع فقط. هي طريقة لمعرفة هل الفكرة تحل المشكلة قبل توسيع التكلفة.
الخطوة 6: اكتب الحالات غير السعيدة
أضف أسئلة مثل:
- ماذا لو انقطع الاتصال بعد الضغط على إرسال؟
- ماذا لو تكرر الطلب؟
- ماذا لو انتهت الجلسة؟
- ماذا لو حُذف سجل مرتبط؟
- ماذا لو فشل الإشعار وبقيت العملية ناجحة؟
- ماذا لو وصل ملف أكبر من الحد؟
المنتج الحقيقي يعيش في هذه الحالات، لا في العرض التجريبي فقط.
الخطوة 7: عرف القبول قبل التقدير
معيار القبول الجيد يمكن لشخص آخر اختباره:
Given: موظف فرع الدوحة ومسودة طلب تخص فرعه
When: يكمل الحقول الإلزامية ويرسل الطلب
Then: تتغير الحالة إلى مرسل، ويظهر الوقت والمنفذ في السجل
And: لا يستطيع موظف فرع آخر فتح الطلبلا تحتاج كتابة كل سيناريو بهذه الصيغة، لكن تحتاج هذا المستوى من الوضوح للوظائف الحرجة.
الخطوة 8: قدر المخاطر لا الوقت فقط
التقدير يتأثر بـ:
- معرفة الفريق بالمجال.
- جودة البيانات.
- جاهزية API الخارجي.
- عدد الأدوار والحالات.
- اعتماد المتاجر أو الدفع أو مزود خارجي.
- توفر أصحاب القرار للاختبار.
افصل العمل المعروف عن البحث أو التكامل غير المثبت. يمكن تنفيذ مرحلة اكتشاف قصيرة بدلاً من وضع هامش عشوائي داخل السعر كله.
ما الذي أسلمه قبل بدء البناء؟
لنطاق متوسط، أريد حزمة صغيرة:
- النتيجة والمستخدمون.
- المهمة الأساسية والحالات.
- نموذج البيانات الأولي.
- الصلاحيات.
- التكاملات والافتراضات.
- النسخة الأولى وما هو خارجها.
- معايير القبول.
- خطة المراحل والتسليم.
اختر هذا الأسلوب عندما
- الفكرة ما زالت واسعة.
- توجد عدة أقسام أو أصحاب قرار.
- السعر والموعد يحتاجان التزاماً.
- يوجد نظام قديم أو API أو متجر خارجي.
لا تحول الاكتشاف إلى بيروقراطية
إذا كان المطلوب صفحة بسيطة أو إصلاحاً محدوداً، يكفي نطاق قصير. مستوى التوثيق يجب أن يناسب تكلفة الخطأ والتنسيق، لا أن يثبت أن الفريق يكتب وثائق كثيرة.
الخلاصة
تحويل الفكرة إلى نطاق يعني إزالة الغموض من المستخدم والمهمة والحالة والبيانات والقبول. عندها يصبح التقدير نتيجة للفهم، لا رقماً مبنياً على عدد الشاشات.
إذا كان المشروع نظام أعمال، ابدأ بـقائمة جاهزية Odoo أو قائمة التدقيق التقني للموقع حسب طبيعة الحل، ثم أرسل الفجوات التي بقيت بلا إجابة.