#priwreadarticles การจัดลำดับความสำคัญแบบ MoSCoW ที่ไม่ได้แปลว่าเมืองหลวงของรัสเซีย

แปลและสรุปจากบทความเหล่านี้

• https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html
• https://en.wikipedia.org/wiki/MoSCoW_method

วิธีการจัดลำดับความสำคัญแบบ MoSCoW นี้ได้รับการพัฒนาโดย Dai Clegg ในปี 1994 เพื่อใช้ใน rapid application development (RAD) และใช้กันอย่างแพร่หลายใน DSDM (Dynamic System Development Method) ตั้งแต่ปี 2002 เป็นต้นมา

MoSCoW มักจะใช้กับกรอบเวลา (Timebox) ซึ่งกำหนดเส้นตายเพื่อให้โฟกัสไปที่ข้อกำหนดที่สำคัญที่สุด มักใช้ในแนวทางการพัฒนาซอฟต์แวร์แบบ Agile เช่น Scrum, Rapid Application Development (RAD) และ DSDM

ในโครงการ DSDM ที่มีการกำหนดเวลา สิ่งสำคัญคือ ต้องเข้าใจความสำคัญสัมพัทธ์ของงานที่ต้องทำ เพื่อสร้างความคืบหน้าและทำงานให้ทันกำหนดเวลา

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

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

โดยทั่วไปจะใช้กับข้อกำหนด/เรื่องราวของผู้ใช้มากที่สุด

MoSCoW เป็นเทคนิคการจัดลำดับความสำคัญ

โดยแต่ละตัวอักษรย่อมาจาก

• Must Have
• Should Have
• Could Have
• Won’t Have this time

การใช้สี่คำนี้ ผู้เขียนบทความเล่าว่า มีความหนักแน่นของคำมากกว่าอีกสองรูปแบบคือ

• high, medium or low อาจจะแปลความได้ไม่ชัด คำจำกัดความของลำดับความสำคัญของแต่ละคนอาจจะไม่เหมือนกัน
• การใช้ลำดับความสำคัญ 1,2,3,4… ตามลำดับ จะเจอปัญหากับการจัดการกับรายการที่มีความสำคัญใกล้เคียงกัน อาจมีการอภิปรายที่ยืดเยื้อว่าสิ่งของควรอยู่ในตำแหน่งที่สูงหรือต่ำกว่า

การใช้ Must Have, Should Have, Could Have หรือ Won’t Have อย่างเฉพาะเจาะจงในครั้งนี้ เป็นการบ่งชี้ที่ชัดเจนเกี่ยวกับรายการนั้น และความคาดหวังในการดำเนินการให้เสร็จสิ้น

Must Have (ต้องมี)

เป็นกลุ่มของ Requirements ที่รับประกันว่าจะส่งมอบได้ Minimum Usable SubseT (MUST)

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

หากตั้งคำถามว่า ‘จะเกิดอะไรขึ้นหากไม่เป็นไปตามข้อกำหนดนี้’ แล้วคำตอบคือ ‘ยกเลิกโครงการ’ แปลว่ามันคือสิ่งที่เป็น Must Have

แต่หากมีวิธีแก้ไข แม้ว่าจะเป็นวิธีแก้ปัญหาแบบ Manual หรือเจ็บปวด จะกลายเป็นข้อกำหนดที่ Should Have หรือ Could Have

การจัดหมวดหมู่ความต้องการ Should Have หรือ Could Have ไม่ได้หมายความว่าจะไม่มีการส่งมอบ เพียงแค่ว่า ไม่มีการรับประกันว่าจะจัดส่ง

Should Have (ควรมี)

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

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

Could Have (น่าจะมี)

• เป็นที่ต้องการหรือพึงปรารถนา แต่มีความสำคัญน้อยกว่า
• ผลกระทบน้อย หากปล่อยทิ้งไว้ (เมื่อเทียบกับ Should Have)

ข้อกำหนดส่วนนี้เป็นเรื่องของความเป็นไปได้ ถ้าใน Best Case มันก็จะถูกจัดส่งได้ทั้งหมด แต่หากเกิดปัญหาและมีความเสี่ยงของ Deadline เกิดขึ้น ข้อกำหนดที่เป็น Could have จะเป็นตัวเลือกแรกที่โดนตัดทิ้งออกจากกรอบเวลาที่กำหนด

Won’t Have this time (ไม่มีในตอนนี้)

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

สิ่งนี้ยังช่วยจัดการความคาดหวังที่ว่า ข้อกำหนดบางอย่างจะไม่รวมอยู่ใน Deployed Solution อย่างน้อยก็ไม่ใช่ในเวลานี้

Won’t Have มีประสิทธิภาพมากในการรักษาโฟกัสของทีมงาน

บางครั้ง W หมายถึงความปรารถนา (wish or would) เช่น ยังเป็นไปได้ แต่ไม่น่าจะรวมอยู่ด้วย (และมีโอกาสน้อยที่จะทำได้) สิ่งนี้แตกต่างจาก X (excluded) ที่ยกเว้นรายการที่ไม่ได้รวมไว้อย่างชัดเจน

ณ จุดนี้ในช่วงเวลาที่สำคัญ สิ่งที่ควรสนใจคือ Must, Should และ Could

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

MoSCoW มีความเกี่ยวข้องกับกรอบเวลา

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

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

ข้อกำหนดอาจมีลำดับความสำคัญสองประการ คือ สำหรับโครงการและสำหรับ Increment แต่ละรอบ

ตอนที่เริ่มต้นโครงการ ทีมพัฒนาจะเริ่มจัดลำดับความสำคัญ ณ จุดนี้ สิ่งที่เป็น Won’t Have this time จะมีเยอะที่สุด

พอทีมเริ่มวางแผนที่จะดำเนินการพัฒนาในกรอบเวลาที่กำหนด ข้อกำหนดต่างๆ จะได้รับการจัดสรรลำดับความสำคัญ Must Have, Should Have และ Could Have

ดังนั้นข้อกำหนดอาจมีลำดับความสำคัญสามระดับ คือ

• MoSCoW for the project
• MoSCoW for the Project Increment
• MoSCoW for this Timebox

ตัวอย่างเช่น ข้อกำหนดว่า ต้องมีสิ่งอำนวยความสะดวกในการเก็บข้อมูลเก่า

• MoSCoW for the project = Must Have
• MoSCoW for the Project Increment = โซลูชันอาจจะใช้งานได้อย่างมีประสิทธิภาพเป็นเวลาสองสามเดือนโดยไม่ต้องใช้สิ่งอำนวยความสะดวกนี้ สำหรับ Incremental แรก สามารถเป็น Should Have or a Could Have ได้
• MoSCoW for this Timebox = ในช่วงต้นโครงการ ก็อาจจะเป็น Should Have or a Could Have (or a Won’t Have) ได้เช่นกัน

สิ่งสำคัญคือ ต้องไม่ลืมวัตถุประสงค์ในภาพรวม นั่นคือ completion of the Project Increment and delivery of the project เมื่อทำงานในระดับ Timebox

การจัดลำดับความสำคัญอย่างมีประสิทธิภาพ

เมื่อตัดสินใจเลือกข้อกำหนด Must Have แล้ว โปรดจำไว้ว่าสิ่งอื่นนอกเหนือจาก Must Have นั้นจะต้องเป็นเรื่องฉุกเฉินในระดับหนึ่ง เนื่องจาก Must Have เป็นสิ่งที่เรารับประกันว่าจะส่งมอบ (แน่นอน)

DSDM แนะนำให้

• 60% Must Have ให้อยู่ในระดับที่ทีมมีความมั่นใจในการส่งมอบสูง
• 20% Could Have สำหรับสถานการณ์ฉุกเฉิน

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

หมายเหตุ: เมื่อคำนวณความพยายามในการทำงานใน Timebox ที่ถูกกำหนด จะไม่รวม Won’t Have

สิ่งสำคัญในการทำให้ MoSCoW ทำงานได้ คือ การมีความยืดหยุ่นที่มองเห็นได้ในระดับข้อกำหนดที่ต้องส่งมอบ

ระดับของ Must Have ที่มากกว่า 60% ทำให้เกิดความเสี่ยงที่จะล้มเหลว เว้นแต่ว่าทีมกำลังทำงานในโครงการที่ตรงตามเกณฑ์เหล่านี้ทั้งหมด

• เป็นที่ทราบกันดีว่าค่าประมาณมีความแม่นยำ
• เข้าใจแนวทางเป็นอย่างดี
• ทีมกำลังแสดง ตามแบบจำลอง Tuckman — storming–norming–performing ขั้นตอนเหล่านี้ทั้งหมดจำเป็นและหลีกเลี่ยงไม่ได้เพื่อให้ทีมเติบโต เผชิญกับความท้าทาย จัดการกับปัญหา ค้นหาแนวทางแก้ไข วางแผนงาน และส่งมอบผลลัพธ์
• สภาพแวดล้อมเป็นที่เข้าใจและมีความเสี่ยงต่ำ ในแง่ของปัจจัยภายนอกที่จะนำมาซึ่งความล่าช้า

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

การแบ่งความพยายามที่แน่นอนระหว่าง Must, Should และ Could นั้นขึ้นอยู่กับแต่ละทีมโครงการ

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

ตกลงล่วงหน้าว่า “ลำดับความสำคัญ” จะถูกใช้อย่างไร

ในขณะที่คำจำกัดความของ Must Have นั้นไม่สามารถต่อรองได้ ความแตกต่างระหว่าง Should และ Could อาจเป็นเรื่องส่วนตัว

จะมีประโยชน์มากหากทีมตกลงร่วมกันในตอนเริ่มโครงการว่าจะนำลำดับความสำคัญสองคำนี้ไปใช้งานอย่างไร

ตัวอย่างเช่น

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

ข้อตกลงนี้ควรมีก่อนที่จะมีการบันทึกข้อกำหนด

เมื่อใดควรจัดลำดับความสำคัญ

ก่อนเริ่มงาน และควรทบทวนการจัดลำดับความสำคัญอย่างต่อเนื่อง

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

เมื่อมีข้อกำหนดใหม่ ต้องระมัดระวังไม่ให้เพิ่มเปอร์เซ็นต์ของ Must Have เกินกว่าระดับที่ตกลงกันไว้

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

อภิปรายและทบทวนลำดับความสำคัญ

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

การเพิ่มกระบวนการตัดสินใจควรตกลงกันตั้งแต่เนิ่นๆ เช่น Business Ambassador และ Business Analyst to Business Visionary to Business Sponsor และระดับของอำนาจที่ตกลงกันเกี่ยวกับการตัดสินใจในแต่ละระดับ

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

MoSCoW ใช้จัดการความคาดหวังทางธุรกิจ

กฎของ MoSCoW ได้รับการกำหนดไว้ในลักษณะที่อนุญาตให้มีการรับประกันการส่งมอบข้อกำหนดย่อยที่ใช้งานได้ขั้นต่ำ และมีพื้นที่เหลือสำหรับสถานการณ์ฉุกเฉินที่เหมาะสมที่สุด เพื่อให้แน่ใจว่าจะส่งมอบสิ่งที่ต้องมีได้ในเวลาที่กำหนด

ธุรกิจสามารถคาดหวังได้อย่างมีเหตุผลว่า อาจจะได้รับ Should Have หลังจาก Must Have นอกจากนี้ยังบอกเป็นนัยว่า ในสถานการณ์ที่ดีที่สุด Could Have จะถูกส่งมอบไปด้วย

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

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

MoSCoW กับวิสัยทัศน์ทางธุรกิจ

The Business Sponsor’s perspective ผู้มีวิสัยทัศน์ทางธุรกิจต้องตรวจสอบให้แน่ใจว่าข้อกำหนดได้รับการจัดลำดับความสำคัญ ซึ่งได้รับการประเมินในแง่ธุรกิจ จัดส่งเพื่อให้ได้ ROI ที่กำหนด และสอดคล้องกับวิสัยทัศน์ทางธุรกิจ

ทำให้ MoSCOW ทำงานได้

หากข้อกำหนดทั้งหมดเป็น Must Have ความยืดหยุ่นที่ได้รับจากการจัดลำดับความสำคัญของ MoSCoW จะไม่ทำงานอีกต่อไป

การเชื่อว่าทุกอย่างเป็นสิ่งที่ต้องมี มักแสดงถึงความต้องการที่ไม่เพียงพอ

เคล็ดลับสำหรับการกำหนดลำดับความสำคัญ

1. ตรวจสอบให้แน่ใจว่าบทบาททางธุรกิจ โดยเฉพาะอย่างยิ่ง Business Visionary และ Business Analyst มีความเข้าใจว่าทำไม DSDM จึงจัดลำดับความสำคัญของข้อกำหนด
2. เริ่มต้นด้วยข้อกำหนดทั้งหมดเป็น Won’t Have จากนั้นดูว่าอะไรต้องมี ควรมี น่าจะมี พร้อมให้เหตุผลว่าเหตุใดจึงต้องให้ความสำคัญแบบนี้
3. สำหรับข้อกำหนดแต่ละข้อที่เสนอให้เป็น Must Have ให้ถามว่า “จะเกิดอะไรขึ้นหากไม่เป็นไปตามข้อกำหนดนี้” หากคำตอบคือ “ยกเลิกโครงการ” ถือเป็นสิ่งที่ต้องมีจริงๆ ถ้าไม่ใช่ ให้ตัดสินใจว่าเป็น Should Have, Could Have หรือ Won’t Have this time
4. ถามว่า “ถ้าฉันมาหาคุณในคืนก่อน Deployment และบอกคุณว่ามีปัญหากับข้อกำหนดที่ต้องมีและเราไม่สามารถส่งมอบได้ คุณจะหยุดการ Deployment หรือไม่” ถ้าคำตอบคือ “ใช่” นี่เป็นข้อกำหนดที่ต้องมี ถ้าไม่ใช่ ให้ตัดสินใจว่า Should Have หรือ Could Have
5. มีวิธีแก้ไข แม้ว่าจะเป็นแบบแมนนวลหรือไม่? หากมีวิธีแก้ปัญหาอยู่แล้ว แสดงว่าไม่ใช่ข้อกำหนดที่ต้องมี เมื่อพิจารณาว่านี่เป็นข้อกำหนดที่ Should Have หรือ Could Have ให้เปรียบเทียบต้นทุนของวิธีแก้ปัญหากับต้นทุนของการส่งมอบความต้องการ รวมถึงต้นทุนของความล่าช้าที่เกี่ยวข้อง และต้นทุนเพิ่มเติมใดๆ เพื่อดำเนินการข้อกำหนดเหล่านี้ในภายหลัง
6. ถามว่า “ทำไมต้องมีข้อกำหนดนี้” สำหรับ project และ Project Increment
7. ข้อกำหนดนี้ขึ้นอยู่กับข้อกำหนดอื่นๆ หรือไม่? สิ่งที่ต้องมี สามารถขึ้นอยู่กับ สิ่งที่ต้องมี ได้แค่นั้น
8. อนุญาตให้มีลำดับความสำคัญที่แตกต่างกันสำหรับเกณฑ์การยอมรับข้อกำหนด ตัวอย่างเช่น ‘กระบวนการสำรองข้อมูลปัจจุบันต้องแน่ใจว่าบริการสามารถกู้คืนได้โดยเร็วที่สุด’ เร็วแค่ไหน? หากให้เวลาและเงินเพียงพอ อาจใช้เวลาไม่กี่วินาที คำจำกัดความที่ฉลาดกว่าคือ การบอกว่า “ควร” เกิดขึ้นภายในสี่ชั่วโมง แต่ “ต้อง” เกิดขึ้นภายใน 24 ชั่วโมง
9. ความต้องการนี้สามารถแยกย่อยได้หรือไม่? จำเป็นหรือไม่ที่จะต้องส่งมอบแต่ละองค์ประกอบเหล่านี้เพื่อตอบสนองความต้องการ? องค์ประกอบที่แยกย่อยมีลำดับความสำคัญเท่ากันหรือไม่
10. เชื่อมโยงความต้องการเข้ากับวัตถุประสงค์ของโครงการ หากวัตถุประสงค์ไม่ใช่สิ่งที่ต้องมี ก็อาจไม่ใช่ข้อกำหนดที่เกี่ยวข้อง
11. ลำดับความสำคัญเปลี่ยนไปตามเวลาหรือไม่? ตัวอย่างเช่น สำหรับรีลีสแรก ข้อกำหนดคือควรมี แต่จะกลายเป็น “ต้องมี” สำหรับรีลีสในภายหลัง
12. จัดลำดับความสำคัญของการทดสอบโดยใช้ MoSCoW
13. ใช้ MoSCoW จัดลำดับความสำคัญของรายการสิ่งที่ต้องทำ สามารถใช้สำหรับ activities และ requirements

สิ่งที่ MoSCOW มีช่องโหว่

• ไม่ช่วยตัดสินใจระหว่างข้อกำหนดหลายรายการที่อยู่ในลำดับความสำคัญเดียวกัน
• ขาดเหตุผลในการจัดลำดับข้อกำหนด ต้องมีการตกลง “คำจำกัดความ” ของแต่ละเลเวล กันล่วงหน้าให้ดีๆ ก่อน
• ความคลุมเครือในเรื่องเวลา โดยเฉพาะในหมวดหมู่ Won’t have ว่า ตกลงจะมี หรือไม่มีในรุ่นนี้ หรือจะไม่มีเลยตลอดไป
• เน้นไปที่การสร้างคุณสมบัติใหม่ มากกว่าการปรับปรุงทางเทคนิค

MoSCoW ใช้เพื่อจัดลำดับความสำคัญของข้อกำหนดเป็นหลัก

แม้ว่าแนวทางปฏิบัติจะมีประโยชน์ในด้านอื่นๆ อีกมากมาย

ในโครงการทั่วไป DSDM แนะนำให้ใช้ความพยายามไม่เกิน 60% สำหรับข้อกำหนด Must Have และ Could Have ประมาณ 20%

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

Disclaimer ภาพด้านล่างนี้ทำขึ้นมาเอง ไม่ได้นำมาจากบทความที่อ่าน และไม่มีคนตรวจสอบด้วยว่าถูกต้องหรือไม่ ทำเพื่อความสนุกส่วนตัวล้วนๆ สามารถข้ามได้ค่ะ 555

การเดินป่าเดินเขาแบบจำกัดน้ำหนักของที่แบกไปได้ด้วย คือ การฝึกความสามารถเรื่องการจัดลำดับความสำคัญมากๆ และแน่นอนว่า ยิ่งเรามีประสบการณ์ในเรื่องนั้นๆ มากเท่าไหร่ เราก็จะมีความสามารถในการเขี่ยของที่ “ดูเหมือนจำเป็น” “น่าเอาไปด้วย” “อยากเอาไปด้วย” ทิ้งได้มากเท่านั้น

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