كيف تحدد وتدير مخاطر المشروع (RAID)؟

Question

Accepted Answer

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

## سجل RAID

أداة بسيطة وموسعة الاستخدام لتتبع التهديدات والعناصر في المشروع:

```text
R — RISKS        → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS  → things we're taking as true (validate them)
I — ISSUES       → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
```

## قيّم كل مخاطرة

```text
For each risk, score:
  LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
```

## اختر ردة فعل

```text
AVOID    → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT   → live with it, but have a fallback ready
```

## مثال ملموس

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

## مشكلة شائعة

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

## لماذا يعتبر ذلك مهماً

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

تكلفة التعامل مع مخاطرة مبكراً صغيرة جداً مقارنة بإطفاء الحريق بعد أن تحدث.

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