ถามว่า MVP คืออะไร ตอบตรงๆ คือ minimum viable product ระบบรุ่นเล็กที่สุดที่ยังใช้ทำงานจริงได้ สร้างขึ้นเพื่อตอบคำถามเดียว คือระบบนี้คุ้มที่จะลงทุนต่อหรือไม่ บทความเรื่อง MVP ส่วนใหญ่เขียนให้ startup ที่สร้าง product ของตัวเอง แต่บทความนี้เขียนให้อีกกลุ่มที่เราเจอบ่อยกว่า คือธุรกิจที่กำลังจะจ้างสร้างระบบ แล้วต้องตัดสินใจว่าจะเทงบทั้งก้อนตั้งแต่วันแรก หรือจ่ายก้อนเล็กเพื่อพิสูจน์ก่อน
MVP คืออะไร และ 3 ความเสี่ยงของการจ้างสร้างระบบเต็มตั้งแต่วันแรก
เหตุผลไม่ซับซ้อน ระบบเต็มถูกสเปคตอนที่ workflow นั้นยังไม่เคยถูกใช้จริง ฟีเจอร์จำนวนมากในเอกสารจึงมาจากการนั่งนึกว่า "น่าจะต้องมี" และจากที่เราเห็นมา การเดาแบบนี้มักผิดในจุดที่แพง
- ฟีเจอร์ที่คิดว่าสำคัญ พอใช้จริงแทบไม่มีใครแตะ แต่จ่ายเงินสร้างไปแล้ว
- ฟีเจอร์ที่ไม่มีใครนึกถึงตอนสเปค กลายเป็นสิ่งที่หน้างานต้องใช้ทุกวัน
- flow ที่วาดไว้สวยในเอกสาร ชนกับวิธีทำงานจริงของคนหน้างานตั้งแต่สัปดาห์แรก
ยิ่งระบบใหญ่ ราคาของการเดาผิดยิ่งสูง เพราะทุกอย่างถูกผูกกันเสร็จแล้ว การแก้จึงไม่ใช่การเติม แต่คือการรื้อ
MVP ที่ดีตัดอะไร และห้ามตัดอะไร
หลักที่เราใช้คือ ตัดขอบเขต ไม่ตัดคุณภาพ
ตัดได้ ฟีเจอร์รอบนอกทั้งหมดที่ยังพิสูจน์ไม่ได้ว่าจำเป็น รายงานสวยๆ ระบบสิทธิ์ซับซ้อน การเชื่อมต่อที่ "เผื่ออนาคต" หน้าจอตั้งค่าที่ยืดหยุ่นทุกอย่าง ของพวกนี้ค่อยเติมเมื่อการใช้จริงยืนยันว่าต้องมี
ห้ามตัด เส้นทางงานหลัก 1 เส้นที่ทำได้จบจริง ความปลอดภัยของข้อมูลตามระดับความเสี่ยงของงาน และโครงสร้างที่ต่อยอดได้ MVP ที่ viable แปลว่าคนหน้างานใช้ทำงานจริงได้ในขอบเขตที่เลือกตั้งแต่วันแรก ไม่ใช่ของทดลองที่บังคับให้ทำงานซ้ำสองที่ไปตลอด
จุดที่หลายเจ้าเข้าใจคลาดคือวัด MVP ด้วยความเร็วเปิดตัว เราวัดต่างออกไป MVP ที่ดีวัดที่ความเร็วในการได้คำตอบ ว่าอะไรควรสร้างต่อ อะไรควรหยุด ระบบที่เปิดตัวเร็วแต่ตอบคำถามนี้ไม่ได้ ก็แค่ระบบเล็กที่สร้างเร็ว
การจ้างแบบ MVP เปลี่ยนความเสี่ยงของ SME ยังไง ใน 3 ขั้น
การจ้างแบบเต็มระบบ เงินทั้งก้อนถูกวางบนการเดาชุดเดียว ส่วนการจ้างแบบ MVP แบ่งการลงทุนเป็นขั้น แต่ละขั้นมีของจริงให้ประเมินก่อนจ่ายขั้นถัดไป
- ขั้นแรก สร้างเส้นทางงานหลัก 1 เส้นให้จบ ใช้กับงานจริง เก็บ feedback จากคนหน้างานจริง
- ขั้นถัดไป เติมจากสิ่งที่การใช้จริงเรียกร้อง ไม่ใช่จากเอกสารสเปคที่เขียนไว้ก่อนใครได้ใช้จริง
- ทุกขั้นมีจุดตัดสินใจ ถ้าขั้นแรกพิสูจน์ว่าระบบไม่ช่วยธุรกิจจริง คุณหยุดได้โดยเสียเท่าที่ลงไปในขั้นนั้น ไม่ใช่ทั้งโครงการ
เคสจริงที่ตรวจย้อนได้คือระบบผลิตบทความที่ใช้เขียนบทความนี้เอง เราเริ่มจากเวอร์ชันเล็กสุดที่ใช้งานได้จริง ใช้กับงานจริงทุกชิ้น และเราเก็บสถิติคำตัดสินของเราเองทุกข้อ ฟีเจอร์ที่มีประโยชน์สุดบางตัวไม่ได้อยู่ในแผนแรกเลย มันงอกจากการใช้จริง และเราเพิ่งตัดสินใจจ่ายเงินขยายระบบหลังผลจริงจาก 5 บทความของเรายืนยันว่าคุ้ม ไม่ใช่ตัดสินจากความรู้สึกวันวางแผน
แนวคิดนี้ต่อกับหลักที่เราเขียนไว้ใน ซอฟต์แวร์สำเร็จรูป vs สั่งทำ พอดี คืองานที่ process ยังเปลี่ยนทุกเดือนอย่าเพิ่งสั่งทำเต็มระบบ MVP คือคำตอบตรงกลางสำหรับงานที่นิ่งพอจะเริ่ม แต่ยังไม่นิ่งพอจะเทหมดหน้าตัก
MVP ไม่ใช่ระบบครึ่งเดียวราคาถูก มันคือการซื้อคำตอบก่อนซื้อระบบ
เมื่อไหร่ไม่ควรเริ่มด้วย MVP
ตอบตามเนื้องานเช่นเคย หลักคือสิ่งที่หั่นได้คือขอบเขตธุรกิจ ไม่ใช่ข้อกำหนดที่จำเป็นต่อการใช้งาน งานที่ผูกกับข้อกำหนดทางบัญชี กฎหมาย หรือปลายทางที่ล็อกขอบเขตตายตัว ยังเริ่มเล็กได้ถ้าลดขอบเขตแล้วข้อกำหนดยังครบ แต่ถ้าครึ่งเดียวแปลว่าผิดข้อกำหนด แบบนั้นให้ล็อกขอบเขตแน่นตั้งแต่ต้น อย่าฝืนหั่น
เริ่มยังไงต่อ
ลองเขียนออกมา 1 ประโยค ว่าถ้าระบบใหม่ทำได้แค่เรื่องเดียว เรื่องนั้นต้องเป็นอะไรธุรกิจถึงรู้สึกทันที นั่นคือขอบเขต MVP ของคุณ ถ้าเขียนแล้วได้ 5 เรื่องเท่ากันหมด แปลว่ายังไม่ได้จัดลำดับ และนั่นคืองานที่ควรทำก่อนคุยกับผู้พัฒนาเจ้าไหนก็ตาม อยากให้ช่วยตีกรอบจากงานจริงของคุณ ดูแนวทางที่ SaaS & Custom Software คุยรอบแรกฟรี ไม่มีข้อผูกมัด
คำถามที่พบบ่อย
MVP ย่อมาจากอะไร
Minimum Viable Product ระบบรุ่นเล็กที่สุดที่ยังใช้ทำงานจริงได้ ไม่ใช่แบบจำลองหรือของทดลอง หัวใจอยู่ที่คำว่า viable คือต้องใช้กับงานจริงและตอบได้ว่าระบบนี้คุ้มที่จะลงทุนต่อหรือไม่
MVP แปลว่าระบบคุณภาพต่ำใช่ไหม
ไม่ใช่ MVP ตัดขอบเขต ไม่ได้ตัดคุณภาพ ฟีเจอร์ที่เลือกทำต้องทำงานได้จริง ปลอดภัยพอกับความเสี่ยงของงาน และรองรับข้อมูลจริงของขอบเขตนั้น สิ่งที่หายไปคือฟีเจอร์รอบนอกที่ยังไม่พิสูจน์ว่าจำเป็น ไม่ใช่ความเรียบร้อยของงาน
MVP ต่างจาก prototype ยังไง
ต่างกันที่เป้าหมาย prototype มีไว้ทดสอบแนวคิดและ flow ก่อนสร้างจริง ส่วน MVP คือระบบจริงที่คนใช้ทำงานได้ ใช้ทดสอบว่าระบบสร้างคุณค่าให้ธุรกิจจริงไหม ส่วนจะต่อยอดโค้ดเดิมได้แค่ไหนขึ้นกับการออกแบบตั้งแต่ต้น
