จัดลำดับความสำคัญของ Feature ด้วย Kano Model
Do You Have Something That Will “WOW” Your Customer?
มีคำถามที่น่าสนใจจาก Product Owner คนนึงมาฝากครับ
“พี่ๆ เราควรมีหลักการในการคิด Feature และจัดลำดับความสำคัญของมันยังไงอะครับ?”
ขออนุญาตแนะนำให้รู้จัก Kano Model ครับ
Kano Model ซึ่งถูกพัฒนาโดย Noriaki Kano นำเสนอหลักการการจัดแบ่งคุณสมบัติของสินค้าตามความสำคัญที่มีต่อลูกค้าและตามความพึงพอใจของลูกค้า Kano แบ่งกลุ่มของ Feature หรือ Requirement ออกเป็นสี่กลุ่มดังนี้
ยกตัวอย่างกรณีศึกษาจากการสร้าง iPod รุ่นแรกเมื่อปี 2001 นะครับ
1. Surprise and Delight
Requirement ที่ถูกจัดอยู่ในกลุ่มนี้คือสิ่งที่อยู่นอกเหนือความคาดหมายของลูกค้า เป็นสิ่งที่ทำให้สินค้าของเราดีเกินกว่าความคาดหวังของลูกค้า (Exceed Expectation) เป็นแนวคิดใหม่ที่จะทำให้สินค้าของเราแตกต่างและดีขึ้นกว่าคู่แข่ง คล้ายๆกับว่าถ้าลูกค้ามาเห็นแล้วต้องร้องว้าวอะไรแบบนี้
สิ่งที่เป็น Surprise and Delight ของ iPod version แรกน่าจะเป็น Nav-Wheel จุดนี้ทำให้ iPod สามารถสร้างความแตกต่างและทำให้ลูกค้าร้องว้าวได้
2. More Is Better
Requirement ในกลุ่มนี้โดยมากแล้วจะเป็นอะไรที่เกี่ยวกับแนวคิดที่ว่า “ใหญ่กว่า เร็วกว่า แข็งแรงกว่า” แต่ความท้าทายในการเขียน Requirement ในกลุ่มนี้ก็คือเราจะรู้ได้อย่างไรว่าเมื่อไรถึงจะพอ เช่น ใหญ่กว่า…แล้วต้องใหญ่แค่ไหน? เร็วกว่า…แล้วต้องเร็วแค่ไหน เป็นต้นครับ การใช้คำที่ว่า Minimize หรือ Maximize เป็นการเขียนที่กำกวมซึ่งยากต่อการเอาไปพัฒนาต่อได้ ตัวอย่างเช่น ถ้าเราเขียนว่าต้อง Minimize search time ของระบบ Search Engine แบบนี้ Developer จะรู้ได้อย่างไรว่า Minimum time ที่ต่ำที่สุดของระบบ Search Engine ควรเป็นเท่าไร?
เป็นเรื่องท้าทายที่จะเขียน Requirement ให้ได้ชัดเจนเพราะว่าการระบุตัวเลขที่ชัดเจนก็เป็นเรื่องยากมากเช่นกัน ตรงนี้กฎของ Diminishing Returns ในทฤษฎีทางเศรษฐศาสตร์จะเข้ามาเกี่ยวข้อง พูดง่ายๆคือความแตกต่างที่ลดลงเรื่อยๆเมื่อปัจจัยใดปัจจัยหนึ่งเพิ่มขึ้นหรือลดลง ผมขอยกตัวอย่างเป็น Search Engine นะ ประโยชน์ที่ลูกค้าได้รับจากการที่ Search Time เป็น 0.21 วินาทีกับ 0.11 วินาทีแทบจะไม่แตกต่างกันเลย ในอีกมุมหนึ่งถ้าเราอยากให้ลูกค้าได้ประโยชน์จากสินค้ามากขึ้น มันก็ต้องแลกมาด้วยค่าใช้จ่ายที่เพิ่มขึ้นด้วย
ยกตัวอย่างจาก iPod เหมือนเดิมก็จะเป็นความสามารถในการเก็บเพลงที่มีมากกว่าคู่แข่งในขณะนั้น
3. Must Be
อันนี้ชื่อก็บอกอยู่อย่างชัดเจนแล้วว่าเป็นสิ่งที่ต้องมี ในสินค้าของเรา ซึ่ง Requirement ที่อยู่ในกลุ่มนี้จะเป็นสิ่งที่ลูกค้าส่วนใหญ่พิจารณาเป็นอันดับต้นๆในการเลือกสินค้า ดังนั้นถ้าอยากขายของได้ เราต้องใส่ Must Be เข้าไปในสินค้า Version แรกของเราเลย
ตัวอย่างจาก iPod สิ่งที่เป็น Must Be ในก็น่าจะเป็นความบาง กระทัดรัด และการออกแบบที่ทันสมัยของมัน รวมถึงความง่ายในการใช้งานเมนูต่างๆ ซึ่งข้อนี้ได้ Feedback ตรงมาจาก Steve Jobs เลย (ใครจะกล้าขัด?) Jobs บอกกับทีมพัฒนาว่า “ผมต้องการเข้าถึงเพลงที่อยากฟังได้ด้วยการกดไม่เกิน 3 ปุ่ม” ชัดเจน
4. Better Not Be
ข้อนี้ฟังดูแล้วเหมือนจะเป็นมุมกลับของ Requirement นั่นคือสิ่งที่ลูกค้าไม่ต้องการให้มีอยู่ในสินค้า เป็นกลุ่มที่อยู่ตรงข้ามกับ Surprise and Delight แต่เราก็ไม่ควรมองข้ามข้อมูลตรงนี้ไปทั้งหมดหรอก เพราะว่าเจ้าพวก Anti-Requirement เหล่านี้อาจจะกลายเป็น Must Be หรือ Surprise and Delight Requirement ขึ้นมาได้ง่ายๆเลย
ยกตัวอย่างจาก iPod เหมือนเดิม ถ้าลูกค้าบอกว่า “ไม่ชอบเลยที่ MP3 Player มีเนื้อที่เก็บเพลงน้อย” นี่เป็นที่มาของ Must Be requirement ที่ว่า “iPod ต้องเก็บเพลงได้เยอะๆ” หรือ ถ้าลูกค้าบอกว่า “ไม่ชอบ Navigation ที่ใช้งานยาก เข้าใจยาก” ก็เลยเป็นที่มาของ Surprise and Delight Requirement ที่ว่า “iPod ต้องสร้างรูปแบบใหม่ของ Navigation ขึ้นมาให้ได้”ก็ Nav Wheel นั่นไง
ประเด็นสำคัญอีกจุดหนึ่งคือในการออบแบบและผลิตสินค้าที่ตรงใจลูกค้ามากที่สุดเราต้องพยายามอย่าให้มี Better Not Be อยู่ในสินค้าเรา
How To Apply
การพัฒนาสินค้าของเราโดยอาศัยหลักการ Minimum Viable Product หรือ MVP นั้น เราสามารถประยุกต์ใช้ Kano Model ได้ด้วยการตอบคำถามเหล่านี้ตามลำดับ
- เรามีอะไรที่เป็น Surprise and Delight เพื่อสร้างความแตกต่างให้กับสินค้าของเราหรือยัง? ผมให้ความสำคัญกับข้อนี้มากเพราะ Requirement กลุ่มนี้ทำมาด้วยความเชื่อที่ว่าลูกค้าจะร้องว้าวซึ่งในทางกลับกันมันก็จะมีความเสี่ยงที่ลูกค้าจะร้องแหวะมาด้วยเช่นกัน การคิดถึง Requirement กลุ่มนี้ก่อนจะทำให้เราสามารถพิสูจน์สมมติฐานของเราได้อย่างรวดเร็ว … Fail Fast ครับ
- Requirement ของสินค้า Version แรกมีสิ่งที่เป็น Must Be ครบแล้วหรือไม่? ข้อถัดมาคือลองพิจารณาดูว่าเรามี Must Be ครบมั้ย ซึ่งถ้าไม่ครบก็ไม่เป็นไรนะ เพราะการทำงานแข่งกับเวลา (Time To Market) นั้นเราสามารถตัด Must Be ที่ยังไม่จำเป็นมากในช่วงแรกได้
- เมื่อเราระบุ More Is Better ข้อมูลเหล่านั้นมีความกำกวม หรือเป็นไปไม่ได้ในทางปฏิบัติหรือไม่? สุดท้ายถ้ามีเรื่องนี้เข้ามา พิจารณาให้หนักครับว่าการลงทุนจะได้ผลตอบแทนที่คุ้มค่ามั้ย
สุดท้ายนี้ไม่ว่าจะใช้หลักการอะไร การจัดลำดับความสำคัญของ Requirement เป็นเรื่องที่ต้องทำและทำอย่างจริงจัง เพราะว่าสินค้าจะประสบความสำเร็จหรือล้มเหลวก็ขึ้นกับว่าเราว่าตอบสนองความต้องการของลูกค้าได้ตรงจุดและตรงเวลาหรือไม่
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
