#Engineering Leader — Bus factor คืออะไร?
Bus factor ในวิศวกรรมซอฟต์แวร์ หมายถึง เราเสียจำนวนบุคคลได้เท่าไหร่ ก่อนที่โครงการหรือทีมซอฟต์แวร์จะไม่สามารถไปต่อได้ เป็นการวัดปริมาณความเสี่ยงที่เกี่ยวข้องกับการที่ทีมต้องพึ่งพาบุคคลสำคัญเพียงไม่กี่คน
ซึ่งมันมาจากวลี “in case they get hit by a bus” ในกรณีที่พวกเขาถูกรถบัสชนและต้องไปรักษาตัว คนที่เหลือสามารถสานต่องานได้หรือไม่
ลองจินตนาการ เหตุการณ์ต่อไปนี้
- ทีมไปต่อได้ไหม หาก senior / lead ทีมลา ไม่อยู่ หรือ ติดโปรเจคเร่งด่วน
- ถ้า keyman ของทีม จำเป็นต้องลาออก
bus factor ของทีมเรา… เป็นยังไงบ้าง?
Bus factor วัดกันยังไงบ้าง?
ตัวเลขยิ่งน้อย ยิ่งเสี่ยงสูงครับ
ตัวอย่าง… ถ้าเรามี 10 software engineers ในทีม และ bus factor = 1 หมายความว่า ถ้าเราขาดสมาชิก 1 คนไป ซึ่งเป็น key-man สำคัญของทีมเลย ทีมไปต่อกันเองไม่ได้
สิ่งนี้สะท้อน ได้ถึง การบริหารจัดการทีมที่ไม่ดี ความรู้ไม่ได้กระจายไปทุกๆคน ทีมไม่สามารถทำงานแทนกันได้ ถ้าขาดคนสำคัญไป
Bus factor สัมพันธ์กับ High-Performing Engineering ยังไงได้บ้าง?
🆘 วิธีการวัดความยืดหยุ่นของทีมพัฒนาซอฟต์แวร์ ยิ่งบัสแฟกเตอร์ต่ำ ทีมก็ยิ่งเสี่ยงที่จะสูญเสียบุคคลสำคัญและทำให้กระบวนการพัฒนาหยุดชะงัก
✅ ในทางกลับกัน ยิ่งบัสแฟกเตอร์สูง ทีมก็จะแข็งแกร่งมากขึ้นในการรับมือกับการหยุดชะงักดังกล่าว
Bus factor ตัวเลขน้อยบ่งบอกอะไร?
- ทีมยังไม่พร้อมสำหรับ cross-functional team
- ทีมยังต้องพึ่งพาฮีโร่บางคนในทีมอยู่มากเกินไป
- workload กระจุกอยู่ที่คนใด คนนึงมากไป
- ทีมยังไม่ได้เตรียมสำหรับการสเกลเรื่องคน
- ยังมี single point of failure อยู่ในเรื่องการจัดการทีมงาน องค์ความรู้ที่กระจุกตัว
เราทำซอฟท์แวร์ยังมองเรื่อง resiliency, no single point of failure ทีมงานก็เช่นเดียวกันครับ
แล้วถ้าเราต้องการปรับปรุงให้ bus factor กลับมาดีขึ้นจะทำยังไงได้บ้าง?
(1) Collective Code Ownership
สร้างความเป็นเจ้าของโค๊ดภายในทีม เริ่มตั้งแต่กำหนด naming convention / project structure / linter rules / standard coding ร่วมกัน การมีกิจกรรมนี้จะทำให้ทุกคนตระหนัก และรู้สึกว่าได้ร่วมกำหนดแนวทางที่ทีมจะไปด้วยกันตั้งแต่เริ่มแรก
อีกวิธีการนึงที่ผมเคยทำผ่านมา นั่นคือ การทำ monorepo ซึ่งข้อดีการใช้รูปแบบนี้ในการจัดเก็บ source code คือ ทุกคนจะเห็นโค๊ดของกันและกัน ตั้งแต่เริ่มเปิด pull request, approve, merge เข้า main branch และถ้าเกิดข้อผิดพลาดใดๆ ทั้งทีมก็จะไปต่อไม่ได้ต้องช่วยกันแก้ (แต่มันก็อาจจะมีข้อเสียที่ทำให้ทีมต้องหยุดมาดูกัน)
(2) Pair Programming / Peer Review
ผมมักแนะนำทีมให้ลองใช้เทคนิค driver and navigator ระหว่าง senior / junior เพราะ นอกจากจะเป็นการถ่ายทอดความรู้ที่ไวที่สุดแล้ว ยังเป็นการช่วย ice-breaking กับสมาชิกใหม่ที่เข้ามาในทีม ให้ซึมซับ culture วิธีการทำงานของทีมอีกด้วย หรือ หาก pair ไม่ได้ ก็ให้ใช้เทคนิค peer review กันเลยเพื่อให้เพื่อนในทีมดูว่าโค๊ดเรา healthy ดีไหม ซึ่งก็เป็นวิธี code sharing ที่ได้ผลดีเหมือนกัน
(3) Code Review
เชื่อว่าทำกันอยู่แล้วเรื่องการรีวิวโค๊ดก่อน merge ของเข้า main branch แต่พบว่าหลายที่ ไม่มีการกำหนด good practice สำหรับเรื่องนี้ เช่น pull request ที่ใหญ่เกินไป หลาย context อยู่ใน 1 pull request หรือ แม้กระทั่ง คนรีวิวไม่ได้ให้คำแนะนำจุดที่ต้อง improve ว่า ทำไม ถึงต้องแก้ ถ้าไม่แก่จะเกิดผลกระทบอะไรบ้าง
(4) Communication
เราเขียนโค๊ดเพื่อให้คนอ่าน ไม่ใช่ให้ machine อ่าน ดังนั้นเรื่องของ readability, clarity สำคัญมากๆ ก่อน delivery code ออกไป แต่ก็ต้องดูด้วยว่า ถ้าเราพยายามจะ DRY ทุกอย่างมากไปตั้งแต่วันแรก อาจจะไม่สามารถ deliver items ใดๆออกมาได้ทันเวลาเลย
แนะนำเรื่อง make it work, make it right and make it faster ครับ
(5) Re-assign
ทีมที่ดี คือ ทีมที่สามารถสร้าง high trust engineering ได้ นั่น คือ ความเชื่อใจในคนๆนั้นให้ขึ้นมาเป็น feature lead การ re-assign คือ การสร้างพื้นที่ปลอดภัยให้คนที่ไม่เคยลีด ขึ้นมาลองทำดู อาจจะเริ่มจากงานเล็กๆ เพื่อให้ได้เรียนรู้ว่า นอกจากการ deliver code / solutions แล้ว ยังมีงานอื่นๆประกอบด้วย ซึ่งกระบวนการตรงนี้ คนที่ไม่เคยลีดจะได้เรียนรู้ จากคนที่เคยลีด เกิดการพูดคุย และ แลกเปลี่ยนประสบการณ์กัน
โดยปกติแล้วโปรเจคต้องอาศัยฮีโร่ 1–2 คน เพื่อให้โปรเจคไปต่อได้ ในทางกลับกันบริษัทต้องเตรียมพร้อมสำหรับการลาออกหรือลางาน เพราะ ถ้าขาดฮีโร่ไปมูลค่าความเสียหายของโปรเจคมีมากแน่นอน ดังนั้น การใช้เทคนิคนี้ ฮีโร่ สร้าง ฮีโร่ขึ้นมาใหม่ ก็เป็นเทคนิคที่ไม่เลวทีเดียว
หรือ การให้คนที่เป็น domain expert ได้ลองทำงานพื้นที่ใหม่ๆ และในขณะเดียวกันก็เป็นผู้ถ่ายทอดให้กับคนใหม่ที่มาช่วยดูแล domain นั้นๆ
(6) Automated
- unit test
- APIs testing
- performance testing
- UI / End-to-End
เมื่อเกิด automation culture นั่นหมายความว่า เราสามารถลด manual work ที่ความรู้อาจจะผูกติดกับคนใดคนนึงออกไปได้แล้ว ซึ่งก็สามารถรันผ่าน CI/CD ได้เองเลย โดยที่ทีมสามารถไปต่อด้วยตัวเองได้
(7) Good Documentation
Service หรือ โปรเจคไหน ไม่มี document ก็เหมือนเราเดินแบบไม่มีแผนที่นำทาง ต่อให้เราออกแบบระบบสเกลได้ โค๊ดทำงานได้ดี อ่านง่าย แต่ถ้าไม่มีเอกสารเลย คนที่มาดูแลต่อ ก็เริ่มต้นได้ยากอยู่ดี ดังนั้นสิ่งนี้ยังจำเป็นอยู่ แค่จัดสรรเวลาให้เหมาะสมว่า เอกสารเราจะมาเพิ่มตามทีหลังได้ ไม่ใช่ไม่ทำเลย และที่สำคัญหมั่นอัพเดตอยู่เสมอ โดยเฉพาะพวก Architecture / API Spec และส่วนสำคัญที่มี dependencies กับข้างนอกโดเมน
(8) Good engineering culture
โดยส่วนตัวชอบแนวคิด เมื่อไม่เห็นด้วย ให้ลงมือทำให้เห็น ไปด้วยกัน เพราะ ระหว่างทาง เราจะได้เรียนรู้ไปด้วยกัน ลองผิด และ ลองถูก ไปด้วยกัน เกิดการแชร์ การช่วยเหลือกัน โดยมีเป้าหมาย เป็นตัวนำทาง
(9) Knowledge Sharing
- technical knowledge sharing
- code-walkthrough
- mini-workshop
- FAQ
นอกจากนี้ยีงมีหลายเทคนิคมากที่น่าทำ เพื่อป้องกันปัญหา low bus factor ลงได้ครับ
- Be clear and visibility task
- On-call rotations
- Engineering demos
- lunch and learn
- write technical blog
สุดท้ายอยากเสริมเรื่อง 4 Pillar ของ Simon Zinek
การสร้าง High-Trust team จะประกอบด้วย 4 ปัจจัยหลัก ได้แก่
- Safety เมื่อทุกคนรู้สึกปลอดภัยในที่ทำงาน เค้าก็กล้าจะทดลองอะไรใหม่ๆ มากกว่าขอบเขตที่ตัวเองเคยทำ
- Dependability ทีมที่ดี ต้องพึ่งพากันได้ ช่วยเหลือกันได้ ข้อนี้ลิงค์ตรงกับเรื่อง bus factor เลย
- Competence ทีมที่ดีรายล้อมไปด้วยคนที่มีความสามารถ ซึ่งก็มีโปรเซสตั้งแต่รับคนเข้ามา รักษาคนที่อยู่ข้างใน และ เติบโตไปด้วยกัน
- Character ทีมที่มีลักษณะเฉพาะจะคอยห้ามปรามและพูดคุยกันอย่างตรงไปตรงมาว่าอันไหนดี อันไหนไม่ควรทำ
หวังว่าบทความนี้จะช่วยให้ทีมของทุกคน ได้กลับมาคุยวิธีป้องกันปัญหา bus factor ที่อาจจะเกิดขึ้นลงไปได้ครับ
References
