الالتزام بمواعيد التسليم

موعد التسليم عندنا ليس أمنية، بل بند تعاقدي لا يمكن الإخلال به

نرفض ثقافة الغموض السائدة في قطاع البرمجيات.

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

«الغموض» صمت ارتضاه قطاع البرمجيات

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

يمر موعد التسليم بثلاث مراحل

إعطاء موعد وهمي عمل ساعة واحدة. أما إعطاء موعد متحقق منه رياضيًا فعملية هندسية من ثلاث مراحل.

1. التحليل وحساب الهامش الاحتياطي (Buffer)

نبدأ بحصر المتطلبات التقنية للمشروع، وحالة النظام الحالي، والاعتماديات الخارجية (واجهات API للجهات الخارجية، وموافقات المتاجر، والتشريعات). ويُضرب خطر كل بند في احتماله، ويُضاف إلى النتيجة هامش احتياطي (Buffer Time). ويمكنك أن تثق بأي موعد نعطيك إياه، لأن هذا الموعد أصبح الآن «رياضيًا».

2. إدارة دورات العمل (Sprint)

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

3. ضمان الجودة النهائي والتسليم

فور انتهاء آخر دورة عمل، يخضع الكود لفحص الجودة المؤلف من 100 بند. وبعد الوصول بهامش الخطأ إلى الصفر، يُسلَّم المشروع في اليوم والساعة المتعهد بهما. ولا نسلّم عند الساعة 23:59 بل في بداية يوم العمل.

تحديد الموعد مسألة رياضية قبل كل شيء

يعني حساب موعد التسليم رياضيًا وضع ثلاثة أمور جنبًا إلى جنب: (1) نطاق المشروع، محوّلًا إلى رقم ملموس بنقاط القصص (Story Points) أو نقاط الوظائف (Function Points)؛ (2) الأداء السابق للفريق (Velocity)، أي مقدار العمل الذي ينجزه في المتوسط في كل دورة عمل (Sprint)، مقيسًا بالبيانات؛ (3) الهامش الاحتياطي (Buffer Time) المخصص لمناطق الغموض، ويبلغ عادة ما بين 15% و25% من الجدول الزمني الإجمالي. وعندما تلتقي هذه الأرقام الثلاثة، فإن الموعد الذي نحصل عليه ليس موعدًا نقول فيه «يمكننا ذلك»، بل موعدًا نقول فيه «سننفذه، رياضيًا». وعندما ينظر مهندسان خبيران منفصلان إلى المشروع نفسه، يعطيان الموعد نفسه أو موعدًا قريبًا جدًا منه، لأن الحساب مفتوح للجميع ومتطابق.

الأرقام هي الخلاصة المقتضبة الحقيقية للالتزامات. والمقاييس التي جمعناها من مشاريعنا السابقة هي الدليل الميداني على انضباطنا في الجداول الزمنية.

97%

التسليم في الموعد

خلال آخر 24 شهرًا

0

عدد الأعذار

التعويض مدفوع دائمًا

8 سنوات

الانضباط نفسه

لم يتغير قط

في عالمنا، عبارة «لم نلحق بالموعد» ليست جوابًا، بل اعتراف

بند التعويض في العقد ليس وسيلة ردع، بل قاعدة تلقائية.

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

ثلاثة تدابير تمنع المخاطر من التحول إلى مفاجآت

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

الوقت الاحتياطي (Buffer Time)

يُحسب كل جدول زمني مع تخصيص هامش إضافي للمناطق غير المؤكدة خارج النطاق. وفي المشروع المعتاد، يذهب 15-25% من إجمالي الجدول الزمني إلى هذا الوقت الاحتياطي. وبهذا الاحتياطي يتحول «غير المتوقع» إلى «متوقع رياضيًا».

خطة الفريق الاحتياطي

خلف كل دور حساس يقف متخصص بديل. فمرض مهندس الواجهة الخلفية (Backend) ليس سببًا لاهتزاز الجدول الزمني، بل هو إشارة لتولي اسم آخر المهمة في اليوم نفسه. والمشروع المعتمد على شخص واحد لا يُعد في نظرنا آمنًا من الفشل (Fail-Safe).

سجل المخاطر ومضاعف الاحتمال

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

بند «التعويض عن التأخير» في عقدنا: قاعدة تسري تلقائيًا

إذا لم نلتزم بالموعد الذي وعدنا به، رغم الوقت الاحتياطي (Buffer Time)، ورغم الفريق الاحتياطي، ورغم بوابات التحكم في دورات العمل (Sprint)، فإن بند التعويض في العقد يسري تلقائيًا. وهذا البند رقمي، ويُحسب وفق معادلة محددة مسبقًا، ويتضاعف مع مرور الأيام. وآلية البند كالتالي: يعادل التأخير في الأسبوع الأول 10% من قيمة العقد، ثم 20% في الأسبوع الثاني، و35% في الأسبوع الثالث. وإذا استمر التأخير بعد نهاية الأسبوع الرابع، تُعاد قيمة العقد كاملة، ويُضاف إليها الجزء الذي يقع علينا من الضرر الذي لحق بوكالتك أمام عميلها. وهذا البند ليس وسيلة تخويف، بل هو الدليل الخارجي على انضباطنا في الجداول الزمنية. فشركة التقنية التي تقبل العمل في ظل بند صارم كهذا مضطرة إلى أن تكون دقيقة رياضيًا عند حساب أي موعد. فالصرامة علينا، والراحة لك.

موعد التسليم ليس وعدًا من القلب، بل رقم نوقّع عليه

التزام يستند إلى الحساب لا إلى الاعتقاد.

ما رأيناه على مر السنين هو أن ما ينقص قطاع البرمجيات ليس حسن النية، بل الانضباط. فعندما يقول مطوّر: «سأنهي هذا المشروع في 6 أسابيع»، فإنه غالبًا يؤمن بذلك حقًا. لكن الموعد لا يُحدَّد بالاعتقاد، بل بالحساب. لهذا يولد الجدول الزمني في Partnerfy عند بداية المشروع من مخرجات معادلة، لا من نية مهندس أول. وتجمع هذه المعادلة بين سرعة الفريق السابقة (Velocity)، وحجم النطاق بالأرقام، والمخاطر المفتوحة، والوقت الاحتياطي (Buffer). ثم نكتب الرقم الناتج في العقد. وما يتغير بالنسبة إليك أمر واحد: لن تُسمع بعد الآن عبارة «آمل أن نلحق بالموعد»، لا منا ولا منك أمام عميلك. فسؤال «هل سنلحق؟» لم يعد مسألة أمل، بل مسألة رياضيات. وقد تولينا حلها بالفعل.

تواصل معنا للحصول على جدول زمني محسوب رياضيًا

املأ النموذج أدناه، وسنعقد معك اجتماعًا تمهيديًا قصيرًا لفهم نطاق مشروعك ومخاطره. وفي نهاية هذا الاجتماع سيكون بين يديك موعد تسليم محسوب رياضيًا. ويمكنك كذلك استخدام الرقم ⁦0850 259 30 04⁩ للتواصل معنا مباشرة.

لأي استفسار، يمكنك التواصل معنا في أي وقت عبر: [email protected]

تم استلام طلبك!

سنراجع طلب الشراكة الخاص بك ونتواصل معك عبر الرقم في أقرب وقت ممكن.

الاسم الأول

اسم العائلة

البريد الإلكتروني

رقم الهاتف

—

ما نوع شركتك؟

اسم الشركة

ما نوع الدعم الذي تحتاج إليه؟

المواقع الإلكترونية مشاريع البرمجيات المخصصة تطبيقات الجوال تطبيقات سطح المكتب الخوادم والبريد الإلكتروني ودعم تقنية المعلومات

الرسالة

عدد العملاء المستهدف

500

1 1.000

العدد الشهري التقديري للعملاء المستهدفين (من 1 إلى 1,000)

حدد المربع للموافقة على

تعرّف على Partnerfy

لماذا Partnerfy؟

الموارد والدعم