كيف تكتب وثيقة متطلبات لمشروعك الرقمي قبل أن تطلب عرض سعر

شراء تقني

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

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

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

لماذا تتباعد العروض إلى هذا الحد؟

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

الملاحظة نفسها موثّقة في السياق الحكومي السعودي. فـ«الدليل الاسترشادي لإعداد كراسات الشروط والمواصفات الخاصة بالمشاريع الرقمية»، الصادر عن هيئة الحكومة الرقمية بالتعاون مع هيئة كفاءة الإنفاق والمشروعات الحكومية، ينبّه إلى أن اختلاف فهم المواصفات الفنية بين المورّدين قد يؤدي إلى اختلافات في الأسعار والمخرجات، وأن توضيح تلك المواصفات يتيح مشاركة عدد أكبر من المورّدين في المنافسة.[1] الدليل موجّه إلى الجهات الحكومية، لكن الآلية التي يصفها تستحق النظر في أي عملية شراء تقني.

لهذا فإن السؤال «كم تكلفة تطبيق كهذا؟» يصعب أن يُجاب بدقة قبل تثبيت النطاق. وإذا كنت في مرحلة تقدير الميزانية، فمراجعة العوامل التي تحدد سعر تطوير التطبيق تعطيك صورة عن البنود التي تحرّك الرقم فعليًا.

ما وثيقة المتطلبات؟

هي ليست وصفًا لكيفية البناء. لا تحدد لغة برمجة ولا بنية قاعدة بيانات إلا إذا كان ذلك قيدًا حقيقيًا لديك (كأن يفرض فريقك الداخلي تقنية معيّنة لأنه سيتولى الصيانة لاحقًا). ترك مساحة القرار الهندسي للمورّد جزء من قيمة ما تشتريه.

تتداخل عدة مسميات في هذا المجال، والخلط بينها يربك الطرفين:

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

ما الذي يجعل المتطلب «جيدًا»؟

هذه ليست مسألة ذوق. المعيار الدولي ISO/IEC/IEEE 29148 الخاص بهندسة المتطلبات يعرّف بنية المتطلب الجيد وخصائصه وسماته عبر دورة حياة النظام.[2] ويحدد إصدار 2018 منه تسع خصائص للمتطلب الواحد:[3]

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

إعادة صياغة: من جملة عامة إلى بند قابل للقياس

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

هيكل الوثيقة: ١٢ بندًا تغطي أغلب المشاريع

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

الجزء المنسي: المتطلبات غير الوظيفية

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

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

«خارج النطاق»: أقصر قسم وأكثره فائدة

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

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

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

قائمة تحقق قبل إرسال الوثيقة

الاختبار الأخير هو الأهم. اعطِ الوثيقة لزميل بعيد عن المشروع واطلب منه وصف المنتج بكلماته. الفجوة بين وصفه وما في ذهنك هي بالضبط الفجوة التي سيسعّرها المورّدون.

كيف تقارن العروض بعد وصولها؟

وثيقة جيدة تُنتج عروضًا قابلة للمقارنة، بشرط أن تطلب ذلك صراحة:

1. اطلب تسعيرًا مبنيًا على بنود الوثيقة نفسها، بترقيمها ذاته. الرقم الإجمالي وحده لا يخبرك أين ذهبت الميزانية.
2. اقرأ قسم الافتراضات والاستثناءات في كل عرض قبل السعر. هناك يظهر ما فهمه المورّد فعلًا، وما استبعده بهدوء.
3. عامل أسئلة المورّد كمؤشر جودة. من يسأل عن حالات الفشل وحجم البيانات وأدوار المستخدمين قرأ الوثيقة؛ ومن يرسل عرضًا خلال ساعة دون سؤال واحد سعّر افتراضاته لا مشروعك.
4. قارن ما تستلمه، لا ما يُبنى فقط. عرضان بنفس السعر قد يختلفان جذريًا في الملكية والتوثيق وفترة الضمان.

وإذا كنت تقارن نماذج التعاون نفسها — تنفيذ كامل مقابل فريق مدمج مقابل تطوير جزئي — فمقال الفرق بين شركة تطوير واستوديو هندسة منتجات يوضح ما تشتريه فعليًا في كل نموذج.

أسئلة متكررة