คุณระบุและจัดการความเสี่ยงของโครงการ (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 อย่างสม่ำเสมอและเพิ่มเติมสิ่งใหม่เมื่อมันปรากฏขึ้น

## เหตุใดจึงสำคัญ

ความเสี่ยงที่ไม่ได้จัดการจะกลายเป็นวิกฤตตามปกติในช่วงเวลาที่แย่ที่สุดเท่าที่เป็นไปได้ใกล้กำหนดส่งมอบ

ค่าใช้จ่ายในการจัดการความเสี่ยงตั้งแต่เนิ่นนั้นน้อยมากเมื่อเทียบกับการผ่าตัดหลังจากที่มันโจมตี

การตั้งชื่อความเสี่ยงอย่างชาญฉลาดยังสร้างความเชื่อถือ — ผู้มีส่วนได้ส่วนเสียมักชอบ "นี่คือสิ่งที่อาจเป็นไปได้และแผนของเรา" มากกว่าความเงียบนิ่งที่มั่นใจตามด้วยการเซอร์ไพรส์ที่ไม่พึงประสงค์