The Mythical Man-Month

การปรุงอาหารที่ดีต้องใช้เวลา หากท่านถูกทำให้ต้องรอ นั่นเป็นเพราะเราต้องการปรนนิบัติท่านให้ดีขึ้น และเพื่อให้ท่านพึงพอใจ — เมนูของภัตตาคาร ANTOINE, นิวออร์ลีนส์

โครงการซอฟต์แวร์จำนวนมากต้องประสบความล้มเหลวเพราะขาดแคลนเวลาในปฏิทิน (calendar time) มากกว่าสาเหตุอื่นๆ ทั้งหมดรวมกัน ทำไมสาเหตุของหายนะนี้ถึงได้พบบ่อยนัก?

อย่างแรก เทคนิคการประมาณการ (estimating) ของเรายังพัฒนามาได้ไม่ดีนัก ที่ร้ายแรงกว่านั้นคือพวกมันสะท้อนถึงสมมติฐานที่ไม่ได้พูดออกมาแต่ไม่เป็นความจริงเลย นั่นคือสมมติฐานที่ว่าทุกอย่างจะราบรื่น

อย่างที่สอง เทคนิคการประมาณการของเราสับสนระหว่างความพยายาม (effort) กับความคืบหน้า (progress) โดยซ่อนสมมติฐานที่ผิดพลาดไว้ว่า "คน" และ "เดือน" สามารถใช้แทนกันได้

อย่างที่สาม เพราะเราไม่แน่ใจในผลการประมาณการของเรา software managers จึงมักขาดความดื้อรั้นอย่างสุภาพแบบเชฟของภัตตาคาร Antoine

อย่างที่สี่ ความคืบหน้าของ schedule ได้รับการตรวจสอบอย่างย่ำแย่ เทคนิคที่ได้รับการพิสูจน์แล้วและเป็นกิจวัตรในสาขาวิศวกรรมอื่นๆ กลับถูกมองว่าเป็นนวัตกรรมที่ล้ำสมัยใน software engineering

อย่างที่ห้า เมื่อพบว่า schedule slippage (ตารางเวลาล่าช้า) เกิดขึ้น การตอบสนองตามธรรมชาติ (และแบบดั้งเดิม) คือการเพิ่มกำลังคน (manpower) ซึ่งเหมือนกับการสาดน้ำมันเข้ากองไฟ สิ่งนี้ทำให้เรื่องแย่ลง และแย่ลงไปอีกมาก ยิ่งไฟลุกโชนก็ยิ่งต้องการน้ำมันมากขึ้น และด้วยเหตุนี้วงจรที่เลวร้ายจึงเริ่มต้นขึ้นและจบลงด้วยหายนะ

การตรวจสอบ schedule จะเป็นหัวข้อของบทความแยกต่างหาก ให้เรามาพิจารณาแง่มุมอื่นๆ ของปัญหานี้ในรายละเอียดเพิ่มเติมกันดีกว่า

Optimism

programmers ทุกคนล้วนเป็นพวกมองโลกในแง่ดี บางทีเวทมนตร์สมัยใหม่นี้อาจดึงดูดโดยเฉพาะผู้ที่เชื่อในตอนจบที่มีความสุขและนางฟ้าแม่ทูนหัว บางทีความหงุดหงิดเล็กๆ น้อยๆ นับร้อยอย่างอาจขับไล่ทุกคนออกไป เหลือเพียงผู้ที่จดจ่ออยู่กับเป้าหมายสุดท้ายเป็นนิสัย หรือบางทีอาจเป็นเพียงเพราะคอมพิวเตอร์ยังเป็นสิ่งใหม่ programmers ก็ยิ่งใหม่กว่า และคนหนุ่มสาวก็มักจะมองโลกในแง่ดีเสมอ แต่ไม่ว่ากระบวนการคัดเลือกจะทำงานอย่างไร ผลลัพธ์ที่ได้นั้นไม่อาจปฏิเสธได้: "ครั้งนี้มันต้องรันได้แน่นอน" หรือ "ผมเพิ่งจะเจอบั๊กตัวสุดท้ายแล้ว"

ดังนั้น สมมติฐานที่ผิดพลาดประการแรกซึ่งเป็นรากฐานของการทำ scheduling สำหรับ systems programming ก็คือทุกอย่างจะดำเนินไปด้วยดี นั่นคือ แต่ละงานจะใช้เวลาเพียงเท่าที่มัน "ควร" จะใช้เท่านั้น

การแพร่กระจายของการมองโลกในแง่ดีในหมู่ programmers นั้นสมควรได้รับการวิเคราะห์มากกว่าเพียงแค่การมองผ่านๆ Dorothy Sayers ในหนังสือที่ยอดเยี่ยมของเธอ The Mind of the Maker ได้แบ่งกิจกรรมการสร้างสรรค์ออกเป็นสามขั้นตอน ได้แก่: แนวคิด (idea), การนำไปใช้งาน (implementation) และการปฏิสัมพันธ์ (interaction) ดังนั้น หนังสือ หรือคอมพิวเตอร์ หรือโปรแกรม จึงเกิดขึ้นครั้งแรกในฐานะโครงสร้างในอุดมคติที่สร้างขึ้นนอกขอบเขตของเวลาและอวกาศ แต่สมบูรณ์อยู่ในจิตใจของผู้สร้าง มันถูกทำให้เป็นจริงในเวลาและอวกาศด้วยปากกา น้ำหมึก และกระดาษ หรือด้วยสายไฟ ซิลิคอน และเฟอร์ไรต์ การสร้างสรรค์จะเสร็จสมบูรณ์เมื่อมีใครบางคนอ่านหนังสือ ใช้คอมพิวเตอร์ หรือรันโปรแกรม ซึ่งเป็นการปฏิสัมพันธ์กับจิตใจของผู้สร้างนั่นเอง

คำอธิบายนี้ ซึ่งคุณ Sayers ใช้เพื่อฉายภาพไม่เพียงแต่กิจกรรมการสร้างสรรค์ของมนุษย์ แต่ยังรวมถึงหลักคำสอนเรื่องตรีเอกภาพของคริสเตียน จะช่วยเราในงานปัจจุบันของเรา สำหรับมนุษย์ผู้สร้างสิ่งต่างๆ ความไม่สมบูรณ์และความไม่สอดคล้องของแนวคิดของเราจะชัดเจนขึ้นก็ต่อเมื่ออยู่ในระหว่าง implementation เท่านั้น ด้วยเหตุนี้ การเขียน การทดลอง การ "ทดลองทำ" จึงเป็นระเบียบวินัยที่จำเป็นสำหรับนักทฤษฎี

ในกิจกรรมการสร้างสรรค์หลายอย่าง สื่อกลางในการดำเนินการนั้นจัดการได้ยาก (intractable) ไม้แปรรูปอาจแตกแยก; สีอาจเลอะเทอะ; วงจรไฟฟ้าอาจเกิดสัญญาณรบกวน ข้อจำกัดทางกายภาพของสื่อเหล่านี้ตีกรอบแนวคิดที่อาจแสดงออกมาได้ และยังสร้างความยากลำบากที่คาดไม่ถึงในระหว่าง implementation อีกด้วย

ดังนั้น การนำไปใช้งาน (implementation) จึงต้องใช้ทั้งเวลาและหยาดเหงื่อ ทั้งเนื่องจากสื่อทางกายภาพและเนื่องจากความไม่เพียงพอของแนวคิดที่เป็นรากฐาน เรามักจะตำหนิสื่อทางกายภาพว่าเป็นต้นเหตุของความยากลำบากส่วนใหญ่ใน implementation เพราะสื่อเหล่านั้นไม่ใช่ "ของเรา" ในแบบที่แนวคิดเป็น และความภาคภูมิใจของเราก็มักจะทำให้การตัดสินใจผิดเพี้ยนไป

อย่างไรก็ตาม การเขียนโปรแกรมคอมพิวเตอร์สร้างสรรค์ขึ้นด้วยสื่อกลางที่จัดการได้ง่ายอย่างยิ่ง (exceedingly tractable medium) นักเขียนโปรแกรมสร้างผลงานจาก "เนื้อสารทางความคิด" บริสุทธิ์ ซึ่งก็คือแนวคิดต่างๆ และการแสดงแทนแนวคิดเหล่านั้นที่ยืดหยุ่นมาก เพราะสื่อกลางนั้นจัดการได้ง่าย เราจึงคาดหวังว่าจะพบความยากลำบากเพียงเล็กน้อยใน implementation นี่คือที่มาของการมองโลกในแง่ดีที่แพร่กระจายไปทั่ว แต่เพราะแนวคิดของเรานั้นมีข้อบกพร่อง เราจึงมีบั๊ก (bugs) ดังนั้นการมองโลกในแง่ดีของเราจึงไม่สมเหตุสมผล

ในงานชิ้นเดียว สมมติฐานที่ว่าทุกอย่างจะดำเนินไปด้วยดีส่งผลต่อ schedule ในเชิงความน่าจะเป็น มันอาจจะเป็นไปตามแผนจริงๆ ก็ได้ เพราะมีการกระจายความน่าจะเป็นสำหรับความล่าช้าที่จะพบเจอ และการที่ "ไม่มีความล่าช้า" เลยก็มีความน่าจะเป็นที่จำกัดอยู่ค่าหนึ่ง อย่างไรก็ตาม ความพยายามในการเขียนโปรแกรมขนาดใหญ่ประกอบด้วยงานจำนวนมาก ซึ่งบางงานต้องทำต่อเนื่องกันไปตามลำดับ ความน่าจะเป็นที่แต่ละงานจะดำเนินไปด้วยดีทั้งหมดจึงกลายเป็นค่าน้อยมากจนแทบจะเป็นศูนย์

The Man-Month

รูปแบบทางความคิดที่ผิดพลาดประการที่สองแสดงออกมาในหน่วยของความพยายามที่ใช้ในการประมาณการและทำ scheduling นั่นคือ "คน-เดือน" (man-month) ต้นทุนแปรผันตามผลคูณของจำนวนคนและจำนวนเดือนจริงๆ แต่ความคืบหน้าไม่ได้เป็นเช่นนั้น ดังนั้น man-month ในฐานะหน่วยสำหรับวัดขนาดของงานจึงเป็นมายาคติที่อันตรายและหลอกลวง มันสื่อเป็นนัยว่าคนและเดือนสามารถใช้แทนกันได้

คนและเดือนจะเป็นสินค้าที่ใช้แทนกันได้ก็ต่อเมื่อ "งาน" นั้นสามารถแบ่งแยกส่วน (partitioned) ให้กับคนงานหลายคนได้โดยไม่มีการสื่อสารระหว่างกัน (รูปที่ 2.1) เช่น การเกี่ยวข้าวสาลีหรือการเก็บฝ้าย แต่นี่ไม่ใช่ความจริงเลยแม้แต่น้อยสำหรับ systems programming

รูปที่ 2.1 เวลาเทียบกับจำนวนคนงาน — งานที่แบ่งแยกส่วนได้อย่างสมบูรณ์

เมื่อวานชิ้นหนึ่งไม่สามารถแบ่งแยกส่วนได้เนื่องจากข้อจำกัดเชิงลำดับ (sequential constraints) การเพิ่มความพยายามเข้าไปจึงไม่มีผลต่อ schedule (รูปที่ 2.2) การตั้งครรภ์ต้องใช้เวลาเก้าเดือน ไม่ว่าจะมีผู้หญิงกี่คนถูกมอบหมายให้ทำงานนี้ก็ตาม งานซอฟต์แวร์หลายอย่างมีลักษณะเช่นนี้เนื่องจากธรรมชาติที่เป็นลำดับขั้นตอนของการทำ debugging

รูปที่ 2.2 เวลาเทียบกับจำนวนคนงาน — งานที่แบ่งแยกส่วนไม่ได้

ในงานที่สามารถแบ่งแยกส่วนได้แต่ต้องมีการสื่อสารระหว่างงานย่อย ความพยายามในการสื่อสารจะต้องถูกบวกเพิ่มเข้าไปในปริมาณงานที่ต้องทำ ดังนั้น ผลลัพธ์ที่ดีที่สุดที่ทำได้จึงแย่กว่าการแลกเปลี่ยนคนกับเดือนแบบเท่าตัวเสมอ (รูปที่ 2.3)

รูปที่ 2.3 เวลาเทียบกับจำนวนคนงาน — งานที่แบ่งแยกส่วนได้แต่ต้องมีการสื่อสาร

ภาระที่เพิ่มขึ้นของการสื่อสารประกอบด้วยสองส่วน ได้แก่ การฝึกอบรม (training) และการสื่อสารระหว่างกัน (intercommunication) คนงานแต่ละคนจะต้องได้รับการฝึกอบรมในด้านเทคโนโลยี เป้าหมายของความพยายาม กลยุทธ์โดยรวม และแผนงาน การฝึกอบรมนี้ไม่สามารถแบ่งแยกส่วนได้ ดังนั้นความพยายามที่เพิ่มขึ้นในส่วนนี้จึงแปรผันตามจำนวนคนงานแบบเชิงเส้น

การสื่อสารระหว่างกัน (intercommunication) ยิ่งแย่กว่านั้น หากแต่ละส่วนของงานต้องได้รับการประสานงานแยกกันกับส่วนอื่นๆ ทั้งหมด ความพยายามจะเพิ่มขึ้นตามสูตร $n(n-1)/2$ คนงานสามคนต้องการการสื่อสารระหว่างกันแบบเป็นคู่ (pairwise) มากกว่าคนงานสองคนถึงสามเท่า; สี่คนต้องการมากกว่าสองคนถึงหกเท่า ยิ่งไปกว่านั้น หากจำเป็นต้องมีการประชุมระหว่างคนงานสามคน สี่คน หรือมากกว่านั้น เพื่อร่วมกันแก้ไขปัญหา เรื่องราวก็จะยิ่งเลวร้ายลงไปอีก ความพยายามในการสื่อสารที่เพิ่มขึ้นอาจลบล้างผลของการแบ่งงานต้นฉบับออกไปจนหมด และนำเราไปสู่สถานการณ์ดังในรูปที่ 2.4

รูปที่ 2.4 เวลาเทียบกับจำนวนคนงาน — งานที่มีความสัมพันธ์ระหว่างกันที่ซับซ้อน

เนื่องจากการสร้างซอฟต์แวร์โดยเนื้อแท้แล้วเป็นงานระดับระบบ เป็นกิจกรรมที่มีความสัมพันธ์ระหว่างกันที่ซับซ้อน ความพยายามในการสื่อสารจึงมหาศาล และในไม่ช้ามันก็จะครอบงำเวลาที่ลดลงจากการแบ่งงานย่อยให้แต่ละคน การเพิ่มจำนวนคนเข้าไปจึงกลับกลายเป็นการทำให้ schedule ยาวขึ้น ไม่ใช่สั้นลง

Systems Test

ไม่มีส่วนใดของ schedule ที่จะได้รับผลกระทบอย่างรุนแรงจากข้อจำกัดเชิงลำดับมากไปกว่าการทำ component debugging และ system test ยิ่งไปกว่านั้น เวลาที่ต้องการยังขึ้นอยู่กับจำนวนและความซับซ้อนของข้อผิดพลาดที่พบ ตามทฤษฎีแล้วจำนวนนี้ควรจะเป็นศูนย์ แต่เพราะการมองโลกในแง่ดี เรามักจะคาดหวังว่าจำนวนบั๊กจะน้อยกว่าที่เป็นจริงเสมอ ดังนั้นการทดสอบจึงมักจะเป็นส่วนที่มีการทำ schedule ผิดพลาดมากที่สุดในงานเขียนโปรแกรม

เป็นเวลาหลายปีที่ผมได้ใช้กฎเกณฑ์คร่าวๆ (rule of thumb) ต่อไปนี้ในการทำ scheduling สำหรับงานซอฟต์แวร์และประสบความสำเร็จด้วยดี:

• 1/3 สำหรับการวางแผน (planning)
• 1/6 สำหรับการเขียนโค้ด (coding)
• 1/4 สำหรับ component test และ system test ช่วงแรก
• 1/4 สำหรับ system test เมื่อมีส่วนประกอบครบทั้งหมดในมือ

สิ่งนี้แตกต่างจาก conventional scheduling ในหลายประการที่สำคัญ:

1. สัดส่วนที่ทุ่มเทให้กับการวางแผนนั้นมากกว่าปกติ ถึงกระนั้น มันก็แทบจะไม่เพียงพอที่จะสร้าง specification ที่ละเอียดและหนักแน่น และไม่เพียงพอที่จะรวมถึงการวิจัยหรือการสำรวจเทคนิคใหม่ๆ ทั้งหมด
2. ครึ่งหนึ่งของ schedule ที่ทุ่มเทให้กับ debugging ของโค้ดที่เสร็จสมบูรณ์แล้วนั้นมากกว่าปกติมาก
3. ส่วนที่ประมาณการได้ง่ายที่สุด นั่นคือ coding กลับได้รับเวลาเพียงหนึ่งในหกของ schedule เท่านั้น

จากการตรวจสอบโครงการที่ทำ schedule แบบดั้งเดิม ผมพบว่ามีเพียงไม่กี่โครงการที่เผื่อเวลาครึ่งหนึ่งของ schedule ที่คาดการณ์ไว้สำหรับการทดสอบ แต่โครงการส่วนใหญ่กลับใช้เวลาจริงถึงครึ่งหนึ่งเพื่อจุดประสงค์นั้น หลายโครงการดำเนินไปได้ตาม schedule จนกระทั่งถึง (และยกเว้น) ช่วง system test ความล้มเหลวในการเผื่อเวลาให้เพียงพอสำหรับ system test โดยเฉพาะอย่างยิ่ง เป็นหายนะที่ประหลาดมาก เพราะความล่าช้านี้มักเกิดขึ้นในช่วงท้ายของ schedule ซึ่งไม่มีใครตระหนักถึงปัญหาของ schedule จนกระทั่งเกือบจะถึงวันส่งมอบ ข่าวร้ายที่มาช้าและไม่มีการเตือนล่วงหน้าย่อมสร้างความปั่นป่วนให้กับทั้งลูกค้าและผู้จัดการ ยิ่งไปกว่านั้น ความล่าช้า ณ จุดนี้ยังมีผลกระทบทางการเงินและทางจิตใจที่รุนแรงอย่างผิดปกติ โครงการมีกำลังคนเต็มอัตรา และต้นทุนต่อวันพุ่งสูงถึงขีดสุด ที่ร้ายแรงกว่านั้นคือ ซอฟต์แวร์มีไว้เพื่อสนับสนุนความพยายามทางธุรกิจอื่นๆ (เช่น การจัดส่งคอมพิวเตอร์ การดำเนินงานของสิ่งอำนวยความสะดวกใหม่ๆ ฯลฯ) และต้นทุนทางอ้อมของการล่าช้าในส่วนนี้จะสูงมาก เพราะมันเกือบจะถึงเวลาที่ต้องจัดส่งซอฟต์แวร์แล้ว อันที่จริง ต้นทุนทางอ้อมเหล่านี้อาจสูงกว่าต้นทุนอื่นๆ ทั้งหมดรวมกันเสียอีก ดังนั้น การเผื่อเวลาให้เพียงพอสำหรับการทำ system test ใน schedule ฉบับร่างแรกจึงเป็นเรื่องสำคัญอย่างยิ่งยวด

Gutless Estimating

สังเกตว่าสำหรับนักเขียนโปรแกรม (programmer) ก็เช่นเดียวกับเชฟ ความเร่งรีบของลูกค้าอาจกำหนดการเสร็จสมบูรณ์ตามกำหนดเวลา (scheduled completion) ของงานได้ แต่ไม่สามารถกำหนดการเสร็จสมบูรณ์ตามจริง (actual completion) ได้ ไข่เจียว (omelette) ที่สัญญาว่าจะเสร็จในสองนาที อาจจะดูเหมือนกำลังดำเนินไปได้ด้วยดี แต่เมื่อมันไม่เซตตัวในสองนาที ลูกค้าก็มีทางเลือกสองทางคือ—รอ หรือกินมันแบบดิบๆ ลูกค้าซอฟต์แวร์เองก็มีทางเลือกแบบเดียวกัน

เชฟยังมีทางเลือกอีกทาง คือการเร่งไฟให้แรงขึ้น ผลลัพธ์มักจะเป็นไข่เจียวที่ไม่มีอะไรกู้คืนได้—ส่วนหนึ่งไหม้ แต่อีกส่วนยังดิบอยู่

ผมไม่ได้คิดว่า software managers มีความกล้าหาญและความเด็ดเดี่ยวในตัวน้อยกว่าเชฟ หรือน้อยกว่าผู้จัดการวิศวกรรมสาขาอื่นๆ แต่การทำ false scheduling (การกำหนดตารางเวลาที่ผิดพลาด) เพื่อให้ตรงกับวันที่ลูกค้าต้องการนั้น พบบ่อยในสาขาวิชาของเรามากกว่าในงานวิศวกรรมด้านอื่นๆ มาก เป็นเรื่องยากมากที่จะปกป้องการประมาณการอย่างแข็งขัน น่าเชื่อถือ และยอมเสี่ยงกับหน้าที่การงาน หากการประมาณการนั้นไม่ได้มาจากวิธีการเชิงปริมาณ (quantitative method) ใดๆ มีข้อมูลสนับสนุนเพียงเล็กน้อย และได้รับการรับรองโดยอาศัยสัญชาตญาณ (hunches) ของผู้จัดการเป็นหลัก

เห็นได้ชัดว่าเราต้องการวิธีแก้ปัญหาสองประการ เราต้องพัฒนาและเปิดเผยตัวเลขผลิตภาพ (productivity figures), ตัวเลขการเกิดบั๊ก (bug-incidence figures), กฎการประมาณการ และอื่นๆ ทั้งวิชาชีพจะได้รับประโยชน์จากการแบ่งปันข้อมูลดังกล่าว จนกว่าการประมาณการจะมีฐานรากที่มั่นคงกว่านี้ ผู้จัดการแต่ละคนจำเป็นต้องทำใจให้แข็งแกร่งและปกป้องการประมาณการของตนด้วยความมั่นใจว่า สัญชาตญาณที่แย่ของพวกเขายังคงดีกว่าการประมาณการที่มาจากการ "วาดฝัน" เอาเอง

Regenerative Schedule Disaster

เราจะทำอย่างไรเมื่อโครงการซอฟต์แวร์ที่สำคัญล่าช้ากว่ากำหนด (behind schedule)? โดยธรรมชาติ เรามักจะเพิ่มกำลังคน (manpower) ดังที่รูปที่ 2.1 ถึง 2.4 แสดงให้เห็นว่าสิ่งนี้อาจช่วยได้หรือไม่ได้ผลเลย

ลองพิจารณาตัวอย่างหนึ่ง สมมติว่างานหนึ่งถูกประมาณการไว้ที่ 12 man-months และมอบหมายให้คนสามคนทำเป็นเวลาสี่เดือน โดยมี mileposts A, B, C, D ที่วัดผลได้ ซึ่งถูกกำหนดให้เสร็จสิ้นในตอนท้ายของแต่ละเดือน (รูปที่ 2.5) ทีนี้สมมติว่า milepost แรกยังไม่เสร็จสิ้นจนกระทั่งเวลาผ่านไปสองเดือน (รูปที่ 2.6) ทางเลือกที่ผู้จัดการต้องเผชิญมีอะไรบ้าง?

1. สมมติว่างานต้องเสร็จตรงเวลา โดยสมมติว่าเฉพาะส่วนแรกของงานเท่านั้นที่ประมาณการผิด (misestimated) ดังนั้นรูปที่ 2.6 จึงบอกเล่าเรื่องราวได้อย่างแม่นยำ ในกรณีนี้ยังเหลือความพยายามอีก 9 man-months และเหลือเวลาอีกสองเดือน ดังนั้นจึงต้องการคน 4 คนครึ่ง นั่นคือต้องเพิ่มคน 2 คนเข้าไปในทีมที่มีอยู่ 3 คน
2. สมมติว่างานต้องเสร็จตรงเวลา โดยสมมติว่าการประมาณการทั้งหมดนั้นต่ำเกินไปอย่างสม่ำเสมอ ดังนั้นรูปที่ 2.7 จึงอธิบายสถานการณ์ที่แท้จริง ในกรณีนี้จะเหลือความพยายามอีก 18 man-months และเหลือเวลาอีกสองเดือน ดังนั้นจึงต้องการคน 9 คน นั่นคือต้องเพิ่มคนอีก 6 คนเข้าไปในทีมเดิม 3 คน

รูปที่ 2.5 รูปที่ 2.6 รูปที่ 2.7

3. ปรับปรุงตารางเวลาใหม่ (Reschedule) ผมชอบคำแนะนำของ P. Fagg วิศวกรฮาร์ดแวร์ผู้มีประสบการณ์ที่ว่า "อย่าเลื่อนทีละนิด" (Take no small slips) นั่นคือ ให้เผื่อเวลาให้เพียงพอใน schedule ใหม่ เพื่อให้มั่นใจว่างาจะสามารถทำได้อย่างระมัดระวังและถี่ถ้วน และจะไม่ต้องมีการปรับปรุง schedule ซ้ำอีก

4. ลดขนาดงานลง (Trim the task) ในทางปฏิบัติ สิ่งนี้มักจะเกิดขึ้นอยู่แล้วเมื่อทีมสังเกตเห็น schedule slippage ในกรณีที่ต้นทุนทางอ้อมจากความล่าช้าสูงมาก นี่คือทางเดียวที่เป็นไปได้ ทางเลือกของผู้จัดการมีเพียงการลดขนาดงานอย่างเป็นทางการและระมัดระวัง การปรับปรุง schedule ใหม่ หรือการเฝ้าดูงานถูกแอบลดขนาดลงเงียบๆ ด้วยการออกแบบที่เร่งรีบและการทดสอบที่ไม่สมบูรณ์

ในสองกรณีแรก การยืนกรานว่างานที่ไม่ได้ถูกลดขนาดจะต้องเสร็จภายในสี่เดือนคือหายนะ พิจารณาถึงผลกระทบที่เกิดซ้ำซ้อน ตัวอย่างเช่น สำหรับทางเลือกแรก (รูปที่ 2.8) คนใหม่สองคน ไม่ว่าจะมีความสามารถเพียงใดหรือรับเข้ามาเร็วแค่ไหนก็ตาม จะต้องได้รับการฝึกอบรม (training) ในงานนั้นโดยหนึ่งในคนที่มีประสบการณ์ หากใช้เวลาหนึ่งเดือน จะเท่ากับว่าเสียเวลาไป 3 man-months กับงานที่ไม่ได้อยู่ในประมาณการเดิม ยิ่งไปกว่านั้น งานที่เดิมแบ่งออกเป็นสามส่วน จะต้องถูกแบ่งส่วนใหม่ (repartitioned) ออกเป็นห้าส่วน ด้วยเหตุนี้ งานบางอย่างที่ทำไปแล้วจะสูญเปล่า และช่วง systems test จะต้องยาวนานขึ้น ดังนั้นเมื่อสิ้นสุดเดือนที่สาม จะยังเหลือความพยายามอีกมากกว่า 7 man-months โดยมีคนที่ผ่าน training แล้ว 5 คน และเหลือเวลาอีกหนึ่งเดือน

ดังที่รูปที่ 2.8 แสดงให้เห็น ผลิตภัณฑ์จะล่าช้าพอๆ กับตอนที่ไม่ได้เพิ่มใครเข้ามาเลย (รูปที่ 2.6) หากหวังว่าจะเสร็จในสี่เดือน โดยพิจารณาเพียงแค่เวลา training และยังไม่รวมการ repartitioning และ systems test ที่เพิ่มขึ้น จะต้องเพิ่มคนถึง 4 คน ไม่ใช่ 2 คน เมื่อสิ้นสุดเดือนที่สอง และเพื่อครอบคลุมผลกระทบจากการ repartitioning และ system test ก็จะต้องเพิ่มคนเข้าไปอีก แต่คราวนี้คุณจะมีทีมอย่างน้อย 7 คน ไม่ใช่ 3 คน ดังนั้น แง่มุมต่างๆ เช่น การจัดองค์กรทีมและการแบ่งงานจึงแตกต่างกันในเชิงคุณภาพ ไม่ใช่แค่เชิงปริมาณ

สังเกตว่าเมื่อสิ้นสุดเดือนที่สาม สถานการณ์จะดูมืดมนมาก milestone ของวันที่ 1 มีนาคม ยังไม่บรรลุถึงแม้จะมีความพยายามในการจัดการอย่างเต็มที่ ความยั่วยวนที่จะทำซ้ำวงจรเดิมโดยการเพิ่มกำลังคน (manpower) เข้าไปอีกนั้นรุนแรงมาก และนั่นแหละคือความบ้าคลั่ง

รูปที่ 2.8

ที่กล่าวมาข้างต้นสมมติว่าเฉพาะ milestone แรกเท่านั้นที่ประมาณการผิด หากในวันที่ 1 มีนาคม เราตั้งสมมติฐานอย่างระมัดระวังว่า schedule นั้นมองโลกในแง่ดีเกินไป ดังที่รูปที่ 2.7 แสดงไว้ เราจะต้องเพิ่มคนถึง 6 คนเพียงเพื่อทำงานเดิมให้เสร็จ การคำนวณผลกระทบจากการ training, การ repartitioning และการ system testing จะละไว้เป็นแบบฝึกหัดให้ผู้อ่านคิดต่อเอง ไม่ต้องสงสัยเลยว่าหายนะที่เกิดซ้ำซ้อนนี้จะให้ผลผลิตที่แย่ลงและล่าช้ากว่าการปรับปรุง schedule ใหม่ด้วยคนสามคนเดิมโดยไม่มีการเพิ่มกำลังคน

หากจะสรุปให้สั้นและง่ายจนเกินจริง เราสามารถระบุ กฎของบรูคส์ (Brooks's Law) ได้ดังนี้:

การเพิ่มกำลังคน (manpower) เข้าไปในโครงการซอฟต์แวร์ที่ล่าช้า จะยิ่งทำให้มันล่าช้ามากขึ้นไปอีก

นี่คือการทำลายมายาคติของ man-month จำนวนเดือนของโครงการขึ้นอยู่กับข้อจำกัดเชิงลำดับ (sequential constraints) ส่วนจำนวนคนสูงสุดขึ้นอยู่กับจำนวนของงานย่อย (subtasks) ที่เป็นอิสระต่อกัน จากปริมาณสองอย่างนี้ เราสามารถกำหนด schedules ที่ใช้คนน้อยลงและใช้เดือนมากขึ้นได้ (ความเสี่ยงเพียงอย่างเดียวคือผลิตภัณฑ์อาจล้าสมัยไปเสียก่อน) อย่างไรก็ตาม เราไม่สามารถสร้าง schedules ที่ใช้งานได้จริงโดยการใช้คนมากขึ้นและใช้เดือนน้อยลง

โครงการซอฟต์แวร์จำนวนมากต้องประสบความล้มเหลวเพราะขาดแคลนเวลาในปฏิทิน มากกว่าสาเหตุอื่นๆ ทั้งหมดรวมกัน