Brooks’s Law

การเพิ่มคนเข้า project ที่ล่าช้าอยู่แล้ว ยิ่งทำให้ช้าลง

ใจความสำคัญ

Fred Brooks เสนอกฎนี้ในหนังสือคลาสสิกปี 1975 The Mythical Man-Month: Essays on Software Engineering ซึ่งเรียบเรียงจากประสบการณ์ตรงของเขาในฐานะผู้จัดการ project พัฒนา OS/360 ให้ IBM project ระบบปฏิบัติการขนาดใหญ่ที่ล่าช้าอย่างหนักแม้จะทุ่มกำลังคนเพิ่มเข้าไปเรื่อย ๆ

“การเพิ่มกำลังคนเข้าไปใน project ซอฟต์แวร์ที่ล่าช้าอยู่แล้ว ยิ่งทำให้มันช้าลงไปอีก”

— Fred Brooks, The Mythical Man-Month (1975)

Brooks เองเรียกกฎนี้ว่าเป็น “an outrageous oversimplification” หรือการทำให้เรื่องซับซ้อนง่ายเกินไปอย่างเกินเลย แต่ก็ยอมรับว่ามันจับใจความสำคัญของปัญหาได้ตรงจุด นั่นคือแนวคิด man-month ซึ่งใช้คำนวณระยะเวลา project จากจำนวนคนคูณจำนวนเดือนนั้น เป็น “the mythical man-month” — หน่วยวัดในตำนานที่ไม่มีอยู่จริง เพราะงานคนกับเวลาไม่ได้แลกเปลี่ยนกันได้เสมอไป (interchangeable) แบบที่สูตรคณิตศาสตร์ง่าย ๆ จะบอก

ความหมายและนัยยะ

Brooks อธิบายว่าเหตุใดการเพิ่มคนจึงมักทำให้ project ที่ล่าช้าอยู่แล้วยิ่งช้าลง ผ่านสามกลไกหลัก

1. Ramp-up time (เวลาปรับตัว) — คนใหม่ต้องใช้เวลาทำความเข้าใจ domain สถาปัตยกรรม และ code ที่มีอยู่ ก่อนจะเริ่มสร้างคุณค่าได้จริง ระหว่างนั้นพวกเขาต้องพึ่งพาคนเก่าในทีมคอยสอนงาน ซึ่งดึงเวลาที่คนเก่าควรใช้ทำงานจริงออกไป ในช่วงแรกคนใหม่อาจสร้างผลลัพธ์สุทธิเป็นลบด้วยซ้ำ เพราะ code ที่ยังไม่เข้าใจบริบทมักมาพร้อม bug และงาน rework

2. Communication overhead (ต้นทุนการสื่อสาร) — ยิ่งทีมใหญ่ ช่องทางสื่อสารที่ต้องดูแลยิ่งเพิ่มแบบไม่เป็นเชิงเส้น ตามสูตร n(n−1)/2 เมื่อ n คือจำนวนคน เช่นทีม 10 คนมี 45 คู่สื่อสารที่อาจต้องประสานกัน แต่ทีม 50 คนกลับมีถึง 1,225 คู่ การประชุม การรีวิว code และการซิงค์ความเข้าใจจึงกินเวลามากขึ้นแบบทวีคูณ ไม่ใช่แค่บวกเพิ่มตามจำนวนคน

3. Task divisibility (ความแบ่งงานไม่ได้) — งานบางอย่างไม่สามารถแบ่งให้คนหลายคนทำพร้อมกันได้ ไม่ว่าจะมีคนกี่คนก็ตาม Brooks เปรียบเทียบไว้อย่างคมคายว่า “nine women can’t make a baby in one month” — แม้จะมีแม่เก้าคน แต่ละคนก็ยังใช้เวลาตั้งครรภ์ 9 เดือนเท่าเดิม งานซอฟต์แวร์ที่มีลำดับขั้นตอนต่อเนื่องกัน (sequential dependency) เช่นการออกแบบสถาปัตยกรรมหลัก หรือการ debug ปัญหาเชิงตรรกะที่ซับซ้อน ก็มีธรรมชาติแบบเดียวกัน

ข้อสำคัญคือกฎนี้ใช้ได้กับ project ที่ ล่าช้าอยู่แล้ว เป็นหลัก การเพิ่มคนตั้งแต่ต้น project หรือการเผื่อกำลังคนสำรองไว้ล่วงหน้า ไม่ได้อยู่ในขอบเขตของกฎนี้โดยตรง — ปัญหาเกิดเมื่อองค์กร “ตื่นตระหนก” แล้วโยนคนเข้าไปแก้ปัญหาเฉพาะหน้าโดยไม่คิดถึงต้นทุนแฝงของการเพิ่มคนกลางคัน

ด้านล่างคือวงจรป้อนกลับ (feedback loop) ที่ Brooks’s Law อธิบาย

flowchart TD
    A[Project is already late] --> B[Add more engineers]
    B --> C[New hires need ramp up time]
    B --> D[Communication pairs grow as n times n minus 1 over 2]
    C --> E[Senior staff time diverted to teach]
    D --> E
    E --> F[Project falls further behind schedule]
    F --> A

ตัวอย่างในโลกจริง

OS/360 ที่ IBM — ต้นกำเนิดของกฎนี้เอง Brooks บริหาร project พัฒนาระบบปฏิบัติการ OS/360 ที่ล่าช้าอย่างหนัก การอัดฉีดวิศวกรเพิ่มเข้าไปเรื่อย ๆ ไม่ได้ทำให้กำหนดส่งมอบดีขึ้น แต่กลับยืดเวลาซ้ำเติมจากภาระการสื่อสารและการประสานงานที่บวมขึ้น ประสบการณ์นี้กลายเป็นแรงบันดาลใจหลักของทั้งเล่ม The Mythical Man-Month
“Bermuda Plan” ในทางกลับกัน — Brooks เคยเสนอเล่น ๆ ว่าวิธีแก้ปัญหา project ล่าช้าอีกทางคือการ ลด คนลง โดยส่งสมาชิกส่วนใหญ่ไปพักที่เบอร์มิวดา แล้วปล่อยให้คนที่เหลือไม่กี่คนซึ่งเข้าใจงานลึกที่สุดทำงานต่อโดยไม่ถูกขัดจังหวะ — สะท้อนว่าปัญหาที่แท้จริงมักไม่ใช่ “มีคนไม่พอ” แต่คือ “สื่อสารกันมากเกินไป”
โครงการ open source ขนาดใหญ่อย่าง Linux kernel — เป็นตัวอย่างที่ดูเหมือนขัดแย้งกับ Brooks’s Law เพราะมีผู้ร่วมพัฒนานับพันคนแต่ยังคงเดินหน้าได้เร็ว เหตุผลคือความเป็น module สูง (modularity) และรูปแบบการ contribute แบบกระจายศูนย์ผ่าน maintainer หลายชั้น ทำให้จำนวนคู่สื่อสารที่ต้องประสานกันจริง ๆ ต่ำกว่าสูตร n(n−1)/2 มาก นี่คือจุดที่ Linus’s Law (“ตายิ่งเยอะ bug ยิ่งตื้น”) ทำงานคนละมิติกับ Brooks’s Law ได้โดยไม่ขัดกัน
ทีมสตาร์ทอัพที่ตื่นตระหนกก่อน deadline — รูปแบบที่พบบ่อยในอุตสาหกรรมคือเมื่อทีมพลาดกำหนดส่งมอบ ผู้บริหารมักตอบสนองด้วยการจ้างคนเพิ่มแบบเร่งด่วน ผลที่ตามมาคือ velocity ของทีมมักลดลงชั่วคราวใน 1-2 sprint แรก เพราะภาระ code review, pairing และการอธิบายบริบทให้คนใหม่เพิ่มขึ้นเร็วกว่าที่ผลผลิตจากคนใหม่จะไล่ทัน

บทเรียนที่นำไปใช้

อย่าตอบสนองความล่าช้าด้วยการโยนคนเข้าไป โดยอัตโนมัติ ให้ถามก่อนว่าคอขวดคืออะไร — ถ้าเป็นปัญหาการสื่อสารหรือ dependency เชิงลำดับ การเพิ่มคนจะยิ่งซ้ำเติม ไม่ใช่แก้ปัญหา
ถ้าจำเป็นต้องเพิ่มคนจริง ๆ ให้เพิ่มแต่เนิ่น ๆ ไม่ใช่ตอนใกล้ deadline และควรมอบหมายงานที่ไม่พึ่งพา ramp-up ลึก เช่นงานทดสอบ (QA) หรือเอกสารประกอบ ให้คนใหม่ช่วยก่อน
ลดต้นทุนการสื่อสารด้วยสถาปัตยกรรมที่เป็น module แบ่งทีมตาม bounded context ที่ชัดเจน (ดู DDD) เพื่อให้แต่ละทีมสื่อสารกันเองน้อยลง — แนวคิดนี้เชื่อมโยงตรงกับ Conway’s Law ที่บอกว่าโครงสร้างระบบมักสะท้อนโครงสร้างทีมที่สร้างมัน
พิจารณาทางเลือกอื่นก่อนเพิ่มคน เช่นตัดขอบเขตงาน (scope) เลื่อน deadline หรือปรับปรุงกระบวนการทำงานของทีมเดิมให้มีประสิทธิภาพขึ้น การอัปเดตแผนงานอย่างตรงไปตรงมาย่อมดีกว่าการซ่อนความล่าช้าไว้ด้วยกำลังคนที่ไม่ช่วยอะไร
ใช้ whole-team practice และ pairing เพื่อกระจายความรู้ตั้งแต่ต้น ลดการพึ่งพาบุคคลใดบุคคลหนึ่งเป็นจุดคอขวดของการสอนงาน เมื่อถึงเวลาต้องขยายทีมจริง ต้นทุน ramp-up จะต่ำกว่าทีมที่ความรู้กระจุกอยู่กับคนเดียว

ที่เกี่ยวข้อง

แหล่งอ้างอิง

ที่มา · deviq.com/laws/brooks-law
Brooks’s law – Wikipedia
The Mythical Man-Month – Wikipedia
Brooks’ Law: Adding Manpower to a Late Project Makes It Later – Effectiviology
The Mythical Man-Month — Fred Brooks (1975)

Brooks’s Law

ใจความ​สำคัญ

ความหมาย​และ​นัย​ยะ

ตัวอย่าง​ใน​โลก​จริง

บทเรียน​ที่​นำ​ไป​ใช้

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง