Bus Factor — วัดความเสี่ยงของทีมเมื่อคนสำคัญหายไป

ลองนึกภาพนี้: นักพัฒนาคนหนึ่งในทีมลาป่วยกะทันหัน — ทีมทั้งหมดหยุดชะงัก เพราะไม่มีใครรู้ว่า authentication module ทำงานอย่างไร ไม่มีใครแตะ deployment script เป็น ไม่มีแม้แต่คนที่รู้ว่า password ของ production server อยู่ที่ไหน

นี่คือสัญญาณว่าทีมมี Bus Factor ต่ำมาก

แล้ว Bus Factor คืออะไรกันแน่?

🚌 Bus Factor คืออะไร#

Bus Factor คือจำนวนขั้นต่ำของสมาชิกทีมที่ถ้าหายไปพร้อมกัน จะทำให้โปรเจกต์หยุดชะงัก เพราะความรู้ที่จำเป็นหายตามไปด้วย

ชื่อนี้มาจากคำถามสมมติว่า “ถ้าคนนี้โดนรถบัสชนพรุ่งนี้ ทีมจะเป็นอย่างไร?” — ฟังดูโหดร้าย แต่ตรงประเด็น แต่ในชีวิตจริง สถานการณ์แบบเดียวกันนี้เกิดได้จากการลาออก เปลี่ยนงาน หรือลาป่วยระยะยาว ผลลัพธ์ก็ไม่ต่างกัน — จึงมีคำเรียกอีกแบบว่า Truck Factor ซึ่งมีความหมายเดียวกัน

ยิ่งตัวเลขต่ำ ความเสี่ยงยิ่งสูง:

• Bus Factor = 1 → คือสถานการณ์เลวร้ายที่สุด ความรู้ทั้งหมดกระจุกอยู่กับคนเดียว ถ้าคนนั้นหายไป โปรเจกต์หยุด
• Bus Factor = 3 → ต้องสูญเสียคน 3 คนพร้อมกันถึงจะมีปัญหา ทีมยืดหยุ่นกว่ามาก

😱 ความเสี่ยงที่ใกล้ตัวกว่าที่คิด#

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

คำถามที่ควรถามตัวเองตอนนี้คือ: ถ้าคนที่รู้เยอะที่สุดในทีมไม่มาพรุ่งนี้ ทีมจะติดขัดที่ไหน?

🧮 วิธีคำนวณ Bus Factor#

วิธีที่ใช้กันในงานวิจัยและเครื่องมือจริงคือ Iterative Removal โดยวิเคราะห์จากประวัติ Git:

1. ดูว่าแต่ละคนเป็น “เจ้าของความรู้” ของไฟล์ไหนบ้าง (ผ่าน commit history ทั้งในระดับไฟล์และระดับบรรทัด)
2. ลบคนที่มีความรู้มากที่สุดออกทีละคน
3. หยุดเมื่อความรู้ที่เหลือครอบคลุมโปรเจกต์ได้น้อยกว่าครึ่งหนึ่ง
4. จำนวนคนที่ลบออกไปแล้ว = Bus Factor

เช่น ถ้าลบ Alice ออกไปแล้วทีมยังทำได้อยู่ แต่พอลบ Bob ออกด้วย ความรู้ก็หายไปเกินครึ่ง — Bus Factor ของโปรเจกต์นี้คือ 2

มีเครื่องมือ open source หลายตัวที่คำนวณตัวเลขนี้จาก Git repository ได้โดยตรง เช่น aserg-ufmg/Truck-Factor ↗ หรือ bus-factor-explorer ↗ — แม้การคำนวณที่แม่นยำสมบูรณ์แบบจะซับซ้อนมากในทางทฤษฎี แต่ Iterative Removal เป็นวิธีประมาณที่ใช้งานได้จริงสำหรับทีมส่วนใหญ่

ถ้าอยากลองเร็ว ๆ โดยไม่ต้องติดตั้งอะไร คำสั่งนี้ช่วยดูได้ว่าใครอยู่เบื้องหลังไฟล์ไหนบ้าง:

git log --format='%an' -- <file> | sort | uniq -c | sort -rn

Output จะเรียงชื่อตามจำนวน commit — ใครที่มี commit สูงกว่าคนอื่นอย่างเห็นได้ชัด ไฟล์นั้นคือจุดเสี่ยง

🌱 Bus Factor ต่ำเกิดได้อย่างไร#

ไม่ได้เกิดจากใครตั้งใจซ่อนความรู้ แต่เกิดจากรูปแบบการทำงานที่สะสมกันมา:

• คนเดิมรับงานซ้ำ ๆ เพราะทำได้เร็วและรู้ระบบดี
• ไม่มีเวลา document งานด่วนทุกวัน ไม่มีใครมานั่งเขียน wiki
• ทีมเล็ก คน 2-3 คนแบ่งงานตามสาย แต่ละคนรู้ส่วนตัวเองลึก แต่ไม่รู้ส่วนอื่นเลย
• ความรู้อยู่ในหัว ไม่ได้อยู่ในโค้ด comment หรือ documentation

ผลลัพธ์คือเราได้ “กูรู” ประจำทีม — คนที่ทุกอย่างต้องถามผ่านคนคนนั้นก่อน ซึ่งกลายเป็นทั้ง bottleneck ของทีม และจุดเสี่ยงที่ใหญ่ที่สุดในเวลาเดียวกัน

📈 วิธีเพิ่ม Bus Factor#

ไม่จำเป็นต้องทำทุกอย่างพร้อมกัน เริ่มจากที่เห็นผลชัดก่อน:

Pair Programming และ Code Review อย่างจริงจัง ไม่ใช่แค่ approve ผ่าน ๆ — reviewer ควรเข้าใจจริง ๆ ว่าโค้ดทำงานอย่างไร และทำไมถึงเลือกวิธีนั้น ๆ การ review อย่างมีส่วนร่วมช่วยกระจายความเข้าใจได้ดีมาก

Rotation ความรับผิดชอบ สลับคนดูแล module บ้าง แม้จะช้าลงในช่วงแรก แต่ช่วยให้ความรู้ไม่ผูกติดกับคนคนเดียว ทีมหนึ่งที่ลอง rotate oncall ทุก sprint พบว่าภายใน 2 เดือน คนที่ไม่เคยแตะ infra เริ่ม debug production ได้เอง

Documentation ที่ใช้จริง ไม่ต้องเขียน document ยาว แค่ Architecture Decision Record (ADR) สั้น ๆ ก็ช่วยได้มาก ตัวอย่างเช่น:

# ADR-001: ใช้ Redis สำหรับ session cache
บริบท: ต้องการ shared session ระหว่าง service หลายตัว
การตัดสินใจ: ใช้ Redis เพราะ latency ต่ำและ team มีประสบการณ์อยู่แล้ว
ผลที่ตามมา: ต้อง maintain Redis instance แยกต่างหาก

Onboarding ที่ดี เวลาสมาชิกใหม่เข้ามา ให้รับผิดชอบส่วนที่ยังไม่มีใครถ่ายทอดความรู้ไว้ — วิธีนี้จะช่วยให้ทีมเห็นช่องว่างของความรู้ได้เร็วขึ้น

⏰ เมื่อไหร่ควรสนใจ Bus Factor มากเป็นพิเศษ#

• ก่อนรับ project สำคัญ — ทีมพร้อมรับความเสี่ยงไหมถ้าคนหลักออกกลางทาง?
• ก่อนคนในทีมลาออก — ควรมี knowledge transfer อย่างน้อยสัก 2-4 สัปดาห์
• ตอน scale ทีม — คนใหม่ควรได้รับความรู้จริง ๆ ไม่ใช่แค่ task ที่ทำตามได้
• หลังโปรเจกต์ใหญ่เสร็จ — retrospect ว่าความรู้กระจายพอไหม

⚠️ ข้อจำกัดที่ควรรู้#

Bus Factor เป็นตัวเลขที่มีประโยชน์ แต่ไม่ใช่ทุกอย่าง:

• วัดแค่จำนวน ไม่ใช่คุณภาพ คน 3 คนที่รู้แค่ผิวเผินอาจสู้คนรู้ลึก 1 คนไม่ได้ แต่ตัวเลข Bus Factor ไม่ได้บอกความแตกต่างนี้
• Git history ไม่ใช่ทั้งหมด ความรู้บางอย่างอยู่ใน Slack thread เก่า ๆ หรือในหัวคน ซึ่งไม่ปรากฏใน commit เลย
• ไม่ได้บอกว่าส่วนไหนเสี่ยง Bus Factor 1 อาจเกิดจาก module เล็ก ๆ ที่ไม่ critical หรือจาก core system ก็ได้

ตัวเลขนี้จึงเหมาะมองเป็น สัญญาณเตือน มากกว่าคำตัดสิน แล้วใช้เป็นจุดเริ่มต้นของการพูดคุยในทีมว่า “ส่วนไหนที่เราเสี่ยงที่สุด?”

📝 สรุป#

Bus Factor คือตัวชี้วัดที่ตรงไปตรงมา: ทีมต้องสูญเสียคนกี่คนก่อนที่ทุกอย่างจะหยุดชะงัก?

ตัวเลขนี้ไม่ได้บอกว่าคนในทีมไม่เก่ง แต่บอกว่าความรู้ในองค์กรกระจายดีแค่ไหน และตัวเลขนี้เตือนเราก่อนที่ความเสี่ยงจะกลายเป็นปัญหาจริง ๆ

ถ้าอยากลองวัด Bus Factor ของทีมตัวเอง เริ่มจากคำถามง่าย ๆ ก็ได้: “ถ้าคนที่รู้เยอะที่สุดไม่มาพรุ่งนี้ ทีมจะติดขัดที่ไหน?” — คำตอบนั้นคือจุดที่ต้องลงทุนความรู้ก่อน

ทีมที่ดีไม่ใช่ทีมที่มี rockstar คนเดียวทำได้ทุกอย่าง แต่คือทีมที่ทุกคนรู้พอที่จะช่วยกันประคองงานต่อได้ แม้จะขาดใครไปก็ตาม

😎 ☕