ศัพท์แปลก ๆ ในทีม software — bus factor, rubber duck, blameless postmortem และอื่น ๆ ที่น่าสนใจ
ถ้าเคยได้ยินคนในทีมพูดถึง bus factor, rubber duck หรือ bikeshedding แล้วงง — บทความนี้รวบรวมศัพท์พวกนี้ไว้พร้อมว่าแต่ละคำมีไว้ทำอะไร
วันแรกที่เข้าทีมใหม่ มีคนพูดว่า “bus factor ของ module นี้เป็น 1 นะ อันตรายมาก” แล้วทุกคนก็พยักหน้า — ยกเว้นเราคนเดียวที่ไม่รู้ว่า bus เกี่ยวอะไรกับโค้ด
วงการ software มีศัพท์แปลก ๆ เยอะ บางคำฟังดูไม่เป็นทางการ แต่ซ่อนแนวคิดที่จริงจังไว้ข้างใน รู้จักคำพวกนี้ไว้ไม่ใช่แค่เพื่อตามทัน — แต่เพราะคำแต่ละคำช่วยให้ทีมคุยเรื่องยาก ๆ ได้เร็วขึ้น
🚌 Bus Factor — ถ้าคนคนนี้หายไป จะเกิดอะไร?#
Bus factor คือจำนวนคนในทีมที่น้อยที่สุดที่ถ้าหายไปพร้อมกันแล้วโปรเจกต์จะเดินหน้าต่อไม่ได้ ฟังดูโหดร้าย แต่นั่นแหละคือจุดประสงค์ — ให้เรานึกภาพสถานการณ์เลวร้ายที่สุดไว้ก่อนที่มันจะเกิดขึ้นจริง
Bus factor เท่ากับ 1 แปลว่ามีคนแค่คนเดียวที่รู้ว่าโค้ดส่วนนั้นทำงานยังไง ถ้าคนนั้นลาออก ป่วย หรือย้ายทีม — งานทั้งหมดก็หยุดนิ่ง
ความเข้าใจผิดที่พบบ่อย: หลายคนคิดว่า bus factor วัดความเก่งของคน — จริง ๆ แล้วมันวัด การกระจายความรู้ในทีม ต่างหาก คนเก่งที่สุดในทีมอาจกลายเป็นจุดเดียวที่ถ้าหายไปก็พังทั้งระบบ ถ้าไม่มีการจดบันทึกหรือสอนต่อให้คนอื่นไว้ วิธีแก้คือการจับคู่กันเขียนโค้ด (pair programming), การรีวิวโค้ดร่วมกัน และการทำเอกสารเก็บไว้ — ไม่ใช่การไปหาคนเก่งมาแทน
บางทีก็เรียกว่า lottery factor สำหรับกรณีที่คนออกไปด้วยเหตุผลดี ๆ เช่น ถูกหวย หรือได้งานในฝัน
🦆 Rubber Duck Debugging — อธิบายให้ตุ๊กตาฟัง#
ชื่ออาจฟังดูขำ แต่เทคนิคนี้มีคำอธิบายว่าทำไมถึงได้ผล
Rubber duck debugging คือการอธิบายโค้ดทีละขั้นตอนออกมาดัง ๆ ราวกับอธิบายให้คนอื่นฟัง โดยไม่ต้องให้ “ผู้ฟัง” ตอบอะไรกลับมาเลย ตุ๊กตายางเป็นแค่ตัวแทน — จะใช้ตุ๊กตาหมี แมว หรือแม้แต่เพื่อนที่ไม่รู้เรื่องการเขียนโปรแกรมก็ได้
ทำไมถึงได้ผล? เพราะการพูดออกมาดัง ๆ บังคับให้สมองเรียบเรียงภาพความเข้าใจในหัวให้เป็นระเบียบมากขึ้น สมองต้องจัดความคิดที่กระจัดกระจายให้เป็นลำดับ และระหว่างนั้นเองที่มักพบว่าสิ่งที่คิดว่าถูกมาตลอด — จริง ๆ แล้วผิด
เทคนิคนี้ใช้ได้กว้างกว่าแค่การแก้ bug — ลองอธิบายโค้ดให้ตัวเองฟังก่อนส่ง PR หรือใช้ตอน standup เพื่อไล่ดูปัญหาที่ค้างอยู่ก็ได้ผลเหมือนกัน ถ้าเริ่มอธิบายแล้วสะดุดหรืออธิบายไม่ได้ — นั่นแหละคือจุดที่ bug ซ่อนอยู่
🤝 Blameless Postmortem — เรียนรู้จากความผิดพลาดโดยไม่โทษใคร#
ระบบล่มช่วง traffic สูงสุด ทุกคนรู้ว่า deployment ล่าสุดเป็นตัวการ และทุกคนรู้ว่าใครเป็นคน deploy — จากนั้นจะเกิดอะไรขึ้นในทีมของคุณ?
Blameless postmortem คือกระบวนการทบทวนเหตุการณ์ที่ระบบมีปัญหา โดยมุ่งหาต้นตอที่แท้จริงและปรับปรุงระบบ ตั้งต้นด้วยสมมติฐานว่าทุกคนมีเจตนาดีและทำดีที่สุดแล้วด้วยข้อมูลที่มีในตอนนั้น แนวคิดนี้มาจากวงการแพทย์และการบินที่ความผิดพลาดมีผลถึงชีวิต
ข้อดีหลักคือมันสร้างบรรยากาศที่คนกล้าพูดความจริงโดยไม่กลัวโดนลงโทษ — เมื่อไม่ต้องกลัวถูกตำหนิ คนจะแจ้งปัญหาตั้งแต่เนิ่น ๆ ไม่ปิดบังความผิดพลาด และเรื่องที่เกิดกับทีมหนึ่งก็กลายเป็นบทเรียนร่วมกันของทั้งองค์กร
สำหรับทีมที่อยากเริ่มทำ postmortem โครงสร้างที่ใช้ได้จริงควรมี: ลำดับเหตุการณ์ ว่าเกิดอะไรขึ้นบ้าง, ปัจจัยที่ทำให้เกิดเรื่อง, และ สิ่งที่จะลงมือแก้ ที่ระบุชัดว่าใครทำอะไรภายในเมื่อไหร่ — เพื่อให้ไม่จบแค่การพูดคุย แต่นำไปสู่การแก้ระบบจริงๆ
แต่มีความเข้าใจผิดที่ต้องระวัง: blameless ไม่ได้แปลว่าไม่มีความรับผิดชอบ ยังต้องระบุว่าอะไรผิดพลาด และใครจะเป็นคนแก้ระบบ แค่ไม่ตอกย้ำว่าใครทำให้เกิดขึ้น
แต่บางคนก็แย้งว่า “การไม่โทษใครเลย” อาจเป็นแค่อุดมคติที่ทำได้ยากในความเป็นจริง เพราะคนเรามีสัญชาตญาณอยากหาคนผิดติดตัวมาอยู่แล้ว และพอเรารู้แล้วว่าเรื่องจบลงยังไง เราก็มักรู้สึกย้อนหลังว่า “ก็เห็น ๆ อยู่ว่าต้องพังแบบนี้ ทำไมไม่ระวังตั้งแต่แรก” ทั้งที่ตอนนั้นมันไม่ได้ชัดขนาดนั้น — ความรู้สึกแบบนี้แหละที่ทำให้เราเผลอโทษคนโดยไม่รู้ตัว เลยมีคนเสนอคำว่า blame-aware (รู้เท่าทันว่าเรากำลังอยากโทษ) แทน คือยอมรับไปเลยว่าความอยากโทษมันมีจริง แล้วตั้งใจคุมมันไว้ ดีกว่าแกล้งทำเป็นว่าไม่มี
🚲 Bikeshedding — ประชุมสามชั่วโมงเรื่องชื่อ variable#
ทุกคนในทีมเคยเจอ: ประชุมที่ควรจะคุยเรื่องโครงสร้างระบบ แต่กลับใช้เวลาครึ่งชั่วโมงถกเถียงว่าจะตั้งชื่อ endpoint ว่า /users หรือ /user
Bikeshedding คือการที่ทีมหมดเวลาไปกับเรื่องเล็กน้อยที่ทุกคนออกความเห็นได้ง่าย แทนที่จะโฟกัสกับเรื่องใหญ่ที่ซับซ้อนกว่า เรื่องที่ถูก bikeshed บ่อยที่สุดคือ code style การตั้งชื่อ และสีของปุ่ม — ในขณะที่เรื่องใหญ่อย่างช่องโหว่ด้านความปลอดภัยหรือการตัดสินใจเรื่องโครงสร้างระบบ กลับผ่านการรีวิวไปอย่างรวดเร็ว
รู้จักคำนี้ไว้มีประโยชน์มากในที่ประชุม — เมื่อสังเกตว่าทีมกำลัง bikeshed อยู่ ก็พูดตรง ๆ ได้เลยว่า “เราอาจกำลัง bikeshed เรื่องนี้อยู่นะ ย้ายไปคุยเรื่องสำคัญกว่าไหม”
🐂 Yak Shaving — ลืมไปแล้วว่าตั้งใจจะทำอะไร#
ตั้งใจจะเพิ่ม feature เล็ก ๆ แต่ก่อนจะทำได้ต้อง update dependency ก่อน update dependency ต้อง upgrade Node ก่อน upgrade Node ต้องแก้ config ก่อน แก้ config ต้อง request permission ก่อน… และสองชั่วโมงต่อมายังไม่ได้เริ่ม feature นั้นเลย
Yak shaving คือ งานย่อยที่พ่วงกันมาเป็นทอด ๆ เหมือนโดมิโน (cascade) ที่ต้องเคลียร์ให้หมดก่อนจะได้ลงมือทำงานหลักจริง ๆ
Yak shaving มีสองประเภทที่ต่างกันมาก:
- Necessary annoyance — งานที่พ่วงกันมาเป็นทอด ๆ ของ dependencies ที่หลีกเลี่ยงไม่ได้จริง ๆ ต้องทำให้เสร็จ
- Procrastination — เอางานย่อยพวกนี้มาเป็นข้ออ้างเพื่อหลบงานหลักที่ไม่อยากทำ
รู้จักสองแบบนี้ไว้ช่วยให้ถามตัวเองได้ว่า — งานที่กำลังทำอยู่นี้จำเป็นจริง ๆ หรือเราแค่ไม่อยากเผชิญกับงานหลักกันแน่? ถ้างานเริ่มพ่วงกันลึกเกิน 2 ชั้น ให้หยุดแล้วถามตัวเองว่างานหลักคืออะไร แล้วค่อยตัดสินใจว่า dependency ไหนจำเป็นจริง ๆ
💳 Technical Debt — หนี้ที่มีดอกเบี้ย#
Technical debt คือต้นทุนที่จะงอกขึ้นในอนาคตจากการเลือกทางที่เร็วในวันนี้ คำนี้เปรียบได้กับการกู้เงิน: ทำให้เสร็จเร็วขึ้นในวันนี้ แต่ต้องจ่าย “ดอกเบี้ย” ในรูปของความยากในการแก้หรือเพิ่ม feature ในภายหลัง
ตัวเลขจริงที่น่าตกใจ: ผลสำรวจหนึ่งในปี 2018 พบว่า 42% ของเวลา developer หมดไปกับ technical debt และโค้ดคุณภาพแย่รวมกัน และอีกผลสำรวจในปี 2020 ที่สอบถามผู้บริหารสายเทคโนโลยีจากบริษัทใหญ่ พบว่า technical debt คิดเป็น 20–40% ของมูลค่าสินทรัพย์ทางเทคโนโลยีก่อนหักค่าเสื่อม
สิ่งสำคัญที่ต้องเข้าใจคือ — technical debt ไม่ได้แย่เสมอไป เหมือนการกู้เงินที่มีเหตุผล ปัญหาคือการสะสมหนี้ไว้โดยไม่มีแผนจ่ายคืน ทีมที่จัดการหนี้ได้ดีมักทำบัญชีไว้ว่ามีหนี้อยู่เท่าไหร่ (debt register) และจัดรอบเวลามาตามเก็บล้างหนี้เป็นประจำ (debt sprint) แทนที่จะปล่อยให้สะสมจนแก้ไม่ได้
👍 LGTM — อนุมัติไว ไม่ได้แปลว่าดี#
LGTM ย่อมาจาก “Looks Good To Me” — ใช้ตอนรีวิวโค้ดเพื่อบอกว่า reviewer เห็นชอบให้ merge PR ได้ สั้น สะดวก และกลายเป็นคำที่ทีมส่วนใหญ่ใช้กันจนเป็นมาตรฐานไปโดยปริยาย
แต่ LGTM ที่มีคุณค่าจริง ๆ ควรมาหลังจากที่ automated tests ผ่าน, สแกนความปลอดภัยผ่าน, และคอมเมนต์ที่ค้างอยู่ถูกเคลียร์หมดแล้ว — ไม่ใช่กดเพราะไม่อยากเป็นคนขัดขวางงานนั้น ๆ
LGTM แบบอนุมัติแบบขอไปทีโดยไม่ได้ดูจริง ๆ คือหนึ่งในช่องทางที่ bug แอบเข้าไปอยู่บน production ได้ง่ายที่สุด
🏛️ Conway’s Law — โครงสร้างทีมกำหนดโครงสร้างซอฟต์แวร์#
“องค์กรที่ออกแบบระบบ มักสร้างระบบที่มีหน้าตาเหมือนกับโครงสร้างการสื่อสารขององค์กรนั้นเอง”
Conway’s Law บอกว่าโครงสร้างของซอฟต์แวร์มักสะท้อนโครงสร้างการสื่อสารขององค์กรที่สร้างมันขึ้นมา
ตัวอย่างที่มักถูกยกมา: บริษัทที่จัดทีมเป็นหน่วยเล็ก ๆ ที่ดูแลบริการของตัวเองแบบเบ็ดเสร็จ ก็มักได้สถาปัตยกรรมแบบ microservices ที่แยกส่วนกันชัดเจนตามมา
แนวคิดที่น่าสนใจกว่าคือ Inverse Conway Maneuver — แทนที่จะปล่อยให้โครงสร้างทีมไปกำหนดสถาปัตยกรรมเอง ก็จงใจปรับโครงสร้างทีมก่อนเพื่อให้ได้สถาปัตยกรรมที่ต้องการ แนวคิดนี้ถูกนำไปใช้จริงในองค์กรที่อยากย้ายจาก monolith ไปเป็น microservices โดยเริ่มจากการแบ่งทีมก่อนแบ่งโค้ด
🐕 Dogfooding — กินอาหารที่ตัวเองทำ#
Dogfooding หรือ “eating your own dog food” คือการที่บริษัทใช้ผลิตภัณฑ์ของตัวเองในการทำงานจริง เพื่อทดสอบและเข้าใจประสบการณ์ของผู้ใช้ก่อนปล่อยให้ลูกค้าใช้
ประโยชน์จริง ๆ คือได้ฟีดแบ็กกลับมาเร็ว — คนที่ใช้ผลิตภัณฑ์ของตัวเองทุกวันจะเจอจุดที่ใช้แล้วสะดุดและ bug ที่ผู้ใช้จะเจอ ได้เร็วกว่ารอบทดสอบของ QA ปกติมาก ในทางกลับกัน ถ้าคนในทีมเองยังไม่อยากใช้ผลิตภัณฑ์ของตัวเอง นั่นคือสัญญาณที่น่าเป็นห่วงมาก
ข้อควรระวังคือคนในทีมมีมุมมองต่างจากผู้ใช้จริงเสมอ — รู้ว่าอะไรอยู่ตรงไหน คุ้นกับขั้นตอนที่คนทั่วไปอาจสะดุด ทำให้ยังมีจุดบอดบางอย่างหลงเหลืออยู่ ถึงจะ dogfood อย่างจริงจังแล้วก็ตาม
🚀 10x Developer — ตำนานหรือความจริง?#
แนวคิดว่ามี developer บางคนที่ทำงานได้มากกว่าคนอื่น 10 เท่า ปรากฏในงานวิจัยตั้งแต่ปี 1968 และยังเป็นที่ถกเถียงจนถึงทุกวันนี้
สิ่งที่งานวิจัยพบจริง ๆ: งานวิจัยต้นทางที่อ้างถึง 10x developer ทำในยุคที่เทคโนโลยีเก่ามาก กลุ่มตัวอย่างก็เล็กมาก และความแตกต่างของผลงานในแต่ละครั้งของคนคนเดียวกัน ยังมากกว่าความแตกต่างระหว่างคนแต่ละคนเสียอีก
ถ้ามี developer ที่ “10x จริง ๆ” ในทีม สาเหตุมักมาจากการฝึกฝนสะสม การมองออกไวว่าปัญหาแบบนี้เคยเจอมาก่อน และความเชี่ยวชาญสภาพแวดล้อมที่ทำงาน — ไม่ใช่ความเร็วในการพิมพ์หรือพรสวรรค์ติดตัว
แต่ที่น่าคิดกว่าคือ การมี 10x developer แค่คนเดียวในทีมมักเป็นสัญญาณของปัญหาในองค์กร เช่น ความรู้ไปกระจุกอยู่ที่คนคนเดียว หรืออำนาจในทีมไม่สมดุล แนวโน้มทุกวันนี้จึงเปลี่ยนจากการ “หา 10x developer มาคนเดียว” ไปเป็นการ “สร้างทีมที่เก่งทั้งทีม” — เพราะได้ผลดีกว่าและยั่งยืนกว่ามาก
💬 จากคำเดียวสู่ภาษากลางของทีม#
ศัพท์พวกนี้ไม่ใช่แค่คำเท่ ๆ — แต่ละคำย่อแนวคิดทั้งก้อนไว้ในคำเดียว พูดว่า “เรากำลัง bikeshed อยู่” สั้นกว่าอธิบายยาว ๆ หลายเท่า — แถมไม่ฟังดูเป็นการโจมตีใครด้วย
ครั้งหน้าที่ได้ยินคำพวกนี้ในที่ประชุม คุณจะไม่ใช่แค่ตามทันบทสนทนา — แต่จะรู้ว่ากำลังคุยเรื่องอะไรและร่วมวงได้ทันที ลองสังเกตดูว่าทีมของคุณใช้คำไหนกันบ้าง แล้วคำไหนที่ยังไม่มีใครรู้จัก — บางทีการแนะนำคำสักคำให้ทีม อาจช่วยให้คุยกันรู้เรื่องขึ้นเยอะเลย 😎 ☕