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