หลายโครงการเวลาเกิดปัญหา หรือทีงสนอะไรที่ยาก และท้าท้าย มันมักจะฮีโร่เข้ามาเป็นควาทหวังของหมู่บ้าน ความหวังของทีมในการแก้ปัญหา แต่ถ้าทุกๆโครงการดันมีฮีโร่เป็นคนเดียวกันหมดหละ !!!!
มันเหมือนอย่างหนัง หรือ การตูนทั่วไปแหละพอมีฮีโร่เพียง 1 คนทุกปัญหาย่อมเกิดขึ้น หากฮีโร่คนนั้นไม่สามารถมาทำงานได้ เห็นไหมว่าเราต้องทีม ทีมอย่าง Avenger เข้ามาร่วมจัดการเหล่าร้าย
ใช่ครับ คนเดียวหัวหาย เป็นทีมดีกว่าครับ จากความหวังหมู่บ้านทำให้ทีมมีจุดแข็ง ก็จะกลายเป็นว่าคนนั้นเป็นจุดศูนย์รวมแห่งความชิบหาย (Single Point of Failure) ด้วยเช่นกันครับ

กลับมาที่ Bus Factor หรืออีกชื่อว่า Truck Factor กันดีกว่า โดยตัว Bus Factor มัน คือ ตัวเลขที่เอาไว้ประเมินความเสี่ยงของโครงการครับ ถ้าฮีโร่คนนั้นหายไป จะมีใครมารับช่วงสายต่องานได้หรือไม่ครับ ทีมสามารถเสียคนได้เท่าไหร่ตัวโครงการถึงหยุดชะงักไปต่อไม่ได้ครับ มันเหมือนระเบิดเวลาดีๆแหละครับ ถ้า Bus Factor ยิ่งน้อยยิ่งเสี่ยงครับ ตัวอย่าง เช่น เรามีทีมทำ Start Up ด้าน FinTech โดยมีทีมทั้งหมด 5 คน แล้วเรากำหนด Bus Factor = 2 นั่นแสดงว่าถ้าเสียลูกทีมไป 2 คน ตัว Start Up ที่ทำอยู่ก็จะมีปัญหา ไม่สามารถดำเนินงานต่อได้ครับ (เคสนี้ถ้าจะให้ดี Bus Factor ควรเป็น 5 ครับ นั่นแสดงว่าทุกคนสามารถทำงานแทนกันได้หมดเลย)
แต่เนื่องจากหลาย Project ประกอบด้วยหลายหน่วยงานครับ บางทีอาจจะต้องประเมิน Bus Factor แยกตามหน่วยครับ เช่น BA / DEV / QA เป็นต้นครับ
แล้วจะป้องกันความเสี่ยงอย่างไร
- Cross Functional Team - จัดให้คนในทีมสามารถทำงานแทนกันได้ครับ เช่น DEV-QA, BA-QA, PM-QA เป็นต้นครับ
- Pair Programming - คู่คิดคู่ทำครับ
- Communicate & Sharing อันนี้ไม่จำเป็นต้องมาจัดประชุมทีมให้ยิ่งใหญ่อลังการครับ ค่อยๆทำทีละนิดก็ได้ครับ
- เขียน Automate Unit Test
- เขียน Comment / เอกสาร / วาด Diagram ในส่วนที่มันซับซ้อน
- Peer-Review เพื่อทำให้คุ้นชินกับ Business / Code / Test Case
ของพวกนี้ในโครงการอาจจะบอกว่ามันเสียเวลา แต่ตอน MA แล้ว มันมีค่ายิ่งกว่าเพชรครับ
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.