قرار go/no-go: كيف تُحضّر له ومن يقرّر

ما الذي يقرّره go/no-go

قرار go/no-go هو اللحظة التي تقول فيها الأعمال: يمكن لهذا الإصدار من نظام CRM أن ينتقل إلى الإنتاج، في هذا التاريخ. أو تقول: ليس بعد. إنه ليس إجراءً شكليًا في نهاية الاختبار. إنه السبب الذي أُجري الاختبار من أجله.

لقرار go/no-go الجيد ثلاثة أجزاء:

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

معظم اجتماعات go/no-go التي تسوء يغيب عنها الجزء الأول. يتجادل الناس حول مدى سوء مشكلة ما، أو حول ما إذا كانت عملية ما قد اختُبرت أصلًا، لأن أحدًا لا يملك الأرقام. يتناول باقي هذا الدليل كيف تضمن وجود الحقائق قبل بدء الاجتماع.

معايير الخروج: اتفق عليها قبل يوم الاختبار الأول

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

معايير تنجح مع معظم عمليات إطلاق أنظمة CRM:

• لا توجد أي مشكلة Critical مفتوحة.
• نجحت كل حالة اختبار Must.
• لكل مشكلة High مفتوحة حل بديل أو موعد للإصلاح تقبله الأعمال.
• لكل حالة اختبار ضمن النطاق نتيجة.
• اعتمد مالك كل عملية.

اتفقوا على معنى الكلمات

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

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

اكتب ما لم يُختبر

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

من يقرّر

تشارك مجموعتان من الأشخاص، بأدوار مختلفة.

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

لكل عملية أو مجموعة في الاختبار، يعتمد شخص واحد من الأعمال: مدير المبيعات لعملية lead to cash، ورئيس خدمة العملاء لإدارة الحالات، ومسؤول المالية للفوترة. فهم يعرفون ما تحتاجه فرقهم، وسيعيشون مع النتيجة. يقول اعتمادهم: يستطيع فريقي أداء عمله بهذا الإصدار.

سمِّهم في بداية المشروع، لا في الأسبوع الأخير. مالك العملية الذي يرى الاختبار لأول مرة في اجتماع go/no-go إما أن يوقّع دون قراءة، أو يطلب أسبوعًا آخر.

اللجنة التوجيهية تقرّر

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

مدير الاختبار يُحضّر، لكنه لا يقرّر

يقدّم مدير الاختبار الحقائق ونصيحة. لا يعتمد مدير الاختبار نيابةً عن الأعمال ولا يتخذ القرار. والفصل بين هذه الأدوار هو ما يجعل القرار صامدًا عندما يحدث خطأ ما بعد الانتقال إلى التشغيل الفعلي.

التقرير: ما الذي يتضمنه

تقرير go/no-go موجّه إلى من لم يشاركوا في الاختبار. اجعله قصيرًا: صفحة واحدة، والتفاصيل خلفها لمن يريدها.

• نصيحة. go، أو go بشروط، أو no-go، مع الأسباب في سطر أو سطرين.
• النطاق. ما العمليات وقصص المستخدمين التي شملها الاختبار، وما الذي لم يُختبر.
• ما الذي اختُبر. البيئة والإصدار والبنية (build). فالنتيجة تخص إصدارًا واحدًا من النظام.
• الأرقام. حالات الاختبار التي نجحت، والتي فشلت، والمعطّلة، وغير المكتملة.
• لكل مجموعة أو عملية. الأرقام نفسها، مع اعتماد كل مجموعة.
• لكل أولوية. كم حالة اختبار Must وShould وCould نجحت، وأي حالات اختبار Must لم تنجح.
• المشكلات حسب الخطورة. كم منها مفتوح، وجاهز لإعادة الاختبار، ومغلق، مع ذكر المشكلات Critical وHigh المفتوحة بالاسم.
• عمليات الاعتماد. من وقّع، ومتى، وبأي قرار، وبأي شروط.
• المخاطر المعروفة. الحلول البديلة التي ستستخدمها الأعمال في الأسابيع الأولى، ومن يدعمها.

أرسل التقرير قبل الاجتماع بيوم. من يقرؤه في البيت يطرح أسئلة أفضل.

في UAT Studioيتضمن Go/no-go report في لوحة المعلومات المؤشر (GO أو GO with conditions أو NO-GO، مع الأسباب)، والأرقام، والتقدّم اليومي، والنتائج لكل مجموعة ولكل epic ولكل أولوية، والمشكلات حسب الخطورة، والمشكلات Critical وHigh المفتوحة بالاسم، وكل اعتماد في الجولة. يتبع المؤشر قواعد ثابتة وهو مجرد نصيحة: اللجنة التوجيهية هي التي تقرّر. شاركه كملف PDF أو نزّله كشرائح لعرض اللجنة التوجيهية.

ماذا تفعل بالمشكلات المفتوحة

توجد دائمًا مشكلات مفتوحة في نهاية UAT. والسؤال ليس ما إذا كانت موجودة، بل ما إذا كان لكل منها قرار. راجعها قبل الاجتماع، مع الأعمال وفريق التطوير، كما في الفرز اليومي.

أعِد التصنيف بحذر

في الأيام الأخيرة يكون هناك ضغط لنقل مشكلة Critical إلى High. وأحيانًا يكون ذلك صحيحًا: يظهر حل بديل، أو يتبيّن أن العملية نادرة. افعل ذلك علنًا، في الفرز، مع مالك العملية، واكتب السبب. لا تفعله أبدًا بصمت لتبدو الأرقام أفضل. هكذا يفشل الانتقال إلى التشغيل الفعلي في أسبوعه الأول.

الرغبات ليست عيوبًا

يجد المختبِرون أشياء يودّون لو كانت مختلفة. إذا كان النظام يعمل كما صُمّم، فهذا طلب تغيير: يذهب إلى قائمة المهام المتراكمة (backlog)، لا إلى هذا الإصدار، ولا يُحتسب ضد الانتقال إلى التشغيل الفعلي.

في UAT Studioيمنح الفرز كل مشكلة درجة خطورة وأولوية ومكلَّفًا وقرارًا: Fix أو Reject أو Change request. مع وحدة AI test design، يكتب Summarize with AI في علامة التبويب Issues نظرة عامة قصيرة على المشكلات المفتوحة لاجتماع go/no-go: مجمّعة حسب الموضوع، مع ما يعيق الانتقال إلى التشغيل الفعلي. وبدونها، يوفّر Summarize with your own AI موجّهًا (prompt) لتلصقه في الذكاء الاصطناعي لشركتك.

go مشروط

تحصل كثير من عمليات إطلاق أنظمة CRM على go بشروط. النظام جيد بما يكفي، شريطة أن يُنجز أمر ما قبل الانتقال إلى التشغيل الفعلي أو بعده مباشرة. وهذا قرار عادل، ما دامت الشروط حقيقية.

الشرط الجيد هو:

• محدّد. إصلاح موافقة الخصم للطلبات التي تتجاوز 50,000 وإعادة اختبارها، لا الموافقات تعمل.
• له مالك. شخص واحد مسؤول عنه، بالاسم.
• مؤرّخ. قبل الانتقال إلى التشغيل الفعلي، أو تاريخ في الأسابيع الأولى بعده.
• مُتحقَّق منه. يؤكد شخص ما أنه أُنجز، وتُبلَّغ اللجنة التوجيهية بذلك.

انتبه إلى عدد الشروط. شرطان أو ثلاثة أمر طبيعي. خمسة عشر شرطًا تعني أن الاختبار لم ينتهِ. go المشروط ليس وسيلة لتجنّب no-go.

الانتقال إلى التشغيل الفعلي على أجزاء

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

الاعتماد لكل مجموعة

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

• Accepted: يستطيع فريقي أداء عمله بهذا الإصدار.
• Accepted with conditions: شريطة إنجاز الشروط. اكتب كل شرط، مع من ينجزه ومتى.
• Rejected: ليس جيدًا بما يكفي للانتقال إلى التشغيل الفعلي. اسأل ما الذي قد يغيّر الجواب.

اجمع عمليات الاعتماد قبل الاجتماع، حتى تقرّر اللجنة التوجيهية بناءً على الصورة الكاملة. الاعتماد يخص إصدارًا واحدًا: عندما تأتي build جديدة أو جولة اختبار جديدة، اعتمد من جديد.

في UAT Studioتحتوي بطاقة Sign-off في لوحة المعلومات على صف للمشروع بأكمله وصف لكل مجموعة، مع Accepted أو Accepted with conditions أو Rejected. ويُسجَّل التاريخ والوقت وعدد المشكلات Critical المفتوحة. افتراضيًا، لا يمكن لأحد القبول ما دامت هناك مشكلة Critical مفتوحة؛ ومع تحديد No sign-off while Must test cases have not passed، ينتظر القبول أيضًا حتى تنجح كل حالة اختبار Must. الرفض ممكن دائمًا. الاعتماد يخص الجولة الحالية.

إدارة اجتماع go/no-go

خطّط للاجتماع عندما تخطّط لأيام الاختبار، مع وضع التاريخ في تقويم اللجنة التوجيهية. خصّص ساعة. ترتيب نموذجي:

1. يعرض مدير الاختبار التقرير: النطاق، والأرقام، والمشكلات المفتوحة، وعمليات الاعتماد. عشر دقائق، والأرقام على الشاشة.
2. يقول كل مالك عملية في جملة أو جملتين لماذا وقّع كما وقّع، وما شروطه.
3. أسئلة حول المشكلات Critical وHigh المفتوحة: هل يوجد إصلاح، أو حل بديل، أو موعد؟
4. أسئلة خارج الاختبار: التدريب، وترحيل البيانات، والدعم في الأسابيع الأولى، وخطة التراجع.
5. القرار: go، أو go بشروط، أو no-go. اقرأه بصوت عالٍ، مع الشروط والمالكين والمواعيد.

إذا كان القرار no-go، فاختم بخطة: ما الذي يجب أن يتغيّر، وجولة اختبار جديدة، وموعد لقرار go/no-go التالي. no-go مع خطة هو قرار عادي في المشروع. أما no-go بدون خطة فيبدو كأنه فشل.

سجل القرارات

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

يحتوي سجل القرارات، لكل قرار go/no-go، على:

• التاريخ، ومن حضر الاجتماع.
• القرار: go، أو go بشروط، أو no-go.
• كل شرط، مع مالكه وموعده، ولاحقًا متى أُنجز.
• المشكلات المفتوحة التي قبلتها الأعمال، مع السبب.
• التقرير الذي بُني عليه القرار، كما كان في تلك اللحظة.

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

في UAT Studioيحتفظ Save snapshot في تقرير go/no-go بالتقرير كما كان عند اتخاذ القرار؛ فلا يتغيّر بعد ذلك، ويفتحه Show مجددًا لاحقًا. ويبقى كل اعتماد في السجل، بما في ذلك ما استُبدل أو سُحب. ولأجل المدقّق، ينزّل المسؤولون Evidence pack: التقرير، وحالات الاختبار، والنتائج، والمشكلات، وسجل كل مشكلة، وكل اعتماد، وسجل التدقيق، مع مجموع اختباري (checksum) لكل ملف.

مجاني الاستخدام

معايير الخروج والاعتماد والتقرير موجودة أيضًا في قائمة تحقق UAT لإطلاق نظام CRM، كملف Excel مجاني. وللاختبار بأكمله، اطّلع على الأدلة الخاصة بـ Salesforce UAT وDynamics 365 UAT.