ผมเคยนั่งฟัง presentation ที่มีข้อมูลแน่นมาก แม่นยำ และวิเคราะห์มาอย่างดี
แต่ฟังจบแล้วคนในห้องประชุมก็พยักหน้าแล้วก็ “ไม่ได้ทำอะไรต่อ”
(คน present คนนั้น ผมก็เคยเป็นมาก่อนด้วย)
และผมก็เคยฟัง presentation อีกแบบที่ข้อมูลไม่ได้ละเอียดมากนัก แต่คนฟังออกจากห้องไปพร้อมกับรู้ว่าต้องทำอะไร
ความต่างของสองอย่างนี้ไม่ใช่คุณภาพของข้อมูลครับ แต่เป็นวิธีที่คนนำเสนอมันออกมา
ปัญหาที่เจอบ่อยมากในวงการ data คือคนที่เก่งเรื่องวิเคราะห์ข้อมูลมักไม่ถนัดเรื่องสื่อสาร และคนที่สื่อสารเก่งมักไม่มีพื้นฐาน data มากพอที่จะอธิบายให้แม่นยำ บทความนี้เลยอยากพูดถึงทักษะที่อยู่ตรงกลางครับ นั่นคือการเอาข้อมูลจริงๆ มาเล่าให้คนที่ไม่ได้ทำงานกับ data ทุกวันฟังแล้วเข้าใจและลงมือทำต่อได้
เข้าใจก่อนว่าคนฟังไม่ได้สนใจ data เขาสนใจแค่คำตอบ
นี่คือสิ่งแรกที่ต้องเปลี่ยนวิธีคิด
คนที่ทำงานกับ data มักตกหลุมพรางอย่างหนึ่งคือคิดว่าถ้าแสดงข้อมูลให้ครบและถูกต้อง
คนฟังจะสรุปเองได้ว่าควรทำอะไร ซึ่งในความเป็นจริงแล้ว คนฟังส่วนใหญ่ไม่ได้มานั่ง process ข้อมูลในหัวพร้อมกับเราครับ เขามาเพื่อรับคำตอบเท่านั้น
ลองเปลี่ยนวิธีเริ่ม presentation ดูครับ แทนที่จะเริ่มด้วย “วันนี้เราจะมาดูข้อมูลยอดขายในไตรมาสที่ผ่านมา” ลองเริ่มด้วย “ยอดขายของเราตกลง 15% และผมรู้แล้วว่าทำไม เดี๋ยวผมเล่าให้ฟัง”
สองประโยคนี้มีข้อมูลเท่ากันครับ แต่ประโยคที่สองทำให้คนฟังอยากฟังต่อทันที เพราะมันสัญญาว่าจะมีคำตอบรออยู่
หลักการง่ายๆ ที่ใช้ได้เสมอคือ ขึ้นต้นด้วยข้อสรุป แล้วค่อยอธิบายว่าทำไม ไม่ใช่กลับกัน
คนที่สนใจรายละเอียดจะถามเพิ่มเอง คนที่ไม่สนใจก็ได้รับสิ่งที่ต้องการแล้วจากประโยคแรก
เปลี่ยนตัวเลขให้เป็นสิ่งที่จับต้องได้จริง
ตัวเลขแบบนามธรรมักจะเข้าสมองได้ยากครับ
แต่ถ้าแปลงให้เป็นสิ่งที่คนฟังรู้จักจากชีวิตจริง มันจะเข้าใจได้ในวินาทีเดียว
ลองเปรียบเทียบสองแบบนี้ครับ
แบบแรก “ระบบนี้ลดเวลาประมวลผลลงได้ 73% จาก 45 นาทีเหลือ 12 นาที”
แบบที่สอง “เมื่อก่อนกว่าจะรู้ผลต้องรอเกือบครึ่งชั่วโมง ตอนนี้แค่เดินไปชงกาแฟเสร็จ ก็รู้แล้ว”
ข้อมูลเหมือนกันทุกอย่างครับ แต่แบบที่สองทำให้คนฟังเห็นภาพได้ทันที เพราะทุกคนรู้ว่าการเดินไปชงกาแฟใช้เวลาเท่าไหร่
เทคนิคนี้เรียกว่า Anchoring to the familiar
หลักการคือเอาตัวเลขที่อยากจะสื่อสาร แล้วหาสิ่งที่คนฟังคุ้นเคยอยู่แล้วมาเทียบ ไม่ว่าจะเป็นระยะทาง เวลา เงิน หรือสิ่งของในชีวิตประจำวัน
อีกตัวอย่างที่ดีครับ แทนที่จะบอกว่า “บริษัทเสียรายได้ 1 แสนบาทต่อเดือนจากปัญหานี้” ลองบอกว่า “ทุกวันที่เราปล่อยปัญหานี้ไว้ เราเสียเงินไปเท่ากับเงินเดือนพนักงาน 2 คน” แบบหลังทำให้คนรู้สึกว่ามันเป็นเรื่องเร่งด่วนที่ต้องแก้ครับ ไม่ใช่แค่ตัวเลขในรายงาน
เลือก chart ให้ถูก กับสิ่งที่อยากบอก
คนส่วนใหญ่เลือก chart โดยใช้ความรู้สึกว่าอันไหน “ดูดี” ครับ
แต่จริงๆ แล้ว chart แต่ละแบบเหมาะกับการบอกเรื่องที่ต่างกัน ถ้าเลือกผิดคนดูจะสับสนแม้ข้อมูลจะถูกต้อง
Bar Chart ดีที่สุดสำหรับเปรียบเทียบหมวดหมู่ เช่น ยอดขายของแต่ละสาขา หรือจำนวนลูกค้าในแต่ละช่วงอายุ อะไรก็ตามที่อยากให้คนเห็นว่าอะไรมากกว่าอะไร
Line Chart ดีที่สุดสำหรับแสดงแนวโน้มตามเวลา เช่น ยอดขายรายเดือน อุณหภูมิรายวัน หรือจำนวนผู้ใช้งานที่เพิ่มขึ้น ถ้าอยากให้คนเห็นว่ามันขึ้นหรือลง ใช้เส้นครับ
Pie Chart ใช้เฉพาะเมื่ออยากแสดงสัดส่วนของส่วนรวม และควรมีไม่เกิน 2-3 ชิ้น ถ้ามีมากกว่านั้นมันจะดูรกและอ่านยาก
pie chart ที่มี 15 ชิ้นไม่ได้บอกอะไรเลยครับ
Scatter Plot ใช้เมื่ออยากแสดงความสัมพันธ์ระหว่างตัวแปรสองตัว เช่น ยิ่งลงทุนโฆษณาเยอะยอดขายเพิ่มขึ้นไหม แต่อันนี้ต้องระวังเรื่องการอธิบายให้ชัด เพราะคนทั่วไปไม่คุ้นเคยกับ chart ประเภทนี้
กฎง่ายๆ ที่ใช้ได้เสมอคือ ถ้าคนดูต้องใช้เวลามากกว่า 5 วินาทีในการเข้าใจ chart แปลว่า chart นั้นล้มเหลวในหน้าที่ของมันครับ ไม่ใช่ความผิดของคนดู
ลด noise ใน slide และ chart ให้เหลือแค่สิ่งที่สำคัญ
นี่คือสิ่งที่คนทำ data presentation ผิดพลาดบ่อยที่สุด นั่นคือใส่ข้อมูลมากเกินไปในหน้าเดียว
มีหลักการที่เรียกว่า Data-Ink Ratio ของ Edward Tufte ครับ แนวคิดคือทุกอย่างที่อยู่ใน chart ควรมีหน้าที่ในการสื่อสารข้อมูล ถ้าลบออกแล้วข้อมูลยังเข้าใจได้เหมือนเดิม สิ่งนั้นก็ควรที่จะถูกลบออก
ลองดูว่า chart ของคุณมีสิ่งเหล่านี้ไหม เส้นกริดที่ไม่จำเป็น สีสันที่ใช้เพราะดูสวยแต่ไม่ได้สื่อความหมาย legend ที่อธิบายสิ่งที่ label บน chart อยู่แล้ว หรือ decimal place ที่ละเอียดเกินความจำเป็น เช่น 47.3829% ทั้งที่บอกแค่ “เกือบครึ่ง” ก็พอ
นอกจากนั้นใน slide เองก็เช่นกันครับ ถ้าใน slide หนึ่งมีข้อมูลสามสี่ประเด็น คนฟังจะไม่รู้ว่าควรดูตรงไหนก่อน ลองแตก slide ออกเป็นหลายหน้า แต่ละหน้ามีแค่ประเด็นเดียวที่ชัดเจน วิธีนี้ทำให้ควบคุมการเล่าเรื่องได้ดีกว่ามากเยอะเลย
เทคนิค SCR — Structure ที่ทำให้เรื่องซับซ้อนๆ ฟังแล้วดูง่าย
ผมใช้โครงสร้างนี้บ่อยมาก ในการนำเสนอข้อมูล เรียกว่า SCR ย่อมาจาก Situation, Complication, Resolution
Situation คือบริบทที่ทุกคนในห้องรู้อยู่แล้วและเห็นด้วยกัน เช่น “ไตรมาสที่ผ่านมาเราตั้งเป้ายอดขายไว้ที่ 10 ล้านบาท”
Complication คือสิ่งที่เปลี่ยนแปลงหรือปัญหาที่เกิดขึ้น เช่น “แต่ทำได้จริงๆแค่ 7.5 ล้าน และข้อมูลบอกว่าปัญหาหลักมาจากกลุ่มลูกค้าอายุ 25-35 ที่ยอดหายไปกว่า 40%”
Resolution คือสิ่งที่ควรทำต่อจากข้อมูลที่มี เช่น “เราควรปรับแคมเปญการตลาดไปโฟกัสที่กลุ่มนี้ โดยเฉพาะช่องทาง Instagram ที่ข้อมูลบอกว่า engagement ของกลุ่มนี้ยังดีอยู่”
โครงสร้างนี้ทำงานได้ดีเพราะมันเลียนแบบวิธีที่สมองมนุษย์ประมวลเรื่องราวตามธรรมชาติ เราชินกับการฟัง “ปกติเป็นแบบนี้ แต่แล้วมีอะไรเกิดขึ้น และนี่คือสิ่งที่ต้องทำ” มาตั้งแต่เด็ก
รู้ว่าเมื่อไหรควรพูดน้อยลง และปล่อยให้ข้อมูลพูดแทน
นี่คือทักษะที่ใช้เวลา “ฝึกนานที่สุด”
มีช่วงเวลาที่ข้อมูลพูดแทนตัวเองได้ดีมากจนการอธิบายเพิ่มเติมกลับทำให้สับสนมากขึ้น
ถ้าคุณแสดง chart ที่ชัดเจนว่ายอดขายตกลงฮวบในเดือนที่แน่นอน คนดูเห็นแล้วครับ ไม่ต้องบอกซ้ำว่า “จะเห็นได้ว่ายอดขายตกลงในเดือนนี้”
แต่ก็มีช่วงเวลาที่ต้องพูดมากกว่านั้น เช่น เมื่อข้อมูลอาจถูกตีความผิดพลาดได้ง่าย หรือเมื่อ context สำคัญมากๆ และไม่มีทางใส่ลงใน chart ได้หมด
กฎที่ดีครับคือ หลังแสดง chart แต่ละอัน ถามตัวเองว่า “ถ้าฉันไม่พูดอะไรเลย คนดูจะเข้าใจผิดไหม?”
ถ้าคำตอบคือไม่ ก็อาจไม่ต้องพูดอะไรเพิ่ม แต่ถ้าคำตอบคือใช่ นั่นแหละคือสิ่งที่ต้องพูด
สรุป — Data ที่ดีแต่ไม่มีใครเข้าใจ ก็ไม่ต่างจากการไม่มี Data
ผมเชื่อว่าทักษะที่ขาดแคลนที่สุดในวงการ data ไม่ใช่การวิเคราะห์ครับ แต่เป็นการสื่อสารมากกว่า เชื่อมากๆ
มีนักวิเคราะห์เก่งๆ จำนวนมากที่งานวิเคราะห์ดีมาก แต่ไม่มีใครเอาไปใช้ต่อเพราะฟังแล้วไม่เข้าใจ และมีนักสื่อสารเก่งๆ ที่พูดน่าฟังมาก แต่ข้อมูลที่นำเสนอไม่แม่นยำพอที่จะเชื่อถือได้
คนที่รวมทั้งสองอย่างได้ นั่นคือวิเคราะห์ได้แม่นและเล่าได้ชัด มีคุณค่ามากในทุกองค์กรครับ และยังดีที่ทักษะนี้มันฝึกฝนได้
ไม่ใช่พรสวรรค์ที่มีมาแต่กำเนิด
เริ่มจากการฝึกอธิบาย insight ที่ได้จากงานตัวเองให้คนนอกสายงาน data ฟังครับ
ถ้าเขาเข้าใจและถามคำถามต่อ แสดงว่าคุณสื่อสารได้แล้ว ถ้าเขาพยักหน้าแต่ตาเหม่อ แสดงว่ายังต้องฝึกต่อ
และนั่นก็โอเคครับ เพราะอย่างน้อยคุณก็รู้แล้วว่าต้องพัฒนาตรงไหนหลังจากนั้น
Leave a Reply