كيف تكتب Brief لمشروع برمجي؟ نموذج عملي يوفر عليك الوقت والمال (2026)

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

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

نقرأ في جاد للتطوير الرقمي (Jad Digital) عشرات الـBriefs سنوياً من عملاء في مصر والسعودية، ونعرف أي الأسطر تنتج تقديراً دقيقاً وأيها تنتج قائمة أسئلة. هذا الدليل مكتوب لصاحب الشركة أو مدير المشروع لا للمبرمج: الأقسام العشرة التي يجب أن يحتويها الـBrief، ونموذج جاهز تنسخه وتملأه، وأمثلة على صياغة واضحة مقابل صياغة غامضة، وما الذي يجب أن تتوقعه من الشركة بعد أن ترسله.

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

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

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

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

لا تحتاج أكثر من هذه العشرة، ولا يصح أن ينقص منها شيء. اكتب كل قسم بلغة عملك أنت، لا بلغة تقنية.

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

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

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

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

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

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

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

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

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

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

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

واذكر لكل تكامل هل هو في اتجاه واحد أم اتجاهين، فالفرق بينهما كبير في العمل والاختبار. كل تكامل بند عمل مستقل له وثائق ومفاتيح واختبارات وحالات فشل. ذكره في الـBrief يمنع أكبر مفاجأة مالية بعد التوقيع.

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

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

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

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

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

انسخ هذه السطور في مستند واملأها بلغتك العادية. صفحتان تكفيان.

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

الفرق بين الصياغتين هو الفرق بين عرض سعر دقيق وعرض تخميني.

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

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

معظم الخلافات بعد التسليم لا تكون حول الميزة الأساسية بل حول ما يحدث حين تسوء الأمور. سطر واحد عن كل حالة من هذه في الـBrief يوفّر أسابيع نقاش لاحقاً. ولست مضطراً لحسمها كلها بنفسك؛ يكفي أن تذكرها حتى تدخل في التقدير ولا تظهر كمفاجأة أثناء الاختبار أو بعد الإطلاق.

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

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

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

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

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

ثم ينتقل النطاق المتفق عليه إلى العقد كملحق. هنا تحديداً يحميك الـBrief: أي طلب لاحق خارج الملحق يُسعَّر كتغيير معلوم لا كخلاف. اطلب أيضاً بنوداً واضحة عن ملكية الكود وقاعدة البيانات وحسابات الاستضافة والنطاق بعد التسليم. معايير اختيار الشريك نفسها مشروحة بالتفصيل في سبعة معايير تُحسم قبل توقيع العقد.

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

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

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

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

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

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

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