معظم الشركات تبيعك رؤية في الاجتماع. عرض تقديمي أنيق، مراجع مبهرة، كل الكلمات الصحيحة عن الأجايل والتصميم المتمحور حول المستخدم.
ثم توقّع. وصمت.
تمر أسابيع. ترسل بريدًا إلكترونيًا للمتابعة. تحصل على تحديث مبهم. في النهاية، ترى عرضًا توضيحيًا لا يتطابق مع ما ناقشتموه. في تلك المرحلة، تكون قد دفعت 40% وتتساءل ماذا حدث.
نسمع هذه القصة من كل عميل تقريبًا يأتي إلينا بعد تجربة فاشلة. المشكلة نادرًا ما تكون تقنية. إنها العملية. الشركة لم يكن لديها واحدة — أو لم تلتزم بتلك التي وعدت بها.
هذا المقال هو الإجابة التي نقدمها لكل عميل محتمل يسأل: «ماذا يحدث فعليًا بعد التوقيع؟»
المرحلة الأولى: الانطلاق وتثبيت النطاق
قبل أن نكتب سطرًا واحدًا من الكود، نثبّت النطاق. ليس بعرض مبهم — بوثيقة يوافق عليها الطرفان.
جلسة الانطلاق ليست دردشة عابرة. إنها جلسة عمل منظمة نحوّل فيها موجز العميل إلى شيء قابل للبناء. إذا لم تكتب موجزًا بعد، نشرنا دليلًا عن كيفية كتابة موجز يساعد فعلًا. هذا يعني قصص مستخدم بمعايير قبول، قائمة ميزات مرتبة حسب الأولوية، و— بنفس الأهمية — قسم صريح «خارج النطاق».
هذا الجزء الأخير أهم مما يعتقد الناس. زحف النطاق لا يبدأ بطلبات كبيرة. يبدأ بافتراضات. «ظننت أن لوحة البيانات ستشمل أيضًا التصدير.» «اعتقدت أن النسخة المحمولة مشمولة.» إذا لم يكن مكتوبًا ومتفقًا عليه، فهو غير موجود.
نقول لا مبكرًا حتى لا نضطر لقول «هذا سيكلف أكثر» لاحقًا. العملاء يقدّرون هذا أكثر مما يتوقعون.
المخرج من هذه المرحلة: وثيقة متطلبات محددة النطاق مع الأولويات والجداول الزمنية والحدود. العميل يوافق عليها قبل أن نتقدم.
المرحلة الثانية: التصميم والتحقق
نصمم قبل أن نبني. يبدو هذا بديهيًا، لكن ستتفاجأ بعدد المشاريع التي تقفز مباشرة من الموجز إلى الكود.
عمليتنا: إطارات سلكية أولًا، ثم تصميم واجهة المستخدم. العميل يرى ويوافق على التدفق — كل شاشة، كل تفاعل — قبل أن نلمس محرر الكود. هذا ليس عن الجماليات. إنه عن اكتشاف سوء التفاهم مبكرًا، حين يكلف ساعات لإصلاحه بدلًا من أسابيع.
«الموافقة» هنا لها معنى محدد. تعني أن العميل راجع كل شاشة، وأكد أن التدفق يتطابق مع توقعاته، ووقّع. ليس إعجابًا على سلاك. تأكيد موثق يقول «نعم، ابنوا هذا.»
هذه المرحلة تقضي على أكبر خطر في مشاريع البرمجيات: بناء الشيء الصحيح بالطريقة الخاطئة، أو الشيء الخاطئ بالطريقة الصحيحة.
المرحلة الثالثة: البناء في سبرنتات، عرض كل أسبوعين
نعمل بدورات مدتها أسبوعان. في نهاية كل دورة، يحصل العميل على عرض حي لما تم بناؤه — برنامج يعمل، وليس شرائح.
هذا غير قابل للتفاوض عندنا. لا نختفي أبدًا لمدة شهر ونعود بمفاجأة. كل أسبوعين، يرى العميل التقدم، يعطي ملاحظاته، ويؤكد أننا على المسار الصحيح.
ماذا يحدث عندما يريد العميل تغيير شيء أثناء السبرنت؟ يحدث في كل مشروع، وهذا طبيعي — بشرط أن يُدار. نقيّم التغيير: هل يتسع له السبرنت الحالي؟ هل يحل محل شيء آخر؟ هل يؤخر الجدول الزمني؟ نقدم المقايضة للعميل، يقرر، ونوثق. لا دراما، لا تكاليف مخفية. كيف ندير الجانب المالي يعتمد على نموذج التسعير — كتبنا مقالًا منفصلًا يشرح كيف يتعامل كل نموذج مع تغييرات النطاق بشكل مختلف.
الإيقاع مهم. دورات الأسبوعين تخلق المسؤولية من الطرفين. نحن نسلّم بانتظام، والعميل يبقى منخرطًا. المشاريع التي تغرق — حين يختفي العميل لمدة شهر ثم يعود بأولويات جديدة — هي التي تفشل. بنية السبرنتات تمنع ذلك.
المرحلة الرابعة: الاختبار والتسليم والإطلاق
قبل أن يصل أي شيء للإنتاج، يمر عبر ضمان الجودة. نختبر على بيئة تجريبية — نسخة مطابقة لبيئة الإنتاج — حيث يمكن للعميل أيضًا الاختبار والإبلاغ عن المشكلات.
النشر ليس حدثًا مرهقًا لنا. نستخدم خطوط نشر آلية. من التجريب إلى الإنتاج هي عملية محكومة، وليست دعاء.
ما يتسلمه العميل ليس مجرد وصول لتطبيق يعمل. إنه حزمة: الكود المصدري الكامل في مستودع Git، توثيق تقني يغطي المعمارية والإعداد والقرارات الرئيسية، بيانات الإدارة وتكوين البيئة، وجلسة تدريبية حتى يتمكن فريق العميل من استخدام وإدارة ما بنيناه فعليًا.
«منتهي» يعني أن العميل يستطيع تشغيل البرنامج بدوننا. إذا احتاجنا للتطوير المستقبلي، ممتاز. لكنه لن يكون محبوسًا أبدًا. الكود ملكه، التوثيق واضح، وأي مطور كفء يمكنه استلام المشروع. ما يأتي بعد ذلك — الاستضافة، التحديثات الأمنية، التطوير المستمر — محادثة منفصلة نجريها قبل الإطلاق، وليس بعده. كتبنا عن ما تتضمنه صيانة ما بعد الإطلاق فعليًا وكم تكلف.
ما لا نفعله
هذه ليست انتقادات للصناعة. إنها التزامات نقدمها لكل عميل:
لا نبدأ بدون نطاق موقّع. لا نتخطى مرحلة التصميم. لا نختفي بين العروض التوضيحية. لا نسلّم كودًا غير موثق. لا نحتجز الكود رهينة. لا نقول «كان مشمولًا» عندما لم يكن مكتوبًا.
كل نقطة من هذه تأتي من نمط رأيناه في مشاريع فاشلة جلبها عملاء إلينا للإنقاذ. بنينا عمليتنا خصيصًا لتجنبها.
ماذا يعني هذا بالنسبة لك
إذا مررت بتجربة برمجية فاشلة من قبل، فمعظم ما وصفته سيبدو بديهيًا. هذا هو المقصود. التسليم الجيد ليس سحرًا — إنه انضباط يُطبق باستمرار.
إذا كان هذا مشروعك البرمجي المخصص الأول، استخدم هذا المقال كقائمة مراجعة. اسأل شركتك: كيف تبدو عملية التسليم لديكم؟ إذا كانت الإجابة غامضة، فهذا يخبرك بشيء. جمعنا القائمة الكاملة للأسئلة التي يجب طرحها قبل التوقيع.
كتبنا سابقًا عن لماذا نبني كل شيء بـ Laravel — اختيارنا التقني هو جزء من قدرتنا على التسليم بشكل موثوق. غطينا أيضًا كم تستغرق المشاريع فعليًا ومتى يكون البناء المخصص هو القرار الصحيح. لكن المجموعة التقنية مجرد أداة. العملية هي ما يصنع أو يكسر المشروع.
لديك مشروع في ذهنك — أو مشروع يحتاج إنقاذًا؟ لنتحدث →