Topic 7 สื่อสารให้เป็น!

ผมเชื่อว่าการถูกคนเพ่งเล็ง ยังดีกว่าการถูกมองข้าม

Mae West, Belle of the Nineties, 1934

บางทีเราอาจเรียนรู้บทเรียนจากคุณ West ได้ว่า มันไม่ใช่แค่ว่าคุณมีอะไร แต่สำคัญที่ว่าคุณห่อหุ้ม (package) มันอย่างไร การมีไอเดียที่ดีที่สุด โค้ดที่เนียนที่สุด หรือการคิดแบบ pragmatic ที่สุดจะไม่มีความหมายเลย ถ้าคุณสื่อสารกับคนอื่นไม่เป็น ไอเดียที่ดีก็เหมือนเด็กกำพร้าถ้าขาดการสื่อสารที่มีประสิทธิภาพ

ในฐานะ developer เราต้องสื่อสารกันหลายระดับมาก เราใช้เวลาหลายชั่วโมงใน meeting ทั้งฟังและพูด เราทำงานร่วมกับ end users เพื่อพยายามทำความเข้าใจความต้องการของเขา เราเขียน code ที่สื่อสารถึงความต้องการของเราให้เครื่องจักรเข้าใจ พร้อมทั้งบันทึกวิธีคิดไว้ให้ developer รุ่นหลังได้ศึกษาต่อ เราเขียน proposal และ memo เพื่อขอทรัพยากร รายงาน status และเสนอแนวทางใหม่ๆ และเราทำงานร่วมกับทีมในแต่ละวันเพื่อผลักดันไอเดีย ปรับปรุงแนวทางปฏิบัติที่มีอยู่เดิม และเสนอสิ่งใหม่ๆ เวลาส่วนใหญ่ในวันทำงานของเราหมดไปกับการสื่อสาร ดังนั้นเราจึงต้องทำมันให้ดี

มองภาษาอังกฤษ (หรือภาษาแม่ของคุณ) ให้เหมือนกับเป็นอีกหนึ่ง programming language เขียนภาษาธรรมชาติเหมือนที่คุณเขียน code: ยึดหลัก DRY principle, ETC, automation และอื่นๆ (เราจะพูดถึง DRY และ ETC design principles ในบทถัดไป)

Tip 11 ภาษาอังกฤษเป็นแค่ programming language อีกตัวหนึ่งเท่านั้น

เราได้รวบรวมไอเดียเพิ่มเติมที่เราคิดว่ามีประโยชน์มาไว้ตรงนี้

รู้จักผู้ฟังของคุณ (Know Your Audience)

คุณจะสื่อสารได้สำเร็จก็ต่อเมื่อคุณถ่ายทอดสิ่งที่คุณต้องการสื่อ—แค่พูดอย่างเดียวนั้นไม่พอ การจะทำแบบนั้นได้ คุณต้องเข้าใจความต้องการ ความสนใจ และความสามารถของผู้ฟัง เราทุกคนเคยนั่งใน meeting ที่ dev สายลึกคนหนึ่งกำลังร่ายยาวเรื่องข้อดีของ technology ที่เข้าใจยากซะจนรองประธานฝ่าย marketing ถึงกับตาค้าง แบบนี้เรียกว่าแค่พูด ไม่ใช่การสื่อสาร และมันน่ารำคาญ [12]

สมมติว่าคุณต้องการเปลี่ยน remote monitoring system ให้ใช้ message broker จากภายนอกเพื่อกระจายการแจ้งเตือนสถานะ (status notifications) คุณสามารถนำเสนอการอัปเดตนี้ได้หลายรูปแบบขึ้นอยู่กับผู้ฟัง end users จะประทับใจที่ระบบของเขาสามารถทำงานร่วมกับบริการอื่นที่ใช้ message broker ได้ แผนก marketing สามารถนำไปใช้เพื่อเพิ่มยอดขายได้ ผู้จัดการทีม development และ operations จะดีใจเพราะการดูแลและรักษาความปลอดภัยส่วนนั้นของระบบกลายเป็นหน้าที่ของคนอื่นไปแล้ว สุดท้าย developer เองก็อาจจะชอบที่ได้สัมผัสกับ APIs ใหม่ๆ และอาจจะเจอวิธีใช้งาน message broker ในรูปแบบใหม่ๆ การนำเสนอที่ตรงประเด็นกับแต่ละกลุ่มจะทำให้ทุกคนตื่นเต้นไปกับโปรเจกต์ของคุณ

เช่นเดียวกับทุกรูปแบบของการสื่อสาร เคล็ดลับที่นี่คือการรวบรวม feedback อย่าแค่รอคำถาม: แต่จงเป็นคนถามเอง สังเกตภาษาท่าทางและสีหน้า หนึ่งในหลักของ Neuro Linguistic Programming คือ “ความหมายของการสื่อสารของคุณคือผลลัพธ์ที่คุณได้รับ” จงหมั่นปรับปรุงความเข้าใจของคุณที่มีต่อผู้ฟังอย่างต่อเนื่องในขณะที่คุณสื่อสาร

รู้ว่าคุณต้องการจะพูดอะไร (Know What You Want to Say)

สิ่งที่ยากที่สุดในสไตล์การสื่อสารที่เป็นทางการมากขึ้นในการทำธุรกิจคือการคิดว่าเราต้องการจะสื่อสารอะไรกันแน่ นักเขียนนิยายมักจะวางโครงเรื่องอย่างละเอียดก่อนเริ่ม แต่คนเขียนเอกสารทางเทคนิค (technical documents) มักจะยินดีที่จะนั่งลงที่ keyboard แล้วพิมพ์ลงไปเลยว่า:

  1. บทนำ (Introduction)

แล้วเริ่มพิมพ์อะไรก็ตามที่โผล่ขึ้นมาในหัวตอนนั้น

จงวางแผนสิ่งที่คุณต้องการจะพูด เขียน outline แล้วถามตัวเองว่า “สิ่งนี้สื่อสารสิ่งที่ฉันต้องการจะบอกแก่ผู้ฟังในรูปแบบที่เหมาะสมกับพวกเขาหรือไม่?” ปรับปรุงมันจนกว่าจะใช่

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

ตอนนี้คุณรู้แล้วว่าผู้ฟังต้องการอะไร มาส่งต่อสิ่งนั้นกันเถอะ

เลือกช่วงเวลาให้ถูก (Choose Your Moment)

มันคือเวลาหกโมงเย็นวันศุกร์ หลังจากสัปดาห์ที่ทีมออดิต (auditors) เพิ่งเข้ามาตรวจ ลูกคนเล็กของเจ้านายคุณกำลังนอนโรงพยาบาล ข้างนอกฝนตกหนัก และการเดินทางกลับบ้านน่าจะเป็นฝันร้ายแน่ๆ นี่คงไม่ใช่เวลาที่ดีนักที่จะไปขอเธออัปเกรดแรม (memory upgrade) ให้กับ laptop ของคุณ

การทำความเข้าใจว่าผู้ฟังต้องการได้ยินอะไรนั้น คุณต้องพิจารณาด้วยว่าลำดับความสำคัญ (priorities) ของเขาคืออะไร ถ้าคุณไปหาผู้จัดการที่เพิ่งโดนเจ้านายของเธอตำหนิมาเพราะมีซอร์สโค้ด (source code) บางส่วนหายไป คุณก็จะมีผู้ฟังที่พร้อมจะรับฟังไอเดียเรื่องการใช้ source code repository มากขึ้น จงทำให้สิ่งที่คุณพูดมีความสำคัญทั้งในแง่ของเวลาและเนื้อหา บางครั้งสิ่งที่ต้องทำก็แค่คำถามง่ายๆ ว่า "สะดวกคุยเรื่อง... ตอนนี้ไหม?"

เลือกสไตล์การนำเสนอ (Choose a Style)

ปรับสไตล์การนำเสนอให้เหมาะกับผู้ฟัง บางคนอาจต้องการข้อมูลที่สรุปมาแบบสั้นๆ "เอาแต่เนื้อๆ" (just the facts) ในขณะที่บางคนชอบการคุยแบบสบายๆ ครอบคลุมหลายหัวข้อก่อนจะเริ่มเข้าเรื่อง ระดับทักษะและประสบการณ์ของเขาเป็นอย่างไร? เขาเป็นผู้เชี่ยวชาญ (experts) หรือมือใหม่ (newbies)? เขาต้องการการประคองไปทีละขั้น หรือแค่ต้องการสรุปสั้นๆ (tl;dr)? ถ้าไม่แน่ใจ ก็ให้ถามเลย

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

ทำให้ดูดี (Make It Look Good)

ไอเดียของคุณมีความสำคัญ มันสมควรจะถูกนำเสนอผ่านช่องทางที่ดูดีเพื่อให้ผู้ฟังของคุณได้รับรู้

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

ไม่มีข้อแก้ตัวสำหรับเอกสารที่ดูไม่ดีในปัจจุบัน ซอฟต์แวร์สมัยใหม่สามารถสร้างผลลัพธ์ที่น่าทึ่ง ไม่ว่าคุณจะเขียนด้วย Markdown หรือใช้ word processor ก็ตาม คุณแค่ต้องเรียนรู้วิธีการใช้งานพื้นฐานเพียงไม่กี่อย่าง ถ้าคุณใช้ word processor ก็ควรใช้ style sheets ของมันเพื่อให้งานมีความสม่ำเสมอ (บริษัทของคุณอาจจะมี style sheet ที่กำหนดไว้อยู่แล้ว) เรียนรู้วิธีตั้งค่าหัวกระดาษและท้ายกระดาษ (headers and footers) ดูตัวอย่างเอกสารที่มาพร้อมกับโปรแกรมเพื่อหาไอเดียเกี่ยวกับสไตล์และการจัดวาง ตรวจสอบตัวสะกด (check spelling) ทั้งแบบอัตโนมัติและตรวจสอบด้วยตัวเอง เพราะบางครั้งตัวตรวจสอบก็หาคำที่สะกดผิดแต่มีความหมายใกล้เคียงไม่เจอ (After awl, their are spelling miss steaks that the chequer can knot ketch.)

ให้ผู้ฟังมีส่วนร่วม (Involve Your Audience)

เรามักจะพบว่าเอกสารที่เราทำเสร็จสมบูรณ์แล้วนั้น กลับมีความสำคัญน้อยกว่ากระบวนการที่เราต้องทำเพื่อให้ได้เอกสารนั้นมาเสียอีก ถ้าเป็นไปได้ ให้คนอื่นมีส่วนร่วมกับแบบร่าง (draft) แรกๆ ของเอกสารของคุณ รับ feedback ของเขา และระดมสมองร่วมกัน คุณจะสร้างความสัมพันธ์ในการทำงานที่ดี และคุณก็น่าจะสร้างเอกสารที่ดีขึ้นได้ในกระบวนการนี้

เป็นผู้ฟัง (Be a Listener)

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

กระตุ้นให้คนพูดโดยการถามคำถาม หรือให้เขาสรุปสิ่งที่พูดคุยกันด้วยคำพูดของเขาเอง เปลี่ยนการประชุมให้เป็นการสนทนา (dialog) แล้วคุณจะถ่ายทอดประเด็นของคุณได้อย่างมีประสิทธิภาพมากขึ้น และใครจะรู้ คุณอาจจะได้เรียนรู้อะไรบางอย่างด้วยก็ได้

ตอบกลับผู้คน (Get Back to People)

ถ้าคุณถามคำถามใครสักคนแล้วเขาไม่ตอบ คุณจะรู้สึกว่าเขาเสียมารยาท แต่กี่ครั้งที่คุณลืมตอบกลับคนอื่นที่ส่งอีเมล (email) หรือบันทึกข้อความ (memo) มาหาคุณเพื่อขอข้อมูลหรือขอให้ทำอะไรบางอย่าง? ในชีวิตประจำวันที่เร่งรีบ มันเป็นเรื่องง่ายที่จะลืม ตอบกลับอีเมลและข้อความเสียงเสมอ แม้ว่าจะเป็นเพียงคำตอบสั้นๆ ว่า "เดี๋ยวฉันจะติดต่อกลับในภายหลัง" การแจ้งให้ผู้คนทราบจะทำให้เขาให้อภัยต่อความผิดพลาดเล็กๆ น้อยๆ ได้ง่ายขึ้น และทำให้เขารู้สึกว่าคุณไม่ได้ลืมเขา

Tip 12 มันสำคัญทั้งสิ่งที่คุณพูดและวิธีที่คุณพูด

ถ้าคุณไม่ได้ทำงานคนเดียว (work in a vacuum) คุณจำเป็นต้องสื่อสารให้เป็น ยิ่งคุณสื่อสารได้มีประสิทธิภาพมากเท่าไหร่ คุณก็จะยิ่งมีอิทธิพลมากขึ้นเท่านั้น

เอกสารประกอบ (Documentation)

สุดท้าย คือเรื่องของการสื่อสารผ่านเอกสาร (documentation) โดยทั่วไปแล้ว developer มักไม่ค่อยให้ความสำคัญกับเอกสารนัก อย่างดีที่สุดก็คือมองว่าเป็นสิ่งที่จำเป็นต้องทำ แย่ที่สุดก็คือมองว่าเป็นงานที่มีลำดับความสำคัญต่ำ และหวังว่าผู้จัดการจะลืมมันไปเมื่อโปรเจกต์จบลง

Pragmatic Programmer จะมองว่าการเขียนเอกสารเป็นส่วนสำคัญของกระบวนการพัฒนา (development process) โดยรวม การเขียนเอกสารสามารถทำได้ง่ายขึ้นโดยไม่จำเป็นต้องทำอะไรซ้ำซ้อนหรือเสียเวลา และเก็บรักษาเอกสารไว้ใกล้ตัว—ซึ่งก็คือในโค้ด (code) นั่นเอง ความจริงแล้ว เราต้องการประยุกต์ใช้หลักการ pragmatic ทั้งหมดของเรากับเอกสารด้วยเช่นกัน

Tip 13 เขียนเอกสารไว้ในตัว อย่ารอมาแปะทีหลัง

มันง่ายมากที่จะสร้างเอกสารประกอบที่ดูดีจากคอมเมนต์ (comments) ในซอร์สโค้ด (source code) และเราขอแนะนำให้เพิ่มคอมเมนต์ในโมดูล (modules) และฟังก์ชัน (functions) ที่ export ออกไปเพื่อให้ developer คนอื่นได้รับข้อมูลที่เป็นประโยชน์เมื่อเขามาใช้งาน

อย่างไรก็ตาม นี่ไม่ได้หมายความว่าเราจะเห็นด้วยกับกลุ่มคนที่บอกว่าทุกฟังก์ชัน ทุกโครงสร้างข้อมูล (data structure) หรือการประกาศประเภทข้อมูล (type declaration) ฯลฯ จำเป็นต้องมีคอมเมนต์เป็นของตัวเอง การเขียนคอมเมนต์แบบเครื่องจักรนี้ความจริงแล้วทำให้การดูแลรักษาโค้ดทำได้ยากขึ้น เพราะตอนนี้มีสองสิ่งที่คุณต้องอัปเดตเมื่อมีการเปลี่ยนแปลง ดังนั้น จงจำกัดการเขียนคอมเมนต์ในส่วนที่ไม่ใช่ API ไว้แค่การคุยว่า "ทำไม" ถึงทำแบบนี้ วัตถุประสงค์และเป้าหมายของมันคืออะไร ส่วนโค้ดได้แสดงให้เห็นแล้วว่ามัน "ทำอย่างไร" ดังนั้นการเขียนคอมเมนต์ซ้ำในส่วนนี้จึงเป็นสิ่งที่เกินความจำเป็น—และเป็นการละเมิดหลักการ DRY (Don't Repeat Yourself)

การเขียนคอมเมนต์ลงในซอร์สโค้ดทำให้คุณมีโอกาสดีที่จะบันทึกส่วนที่หาดูที่ไหนไม่ได้อีกในโปรเจกต์ เช่น การแลกเปลี่ยนทางวิศวกรรม (engineering trade-offs) ทำไมถึงตัดสินใจแบบนี้ มีตัวเลือกอื่นๆ อะไรบ้างที่ถูกยกเลิกไป และอื่นๆ

สรุป (Summary)

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

หัวข้อที่เกี่ยวข้อง (Related Sections Include)

  • Topic 15, ​_Estimating_​
  • Topic 18, ​_Power Editing_​
  • Topic 45, ​_The Requirements Pit_​
  • Topic 49, ​_Pragmatic Teams_​

การสื่อสารออนไลน์ (Online Communication)

ทุกสิ่งที่เราพูดถึงเกี่ยวกับการสื่อสารผ่านการเขียนนั้นสามารถนำไปปรับใช้ได้เช่นเดียวกันกับอีเมล (email), โพสต์บนโซเชียลมีเดีย, บล็อก และอื่นๆ โดยเฉพาะอย่างยิ่งอีเมลได้วิวัฒนาการจนกลายเป็นหัวใจหลักของการสื่อสารในองค์กรไปแล้ว ไม่ว่าจะเป็นการใช้พูดคุยเรื่องสัญญา, ยุติข้อพิพาท หรือแม้แต่ใช้เป็นหลักฐานในชั้นศาล แต่ด้วยเหตุผลบางอย่าง คนที่ไม่เคยคิดจะส่งเอกสารกระดาษที่ดูแย่ออกไป กลับยินดีที่จะส่งอีเมลที่ดูไม่เป็นระเบียบและอ่านไม่รู้เรื่องไปทั่วโลก

เคล็ดลับของเรานั้นเรียบง่าย:

  • ตรวจทานก่อนกดปุ่ม SEND (ส่ง)

  • ตรวจสอบตัวสะกดและมองหาความผิดพลาดจากการแก้ไขอัตโนมัติ (auto-correct) ที่ไม่พึงประสงค์

  • รักษาฟอร์แมต (format) ให้เรียบง่ายและชัดเจน

  • จำกัดการอ้างอิงข้อความ (quoting) ให้เหลือน้อยที่สุด ไม่มีใครชอบรับอีเมล 100 บรรทัดของตัวเองที่เพิ่งส่งไป โดยที่มีแค่คำว่า "เห็นด้วย" แปะอยู่ข้างใต้

  • ถ้าคุณต้องอ้างอิงอีเมลของคนอื่น อย่าลืมระบุแหล่งที่มา และอ้างอิงแบบแทรกไปในเนื้อหา (inline) แทนที่จะส่งเป็นไฟล์แนบ (attachment) เช่นเดียวกับการอ้างอิงบนแพลตฟอร์มโซเชียลมีเดีย (social media)

  • อย่าใช้ถ้อยคำรุนแรง (flame) หรือทำตัวเป็นเกรียน (troll) เว้นแต่ว่าคุณอยากให้มันกลับมาหลอกหลอนคุณในภายหลัง ถ้าคุณไม่กล้าพูดเรื่องนี้ต่อหน้าเขา ก็อย่าพูดมันบนโลกออนไลน์

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

อย่างที่บริษัทใหญ่ๆ และนักการเมืองนับไม่ถ้วนได้พบมา อีเมลและโพสต์บนโซเชียลมีเดียนั้นคงอยู่ตลอดไป (forever) พยายามให้ความใส่ใจและความรอบคอบกับอีเมลให้เหมือนกับที่คุณทำกับบันทึกข้อความ (memo) หรือรายงานที่เขียนขึ้นอย่างเป็นทางการ

ความท้าทาย (Challenges)

  • มีหนังสือดีๆ หลายเล่มที่มีส่วนเกี่ยวกับการสื่อสารภายในทีม รวมถึง _The Mythical Man-Month: Essays on Software Engineering_ [Bro96] และ _Peopleware: Productive Projects and Teams_ [DL13] ลองหาโอกาสอ่านเล่มเหล่านี้ให้ได้ภายในช่วง 18 เดือนหน้า นอกจากนี้ _Dinosaur Brains: Dealing with All Those Impossible People at Work_ [BR89] ยังได้พูดถึงเรื่อง "ภาระทางอารมณ์" (emotional baggage) ที่เราทุกคนนำติดตัวมาในสภาพแวดล้อมการทำงานด้วย

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