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