ถอดฟีเจอร์อะไรจาก MVP เพื่อส่งมอบได้ในไม่กี่สัปดาห์
เรียนรู้บทเรียนจากการพัฒนา MVP ของนักพัฒนาที่ตัดฟีเจอร์ส่วนเกินอย่างแอดมินและระบบจ่ายเงินออก เพื่อส่งงานให้ทันในไม่กี่สัปดาห์

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

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

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
กระนั้น การตัดสินใจบางอย่างก็นำมาซึ่งความเสียดายในภายหลัง ระบบวิเคราะห์ข้อมูลพื้นฐานถูกตัดทิ้งเพื่อประหยัดเวลาไปเพียงวันเดียว แต่กลับทำให้ผู้พัฒนาต้องเสียเวลาอีกหลายสัปดาห์ในการคาดเดาว่าหน้าจอใดที่ผู้ใช้งานใช้งานจริง รวมถึงระบบค้นหาเล็กๆ ที่คิดว่าผู้ใช้ยังไม่มีข้อมูลมากพอ แต่กลับมีผู้ใช้กลุ่มหนึ่งต้องการใช้งานภายในเดือนแรกทันที
"If I could do it by hand for the first group of users, it stayed out of the code. If skipping it could lose data or hide errors, it stayed in."
Rishita Sharma
บทเรียนสำคัญจากการพัฒนานี้สรุปได้ว่า หากสิ่งใดสามารถทำด้วยมือสำหรับผู้ใช้งานกลุ่มแรกได้ สิ่งนั้นจะถูกตัดออกจากโค้ด แต่หากการละเลยมันอาจทำให้ข้อมูลสูญหายหรือซ่อนข้อผิดพลาด สิ่งนั้นจะต้องคงอยู่ต่อไป
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น