ขอคำปฏิเสธ อย่าขอคำตอบรับ (2022)

 (mooreds.com)
1 คะแนน โดย GN⁺ 2025-02-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

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

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

 
GN⁺ 2025-02-23
ความคิดเห็นจาก Hacker News
  • เป็นทักษะสำคัญในองค์กรขนาดใหญ่ มีประโยชน์เมื่อทุกคนยุ่งและเรื่องงานถูกลืมได้ง่าย อธิบายปัญหาทางอีเมลแล้วบอกว่า "ถ้าไม่มีคำตอบภายใน [N] วัน ฉันจะทำ XYZ ใน [DAY N]" วิธีนี้คือการแจ้งให้ทราบแทนที่จะรอการอนุมัติ
    • บางครั้งผ่านไปหลายสัปดาห์จะมีคนโกรธที่มีคนทำ XYZ ไปแล้ว แต่ก็มีบันทึกที่แสดงได้ว่าพวกเขาเป็นฝ่ายพลาดเอง
    • เรียกสิ่งนี้ว่า "อย่าถาม ให้บอก" และใช้ได้หลายแบบทั้งในและนอกที่ทำงาน มันช่วยให้ได้ผลลัพธ์ที่ชัดเจนและเด็ดขาด
    • ผมคุยแบบนี้กับภรรยาบ่อยเหมือนกัน ภรรยาชอบถาม ในงานนัดกินข้าวเย็น ภรรยาถามว่า "จะไปถึงกี่โมง" แต่ผมบอกไปเลยว่าเราจะไปถึงเมื่อไร และจะรออยู่ที่บาร์ สุดท้ายทุกคนไปถึงกันเร็ว และทุกอย่างก็สมบูรณ์แบบด้วยการสื่อสารน้อยที่สุด
    • มันเกี่ยวข้องกับแนวคิด "ขออภัยทีหลัง ดีกว่าขออนุญาตก่อน" ซึ่งอาจเสี่ยงได้ แต่โดยพื้นฐานแล้วผมเป็นคนหัวขบถ อย่างไรก็ตาม ในสภาพแวดล้อมการทำงานร่วมกันอย่าง GitHub การพยายามเปลี่ยนแปลงใหญ่แบบส่งเดชไม่ใช่ความคิดที่ดี
  • เวลาผมให้คำแนะนำเพื่อนร่วมงานเรื่องวิธีขอการอนุมัติสำหรับคำแนะนำ ผมก็พูดคล้ายกัน
    • "ทำให้การอนุมัติเกิดขึ้นได้ง่าย"
    • อธิบายปัญหาอย่างสั้น ๆ และอธิบายว่าทำไมวิธีแก้ถึงถูกต้อง ถ้าอยากรู้ลึกกว่านั้นก็แนบลิงก์เอกสารไว้ให้ ตรวจสอบด้วยว่าได้การเห็นชอบจากสมาชิกทีมหรือเจ้าของผลิตภัณฑ์แล้วหรือยัง
    • "เราจะทำ Y เพื่อแก้ปัญหา X ทีมเห็นด้วยกันหมดแล้ว รายละเอียดอยู่ที่ [ลิงก์] ถ้าไม่มีฟีดแบ็กเพิ่มเติม เราจะเริ่มในวันอังคาร"
    • ผู้จัดการไม่มีเวลาลงกับรายละเอียดทุกอย่าง ดังนั้นถ้าได้รับการสนับสนุนจากทีมแล้ว ก็จะทำให้อนุมัติได้ง่ายขึ้น
  • ยังมีแนวทาง "กระจายเจตนา" ด้วย คือบอกสิ่งที่ตั้งใจจะทำและแผนงาน พร้อมเปิดโอกาสให้ผู้มีส่วนได้ส่วนเสียคัดค้านอย่างชัดเจน ใช้ได้ในบางสถานการณ์ และต้องอาศัยความไว้วางใจพื้นฐาน
  • ถ้าครั้งแรกที่ทำแล้วทำพัง มันอาจกลายเป็นหายนะได้ การได้คำตอบว่าใช่หรือไม่ใช่อย่างน้อยก็หมายความว่าหัวหน้ารับรู้อยู่
    • เมื่อถูกถามว่า "ใครเป็นคนอนุมัติ" ก็สามารถตอบได้ว่าไม่มีใครอนุมัติ
  • วิธีนี้อาจใช้ได้เฉพาะในบริษัทอเมริกันหรือกับหัวหน้าที่คุ้นเคยกับธุรกิจแบบอเมริกันเท่านั้น ถ้าหัวหน้าไม่ชอบก็อาจให้ผลตรงข้ามได้ ในการประเมินผลงาน หัวหน้าอาจตีตราว่าเป็นการไม่เชื่อฟัง บางครั้งการขออนุญาตอาจเป็นทางเลือกที่ดีที่สุด
  • ส่วนหนึ่งของกลเม็ดแบบ "ฉันจะทำสิ่งนี้" คือไม่เขียนให้ดูเหมือนคำถาม แบบนี้ผู้รับไม่จำเป็นต้องเขียนตอบ และไม่ต้องอ่านอีเมลเพิ่ม
    • ชอบฟังก์ชันรีแอ็กชันอีโมจิของ GitHub และ Google Docs เพราะเป็นวิธีง่าย ๆ ในการบอกว่าเห็นด้วย แม้ใน HN จะไม่ค่อยนิยม แต่รีแอ็กชันอีโมจิก็เป็นวิธีสื่อสารที่เรียบง่าย
  • ผมเข้าใจจุดยืนของ OP แต่การเลือกขออภัยแทนขออนุญาตนั้นขึ้นอยู่กับสถานการณ์ บนเว็บไซต์โซเชียลเน็ตเวิร์ก คุณอาจเคลื่อนไหวเร็วและทำพลาดได้ แต่ในระบบควบคุมการยิงนิวเคลียร์ คุณต้องมีระบบแบบ "ห้ามยิงจนกว่าจะได้รับอนุญาต"
    • ผมใช้เทคนิคนี้ในโปรเจกต์ทำงานร่วมกันขนาดใหญ่ โดยบอกว่า "ถ้าเราไม่สามารถหาฉันทามติได้ ผมจะใช้ตัวเลือกปริยาย" ตอนอายุน้อยกว่านี้ผมเคยคิดว่าต้องมีค่าเริ่มต้นที่แย่มาก ๆ แต่แบบนั้นใช้ได้แค่ไม่กี่ครั้ง
  • ผมเรียกสิ่งนี้ว่า "การสร้างค่าเริ่มต้นที่สมเหตุสมผล" แทนที่จะขอให้ตัดสินใจทุกเรื่องยิบย่อย ก็เลือกค่าเริ่มต้นที่แสดงให้เห็นว่าคุณเข้าใจสถานการณ์ แล้วแจ้งว่าจะดำเนินการตามนั้น วิธีนี้ช่วยสร้างความไว้วางใจ และทำให้คนอื่นใส่ใจเมื่อจำเป็นจริง ๆ
  • ผมชอบรูปแบบการสื่อสารนี้ แต่ไม่ชอบส่วนที่เป็น "เส้นตาย" ผมอยากให้รายงานบอกว่าพวกเขากำลังทำงานที่ผมอาจคัดค้านได้ การกำหนดเส้นตายให้ผู้จัดการฟังดูแปลกและเหมือนเป็นการข่มขู่ที่น่ารำคาญ ผมอยากให้สมาชิกทีมมีอิสระในการตัดสินใจ