كانت منصة Nike B2B للتجارة الإلكترونية تعمل لأكثر من ستة سنوات. كانت تعالج مليارات الدولارات في الطلبات. والتطبيقان على أساسها كانا مستحقين لهجرة سيلمس سلسلة إدخال الطلبات وتكامل SAP وأساس منصة التطبيقات نفسه. تم إحضار الفريق في TechSparq كشريك تجارة إلكترونية لـ Nike للتنفيذ.
هذه ليست قصة عن اكتشاف غير الاستراتيجية. هذه قصة عن كيف يبدو التنفيذ النظيف عندما تكون الرهانات 9 مليارات دولار في الإيرادات ومعيار العيب لم تتمكن الشركاء الأكبر من تحقيقه بشكل ثابت قبلك.
المنصة وما كان على المحك
لم تكن تطبيقا ATG Dynamo اللذان أشركت Nike TechSparq لترحيلهما تجريبياً. كانا في الإنتاج لأكثر من ستة سنوات، يخدمان عمليات التجارة الإلكترونية B2B في Nike. كانت المنصة التي كانا جزء منها مسؤولة عن تسعة مليارات دولار في الإيرادات السنوية.
كان نطاق الهجرة كبيراً. نقل كلا التطبيقين من ATG Dynamo إلى JBoss Enterprise Application Platform. ترقية جميع مكتبات مفتوحة المصدر إلى الإصدارات الحالية. ترقية تكامل SAP BAPI إلى أحدث إصدار ممكن. وتسليم عدة تغييرات وظيفية جنباً إلى جنب مع الهجرة. كل هذا دون تعطيل عمليات التجارة الإلكترونية التي تعمل على المنصة.
كان خط أساس Nike للتوقعات لإصدارات الإنتاج من هذا النوع مستنداً إلى تجربة مؤلمة. كانت الإصدارات من هذا النوع عادة تنتج حوالي سبعة إلى عشرة أخطاء حرجة في الأسابيع الأولى الأربعة في الإنتاج. لم تكن هذه حالة شاذة. كان هذا معيار الصناعة لما سلمه شركاء Nike الآخرون.
التحدي التقني وحيث أصبح أصعب
ATG Dynamo إلى JBoss هو تحول معماري مهم. كانت التطبيقات الموجودة قائمة على JSP و Struts، مبنية على بنية تحتية تجارية ATG جنباً إلى جنب مع تبعيات مفتوحة المصدر مختلفة تراكمت على مدى ستة سنوات. ترقية المكتبات أثناء تغيير منصة التطبيقات وشحن تغييرات الوظائف في نفس الوقت هي هجرة متعددة الأبعاد تضاعف المخاطر في كل طبقة.
أضاف تكامل SAP بعداً لا يمكن التخطيط له. أحد التطبيقين ألحقت مباشرة مع SAP وتطلب تقنية SAP BAPI لهذا التكامل. أثناء التطوير، اكتشف الفريق أن عدم توافق الإصدار بين رمز BAPI الموجود وبيئة الهدف لم يكن قابلاً للحل مع التحديثات الإضافية. كان رمز BAPI يتطلب إعادة كتابة بالحجم الكامل.
هذا النوع من الاكتشاف، في منتصف الهجرة، على منصة إنتاج 9 مليارات دولار، هو المكان الذي تنزلق فيه جداول المشاريع، حيث تطلب الفرق تخفيف النطاق، وحيث تبدأ الشركات ذات العمق التقني الأقل في إجراء مقايضات تضر الجودة. حلت فريق TechSparq هذا دون ساعات إضافية وبدون تأثير الجدول الزمني.
نموذج الفريق البعيد الذي جعله يعمل
تم إجراء الارتباط بطريقة دون ثقل. مدير مشروع، مطور Java رئيسي واحد، مطور Java كبير واحد، مطور Oracle واحد، ومدير برنامج وعلاقات. سافر مطور الرصاص إلى موقع عميل Nike تقريباً أسبوع واحد شهرياً. عملت بقية الفريق من مركز تطوير Atlanta في TechSparq.
هذا يستحق التوقف عنده. العملاء المؤسسيين في حجم Nike معتادون على فرق كبيرة في الموقع من شركات استشارية كبيرة - فرق تخلق انطباع بصري للجهد من خلال العدد والحضور المادي. عملت TechSparq مع فريق بعيد منضبط يتطلب دعم عميل ضئيل وتوجيه. تم الاعتراف بالنتيجة داخلياً في Nike في عدة اجتماعات قيادة كبرى كنموذج لكيفية تشغيل هذا النوع من المشروع.
يعمل النموذج البعيد عندما يكون لدى الفريق العمق التقني للعمل بشكل مستقل وانضباط العملية للبقاء متزامناً دون قرب ومعايير الاتصال لإظهار المشاكل قبل أن تصبح عناصر حجب. لا يعمل عندما تتطلب الفرق الدعم اليدوي الثابت أو عندما تغطي إدارة المشروع فجوات تقنية. لم يكن لدى هذا الفريق فجوات لتغطيتها.
بعد التسليم، تم تسليط الضوء على ارتباط TechSparq في عدة اجتماعات قيادة داخلية Nike كمشروع نموذجي. كان الاعتراف محدداً. دعم عميل قليل جداً مطلوب. تم التسليم في الوقت المحدد. تم التسليم ضمن الميزانية. بالنسبة لشركة تتنافس للحصول على أعمال Nike المستمرة جنباً إلى جنب مع شركاء أكبر بكثير، كان هذا الاعتراف النتيجة المباشرة لجودة التنفيذ، وليس إدارة العلاقات.
النتيجة التي تتحدث عن نفسها
تم تسليم التطبيقات المرتقاة في الوقت المحدد وضمن الميزانية. لم تكن ساعات إضافية مطلوبة. وفي الأسابيع الأربعة الأولى من الإنتاج، تم اكتشاف عيبين غير حرجين. ليس سبعة. ليس عشرة. ليس أي أخطاء حرجة على الإطلاق. عيبان غير حرجيين على هجرة منصة B2B بالحجم الكامل التي تتضمن إعادة كتابة SAP BAPI معقدة وتغيير منصة وترقية مكتبة عبر سنة ستة قديمة من قاعدة الرمز.
لم تحدث هذه النتيجة لأن المشروع كان بسيطاً. حدثت لأن الفريق الذي فعله كان قادراً تقنياً بما يكفي للعثور على مشاكل أثناء التطوير بدلاً من السماح لها بالظهور في الإنتاج. هذا هو التمييز بين فريق يرمز وفريق هندسة.
ما كان مدير Nike حقاً يسأل
سؤال Shane Guenes - لماذا يمكن لـ TechSparq فعل ذلك عندما لا يستطيع الشركاء الأكبر - يستحق الإجابة بشكل مباشر. إنه ليس سؤال بلاغي. إنه سؤال هيكلي.
تجلب شركات الاستشارات والتكنولوجيا الكبيرة موارد كبيرة. يجلبون أيضاً علوية وطبقات إدارة مشاريع وفرق بعمق تقني غير متساوٍ وأنماط حوكمة محسنة لحماية الشركة بدلاً من تسليم النتيجة. عندما تعاني جودة التنفيذ، نادراً ما يكون السبب هو أن الشركة تفتقر إلى أشخاص أذكياء. السبب هو أن الأشخاص الأذكياء دفنوا تحت العملية، أو لأن الفريق على العمل الفعلي لم يكن الفريق الذي فاز بالارتباط.
تعمل TechSparq بشكل مختلف. الفريق الذي ينطق العمل هو الفريق الذي يفعل العمل. العمق التقني حقيقي وينطبق على جميع الفريق، وليس فقط الرصاص. انضباط العملية والقدرة على التنفيذ البعيد ليسا نقاط الحديث. إنهم نموذج التشغيل. وعندما يحدث شيء غير متوقع في منتصف المشروع - مثل مجموعة رمز BAPI يتطلب إعادة كتابة كاملة - لا توجد طبقة إدارة مشاريع بين المشكلة والمهندسين الذين يحلونها.
- العمق التقني يتفوق على العدد. فريق دون ثقل يتمتع بخبرة حقيقية سيتفوق على فريق كبير بقدرة متوسطة على الهجرات المعقدة في كل مرة.
- يمكن للفرق البعيدة أن تتفوق على المفروشة. الحضور ليس وكيل للجودة. معايير الجودة وعملية ديسمبر وجغرافيا.
- معدلات العيوب هي خيار. سبعة إلى عشرة أخطاء حرجة في أربعة أسابيع ليست حتمية. هذا ما يحدث عندما يتم التعامل مع الجودة كمشكلة اختبار بدلاً من معيار هندسي.
- المفاجآت ليست أعذار. إعادة كتابة BAPI في منتصف المشروع هي اكتشاف مهم. كما أن فريق قادر تقنياً يمتصه ويحله دون تأثير الجدول الزمني أو الميزانية.
منصتك تستحق تسليم خالي من العيوب.
عملت TechSparq كشريك تقني موثوق به لـ Nike و Columbia Sportswear و Empower Global والآخرين حيث يتم قياس تكلفة التنفيذ الضعيف بالإيرادات وليس فقط بالجدول الزمني. إذا كان لديك هجرة معقدة أو تكامل أو مبادرة منصة، يجب أن نتحدث.
حجز جلسة استراتيجية تقنية ↖︎