The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์
ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap
แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุมกลับจบลงด้วยความตึงเครียด ความบาดหมาง หรือสภาวะ Silent Resentment (ความไม่พอใจที่เงียบงัน) ที่กัดกินประสิทธิภาพของทีมมากกว่าเดิม
วันนี้เราจะมาถอดรหัสผ่านแนวคิดจิตวิทยาเรื่อง Status (สถานะ) และ Relationship (ความสัมพันธ์) ว่าทำไมยิ่งคุณ “ถูก” มากเท่าไหร่ ทีมอาจยิ่งพังมากเท่านั้น
1. กับดักของสถานะ: เมื่อความถูกต้องคือการกดหัว
หนังสือจิตวิทยาเล่มหนึ่งเคยกล่าวไว้ว่า “ในวินาทีที่เรายกเหตุผลที่ถูกต้องที่สุดมาอ้าง ตัวเราจะอยู่ในสถานะที่สูงกว่าอีกฝ่ายเสมอ”
ลองจินตนาการถึงเหตุการณ์ใน Pull Request หรือการประชุม Management:
- ในมุม Developer: เมื่อเราคอมเมนต์ว่า “Pattern นี้ผิดหลัก Clean Code” แม้จะพูดด้วยน้ำเสียงราบเรียบ แต่ในเชิงจิตวิทยา เรากำลังขยับสถานะตัวเองเป็น “ผู้รู้” และกดให้อีกฝ่ายเป็น “คนทำผิด”
- ในมุม Management: เมื่อ CTO ยืนยันว่า “ต้อง Re-write ใหม่หมดไม่งั้นระบบล่ม”ฝั่ง Business จะรู้สึกเหมือนถูก “ต้อนเข้ามุม” เพราะถ้าเขาปฏิเสธ เขาจะกลายเป็น “คนผิด” ทันที
เมื่อมนุษย์รู้สึกว่าสถานะ (Status) ของตนถูกคุกคาม สัญชาตญาณการเอาตัวรอดจะสั่งให้เขา “สร้างกำแพง” มากกว่าการยอมรับข้อเท็จจริง ต่อให้เหตุผลของคุณจะช่วยประหยัดเงินได้เป็นล้าน แต่ถ้าคนฟังปิดใจไปแล้ว คำพูดของคุณก็เป็นเพียงแค่เสียงนกเสียงกา
2. พลังสื่อสารที่ลดลงตามความสัมพันธ์ที่เสื่อมถอย
กฎเหล็กที่คนทำงานสาย Tech มักลืมคือ “เมื่อความสัมพันธ์เสียไป พลังในการสื่อสารจะลดลงทันที”
ในวงการบริหาร เรามักเถียงกันเรื่อง Methodology เช่น Agile vs Waterfall หรือ Timeline vs Technical Debt แต่ละฝ่ายต่างงัด “ความถูกต้อง” ของตัวเองมาฟาดฟันกัน โดยลืมไปว่า คนที่ขับเคลื่อน Logic คือมนุษย์
หากเรายัดเยียดความถูกต้อง (Correctness) โดยไม่สนจังหวะและหัวใจของคนฟัง เราอาจชนะในประเด็นนั้น (Win the argument) แต่เราจะแพ้ในเกมระยะยาว (Lose the team) เพราะทีมจะเริ่มไม่ร่วมมือ แผนงานที่สวยหรูบนแผ่นกระดาษจะไม่มีใครอยากทำให้มันเกิดขึ้นจริง
3. เปลี่ยนจาก “การพิสูจน์ความถูก” เป็น “การสร้างความร่วมมือ”
ถ้า Code มันผิด หรือแผนงานมันพังจริงๆ เรายังต้องพูดครับ แต่ต้อง “เปลี่ยน Relationship ของบทสนทนา” ด้วย 3 เทคนิคนี้:
• เปลี่ยนคำสั่ง เป็นคำถาม (Ask, Don’t Tell)
แทนที่จะบอกว่า “ทำแบบนี้มันผิด” ให้ลองใช้คำถามว่า “ถ้าเราปรับมาเป็นวิธีนี้ คุณคิดว่าจะมีผลกระทบอะไรที่เราต้องระวังไหม?” วิธีนี้ช่วยให้อีกฝ่ายได้ใช้เหตุผลของเขาเองและรู้สึกว่าเขายังมีอำนาจในการตัดสินใจ
• เปลี่ยน Correctness เป็น Trade-off
ในระดับบริหาร อย่าพูดว่าวิธีไหน “ถูกที่สุด” แต่ให้กางทางเลือกเป็น Trade-off เช่น “ถ้าเราเลือก Launch เร็ว (A) เราอาจจะมี Technical Debt เพิ่มขึ้น (B) ทีมคิดว่าเราแบกรับความเสี่ยงนี้ได้แค่ไหน?” การพูดแบบนี้ทำให้ทุกคนอยู่ในสถานะ “หุ้นส่วน” (Equal Status) ที่ต้องตัดสินใจร่วมกัน
• แชร์ความเปราะบาง (Vulnerability)
การที่หัวหน้าหรือ Senior พูดว่า “ผมเคยพลาดเรื่องนี้มาก่อน…” หรือ “ผมอาจจะไม่เข้าใจ Technical ตรงนี้ ช่วยอธิบายหน่อยได้ไหม?” เป็นการลดสถานะตัวเองลงมา เพื่อเปิดพื้นที่ให้อีกฝ่ายกล้าแชร์ความจริงโดยไม่รู้สึกว่ากำลังถูกจับผิด
เหตุผล สร้าง Software แต่ความสัมพันธ์ สร้าง “ทีม”
ความถูกต้องของ Logic เป็นสิ่งจำเป็นในการสร้างซอฟต์แวร์ที่ยอดเยี่ยม แต่การให้เกียรติและความเข้าใจเป็นสิ่งจำเป็นในการสร้าง “ทีม” ที่ยั่งยืน
ก่อนจะกด Send คอมเมนต์ใน PR ครั้งหน้า หรือก่อนจะค้านใครในที่ประชุม ลองถามตัวเองสักนิดว่า:
“เรากำลังใช้ความถูกต้องเพื่อช่วยทีม หรือใช้มันเพื่อให้ตัวเองดูเหนือกว่า?”
เพราะสุดท้ายแล้วความเก่งอาจช่วยให้คุณสร้าง ‘Software’ ที่ดี แต่ความเข้าใจคนจะช่วยให้คุณสร้าง ‘ทีม’ ที่ประสบความสำเร็จครับ
หากบทความนี้มีประโยชน์
คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง
ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer
แบบไม่ต้องใส่สูท
แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ
