الجواب القصير. لا يُسلَّم التطبيق مرة واحدة في النهاية؛ بل يُسلَّم كل أسبوعين، ويسلك كل تسليم الطريق نفسه: دفعة تُكتب قبل الكود بسيناريوهات قبولها؛ اختبارات آلية تُسلَّم مع كل وظيفة وتُعاد مع كل تغيير بواسطة تكامل مستمر على خادم يرفض التسليم قبل أن يراه الزبون؛ بيئة قبول على عنوانها الخاص، نسخة من الإنتاج ببيانات اختبار، يفتحها الزبون على هاتفه من فرنسا؛ عرض وقبول مكتوب نقطة نقطة؛ ثم إطلاق تدريجي دون انقطاع، متجر واحد أو جزء من المستعملين أولاً، مع تراجع بأمر واحد وترحيلات قاعدة قابلة للتراجع. الكود والسكريبتات والبيئات باسم الشركة. أربعة وعشرون تسليماً في السنة، ويعرف الزبون في كل لحظة أين يقف تطبيقه.
هذا الدليل موجّه إلى المؤسس المقيم في فرنسا الذي لا يستطيع أن يكون في مقر المورّد ويريد أن يعرف ما يحق له طلبه، وإلى الشركة في الجزائر التي عاشت التسليم الكبير في نهاية المشروع وأسابيعه الثلاثة من الأعطال، وإلى من يقرأ «اختبارات وقبول» في عرض سعر دون أن يعرف ما يجب أن يحتويه. لا يتناول ما يُكتب قبل المشروع، وهو ما يفعله دليل دفتر الشروط، ولا الآجال الإجمالية الموصوفة في دليل الآجال الحقيقية؛ بل يتناول الآلية التي تجعل التسليم يصل كاملاً، والتسليم الفاشل يكلّف عشر دقائق لا عطلة نهاية أسبوع.
ما تقوله الأرقام
التسليم يُقاس، والمفردات موجودة. يعرّف برنامج البحث DORA من Google Cloud، الذي ينشر منذ عشر سنوات الاستطلاع المرجعي عن تسليم البرمجيات، خمسة مقاييس في دليله: ثلاثة للإنتاجية: مهلة التغيير، «الوقت الذي يستغرقه تغيير من إيداعه في مستودع الكود إلى نشره في الإنتاج»، وتواتر النشر، ووقت التعافي بعد نشر فاشل؛ واثنان لعدم الاستقرار: معدل فشل التغييرات، «نسبة عمليات النشر التي تتطلب تدخلاً فورياً»، ومعدل إعادة النشر، عمليات النشر غير المخططة بسبب حادث في الإنتاج. وما يفرضه ذلك على زبون في الجزائر أو فرنسا: يمكن الحكم على المورّد بهذه الأرقام الخمسة، وعرض السعر الذي لا يتيح قياسها لا يصف منهجية تسليم.
ويقول تقرير DORA 2025، المنشور في 23 سبتمبر 2025 من نحو 5 000 إجابة لمحترفين من العالم كله وأكثر من مائة ساعة مقابلات، شيئين مهمين لسنة 2027: 90 % من المستجيبين يستعملون الذكاء الاصطناعي في العمل، و«على خلاف السنة الماضية، نلاحظ علاقة إيجابية بين تبنّي الذكاء الاصطناعي وإنتاجية التسليم»، لكن «تبنّي الذكاء الاصطناعي ما زال على علاقة سلبية باستقرار التسليم». أي أن أدوات الذكاء الاصطناعي تجعل كوداً أكثر يُكتب أسرع، وهذا الكود ينكسر أكثر في الإنتاج إن لم تواكبه منهجية التسليم؛ وتقرير 2024، وفق الملخصات المنشورة عنه، كان يرى أصلاً حصة الفرق عالية الأداء تتراجع وحصة الفرق ضعيفة الأداء تكبر من سنة إلى أخرى، وهو رقم ننقله من مصدر ثانٍ. وما يفرضه ذلك: في 2027 لم يعد السؤال «كم من الوقت لكتابة الوظيفة» بل «كيف تصل إلى الإنتاج دون كسر ما كان يعمل»، وهذا ما يصفه الدليل.
والباقي جزائري لا يرد في أي تقرير: المؤسس في باريس الذي لن يرى مقر المورّد إلا مرتين في السنة، الموصوف في دليل الإطلاق من فرنسا؛ المورّد الذي ينشر بنسخ الملفات إلى الخادم مساء الخميس؛ القبول «بالنظر» إلى شاشة المطوّر؛ ترحيل القاعدة المنفَّذ في الإنتاج بلا عودة. لا إحصاء لدينا عن هذه الحالات؛ نصادفها في أغلب المشاريع التي نستلمها، وهذا الدليل مكتوب ضدها.
حياة تسليم، في ست لحظات
المنهجية لا توصف بأدواتها بل بما يحدث لدفعة عمل، من السطر المكتوب في الأسبوع 1 إلى هاتف زبون يوم ثلاثاء في ساعات الهدوء.
دفعة الأسبوعين تُكتب قبل أول commit: ما سيُعرض بعد خمسة عشر يوماً، بجمل قابلة للتحقق، ولكل وظيفة سيناريو قبول، من يفعل ماذا وما يجب أن يُرى، يصادق عليه الزبون؛ وهو المبدأ نفسه الذي يطبّقه دليل دفتر الشروط على المشروع كله، مختزَلاً في أسبوعين. التطوير مع الاختبارات يسلّم كل وظيفة باختباراتها الآلية: اختبارات وحدة لقواعد العمل، واختبارات تكامل للواجهات، واختبارات شاملة على الهاتف للمسارات؛ والتغيير الذي يُفشل اختباراً قائماً لا يدخل التسليم، والآلة هي التي تقول ذلك لا الزبون. المراجعة والتكامل: مطوّر ثانٍ يراجع كل تغيير، والتكامل المستمر يبني ويختبر وينشر على بيئة القبول مع كل تغيير، من خادم، لا من حاسوب أحد أبداً.
بيئة القبول نسخة من الإنتاج، على عنوانها الخاص، ببيانات اختبار والموصلات نفسها في وضع التجربة، يفتحها الزبون على هاتفه من فرنسا؛ وما يعمل هناك سيعمل في الإنتاج لأنه البناء نفسه. العرض والقبول هما اللحظة التي تحل محل السفر: ينفّذ الزبون السيناريوهات المكتوبة في الأسبوع 1 على بيئة القبول، مسترشداً بفيديو قصير من المورّد، ويقبل أو يرفض كتابةً نقطة نقطة؛ وما يُرفض يُصحَّح أو ينتقل إلى الدفعة التالية كتابةً. الإطلاق التدريجي يتم دون انقطاع، في ساعات الهدوء، لمتجر واحد أو جزء من المستعملين أولاً، مع من يشرف على الساعة التالية؛ وإن ارتفع خطأ أو بطء فالتراجع أمر واحد، وترحيل القاعدة، المنفَّذ على مرحلتين، يتراجع معه. ويتلقى سجل الإصدارات رقمه وقائمة تغييراته، والدفعة التالية مكتوبة أصلاً.
تسليم تطبيق، في خمس طبقات
خلف اللحظات الست خمس طبقات، والتي تنساها عروض الأسعار هي الرابعة.
المتطلبات والسيناريوهات: الدفعة المكتوبة وسيناريوهات القبول ومعاييره، تُحرَّر قبل الكود؛ وعليها يُقبل التسليم أو يُرفض، وبدونها يكون القبول انطباعاً. الكود والاختبارات: اختبارات وحدة لكل قاعدة عمل، اختبارات تكامل لكل واجهة وكل موصل، اختبارات شاملة على الهاتف لكل مسار، واختبارات إساءة، تلك التي تحاول التسرب بين الزبائن الموصوف في دليل SaaS متعدد المستأجرين أو ضخّ SMS الموصوف في دليل المصادقة. التكامل والبيئات: تكامل مستمر يبني ويختبر كل تغيير على خادم، مستودع باسم الشركة، وثلاث بيئات: القبول وما قبل الإنتاج والإنتاج، لكل منها عنوانها.
الإطلاق هو الطبقة التي تجعل التسليم الفاشل يكلّف عشر دقائق: نشر دون انقطاع، تدريجي، ترحيلات قابلة للتراجع على مرحلتين، إضافة قبل وإزالة بعد، وتراجع بأمر واحد مختبَر في القبول قبل كل نشر؛ وهو أيضاً ما يتيح تحديث مائة زبون دفعة واحدة دون قطع أحد. الإشراف والتغذية الراجعة: الأخطاء والبطء والتنبيهات وملاحظات المستعملين وسجل الإصدارات، ما يقول خلال ساعة إن كان التسليم قد كسر شيئاً، بالعدادات نفسها التي يصفها دليل لوحة القيادة للمسيّر. والأدوات التي تحمل هذه الطبقات هي التي يسمّيها دليل DevOps؛ وهذا الدليل يقول ما يراه الزبون منها.
«التسليم عملية تتكرر أربعاً وعشرين مرة في السنة، لا حدث في نهاية المشروع.»
مثال محسوب
مثال على مدى سنة، بآلية لا تتوقف على الفرضيات: تطبيق تجارة، مؤسس في فرنسا، فريق في الجزائر.
أربعة وعشرون تسليماً في سنة، واحد كل أسبوعين، كلٌّ معروض على بيئة القبول ومقبول من فرنسا قبل النشر؛ وصل أول إصدار صالح في الأسبوع 6 لا الشهر 6، وسافر المؤسس مرتين في السنة بدل ست. تراجعان: بطء في صفحة المخزون بعد ترحيل، سُحب في ثماني دقائق، وقاعدة خصم أُسيء فهمها، سُحبت في ست، ثم أُعيدت كتابتها في الدفعة التالية بسيناريوها المصحَّح؛ وهذه فرضيتنا عن التواتر، تُقاس عندكم، والمهم أن أياً منهما لم يره أكثر من متجر واحد.
أقل من عشر دقائق بين الإشارة والعودة إلى الإصدار السابق، بالترحيل، هي الآلية لا الحظ: الإصدار السابق جاهز دائماً، والترحيل نُفِّذ على مرحلتين واختُبر تراجعه في القبول، وأمر التراجع هو نفسه في كل تسليم. صفر انقطاع مرئي: نشر دون توقف، في ساعات الهدوء، متجر واحد أولاً لساعة، ثم الكل. ما يُظهره المثال: بالتسليم الكبير كانت الدفعات الأربع والعشرون ستصير يوم نشر واحداً، كل السيناريوهات تُقبل في الوقت نفسه، وتراجع مستحيل لأن الإصدار السابق لم يكن ليشترك في شيء مع الجديد. الفرضيات التي تُتحقَّق عندكم: كم سيناريو في الدفعة، كم من الوقت لدى الزبون فعلاً للقبول، وأي ساعة هادئة عند مستعمليكم؛ والأسبوع الأول من المشروع يجيب عنها.
ستة أشياء يتحقق منها الزبون في كل تسليم، من فرنسا
ست تحققات لا تتطلب الوجود في المكان ولا معرفة قراءة الكود، ويستطيع الزبون طلبها في كل تسليم.
سيناريو القبول يمرّ: كل سيناريو كُتب في الأسبوع 1 ينفّذه الزبون بنفسه من البداية إلى النهاية، على بيئة القبول، من هاتفه، بفيديو قصير من المورّد للإرشاد؛ والقبول مكتوب نقطة نقطة، والرفض يسمّي السيناريو الفاشل. الاختبارات الآلية موجودة: تقرير اختبارات التكامل المستمر مرفق بكل تسليم، وعدد الاختبارات يجب ألا ينخفض من تسليم إلى آخر؛ والمورّد الذي لا يستطيع إظهار هذا التقرير لا اختبارات لديه. الكود في مستودعكم: الكود وسكريبتات النشر والتوثيق في مستودع Git باسم الشركة، والتسليم وسم إصدار في هذا المستودع لا ملف مُرسَل؛ وهذه الحماية التي يوصي بها دليل التطبيق العالق عند مطوّر اختفى.
الترحيل يتراجع: يعرض المورّد، والساعة في اليد، تراجع تغيير قاعدة على بيئة القبول دون فقدان بيانات. يعمل على هاتف حقيقي: على هواتف Android من الفئة الأولى، بالعربية والفرنسية، على شبكة مقيَّدة، بلقطة مرفقة؛ وبيئة القبول المفتوحة على هاتف الزبون في فرنسا لا تغني عن هذا الاختبار لأن هاتفه وشبكته ليسا هاتف مستعمليه وشبكتهم، كما يذكّر دليل PWA والتطبيق الأصلي. سجل الإصدارات مُمسَك: لكل تسليم رقم وقائمة تغييرات وتاريخ يقرؤها الزبون؛ وهو ما يتيح القول «منذ 1.14 المخزون خاطئ» والعودة إلى 1.13 عن علم.
ست حالات تكسر التسليم
ست حالات نراها في المشاريع التي نستلمها، وما تفعله المنهجية ضد كل منها.
«يعمل عندي»: يُجرى العرض على حاسوب المطوّر، بقاعدته وملفاته واتصاله؛ وعلى الإنترنت لا يعمل شيء بالطريقة نفسها. العرض والقبول على بيئة القبول التي يبنيها التكامل المستمر فقط، لا على حاسوب أبداً. التسليم الكبير: ستة أشهر من العمل تُسلَّم دفعة واحدة، كل شيء يُقبل في الوقت نفسه وينكسر في الوقت نفسه، ولا تراجع ممكن؛ دفعة كل أسبوعين، معروضة ومنشورة، وأول إصدار صالح في الأسبوع 6. الترحيل الذي لا يتراجع: يُجرى تغيير القاعدة في الإنتاج، يفشل التسليم، ولا عودة دون فقدان بيانات؛ ترحيلات على مرحلتين، إضافة قبل وإزالة بعد، ولكل ترحيل تراجعه المختبَر في القبول.
القبول بلا سيناريوهات: الزبون «يلقي نظرة» ويقول إنه جيد، وبعد ثلاثة أسابيع الوظيفة ليست المنتظرة؛ سيناريوهات تُكتب قبل الكود وتُنفَّذ نقطة نقطة، ورفض مكتوب بالسيناريو الفاشل. مساء الخميس: نشر قبل عطلة نهاية الأسبوع، لا أحد يراقب، ويكتشف الزبائن العطل صباح السبت؛ نشر في ساعات الهدوء، في يوم عمل، مع من يشرف على الساعة التالية، ولا عشية عطلة أبداً ولا في رمضان دون تخطيط. الاختبارات اليدوية فقط: كل وظيفة جديدة تكسر قديمة لم يعد أحد تجريبها؛ اختبارات آلية على كل قواعد العمل تُعاد مع كل تغيير، والآلة ترفض قبل الزبون. للست علاج واحد: التسليم عملية تتكرر أربعاً وعشرين مرة في السنة لا حدث.
«ما يُنشر يجب أن يكون قابلاً للسحب في عشر دقائق بالترحيل؛ وإلا فليس تسليماً بل رهاناً.»
رأيناه في مكان آخر: DORA، وما ينتقل
نصّان علنيان يقولان الجوهر. يعطي دليل مقاييس DORA المفردات: مهلة التغيير، تواتر النشر، وقت التعافي، معدل الفشل، معدل إعادة النشر؛ وما ينتقل هو أن هذه الأرقام الخمسة تُطلب من المورّد كما تُطلب المراجع، وأن فريقاً يسلّم كل أسبوعين منذ سنة يستطيع إعطاءها، بينما فريق يعدّ تسليمه الكبير لا يملك أياً منها. ويقول تقرير 2025 إن الذكاء الاصطناعي يسرّع كتابة الكود ويُضعف التسليم حين لا تواكبه المنهجية؛ وما ينتقل هو أن الاختبارات الآلية والتكامل المستمر والتراجع أهم في 2027 منها في 2024، لأن الكود يصل أسرع ويجب الإمساك به بثبات أكبر.
وما لا ينتقل كما هو: تقيس DORA فرقاً تنشر أحياناً عدة مرات في اليوم لمنتجات عالمية؛ وتطبيق تجارة في الجزائر لا يحتاج إلى النشر عشر مرات في اليوم، بل إلى النشر كل أسبوعين دون كسر، وإلى زبون في فرنسا يستطيع التحقق. وما لا تقوله هذه النصوص: أي ساعة هادئة عند مستعمليكم، كم سيناريو تتسع له الدفعة، ومن لديه عندكم ثلاثة أيام للقبول؛ والأسبوع الأول من المشروع يجيب.
قواعد التسليم الذي يصمد
ست قواعد تُكتب في الأسبوع الأول وتُعاد قراءتها مع كل تسليم. الدفعة تُكتب قبل الكود، بسيناريوهات قبولها المصادَق عليها من الزبون؛ وما لم يُكتب لن يُقبل. كل وظيفة تصل باختباراتها، واختبار فاشل يوقف التسليم، بالآلة، قبل الزبون. القبول لا يتم إلا على بيئة القبول، التي يبنيها التكامل المستمر، لا على حاسوب ولا في الإنتاج أبداً. لا شيء يذهب إلى الإنتاج دون قبول مكتوب، نقطة نقطة، وما يُرفض ينتقل إلى الدفعة التالية كتابةً. كل إطلاق تدريجي وقابل للتراجع: ساعات الهدوء، متجر واحد أولاً، تراجع بأمر واحد، ترحيلات على مرحلتين، لا عشية عطلة أبداً. الكود والسكريبتات والبيئات والحسابات باسم الشركة، والتسليم وسم في مستودعها.
قاعدة سابعة تخص عرض السعر: «اختبارات وقبول» ليست منهجية بل جملة؛ المنهجية تُكتب «دفعة تُعرض كل أسبوعين على بيئة قبول متاحة للزبون؛ اختبارات آلية تُسلَّم مع كل وظيفة بتقريرها؛ قبول مكتوب قبل أي نشر؛ إطلاق تدريجي بتراجع في أقل من خمس عشرة دقيقة بالترحيل، يُعرض في كل تسليم؛ المستودع والبيئات باسم الزبون»، ويُتحقَّق منها من أول تسليم. وعرض السعر الذي يسعّر «القبول» كمرحلة نهائية من ثلاثة أسابيع سعّر التسليم الكبير، بما يكلّفه بعد ذلك، الموصوف في دليل حياة التطبيق.
ستة مشاريع، ما يُسلَّم وما يُقبل
ستة مشاريع نسلّمها كثيراً، ولكل منها ما تحتويه دفعة الأسبوعين وما يقبله الزبون.
- تطبيق الميدان دون اتصال، الموصوف في الدليل المخصص. قبول في وضع الطائرة على هاتف حقيقي: الإدخال، قطع الشبكة، إعادتها، التحقق من أن شيئاً لم يُفقد ولم يتكرر؛ إطلاق متجراً متجراً.
- البوابة أو السوق الإلكترونية. قبول مسارات الطلب والدفع في بيئة التجربة، من فرنسا؛ إطلاق في ساعات الهدوء مع جزء من الزوار أولاً.
- وكيل الذكاء الاصطناعي على WhatsApp، الموصوف في الدليل المخصص. قبول على رقم اختبار بسيناريوهات محادثة مكتوبة، بما فيها التحويل إلى إنسان؛ إطلاق لدفعة من الزبائن أولاً.
- التكامل مع المحاسبة، الموصوف في الدليل المخصص. قبول من المحاسب على قيود اختبار؛ التدفق الأول أسبوعين بالتوازي مع الإدخال قبل إيقافه.
- SaaS متعدد المستأجرين. قبول على مستأجر اختبار، اختبار تسرب بين المستأجرين مرفق بكل تسليم؛ إطلاق على موجات من الزبائن، ترحيلات قابلة للتراجع معروضة.
- لوحة قيادة المسيّر. قبول الأرقام العشرة مقابل أرقام المحاسب على شهر؛ إطلاق دون مسّ الصناديق، مع الإبقاء على تقرير الاثنين حتى القبول.
دفعة الأسبوعين، يوماً بيوم
التقويم تقويم دفعة من أربعة عشر يوماً، تتكرر أربعاً وعشرين مرة في السنة، ثلاثة أيام منها للزبون.
اليوم 0 إلى 1 يكتب الدفعة وسيناريوهات قبولها، يصادق عليها الزبون قبل أول commit؛ وهو اليوم الذي يقرر إن كان القبول سيكون تحققاً أم انطباعاً. الأيام 1 إلى 8 للتطوير، كل وظيفة باختباراتها، والتكامل المستمر يبني ويختبر مع كل تغيير ويحدّث بيئة القبول يومياً، كي يستطيع الزبون النظر قبل النهاية إن شاء. اليوم 8 إلى 9 للمراجعة والتجميد: مراجعة مطوّر ثانٍ، لا وظيفة جديدة بعد اليوم 9، تصحيحات فقط. الأيام 9 إلى 11 للزبون: ثلاثة أيام لتنفيذ السيناريوهات من فرنسا، على هاتفه، والقبول أو الرفض كتابةً نقطة نقطة.
اليوم 11 إلى 12 يصحّح النقاط المرفوضة ويعيد قبولها؛ وما لا يتسع له الأجل ينتقل إلى الدفعة التالية كتابةً ولا يذهب إلى الإنتاج. اليوم 12 إلى 13 هو الإطلاق التدريجي، في ساعات الهدوء، متجر واحد أو جزء أولاً، مع التراجع جاهزاً ومن يشرف. اليوم 13 إلى 14 يشرف على الإصدار ويجمع الملاحظات ويحدّث سجل الإصدارات ويكتب الدفعة التالية. وعلى مدى السنة، هذه الدورة هي ما يحل محل أربع من رحلات المؤسس الست الموصوفة في دليل الإطلاق من فرنسا: والرحلتان المتبقيتان للقاء الزبائن لا لمراقبة المورّد.
ما يُفشل التسليم
المشاريع التي نستلمها فشلت عند التسليم دائماً تقريباً لأحد هذه الأسباب.
- التسليم الكبير. ستة أشهر دون نشر شيء، ثم كل شيء دفعة واحدة؛ ينكسر كل شيء ولا يتراجع شيء.
- العرض على حاسوب المطوّر. ما رآه الزبون لا يوجد في أي مكان آخر.
- لا اختبارات آلية. كل تسليم يكسر وظيفة قديمة؛ ويصير الزبون المختبِر، عن بُعد، بلا سيناريوهات.
- الترحيل الذي لا يتراجع. تغيّرت القاعدة، فشل التسليم، والمخرج الوحيد التصحيح في الإنتاج ليلاً.
- نشر مساء الخميس. لا أحد يراقب، ويكتشف الزبائن العطل يوم السبت.
- المستودع عند المورّد. التسليم ملف مُرسَل؛ ويوم يتوقف المورّد عن الإجابة يضيع الإصدار السابق.
- الزبون الذي لا يملك ثلاثة أيام. يُوقَّع القبول دون إجرائه؛ ويأتي الرفض بعد شهر حين تكون الدفعة التالية قد بُنيت عليه.
أسئلة شائعة
الأسئلة التي نتلقاها من مؤسسين مقيمين في فرنسا ومسيّرين في الجزائر وفرق تستلم مشروعاً.
- أنا في فرنسا. كيف أتحقق من العمل دون سفر؟
- ببيئة القبول، على عنوانها الخاص، التي تفتحونها على هاتفكم، وبالسيناريوهات المكتوبة قبل الكود التي تنفّذونها بأنفسكم كل خمسة عشر يوماً؛ ويكمّلها تقرير الاختبارات والوصول إلى مستودع Git وسجل الإصدارات. ورحلتا السنة للقاء زبائنكم لا لمراقبة المورّد.
- كل أسبوعين، أليس ذلك كثيراً؟
- هو ما يجعل كل تسليم صغيراً، فيُقبل في ثلاثة أيام ويتراجع في عشر دقائق. أما التسليم كل ستة أشهر فكبير، فيستحيل قبوله كاملاً ويستحيل التراجع عنه. ويصمد الإيقاع إن كُتبت الدفعة قبل الكود وكانت الاختبارات آلية.
- ماذا يحدث إن كسر النشر شيئاً؟
- الإصدار السابق جاهز دائماً، وترحيل القاعدة نُفِّذ على مرحلتين واختُبر تراجعه في القبول، والتراجع أمر واحد: أقل من عشر دقائق، ولم ير المشكلة إلا المتجر الأول أو الجزء الأول من المستعملين. ثم تُصحَّح الدفعة ويُعاد قبولها قبل أن تنطلق مجدداً.
- كيف أعرف أن الاختبارات موجودة فعلاً؟
- تقرير اختبارات التكامل المستمر مرفق بكل تسليم، بعدد الاختبارات ونتيجتها، وهذا العدد يجب ألا ينخفض؛ ويستطيع المورّد أيضاً أن يعرض في القبول تغييراً خاطئاً عمداً ترفضه الآلة. والمورّد الذي لا يستطيع إظهار أيٍّ منهما لا اختبارات لديه.
- هل يمكن النشر في رمضان أو قبل عطلة؟
- لا عشية عطلة، وفي رمضان في ساعات الهدوء الحقيقية لمستعمليكم فقط، وهي ليست ساعات بقية السنة؛ والقاعدة أن النشر يتم حين يستطيع أحد الإشراف على الساعة التالية ويكون مستعملوكم قلة.
- ماذا يجب أن يحتوي عرض السعر في هذه النقطة؟
- دفعة تُعرض كل أسبوعين على بيئة قبول متاحة للزبون؛ اختبارات آلية تُسلَّم مع كل وظيفة بتقريرها؛ قبول مكتوب قبل أي نشر؛ إطلاق تدريجي بتراجع معروض؛ المستودع والبيئات باسم شركتكم. وعرض السعر الذي يسعّر القبول كمرحلة نهائية من ثلاثة أسابيع يصف التسليم الكبير.