อาหารชั้นดีต้องใช้เวลาในการปรุง หากคุณต้องรอ นั่นคือเพื่อเสิร์ฟสิ่งที่ดีกว่าให้คุณ และเพื่อให้คุณพอใจ
— MENU OF RESTAURANT ANTOINE, NEW ORLEANS
โปรเจกต์ซอฟต์แวร์ล้มเหลวเพราะปัญหาด้านเวลามากกว่าสาเหตุอื่น ๆ ทั้งหมดรวมกันเสียอีก ทำไมสาเหตุของหายนะนี้ถึงพบได้บ่อยนัก?
ประการแรก เทคนิคการประมาณของเรายังพัฒนาได้ไม่ดีพอ ที่ร้ายแรงกว่านั้นคือ มันสะท้อนสมมติฐานที่ไม่ได้พูดออกมาซึ่งไม่เป็นความจริงเลย นั่นคือ ทุกอย่างจะราบรื่นไปหมด
ประการที่สอง เทคนิคการประมาณของเราสับสนระหว่างความพยายามกับความคืบหน้าอย่างผิด ๆ โดยซ่อนสมมติฐานที่ว่าคนและเดือนนั้นสามารถใช้แทนกันได้
ประการที่สาม เพราะเราไม่มั่นใจในการประมาณของตนเอง ผู้จัดการซอฟต์แวร์จึงมักขาดความยืนหยัดอย่างสุภาพเหมือนเชฟของร้าน Antoine
ประการที่สี่ ความคืบหน้าตามกำหนดการถูกติดตามอย่างไม่ดีนัก เทคนิคที่พิสูจน์แล้วและเป็นเรื่องปกติในสาขาวิศวกรรมอื่น ๆ กลับถูกมองว่าเป็นนวัตกรรมหัวรุนแรงในวิศวกรรมซอฟต์แวร์
ประการที่ห้า เมื่อตรวจพบว่ากำหนดการล่าช้า การตอบสนองที่เป็นธรรมชาติ (และเป็นธรรมเนียมปฏิบัติ) คือการเพิ่มคนทำงาน เหมือนกับการเอาน้ำราดไฟ มันทำให้เรื่องแย่ลง ยิ่งแย่ลงมาก ๆ ยิ่งไฟแรงเท่าไหร่ก็ยิ่งต้องใช้น้ำมันมากขึ้นเท่านั้น และนี่คือจุดเริ่มต้นของวงจรที่นำไปสู่หายนะในที่สุด
การติดตามกำหนดการจะเป็นหัวข้อของบทความแยกต่างหาก ขอให้เรามาดูรายละเอียดด้านอื่น ๆ ของปัญหากันก่อน
Optimism (การมองโลกในแง่ดี)
โปรแกรมเมอร์ทุกคนเป็นคนมองโลกในแง่ดี บางทีศาสตร์เวทมนตร์สมัยใหม่นี้อาจดึงดูดคนที่เชื่อในตอนจบที่มีความสุขและนางฟ้าแม่มดเป็นพิเศษ บางทีความหงุดหงิดเล็ก ๆ น้อย ๆ นับร้อยอาจขับไล่คนอื่นออกไป เหลือไว้เพียงคนที่เคยชินกับการจดจ่ออยู่ที่เป้าหมายปลายทาง หรือบางทีมันอาจเป็นแค่เรื่องที่คอมพิวเตอร์ยังเด็ก โปรแกรมเมอร์ยิ่งเด็กกว่า และคนหนุ่มสาวก็มักมองโลกในแง่ดีเสมอ แต่ไม่ว่ากระบวนการคัดเลือกจะทำงานอย่างไร ผลลัพธ์ก็เถียงไม่ได้: "ครั้งนี้มันต้องรันได้แน่" หรือ "เพิ่งเจอบั๊กตัวสุดท้ายนี่เอง"
ดังนั้นสมมติฐานเท็จข้อแรกที่อยู่เบื้องหลังการวางตารางงานของระบบ programming ก็คือ ทุกอย่างจะไปได้สวย นั่นคือ แต่ละงานจะใช้เวลาเท่าที่มัน "ควร" จะใช้เท่านั้น .
การมองโลกในแง่ดีที่แพร่หลายในหมู่โปรแกรมเมอร์สมควรได้รับการวิเคราะห์ที่ลึกซึ้งกว่านี้ Dorothy Sayers ในหนังสือที่ยอดเยี่ยมของเธอ The Mind of the Maker ได้แบ่งกิจกรรมสร้างสรรค์ออกเป็นสามขั้นตอน: แนวคิด (idea), การนำไปปฏิบัติ (implementation), และการโต้ตอบ (interaction) หนังสือ คอมพิวเตอร์ หรือโปรแกรม เกิดขึ้นครั้งแรกในฐานะโครงสร้างในอุดมคติ ที่สร้างขึ้นนอกกาลเวลาและสถานที่ แต่สมบูรณ์ในความคิดของผู้สร้าง จากนั้นมันก็เกิดขึ้นจริงในกาลเวลาและสถานที่ ผ่านปากกา หมึก และกระดาษ หรือผ่านสายไฟ ซิลิคอน และเฟอร์ไรต์ การสร้างจะสมบูรณ์เมื่อมีคนอ่านหนังสือ ใช้คอมพิวเตอร์ หรือรันโปรแกรม นั่นคือการโต้ตอบกับจิตใจของผู้สร้าง
คำอธิบายนี้ ซึ่งคุณ Sayers ใช้ไม่เพียงเพื่ออธิบายกิจกรรมสร้างสรรค์ของมนุษย์เท่านั้น แต่ยังรวมถึงหลักคำสอนเรื่องตรีเอกานุภาพของคริสต์ศาสนาด้วย จะช่วยเราในงานปัจจุบันของเรา เพราะสำหรับผู้สร้างสิ่งต่าง ๆ ที่เป็นมนุษย์ ความไม่สมบูรณ์และความไม่สอดคล้องกันของแนวคิดเราจะชัดเจนก็ต่อเมื่ออยู่ในขั้นตอนการนำไปปฏิบัติเท่านั้น นี่คือเหตุผลที่การเขียน การทดลอง และ "การขัดเกลา" เป็นระเบียบวินัยที่จำเป็นสำหรับนักทฤษฎี
ในกิจกรรมสร้างสรรค์หลายอย่าง สื่อกลางที่ใช้ในการทำงานนั้นดื้อรั้น ไม้แตก สีเลอะ วงจรไฟฟ้ามีสัญญาณรบกวน ข้อจำกัดทางกายภาพของสื่อกลางเหล่านี้จำกัดแนวคิดที่อาจถูกแสดงออก และยังสร้างอุปสรรคที่ไม่คาดคิดในการนำไปปฏิบัติอีกด้วย
การนำไปปฏิบัตินั้นต้องใช้เวลาและความพยายาม ทั้งเพราะสื่อกลางทางกายภาพและเพราะความไม่สมบูรณ์ของแนวคิดพื้นฐาน เรามักจะโทษสื่อกลางทางกายภาพสำหรับปัญหาส่วนใหญ่ในการimplement เพราะสื่อกลางเหล่านั้นไม่ใช่ "ของเรา" ในแบบที่แนวคิดเป็น และความภูมิใจของเราก็บิดเบือนการตัดสิน
แต่การเขียนโปรแกรมคอมพิวเตอร์นั้นสร้างขึ้นด้วยสื่อกลางที่ยืดหยุ่นอย่างยิ่ง โปรแกรมเมอร์สร้างจากวัตถุดิบทางความคิด: แนวคิดและตัวแทนที่ยืดหยุ่นอย่างมากของมัน เพราะสื่อกลางนั้นยืดหยุ่น เราจึงคาดหวังอุปสรรคในการimplement น้อย จึงเกิดการมองโลกในแง่ดีที่แพร่หลาย เพราะแนวคิดของเรามีข้อบกพร่อง เราจึงมีบั๊ก ดังนั้นการมองโลกในแง่ดีของเราจึงไม่มีพื้นฐานที่ถูกต้อง
ในงานเดี่ยว ๆ สมมติฐานที่ว่าทุกอย่างจะไปได้สวยนั้นส่งผลต่อกำหนดการในเชิงความน่าจะเป็น มันอาจจะดำเนินไปตามแผนจริงก็ได้ เพราะมีความน่าจะเป็นของการดีเลย์ที่อาจเกิดขึ้น และ "ไม่ดีเลย์" ก็มีความน่าจะเป็นที่จำกัดอยู่ แต่โปรเจกต์การเขียนโปรแกรมขนาดใหญ่นั้นประกอบด้วยงานหลายงาน บางงานก็ต่อกันเป็นลูกโซ่ ความน่าจะเป็นที่แต่ละงานจะไปได้สวยนั้นแทบจะเป็นศูนย์
The Man-Month (คน-เดือน)
รูปแบบความคิดที่ผิดพลาดประการที่สองนั้นแสดงออกมาผ่านหน่วยของความพยายามที่ใช้ในการประมาณและกำหนดตารางงาน: คน-เดือน (man-month) ต้นทุนนั้นแปรผันตามผลคูณของจำนวนคนและจำนวนเดือนจริง แต่ความคืบหน้านั้นไม่เป็นเช่นนั้น ดังนั้นการใช้คน-เดือนเป็นหน่วยวัดขนาดของงานจึงเป็นมายาคติที่อันตรายและหลอกลวง มันบอกเป็นนัยว่าคนและเดือนสามารถใช้แทนกันได้
คนและเดือนจะสามารถใช้แทนกันได้ก็ต่อเมื่องานสามารถแบ่งออกให้คนทำงานหลายคนทำพร้อมกันได้ โดยที่ไม่ต้องสื่อสารกันระหว่างพวกเขา ( Fig. 2.1 ) ซึ่งเป็นจริงสำหรับการเก็บเกี่ยวข้าวสาลีหรือเก็บฝ้าย แต่มันไม่เป็นความจริงแม้แต่โดยประมาณสำหรับการเขียนโปรแกรมเชิงระบบ
Figure 2.1. เวลากับจำนวนคนทำงาน—งานที่สามารถแบ่งได้อย่างสมบูรณ์แบบ
เมื่องานไม่สามารถแบ่งได้เนื่องจากข้อจำกัดเชิงลำดับ (sequential constraints) การเพิ่มความพยายามมากขึ้นไม่มีผลต่อกำหนดการ ( Fig. 2.2 ) การมีบุตรต้องใช้เวลาเก้าเดือน ไม่ว่าจะจัดสรรผู้หญิงกี่คนก็ตาม งานซอฟต์แวร์จำนวนมากมีลักษณะเช่นนี้เนื่องจากธรรมชาติเชิงลำดับของการดีบั๊ก
Figure 2.2. เวลากับจำนวนคนทำงาน—งานที่ไม่สามารถแบ่งได้
ในงานที่สามารถแบ่งได้แต่ต้องมีการสื่อสารระหว่างงานย่อย ความพยายามในการสื่อสารต้องถูกเพิ่มเข้าไปในปริมาณงานที่ต้องทำ ดังนั้นสิ่งที่ดีที่สุดที่ทำได้ก็คือแย่กว่าการแลกคนกับเดือนแบบสูสี ( Fig. 2.3 )
Figure 2.3. เวลากับจำนวนคนทำงาน—งานที่แบ่งได้แต่ต้องมีการสื่อสาร
ภาระเพิ่มเติมของการสื่อสารประกอบด้วยสองส่วนคือ การฝึกอบรมและการสื่อสารระหว่างกัน คนทำงานแต่ละคนต้องได้รับการฝึกอบรมในเทคโนโลยี เป้าหมายของโครงการ กลยุทธ์โดยรวม และแผนงาน การฝึกอบรมนี้ไม่สามารถแบ่งได้ ดังนั้นส่วนนี้ของความพยายามที่เพิ่มขึ้นจึงแปรผันเชิงเส้นกับจำนวนคนทำงาน [1]
การสื่อสารระหว่างกันยิ่งแย่เข้าไปใหญ่ ถ้าแต่ละส่วนของงานต้องประสานงานแยกกันกับทุกส่วนอื่น ความพยายามจะเพิ่มขึ้นเป็น n ( n –1)/2 คนทำงานสามคนต้องการการสื่อสารระหว่างคู่มากกว่าสองคนถึงสามเท่า สี่คนต้องการมากกว่าสองคนถึงหกเท่า ยิ่งไปกว่านั้น ถ้าต้องมีการประชุมระหว่างสามคน สี่คน ฯลฯ เพื่อแก้ไขปัญหาร่วมกัน สถานการณ์ก็ยิ่งแย่ลงไปอีก ความพยายามที่เพิ่มขึ้นจากการสื่อสารอาจลบล้างการแบ่งงานเดิมทั้งหมด และพาเราไปสู่สถานการณ์ใน Fig. 2.4 .
Figure 2.4. เวลากับจำนวนคนทำงาน—งานที่มีความสัมพันธ์ซับซ้อน
เนื่องจากการสร้างซอฟต์แวร์เป็นความพยายามเชิงระบบโดยธรรมชาติ—เป็นการฝึกฝนในความสัมพันธ์ที่ซับซ้อน—ความพยายามในการสื่อสารจึงมหาศาล และมันครอบงำการลดลงของเวลาทำงานแต่ละคนที่เกิดจากการแบ่งงานอย่างรวดเร็ว การเพิ่มคนมากขึ้นจึงทำให้กำหนดการยาวขึ้น ไม่ใช่สั้นลง
Systems Test (การทดสอบระบบ)
ไม่มีส่วนใดของกำหนดการที่ได้รับผลกระทบจากข้อจำกัดเชิงลำดับเท่ากับการดีบั๊ก component และการทดสอบระบบอีกแล้ว ยิ่งไปกว่านั้น เวลาที่ต้องการยังขึ้นอยู่กับจำนวนและความซับซ้อนของข้อผิดพลาดที่พบอีกด้วย ในทางทฤษฎี จำนวนนี้ควรเป็นศูนย์ แต่เพราะการมองโลกในแง่ดี เรามักคาดหวังว่าจำนวนบั๊กจะน้อยกว่าที่เป็นจริง ดังนั้นการทดสอบจึงมักเป็นส่วนที่ถูกประมาณผิดมากที่สุดในการเขียนโปรแกรม
เป็นเวลาหลายปีที่ผมใช้กฎง่าย ๆ ต่อไปนี้ในการกำหนดตารางงานซอฟต์แวร์ได้สำเร็จ:
1/3 การวางแผน
1/6 การเขียนโค้ด
1/4 การทดสอบ component และการทดสอบระบบช่วงต้น
1/4 การทดสอบระบบ เมื่อมีทุก component อยู่ในมือแล้ว
วิธีนี้แตกต่างจากการกำหนดตารางงานแบบทั่วไปในหลายประเด็นสำคัญ:
1. สัดส่วนที่จัดสรรให้การวางแผนมากกว่าปกติ ถึงกระนั้นก็แทบจะเพียงพอต่อการสร้างสเป็คที่ละเอียดและแข็งแกร่งเท่านั้น และไม่เพียงพอสำหรับการวิจัยหรือสำรวจเทคนิคใหม่ ๆ โดยสิ้นเชิง
2. ครึ่งหนึ่ง ของกำหนดการที่อุทิศให้กับการดีบั๊กโค้ดที่เขียนเสร็จแล้วนั้นมากกว่าปกติมาก
3. ส่วนที่ประมาณได้ง่ายที่สุด นั่นคือการเขียนโค้ด กลับได้รับเพียงหนึ่งในหกของกำหนดการเท่านั้น
ในการตรวจสอบโปรเจกต์ที่วางกำหนดการแบบทั่วไป ผมพบว่ามีไม่กี่โปรเจกต์ที่จัดสรรเวลาครึ่งหนึ่งของกำหนดการที่วางแผนไว้สำหรับการทดสอบ แต่ส่วนใหญ่แล้วก็ใช้เวลาจริงครึ่งหนึ่งของกำหนดการไปกับจุดประสงค์นั้นจริง ๆ หลายโปรเจกต์เหล่านี้เป็นไปตามกำหนดการจนถึงและยกเว้นการทดสอบระบบ [2]
การไม่จัดเวลาให้เพียงพอสำหรับการทดสอบระบบนั้นสร้างความเสียหายอย่างยิ่งเป็นพิเศษ เนื่องจากความล่าช้ามาตอนท้ายของกำหนดการ จึงไม่มีใครรู้ว่ามีปัญหากับกำหนดการจนกระทั่งเกือบถึงวันส่งมอบ ข่าวร้ายที่มาช้าและไม่มีการเตือนล่วงหน้าทำให้ลูกค้าและผู้จัดการไม่สบายใจ
ยิ่งไปกว่านั้น ความล่าช้า ณ จุดนี้ส่งผลกระทบทางการเงินที่รุนแรงผิดปกติ รวมถึงผลกระทบทางจิตวิทยาด้วย โปรเจกต์มีคนทำงานเต็มอัตรา และต้นทุนต่อวันก็สูงที่สุด ที่ร้ายแรงกว่านั้นคือ ซอฟต์แวร์นี้ต้องรองรับความพยายามทางธุรกิจอื่น ๆ (การจัดส่งคอมพิวเตอร์ การดำเนินงานสิ่งอำนวยความสะดวกใหม่ ฯลฯ) และต้นทุนทุติยภูมิจากการล่าช้าเหล่านี้สูงมาก เพราะใกล้ถึงเวลาส่งมอบซอฟต์แวร์แล้ว อันที่จริง ต้นทุนทุติยภูมิเหล่านี้อาจสูงกว่าต้นทุนอื่น ๆ ทั้งหมดเสียอีก ดังนั้นจึงสำคัญอย่างยิ่งที่จะต้องจัดสรรเวลาทดสอบระบบให้เพียงพอในกำหนดการเดิม
Gutless Estimating (การประมาณที่ไร้ความกล้า)
สังเกตว่าสำหรับโปรแกรมเมอร์ เช่นเดียวกับเชฟ ความเร่งด่วนของลูกค้าอาจกำหนดวันแล้วเสร็จตามกำหนดการ แต่มันไม่สามารถกำหนดวันแล้วเสร็จจริงได้ ไข่เจียวที่สัญญาว่าจะเสร็จในสองนาทีอาจดูเหมือนกำลังไปได้สวย แต่เมื่อมันไม่เซ็ตตัวในสองนาที ลูกค้ามีสองทางเลือก—รอหรือกินดิบ ๆ ลูกค้าซอฟต์แวร์ก็มีทางเลือกเดียวกัน
พ่อครัวมีอีกทางเลือกหนึ่ง เขาสามารถเร่งไฟได้ ผลลัพธ์มักจะเป็นไข่เจียวที่ไม่มีอะไรช่วยได้—ไหม้ด้านหนึ่ง ดิบอีกด้านหนึ่ง
ผมไม่คิดว่าผู้จัดการซอฟต์แวร์มีความกล้าและความแน่วแน่น้อยกว่าเชฟโดยธรรมชาติ หรือน้อยกว่าผู้จัดการวิศวกรรมคนอื่น ๆ แต่การกำหนดตารางงานที่ผิดพลาดเพื่อให้ตรงกับวันที่ลูกค้าต้องการนั้นพบได้บ่อยกว่าในสาขาของเรามากเมื่อเทียบกับสาขาวิศวกรรมอื่น มันยากมากที่จะปกป้องการประมาณที่ไม่ได้มาจากวิธีการเชิงปริมาณ ไม่มีข้อมูลสนับสนุน และรับรองโดยสัญชาตญาณของผู้จัดการเท่านั้น อย่างแข็งขัน มีเหตุผล และเสี่ยงต่องาน
แน่นอนว่าต้องมีสองแนวทางแก้ไข เราจำเป็นต้องพัฒนาและเผยแพร่ตัวเลขผลิตภาพ ตัวเลขอัตราการเกิดบั๊ก กฎการประมาณ และอื่น ๆ วงการวิชาชีพทั้งหมดจะได้รับประโยชน์จากการแบ่งปันข้อมูลดังกล่าว
จนกว่าการประมาณจะมีพื้นฐานที่มั่นคงกว่านี้ ผู้จัดการแต่ละคนจะต้องทำให้กระดูกสันหลังของตนแข็งแกร่งขึ้น และปกป้องการประมาณของตนด้วยความมั่นใจว่าสัญชาตญาณที่ไม่ดีของพวกเขายังดีกว่าการประมาณที่เกิดจากความปรารถนา
Regenerative Schedule Disaster (หายนะแบบฟื้นตัวได้เองของกำหนดการ)
จะทำอย่างไรเมื่อโปรเจกต์ซอฟต์แวร์ที่สำคัญล่าช้ากว่ากำหนดการ? ก็เพิ่มคนสิ ตามปกติ ดังที่ Figs. 2.1 ถึง 2.4 ชี้ให้เห็น นั่นอาจจะช่วยหรือไม่ช่วยก็ได้
ลองพิจารณาตัวอย่างดู [3] สมมติว่างานถูกประมาณไว้ที่ 12 คน-เดือน และมอบหมายให้คนสามคนทำในเวลาสี่เดือน และมีจุดตรวจวัด A, B, C, D ที่กำหนดไว้ให้แล้วเสร็จปลายแต่ละเดือน ( Fig. 2.5 )
Figure 2.5.
ทีนี้สมมติว่าจุดตรวจวัดแรกไม่สำเร็จจนกระทั่งสองเดือนผ่านไป ( Fig. 2.6 ) ผู้จัดการมีทางเลือกอะไรบ้าง?
1. สมมติว่างานต้องทำให้เสร็จตรงเวลา สมมติว่ามีเพียงส่วนแรกของงานที่ถูกประมาณต่ำเกินไป ดังนั้น Fig. 2.6 บอกเรื่องราวได้ถูกต้อง แล้วจะเหลือความพยายาม 9 คน-เดือน และอีกสองเดือน ดังนั้นจะต้องใช้ 4.5 คน เพิ่มอีก 2 คนจาก 3 คนที่มี
Figure 2.6.
2. สมมติว่างานต้องทำให้เสร็จตรงเวลา สมมติว่าการประมาณทั้งหมดต่ำเกินไปอย่างสม่ำเสมอ ดังนั้น Fig. 2.7 อธิบายสถานการณ์ได้ถูกต้อง แล้วจะเหลือความพยายาม 18 คน-เดือน และอีกสองเดือน ดังนั้นจะต้องใช้ 9 คน เพิ่มอีก 6 คนจาก 3 คนที่มี
Figure 2.7.
3. กำหนดตารางงานใหม่ ผมชอบคำแนะนำของ P. Fagg วิศวกรฮาร์ดแวร์ผู้มีประสบการณ์: "อย่าให้ลื่นไถลน้อย ๆ" นั่นคือ จัดเวลาให้เพียงพอในกำหนดการใหม่เพื่อให้แน่ใจว่างานสามารถทำได้อย่างรอบคอบและละเอียดถี่ถ้วน และไม่ต้องมากำหนดการใหม่ซ้ำอีก
4. ลดขอบเขตงาน ในทางปฏิบัติสิ่งนี้มักเกิดขึ้นอยู่แล้วเมื่อทีมสังเกตเห็นกำหนดการล่าช้า ในกรณีที่ต้นทุนทุติยภูมิของความล่าช้าสูงมาก นี่เป็นทางเลือกเดียวที่ทำได้ ทางเลือกเดียวของผู้จัดการคือลดขอบเขตงานอย่างเป็นทางการและระมัดระวัง กำหนดตารางงานใหม่ หรือปล่อยให้งานถูกตัดทอนอย่างเงียบ ๆ ด้วยการออกแบบที่เร่งรีบและการทดสอบที่ไม่สมบูรณ์
ในสองกรณีแรก การยืนกรานว่างานที่ไม่มีการเปลี่ยนแปลงต้องเสร็จในสี่เดือนนั้นเป็นหายนะ ลองพิจารณาผลกระทบแบบฟื้นตัวได้เอง เช่น สำหรับทางเลือกแรก ( Fig. 2.8 ) คนใหม่สองคน ไม่ว่าพวกเขาจะมีความสามารถแค่ไหนและได้รับการว่าจ้างเร็วแค่ไหน ก็ต้องได้รับการฝึกอบรมเกี่ยวกับงานจากคนที่มีประสบการณ์คนหนึ่ง ถ้าสิ่งนี้ใช้เวลาหนึ่งเดือน 3 คน-เดือนจะถูกใช้ไปกับงานที่ไม่ได้อยู่ในประมาณการเดิม ยิ่งไปกว่านั้น งานที่เดิมแบ่งออกเป็นสามส่วนต้องถูกแบ่งใหม่เป็นห้าส่วน ดังนั้นงานที่ทำไปแล้วบางส่วนจะสูญเสียไป และการทดสอบระบบก็ต้องยาวนานขึ้น ดังนั้น ณ สิ้นเดือนที่สาม จะเหลือความพยายามมากกว่า 7 คน-เดือนอย่างมีนัยสำคัญ และมีคนที่ได้รับการฝึกอบรมแล้ว 5 คนกับเวลาอีกหนึ่งเดือน ดังที่ Fig. 2.8 ชี้ให้เห็น ผลลัพธ์ก็ล่าช้าพอ ๆ กับที่ไม่ได้เพิ่มใครเลย ( Fig. 2.6 )
Figure 2.8.
หากหวังว่าจะทำให้เสร็จในสี่เดือน โดยพิจารณาเฉพาะเวลาในการฝึกอบรมและไม่รวมการแบ่งงานใหม่และการทดสอบระบบที่เพิ่มขึ้น ก็จะต้องเพิ่มคน 4 คน ไม่ใช่ 2 คน ณ สิ้นเดือนที่สอง เพื่อครอบคลุมผลของการแบ่งงานใหม่และการทดสอบระบบ ก็ต้องเพิ่มคนอีก ตอนนี้เรามีทีมอย่างน้อย 7 คน ไม่ใช่ 3 คน ดังนั้นแง่มุมต่าง ๆ เช่น การจัดองค์กรทีมและการแบ่งงานจึงแตกต่างกันในเชิงชนิด ไม่ใช่แค่ในเชิงปริมาณ
สังเกตว่า ณ สิ้นเดือนที่สาม สถานการณ์ดูมืดมนมาก จุดตรวจวัดวันที่ 1 มีนาคมยังไม่สำเร็จแม้จะมีความพยายามบริหารจัดการทั้งหมด สิ่งล่อใจให้ทำซ้ำวงจรอีก โดยเพิ่มคนมากขึ้นอีกนั้นมีพลังมาก และนั่นคือหนทางสู่ความบ้าคลั่ง
สิ่งที่กล่าวมาข้างต้นสมมติว่ามีเพียงจุดตรวจวัดแรกเท่านั้นที่ถูกประมาณต่ำเกินไป ถ้าในวันที่ 1 มีนาคม เราตั้งสมมติฐานแบบอนุรักษ์นิยมว่ากำหนดการทั้งหมดมองโลกในแง่ดีเกินไป ดังที่ Fig. 2.7 แสดงให้เห็น เราจะต้องเพิ่มคน 6 คนให้กับงานเดิม การคำนวณผลกระทบของการฝึกอบรม การแบ่งงานใหม่ และการทดสอบระบบขอฝากไว้เป็นแบบฝึกหัดสำหรับผู้อ่าน ไม่ต้องสงสัยเลยว่าหายนะแบบฟื้นตัวได้เองจะให้ผลลัพธ์ที่แย่กว่าและช้ากว่าการกำหนดตารางงานใหม่กับคนเดิมสามคนโดยไม่เพิ่มใคร
ถ้าจะพูดให้เกินจริงอย่างมหันต์ เราขอกล่าวถึง Brooks's Law:
การเพิ่มคนทำงานให้กับโปรเจกต์ซอฟต์แวร์ที่ล่าช้าทำให้มันล่าช้ายิ่งขึ้น
นี่คือการขจัดมายาคติของ man-month จำนวนเดือนของโปรเจกต์ขึ้นอยู่กับข้อจำกัดเชิงลำดับของมัน จำนวนคนสูงสุดขึ้นอยู่กับจำนวนงานย่อยที่เป็นอิสระต่อกัน จากสองปริมาณนี้ เราสามารถหากำหนดการที่ใช้คนน้อยลงและใช้เวลามากขึ้น (ความเสี่ยงเดียวคือความล้าสมัยของผลิตภัณฑ์) แต่เราไม่สามารถหากำหนดการที่ใช้งานได้โดยใช้คนมากขึ้นและเวลาเดือนน้อยลง โปรเจกต์ซอฟต์แวร์ล้มเหลวเพราะขาดเวลาในปฏิทินมากกว่าสาเหตุอื่นทั้งหมดรวมกันเสียอีก