Những điều tôi nghĩ đến khi biên tập (2019)
(evaparish.com)- Biên tập là công việc xác định điều bài viết thực sự muốn nói và độc giả là ai trước khi trau chuốt câu chữ; có thể áp dụng cùng các nguyên tắc cơ bản cho email, tài liệu, blog và tiểu thuyết
- Nhắc lại điểm cốt lõi ở phần mở đầu và kết thúc, đồng thời thêm danh từ thay vì dùng các đại từ chỉ định như “this/that”, sẽ giúp độc giả không mất ngữ cảnh và tăng độ rõ ràng
- Lược bớt từ không cần thiết, chuyển câu hướng dẫn sang thể mệnh lệnh, tách các câu dài và cấu trúc “of/for” sẽ giúp ý nghĩa được truyền đạt nhanh hơn
- Thể bị động, trạng từ, thuật ngữ chuyên môn và lối nói sáo rỗng có thể làm mờ tác nhân, ý nghĩa chính xác và phạm vi độc giả; vì vậy nên thay bằng động từ và giải thích cụ thể
- Biên tập tốt không phải là mù quáng tuân theo quy tắc, mà là ý thức về lựa chọn ngôn ngữ phù hợp với thông điệp muốn truyền tải và loại bỏ những cách diễn đạt không cần thiết
Trước hết, xác định bài viết thực sự nói gì
- Trước khi bắt đầu biên tập từng câu, trước hết cần kiểm tra xem bài viết có thực sự nói đúng điều nó định nói hay không
- Nếu viết sẵn một lời mở đầu (preamble) riêng cho mỗi bài, bạn sẽ có tiêu chí để biên tập
- Các câu hỏi cốt lõi là “Ý chính là gì?” và “Viết cho ai?”
- Ghi thông tin này ở đầu tài liệu, rồi so sánh với nội dung thực tế trong quá trình viết và biên tập
- Nếu không thể tóm tắt ý chính của một bài blog trong một hoặc hai câu, sẽ khó viết được một bài nhất quán
- Trong các lớp sáng tác của Writers Studio, mỗi bài tập đều yêu cầu viết một lời mở đầu gồm người kể dự định, giọng văn và bầu không khí; việc đánh giá tập trung vào kỹ thuật và mức độ đạt được ý định hơn là sở thích
Lặp lại là thiết bị giúp giữ chân độc giả
- Ngay cả khi ý chính có vẻ đã đủ rõ, việc nói lại ở đầu và cuối bài sẽ giúp độc giả theo dõi luận điểm tốt hơn
- Hướng dẫn dạng tài liệu thường nên có cấu trúc: giới thiệu sẽ làm gì, cung cấp quy trình, rồi xác minh xem đã thực hiện đúng chưa
- Bài blog cũng phù hợp với cách giới thiệu chủ đề sẽ bàn, triển khai trong phần thân, rồi có một phần tóm tắt ngắn ở cuối
- Cần lặp lại cả ở cấp độ ngôn ngữ
- Đừng chỉ dùng các đại từ chỉ định như “this”, “that”; hãy thêm danh từ để nói rõ chúng chỉ điều gì
- “To solve this shortage” rõ ràng hơn “To solve this”
- “Successfully authenticating will take you to the home screen” rõ ràng hơn “That will take you to the home screen”
- Với người viết, điều đó có thể giống như lặp lại; nhưng với độc giả, đó là sự làm rõ giúp họ dễ theo dõi bài viết hơn
Đơn giản hóa: loại bỏ những từ không mang ý nghĩa
- Việc quan trọng nhất khi biên tập là loại bỏ những từ không đóng góp vào ý nghĩa
- “You will need to run this script” có thể rút gọn thành “Run this script”
- “You can aid in readability by making sure…” có thể rút gọn thành “Make sure…”
- Nếu không có lý do đặc biệt, nên đi vào trọng tâm càng nhanh càng tốt, và không để ý nghĩa bị chôn vùi dưới quá nhiều từ hoặc cấu trúc câu trang trí
-
Chuyển câu hướng dẫn sang thể mệnh lệnh
- Trong câu hướng dẫn, “You should X”, “You can X” nên được đổi sang thể mệnh lệnh của động từ để ngắn gọn hơn
- “You should save the file to your home directory” trở thành “Save the file to your home directory”
- Thay đổi này giảm số từ và dẫn độc giả thẳng vào hành động
-
Giảm cấu trúc “of” và “for”
- Các cấu trúc nối tiếp bằng “of” hoặc “for” sẽ hiệu quả hơn nếu viết lại để đặt thông tin trước danh từ
- “The manager of the team responsible for marketing” trở thành “The marketing team’s manager”
- Câu được sắp xếp lại giúp độc giả nắm ý nhanh hơn mà không phải điều chỉnh cách hiểu sau từng mệnh đề
-
Tách câu dài và dùng dấu phẩy
- Nên chia câu dài thành nhiều câu ngắn
- Ví dụ về dự án Acme từng nhồi milestone, môi trường máy chủ, cải thiện thời gian build và so sánh với XYZ plan vào cùng một câu; bản sửa đã tách chúng thành ba câu
- Bản sửa truyền đạt riêng từng ý: các máy chủ non-staging chạy trong môi trường Foobaz, thời gian build giảm xuống dưới 10 phút, và trong XYZ plan trước đây quá trình này mất hơn 1 giờ
- Thêm dấu phẩy đúng chỗ giúp độc giả xử lý phần đầu rồi mới đọc phần còn lại
- “If you’re looking for me, I’ll be in my office”
- “Due to the fog, our flight was delayed”
- Khi mệnh đề phụ đứng đầu câu, cần có dấu phẩy; dấu phẩy này trở thành điểm xử lý hỗ trợ việc đọc hiểu
Giảm những cách diễn đạt làm mờ tác nhân và ý nghĩa
-
Loại bỏ thể bị động
- Thể bị động che khuất ai hoặc cái gì thực hiện hành động
- Khi chuyển câu bị động sang chủ động, độc giả có thể liên kết hành động với đúng người hoặc đối tượng, giúp câu rõ ràng hơn
- “The fire alarm was pulled and the building was evacuated” làm lộ tác nhân khi viết thành “The fire marshal pulled the alarm and the employees evacuated the building”
- “Millions of dollars were embezzled from the company” nêu rõ ai làm khi viết thành “Two executives embezzled millions of dollars from the company”
- Trong phần giải thích hệ thống, nếu viết “An alert is triggered and the job is started” thì không rõ dịch vụ nào kích hoạt cảnh báo và thành phần nào chạy tác vụ
- Trong tài liệu kỹ thuật, nếu không nêu rõ chủ thể của hành động, độ chính xác sẽ giảm
-
Dùng động từ và mô tả cụ thể thay cho trạng từ
- Trạng từ hầu như luôn có thể được thay bằng động từ hoặc lời mô tả cụ thể hơn
- Từ “loudly” trong “He laughed loudly” khiến độc giả phải đoán độ lớn hoặc cảm giác chính xác của tiếng cười
- Nếu ý thực sự là “cười lớn đến mức cả nhà hàng quay lại nhìn”, thì mô tả trực tiếp tình huống đó sẽ cụ thể hơn
- Các trạng từ như “Basically”, “Essentially” thường được dùng như cách nói giảm chắc chắn; tốt hơn là loại bỏ chúng và nói thẳng điều muốn nói
Đừng giả định kiến thức và giọng điệu của độc giả
-
Giải thích chữ viết tắt và khái niệm
- Khi viết về một chủ đề mình hiểu rõ, rất dễ quên những bối cảnh mà độc giả chưa biết
- Với chữ viết tắt và chữ cái đầu, hãy viết đầy đủ ở lần xuất hiện đầu tiên, đặt chữ viết tắt trong ngoặc, rồi từ đó trở đi chỉ dùng chữ viết tắt
- “TTFB” lúc đầu được viết là “time to first byte (TTFB)”
- Khi một khái niệm lần đầu xuất hiện, thêm một giải thích ngắn sẽ giúp độc giả dễ theo dõi hơn
- TTFB đo khoảng thời gian từ lúc người dùng gửi yêu cầu HTTP đến khi trình duyệt tải byte đầu tiên
- Nó được dùng làm chỉ số thể hiện độ phản hồi của website
- Khi cần, có thể cung cấp liên kết để học thêm như time to first byte (TTFB) metric
-
Tính nhất quán của giọng văn
- Giọng văn của bài viết, dù là khẩu ngữ hay trang trọng, nên được chọn thống nhất và duy trì nhất quán
- Nếu một câu bắt đầu rất khẩu ngữ rồi chuyển sang cách diễn đạt học thuật, điều đó có thể làm độc giả bối rối hoặc khiến họ mất tập trung khỏi nội dung muốn nói
- Câu ví dụ có thể được sửa thành một giọng nhất quán, kiểu như “ban đầu rất hào hứng với framework mới nhưng không thu được các chỉ số mong muốn”
Trau chuốt thuật ngữ chuyên môn, lối nói sáo rỗng và cấu trúc thị giác
-
Tránh thuật ngữ chuyên môn và lối nói sáo rỗng
- Thuật ngữ kinh doanh có những cách diễn đạt như “deep dive”, “low-hanging fruit”; trong các loại bài viết khác, các lối nói sáo rỗng như ẩn dụ bóng chày cũng thường được dùng
- Thuật ngữ chuyên môn giả định rằng độc giả thuộc nhóm nội bộ sử dụng cách nói đó
- Với độc giả không phải người bản ngữ tiếng Anh hoặc không quen với văn hóa bóng chày, thuật ngữ chuyên môn và lối nói sáo rỗng có thể khiến bài viết khó theo dõi
- “tl;dr, if you can hack something together by EOD…” chứa chữ viết tắt và tiếng lóng kỹ thuật, đồng thời không nghe giống một lời yêu cầu
- “Can you deliver a prototype by the end of today?” trở thành một yêu cầu rõ ràng, hỏi trực tiếp về kết quả cần có và thời hạn
-
Tận dụng khoảng trắng và định dạng
- Khoảng trắng quan trọng trong tài liệu kỹ thuật, và cũng có hiệu quả trong bài blog lẫn email
- Các đoạn văn dài đặc biệt khó đọc trên màn hình máy tính, và có thể khiến độc giả mất tập trung
- Chia trang về mặt thị giác giúp dễ tìm ý chính hơn
- Chia đoạn dài thành nhiều đoạn ngắn
- Tạo cấu trúc bằng các tiểu mục hữu ích, để độc giả có thể nhảy đến phần họ quan tâm
- Viết các mục liên quan dưới dạng danh sách
- Khi truyền tải nhiều thông tin như trong tài liệu tham khảo, bảng có thể tốt hơn danh sách
- Dùng chữ đậm để độc giả đọc lướt vẫn nắm được điểm chính
Triết lý biên tập
- Triết lý biên tập có thể rút gọn thành hai điều
- Đừng dựa vào trạng từ, thuật ngữ chuyên môn, lối nói sáo rỗng hay cách nói giảm chắc chắn; hãy nói chính xác điều mình muốn nói
- Loại bỏ mọi từ không cần thiết
- Hai nguyên tắc này trở thành khung để sửa bài của chính mình và đánh giá bài viết của người khác
- Qua luyện tập, bạn sẽ hình thành phong cách và sở thích riêng; nếu hiểu rõ lý do, bạn vẫn có thể đi lệch khỏi một số khuyến nghị
- Mục đích của biên tập không phải là tuân theo quy tắc một cách thiếu phê phán, mà là ý thức về cách dùng ngôn ngữ và đưa ra lựa chọn phù hợp với thông điệp muốn truyền tải
1 bình luận
Ý kiến trên Hacker News
Tôi là người đã viết bài này. Tôi rất vui và vinh dự khi thấy nó chạm đến nhiều người. Sau khi viết bài, tôi đã đi theo sự tò mò của mình và trực tiếp trở thành một kỹ sư phần mềm; nhưng sau vài năm làm việc, tôi lại nhớ những vai trò có tỷ trọng viết lách lớn hơn Nếu bạn biết vị trí nào như technical writer xuất sắc, developer advocate, hoặc vai trò kết hợp giữa chuyên môn giao tiếp và năng lực kỹ thuật, xin hãy cho tôi biết. Có thể liên hệ qua biểu mẫu trên website (https://evaparish.com/contact) hoặc LinkedIn
Một trong những điều làm tôi khó chịu nhất khi đọc tài liệu kỹ thuật là khi xuất hiện từ viết tắt mà độc giả vẫn chưa được giới thiệu. Điều này lặp đi lặp lại ở nhiều chỗ trong tài liệu dự án, và khi người phụ trách thay đổi qua vài năm thì thậm chí đi đến tình trạng không còn ai biết một từ viết tắt cụ thể là viết tắt của cái gì Tôi đã nhiều lần thấy tình huống kỳ lạ là có một đội phát triển và bảo trì dịch vụ tên ABC, nhưng không một thành viên nào biết ABC là viết tắt của gì. Khi đó, để tránh phải chọn tên mới và cập nhật toàn bộ tài liệu liên quan, người ta cứ coi ABC như một danh từ riêng và bỏ qua Ví dụ giả: Để lấy access token cho CDIS, hãy vào DMC của và nhấp vào mục "CDIS" ở thanh bên trái, rồi nhấn "Generate Access Token" để sao chép token Tôi thà đọc thế này hơn: Để lấy access token cho Customer Data Indexing Service (CDIS), hãy vào Data Management Console (DMC) của và nhấp vào mục "CDIS" ở thanh bên trái, rồi nhấn "Generate Access Token" để sao chép token