The Mythical Man-Month ทำไมเพิ่มคนแล้วโปรเจกต์ซอฟต์แวร์ยิ่งช้า: บทความว่าด้วยวิศวกรรมซอฟต์แวร์

หยิบเล่มนี้มาอ่านตอนเป็นหัวหน้านักพัฒนาปีแรก แล้วให้ความรู้สึกเหมือน Brooks มานั่งอยู่ข้างๆ ในห้องด้วยกันเลย แม้ว่าเทคโนโลยีในเรื่องจะเก่าไปหลายสิบปีแล้ว แต่จิตวิทยามนุษย์ในการบริหารโปรเจกต์ไม่ได้เปลี่ยนไปเลยสักนิด การเปรียบเปรยอันโด่งดังเรื่องที่ว่าผู้หญิงเก้าคนช่วยกันคลอดลูกในเดือนเดียวไม่ได้ ทุกวันนี้ก็ยังเฉียบคมไม่ต่างจากยุค 70 เราเองก็ยังพยายามระดมยัดคนเพิ่มเข้าไปแก้ปัญหาเดดไลน์ที่กำลังจะพัง แล้วสุดท้ายมันก็พังไม่เป็นท่าใส่หน้าเราทุกครั้งไป เอาจริงๆ บทความ 'No Silver Bullet' ควรเป็นสิ่งที่ผู้บริหารทุกคนต้องอ่าน โดยเฉพาะคนที่คิดว่า AI หรือเฟรมเวิร์กใหม่ๆ จะเข้ามาแก้ปัญหาพื้นฐานระดับองค์กรได้ทั้งหมด บางช่วงเนื้อหาอ่านยากและอัดแน่นไปบ้าง และตัวอย่างเรื่อง OS/360 ก็มาจากยุคสมัยอื่นของวงการคอมพิวเตอร์อย่างเห็นได้ชัด อย่างไรก็ตาม แก่นความรู้เรื่องความสมบูรณ์ของแนวคิดและโมเดลทีมศัลยแพทย์ยังคงใช้ได้จริงอย่างไม่น่าเชื่อ คุณแค่ต้องมองข้ามเรื่องบัตรเจาะรูและการใช้ภาษาที่ไม่ได้ครอบคลุมคนทุกกลุ่มไปให้ได้ แล้วจะเห็นความหลักแหลมที่ซ่อนอยู่ข้างใต้

แค่บท 'No Silver Bullet' บทเดียวก็คุ้มค่าตัวหนังสือแล้วสำหรับใครก็ตามที่จริงจังกับการบริหารงานวิศวกรรม เราอยู่ในอุตสาหกรรมที่วิ่งไล่ตามเทคโนโลยีใหม่ๆ ที่ฮือฮาอยู่ตลอดเวลา แต่ Brooks คอยเตือนเราว่าความซับซ้อนคือส่วนหนึ่งที่แยกไม่ออกจากงานนี้ การเพิ่มคนเข้าไปในโปรเจกต์ซอฟต์แวร์ที่ล่าช้ามีแต่จะทำให้มันช้าลงไปอีก นี่คือกฎธรรมชาติที่เหล่าผู้จัดการก็ยังไม่ยอมรับกันอยู่ดี ผมชอบการเปรียบเทียบในเล่มมาก ตั้งแต่เรื่องสัตว์ยุคก่อนประวัติศาสตร์ในบ่อยางมะตอยไปจนถึงความเป็นเอกภาพทางสถาปัตยกรรมของมหาวิหาร สำนวนการเขียนมีความเป็นวรรณกรรมอย่างน่าประหลาดใจสำหรับหนังสือสายเทคนิค ซึ่งช่วยให้เนื้อหาส่วนที่หนักๆ เกี่ยวกับประวัติศาสตร์ของ IBM 360 ย่อยง่ายขึ้นเยอะ คือหนังสือเล่มนี้มันเก่าอย่างเห็นได้ชัดแหละ และสะท้อนบรรทัดฐานทางสังคมในยุคนั้น ซึ่งอ่านแล้วก็อาจจะหงุดหงิดใจได้บ้าง แต่ถ้าคุณโฟกัสไปที่แง่มุมทางสังคมวิทยาของวิธีที่ทีมสร้างระบบอันซับซ้อน คุณจะได้พบกับความรู้อันลุ่มลึกในนี้มากกว่าอ่านบล็อกเกี่ยวกับ Agile ทั่วๆ ไปรวมกันสิบเว็บเสียอีก มันมีเหตุผลอยู่ว่าทำไมเล่มนี้ถึงเป็นตำราระดับรากฐาน

ในที่สุดก็ได้ฤกษ์อ่านหนังสือคลาสสิกเล่มนี้จนจบ แล้วบอกตามตรงว่าตกใจมากที่โลกของการบริหารโปรเจกต์แทบไม่ได้เปลี่ยนไปเลย คำคมอันโด่งดังที่ว่าโปรเจกต์ล่าช้าไปเป็นปีได้ยังไง 'ก็ช้าไปทีละวันไงล่ะ' เป็นประโยคที่ผมอยากจะสักไว้ที่หน้าผากตัวเองเลย คนเรามักจะมองข้ามความล่าช้าเล็กๆ น้อยๆ ได้ง่ายมาก จนกระทั่งมันสะสมพอกพูนกลายเป็นหายนะที่แก้ไขไม่ได้ Brooks มีความสามารถอันน่าทึ่งในการนำปัญหาทางสังคมวิทยาที่ซับซ้อนมาเปลี่ยนเป็นอุปมาที่ชัดเจนและนำไปใช้ได้จริง ฉบับครบรอบ 20 ปีมีการเพิ่มบทสะท้อนความคิดที่ยอดเยี่ยมเกี่ยวกับไอเดียดั้งเดิมของเขาเข้าไปด้วย ซึ่งพิสูจน์ให้เห็นว่าเขาพร้อมจะยอมรับในจุดที่ตัวเองเคยคิดผิด ส่วนตัวผมมองว่าช่วงที่ถกกันเรื่อง 'Second System Effect' เป็นส่วนที่มีประโยชน์ที่สุดในหนังสือรวมบทความเล่มนี้แล้ว มันเป็นคำเตือนที่วิศวกรอาวุโสทุกคนต้องได้ฟังก่อนจะเริ่มโปรเจกต์ใหญ่ตัวใหม่แกะกล่อง แม้จะมีการอ้างอิงที่ล้าสมัยไปบ้างอย่างเรื่องเทปแม่เหล็ก แต่ข้อมูลเชิงลึกทางจิตวิทยานั้นเป็นอมตะอย่างแท้จริง เทคลีดทุกคนควรมีติดชั้นหนังสือไว้สักเล่ม

ให้ตายเถอะ รู้งี้ผมน่าจะได้อ่านเล่มนี้เมื่อสิบปีก่อน แทนที่จะต้องมาเรียนรู้บทเรียนราคาแพงพวกนี้ด้วยตัวเองแบบเจ็บปวด ผมอยากจะเหมาหนังสือเล่มนี้สักร้อยเล่มแล้วเอาไปแจกให้ลูกค้าทุกคนที่ถามว่าทำไมเราถึงแค่ 'เพิ่มคนเข้าไป' เพื่อให้ทันเดดไลน์ไม่ได้ มันน่าหงุดหงิดนะที่ผ่านการพัฒนาซอฟต์แวร์มาสี่ทศวรรษแล้ว แต่เราก็ยังไม่จำบทเรียนเหล่านี้กันอีกตั้งมากมาย Brooks อธิบายเรื่องภาระในการสื่อสารและความจำเป็นของการมีวิสัยทัศน์ที่เป็นหนึ่งเดียวได้อย่างชัดเจนแจ่มแจ้ง จนทำให้คุณต้องสงสัยว่าทำไมพวกเราถึงยังต้องมาดิ้นรนกับเรื่องพื้นฐานพวกนี้อยู่ บทที่ว่าด้วยเรื่อง 'No Silver Bullet' คือผลงานชิ้นเอกทางตรรกะที่ผ่าทะลุคำโฆษณาชวนเชื่อทางการตลาดทั้งหมดของอุตสาหกรรมเทค บอกตามตรงว่าผมไม่สนใจหรอกว่าตัวอย่างในเล่มจะเป็นเรื่องเมนเฟรมและไมโครฟิช เพราะองค์ประกอบด้านมนุษย์นั้นเหมือนกับสิ่งที่ผมเห็นอยู่ทุกวันเป๊ะๆ มันเป็นผลงานชิ้นเอกของวรรณกรรมสายเทคนิคที่ให้ความสำคัญกับผู้คนซึ่งอยู่เบื้องหลังโค้ด ถ้าคุณทำงานด้านซอฟต์แวร์แล้วยังไม่ได้อ่านเล่มนี้ คุณกำลังพลาดสิ่งสำคัญและทำร้ายตัวเองอย่างมหันต์ นี่คือรากฐานของวิชาชีพเราทั้งหมด

เคยสงสัยไหมว่าทำไมโปรเจกต์ซอฟต์แวร์ถึงยังล้มเหลวด้วยวิธีเดิมๆ เหมือนเมื่อห้าสิบปีก่อน การได้อ่านบทแรกเรื่อง 'The Tar Pit' ทำให้ผมตระหนักว่าปัญหาการดิ้นรนพื้นฐานของการเขียนโปรแกรมเป็นเรื่องสากลและเหนือกาลเวลา Brooks ถ่ายทอดความรู้สึกของการจมดิ่งลงไปในความยุ่งเหยิงของระบบที่ต้องพึ่งพากันและข้อกำหนดที่เปลี่ยนไปมาได้อย่างสมบูรณ์แบบ คำเตือนของเขาเกี่ยวกับ 'Second System Effect' ที่นักออกแบบมักจะใส่ลูกเล่นและฟีเจอร์ทุกอย่างเท่าที่จะจินตนาการได้จนล้นเกินในโปรเจกต์ถัดไป เป็นอะไรที่แทงใจดำสุดๆ ผมเคยเห็นเหตุการณ์แบบนี้เป๊ะๆ เกิดขึ้นในบริษัทอย่างน้อยสามแห่ง พูดกันตามตรง คุณต้องทำเป็นมองข้ามมุมมองทางสังคมที่ค่อนข้างอนุรักษ์นิยมของเขา รวมถึงการใช้สรรพนามเพศชายตลอดทั้งเล่มไปให้ได้ ถ้าคุณกรองเอาบริบทที่ล้าสมัยออกไปได้ ตรรกะที่เหลืออยู่เกี่ยวกับการสื่อสารในทีมและความสอดคล้องทางสถาปัตยกรรมคือทองคำล้วนๆ มันไม่ใช่หนังสือที่สมบูรณ์แบบตามมาตรฐานยุคปัจจุบัน แต่แก่นข้อมูลเชิงลึกข้างในยังเฉียบคมอย่างน่าประหลาดใจเมื่อเทียบกับอายุของมัน

ในฐานะคนที่เข้าสู่วงการนี้ผ่านบูตแคมป์ไม่ได้จบปริญญาวิทยาการคอมพิวเตอร์มาโดยตรง ตอนแรกผมก็แอบกังขาอยู่เหมือนกันกับการต้องมาอ่านหนังสือตั้งแต่ยุค 70 อย่างไรก็ตาม คำแนะนำที่ให้ 'วางแผนที่จะทิ้งตัวแรกไปได้เลย' เพราะยังไงคุณก็ต้องได้ทิ้งแน่ๆ น่าจะเป็นสิ่งที่อ่านแล้วปลดล็อกความคิดได้ดีที่สุดในปีนี้เลย มันเป็นเครื่องเตือนใจชั้นดีว่าเวอร์ชันแรกคือการเรียนรู้เสมอ และแทบจะไม่เคยเป็นผลิตภัณฑ์ตัวสุดท้ายเลย แนวคิดเรื่องความสมบูรณ์ของแนวคิดก็ติดอยู่ในหัวผมเหมือนกัน โดยเฉพาะไอเดียที่ว่าระบบต้องมีวิสัยทัศน์ที่เป็นหนึ่งเดียวกัน มันช่วยอธิบายได้เลยว่าทำไมแอปสมัยใหม่หลายๆ ตัวถึงให้ความรู้สึกเหมือนเอาฟีเจอร์ที่ออกแบบโดยคณะกรรมการมายำรวมกันแบบสะเปะสะปะ แต่ผมรู้สึกว่าส่วนที่พูดถึง 'ทีมศัลยแพทย์' แอบแปลกไปหน่อย โดยเฉพาะไอเดียเรื่องการมีเลขาหลายคนและมีผู้ช่วยนักบินหนึ่งคนเพื่อคอยซัพพอร์ตหัวหน้านักพัฒนาแค่คนเดียว มันดูเป็นการบริหารจากบนลงล่างมากๆ และไม่ค่อยเข้ากับการทำงานของทีมแบบข้ามสายงานในยุคปัจจุบันเท่าไหร่ ถึงอย่างนั้น บทความส่วนใหญ่ก็ชวนให้ขบคิดได้อย่างไม่น่าเชื่อและยังเข้ากับงานที่ต้องเจอในแต่ละวันได้ดี

หลังจากได้ยินผู้จัดการของผมยกคำพูดจาก 'กฎของ Brooks' มาอ้างเป็นรอบที่ร้อย ผมก็เลยตัดสินใจว่าถึงเวลาต้องมาอ่านงานต้นฉบับด้วยตัวเองแล้ว ผมประหลาดใจมากที่ตัวเองเพลิดเพลินไปกับสำนวนการเขียนได้ขนาดนี้ โดยเฉพาะวิธีที่เขาเชื่อมโยงการออกแบบซอฟต์แวร์เข้ากับช่างสร้างมหาวิหารแห่งแร็งส์ มันเป็นมุมมองที่ลึกซึ้งเชิงปรัชญามากเกี่ยวกับความหมายของการสร้างสรรค์สิ่งที่ซับซ้อนและงดงาม อุปมาเรื่อง 'บ่อยางมะตอย' ก็เห็นภาพชัดเจนอย่างไม่น่าเชื่อ มันอธิบายความรู้สึกของโปรเจกต์ที่ค่อยๆ สูญเสียแรงขับเคลื่อนเมื่อถูกถ่วงด้วยน้ำหนักของตัวมันเองได้อย่างสมบูรณ์แบบ ข้อติเดียวของผมจริงๆ ก็คือการขาดความหลากหลายอย่างเห็นได้ชัดในตัวอย่างที่ยกมา และการใช้สรรพนามเพศชายอยู่ตลอดเวลา ซึ่งทำให้รู้สึกเหมือนเป็นหนังสือแบบ 'คลับของผู้ชาย' มากๆ จากประสบการณ์ของผม บทเรียนหลักเกี่ยวกับความสมบูรณ์ของแนวคิดคือส่วนที่มีคุณค่าที่สุดของหนังสือเล่มนี้สำหรับนักพัฒนายุคใหม่ ถือเป็นหนังสือที่ดีเล่มหนึ่งเลยถ้าคุณสามารถมองข้ามวัฒนธรรมออฟฟิศยุค 1970 ไปได้แล้วโฟกัสแค่เรื่องสถาปัตยกรรม

คนเราจะอ้างอิงถึงหอคอยบาเบลหรือมหาวิหารแห่งแร็งส์ได้สักกี่ครั้งกันก่อนที่มันจะชักจะมากเกินไป ผมยอมรับนะว่า Brooks เป็นระดับตำนานในวงการนี้ แต่การมาอ่านเล่มนี้ในปี 2024 ก็แอบช็อกกับวัฒนธรรมในยุคนั้นอยู่หน่อยๆ การที่โลกทัศน์ของเขาไม่มีผู้หญิงอยู่เลยเป็นอะไรที่ชัดเจนจนแสบตา และการใส่บันทึกเกี่ยวกับ 'แผนการของพระเจ้าสำหรับการแต่งงาน' ลงในคู่มือทางเทคนิคก็เป็นเรื่องที่พิลึกมาก ผมเข้าใจถึงความสำคัญทางประวัติศาสตร์ของกฎของ Brooks นะ แต่ส่วนที่เหลือของหนังสือให้ความรู้สึกเหมือนกำลังฝืนลุยอ่านประวัติศาสตร์ยุคโบราณของ IBM บอกตามตรงว่า รายละเอียดทางเทคนิคเกี่ยวกับไมโครฟิชและการอัปเดตคู่มือไม่ได้มีประโยชน์อะไรนักสำหรับคนที่ทำงานในสภาพแวดล้อมแบบ CI/CD สมัยใหม่ แม้จะมีข้อคิดดีๆ เรื่องภาระในการสื่อสารอยู่บ้าง แต่ผมกลับพบว่าตัวเองอ่านข้ามๆ เนื้อหาส่วนใหญ่ไป เพราะรู้สึกเหมือนกำลังเรียนวิชาประวัติศาสตร์มากกว่าอ่านคู่มือแนะแนว ถ้ามองเป็นของสะสมเข้าพิพิธภัณฑ์ก็ถือว่าโอเค แต่ไม่ควรเป็นหนังสือเล่มแรกที่คุณยื่นให้พนักงานใหม่

ไม่ค่อยเหมือนที่คาดหวังไว้เมื่อเทียบกับกระแสคำชมที่อวยกันหนักมาก แต่ก็พอเข้าใจได้ว่าทำไมมันถึงเป็นการปฏิวัติวงการตอนที่วางแผงครั้งแรก แนวคิดเรื่อง 'Mythical Man-Month' ขึ้นหิ้งเป็นความคลาสสิกได้แบบมีเหตุผลรองรับอยู่ แต่บทความเรื่อง 'ทีมศัลยแพทย์' ที่มีบทบาทนักบินและผู้ช่วยนักบินให้ความรู้สึกที่หลุดจากความเป็นจริงไปโดยสิ้นเชิง การให้คนคนเดียวเป็นคนคิดทั้งหมดในขณะที่คนอื่นๆ ที่เหลือทำหน้าที่เป็นแค่ฝ่ายสนับสนุน ฟังดูเหมือนเป็นสูตรสำเร็จที่จะนำไปสู่ภาวะหมดไฟและขวัญกำลังใจที่ตกต่ำ นอกจากนี้ การเน้นหนักไปที่เรื่องคู่มือของ OS/360 ก็ให้ความรู้สึกเหมือนพาออกนอกเรื่องไปไกลมาก ซึ่งไม่ได้ช่วยเพิ่มความเข้าใจเกี่ยวกับการพัฒนาซอฟต์แวร์ยุคใหม่ให้ผมสักเท่าไหร่ พูดกันตามตรง Brooks เขียนด้วยน้ำเสียงที่ทรงภูมิมาก และข้อสังเกตของเขาเกี่ยวกับความล้มเหลวในการสื่อสารแบบ 'หอคอยบาเบล' ก็ตรงเผง เพียงแต่ว่าคุณต้องเอามาแปลความหมายในหัวเยอะมากเพื่อจะนำแนวคิดเหล่านี้ไปปรับใช้กับทีมยุคใหม่ที่ทำงานแบบอไจล์และทำงานจากระยะไกล ผมว่ามันคุ้มที่จะอ่านแบบผ่านๆ เพื่อเก็บไอเดียใหญ่ๆ นะ แต่ไม่ต้องรู้สึกแย่หรอกถ้าคุณจะพบว่าตัวเองรู้สึกเบื่อกับรายละเอียดทางเทคนิคของคอมพิวเตอร์ยุคกลางศตวรรษ

หนังสือเล่มนี้เอาเข้าจริงก็เหมือน 'The Elements of Style' ของวงการเขียนโปรแกรม คือคนเอาแต่แนะนำต่อๆ กันมาเพราะรู้สึกว่าต้องแนะนำ ไม่ใช่เพราะว่ามันมีประโยชน์จริงๆ คำแนะนำที่นำไปใช้ได้จริงส่วนใหญ่ถูกฝังอยู่ใต้กองเกร็ดเล็กเกร็ดน้อยเกี่ยวกับการพัฒนาเมนเฟรมและไมโครฟิช ในยุคของ GitHub และ Stack Overflow แบบนี้ เรายังต้องมานั่งอ่านข้อมูลการอัปเดตคู่มือของ OS/360 เป็นหน้าๆ กันอีกเหรอ พูดตรงๆ เลยนะ การที่หนังสือทั้งเล่มไม่ใช้สรรพนามเพศหญิงเลยแม้แต่คำเดียวมันทำให้รู้สึกแปลกแยกอย่างไม่น่าเชื่อ แม้แต่อุปมาหลักของเรื่องอย่าง 'man-months' ก็ยังให้ความรู้สึกเหมือนเป็นวิธีมองแรงงานมนุษย์ที่ล้าสมัยและลดทอนความเป็นมนุษย์ แม้ผมจะเข้าใจว่ากฎของ Brooks นั้นสำคัญ แต่คุณสามารถเรียนรู้เรื่องนั้นได้จากวิดีโอ YouTube ความยาวห้านาทีโดยไม่ต้องมาทนอ่านการเปรียบเทียบทางศาสนาของเขา อุตสาหกรรมนี้ก้าวข้ามวิธีคิดที่ตายตัวและยึดติดกับลำดับขั้นแบบนี้ไปแล้ว และผมคิดว่ารายชื่อหนังสือแนะนำของเราก็ควรก้าวข้ามไปได้แล้วเหมือนกัน ถึงเวลาเลิกยกย่องหนังสือเล่มนี้ว่าเป็นคัมภีร์ศักดิ์สิทธิ์ของการบริหารทีมพัฒนาเสียที