من التجربة إلى الإطلاقPilot to production

التجربة إطلاق محدود على عدد صغير من العملاء الحقيقيين قبل فتح المنتج للجميع. والغرض منها ليس اختبار الكود، بل اكتشاف ما لم يخطر لك حين يتحرك مال حقيقي.

يقلل الإطلاق الصغير مساحة الخطأ، لكنه لا يعفيك من معرفة ما ستفعله بكل ريال تحرك.

ليش ما أطلق للجميع من أول يوم؟

وهذا سؤال وجيه، خصوصاً إن كان المنتج جاهزاً واختُبر داخلياً. فلماذا نبطئ عمداً؟

لأن أخطر الأعطال في المنتجات المالية لا تظهر إلا بالحجم.

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

ولا واحد من هذه كان قابلاً للاكتشاف بمئتي مستخدم.

وثمة سبب ثانٍ أهم: لا يمكنك التراجع عن إطلاق. فتطبيق ألعاب فيه خلل يُغلق ويُعتذر عنه. أما إن خُصم من ألف عميل مرتين، فقد وقع الضرر ودخلت في مسار تصحيح وتعويض وربما بلاغ للجهة الرقابية. فالمشكلة لم تعد تقنية.

ولهذا فالإطلاق التدريجي ليس تردداً، بل هو الطريقة الوحيدة لجعل ثمن الخطأ محتملاً. فأن يتأثر خمسون عميلاً وتتصل بهم شخصياً، خير من أن يتأثر خمسون ألفاً وتقرأ عن نفسك في الأخبار.

حدد معنى التجربة

وتبدأ «التجربة المحدودة» بمجموعة معروفة ومدة وحجم وأهداف. فقد تطلق لمئة موظف في شركة واحدة لأربعة أسابيع، وبحد تحويل يومي قدره ألف ريال. ولا تعني التجربة فتح المنتج للجميع ثم تسميته تجريبياً.

واختر عملاء يمثلون الاستخدام الحقيقي لكن يمكن الوصول إليهم عند الخطأ. ولا تملأ التجربة بموظفي شركتك فقط، فهم يعرفون الواجهة ويتسامحون مع الأعطال. وأدخل حالات مختلفة في الأجهزة والبنوك وأنماط الدخل ضمن الحدود المرخصة.

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

ضع مفتاحاً وحدوداً

ويعني «مفتاح الميزة» Feature flag تحكماً يفعل المنتج لبعض العملاء دون نشر كود جديد. فيمكنك تشغيل التحويل لمجموعة واحدة وإيقافه خلال دقائق. ولا تجعل المفتاح مجرد زر في واجهة غير محمية، بل ضابطاً بصلاحيات وسجل.

وحدد حدوداً للقيمة والعدد والبلدان وأنواع العملاء. فإذا ظهر خلل، يبقى أقصى أثر معروفاً. وراجع الحدود مع المخاطر والامتثال والخزانة، لأن الحد التقني قد يتجاوز قدرة الشركة على التعويض.

ولا تعتمد على المفتاح وحده. فقد يفشل نظام التحكم أو يُستخدم خطأ. واستخدم حدوداً داخل الخدمة والمزود والسجل، بحيث لا يستطيع خطأ واحد فتح الحجم كله.

اكتب شرط التوقف مسبقاً

ولا يستطيع فريق متحمس الحكم بهدوء وسط الإطلاق. ولذلك اكتب رقماً ونافذة زمنية وفعلاً. فقد تقول إنك توقف الميزة إذا تجاوز فشل الدفع ٠٫٥ بالمئة عشر دقائق، أو ظهر فرق مطابقة واحد غير مفسر.

واجعل لكل شرط مصدراً ومالكاً. فإذا كانت اللوحة متأخرة ساعة، لا تصلح لقرار خلال عشر دقائق. وإذا لم يملك أحد صلاحية الإيقاف، فالشرط أمنية لا ضابط.

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

تدرب على التراجع

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

وقد ينجح الكود القديم لكنه لا يفهم حقلاً كتبته النسخة الجديدة. وقد تبقى رسائل في الطابور تعيد تشغيل السلوك بعد التراجع. ولذلك تشمل الخطة التطبيق والبيانات والوظائف المجدولة والطوابير والتكاملات.

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

الكود يعود والمال لا يعود

ولا يلغي التراجع دفعة نُفذت أو رسماً خُصم. فقد أرسل الإصدار الخاطئ حوالتين، ثم عاد الكود القديم. وتظل الحوالتان في البنك والسجل وتحتاجان معالجة منفصلة.

وافصل خطة الاستعادة التقنية عن خطة المعالجة المالية. فحدد كيف ستجد العمليات المتأثرة، ومن يوقف التسوية إن أمكن، وكيف ستعيد المال، ومن يوافق على التعويض. ولا تعد العميل بعكس عملية نهائية قبل تأكيد القدرة.

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

جهز الدعم والعمليات

ولا يكون المنتج حياً حين يعمل الخادم فقط. فيحتاج موظف الدعم معرفة الحالات والرسائل وحدود ما يستطيع فعله. ويحتاج موظف العمليات قائمة بالطلبات المعلقة وطريق تصعيد للمزود.

واكتب سيناريوهات لأول يوم: خصم بلا تأكيد، وهوية عالقة، وتحويل متأخر، وعميل يريد الإلغاء. وأعط كل سيناريو جواباً ومالكاً ووقت استجابة. ولا تجعل العميل أول من يختبر عملية الشركة.

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

راقب الرحلة كاملة

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

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

وسجل القرارات أثناء التجربة. فإذا غيرت حداً أو رسالة أو قاعدة، اكتب السبب والوقت والأثر المتوقع. ولا تسمح بتغييرات يومية مجهولة تجعل مقارنة النتائج مستحيلة.

توسع على درجات

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

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

ويكتمل الانتقال إلى الإنتاج حين يصبح التشغيل عادياً لا بطولياً. فيعرف الفريق شرط التوقف، ويجرب التراجع، ويعالج المال المنقول، ويملك كل استثناء. وعندها يكون التوسع زيادة محسوبة لا قفزة في المجهول.