ระยะเวลาพัฒนา MVP บวมขึ้นตรงไหน

เรื่องเดียวที่ต้องตกลงก่อนถามเรื่องระยะเวลา

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

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

เลือกของที่จะตัดออกจากเวอร์ชันแรกก่อน

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

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

พองานเริ่มเดิน ความเร็วในการตอบกลับคือตัวคุมกำหนดการ

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

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

การรีวิวของสโตร์กับสัญญาระบบชำระเงินเป็นปฏิทินของคนอื่น

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

กำหนดการชุดนี้ฝ่ายที่ทำเร่งให้ไม่ได้ ถ้านับรวมเข้าไปในช่วงพัฒนา วันเปิดจริงจะคลาดเคลื่อน

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

ถ้าวันเปิดถูกล็อกไว้แล้ว

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