สิ่งที่ผมคิดถึงเมื่อต้องแก้ไขงานเขียน (2019)

 (evaparish.com)
2 คะแนน โดย GN⁺ 2024-04-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การแก้ไขงานเขียนคือการตรวจสอบว่างานเขียนต้องการสื่ออะไรจริง ๆ และผู้อ่านคือใคร ก่อนจะขัดเกลาประโยค โดยสามารถนำ หลักการพื้นฐาน เดียวกันไปใช้กับอีเมล เอกสาร บล็อก และนิยายได้
  • หากย้ำใจความหลักอีกครั้งในตอนต้นและตอนท้ายของงานเขียน และใส่คำนามแทนการใช้คำชี้เฉพาะอย่าง “this/that” ผู้อ่านจะไม่หลุดจากบริบท ทำให้ ความชัดเจน สูงขึ้น
  • ลดคำที่ไม่จำเป็น เปลี่ยนคำสั่งให้เป็นรูปคำสั่ง และแยกประโยคยาว ๆ กับโครงสร้างแบบ “of/for” ออก จะทำให้สื่อความหมายได้เร็วขึ้น
  • กรรมวาจก คำวิเศษณ์ ศัพท์เฉพาะ และสำนวนซ้ำซาก อาจทำให้ผู้กระทำ ความหมายที่แม่นยำ และขอบเขตของผู้อ่านพร่ามัว จึงควรเปลี่ยนเป็นกริยาและคำอธิบายที่เฉพาะเจาะจง
  • การแก้ไขงานเขียนที่ดีไม่ใช่การทำตามกฎอย่างมืดบอด แต่คือการตระหนักถึง การเลือกใช้ภาษา ให้เหมาะกับสารที่ต้องการสื่อ และตัดถ้อยคำที่ไม่จำเป็นออก

เริ่มจากกำหนดว่างานเขียนพูดถึงอะไรจริง ๆ

  • ก่อนเข้าสู่การแก้ไขระดับประโยค ต้องตรวจสอบก่อนว่างานเขียนพูดในสิ่งที่ตั้งใจจะพูดจริงหรือไม่
  • หากเขียน preamble ส่วนตัวไว้สำหรับงานเขียนแต่ละชิ้น จะมีเกณฑ์สำหรับการแก้ไข
    • คำถามหลักคือ “ประเด็นสำคัญคืออะไร” และ “เขียนเพื่อใคร”
    • เขียนข้อมูลนี้ไว้ด้านบนสุดของเอกสาร แล้วเปรียบเทียบกับเนื้อหาจริงระหว่างการเขียนและการแก้ไข
  • หากสรุปประเด็นของบทความบล็อกเป็นหนึ่งหรือสองประโยคไม่ได้ ก็ยากที่จะเขียนบทความที่สอดคล้องเป็นหนึ่งเดียว
  • ในคลาสเขียนเชิงสร้างสรรค์ของ Writers Studio ผู้เรียนจะเขียน preamble สำหรับทุกงาน โดยระบุผู้เล่าเรื่องที่ตั้งใจไว้ น้ำเสียง และบรรยากาศ ส่วนการประเมินจะเน้น เทคนิค และการบรรลุเจตนา มากกว่ารสนิยม

การทำซ้ำคือเครื่องมือที่ช่วยยึดผู้อ่านไว้

  • แม้ใจความหลักจะดูชัดเจนพอแล้ว การพูดซ้ำในตอนต้นและตอนท้ายของงานเขียนจะช่วยให้ผู้อ่านตามประเด็นได้ดีขึ้น
  • บทแนะนำการใช้งานในเอกสารมักเหมาะกับโครงสร้างที่เริ่มจากแนะนำว่าจะทำอะไร ตามด้วยขั้นตอน แล้วตรวจสอบว่าทำได้ถูกต้องหรือไม่
  • บทความบล็อกก็เหมาะกับการแนะนำหัวข้อที่จะกล่าวถึง ขยายความในเนื้อหา แล้วปิดท้ายด้วยสรุปสั้น ๆ
  • ในระดับภาษาก็จำเป็นต้องมีการทำซ้ำเช่นกัน
    • อย่าใช้แค่ สรรพนามชี้เฉพาะ อย่าง “this”, “that” แต่ให้ใส่คำนามเพื่อบอกว่ากำลังชี้ถึงอะไร
    • “To solve this shortage” ชัดเจนกว่า “To solve this”
    • “Successfully authenticating will take you to the home screen” ชัดเจนกว่า “That will take you to the home screen”
  • แม้สำหรับผู้เขียนอาจรู้สึกเหมือนพูดซ้ำ แต่สำหรับผู้อ่าน นี่คือ การทำให้ชัดเจน ที่ช่วยให้อ่านตามได้ง่ายขึ้น

ทำให้เรียบง่าย: ตัดคำที่ไม่มีความหมายออก

  • งานสำคัญที่สุดในการแก้ไขคือการลบคำที่ไม่ได้ช่วยเพิ่มความหมาย
    • “You will need to run this script” ลดเหลือ “Run this script” ได้
    • “You can aid in readability by making sure…” ลดเหลือ “Make sure…” ได้
  • หากไม่มีเหตุผลพิเศษ ควรเข้าสู่ประเด็นให้เร็วที่สุด และไม่ควรฝังความหมายไว้ใต้คำฟุ่มเฟือยหรือโครงสร้างประโยคที่ตกแต่งเกินจำเป็น

  • เปลี่ยนคำสั่งให้เป็นรูปคำสั่ง

    • ในคำสั่ง การเขียน “You should X”, “You can X” มักกระชับกว่าหากเปลี่ยนเป็น รูปคำสั่ง ของกริยา
    • “You should save the file to your home directory” กลายเป็น “Save the file to your home directory”
    • การเปลี่ยนแบบนี้ลดจำนวนคำและพาผู้อ่านไปสู่การลงมือทำทันที

  • ลดโครงสร้าง “of” และ “for”

    • โครงสร้างที่มี “of” หรือ “for” ต่อกัน มักเขียนใหม่ให้วางข้อมูลไว้หน้าคำนามได้อย่างมีประสิทธิภาพกว่า
    • “The manager of the team responsible for marketing” กลายเป็น “The marketing team’s manager”
    • ประโยคที่จัดวางใหม่ช่วยให้ผู้อ่านเข้าใจความหมายได้เร็วขึ้น โดยไม่ต้องปรับความเข้าใจใหม่ทีละอนุประโยค

  • แยกประโยคยาวและใช้จุลภาค

    • ควรแบ่งประโยคยาวออกเป็นประโยคสั้นหลายประโยค
    • ตัวอย่างโครงการ Acme เดิมใส่ทั้ง milestone, สภาพแวดล้อมเซิร์ฟเวอร์, การปรับปรุงเวลา build และการเปรียบเทียบกับ XYZ plan ไว้ในประโยคเดียว ส่วนฉบับแก้ไขแยกออกเป็นสามประโยค
    • ฉบับแก้ไขแยกบอกว่าเซิร์ฟเวอร์ non-staging ทำงานในสภาพแวดล้อม Foobaz, build ลดลงเหลือต่ำกว่า 10 นาที และใน XYZ plan ก่อนหน้านี้ใช้เวลามากกว่า 1 ชั่วโมง
    • การเพิ่มจุลภาคในตำแหน่งที่เหมาะสมช่วยให้ผู้อ่านประมวลผลส่วนหน้าก่อนอ่านส่วนที่เหลือ
    • “If you’re looking for me, I’ll be in my office”
    • “Due to the fog, our flight was delayed”
    • เมื่อมีอนุประโยครองนำหน้าประโยค จำเป็นต้องมีจุลภาค และจุลภาคนี้ทำหน้าที่เป็น จุดประมวลผล ที่ช่วยให้อ่านเข้าใจ

ลดถ้อยคำที่ทำให้ผู้กระทำและความหมายพร่ามัว

  • ตัดกรรมวาจกออก

    • กรรมวาจกบดบังว่าใครหรืออะไรเป็นผู้กระทำ
    • เมื่อเปลี่ยนประโยคกรรมวาจกเป็นกรรตุวาจก ผู้อ่านจะเชื่อมโยงการกระทำกับบุคคลหรือสิ่งที่ถูกต้องได้ ทำให้ประโยคชัดเจนขึ้น
    • “The fire alarm was pulled and the building was evacuated” เปิดเผยผู้กระทำได้เป็น “The fire marshal pulled the alarm and the employees evacuated the building”
    • “Millions of dollars were embezzled from the company” ระบุว่าใครทำได้เป็น “Two executives embezzled millions of dollars from the company”
    • ในคำอธิบายระบบ หากเขียนว่า “An alert is triggered and the job is started” จะไม่เห็นว่าบริการใด trigger การแจ้งเตือน และคอมโพเนนต์ใดเริ่มงาน
    • หากไม่ระบุผู้กระทำในเอกสารทางเทคนิค ความแม่นยำ จะลดลง

  • ใช้กริยาและคำบรรยายที่เฉพาะเจาะจงแทนคำวิเศษณ์

    • คำวิเศษณ์แทบทุกครั้งสามารถเปลี่ยนเป็นกริยาหรือคำอธิบายที่เฉพาะเจาะจงกว่าได้
    • คำว่า “loudly” ใน “He laughed loudly” ทำให้ผู้อ่านต้องเดาขนาดหรือความรู้สึกของเสียงหัวเราะที่แท้จริง
    • หากเจตนาจริงคือ “หัวเราะดังจนทั้งร้านอาหารหันมามอง” การบรรยายสถานการณ์นั้นโดยตรงจะเฉพาะเจาะจงกว่า
    • คำวิเศษณ์อย่าง “Basically”, “Essentially” มักถูกใช้เป็นการเลี่ยงน้ำหนักคำพูด จึงควรตัดออกแล้วพูดสิ่งที่ต้องการสื่อโดยตรง

อย่าทึกทักความรู้และน้ำเสียงของผู้อ่าน

  • อธิบายตัวย่อและแนวคิด

    • เมื่อเขียนเรื่องที่รู้ดีอยู่แล้ว มักลืมพื้นหลังที่ผู้อ่านอาจไม่รู้
    • ตัวย่อและอักษรย่อควรเขียนเต็มเมื่อปรากฏครั้งแรก ใส่ตัวย่อไว้ในวงเล็บ แล้วหลังจากนั้นจึงใช้เฉพาะตัวย่อ
    • “TTFB” ควรเขียนครั้งแรกเป็น “time to first byte (TTFB)”
    • เมื่อแนวคิดปรากฏครั้งแรก การเพิ่มคำอธิบายสั้น ๆ จะช่วยให้ผู้อ่านตามได้ง่ายขึ้น
    • TTFB วัดเวลาตั้งแต่ผู้ใช้ส่งคำขอ HTTP จนถึงเวลาที่เบราว์เซอร์โหลดไบต์แรก
    • ใช้เป็นตัวชี้วัดความตอบสนองของเว็บไซต์
    • หากจำเป็น สามารถให้ลิงก์สำหรับศึกษาเพิ่มเติม เช่น time to first byte (TTFB) metric

  • ความสม่ำเสมอของน้ำเสียง

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

ขัดเกลาศัพท์เฉพาะ สำนวนซ้ำซาก และโครงสร้างเชิงภาพ

  • เลี่ยงศัพท์เฉพาะและสำนวนซ้ำซาก

    • ศัพท์เฉพาะทางธุรกิจมีสำนวนอย่าง “deep dive”, “low-hanging fruit” และในงานเขียนอื่น ๆ มักใช้สำนวนซ้ำซาก เช่น อุปมาเกี่ยวกับเบสบอล
    • ศัพท์เฉพาะทึกทักว่าผู้อ่านอยู่ในกลุ่มคนวงในที่ใช้สำนวนเหล่านั้น
    • สำหรับผู้อ่านที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่ หรือไม่คุ้นกับวัฒนธรรมเบสบอล ศัพท์เฉพาะและสำนวนซ้ำซากอาจทำให้อ่านตามได้ยาก
    • “tl;dr, if you can hack something together by EOD…” มีทั้งตัวย่อและสแลงทางเทคนิค และฟังดูไม่เหมือนคำขอ
    • “Can you deliver a prototype by the end of today?” กลายเป็น คำขอที่ชัดเจน ซึ่งถามถึงผลลัพธ์ที่ต้องการและกำหนดเวลาโดยตรง

  • ใช้พื้นที่ว่างและรูปแบบให้เป็นประโยชน์

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

ปรัชญาการแก้ไขงานเขียน

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

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

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

 
GN⁺ 2024-04-07
ความคิดเห็นจาก Hacker News

  • ผมเป็นคนเขียนบทความนี้เอง ดีใจและเป็นเกียรติมากที่บทความนี้โดนใจหลายคน หลังจากเขียนบทความ ผมตามความอยากรู้อยากเห็นจนได้มาเป็น วิศวกรซอฟต์แวร์ เอง และพอทำงานมาหลายปี ก็เริ่มคิดถึงบทบาทที่มีสัดส่วนงานเขียนมากกว่า ถ้าคุณกำลังมองหานักเขียนเทคนิคที่ยอดเยี่ยม, developer advocate หรือบทบาทที่ผสมผสานความเชี่ยวชาญด้านการสื่อสารเข้ากับความสามารถด้านเทคนิค โปรดบอกผมได้เลย ติดต่อได้ผ่านแบบฟอร์มบนเว็บไซต์(https://evaparish.com/contact) หรือ LinkedIn

    • ผมได้อะไรจากบทความนี้เยอะมากจริง ๆ น่าจะช่วยให้เขียนได้ กระชับและชัดเจน ขึ้น และทำให้ผู้อ่านเข้าใจได้ดีขึ้น แต่หลังจากเขียนว่า “I really got a lot out of the article.” แล้ว ผมก็ลังเลว่าประโยคนี้จำเป็นไหม ชัดเจนไหม และตรงกับสิ่งที่ตั้งใจจะพูดจริงหรือเปล่า สุดท้ายมันก็เป็นสิ่งที่อยากพูดจริง ๆ และประโยคถัดไปก็ขยายความไว้แล้ว เลยอยากรู้ว่าคุณมองอย่างไร
    • ทำให้นึกถึงคำแนะนำเรื่องการเขียนหลายอย่างที่เคยได้ยินจากการบรรยาย/เวิร์กช็อป Clear, accurate, concise writing ของ Jean-luc Doumont
    • ตลกดีที่ในตัวอย่างใช้ HTTP โดยไม่อธิบายเลย อยากรู้ว่านั่นเป็นมุกที่ตั้งใจไว้หรือเปล่า

  • สิ่งหนึ่งที่กวนใจที่สุดเวลาอ่านเอกสารเทคนิคคือการเจอ ตัวย่อ ที่ยังไม่ได้แนะนำให้ผู้อ่านรู้จัก เรื่องแบบนี้เกิดซ้ำ ๆ ในหลายจุดของเอกสารโปรเจกต์ และพอคนรับผิดชอบเปลี่ยนไปในช่วงหลายปี ก็ถึงขั้นไม่มีใครรู้แล้วว่าตัวย่อบางตัวจริง ๆ ย่อมาจากอะไร ผมเคยเห็นสถานการณ์แปลก ๆ หลายครั้งที่ทีมหนึ่งพัฒนาและดูแลบริการชื่อ ABC แต่ไม่มีสมาชิกทีมคนไหนรู้ว่า ABC ย่อมาจากอะไร ในกรณีแบบนั้นก็มักจะถือว่า ABC เป็นชื่อเฉพาะไปเลย เพื่อหลีกเลี่ยงงานเลือกชื่อใหม่และอัปเดตเอกสารที่เกี่ยวข้องทั้งหมด ตัวอย่างสมมติ: หากต้องการรับ access token สำหรับ CDIS ให้ไปที่ DMC ของ แล้วคลิกรายการ "CDIS" ในแถบด้านข้างซ้าย จากนั้นกด "Generate Access Token" แล้วคัดลอกโทเคน ผมอยากอ่านแบบนี้มากกว่า: หากต้องการรับ access token สำหรับ Customer Data Indexing Service(CDIS) ให้ไปที่ Data Management Console(DMC) ของ แล้วคลิกรายการ "CDIS" ในแถบด้านข้างซ้าย จากนั้นกด "Generate Access Token" แล้วคัดลอกโทเคน