Data, Insight และ Solution
เรื่องนึงที่ผมพบว่ายากที่จะอธิบายและเป็น Challenge ขนาดใหญ่ของการทำ Product development คือการเข้าใจ Data และ Insight
ในระบบหนึ่งที่ผมพัฒนา มีการทำการสำรวจผู้ใช้งานว่าต้องการอะไรเพิ่ม และเราก็พบว่า มีคนขอความสามารถในการ Print หน้าจอออกมาเป็น PDF เยอะจนมีนัยสำคัญทางสถิติ
หลายๆ คนในทีมพัฒนาก็บอกว่าเรามาพัฒนาให้มัน Export หน้าจอออกเป็น PDF ได้กันเถอะ มันเป็นสิ่งที่คนใช้งานต้องการมากเลยนะ
ผมถามคำถามว่า “ทำไมเขาถึงอยากพิมพ์”
ผมลองไปหาคำตอบจาก User แต่ละคนดู ลอง Sample ตัวอย่างและจี้ถามลงไป
User หลายคนตอบว่า หลายๆ ครั้ง เขาต้องเอาข้อมูลไปเสนอเจ้านายและลูกค้าในห้องประชุม เขาเลยอยากพิมพ์ออกไป
สุดท้ายผมจึงเลือกพัฒนาให้สามารถ Export ออกไปเป็น Google Sheets ที่สามารถปรับแต่งได้
ผมมองว่าถ้าโจทย์เป็นแบบนี้ การทำ Export Google Sheets มันตอบมากกว่าพยายามพิมพ์ PDF เพราะถ้าเขาต้องเอาไปเข้าห้องประชุม หลายๆ ครั้งก็ต้องมีการเน้นสีตัวเลขต่างๆ มีการเพิ่ม Mark เพิ่ม Highlight หรือแม้แต่ซ่อนแสดงข้อมูลบางอย่างให้เหมาะกับบริบทของ Presentation
ไม่นับที่ว่าการทำ PDF Layout ให้แม่นยำเป๊ะๆ บนข้อมูลขนาดแตกต่างกัน นั้นยากกว่าการ Export Google Sheets เป็นอย่างมาก
สุดท้าย Feedback ของงานนี้ออกมาดีทีเดียว และก็ไม่มีใครขอ Print PDF บนหน้าจอนั้นอีก
ผมพบว่าถ้าเราจะทำต่ออันนี้ เราอาจจะให้ Export ไปเป็น Presentation พวก Powerpoint ไปเลยก็น่าจะดี แต่คงมิใช่การกลับไปทำให้พิมพ์เป็น PDF ได้
ในที่นี้ เราต้องแยกแยะให้ออกระหว่าง Data, Insight และ Solution
อย่างในกรณีของผม
- Significant proportion of user-based ต้องการความสามารถในการพิมพ์ ตรงนี้เป็น Data เป็นข้อมูล
- เขาต้องการการพิมพ์เพื่อนำไป Present กับคนอื่นในงานประชุม อันนี้เป็น Insight
- Feature ในการส่งออกข้อมูลไปยัง Google sheet เป็น Solution
Data ไม่ใช่ Insight และไม่ใช่ Solution ข้อมูลก็เป็นแค่ข้อมูล
Insight ก็คือ Insight ไม่ใช่ Data และไม่ใช่ Solution เช่นกัน
Data is not a solution
ข้อมูลเป็นแค่ข้อมูล มันไม่มีทางออก ไม่มีถูกผิด ไม่มีคำตอบ เป็นแค่ข้อมูล เป็นแค่วัตถุดิบก้อนนึงที่เราต้องนำมาตีความ
หลายๆ ครั้งที่ผมเห็นองค์กรหรือทีมที่บอกว่าตัวเองเป็น Data-driven มักทำพลาดที่เอา Data มาเป็น Solution เลย โดยไม่เห็นว่าตัวเองไม่ได้ตีความข้อมูลอย่างมืออาชีพอย่างที่มือโปรด้าน Data เขาทำกัน
หลายๆ ครั้งผมเห็นองค์กรส่ง User Survey แล้วเอาสิ่งที่ User ตอบมาเป็นแนวทางพัฒนาต่อเลย
Survey ออกมา User บอกว่าต้องการ Feature A ก็เลยบอกว่าทำ A กันเถอะ ไม่ตีความอะไรต่อ เขาเหล่านี้มักจะมองว่า ถ้าทำตาม User บอก เราไม่ผิดชัวร์ (และไม่โดนผู้บริหารต่อว่าแน่นอน ก็ผมเชื่อ User อ่ะครับ)
แล้วก็เข้าใจว่าการทำแบบนี้ เป็นการทำงานแบบ Data-driven โดยมองไม่เห็นว่าตัวเองไม่ได้ตีความข้อมูลเลย
อันนี้เป็นหล่มแรกที่ตกบ่อย
หลายๆ ครั้งผมเห็นองค์กรตีความ User survey ออกมาเป็น Solution โดยไม่เห็นว่าตัวเองกำลัง “ด่วนสรุป” อยู่
Survey ออกมา User บอกว่าระบบทำงานช้า แล้วในทีมพัฒนาก็มานั่งถามกันว่า “อะไรช้า” แล้วนาย A ก็บอกว่า “นี่ตรงนี้แน่ๆ เลยที่ช้า ผมใช้บ่อย ผมมั่นใจว่า User บ่นว่าตรงนี้ช้า”
แล้วก็เข้าใจว่าการทำแบบนี้ เป็นการทำงานแบบ Data-driven โดยมองไม่เห็นว่าตัวเองใส่การตีความ เกินสิ่งที่ข้อมูลบอกไปมาก
อันนี้เป็นหล่มที่สองที่ตกบ่อย
คนที่ใช้ Data ต้องเข้าใจว่า Data มันเป็นแค่ Data มันไม่มีถูกไม่มีผิด ไม่ชี้อะไรทั้งนั้น ข้อมูลเป็นแค่ข้อมูล
ทุกคนเก็บข้อมูลได้
แต่คนที่ตีความอย่างเฉียบคม
ถึงจะสามารถใช้ข้อมูลเป็นข้อได้เปรียบ ใช้ข้อมูลในการเป็นผู้นำในตลาด
Insight is not a data
กลับมาอีกทางหนึ่ง หลายๆ ครั้งเวลาที่เราเริ่มทำ User interview กันจริงจัง ทำ UX Research กันจริงจัง ผมก็พบว่าหลายๆ ครั้งเราจะเกิดอาการ “อิน” จนมองไม่เห็นภาพรวม
การหา Insight เป็นการหาข้อมูลอย่างละเอียด ซึ่งมักจะทำในสเกลใหญ่ไม่ได้
หลายๆ ครั้งผมพบว่า คนที่ทำเรื่อง Insight มักจะมีปัญหากับ Data Science เพราะตัวเอง “อิน” กับคนตรงหน้าเยอะจนมองไม่เห็นภาพรวม
สมมติคุณ Sampling พลาด ทำกับคนที่ไม่ได้ Represent Persona ที่ต้องการสร้าง Feature คุณจะรู้ได้อย่างไร
ผมตอบว่า ทั่วไป Insight ควรจะสอดคล้องกับ Data ระดับนึง ไม่งั้นเป็นไปได้สูงว่า Insight ไปสำรวจมาไม่ตรงกับภาพใหญ่
แต่หล่มทั่วไปคือ คนที่ทำ User Interview มักจะ Emotionally invest ไปกับคนที่สัมภาษณ์ หรือถ้าไม่เก๋าพอ อาจจะเผลอไปพูดจาแนวสร้าง Commitment กับ Interviewee ไป
จนสุดท้ายต้อง Push agenda ของตัวเองหนักกว่าที่ควรเป็น แม้ว่ามันจะขัดกับ Data ก็ตาม
ถ้าจะทำ UX Research อย่างเป็นกลาง ต้องระวังเรื่องนี้ให้มาก
(โดยเฉพาะคนที่ทำ Internal solution และทำ Interview กับผู้ใช้ระดับ “ผู้บริหารขั้นสูง” มักจะมีแรงกดดันพิเศษ)
ผมเขียนเรื่องนี้คืออยากจะฝากไว้ว่า “อย่าขี้เกียจ” กับการตีความข้อมูล
คุณต้องแยกแยะให้ออก
จำไว้เสมอว่า Data เป็นแค่ข้อมูล ไม่ใช่คำตอบ
จำไว้เสมอว่า Insight เป็นภาพละเอียด ไม่ใช่ภาพรวม
Data -> Assumption -> Hypothesis -> Test
จะขาดขั้นตอนใดขั้นตอนหนึ่งไม่ได้
และมันมีเหตุผลที่เขาเรียกขั้นที่สองว่า Assumption ไม่ใช่ Solution
ถ้าไม่มั่นใจว่าเราตีความข้อมูล หรือด่วนสรุปอยู่
ผมแนะนำง่ายๆ ครับ ให้จำไว้ว่า ทุกข้อมูล มันตีความได้หลายแบบ
ถ้าคุณตีความข้อมูลออกมาเป็น Solution ได้เกิน 2–3 แบบขึ้นไป แล้วสุดท้ายเลือกแบบใดแบบหนึ่ง อันนี้คือคุณไม่ด่วนสรุปแล้ว
แต่ถ้าข้อมูลมันออกมาแล้วคุณมองเห็นว่า “ชัดมาก นี่แหละทางไปต่อ มันเป็นแบบนี้แน่ๆ”
อันนี้ให้พึงสงสัยว่า ตัวเองกำลังด่วนสรุปข้อมูลอยู่
เอาเป็นว่าไม่เคยมีครั้งไหนในชีวิต ที่ผมจะพบว่า ข้อมูลแต่ละข้อมูล จะมี Interpretation แบบเดียวน่ะครับ ยังไม่เคยเจอมาก่อนจริงๆ
เราในฐานะพัฒนา ในฐานะ Developer
เราไม่ได้ทำงานตามสั่ง แต่เราเป็น Problem solver
เราฟังปัญหาของลูกค้า แล้วเสนอทางออก
นั่นคือ Value added ของเรา
นั่นคือสิ่งที่แยกระหว่าง “กรรมกรผลิตโค้ด” และ “นักพัฒนา”
เพราะถ้าคุณทำตามสั่งเด๊ะๆ เสมอ
มันก็ไม่ต่างอะไรกับคนทำงานผลิตในสายพานน่ะครับ
และแน่นอนการเป็นนักพัฒนามันเป็นเรื่องยาก
การเสนอทางออกที่ไม่ทำตามใบสั่ง ก็จะมีแรงต้าน ต้องใช้แรงในการ Present ในการอธิบาย ในการนำเสนอ ในการสร้างความไว้ใจว่าที่เราไม่ทำตามเขาสั่งเนี่ย เราไม่ได้คิดขี้เกียจตัดสโคปงานให้น้อยลงนะ แต่เราคิดเผื่อเขา เราคิดไปไกลกว่าเขา
มันยากกว่าการทำตามใบสั่งเยอะมากๆ การเอาข้อมูลมาใช้เด๊ะๆ เยอะมากๆ
แต่เพราะมันยากนี่แหละ
คนที่ทำได้ ถึงได้มี Value ในตลาดนักพัฒนา สูงกว่าคนที่ทำไม่ได้ มากมายเหลือเกินครับ
และผมยืนยันจากประสบการณ์ส่วนตัวได้ว่า มันทำได้จริงๆ ครับ