تطوير البرمجيات وفق نموذج Follow-the-Sun: كيف يُحقق Hamburg + Ho Chi Minh City هندسةً مستمرة على مدار الساعة
Scaling Business

تطوير البرمجيات وفق نموذج Follow-the-Sun: كيف يُحقق Hamburg + Ho Chi Minh City هندسةً مستمرة على مدار الساعة

Rosie Nguyen

Rosie Nguyen

14 June 2026

لا يجب أن يتوقف السبرينت حين ينهي فريقك الأوروبي يوم عمله. يُمدّد نموذج Follow-the-Sun في تطوير البرمجيات ساعاتِ العمل الهندسي المنتجة عبر المناطق الزمنية، ما يُقلّص دورات التسليم دون أن يضطر أحد للعمل خارج ساعات العمل المعتادة. بالنسبة للشركات التي تسعى إلى التسليم الأسرع دون توسيع الكوادر البشرية، فهذا أحد أقل النماذج استخداماً في تطوير البرمجيات الموزعة.

التحدي أن أغلب الفرق التي تدّعي تطبيقه لا تفعل ذلك فعلياً. هذا ما يستلزمه النموذج حقاً، وهذا كيف تُشغّله Gradion بين Hamburg وHo Chi Minh City.

ما هو نموذج Follow-the-Sun في تطوير البرمجيات؟

Follow-the-Sun (FTS) هو، وفق تعريف Carmel وEspinosa وDubinsky الباحثين الذين أرسوا الأسس الأكاديمية لهذا النموذج، نوعٌ من سير العمل المعرفي العالمي المصمَّم لتقليص وقت الطرح في السوق. تُسلَّم المهام بين الفرق الموزعة جغرافياً عند انتهاء كل موقع من يومه، فيستلمها الفريق القادم مباشرةً ويواصل التطوير.

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

هذه هي الحقيقة التي تغفلها أغلب الأوصاف. Follow-the-Sun ليس ترتيباً للمناطق الزمنية، بل هو انضباط. المنطقة الزمنية مجرد شرط مسبق، أما الانضباط فهو ما يُحقق النتائج.

لماذا Hamburg وHo Chi Minh City؟

تعمل Hamburg وفق توقيت CET (UTC+1) شتاءً وCEST (UTC+2) صيفاً. أما Ho Chi Minh City فتعمل وفق توقيت ICT (UTC+7) طوال العام. يبلغ الفارق الزمني 5 ساعات صيفاً و6 ساعات شتاءً.

Follow the Sun


تمتلك Gradion أيضاً مركزاً هندسياً في Cairo. تعمل مصر وفق توقيت EET (UTC+2) طوال العام، إذ أُلغي التوقيت الصيفي عام 2011. يضع هذا Cairo في نطاق زمني مماثل لـ Hamburg: متطابق صيفاً، ومتقدم بساعة واحدة شتاءً.

من منظور FTS، تُشكّل Hamburg وCairo معاً ركيزةً غربية واحدة، لا نقطتَي إرسال مستقلتين. إذ تتشاركان نافذة الصباح الأوروبية ومنطقة الشرق الأوسط وشمال أفريقيا، وتُعمّقان الطاقة الهندسية المجمّعة على الجانب الغربي، وتُوسّعان تغطية Gradion السوقية في منطقة الشرق الأوسط وشمال أفريقيا. تنتقل المهام شرقاً إلى HCMC مع انتهاء أوروبا ومنطقة الشرق الأوسط وشمال أفريقيا من يومها، وتعود إلى الفريق الغربي في صباح اليوم التالي.

يُنشئ هذا نافذةَ توقيت مشترك طبيعية. تبدأ Hamburg وCairo في الساعة 09:00 بالتوقيت المحلي، فيما تكون HCMC عند الساعة 14:00 ICT في منتصف فترة العمل المسائية، في ذروة الإنتاج. تمنح جلسة المزامنة المنظمة من 09:00 إلى 11:00 CET كلا الجانبين سياقاً مشتركاً، ثم يُسلّم الفريقان الغربيان المهام لتواصل HCMC العمل حتى مساء يومها.

بحلول إغلاق HCMC عند 18:00 ICT، تكون Hamburg في الساعة 12:00-13:00 CET من اليوم التالي. العمل المنجز جاهز، تبدأ المراجعة، وتتواصل الدورة.

ستة عشر ساعة هندسية منتجة. لا أحد يعمل خارج ساعات العمل المعتادة. لا حاجة لأي جهود استثنائية.

هنا أيضاً يعكس انتشار Gradion شيئاً أعمق من مجرد حسابات المناطق الزمنية. تجلب Hamburg الصرامة الهندسية الألمانية، وقرارات البنية المنظمة، والتوثيق المنضبط، ومعايير التسليم الدقيقة. تُضيف Cairo قرباً من سوق الشرق الأوسط وشمال أفريقيا وعمقاً هندسياً للركيزة الغربية. وتأتي HCMC بسرعة التسليم، والإنتاجية العالية، والتكرار السريع، وفريق هندسي متمرس بُني للتحرك. معاً، لا يُغطون ساعاتٍ أكثر فحسب، بل يُغطون نطاقاً أوسع.

ما الذي يُنجح النموذج عملياً؟

استعرض Kroll وزملاؤه (2013) 36 ممارسة مثلى عبر تطبيقات Follow-the-Sun المختلفة. خلاصة نتائجهم: جودة عملية تسليم المهام هي العامل الأكثر أهمية على الإطلاق. ضعف نقل السياق هو حيث ينهار FTS، لا فجوات المناطق الزمنية أو الاختلافات الثقافية.

عملياً، يستلزم سير عمل FTS الفعّال أربعة عناصر:

  • توثيق منظم لتسليم المهام. يجب أن تحمل كل مهمة تُنقل بين المواقع حالتها الراهنة، والعوائق المفتوحة، والقرارات المتخذة، والإجراء التالي المطلوب. التسليم الشفهي عبر المناطق الزمنية ليس تسليماً حقيقياً، بل هو افتراض سيكلف ساعاتٍ من الضياع.
  • ساعات توقيت مشترك ثابتة. نافذة التوقيت المشترك ليست للتدارك، بل للمحاذاة: حلّ العوائق، وتأكيد الأولويات، وإغلاق الغموض قبل أن يعمل الفريق المستلِم دون دعم. في Gradion، هذه النافذة ثابتة لا مرنة.
  • التواصل غير المتزامن أولاً. خارج نافذة التوقيت المشترك، يعمل كلا الفريقين بصورة غير متزامنة. القرارات لا تنتظر محادثة مباشرة. التوثيق، ومراجعة PR غير المتزامنة، والقرارات المعمارية المكتوبة ليست عبئاً إضافياً، بل هي نظام التشغيل بأكمله.
  • بنية تحتية للتسليم المستمر. الأنابيب الآلية، والبيئات المشتركة، وتغطية الاختبارات أمورٌ غير قابلة للتفاوض. أي بناء لا يعرف كيف يُشغّله إلا فريق Hamburg يعني تأخيراً من ستّ ساعات في كل مرة يحتاجه HCMC.

ما الذي ليس Follow-the-Sun:

FTS كثيراً ما يُدَّعى ونادراً ما يُمارَس. وثّق Treinen وMiller-Frost (2006) في دراسة حالة بمجلة IBM Systems Journal تطبيقاتٍ ناجحة وأخرى فاشلة لـ FTS. أكثر أسباب الفشل شيوعاً: فرق تعمل بالتوازي لا بالتتابع. كان كلا الموقعين نشطاً، لكن لم يكن أيٌّ منهما يبني على مخرجات الآخر. كانت النتيجة تكراراً وتعارضاً في الدمج وعبئاً تنسيقياً أفقد النموذج ميزته الزمنية كلياً.

أي مورّد يصف نموذجه بأنه Follow-the-Sun لكنه عاجز عن وصف آلية تسليم مهامه لا يُشغّل FTS فعلاً. إنه يُشغّل فريقاً موزعاً بتسويق أكثر صقلاً.

هذا التمييز يُفضي إلى نتائج مختلفة. التطوير الموزع بالتوازي يُوسّع الطاقة الإنتاجية. تطوير Follow-the-Sun يُسرّع الإيقاع. الأول يُضيف مهندسين. الثاني يُقلّص الجدول الزمني.

نموذج Gradion عملياً

صُمّم إعداد Gradion وفق مبادئ FTS من البداية، ولم يُضَف لاحقاً على بنية قائمة.

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

تسليم المهام موثَّق كتابياً. نوافذ التوقيت المشترك محمية. التواصل غير المتزامن هو الأصل، لا الاستثناء.

بالنسبة للعملاء، يعني هذا أن عائقاً يُحلّ عند 17:00 CET لا ينتظر حتى الساعة 09:00 من صباح اليوم التالي، بل يُعالجه HCMC في مساء ذلك اليوم، والمخرج جاهز حين تفتتح Hamburg وCairo يومهما.

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

ما الذي يجب أن تسأل عنه عند تقييم مورّد Follow-the-Sun؟

إن كنت تقيّم ما إذا كان مورّدٌ ما يعمل وفق نموذج FTS فعلياً، فاطرح ثلاثة أسئلة:

  1. 1. كيف توثّقون المهام وتنقلونها بين المواقع في نهاية اليوم؟ وكيف يبدو وثيقة التسليم؟
  2. 2. ما نافذة التوقيت المشترك الثابتة لديكم، ومن يُلزَم بالحضور فيها؟
  3. 3. كيف تتعاملون مع عائق يظهر بعد عملية التسليم؟

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

تطوير Follow-the-Sun قرارٌ تشغيلي بامتياز. الجغرافيا تجعله ممكناً. الانضباط هو ما يجعله يعمل.

المصادر

  • Carmel, Espinosa & Dubinsky (2010), Follow-the-Sun Software Development, Journal of Management Information Systems
  • Treinen & Miller-Frost (2006), IBM Systems Journal, successful and failed FTS case studies
  • Kroll et al. (2013), systematic literature review, 36 FTS best practices identified
  • Wikipedia, Follow-the-sun (citing Carmel, Dubinsky & Espinosa, 2009, Hawaii International Conference on System Sciences)
  • Timezone offsets: CET UTC+1, CEST UTC+2, EET UTC+2 year-round (Egypt abolished DST 2011), ICT UTC+7
Rosie Nguyen

About the author

Rosie Nguyen

تعمل Rosie Nguyen في نقطة التقاء التسويق والاتصالات ورواية القصص الهادفة في Gradion. تكتب عن القيادة وتوسيع نطاق الأعمال، موجهةً مقالاتها للمؤسسين والقادة التشغيليين الذين يبنون شركاتهم في مختلف أنحاء آسيا.

اطرح علينا الأسئلة الثلاثة

يمكننا وصف آلية تسليم المهام، ونافذة التوقيت المشترك، وكيفية التعامل مع عوائق العمل التي تقع بين المواقع.