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 ในตลาดนักพัฒนา สูงกว่าคนที่ทำไม่ได้ มากมายเหลือเกินครับ

และผมยืนยันจากประสบการณ์ส่วนตัวได้ว่า มันทำได้จริงๆ ครับ