في صباح يوم الثلاثاء، يبلغك مدير المنتج بأن موعد الإطلاق أصبح مهدداً بالخطر. وبحلول وقت الغداء، يخبرك مسؤول التكامل بأن المورّد قد غيّر واجهة برمجة التطبيقات (API) الخاصة به، مما يتطلب إعادة العمل من قِبَل الفريق. وفي نهاية اليوم، يستفسر فريق ضمان الجودة (QA) عن الاختبارات التي يمكن استبعادها نظراً لضغط الجدول الزمني. ويضيف محلل الأمن أن الفترة الزمنية المحدودة للاختبار ستعني على الأرجح ظهور النتائج بعد مرحلة “تجميد الكود” (code freeze). بصفتك مدير المشروع، تجد نفسك أمام قرار صعب: هل تحافظ على نطاق العمل كما هو، أم تؤجل الموعد، أم تقبل بتراجع مستوى الجودة؟ ومع كل ساعة انتظار، تزداد تكلفة القرار النهائي لأن الفرق تواصل العمل بناءً على افتراضات متباينة.
قبل إعداد شريحة عرض لحالة المشروع، تحتاج إلى فهم فرق جوهري وواضح: المخاطرة (Risk) هي حدث مستقبلي غير مؤكد قد يؤثر على الأهداف، بينما المشكلة (Issue) هي أمر واقع يحدث بالفعل حالياً. يُعد تغيير واجهة برمجة التطبيقات من قِبَل المورّد “مشكلة” بمجرد حدوثه، في حين كان احتمال حدوثه يُصنّف سابقاً على أنه “مخاطرة”. تهدف هذه الدورة التدريبية إلى بناء القدرة على التقييم وتوفير الأدوات اللازمة للحفاظ على هذا التمييز بوضوح وفعالية؛ وذلك من خلال استخدام سجل للمخاطر عملي، وتحديد الأهداف ومستوى تقبّل المخاطر في صفحة واحدة، وصياغة بيانات واضحة للمخاطر تتضمن مؤشرات التحفيز (triggers)، واعتماد آليات مراقبة مبسطة تتيح رصد حالة عدم اليقين مبكراً بما يكفي لاتخاذ الإجراءات اللازمة.
كمقدمة تمهيدية، استعرض تسلسل الأحداث وحدد اللحظة التي انتقل فيها المشروع من حالة عدم اليقين إلى الواقع الفعلي.
عندما تتجادل فرق العمل حول ما إذا كان أمر ما يشكل خطراً يستحق المتابعة، فإنهم غالباً ما يتجادلون حول شيء آخر تماماً؛ فهم يتناقشون حول الأولويات القصوى للمشروع، والافتراضات المعتمدة، والقيود غير القابلة للتغيير. وإذا كانت هذه الأمور غير واضحة، فإن أي نقاش حول المخاطر سينتهي بنصائح مبهمة مثل “لنراقب الأمر وحسب”.
تتمثل الصيغة العملية في إطار عمل موجز (في صفحة واحدة) يبدأ بتحديد الأهداف. فقد يكون هدف الجدول الزمني هو إطلاق المنتج بحلول نهاية الربع السنوي، وهدف التكلفة هو الالتزام بميزانية محددة للمورد، وهدف الجودة هو خلو المنتج من أي ثغرات أمنية حرجة عند الإطلاق. ومن هنا، تقوم بإدراج الافتراضات التي تعتمدها كحقائق لأغراض التخطيط (مثل ضمان استمرار توافق واجهة برمجة تطبيقات المورد مع الإصدارات السابقة)، والقيود غير القابلة للتفاوض (مثل المواعيد النهائية التنظيمية). بعد ذلك، تحدد الشهية للمخاطر، وهي تعبر عن حجم التباين أو الانحراف الذي يمكن للراعي (صاحب المشروع) تقبله قبل أن يتوقع تصعيد الأمر واتخاذ قرار بشأنه. إن الشهية للمخاطر لا تعني التفاؤل، بل هي بمثابة حد فاصل يوجه مسار العمل.
خطأ شائع: يتمثل الخطأ في الميل الفطري لتحديد مستوى واحد عام للشهية للمخاطر، مثل القول بأننا “نتبنى نهجاً منخفض المخاطر”؛ إذ يبدو هذا القرار حاسماً وقوياً. لكن النتيجة تكون اللجوء إلى مقايضات خفية؛ حيث يحمي الفريق الجدول الزمني عبر تقليص الاختبارات دون موافقة الراعي، أو يحمي الجودة عبر تأجيل موعد الإطلاق دون إبلاغ فريق المبيعات.
اختر مستويات الشهية للمخاطر التي تتناسب مع سياق المشروع، وليس بناءً على تفضيلاتك الشخصية.