คู่มือฉบับสมบูรณ์เกี่ยวกับระเบียบวิธี Waterfall ในการพัฒนาโครงการ

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

ในบรรดาวิธีการต่างๆ ที่กล่าวมา วิธีการแบบ Waterfall ยังคงเป็นหนึ่งในวิธีการที่รู้จักกันดีที่สุด แม้ว่า Agile, Scrum และ Kanban จะเป็นที่พูดถึงกันอย่างกว้างขวาง แต่ Waterfall ก็ยังคงได้รับความนิยมอย่างมากในภาคส่วนที่ความเสถียร ความสามารถในการคาดการณ์ และเอกสารประกอบที่ครบถ้วนมีความสำคัญมากกว่าความยืดหยุ่นอย่างสมบูรณ์ ในคู่มือฉบับนี้ ผมจะอธิบายทีละขั้นตอนว่า Waterfall คืออะไร มาจากไหน มีโครงสร้างอย่างไร เมื่อใดจึงเหมาะสมที่จะใช้ แตกต่างจาก Agile อย่างไร และเข้ากับงานบริหารโครงการสมัยใหม่ได้อย่างไร

ระเบียบวิธี Waterfall คืออะไร?

ระเบียบวิธีแบบน้ำตก (Waterfall methodology) เป็นแบบจำลองการพัฒนาเชิงเส้นและต่อเนื่องที่โครงการดำเนินไปทีละขั้นตอนโดยไม่มีอุปสรรคอย่างเป็นระบบ ชื่อ "น้ำตก" มาจากภาพนี้โดยตรง: แต่ละขั้นตอนจะส่งต่อผลลัพธ์ไปยังขั้นตอนถัดไป เหมือนน้ำที่ไหลลงมาจากขั้นหนึ่งไปยังอีกขั้นหนึ่ง และเมื่อคุณลงไปขั้นหนึ่งแล้ว การจะกลับขึ้นมานั้นยากมาก

ในทางปฏิบัติ หมายความว่าวงจรชีวิตของโครงการจะเสร็จสมบูรณ์เพียงครั้งเดียว ตั้งแต่เริ่มต้นจนจบ : ขั้นแรก รวบรวมข้อกำหนดทั้งหมด จากนั้น ออกแบบโซลูชัน ต่อมา ดำเนินการ ทดสอบ และสุดท้าย นำไปใช้งานและบำรุงรักษา แต่ละขั้นตอนจะต้องเสร็จสมบูรณ์และได้รับการอนุมัติก่อนที่จะเริ่มขั้นตอนถัดไป โดยมีผลลัพธ์ที่เป็นรูปธรรมและเกณฑ์การสิ้นสุดที่กำหนดไว้อย่างชัดเจน

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

ที่มาและวิวัฒนาการของแบบจำลองน้ำตก

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

ในด้านการพัฒนาซอฟต์แวร์ ตัวอย่างแรกๆ อย่างหนึ่งย้อนกลับไปในเดือนมิถุนายน ปี 1956 เมื่อเฮอร์เบิร์ต ดี. เบนิงตันนำเสนอโมเดลแบบเป็นขั้นตอนสำหรับระบบขนาดใหญ่ อย่างไรก็ตาม คำอธิบายที่ถือว่าเป็นแบบคลาสสิกของโมเดลแบบน้ำตกนั้นมาจากวินสตัน ดับเบิลยู. รอยซ์ในบทความปี 1970 เกี่ยวกับการจัดการโครงการพัฒนาซอฟต์แวร์ขนาดใหญ่ หลายปีต่อมา ในปี 1976 เบลล์และเธเยอร์ได้ทำให้คำว่า "น้ำตก" เป็นที่นิยมและอ้างอิงถึงรอยซ์เป็นแหล่งอ้างอิง

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

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

วิธีการทำงานของระเบียบวิธี Waterfall

ในโครงการที่บริหารจัดการโดยใช้แนวทางแบบน้ำตก (waterfall approach) แต่ละขั้นตอนจะดำเนินไปตามลำดับอย่างเคร่งครัดขั้นตอนใหม่จะไม่เริ่มต้นจนกว่าขั้นตอนก่อนหน้าจะเสร็จสมบูรณ์และในทางทฤษฎีแล้ว จะไม่มีการย้อนกลับ เว้นแต่จะมีปัญหาที่ร้ายแรงมากเกิดขึ้น หรือมีการเปลี่ยนแปลงในสัญญา

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

ขั้นตอนของวิธีการน้ำตก

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

1. ข้อกำหนด

ขั้นตอนการกำหนดความต้องการเป็นหัวใจสำคัญของโครงการแบบ Waterfall ทุกโครงการ เป้าหมายในขั้นตอนนี้คือการรวบรวม ความต้องการและข้อจำกัด ทั้งหมดของลูกค้าและธุรกิจ ทั้งในด้านฟังก์ชันการทำงาน (ระบบต้องทำอะไรได้บ้าง) และด้านที่ไม่ใช่ฟังก์ชันการทำงาน (ประสิทธิภาพ ความปลอดภัย ข้อกำหนดต่างๆ เป็นต้น)

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

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

2 การวิเคราะห์

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

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

3. การออกแบบหรือแนวคิด

ขั้นตอนการออกแบบจะเปลี่ยน "อะไร" ให้เป็น "อย่างไร" โดยเริ่มต้นจากข้อกำหนดที่กำหนดไว้ ทีมสถาปัตยกรรมและการออกแบบจะกำหนดโครงสร้างของโซลูชันทั้งหมดในด้านซอฟต์แวร์ มักจะแบ่งออกเป็น การออกแบบระดับสูง (สถาปัตยกรรม โมดูล อินเทอร์เฟซ เทคโนโลยี) และการออกแบบรายละเอียด (อัลกอริทึม ฐานข้อมูล แผนผังอินเทอร์เฟซ ฯลฯ)

ในภาคส่วนอื่นๆ ขั้นตอนนี้เทียบเท่ากับแบบก่อสร้าง การคำนวณโครงสร้าง แผนผังไฟฟ้า หรือรายการวัสดุ เป้าหมายคือการดำเนินการในขั้นตอนต่อไปจะเป็นการนำแบบมาใช้ได้อย่างซื่อตรง โดย ไม่ต้องตีความข้อกำหนดใหม่

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

4. การนำไปปฏิบัติหรือการพัฒนา

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

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

แม้ว่าจะมีการตรวจสอบภายในและการทดสอบหน่วยย่อย แต่ระเบียบวิธี Waterfall แบบดั้งเดิมจะสงวนการตรวจสอบอย่างเป็นทางการไว้สำหรับขั้นตอนถัดไป เมื่อระบบทั้งหมดได้รับการบูรณาการแล้ว

5. การตรวจสอบ การทดสอบ และการรับรอง

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

การตรวจสอบความถูกต้องเกี่ยวข้องกับการตรวจสอบให้แน่ใจว่าผลิตภัณฑ์ได้รับการสร้างขึ้นอย่างถูกต้อง: ระบบจะถูกเปรียบเทียบกับข้อกำหนดการออกแบบ และจะมีการทดสอบระดับหน่วย การทดสอบการบูรณาการ และการทดสอบระบบเพื่อค้นหาข้อผิดพลาดทางเทคนิค เมื่อมีการใช้งาน API จะใช้เครื่องมือต่างๆ เช่นคู่มือการทดสอบ API ของ Postmanคำตอบคือ: "เราสร้างระบบตามการออกแบบหรือไม่?"

ในทางกลับกัน การตรวจสอบความถูกต้องมุ่งเน้นไปที่การตรวจสอบว่าผลิตภัณฑ์นั้นถูกต้อง กล่าวคือตรงตามความต้องการและข้อกำหนดของผู้ใช้ตามที่กำหนดไว้ตั้งแต่แรก เป็นการตอบคำถามว่า "ระบบนี้สามารถแก้ปัญหาทางธุรกิจได้อย่างแท้จริงหรือไม่"

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

6. การติดตั้งหรือเริ่มต้นใช้งาน

เมื่อการทดสอบอย่างเป็นทางการและการยอมรับจากลูกค้าเสร็จสมบูรณ์ ผลิตภัณฑ์จะเข้าสู่ขั้นตอนการติดตั้งใช้งานหรือการผลิต ในด้านซอฟต์แวร์ ขั้นตอนนี้อาจเกี่ยวข้องกับการติดตั้งระบบในสภาพแวดล้อมสุดท้าย การย้ายข้อมูล การฝึกอบรมผู้ใช้ และการผสานรวมระบบใหม่เข้ากับระบบที่มีอยู่ ซึ่งความรู้เกี่ยวกับ การจัดการ APIจะมีประโยชน์

ในภาคส่วนอื่นๆ เหตุการณ์สำคัญนี้หมายถึงการเปิดใช้งานสิ่งอำนวยความสะดวก การส่งมอบโรงงานอุตสาหกรรม หรือการใช้งานโครงสร้างพื้นฐาน ในลักษณะต่อเนื่อง เหตุการณ์สำคัญนี้ยังบ่งบอกถึงการสิ้นสุดของโครงการพัฒนาและการเริ่มต้นของขั้นตอนการบำรุงรักษาด้วย

7 Mantenimiento

หลังจากเริ่มใช้งานแล้ว ขั้นตอนการบำรุงรักษาจะเริ่มต้นขึ้น ซึ่งในหลายกรณีเป็นขั้นตอนที่ยาวที่สุดในวงจรชีวิตขั้นตอนนี้เกี่ยวข้องกับการแก้ไขข้อผิดพลาดที่เกิดขึ้น การปรับระบบให้เข้ากับการเปลี่ยนแปลงเฉพาะในสภาพแวดล้อม (ข้อกำหนด ระบบภายนอก ฮาร์ดแวร์) และการปรับปรุงเล็กน้อย

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

บทบาทสำคัญของเอกสารประกอบในกระบวนการ Waterfall

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

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

แผนโครงการและฐานข้อมูลเริ่มต้น

แผนโครงการในสภาพแวดล้อมแบบ Waterfall เปรียบเสมือนแผนที่เส้นทาง ที่แท้จริง มันกำหนดขอบเขต กำหนดการโดยละเอียด ทรัพยากร เหตุการณ์สำคัญ ความเสี่ยง และเกณฑ์การยอมรับสำหรับแต่ละขั้นตอน โดยทั่วไปจะนำเสนอด้วยแผนภูมิ Gantt ที่มีรายละเอียดสูง และกำหนดการทบทวนอย่างเป็นทางการเมื่อสิ้นสุดแต่ละขั้นตอน

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

เอกสารระบุความต้องการเป็นเอกสารสำคัญ

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

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

การตรวจสอบย้อนกลับและบันทึกการทดสอบ

อีกหนึ่งลักษณะเด่นของวิธีการแบบ Waterfall คือการใช้เมทริกซ์การตรวจสอบย้อนกลับ ซึ่งเชื่อมโยงข้อกำหนดแต่ละข้อเข้ากับองค์ประกอบการออกแบบที่นำไปใช้ และกรณีทดสอบที่ใช้ตรวจสอบความถูกต้อง การดูแลรักษาเมทริกซ์เหล่านี้ต้องอาศัยวินัย แต่มีคุณค่าอย่างยิ่งในการตรวจสอบและรับรอง

แผนการทดสอบ สคริปต์ ผลลัพธ์ และรายงานการตรวจสอบ ล้วนเป็นหลักฐานที่แสดงให้เห็นว่าระบบได้รับการทดสอบอย่างเป็นระบบแล้วในภาคส่วนต่างๆ เช่น ยา การบินและอวกาศ และการรถไฟ บันทึกเหล่านี้เป็นสิ่งจำเป็นและต้องเก็บรักษาไว้เป็นเวลาหลายปี

เอกสารสำคัญใช่ แต่ระบบราชการไม่ยุ่งยาก

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

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

ข้อดีของวิธีการแบบน้ำตก (Waterfall methodology)

น้ำตกไม่ใช่ยารักษาโรคได้ทุกชนิด แต่ในบริบทที่เหมาะสม น้ำตกมีจุดแข็งหลายประการที่หาอะไรมาเทียบได้ยาก นี่คือจุดแข็งที่โดดเด่นที่สุด

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

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

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

นอกจากนี้ การกำหนดขั้นตอนต่างๆ ไว้อย่างชัดเจนยังช่วยให้วัดความคืบหน้าของโครงการและรายงานต่อผู้บริหารได้ง่ายขึ้น สามารถใช้เทคนิคต่างๆ เช่น การประเมินมูลค่าที่ได้รับ (Earned Value) และเปรียบเทียบกับแผนงานเริ่มต้นได้อย่างเป็นกลาง

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

ข้อจำกัดและความเสี่ยงของวิธีการแบบน้ำตก

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

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

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

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

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

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

น้ำตกในการพัฒนาซอฟต์แวร์

ในวงการพัฒนาซอฟต์แวร์ โมเดล Waterfall เป็นโมเดลที่โดดเด่นมา นานหลายปี โดยเฉพาะในระบบขนาดใหญ่สำหรับภาครัฐ กองทัพ ธนาคาร และโทรคมนาคม ลำดับขั้นตอน "ความต้องการ-การออกแบบ-การเขียนโค้ด-การทดสอบ-การบำรุงรักษา" นั้นสอดคล้องกับแนวคิดทางวิศวกรรมในยุคนั้น

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

ด้วยเหตุนี้ ทีมพัฒนาซอฟต์แวร์ที่เน้นผลิตภัณฑ์ส่วนใหญ่จึงนำ วิธีการ แบบ Agile และแบบวนซ้ำมาใช้ (เช่น Scrum, Kanban, Lean เป็นต้น) ซึ่งช่วยให้สามารถเพิ่มผลผลิตได้บ่อยครั้ง ตรวจสอบสมมติฐานทางธุรกิจ และปรับเปลี่ยนทิศทางได้อย่างรวดเร็ว

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

เมื่อใดจึงเหมาะสมที่จะใช้ระเบียบวิธีแบบน้ำตก (waterfall methodology)?

การเลือกใช้ระหว่าง Waterfall และ Agile ไม่ได้ขึ้นอยู่กับกระแส แต่ขึ้นอยู่กับบริบท มีสถานการณ์ที่ Waterfall เป็นตัวเลือกที่เหมาะสมมากและก็มีสถานการณ์ที่มันเป็นการทำลายวิธีการทำงานอย่างสิ้นเชิง

โครงการที่มีข้อกำหนดที่คงที่และเป็นที่รู้จักดี

สถานการณ์ที่เหมาะสมที่สุดสำหรับโมเดล Waterfall คือสถานการณ์ที่ข้อกำหนดมีความชัดเจน ครบถ้วน และไม่น่าจะเปลี่ยนแปลงตัวอย่างเช่น การย้ายระบบเดิมไปยังแพลตฟอร์มใหม่โดยคงฟังก์ชันการทำงานเดิมไว้ การจำลองโรงงานอุตสาหกรรมที่ประสบความสำเร็จในสถานที่อื่น หรือการติดตั้งระบบ ERP โดยมีขอบเขตที่กำหนดไว้ในสัญญา

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

สภาพแวดล้อมที่มีการควบคุมและมีความสำคัญสูง

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

ในขอบเขตเหล่านี้ การจัดทำเอกสารที่ไม่ละเอียดถี่ถ้วนและการทดลองอย่างต่อเนื่องของแนวทางการพัฒนาแบบ Agile บางอย่าง ไม่สอดคล้องกับข้อกำหนดการรับรอง ระเบียบวิธีแบบ Waterfall ให้กรอบการจัดทำเอกสาร ที่จำเป็น สำหรับการผ่านการตรวจสอบอย่างเป็นทางการและขั้นตอนการตรวจสอบตามกฎระเบียบ

สัญญาแบบราคาคงที่และการว่าจ้างภายนอก

เมื่อซัพพลายเออร์เซ็นสัญญาราคาคงที่ พวกเขาจำเป็นต้องลดความไม่แน่นอนให้น้อยที่สุด โมเดลแบบน้ำตก (Waterfall model) เหมาะสมกับเรื่องนี้เป็นอย่างดี เพราะขอบเขตงานจะได้รับการเจรจา บันทึก และกำหนดอย่างแน่นอนก่อนที่จะมีการผูกมัดใดๆ การเปลี่ยนแปลงใดๆ ในภายหลังจะมีกระบวนการที่เป็นทางการของตนเอง และมักเกี่ยวข้องกับการเจรจาต่อรองต้นทุนและกำหนดเวลาใหม่

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

วัฒนธรรมองค์กรที่ไม่ค่อยยอมรับความไม่แน่นอน

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

โมเดลแบบน้ำตก (Waterfall model) เหมาะที่สุดสำหรับโครงสร้างที่ให้ความสำคัญกับแผนงานที่ชัดเจนตั้งแต่เริ่มต้น โดยมีการรายงานความคืบหน้าเป็นลำดับขั้นและมีการตรวจสอบอย่างเป็นทางการ ในที่นี้ ผู้จัดการโครงการทำหน้าที่เป็นผู้พิทักษ์แผนงานพื้นฐาน (baseline ) มากกว่าเป็นผู้สนับสนุนการดำเนินงานในแต่ละรอบ

การบูรณาการผู้ขายหลายรายและโครงการขนาดใหญ่

ในโครงการขนาดใหญ่ที่มีผู้รับเหมาหลายราย (เช่น อุตสาหกรรมยานยนต์ การต่อเรือ หรือโครงสร้างพื้นฐานขนาดใหญ่) โมเดลแบบน้ำตก (Waterfall model) ทำหน้าที่เป็นภาษากลางในการประสานงานส่วนต่อประสานต่างๆผู้จำหน่ายแต่ละรายจะพัฒนาซับซิสเต็มของตนตามข้อกำหนดส่วนต่อประสานที่กำหนดไว้ และการทดสอบการบูรณาการจะถูกวางแผนไว้ล่วงหน้าเป็นอย่างดี

หากแต่ละทีมทำงานโดยมีการเปลี่ยนแปลงลำดับความสำคัญและดำเนินงานเป็นรอบ ๆ อย่างอิสระโดยไม่มีกรอบการทำงานโดยรวม การบูรณาการก็จะเกิดความวุ่นวาย วิธีการแบบเป็นลำดับขั้นตอนทำให้สามารถกำหนดจุดบูรณาการที่ชัดเจนและควบคุมห่วงโซ่อุปทานได้ดียิ่งขึ้น

เมื่อใดที่ไม่ควรใช้เทคนิค Waterfall?

การรู้ว่าวิธีการวิเคราะห์แบบ Waterfall มีประสิทธิภาพสูงสุดในสถานการณ์ใดนั้นสำคัญพอๆ กับการรู้ว่าสถานการณ์ใดที่ควรละทิ้งวิธีการวิเคราะห์แบบ Waterfall โดยไม่ลังเลตัวอย่างสถานการณ์ทั่วไปบางส่วน:

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

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

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

Agile กับ Waterfall: ความแตกต่างที่สำคัญ

การเปรียบเทียบระหว่าง Waterfall และ Agile มักถูกหยิบยกขึ้นมาพูดคุยในแทบทุกการสนทนาเกี่ยวกับการบริหารโครงการ ทั้งสองแบบไม่ได้ดีหรือแย่โดยเนื้อแท้ เพียงแต่สะท้อนให้เห็นถึงปรัชญาที่แตกต่างกันเท่านั้น

แบบจำลอง Waterfall เสนอแนวทางเชิงเส้นและเป็นลำดับ: เริ่มจากการกำหนดทุกอย่าง จากนั้นออกแบบ พัฒนา ทดสอบ และส่งมอบ ในทางกลับกัน แบบจำลอง Agile แบ่งงานออกเป็นรอบการทำงานสั้นๆ (Sprint) โดยในแต่ละรอบจะมีการวางแผน ออกแบบ พัฒนา และทดสอบฟังก์ชันการทำงานจำนวนเล็กน้อย

ในวิธีการพัฒนาแบบ Waterfall ขอบเขตงานจะถูกกำหนดไว้ตั้งแต่เริ่มต้น และการเปลี่ยนแปลงถือเป็นข้อยกเว้นที่มีค่าใช้จ่ายสูง ในขณะที่วิธีการพัฒนาแบบ Agile การเปลี่ยนแปลงถือเป็นเรื่องปกติ และผลิตภัณฑ์จะพัฒนาไปทีละสปรินต์ โดยปรับ Backlog ตามความคิดเห็นของผู้ใช้และฝ่ายธุรกิจ

ในส่วนของการมีส่วนร่วมของลูกค้า วิธีการแบบ Waterfall จะเน้นการมีส่วนร่วมในช่วงเริ่มต้นและช่วงท้ายของโครงการ ในขณะที่วิธีการแบบ Agile จะกระจายการมีส่วนร่วมไปตลอดวงจรชีวิตของโครงการ โดยมีการทบทวนบ่อยครั้งและมีผลิตภัณฑ์ที่พร้อมส่งมอบได้ในตอนท้ายของแต่ละสปรินต์

ในแง่ของระยะเวลาในการนำผลิตภัณฑ์ออกสู่ตลาด โครงการแบบ Waterfall มักจะส่งมอบคุณค่าในตอนท้ายของกระบวนการ ในขณะที่ Agile อนุญาตให้ปล่อยเวอร์ชันเริ่มต้น (MVP) ออกมาก่อน แล้วค่อยปรับปรุงแก้ไขไปเรื่อย ๆ

ในทางปฏิบัติ องค์กรหลายแห่งเลือกใช้ วิธีการแบบ ผสมผสานเช่น "Water-Scrum-Fall" ที่เป็นที่รู้จักกันดี กล่าวคือ การวางแผนและการออกแบบโดยทั่วไปอยู่ในโหมด Waterfall การพัฒนาในแต่ละวันใช้ Scrum และการปรับใช้/ส่งมอบอีกครั้งภายใต้กรอบการทำงานที่คาดการณ์ได้แม่นยำยิ่งขึ้น

บทบาทของผู้จัดการโครงการในโมเดล Waterfall

ในสภาพแวดล้อมแบบ Waterfall บทบาทของผู้จัดการโครงการจะแตกต่างจาก Scrum Master หรือ Agile Coach ในที่นี้ พวกเขาถูกคาดหวังให้เป็นนักวางแผนและผู้ควบคุมความคืบหน้าอย่างพิถีพิถันมากกว่าที่จะเป็นผู้สนับสนุนทีมที่จัดการตนเองได้

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

สำหรับผู้ที่ต้องการเชี่ยวชาญในด้านการจัดการประเภทนี้ การรับรองต่างๆ เช่นPMP จาก PMIหรือมาตรฐานเฉพาะของภาคส่วนที่มีการกำกับดูแล (ตัวอย่างเช่น DO-178C ในอุตสาหกรรมการบินและอวกาศ) จะช่วยเสริมสร้างทักษะเหล่านี้ได้อย่างแม่นยำ ซึ่งมุ่งเน้นไปที่การคาดการณ์และการจัดการวงจรชีวิตอย่างเป็นระบบและมีเอกสารประกอบอย่างครบถ้วน

วิธีการแบบผสมผสานและการทำงานร่วมกับแนวทางแบบ Agile

ความเป็นจริงคือ ปัจจุบันแทบไม่มีโครงการสำคัญใดที่ใช้โมเดล Waterfall หรือ Agile 100% มักพบเห็นการผสมผสานกัน โดยที่Waterfall ทำหน้าที่เป็นกรอบการทำงานตามสัญญาในขณะที่วงจรการพัฒนาแบบวนซ้ำถูกนำมาใช้ภายในเพื่อลดความเสี่ยงในบางส่วนงานเฉพาะด้าน

ตัวอย่างเช่น สถาปัตยกรรมโดยรวมและส่วนต่อประสานต่างๆ สามารถกำหนดได้โดยใช้วิธีการแบบน้ำตก (waterfall methodology) แต่ระบบย่อยบางส่วนสามารถพัฒนาได้ด้วยการทำซ้ำสั้นๆ และการสร้างต้นแบบตราบใดที่ส่วนต่อประสานและเป้าหมายการบูรณาการได้รับการเคารพ การผสมผสานนี้ก็สามารถใช้งานได้ดีมาก

สิ่งที่คล้ายกันนี้เกิดขึ้นในกระบวนการเปลี่ยนแปลงทางดิจิทัล: องค์กรสามารถย้ายระบบหลักด้านธุรกรรม (ที่เสถียรและมีการควบคุม) โดยใช้โมเดล Waterfall ในขณะที่พัฒนาแอปพลิเคชันส่วนหน้าสำหรับลูกค้าปลายทางด้วยทีมงานแบบ Agile นี่ไม่ใช่สิ่งที่ขัดแย้งกัน แต่เป็นวิธีการที่ชาญฉลาดในการเลือกใช้เครื่องมือที่เหมาะสมกับแต่ละปัญหา

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

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