نطاق العمل في مشروع التطبيق: كيف تكتبه حتى لا يُفسَّر بطريقتين
أغلب خلافات مشاريع التطبيقات تبدأ بجملة في نطاق العمل قرأها كل طرف بطريقته. هذا نموذج لمدير المنتج والمشتريات وصاحب المشروع يحدد ما يدخل وما لا يدخل، بعبارات لها حدود، ومثال كامل لجدول داخل النطاق وخارجه.
نطاق عمل مشروع تطبيق لا يُفسَّر بطريقتين حين يجيب عن خمسة أشياء كتابةً: ما المخرجات التي تستلمها بصيغتها، وما المزايا بمستوى تفصيل يمنع التأويل (ما تشمله كل ميزة وحدودها)، وما هو خارج النطاق صراحة، وما الافتراضات التي بُني عليها السعر، وما الذي يعتمد على العميل ومتى. العبارات العامة مثل «تصميم احترافي» أو «ربط مع بوابة الدفع» تُستبدل بحدود قابلة للعدّ والتحقق. والاختبار البسيط قبل التوقيع: أعط النص لشخصين تقنيين منفصلين؛ إن فهما منه مشروعين مختلفين، فالنطاق لم يُكتب بعد.
أغلب الخلافات في مشاريع التطبيقات لا تبدأ بسوء نية، بل بجملة قرأها كل طرف بطريقته. العميل قرأ «ربط مع بوابة الدفع» فتوقع الدفع والاسترداد والمطابقة اليومية، والشركة قرأت الجملة نفسها فسعّرت شاشة دفع ناجح فقط. بعد ثلاثة أشهر يتحول الفرق إلى طلب تغيير يرفضه العميل، أو عمل مجاني تنفذه الشركة على مضض. هذه المقالة لمدير المنتج والمشتريات وصاحب المشروع: نموذج لنطاق العمل التعاقدي تنسخه، وأمثلة لعبارات غامضة وإعادة صياغتها، وجدول «داخل النطاق وخارجه» لمشروع افتراضي كامل.
ما الذي يفعله نطاق العمل، وبماذا يختلف عن وثيقة المتطلبات؟
نطاق العمل (Scope of Work) مستند تعاقدي يحدد ما يلتزم المزود بتسليمه مقابل السعر، وما لا يلتزم به. وثيقة المتطلبات (SRS) تصف كيف يعمل النظام بتفصيل يكفي للتصميم والبناء والاختبار. الأولى تجيب «ماذا اشترينا؟» والثانية تجيب «كيف يعمل ما اشتريناه؟». في المشاريع الصغيرة قد يجتمعان في مستند واحد، وفي المشاريع الأكبر يحيل النطاق إلى الوثيقة ويجعلها مرجعًا لتفاصيل المزايا.
ما يعنيك عمليًا أن النطاق هو ما يُرجع إليه عند الخلاف، وعند طلب التغيير، وعند القبول. لذلك يكتب بلغة الحدود لا بلغة الطموح. إن لم تكن لديك وثيقة متطلبات بعد، فصفحة تحليل المتطلبات وإعداد وثيقة SRS تشرح ما تتضمنه وثيقة يستطيع أي فريق أن يسعّر عليها ويبني منها، ونموذج متطلبات تطبيق الجوال نقطة بداية أخف تملؤها بنفسك.
- المسودةمن المتطلبات أو الكراسة وعرض المزودالمزود أو مدير المنتج
- قراءة مستقلةشخصان يقرآن النص منفصلين ويسجلان ما فهماهطرف من كل جانب
- جلسة الحدودحسم كل اختلاف في الفهم، وكتابة خارج النطاق والافتراضاتالطرفان معًا
- الاعتماديوقّع مرفقًا للعقد، بترتيب أولوية واضحصاحب القرار
- خط الأساسيُقاس عليه كل تغيير وكل قبولإدارة المشروع
نموذج نطاق عمل مشروع تطبيق: الأقسام الثمانية
انسخ هذه الأقسام بترتيبها. ليس المطلوب أن تطول، بل أن تكون قاطعة:
| القسم | ما يُكتب فيه | سؤال الفحص |
|---|---|---|
| 1. الغرض والمستخدمون | فقرة واحدة: لماذا يُبنى التطبيق، ولمن، والأدوار المشمولة | هل كل دور مذكور له مزايا في القسم 3؟ |
| 2. المخرجات | قائمة بما تستلمه وصيغته: التطبيقات على المتاجر، واللوحة، والكود في مستودعك، والتصاميم المصدرية، والوثائق | هل يمكن التحقق من كل مخرج بالعين أو بالاختبار؟ |
| 3. المزايا وحدودها | لكل ميزة: ما تشمله، وحدودها الكمية، وما لا تشمله، ومرجع معايير قبولها | هل يمكن لشخصين أن يقدّرا الميزة بفرق كبير؟ |
| 4. المتطلبات العامة | المنصات والإصدارات، واللغات، والأجهزة المختبرة، والبيئات، والاستضافة | هل كل رقم محدد أم متروك «للمناسب»؟ |
| 5. خارج النطاق صراحة | قائمة بما قد يُفترض أنه مشمول وليس كذلك | هل ذُكر كل ما سألت عنه ولم يدخل؟ |
| 6. الافتراضات | ما بُني عليه السعر والجدول، وما يحدث إن ثبت خطؤه | هل لكل افتراض أثر مكتوب؟ |
| 7. التزامات العميل | ما تقدمه منشأتك، ومتى، وأثر تأخره | هل لكل التزام موعد أو مرحلة؟ |
| 8. المراحل والقبول والتغيير | المراحل ومخرجاتها، وطريقة القبول، ومسار طلب التغيير | هل يُعرف متى تنتهي كل مرحلة ومن يعتمدها؟ |
القسمان 5 و6 هما ما يغيب غالبًا، وهما ما يحسم الخلافات. أما القسم 8 فيربط النطاق بمعايير القبول ومسار التغيير، وتفصيلهما في مقالتي معايير القبول في مشروع التطبيق وطلبات التغيير وتضخم النطاق.
كم تفصيلًا يكفي لكل ميزة؟ بطاقة الحدود
التفصيل الكافي ليس وصف كل زر، بل تحديد ما يغيّر الجهد إن اختلف فهمه. لكل ميزة أسئلة قليلة تحسم حجمها، والباقي يُترك لوثيقة المتطلبات والتصميم. خذ ميزة «الإشعارات» مثالًا:
- ما تشمله
- إشعارات داخل التطبيق (Push) للعميل عند تأكيد الطلب، وخروجه للتوصيل، وتسليمه، وإلغائه.
- حدودها الكمية
- أربعة أحداث، بقالب نصي لكل حدث باللغتين، يعدّل نصه المشرف من لوحة التحكم.
- ما لا تشمله
- الرسائل النصية وواتساب والبريد، والإشعارات التسويقية المجدولة، وتقسيم المستخدمين إلى شرائح.
- مرجع القبول
- معايير القبول في المرفق، البند الخاص بالإشعارات.
هذه الأسطر الأربعة تمنع خلافًا متوقعًا: العميل الذي يسمع «إشعارات» قد يتخيل حملات تسويقية بشرائح، والمطور قد يسعّر أربعة إشعارات ثابتة. كلا الفهمين معقول، والنص هو ما يختار بينهما. طبّق البطاقة نفسها على كل ميزة يحتمل اسمها أكثر من معنى، واكتفِ بسطر لما لا يحتمل.
عبارات غامضة في نطاق العمل وإعادة صياغتها
هذه عبارات تتكرر في عروض ونطاقات مشاريع التطبيقات، وكل منها يُقرأ بطريقتين على الأقل:
| العبارة الغامضة | ما قد يفهمه العميل | ما قد يسعّره المزود | صياغة أوضح |
|---|---|---|---|
| «تصميم احترافي للواجهات» | هوية بصرية كاملة وجولات تعديل حتى الرضا | واجهات على دليل هوية جاهز، بجولة تعديل واحدة | تصميم واجهات الشاشات الواردة في القائمة، على دليل الهوية الذي يقدمه العميل، مع جولتي تعديل لكل مجموعة شاشات، ونموذج أولي تفاعلي للرحلة الأساسية |
| «ربط مع بوابة الدفع» | الدفع والاسترداد والمطابقة والفواتير | شاشة دفع وإشعار نجاح | الدفع بالبطاقات المدعومة لدى البوابة التي يتعاقد معها العميل، مع الاسترداد الكامل من اللوحة، ومعالجة الدفع المعلق؛ والاسترداد الجزئي والمطابقة الآلية خارج النطاق |
| «نشر التطبيق على المتاجر» | المزود يتولى كل شيء حتى يظهر التطبيق | رفع نسخة واحدة، والحسابات والمحتوى على العميل | رفع الإصدار الأول إلى المتجرين بحسابات العميل، وإعداد صفحة المتجر من محتوى يقدمه العميل، ومعالجة ملاحظات المراجعة المتعلقة بالكود حتى القبول |
| «نقل البيانات من النظام القديم» | كل السجلات التاريخية منظفة ومطابقة | استيراد ملف واحد كما هو | ترحيل العملاء والمنتجات النشطة من ملفات يصدّرها العميل بالصيغة المتفق عليها، مع تقرير بالسجلات المرفوضة؛ والسجلات التاريخية وتنظيف البيانات خارج النطاق |
| «تدريب المستخدمين» | تدريب كل الموظفين في كل الفروع | جلسة واحدة عن بعد | جلستان للمشرفين عن بعد، مع دليل استخدام مكتوب للوحة التحكم وتسجيل للجلستين |
| «تعديلات بسيطة أثناء التطوير» | أي تعديل يطلبه لا يُحسب | تصحيح نصوص وألوان فقط | تعديلات لا تضيف شاشة أو حالة أو قاعدة عمل جديدة؛ وما عداها طلب تغيير يُقدّر ويُعتمد |
| «قابل للتوسع مستقبلًا» | إضافة أي ميزة لاحقًا دون إعادة عمل | عبارة وصفية لا التزام فيها | احذفها من النطاق، واكتب بدلها القرار المعماري المقصود في وثيقة المعمارية |
| «حسب أفضل الممارسات» | معايير أعلى في كل شيء | ما يراه الفريق مناسبًا | اذكر الممارسة نفسها: مراجعة كود لكل تعديل، واختبارات آلية لمنطق الدفع، وبيئة اختبار منفصلة |
لاحظ أن الصياغة الأوضح لا تنحاز لطرف. بعضها يوسّع ما سيُبنى، وبعضها يقلصه ويكتب الباقي خارج النطاق. المهم أن يعرف الطرفان الشيء نفسه قبل التوقيع.
مثال كامل: جدول داخل النطاق وخارجه
مثال افتراضي للتوضيح مطبخ مركزي يقدم وجبات يومية لموظفي الشركات. يريد تطبيقًا يطلب منه موظفو الشركات المتعاقدة وجباتهم، ولوحة يدير منها المطبخ القوائم والطلبات والتوصيل لكل شركة، وحسابًا لمسؤول كل شركة يتابع استهلاك موظفيه. هذا جدول النطاق بعد جلسة الحدود:
| المجال | داخل النطاق | خارج النطاق صراحة |
|---|---|---|
| الأدوار | الموظف، ومسؤول الشركة، ومشرف المطبخ، ومدير النظام | تطبيق مستقل للسائقين (التوصيل يُدار من اللوحة) |
| الطلب | طلب وجبة اليوم التالي حتى موعد إغلاق تحدده كل شركة، وتعديله أو إلغاؤه قبل الإغلاق | الطلب الفوري لنفس اليوم، والطلبات الجماعية للمناسبات |
| القوائم | قائمة أسبوعية لكل شركة، وخيارات الحساسية الغذائية كوسوم تظهر للموظف | حساب السعرات والقيم الغذائية |
| الدفع | لا دفع في التطبيق: الفاتورة شهرية للشركة، وتقرير استهلاك قابل للتصدير | دفع الموظف بنفسه عن وجبات إضافية |
| التكامل | تصدير تقرير الاستهلاك الشهري بصيغة جدول | الربط الآلي مع النظام المحاسبي للمطبخ أو أنظمة الموارد البشرية لدى الشركات |
| الإشعارات | تذكير قبل موعد الإغلاق، وتأكيد الطلب، وخروج الوجبات | الرسائل النصية وواتساب |
| المنصات | iOS وAndroid بقاعدة كود واحدة، ولوحة ويب، باللغتين | تطبيق للأجهزة اللوحية في المطبخ |
| الدخول | رقم الجوال ورمز تحقق، وتفعيل الموظف عبر قائمة ترفعها شركته | الدخول الموحد عبر أنظمة الشركات |
| ما بعد الإطلاق | فترة ضمان للعيوب تبدأ من الإطلاق | التطوير الجديد والدعم بمستوى خدمة، ويُتفق عليهما في عقد مستقل |
عمود «خارج النطاق» ليس قائمة رفض، بل قائمة قرارات مؤجلة. كل سطر فيه سؤال طرحه أحد الطرفين في الجلسة، وحُسم كتابةً. حين يطلب مسؤول شركة بعد الإطلاق «ربطًا مع نظام الرواتب»، لا يحتاج أحد إلى الجدال في ما إذا كان مشمولًا؛ يُفتح طلب تغيير أو يُخطط لإصدار لاحق.
الافتراضات والتزامات العميل: القسمان اللذان يحسمان الخلاف
الافتراض شرط غير معلن بُني عليه السعر. إن لم يُكتب، اكتشفته حين يثبت خطؤه. اكتب كل افتراض مع أثره:
| الافتراض | إن ثبت خطؤه |
|---|---|
| كل شركة لها قائمة أسبوعية واحدة وموعد إغلاق واحد | تعدد القوائم أو المواعيد داخل الشركة يُقدّر طلب تغيير |
| قوائم الموظفين تُرفع من ملف بالصيغة المتفق عليها | التزامن الآلي مع أنظمة الشركات خارج النطاق |
| الاستضافة على حساب سحابي باسم المطبخ يوفره قبل مرحلة البناء | تأخر الحساب يؤخر بيئة الاختبار والجدول بالقدر نفسه |
| النصوص والصور يقدمها العميل جاهزة باللغتين | كتابة المحتوى أو ترجمته خدمة منفصلة |
والتزامات العميل هي الوجه الآخر: ما لا يستطيع المزود التقدم دونه. كتابتها تحميك أنت أيضًا، لأنك تعرف مسبقًا ما عليك ومتى:
- دليل الهوية والشعار قبل مرحلة التصميم.
- حسابات المتاجر والسحابة والنطاق باسم المنشأة قبل مرحلة البناء.
- شخص يعتمد التصاميم ويرد على الأسئلة خلال مهلة متفق عليها.
- بيانات الاختبار والمحتوى الأولي قبل اختبار القبول.
- فريق من طرفك ينفذ حالات اختبار القبول المكتوبة.
هذا يتسق مع طريقة عمل أغلب الفرق المنظمة. في منهجية العمل لدينا مثلًا تنتج مرحلة الاكتشاف والتحليل وثيقة النطاق وقائمة الشاشات، ودورك فيها الإجابة عن الأسئلة واعتماد النطاق، ولا ننتقل إلى التصميم قبل اعتماده. وبند التزامات العميل في العقد نفسه تجده في مقالة بنود عقد تطوير التطبيق.
أخطاء شائعة في كتابة نطاق العمل
- الاعتماد على العرض الفني بدل نطاق مستقل: العرض كُتب ليقنعك، لا ليحدد التزامًا. انقل منه ما يلزم إلى مرفق نطاق يوقّع.
- قائمة مزايا بأسماء فقط: «إشعارات، تقارير، دفع» ثلاث كلمات تحتمل عشرة مشاريع.
- غياب «خارج النطاق»: كل ما لم يُكتب خارج النطاق سيدّعي أحد الطرفين أنه داخله.
- افتراضات بلا أثر: «يفترض توفر واجهات النظام الآخر» دون أن تقول ماذا يحدث إن لم تتوفر.
- أرقام مفتوحة: «جولات تعديل حسب الحاجة» أو «أجهزة متعددة» بدل رقم أو قائمة.
- نطاق يوقّع ثم يُعدّل بالمحادثات: رسالة «نعم أضيفوها» في محادثة لا تعدّل النطاق؛ طلب التغيير المعتمد هو ما يعدّله.
- كتابة النطاق بلغة التقنية وحدها: صاحب القرار الذي سيعتمد القبول يجب أن يفهم كل سطر.
ما تطلبه من شركة التطوير، وما تجهزه قبل أن تطلب العرض
اطلب من الشركة قبل التوقيع:
- مرفق نطاق مستقل بالأقسام الثمانية، لا العرض الفني نفسه.
- بطاقة حدود لكل ميزة يحتمل اسمها أكثر من معنى.
- قائمة صريحة بما هو خارج النطاق، تشمل كل ما سألت عنه ولم يدخل.
- قائمة افتراضات مرقمة، ولكل افتراض أثر إن ثبت خطؤه.
- قائمة بما تحتاجه الشركة منك ومتى.
- ربط كل مرحلة بمخرجاتها ومعايير قبولها.
وجهّز من طرفك قبل طلب العرض:
- الأدوار ورحلة كل دور الأساسية، وحالات الاستثناء التي تعرفها من عملك.
- قائمة المزايا مصنفة: ضروري للإطلاق، ومهم لاحقًا، وفكرة للمستقبل.
- ما تريده خارج النسخة الأولى صراحة، حتى لا يسعّره المزود ولا يعدك به.
- الأنظمة والحسابات التي تملكها اليوم، وما ستوفره ومتى.
- من سيعتمد النطاق، ومن سيقرأه قراءة مستقلة قبل التوقيع.
للجهات التي تطرح المشروع بكراسة، يُكتب النطاق داخل الكراسة ويُطلب من المتقدمين الرد عليه بندًا بندًا، كما في مقالة كيف تكتب طلب عروض لتطوير تطبيق، ويمكن إرسال الكراسة لتصلك أسئلة الاستيضاح قبل العرض. وللمشاريع الخاصة، أرسل ما جهزته عبر طلب عرض سعر لمشروع جديد.
الخلاصة: اكتب الحدود قبل أن تكتب الطموح
نطاق العمل الجيد قصير وقاطع: مخرجات يمكن التحقق منها، ومزايا بحدودها، وخارج نطاق صريح، وافتراضات لها أثر، والتزامات عميل لها مواعيد. اختبره بقراءة مستقلة من شخصين قبل التوقيع، واحسم كل اختلاف في جلسة واحدة، ثم اجعله خط الأساس الذي يُقاس عليه كل تغيير وكل قبول. بهذا لا تمنع التغيير، بل تمنع الجدال حول ما إذا كان تغييرًا أصلًا.
وحين يصلك التقدير، اقرأه على هذا الأساس: هل بُني على نطاق مكتوب بهذه الأقسام، أم على وصف من سطرين؟ التقدير يضيق كلما اتضح النطاق، ثم يتحول إلى عرض بسعر ونطاق مكتوبين، كما توضح صفحة كيف يتم تقدير مشروع التطبيق.
أسئلة شائعة
غالبًا تكتب الشركة المسودة من متطلباتك وعرضها، لأنها تعرف ما سعّرته. لكن اعتماده مسؤوليتك: اقرأه قراءة مستقلة، واطلب إضافة ما هو خارج النطاق والافتراضات إن غابت. وفي المنافسات تكتب الجهة النطاق في الكراسة ويرد عليه المتقدمون.
نطاق العمل مستند تعاقدي يحدد ما يلتزم المزود بتسليمه مقابل السعر وما لا يلتزم به. وثيقة المتطلبات تصف كيف يعمل النظام بتفصيل يكفي للتصميم والبناء والاختبار. في المشاريع الصغيرة قد يجتمعان، وفي الأكبر يحيل النطاق إلى الوثيقة.
لا. اكتب ما يغير الجهد إن اختلف فهمه: ما تشمله كل ميزة، وحدودها الكمية، وما لا تشمله. تفاصيل الشاشات مكانها قائمة الشاشات ووثيقة المتطلبات والتصميم، ويحيل إليها النطاق بوصفها مرفقًا.
لا تفترض أنها مشمولة ولا تتفاوض عليها في محادثة. افتح طلب تغيير مكتوبًا بوصف الحاجة، واطلب تقدير أثرها على السعر والجدول، ثم قرر: تنفذ الآن، أو تؤجل لإصدار لاحق، أو تستبدل بها ميزة أقل أهمية داخل النطاق.
أعطه لشخصين تقنيين منفصلين واطلب من كل منهما أن يكتب ما سيُبنى ويقدر حجمه تقريبًا. إن اختلفا كثيرًا في ميزة، فهي تحتاج بطاقة حدود. واسأل نفسك: هل كل ما سألت عنه ولم يدخل مذكور في خارج النطاق؟
خدمات وصفحات مرتبطة
اقرأ أيضًا
احصل على تقدير مبني على نطاق مكتوب بحدوده
أرسل ما جهزته من أدوار ومزايا وحدود، ونرد بتقدير يذكر الافتراضات وما هو خارج النطاق صراحة، ثم عرض بنطاق وسعر مكتوبين.