การแก้ปัญหา Requirement ของโครงการ ไม่ชัดเจน ด้วย MVP

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

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

วิเคราะห์ความต้องการ -> ออกแบบระบบงาน -> พัฒนาระบบงาน -> ทดสอบ -> ติดตั้งระบบงาน

        หากไม่สามารถวิเคราะห์และกำหนดความต้องการได้ครบถ้วน ก็จะทำให้การออกแบบการพัฒนาไม่ครบถ้วน ส่งผลให้ต้องกลับมาวางแผนกันใหม่ หรือเกิดกระบวนการเปลี่ยนแปลงแผนงานโครงการบ่อยครั้ง ในกรณีนี้ Project Manager ควรพิจารณาแบ่งการส่งมอบงานออกเป็น Phase เพื่อให้การกำหนดความต้องการ สามารถระบุได้ตาม Phase งาน เพื่อลดปัญหาความซับซ้อนของงาน และให้โอกาสผู้มีส่วนได้ส่วนเสียในการเรียนรู้เพื่อตัดสินใจในเรื่องความต้องการต่างๆ ที่ยังไม่สามารถระบุได้ในช่วง Phase ต้นๆ ของโครงการ และอาจจะสามารถกลับมาตัดสินใจอีกครั้งในช่วง Phase ถัดไปของโครงการได้ วิธีการนี้เป็นที่คุ้นเคยกันในรูปแบบการบริหารโครงการในแบบ Incremental ซึ่งมักจะพบในองค์กรที่อยู่ระหว่างการพยายามปรับรูปแบบการบริหารโครงการ จาก Waterfall สู่การบริหารโครงการ แบบ Agile  หรือพูดอีกนัยหนึ่งการบริหารโครงการแบบ Incremental นั้นพยายามส่งมอบงานให้รวดเร็ว และต้องการ การมีปฏิสัมพันธ์กับผู้ใช้งานคล้าย Agile แต่ยังมีลำดับการทำงานเหมือน Waterfall ที่สั้นลงและส่งมอบถี่ขึ้น เช่นระบบงานของเรา มี 6 Functions เราจึงแบ่งการส่งมอบงาน เป็น 3 ช่วงเวลา

รอบที่ 1
วิเคราะห์ความต้องการ -> ออกแบบ -> พัฒนา -> ทดสอบ -> ติดตั้งระบบงาน (Function 1,2)
 
รอบที่ 2
วิเคราะห์ความต้องการ -> ออกแบบ -> พัฒนา -> ทดสอบ -> ติดตั้งระบบงาน (Function 3,4)
 
รอบที่ 3
วิเคราะห์ความต้องการ -> ออกแบบ -> พัฒนา -> ทดสอบ -> ติดตั้งระบบงาน (Function 5,6)

        ประเด็นในการพิจารณาจากตัวอย่างข้างต้นนั้น การเลือก Function 1 และ 2 มาทำการวิเคราะห์ ออกแบบ และพัฒนา เพื่อส่งมอบก่อน Function อื่นๆ นั้น  จำเป็นต้องมีการคัดเลือก Function ที่สำคัญมาทำก่อน และ Function ที่สำคัญเหล่านี้ เราเรียกมันว่า Minimal Viable Products (MVP)  หรือบางท่านจะเรียกว่า Minimal Marketable Feature (MMF) แต่ในบทความนี้จะขอเรียกว่า MVP ซึ่งหมายถึง Functions หรือ Features จำนวนน้อยที่สุด ที่สามารถทำให้ระบบงานทำงานได้สำหรับหน้าที่ที่จำเป็นเท่านั้น เช่น

MVP ของ โทรศัพท์มือถือ คือ ฟังก์ชั่นโทรออก รับสาย    บันทึกชื่อ Contact และเบอร์   รับและส่ง SMS   แต่จะไม่รวม ฟังก์ชั่น การเชื่อมต่อ Internet การถ่ายรูป การดูหนัง ฟังเพลง เป็นต้น 

MVP ของ ตู้ ATM (Automated Teller Machine) คือ ฟังก์ชั่น แสดงตัวตน พิสูจน์ตัวตน ถอนเงิน แสดงยอดเงินคงเหลือ ป้องกันการโกงเงิน แข็งแรงพอจะป้องกันการงัดขโมยเงิน เก็บข้อมูลและรับส่งข้อมูลอย่างปลอดภัย แต่จะไม่รวม ฟังก์ชั่น การรับฝากเงิน การรับฝากเช็ค การสมัครใช้บริการต่างๆของธนาคาร เป็นต้น

        การพิจารณาว่า Function ใดเป็น Function ที่อยู่ใน MVP นั้น ต้องพิจารณา Business Value  ของสิ่งส่งมอบในโครงการเป็นหลัก โดย MVP จะต้องเพียงพอครบถ้วนสำหรับการใช้งานในฟังก์ชั่นที่น้อยที่สุดที่จะสามารถส่งมอบ Business Value หลักๆ ได้ แต่ต้องไม่มากจนเกือบจะเป็น Function ทั้งหมดที่โครงการต้องส่งมอบ ซึ่งผู้ใช้งาน หรือ Product Owner ของโครงการจะต้องมีบทบาทสำคัญในการช่วยกำหนด MVP  ให้ชัดเจนด้วยวิธีการนี้ ก็จะสามารถบรรเทาปัญหาการกำหนด Requirement ไม่ชัดเจนได้บ้าง เนื่องจาก ผู้ใช้งานยังไม่มีความจำเป็นต้องกำหนดความต้องการของโครงการทั้งหมดในคราวเดียว แต่สามารถกำหนดความต้องการเฉพาะส่วน MVP ก่อนเท่านั้น และเมื่อมีการส่งมอบงานส่วน MVP เรียบร้อยแล้ว จึงจะกลับมากำหนดความต้องการในส่วนอื่นๆ ถัดๆ ไป ซึ่งคาดหวังว่า ณ เวลานั้น ความต้องการในส่วนที่เหลือ จะมีความชัดเจนมากขึ้น เนื่องจากผู้ใช้งานและทีมงานโครงการได้เรียนรู้ข้อมูลต่างๆ จากการส่งมอบ MVP เพื่อนำมาเป็นต้นทุน ในการกำหนดรายละเอียดความต้องการในรอบต่อๆไป

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