What’s in it for them? ทำไมพูดอะไรไปก็ไม่เห็นมีใครเห็นด้วยเล๊ย เผยเทคนิคลับ ในการถกเถียงเจรจาต่อรอง

Doppio_Toasty-EDlT0R

Other

March 24, 2026

Table of Content

เชื่อว่าในชีวิตประจำวันของเรา ตอนทำงานบางทีเราก็รู้สึกว่าไอ้ตัวงานเนี่ย ง๊ายง่าย ไม่ได้ยากอะไรมากมาย แต่ทำไม๊ เวลาต้องไปติดต่อเจรจากับคนนี่มันยากจังนะ โดยเฉพาะกับคนที่เราไม่ได้สนิทด้วยหรือไม่ได้แบบมี relationship ที่จะทำให้พยายามช่วยเหลือกันโดยง่ายเนี่ย มันย๊ากยาก บางทีเราก็ว่าเรื่องทีเราบอกหรือขอไป มันโคตรจะ make sense แต่ทำไมอีกฝั่งมันไม่ get ไม่เห็นด้วยกับเราง่ายๆเลยนะ

ปัญหามันอยู่ตรงนี้แหล๊ะ หลายๆครั้งเราคิดว่ามัน make sense เพราะเราคิดและพูดถึงสิ่งต่างๆในมุมมองของเรา ดังนั้นคำพูดของเรามันคือ what’s in it for me แต่ what in it for เรา (me) เนี่ย ส่วนใหญ่แล้ว มันจะไม่ใช่ what’s in it for them เล๊ย คำว่า what’s in it for them ในที่นี้ มองง่ายๆคือ ประโยชน์หรือ value ที่เกิดขึ้นกับคู่สนทนาของเรา ถึงจุดนี้ น่าจะเริ่มงงๆกันหล่ะ อะไรคือ for me อะไรคือ for them อิหยั๋งหว่า

มาดูตัวอย่างกันดีกว่า ถ้าเรารู้สึกว่าคอมพิวเตอร์บริษัทที่เราใช้มันเก๊าเก่า อยากได้ใหม่ แล้วเราไปบอกหัวหน้าว่า “อยากได้คอมใหม่ครับพี่ คอมผมมันเก๊าเก่า” อันนี้ในมุมของเรา make sense สุดๆ ก็คอมมันเก่าเกินกว่าจะทำงานได้ดี ก็ขอใหม่อ่ะ ต้องให้สิ่ แต่บางทีเราก็ลืมคิดไปว่า ถ้าเราเป็นพี่หัวหน้าเนี่ย ทำไมเราถึงจะอยากให้คอมใหม่กับน้องคนนี้นะตอนนี้ยุ่งอยู่ ทดไว้ก่อนละกัน ทีนี้ มาลองดู take 2 กัน ถ้าเราคิดเพิ่มนิดนึง ว่าที่เราจะขอพี่เค้าเนี่ยมันมี what’s in it for them (them ในที่นี้คือ พี่หัวหน้า) สำหรับพี่หัวหน้าเค้าบ้างมั๊ย เราจะเห็นมุมอีกมุมนึงว่า เออหว่ะ ไม่มีเลย ทำไมพี่เค้าต้องให้เรานะ ตอน take 2 เนี่ย ลองคิดและเพิ่ม what’s in it for them เข้าไป เราก็อาจจะได้ประโยคขอใหม่ว่า “พี่ครับตอนนี้คอมที่ผมใช้ มันเก่ามากเลย เวลา compile software ทีใช้เวลาเป็นชั่วโมงเลยพี่ ถ้าได้คอม spec ใหม่มาเนี่ย ผม research ดูแล้วมันลดเวลาเหลือแค่ 5 นาทีเองครับ ถ้าเป็นแบบนี้ ผมจะทำงานได้ effective และ deliver งานได้เพิ่มขึ้น 20% เลยนะครับ โปรเจคที่ทำอยู่ก็จะเสร็จเร็วขึ้น” ลองคิดตามดูนะครับ แบบแรกหรือแบบหลัง ถ้าเราเป็นพี่หัวหน้า เราจะ say yes กับอันไหนง่ายกว่ากัน

ตัวอย่างที่ 2 ถ้าเราเป็น tester เราเจอบั๊ก แล้วเราไปบอกทั้ง dev และ project/product manager ว่า บั๊กตัวนี้ต้อง fix ก่อน deploy นะ อันนี้ก็ฟังดูเป็นเรื่องปกติ make sense สำหรับเรา ก็มีบั๊กอ่ะ ก็ต้อง fix สิ แต่บางทีเราอาจจะลืมไปว่า สิ่งที่เราแจ้งบั๊กกับทีมเนี่ย by design เลย มันคือข่าวร้ายสำหรับ dev เพราะเค้าต้องทำงานแก้บั๊กเพิ่ม และเป็นข่าวร้ายสำหรับ project/product manager เพราะเค้ายัง release software ไม่ได้ ทีนี้ลองมาใช้เทคนิค what’s in it for them ดูซิว่าจะเปลี่ยนไปยังไงได้มั่ง

Take 2 คุยกับ dev: เพื่อน Dev เราว่า bug ตัวนี้ต้อง fix ก่อน deploy ขึ้น production นะ ลองคิดดูดิ่เพื่อน ถ้าเรายังไม่ fix มันอ่ะ feature ใหม่ที่เรามีแปลนจะ add มันมาใน phase 2 เนี่ย แต่ะโค้ดตรงนี้ล้วนๆเลยนะ ถ้าไม่แก้ตอนนี้ น่าจะไปแก่ะโค้ดแก้ทีหลังยากมากเลยนะ แล้วเอาจริงๆถ้าปล่อยบั๊กตัวนี้ไปก่อน เดี๋ยวพอขึ้น production นะ ลูกค้าโวยวายมาต้องมาทำงานดึกๆเสาร์อาทิตย์ รีบออก hotfix ไปอีกนะ เหนื่อยกันอีก รีบ fix ตอนนี้เลยดีกว่า

Take 2 คุยกับ Product/Project manager: พี่ครับ bug ตัวนี้ผมว่าควรจะ fix เลยนะ เพราะว่าถึง impact มันจะดูไม่แรงมากสุดๆ แต่จุดที่มันพังเนี่ย มันมีโอกาสที่กลุ่มลูกค้า vip ของเราจะมาเจอ ซึ่งถ้าลูกค้า vip มาเจอแล้วโวยวายเนี่ย เป็นเรื่องใหญ่แน่ผมว่า พี่ได้รับโทรศัพท์จาก ceo แน่ๆเลยครับ เราใช้แค่สองวัน fix กับ test มันก่อนขึ้น production กันเถอะ

พอเห็นภาพมั๊ยครับ แม้แต่ what’s in it for them ระหว่าง dev กับ project/product manager ก็ไม่เหมือนกันแล้วนะ และมันก็ไม่เหมือน what’s in it for เราอย่างแน่นอน

จากประสบการณ์ส่วนตัวเนี่ย การฝึกใช้อันนี้จนชิน กับการไม่ได้นึกถึงและไม่ใช้เลยมันต่างกันมากนะครับ ผลที่ได้ ต่างกันฟ้ากับเหว จนถ้าเราใช้จนชิน เวลาเราเห็นคนคุยกัน พยายาม convince กันแล้วไม่สำเร็จ หรือเวลาเห็นคนทะเลาะกัน เราจะเห็นภาพชัดเลยว่า อ่อ ก็เค้าไม่ได้ใช้ ไม่ได้คิดถึง what’s in it for them เลย ต่างคนต่างพูด what’s in it for me ใส่กันล้วนๆ แล้วก็ต่างมั่นใจว่า ก็ไอเดียที่ชั้นเสนอหรือพูดเนี่ย ถูกต้อง ทำไมแก (คู่สนทนา)ไม่ get นะ ไม่ได้เรื่องเลย แค่นี้ก็ไม่เค้าใจ

เอาจริงๆแล้ว หลายๆครั้ง พอฝึกคิดแบบนี้ เราก็เข้าใจและยกเลิกความคิดเราไปเองโดยที่ไม่ต้องพูดออกมาเลยนะ เพราะเราเข้าใจแล้วว่า what’s in it for เรา เนี่ย คิดดีๆแล้วมันไม่ make sense เลย หา what’s in it for them ไม่ได้เลย แบบ มันเป็น check and balance ให้ตัวเองได้ดีเลยหล่ะ

แนะวิธีฝึกง่ายๆคือ เริ่มตั้งแต่ตอนนี้ เวลาเราเถียงกับใคร หรือไป convince ใครไม่สำเร็จ หลังจากจบเหตุการณ์แล้ว มาย้อนดูซิ นี่เวลาเราพูด เราใช้ what’s in it for them รึเปล่า ทีนี้ส่วนใหญ่ เราก็จะเก็ทว่า เออ ไม่ได้คิด ไม่ได้ใช้เลยหว่ะ ทีนี้ให้ลองฝึกคิด take 2 นะ ว่าถ้าย้อนเวลากลับไปได้ แล้วใช้ what’s in it for them เนี่ย เราจะพูดว่ายังไง ฝึกคิดแบบนี้ตามหลังบ่อยๆ เราจะเริ่มใช้มันแบบ real time ได้เอง

ถ้าจะเจาะลึก what’s in it for them ก็มีไปลึกได้อีกนะ ตัวอย่างเช่น ชวนให้เห็นประโยชน์ร่วมกัน การขู่ว่าถ้าไม่ทำจะเกิดแบบโน้นนี้ การ refer ถึงหัวหน้าหรือคนใหญ่ ๆ บางทีก็เอามาใช้เป็น what’s in it for them ได้ เช่น คุยกับพี่หัวหน้าใหญ่มาแล้ว เค้าโอเค (แต่ไม่แนะนำให้ใช้บ่อย ใช้ share value เวิร์คสุด) ไว้ว่างๆจะเขียนแยกเทคนิคเบื้องลึกให้อีกทีละกันนะ

Related Blog

Automation Test

คิดและเลือก automation framework อย่างไรในปี 2023

จริงถึงแม้จะจั่วหัวไว้ว่าเป็นปี 2023 แต่จริงๆหลักการนี้ใช้ได้ทุกปีแหละครับ แหะๆ ซึ่งบทความนี้ได้แรงบันดาลใจจากที่ว่า ช่วงนี้น้องๆ หลายคนที่เคยทำงานด้วยกัน ทักมาปรึกษาโน้นนี่นั่นกันอยู่เป็นระยะๆ หลายๆครั้งมีน้องบางคนเข้าไปทำงานในบริษัทที่ยังไม่มี Automation เลย พูดง่ายๆ คือการเข้าไปเริ่มตั้งไข่ให้เองนักเลงพอ และหลายคนจะกลับมาถามคำถามเดียวกัน (คำถามเดียวกันจริงๆนะ) บทสนทนาจะเป็นประมาณนี้ น้อง : พี่โอ ว่างไหมพี่โอ : ครับน้อง : สบายดีนะครับโอ : สบายดีครับ เราล่ะเป็นไงบ้างน้อง : พี่โอ cypress นี่ดีไหมครับ (ไม่พูดพร่ำทำเพลง get to the point ดีมาก) พอคุยไปคุยมา เรามักจะได้คำตอบว่า น้องได้รับมอบหมายว่าให้เริ่มต้นทำ Automation โดยเริ่มตั้งแต่เลือก Framework ไปจนถึงวาง Project structure วันนี้เลยอยากจะมาลองแชร์ว่า ปกติเวลาเราจะเลือก Framework มาใช้เนี่ยเราควรดูอะไรบ้าง แต่ก่อนจะเข้าเรื่องบอกก่อนเลยว่า มันไม่มีคำว่า “ดี” หรือ “ไม่ดี”…

QA

สามเหลี่ยม’ ที่จะช่วยจัดการ project ให้ดี

"สามเหลี่ยมกู้ชีพ" เคล็ดลับการบริหารโปรเจกต์และต่อรองฉบับสายเทค ในการทำงานสาย Tech ไม่ว่าจะเป็น Developer, QA หรือ Software Tester ปัญหาที่พบบ่อยที่สุดคือ "เวลาไม่พอ" หรือ "สโคปงานที่เพิ่มขึ้นกะทันหัน" หลายคนเลือกที่จะแก้ปัญหาด้วยการทำงานหนักหรืออยู่ล่วงเวลา (OT) แต่วิดีโอนี้ได้นำเสนอทางออกที่ยั่งยืนกว่าผ่านแนวคิด "สามเหลี่ยมบริหารจัดการ" 1. รู้จัก 3 แกนหลักของสามเหลี่ยม หัวใจสำคัญของการบริหารโปรเจกต์ประกอบด้วย 3 ส่วนที่สัมพันธ์กันคือ เวลา (Time), ขอบเขตงาน (Scope) และ ทรัพยากร (Resource) กฎเหล็กของสามเหลี่ยมนี้คือ "ถ้าแกนใดแกนหนึ่งเปลี่ยน อีก 2 แกนที่เหลือต้องเปลี่ยนตามเพื่อรักษาความสมดุล" ตัวอย่างเช่น หากเวลาลดลง (Deliver ช้าลง) สิ่งที่ต้องพิจารณาคือ: เพิ่ม Resource: อาจจะขอคนเพิ่ม แต่ต้องเป็นคนที่มีความรู้อยู่แล้ว (Knowledge) ถึงจะช่วยได้จริง ซึ่งในความเป็นจริงนั้นหาได้ยาก ลด Scope: นี่คือสิ่งที่ควรตั้งคำถามกับ PM หรือลูกค้าว่า "มีส่วนไหนที่ตัดออกได้บ้างเพื่อให้เราส่งมอบงานได้ทันเวลา?"…

QA

Software Tester/QA 100.1

วันนี้มาด้วยชื่อ blog แปลกๆ คือปกติมันต้องเริ่มด้วย 101 แต่ว่าอันนี้มันยิ่งกว่า 101 มันเป็นจุดเริ่มต้นยิ่งกว่านั้นเอาเป็นชื่อ 100.1 ละกันนะ Inspiration เริ่มมาจากมีน้องๆหลายคนมากมาสมัครงานแบบที่ไม่มีประสบการณ์ software testing เลย มีทั้งแบบ new grad และแบบที่อยากเปลี่ยนสายงาน จาก IT support มั่ง Sale มั่ง Admin มั่งทั้งที่จบตรงและไม่ตรงสาย เอาจริงๆเห็น potential น้องๆหลายคนเลยนะ ที่สามารถเรียนรู้และเปลี่ยนสายงานได้ (แล้วก็หางาน QA ให้ได้สำเร็จ ของไม่ตรงสายได้แล้วหนึ่งคน เย่) คือที่เห็น น้องๆหลายคนอยากเปลี่ยนสาย ก็พยายามไปหาความรู้ บางคนเริ่มไปดู automate บางคนไปอ่านกับเรียนวิธีการ test text box ต่างๆ เอาจริงๆก็ดีใจที่เห็นน้องอยากเปลี่ยนสายแล้วลงทุนเรียนรู้ แต่อีกมุมนึงก็รู้สึกว่าหลายๆคนไปกันแบบโหวงๆ ยังไม่รู้ด้วยซ้ำว่าจุดที่ชั้นไปอ่านไปเรียนมันคือตรงไหนของงาน ไม่เข้าใจลักษณะงานหลักๆเลยด้วยซ้ำ ก็เลยตั้งใจเขียนอันนี้ไว้เป็น guideline ให้มือใหม่อยากเข้าวงการ ให้อ่านแล้วเห็นภาพใหญ่ ก่อนจะเจาะลึกแต่ละส่วนละกันนะ…