Kano Model ภาคคำนวณ: ทำแบบสอบถามจริง และอ่านค่า Better–Worse ให้รู้ว่าฟีเจอร์ไหนควรทำก่อน

รู้ว่า Kano Model คืออะไรแล้ว แต่พอจะใช้จริงกลับติดตั้งแต่คำถามแรก บทความนี้พาทำภาคปฏิบัติทั้งกระบวนการ ตั้งแต่การเขียนคำถามคู่ functional–dysfunctional ตารางแปลผล ไปจนถึงสูตร Better–Worse coefficient พร้อมตัวอย่างตัวเลขจริงที่คำนวณตามได้ทุกขั้น
Kano Model คือกรอบคิดที่แบ่งฟีเจอร์ออกเป็นกลุ่มตามผลต่อความพึงพอใจของลูกค้า ตั้งแต่ Must-be ที่ไม่มีไม่ได้ One-dimensional ที่ยิ่งดียิ่งพอใจ ไปจนถึง Attractive ที่ไม่มีใครคาดหวังแต่มีแล้วว้าว บทความก่อนหน้าของเราอธิบายแนวคิดนี้ไว้แล้วว่าทำไมการแยกกลุ่มถึงเปลี่ยนการตัดสินใจ แต่ในห้องประชุมจริง ปัญหาไม่ได้อยู่ที่ทฤษฎี ปัญหาคือทีมมักแปะป้ายให้ฟีเจอร์ด้วยความรู้สึกของตัวเอง คนขายมั่นใจว่าฟีเจอร์ที่ลูกค้ารายใหญ่บ่นถึงคือ Must-be คนพัฒนามั่นใจว่าสิ่งที่ตัวเองอยากสร้างคือ Attractive แล้วการถกเถียงก็วนกลับไปที่เสียงดังกว่าชนะ ทางออกของเรื่องนี้คือการเก็บข้อมูลจากลูกค้าจริงด้วยแบบสอบถามแบบ Kano แล้วปล่อยให้ตัวเลขเป็นคนตัดสิน ซึ่งทำได้ในหนึ่งสัปดาห์กับลูกค้าไม่กี่สิบราย ถ้ารู้วิธีตั้งคำถาม วิธีแปลคำตอบ และวิธีคำนวณค่าสรุปที่ชื่อ Better–Worse coefficient
คำถามคู่: ถามทั้งด้านมีและด้านไม่มี
หัวใจของแบบสอบถาม Kano คือทุกฟีเจอร์ถูกถามสองครั้ง ครั้งแรกเป็นคำถามเชิงบวก (functional) — ถ้าระบบแจ้งเตือนคุณทาง LINE เมื่อสต๊อกใกล้หมด คุณรู้สึกอย่างไร และครั้งที่สองเป็นคำถามเชิงลบ (dysfunctional) — ถ้าระบบไม่มีการแจ้งเตือนนี้ คุณรู้สึกอย่างไร แต่ละคำถามให้เลือกตอบหนึ่งจากห้าระดับเหมือนกัน คือ ชอบมาก เป็นสิ่งที่ควรมีอยู่แล้ว เฉย ๆ ทนได้ และไม่ชอบ ความผิดพลาดที่พบบ่อยที่สุดคือการเขียนคำถามเป็นชื่อฟีเจอร์เชิงเทคนิคแทนที่จะเป็นผลลัพธ์ที่ลูกค้าสัมผัสได้ ลูกค้าตอบคำถามว่ามี API สำหรับเชื่อมต่อไม่ได้ แต่ตอบได้ทันทีว่ารู้สึกอย่างไรถ้ายอดขายจากทุกช่องทางมารวมในหน้าจอเดียวโดยไม่ต้องคีย์ซ้ำ กติกาง่าย ๆ คือเขียนคำถามจากสิ่งที่ลูกค้าเห็นหรือได้รับ ไม่ใช่จากสิ่งที่ทีมพัฒนาต้องสร้าง และจำกัดชุดคำถามไว้ที่ 10–15 ฟีเจอร์ต่อแบบสอบถามหนึ่งชุด เพราะเกินกว่านั้นคุณภาพคำตอบช่วงท้ายจะตกอย่างเห็นได้ชัด
ตารางแปลผล: จากคำตอบคู่สู่หมวดหมู่
คำตอบสองข้อของลูกค้าหนึ่งคนต่อหนึ่งฟีเจอร์ จะถูกจับคู่แล้วเปิดตารางแปลผลมาตรฐานของ Kano เพื่อจัดหมวด ตรรกะของตารางไม่ต้องท่องจำ เพราะมันสรุปได้เป็นหลักคิดสั้น ๆ ไม่กี่ข้อ
- ชอบเมื่อมี และไม่ชอบเมื่อไม่มี → One-dimensional (O): ฟีเจอร์เชิงประสิทธิภาพ ยิ่งดียิ่งพอใจ ไม่มียิ่งเสียใจ
- ชอบเมื่อมี แต่เฉย ๆ หรือทนได้เมื่อไม่มี → Attractive (A): ของว้าวที่ยังไม่มีใครคาดหวัง มีแล้วได้ใจ ไม่มีก็ไม่โดนหัก
- เฉย ๆ เมื่อมี แต่ไม่ชอบเมื่อไม่มี → Must-be (M): ของที่ถูกมองว่าต้องมีอยู่แล้ว ทำดีแค่ไหนก็ไม่มีใครชม แต่พลาดเมื่อไรโดนทันที
- เฉย ๆ ทั้งสองด้าน → Indifferent (I): ลูกค้าไม่แคร์ ทำไปก็เปลืองงบ
- ชอบเมื่อไม่มี หรือไม่ชอบเมื่อมี → Reverse (R): มีลูกค้ากลุ่มหนึ่งที่ฟีเจอร์นี้ทำให้ประสบการณ์แย่ลง เช่น ระบบอัตโนมัติที่ผู้ใช้บางกลุ่มอยากควบคุมเอง
- ชอบทั้งเมื่อมีและเมื่อไม่มี → Questionable (Q): คำตอบขัดแย้งกันเอง มักแปลว่าคำถามกำกวมหรือผู้ตอบไม่ตั้งใจ ตัดทิ้งจากการคำนวณ
Better–Worse coefficient: บีบสี่สิบคำตอบให้เหลือสองตัวเลข
เมื่อจัดหมวดคำตอบของผู้ตอบทุกคนแล้ว แต่ละฟีเจอร์จะมีจำนวนนับในแต่ละหมวด เช่น A กี่คน O กี่คน ปัญหาคือฟีเจอร์จริงแทบไม่เคยตกหมวดเดียวเด็ดขาด ลูกค้า 40 คนอาจกระจายเป็นสามสี่หมวดเสมอ ค่า Better–Worse coefficient จึงถูกออกแบบมาเพื่อสรุปการกระจายนี้เป็นสองตัวเลขที่อ่านง่าย Better บอกว่าถ้าทำฟีเจอร์นี้ สัดส่วนลูกค้าที่ความพึงพอใจจะเพิ่มขึ้นมีเท่าไร ส่วน Worse บอกว่าถ้าไม่ทำ สัดส่วนลูกค้าที่จะไม่พอใจมีเท่าไร โดยติดลบเสมอเพื่อย้ำทิศทาง
ลองกับตัวเลขจริง สมมติถามลูกค้า 40 รายเรื่องการแจ้งเตือนสต๊อกใกล้หมดผ่าน LINE ผลออกมาเป็น Attractive 16 คน One-dimensional 8 คน Must-be 4 คน และ Indifferent 12 คน ค่า Better คือ (16+8)/40 = 0.60 และ Worse คือ -(8+4)/40 = -0.30 อ่านว่าลูกค้า 6 ใน 10 จะพอใจขึ้นถ้าทำ แต่มีเพียง 3 ใน 10 ที่จะรู้สึกแย่ถ้าไม่ทำ ฟีเจอร์นี้จึงเป็นตัวสร้างความประทับใจมากกว่าเป็นของที่ขาดไม่ได้ เหมาะกับการใช้ชิงความต่างจากคู่แข่ง แต่ยังไม่ใช่เหตุผลเลื่อนงานซ่อมฟีเจอร์ Must-be ที่ Worse ลึกกว่า วิธีอ่านภาพรวมที่มืออาชีพใช้คือวางทุกฟีเจอร์ลงกราฟสองแกน แกนนอนคือ Better แกนตั้งคือ Worse ฟีเจอร์มุมขวาบน (Better สูง Worse ลึก) ทำก่อนเสมอ มุมขวาล่างคืออาวุธสร้างความต่าง มุมซ้ายบนคือหนี้ที่ต้องจ่ายให้ครบ และมุมซ้ายล่างคือรายการที่ควรกล้าตัดทิ้ง
กับดักการอ่านผลที่ทำให้ทีมเก่ง ๆ พลาด
ตัวเลขเดียวกันอ่านผิดได้หลายทาง กับดักแรกคือการรวมลูกค้าทุกกลุ่มไว้ในการคำนวณเดียว ฟีเจอร์ใบกำกับภาษีอัตโนมัติอาจเป็น Indifferent สำหรับร้านค้าทั่วไป แต่เป็น Must-be เด็ดขาดสำหรับลูกค้านิติบุคคล ถ้าเฉลี่ยรวมกันจะได้ค่ากลาง ๆ ที่ไม่จริงกับใครเลย ควรแยกคำนวณตามกลุ่มลูกค้าเสมอเมื่อมีเหตุให้เชื่อว่าพฤติกรรมต่างกัน กับดักที่สองคือการลืมว่าหมวดหมู่เสื่อมตามเวลา ฟีเจอร์ Attractive ของปีนี้จะกลายเป็น One-dimensional แล้วไหลลงเป็น Must-be เมื่อทั้งตลาดทำตาม การส่งฟรีของอีคอมเมิร์ซคือตัวอย่างคลาสสิก ผล Kano จึงมีวันหมดอายุและควรเก็บซ้ำเมื่อตลาดขยับ กับดักที่สามคือการเชื่อผลจากกลุ่มตัวอย่างจิ๋ว ถ้าผู้ตอบมีสิบคน การขยับของคนสองคนก็เปลี่ยนหมวดได้แล้ว ตัวเลขระดับนี้ใช้เป็นสัญญาณตั้งต้นเพื่อไปคุยต่อได้ แต่อย่าใช้ตัดสินการลงทุนก้อนใหญ่ และกับดักสุดท้ายคือหมวด Reverse ที่มักถูกมองข้าม ถ้าฟีเจอร์ไหนมี R เกินหนึ่งในสี่ นั่นไม่ใช่สัญญาณให้ทำแบบครึ่ง ๆ กลาง ๆ แต่เป็นสัญญาณให้ทำเป็นตัวเลือกเปิดปิดได้ หรือแยกผลิตภัณฑ์กันไปเลย
บริการที่เกี่ยวข้อง
รับพัฒนาระบบและซอฟต์แวร์เฉพาะทาง
ออกแบบและวางระบบตามความต้องการเฉพาะของธุรกิจคุณ ตั้งแต่ต้นจนใช้งานจริง
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

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

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

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

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