อย่าพยายามหลีกเลี่ยงการฟังสิ่งที่ผู้คนพูดด้วยวิธีแบบวิศวกรรม

 (ashley.rolfmore.com)
1 คะแนน โดย GN⁺ 9 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปัญหาหลักในงานซอฟต์แวร์ไม่ได้อยู่ที่การขาดการสนทนา แต่คือ การฟังที่ไม่เพียงพอ และการพยายามแก้ปัญหานี้ด้วยการเปลี่ยนมันให้เป็นคำอย่าง framework หรือ system เป็นการเลี่ยงการฟังที่จำเป็นจริง ๆ
  • การทำตามคำขอของใครบางคนตรง ๆ ไม่เหมือนกับการเข้าใจความต้องการที่แท้จริง และ ผลของความเชี่ยวชาญ กับ การแบ่งแยก technical/non-technical แบบสองขั้ว ทำให้มองข้ามความรู้และบริบทของอีกฝ่าย
  • หากมองว่าทุกคนมีพลังงาน ทักษะ และเงินทุนเท่ากัน หรือเหมารวมคุณลักษณะของคนหนึ่งคนไปทั้งกลุ่ม ก็จะจับข้อจำกัดและเกณฑ์การตัดสินใจที่ต่างกันของแต่ละคนไม่ได้อย่างถูกต้อง
  • คนและองค์กรเปลี่ยนแปลงตามเวลา บทบาท ความเครียด และพลวัตของกลุ่ม อีกทั้งสิ่งที่พูดกับสิ่งที่คิดจริงก็ไม่ได้ตรงกันเสมอไป ทำให้ requirements แบบตายตัว มักคลาดเคลื่อนจากการพัฒนาซอฟต์แวร์ได้ง่าย
  • การฟังที่ล้มเหลวทำให้พลาดอินไซต์ที่มีค่าที่สุด และนำไปสู่การสูญเสีย โอกาสทำรายได้ กับความได้เปรียบทางการแข่งขัน รวมถึงการเพิ่มขึ้นของ tech debt จากความเข้าใจผิดที่สะสม

ข้อโต้แย้งหลัก

  • ในงานซอฟต์แวร์ ประเด็นสำคัญที่ใหญ่กว่าการขาดการพูดคุยระหว่างคนคือ การฟังที่ไม่เพียงพอ และการพยายามแก้ด้วยการแปลงสิ่งนี้ให้เป็นคำอย่าง framework หรือ system คือวิธีเลี่ยงงานที่จำเป็นจริง
  • นักออกแบบและผู้รับผิดชอบด้าน product พยายามแปลงการพูดคุยกับคนให้เป็นถ้อยคำที่ฝ่าย engineering รับได้ง่ายกว่า แต่สิ่งที่จำเป็นไม่ใช่ระบบที่ดีกว่า หากคือการฟังสิ่งที่ผู้คนพูดให้ดีจริง ๆ
  • บนสมมติฐานที่ว่า การฟังสิ่งที่ผู้คนพูด ยากกว่าการแค่พูดคุยกับผู้คน จึงมีการสรุปกับดักสำคัญที่ขัดขวางการฟังจริง ๆ

กับดักสำคัญที่ขัดขวางการฟัง

  • การทำตามที่พูดไม่ใช่การฟัง

    • การทำตามสิ่งที่ใครบางคนบอกว่าอยากได้ กับ การฟังความต้องการที่แท้จริง ไม่ใช่เรื่องเดียวกัน
    • แนวทางที่ถูกพูดถึงก่อนหน้านี้ในประเด็นนี้ เช่น Jobs To Be Done, Outcome Driven Innovation และ empathy mapping ในสาย UX

  • ผลของความเชี่ยวชาญทำให้ประเมินมุมมองตนเองต่ำเกินไป

    • เมื่อเรียนรู้ในสาขาใดสาขาหนึ่งมานาน มักเกิดสมมติฐานว่า "เรื่องแค่นี้ก็น่าจะรู้อยู่แล้ว"
    • แม้อีกฝ่ายจะเป็นผู้เชี่ยวชาญในสาขานั้น ก็ไม่ได้หมายความว่าจะรู้ชุดความรู้เดียวกัน และอาจรู้ ความรู้อีกแบบหนึ่ง แทน
    • หากอยากฟังให้ดี ต้องเข้าใจให้มากขึ้นว่าอีกฝ่ายรู้อะไรอยู่บ้าง

  • มอง technical เป็นหมวดหมู่เดียว

    • นี่เป็นกับดักที่พบบ่อยโดยเฉพาะในหมู่นักพัฒนาซอฟต์แวร์ โดย technical ไม่ใช่คุณสมบัติแบบเดียว แต่เป็นสเปกตรัมกว้างขององค์ความรู้ที่หลากหลาย
    • หากมองผู้คนด้วยการแบ่งแบบ "technical / non-technical" ก็จะพลาดอินไซต์ และมีโอกาสสูงขึ้นที่จะฟังไม่ถูกต้อง

  • สมมติว่าทุกคนมีทรัพยากรเท่ากัน

    • ถ้าคิดว่าทุกคนมีพลังงาน ทักษะ และเงินสำรองเท่ากัน ก็จะนำไปสู่การตัดสินผิด
    • แม้จะมีสุขภาพใกล้เคียงกัน แต่รูปแบบการดูแลหรือสิ่งที่ทำได้จริงก็อาจต่างกัน
    • มีทั้งคนที่เก่งคณิตศาสตร์ คนที่เด่นด้านความสามารถอื่น และคนที่มีเงินหรือเวลาน้อยจึงต้องหลีกเลี่ยงความเสี่ยงมากกว่า เป็นต้น

  • เหมารวมคุณลักษณะของคนหนึ่งไปทั้งกลุ่ม

    • เพียงเพราะเจอคนคนหนึ่งที่มีลักษณะบางอย่าง ก็ไม่ได้แปลว่าคนที่เหลือจะเหมือนกันทั้งหมด
    • มีการยกตัวอย่างทัศนคติที่ด่วนสรุปว่าผู้สูงอายุย่อมไม่เข้าใจคอมพิวเตอร์
    • การลดทอนผู้หญิงทั้งหมดให้เหลือภาพจากความสัมพันธ์ในครอบครัวส่วนตัวก็เป็นความผิดพลาดแบบเดียวกัน

  • สมมติว่าคนและองค์กรไม่เปลี่ยนแปลง

    • ในระดับมหภาค บุคลิกย่อมเปลี่ยนไปตามเวลา
    • ในระดับจุลภาค persona ในที่ทำงานกับตัวตนที่บ้านอาจต่างกัน และการตัดสินใจก็เปลี่ยนไปได้ภายใต้ความเครียดหรือเงื่อนไขเฉพาะ

  • สมมติว่าสิ่งที่พูดเท่ากับสิ่งที่คิด

    • บางคนหมายความตามที่พูดจริง แต่บางคนก็ไม่ใช่
    • แม้เจ้าตัวจะคิดว่าตนพูดอย่างตรงไปตรงมา แต่ในความเป็นจริงก็มักไม่เป็นเช่นนั้น

  • ตัดสินผู้คน

    • หากไปเกลียดหรือ dismiss คนที่เข้าใจเอกสารที่เขียนไว้อย่างไม่ดีผิดไป ก็แทบจะไม่มีโอกาสฟังเขาได้อย่างถูกต้อง
    • ท่าทีที่ตั้งต้นว่าคู่สนทนาทำงานไม่เก่งหรือใช้ชีวิตผิด ก็เป็นอีกปัจจัยที่ขวางการฟัง

  • ปฏิบัติต่อคน 80 คนเหมือนเป็นกลุ่มเดียว แทนที่จะเป็นมนุษย์ 80 คน

    • B2B กลับมีด้านที่เป็นมนุษย์มากกว่า B2C เสียอีก โดยมีทั้งความสัมพันธ์ พลวัต และ soft power นอกผังองค์กรเข้ามาเกี่ยวข้อง
    • เมื่อมีพลวัตของกลุ่มเพิ่มเข้ามา ตัวแปรก็ยิ่งซับซ้อนกว่าระดับปัจเจก

ความไม่สอดคล้องระหว่าง requirements แบบตายตัวกับซอฟต์แวร์

  • เพราะคนและองค์กรเปลี่ยนแปลงอยู่เสมอ fixed project management จึงไม่เหมาะกับการสร้างซอฟต์แวร์
  • ต่อให้ล็อก requirements ไว้ตั้งแต่ต้น ระหว่างนั้นผู้คนก็เปลี่ยนไป และเมื่อผลงานเสร็จ สิ่งที่ได้มากที่สุดคืออาจตรงกับคำขอ ณ จุดเริ่มต้นเท่านั้น
  • เมื่อถึงเวลาเปิดตัว มันอาจไม่ใช่สิ่งที่ต้องการอีกต่อไปแล้ว และระหว่างที่รอ ผู้คนก็มักเติมความคาดหวังของตัวเองเข้าไป ทำให้ความจริงไม่ตรงกับความคาดหวังทั้งหมดนั้น

ผลลัพธ์และผลกระทบ

  • หากฟังสิ่งที่ผู้คนพูดไม่ดีพอ ก็จะพลาดอินไซต์ที่มีค่าที่สุด ซึ่งนำไปสู่การสูญเสีย โอกาสทำรายได้ และ ความได้เปรียบทางการแข่งขัน
  • ยิ่งความเข้าใจผิดสะสมมากเท่าไร ก็ยิ่งต้องเพิ่มองค์ประกอบใหม่ลงในโค้ดที่ภายหลังต้องร่วมกันดูแล และการฟังก็เชื่อมโยงกับการลดสาเหตุบางส่วนของ tech debt ด้วย
  • ยิ่งรู้ตัวได้เร็วว่าเมื่อไรที่เราฟังไม่ออก เราก็ยิ่งมีโอกาสฟังได้ดีขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 9 일 전
ความเห็นจาก Hacker News

  • ฉันเป็นคนที่ เลือกคำอย่างแม่นยำ พอสมควร ถ้าใช้สำนวนไหนก็หมายความตามนั้นจริง ๆ แต่คนจำนวนมากในสายตาฉันพูดเหมือน tone poem วนอยู่รอบ ๆ คำที่จับต้องได้และคาดหวังให้คนอื่นเข้าใจจากนัยรวม ๆ เลยทำให้การตีความนั้นเหนื่อยมาก เวลาเขียนฉันเลือกทุกคำโดยตั้งใจ แต่แม้แต่ที่ทำงานก็แทบจะเกิดซ้ำอยู่ตลอดที่คนตีความคำพูดฉันเหมือนมันไม่แม่นยำ ซึ่งทรมานมาก ฉันอาจมีลักษณะอยู่บนสเปกตรัมก็ได้ แต่ไม่เคยได้รับการวินิจฉัย เมื่อราวครึ่งปีก่อน ฉันทำ RPC เล็ก ๆ และเขียนเอกสารเพื่อให้อีกแผนกเริ่มงานชิ้นใหญ่ได้ เอกสารยาวไม่ถึงหนึ่งหน้า แต่ครบถ้วน ถูกต้อง และกระชับมาก แต่ผู้จัดการกลับเอาเอกสารนั้นไปผ่าน AI แล้วส่งต่อโดยไม่อธิบายเหตุผล และฉันก็ไม่รู้เรื่องนี้เลย ไม่ถึงวันก็มีฟีดแบ็กไร้สาระถาโถมเข้ามา พอได้เห็นตัวอย่างคำขอจริงก็พบว่ามีการ ดัดแปลง endpoint มันไม่ใช่แค่พิมพ์ผิด แต่เป็นที่อยู่ที่แต่งขึ้นมาล้วน ๆ ในเอกสารนั้นทั้ง endpoint และพารามิเตอร์บังคับผิดหมด แถมยังมีฟังก์ชันที่ไม่มีอยู่จริงถูกแต่งขึ้นมาอีก ปกติฉันเป็นคนใจเย็น แต่ไม่เคยโกรธเท่าวันนั้น และตอนนี้ก็ยังโกรธอยู่ ถ้าตลาดงานไม่เป็นแบบนี้ ฉันคงลาออกไปแล้ว การเอาภาษาที่คนควรอ่านและตีความด้วยตัวเองไปให้ AI จัดการ มันให้ความรู้สึกเหมือนเป็น ความตายของภาษาที่เคร่งครัดแม่นยำ และหลายเดือนมานี้ฉันก็คิดอย่างจริงจังว่า generative AI อาจเป็น Great Filter บางอย่างที่ทำลายอารยธรรมก็ได้

    • ฉันรู้สึกว่ามุมมองนี้ค่อนข้างแปลกสำหรับฉัน ฉันไม่คิดว่าคำพูดจะตัดขอบเขตของความคิดได้อย่างแม่นยำขนาดนั้น ภาษาเป็นเครื่องมือในการแสดงโลกและความเข้าใจของแต่ละคน ดังนั้นการอธิบายแนวคิดคล้ายกันด้วยคำคนละชุดจึงเป็นเรื่องธรรมชาติ สำหรับคนที่แปลงความคิดออกมาเป็นคำ มันอาจดูชัดกว่า แต่สำหรับคนฟังอาจไม่เป็นแบบนั้น เพราะฉะนั้นฉันไม่คิดว่าเราจะมองข้าม ภาระของการตีความ ได้ง่าย ๆ ถ้าคุยกับอีกฝ่ายในสถานการณ์นั้น ฉันเดาว่าพวกเขาเองก็คงพูดคล้ายกันว่าท้ายที่สุดแล้วคำพูดของคุณตีความได้ยาก
    • ฉากตั้งต้นนี้แรงมากจนฉันนึกถึงนิยายขึ้นมาทันที ไอเดียที่เอา Great Filter มาผูกกับ generative AI นั้นดีมาก รู้สึกเหมือนเป็นเรื่องที่ Cory Doctorow ควรรีบเขียนเดี๋ยวนี้เลย
    • ฉันคิดว่าอย่างแรกควรถามก่อนว่าทำไมผู้จัดการถึงเอาเอกสารนั้นใส่ AI บางครั้งยิ่ง ความแม่นยำ สูง ความอ่านง่ายก็ยิ่งลดลง และยิ่งภาษาถูกบีบอัดมากเท่าไร ผู้อ่านก็ยิ่งต้องใช้ต้นทุนทางการรับรู้กับแต่ละคำมากขึ้น การอ่านคือกระบวนการแปลโมเดลในหัวผู้เขียนให้กลายเป็นโมเดลของผู้อ่าน ไม่ใช่การแปลงอัตโนมัติจากคำเพียงอย่างเดียว แต่ต้องมีการตีความ ถ้ากระชับเกินไป เครื่องมือช่วยผู้อ่านอาจหายไปได้ จึงน่าสงสัยว่าที่เกิดทางอ้อมอย่างการสรุปด้วย AI อาจเป็นเพราะเอกสารหนึ่งหน้านั้นสั้นเกินไปสำหรับผู้อ่านทั่วไปจนช่วยให้เข้าใจไม่ได้ การ เขียนเพื่อผู้อ่าน เป็นงานคนละอย่างกับการจดบันทึกให้แม่นยำสำหรับผู้อ่านที่มีบริบทสูง โดยเฉพาะเวลาจะเขียนให้คนหมู่มาก คุณควรใส่การย้ำ ตัวอย่างง่าย ๆ บริบทที่คุ้นเคย การแยกขั้นตอนละเอียด ๆ และบางครั้งก็รวมถึงอารมณ์ขันกับคำอธิบายพื้นหลังเพื่อช่วยให้เข้าใจ
    • ฉันก็เพิ่งเจออะไรคล้ายกันมา ฉันเขียนสเปก 4 หน้า แต่คนที่ได้รับไม่ได้อ่าน กลับเอาไปให้ LLM สรุปเป็น bullet summary ไม่กี่ข้อ แล้วผลลัพธ์คือมีข้อเสนอที่ไม่ตรงกับความต้องการส่งกลับมา พอฉันคัดค้าน เขาก็บอกว่าเนื้อหานั้นควรอยู่ในสเปกตั้งแต่แรก แต่ความจริงมันอยู่ในสเปกแล้ว แค่ไม่มีอยู่ใน LLM summary ของเขาเท่านั้น ฉันไม่ใช่คนยึดติดกับทุกคำมากขนาดนั้น แต่ฉันรู้สึกว่าข้อมูลจากเอกสาร 4 หน้าไม่มีทางถูกบรรจุอย่างครบถ้วนใน bullet 10 ข้อได้
    • ฉันกลับรู้สึกว่านี่เป็นกรณีที่เหมาะมากสำหรับพรอมป์ต์เฉพาะทางหรือ custom LLM ที่เอาไว้แปลงข้อความนี้ให้เป็น normie speak

  • แค่ดูช่องคอมเมนต์นี้ ฉันก็รู้สึกประชดดีที่มีคนจำนวนมากกำลังทำซ้ำปัญหาที่บทความชี้ไว้ตรง ๆ ฉันอยากเสริมอีกสักหน่อย อย่างแรก ต่อให้มีความรู้และการถกเถียงมากแค่ไหน ถ้าอีกฝ่ายไม่อยากรับ ก็จะไม่รับง่าย ๆ อย่างที่สอง การ ฟังอย่างแท้จริง คือการทำให้ตัวเองอยู่ในสภาพเปราะบางทั้งทางจิตใจและร่างกาย เพราะคุณอาจได้ยินสิ่งที่ขัดกับประสบการณ์ ความเชื่อ และโลกทัศน์ของตัวเอง และท่าทีแบบตัดสินคนก็มักเป็นกลไกป้องกันตัวเอง จึงยิ่งทำให้ฟังไม่เป็น อย่างที่สาม การรับฟังมักหมายถึงการไม่รีบกระโดดไปหาวิธีแก้ทันที แต่เป็นการ ดูดซับความเจ็บปวด ของอีกฝ่ายและประมวลผลมัน เช่น Product manager อาจรีบลดทอนทุกอย่างให้เป็นฟีเจอร์ใหม่หรือตั๋วงาน แต่จริง ๆ แล้วควรฟัง use case ค้นหาจุดที่เจ็บปวด แล้วค่อยแก้ ไม่ใช่พยายามเข้าใจแค่ชื่อฟีเจอร์ที่ผู้ใช้เรียกร้อง

    • ฉันรู้สึกว่าการ ตั้งเป็นสมมติฐานล่วงหน้า แบบนี้อันตราย งานส่วนใหญ่มักมีพื้นที่ให้ต่อรอง และถ้ารู้วิธีเจรจาอย่างถูกต้อง อะไร ๆ ก็เปลี่ยนได้
    • ฉันรู้สึกว่าข้อ 2 ลึกมากเป็นพิเศษ อยากส่งคำนี้ให้คนสำคัญสักคนจริง ๆ และหวังว่าเขาจะ listen ให้จริง ๆ ด้วย
    • ฉันเห็นด้วยว่าการฟังคือการทำให้ตัวเองเปราะบาง แต่ก็คิดว่าถ้ามีหลักประกันว่าความเปราะบางนั้นจะไม่ถูก นำไปใช้ในทางที่ผิด ทุกครั้ง ฉันก็ยินดีสละเวลาเพื่อฟังอย่างจริงจังเสมอ
    • ฉันอยากรู้จริง ๆ ว่าการ ดูดซับ ความเจ็บปวดของคนอื่น ในทางปฏิบัติมันหมายถึงอะไร และจากจุดนั้นจะไหลไปสู่การนิยามฟีเจอร์หรือการเขียน ticket อย่างเป็นธรรมชาติได้อย่างไร
    • ฉันรู้สึกว่าคำอธิบายนี้แหละคือแก่นของ presales discovery มันแทบจะเป็นงานที่ใกล้ศิลปะมากกว่าเทคนิค

  • ฉันเห็นด้วยกับความกังวลหลัก แต่รายการนี้อ่านแล้วค่อนข้างเหมือน การระบายความคับข้องใจ การสื่อสารอย่างมีประสิทธิภาพแทบเป็นปัญหาแกนกลางของมนุษยชาติอยู่แล้ว และข้อความนี้ให้น้ำเสียงเหมือนกำลังตำหนินักพัฒนาว่าฟังไม่เป็น เลยรู้สึก วางตัวสูง ไปนิด ปัญหารากจริง ๆ คือคนไม่รู้ว่าตัวเองไม่รู้อะไร นักสื่อสารที่ดีที่สุดจะคล้ายนักแปล และผู้คนจะเริ่มฟังจริง ๆ ก็ต่อเมื่อข้อความนั้นชัดเจนเองภายในกรอบความเข้าใจของเขา ฉันไม่คิดว่ามันเป็นแค่ความพังพินาศง่าย ๆ แบบทุกคนทำตัวเป็นเด็กเล็กที่ปิดหูไม่ฟัง เพราะเหตุนี้เราจึงหันไปหาระบบและวิศวกรรม เพื่อให้ระบบมีการตรวจจับช่องว่างและกรอบการแปลในตัว ถึงจะไม่สมบูรณ์ แต่ฉันคิดว่าการเปลี่ยนสภาพแวดล้อมในระดับทีม บริษัท และระบบ สำคัญกว่าการเทศนาให้แต่ละคนฟังให้ดีกว่าเดิม

    • มันทำให้ฉันนึกถึงตอนที่ผู้เฒ่าคนหนึ่งเคยบอกให้มองสิ่งนี้เป็น Noisy system สัญญาณย่อมอ่อนกว่าเสียงรบกวนเสมอ และภายในนั้นก็มีมนุษย์ที่มีข้อจำกัด แต่ละคนมีเพดานของสิ่งที่ทำได้ มีขีดจำกัดของความเร็วในการอัปเดตแบบจำลองความคิด และข้อจำกัดของกลุ่มยิ่งต่ำกว่าของปัจเจก โดยเฉพาะองค์กรใหญ่ ต่อให้ความจริงเปลี่ยนไปหมดแล้ว ก็ยังอาจใช้เวลาหลายสิบปีกว่าจะเปลี่ยนแบบจำลองเดิมได้ เพราะงั้นสิ่งสำคัญคือยอมรับข้อจำกัดเหล่านี้ แล้วตัดสินใจว่าจะใช้เวลาและพลังงานของตัวเองกับอะไร
    • สำหรับฉัน ข้อความนี้ดูเหมือนบทความ self-help ธรรมดา ๆ และยังน่าผิดหวังยิ่งขึ้นไปอีกเพราะตัวอย่างก็น้อยด้วย
    • ฉันเป็นนักพัฒนาและก็เคยทำงานอย่างอื่นมาพอสมควร เลยรู้ดีว่าการสื่อสารสำคัญแค่ไหน และนักพัฒนามักอ่อนตรงนี้บ่อยเพียงใด รูปแบบที่เห็นบ่อยคือพวกเขาเหมือน หมอที่ไม่ดี คือทำท่าเหมือนฟัง แต่รีบวินิจฉัยเร็วเกินไป ก่อนที่อีกฝ่ายจะพูดสิ่งสำคัญออกมาครบ ก็ประกาศแล้วว่ารู้ว่าต้องการอะไร ในซอฟต์แวร์ สิ่งที่สำคัญกว่าสิ่งที่ลูกค้าบอกว่าอยากได้ มักคือสิ่งที่ลูกค้า จำเป็นต้องมี จริง ๆ มีลูกค้าไม่มากนักที่เข้าใจวิธีแก้ปัญหาด้วยซอฟต์แวร์อย่างสวยงามจริง ๆ ส่วนใหญ่คือคนที่ไม่ได้คิดเรื่องซอฟต์แวร์ลึกมากแล้วเอาไอเดียมาให้ นั่นไม่ได้แปลว่าไอเดียนั้นไร้ค่า แต่แปลว่าการเก็บ requirement และการหาทางออกยังไม่เสร็จ วิธีทำให้มันเสร็จคือการสังเกต การอธิบาย และการสนทนา จากประสบการณ์ของฉัน นักพัฒนาหลายคนฟังไม่เก่งจริง ๆ และหมอหรือสายอาชีพเทคนิคอื่นก็คล้ายกัน พวกเขาอยากรีบดูเก่งด้วยการโชว์ว่าตัวเองรู้มากแค่ไหน และจัดอีกฝ่ายให้เข้าไปอยู่ในประเภทปัญหาที่เคยเห็นมามากแล้ว บางครั้งมันใช้ได้ แต่ก็ต้องมีวันที่มันใช้ไม่ได้แน่ ๆ
    • ถ้าจะพูดเล่น ๆ นะ ถ้าการสื่อสารเป็นปัญหาแกนกลางของมนุษยชาติจริง Bible ก็น่าจะมีสักข้อที่พูดถึงเรื่องนี้บ้างไม่ใช่หรือ

  • ฉันคิดว่าเราไม่ควรตั้งสมมติฐานง่าย ๆ ว่าสิ่งที่คนพูดตรงกับสิ่งที่เขาคิดจริงเสมอไป ในทางกลับกัน คนพูดเองก็มักเข้าใจผิดว่าคนฟังกำลังนึกถึงสิ่งเดียวกันและเข้าใจตรงกัน ดังนั้นการเขียนให้ ละเอียดและไม่กำกวม เท่าที่ทำได้จึงสำคัญ ถ้าในประชุมมีใครพยายามอธิบายเป้าหมายด้วย bullet เพียง 6 คำ ฉันรู้สึกว่านั่นแทบเป็นสัญญาณว่า ไม่มีใครเข้าใจเป้าหมายเลย ถ้ามาประชุมโดยไม่มีเอกสารแม้แต่หน้าเดียว แปลว่าคนนั้นยังเข้าใจเรื่องนั้นไม่พอ และถ้าความคืบหน้าของฉันขึ้นอยู่กับผลลัพธ์นั้น ฉันก็ควรเรียกร้องภาพที่ชัดเจนกว่านี้

    • ฉันมีสถานการณ์ที่ต้องถามเพื่อนร่วมงานวันละหลายครั้งว่า about what? บ่อยมาก ต้องถามย้ำ 4-5 รอบกว่าจะพูดให้ชัดว่าเป็นลูกค้ารายไหน ฟีเจอร์อะไร หรือโปรดักต์ไหน บางครั้งถึงฉันจะรู้แน่อยู่แล้วว่าเขาหมายถึงอะไร ฉันก็ยังต้องทำแบบนั้น
    • ฉันรู้สึกว่าต้องตรวจสอบความสมเหตุสมผลของ requirement ด้วย เพราะวิธีที่ง่ายที่สุดในการซ่อนสภาพที่ไม่รู้ว่าตัวเองต้องการอะไรจริง ๆ ก็คือการยื่น ความต้องการเกินจริง ตามประสบการณ์ของฉัน การขอเกินกว่าที่ต้องใช้จริง 10 เท่าเป็นเรื่องธรรมดา และฉันเคยเจอถึงขั้นมีคนบอกว่าถ้าไม่อยากกังวลเรื่องอนาคต ก็ควรซื้อสเปกสูงสุด ทั้งที่ตัวเลือกนั้น แพงกว่ากัน 500 เท่า
    • ฉันคิดว่าการเขียนให้ละเอียดและไม่กำกวมอาจเป็นเงื่อนไขตั้งต้นของความเข้าใจร่วมที่ลึกซึ้ง แต่ในช่วงไม่กี่ปีมานี้ คนอ่านแชต ticket หรืออีเมลเกินกว่าประโยคแรกกันน้อยมากจริง ๆ เลยต้องคอยป้อนข้อมูลเป็น ชิ้นเล็กมาก ๆ แตกย่อยลงไป ซึ่งฉันเกลียดมาก
    • ฉันรู้สึกว่าเรื่องแบบนี้เกิดขึ้นบ่อยเกินไปในชีวิตจริง พอฉันพูดว่า ยังไม่พร้อมสำหรับ production ฝ่ายบริหารก็มักได้ยินว่ามันหมายถึงขายให้ลูกค้าเป็น acceptance testing ได้
    • อยู่ ๆ ฉันก็นึกถึงหนังยุคโซเวียตเรื่อง Kin-dza-dza ขึ้นมา ในเรื่องนั้นมีตัวละครคนหนึ่งพูดถึงอีกคนว่า เขาพูดในสิ่งที่ตัวเองไม่ได้คิด และคิดในสิ่งที่ตัวเองไม่ได้คิด ซึ่งฉันรู้สึกว่ามันเข้ากับความสับสนปะปนของบทสนทนานี้ได้ดีทีเดียว

  • ฉันทำหน้าที่ฝั่งดูแลความสัมพันธ์ลูกค้าเป็นหลัก ดังนั้นฉันมองว่างานที่สำคัญที่สุดคือทำให้ ความคาดหวังของลูกค้าอยู่แนวเดียวกัน กับความเป็นจริง ถ้าทำให้ความเป็นไปได้ ระยะเวลา ต้นทุน และช่วงเวลาที่ขึ้น production ได้ ไปตรงกับความคาดหวังของลูกค้าได้ ต่อให้เขาไม่ชอบวันเริ่มต้นหรือราคา สุดท้ายก็จะเป็น ลูกค้าที่มีความสุข โดยเฉพาะเรื่องต้นทุนซึ่งมักเป็นปัจจัยที่ทำให้ดีลล่ม ฉันจึงชอบตั้งกรอบคร่าว ๆ ไว้ตั้งแต่ต้น ต่อให้ฟังเก่งและเห็นอกเห็นใจแค่ไหน ความจริงก็คือความจริง และลูกค้าก็ต้องยอมรับข้อจำกัดนั้นด้วย คนดูแลลูกค้าที่คอยเออออตามทุกอย่างที่ลูกค้าต้องการ สุดท้ายจะทำให้ลูกค้าไม่มีความสุขยิ่งกว่าเดิม และคนที่เป็นตัวกลางที่ดีควรฟังทั้งฝั่งลูกค้าและทีมภายใน เพื่อทำให้สิ่งที่ส่งมอบได้จริงสอดคล้องกับความคาดหวังของลูกค้า

  • ฉันรู้สึกว่าเป็นไปได้ว่าเราอาจใช้เวลาไปกับ การสื่อสารมากเกินไป แล้วก็ได้ ถ้าเผื่อเวลามากเกินไป สมาธิจะพร่า และก็ผัดไปได้ง่ายว่าเดี๋ยวค่อยทำให้ชัดในรอบหน้า ถ้าลดประชุมที่ไม่จำเป็นและจัดเวลาแค่ minimum viable time คนอาจฟังกันดีขึ้นด้วยซ้ำ

    • ฉันแทบไม่เคยเห็นปรากฏการณ์นี้ในชีวิตจริง ส่วนใหญ่การประชุมไม่ได้เป็นการสื่อสาร แต่เป็น การสั่งการ และการแจ้งให้ทราบมากกว่า และความสามารถในการฟังเป็นทักษะอีกแบบหนึ่งที่ไม่เกี่ยวกับความยาวของประชุม การฟังคือทักษะที่ต้องฝึก ไม่ใช่อะไรที่จะเกิดขึ้นเองอัตโนมัติเพียงเพราะลดเวลาประชุม
    • ฉันเคยเข้าประชุมมากเกินไปที่ผลลัพธ์คือการนัดประชุมครั้งถัดไป บางทียังลากคนเพิ่มเข้ามาอีก และฉันก็เคยเห็นรูปแบบที่ทีมใหญ่ใช้จำนวนคนดึงการตัดสินใจให้เข้าข้างตัวเองเพื่อกอบโกยอิทธิพลทางการเมือง ซึ่งก็วนกลับไปสู่การจ้างคนเกินความจำเป็นและการประชุมเกินความจำเป็นอีก ทางออกไม่ใช่การเพิ่มการสื่อสาร แต่คือการตั้ง วิสัยทัศน์เดียว และลดการพึ่งพาข้ามทีม เพื่อให้แต่ละทีมทำงานได้อย่างอิสระ
    • ฉันทำงานด้านสถาปัตยกรรมซอฟต์แวร์ และเห็นบ่อยมากว่าไดอะแกรมหนึ่งภาพช่วยประหยัด การถกเถียงเกิน 60 นาที กับการประชุมหลายรอบได้ ต่อให้วาดไม่เก่งนัก แค่ยึดตามข้อเท็จจริงก็พอแล้ว และตรรกะที่ซับซ้อนหรือไม่ชัดโดยสัญชาตญาณนั้น diagram ชัดกว่าคำพูดมาก ถ้าเป็นประชุมระยะไกลก็วาดเร็ว ๆ ด้วย Ai agent กับ Mermaid.js ได้ ถ้าเจอหน้ากัน ไวต์บอร์ดหรือกระดาษกับปากกาก็พอ
    • ฉันรู้สึกว่าการใช้เวลากับการสื่อสาร กับการ สื่อสารจริง ๆ เป็นคนละเรื่องกันโดยสิ้นเชิง
    • ฉันคิดว่าในความเป็นจริง เราไม่ได้ใช้เวลากับการสื่อสารมากเกินไป แต่ใช้เวลากับการ แกล้งทำเป็นสื่อสาร มากเกินไปต่างหาก ฉันเห็นบ่อยมากว่ามีการฝืนเปิดประชุมทั้งที่คนไม่ครบองค์ประชุม ดำเนินไปโดยไม่มีเงื่อนไขตั้งต้น และโยน AI slop document ที่ทำมาแบบไม่คิดให้คนอ่าน พอคนอื่นไม่เข้าใจก็กลับทำเหมือนว่าคนอ่านโง่เอง 30 นาทีแรกของประชุมผ่านไปเหมือนโดน gaslighting แล้ว 10 นาทีสุดท้ายค่อยยอมรับว่าเสียเวลาเปล่าและพยายามเก็บกวาด จริง ๆ แล้วการประชุมควรเป็นที่แบ่งปันความคิดที่ผ่านการตกผลึกมาแล้วและทิศทางที่สอดคล้องกัน พร้อมรับฟีดแบ็กที่มีความหมายต่อข้อเสนอที่ชัดเจน แต่ในชีวิตจริงมันมักกลายเป็นการที่ทุกคนต้องมาช่วยจัดการความพยายามของใครสักคนที่อยากเปลี่ยนงานของตัวเองให้เป็นโปรเจกต์กลุ่มแบบ stone soup ถ้าถามตั้งแต่ต้นว่าประชุมนี้มีเป้าหมายอะไร ก็จะเห็นทันทีว่าผู้จัดประชุมแค่เปิด study group ง่าย ๆ ไว้หรือเปล่า ผู้จัดการที่มีแต่มุมมองระดับสูงมักเข้าใจผิดว่างานเกิดขึ้นในห้องประชุม แต่กลับมองไม่เห็นงานคิดที่จำเป็นต้องเกิดก่อนจะมีประชุมดี ๆ ถ้ารีบสื่อสารก่อนที่ความคิดจะเป็นรูปเป็นร่าง การประชุมก็จะกลายเป็นแค่เสียงรบกวน ในสถานการณ์แบบนี้ การตอบสนองที่ทรงพลังที่สุดคือท่าทีแบบ มาลองหาคำตอบไปด้วยกันตอนนี้ และฉันจะบังคับให้ทุกคนรักษาลำดับความพึ่งพา Why, What, How, Who, When ถ้าต้นทางยังว่าง ก็ไปต่อปลายทางไม่ได้ ไม่ว่าจะเป็นอินเทิร์นหรือ VP ก็ไม่มีสิทธิ์มึน ๆ เบลอ ๆ ผ่านไป ถ้าแยกปัญหาและคิดกันสด ๆ ตรงนั้นแล้วทีมยังไม่เปลี่ยน สุดท้ายก็คงต้องไปหาทีมอื่นแทน

  • ฉันรู้สึกว่าข้อสังเกตเรื่อง specialism effect ในบทความนี้ถูกประเมินต่ำเกินไปพอสมควร ฉันเองก็เคยหงุดหงิดว่าทำไมผู้ใช้ไม่เข้าใจสิ่งที่ฉันใช้เวลาหลายปีซึมซับมา แต่ไม่นานก็รู้ว่าปัญหาไม่ใช่เพราะพวกเขาไม่มีความรู้ แต่เป็นเพราะความรู้ของพวกเขา สะสมอยู่คนละที่ ต่างหาก พวกเขาเองก็แค่ใช้เวลาเท่ากันไปกับการฝึกอย่างลึกซึ้งในอีกเรื่องหนึ่ง

  • ฉันไม่เห็นด้วยเต็มที่กับคำอธิบายที่ว่าต้นเหตุหลักคือคนไม่พูดและไม่ฟัง ถ้าจะยืมอุปมาแบบการ์ตูน คนจำนวนมากตั้งแต่แรกก็ไม่ได้อยากได้ถนนเท่ากับอยากได้ พิธีตัดริบบิ้น และสุดท้ายก็ได้สิ่งนั้น จึงเกิดเรื่องแบบนี้ขึ้น

  • ฉันเคยเจอแบบขำ ๆ เยอะเหมือนกันที่คนพูดว่าตัวเอง หมายความตามที่พูดตรง ๆ แต่ความจริงไม่ใช่ ฉันลองถอดความคำพูดของอีกฝ่ายกลับไปแทบจะตรงตามต้นฉบับเพื่อเช็กความเข้าใจ แล้วสิ่งที่ได้กลับมาคือการปฏิเสธอย่างหนักแน่นว่านั่นไม่ใช่สิ่งที่เขาจะพูดอย่างเด็ดขาด

  • ฉันรู้สึกว่าปัญหาหลายอย่างเวลาคุยกับฝ่ายที่ไม่ใช่สายเทคนิค อยู่ที่พวกเขาชอบบอกว่าให้เพิ่ม X เปลี่ยน Y โดยไม่มี บริบทเรื่องต้นทุน แนบมาด้วย แน่นอน เราทำสิ่งที่สั่งเกือบทั้งหมดได้ แต่ทุกคำขอมีต้นทุน และถ้าไม่เข้าใจเรื่องนั้น ก็ยากจะไปด้วยกันกับการส่งมอบโปรดักต์ที่เชื่อถือได้

    • ฉันรู้สึกว่าคำตอบนี้ต่างหากที่แสดงแก่นของบทความได้ตรงที่สุด ไม่ใช่ว่าพวกเขาไม่เข้าใจต้นทุน แต่แค่ บริบทต่างกัน และบทบาทของคนสายเทคนิคไม่ใช่คาดหวังให้คนอื่นรู้อยู่ก่อนว่าต้นทุนคืออะไร แต่คือช่วยให้พวกเขาตัดสินใจเรื่อง tradeoff อย่างมีข้อมูล
    • ฉันรู้สึกว่าคำถามแบบ whys สำคัญมากในสถานการณ์แบบนี้ ถ้าเข้าใจกระบวนการที่ไม่ใช่สายเทคนิคจริง ๆ แล้ว อาจพบว่าไม่จำเป็นต้องเพิ่มหรือเปลี่ยนอะไรเลยก็ได้ และฉันก็เห็นด้วยว่าถ้าใส่ทุกอย่างลงไป สุดท้ายก็จะได้สัตว์ประหลาดแบบ Turing complete Excel/Email clone
    • ฉันคิดว่าในสถานการณ์แบบนี้จะเกิดความไม่สมมาตร คือคนที่ไม่ใช่สายเทคนิคไม่รู้เรื่องต้นทุน ส่วนคนสายเทคนิคก็ ไม่รู้เรื่องผลประโยชน์ สุดท้ายจึงต้องมีการสื่อสารจากทั้งสองฝั่งเพื่อหาจุดที่คุ้มค่าระหว่างต้นทุนกับผลลัพธ์
    • ฉันรู้สึกว่านี่เป็นปัญหาที่ แก้ได้ค่อนข้างตรงไปตรงมา แค่ตอบแต่ละคำขอด้วยการประเมินว่าจะใช้เวลากี่เดือนและต้องใช้เงินเท่าไร เป็นหน่วยเดือนและดอลลาร์
    • แต่ฉันก็รู้สึกว่าทุกวันนี้ AI มาช่วยทำ code thing แทนได้มากขึ้น จนต้นทุนการลงมือทำจริงลดลงพอสมควรแล้ว จะชอบหรือไม่ชอบ เราก็ควรยอมรับความเปลี่ยนแปลงนั้น