Mở đầu — vì sao bài này quan trọng
Có một sự thật hơi phũ phàng mà nhiều kỹ sư giỏi phải học đi học lại nhiều năm: giá trị công việc của bạn không được đo bằng những gì bạn làm, mà bằng những gì người khác hiểu rằng bạn đã làm. Bạn có thể vừa vá xong một lỗ hổng bảo mật cực kỳ tinh vi, tối ưu query xuống còn 1/10 thời gian, hay thiết kế một kiến trúc chịu tải triệu request — nhưng nếu người ra quyết định (sếp, khách hàng, đội sales, nhà đầu tư) không hiểu được ý nghĩa của việc đó, thì trong mắt họ, bạn "chỉ đang làm mấy thứ kỹ thuật".
Viết cho đối tượng phi kỹ thuật (non-technical audiences) là một trong những kỹ năng có đòn bẩy cao nhất trong sự nghiệp tech. Nó là chiếc cầu nối giữa "tôi làm được việc" và "tôi được công nhận, được tin tưởng, được giao việc lớn hơn". Ở Việt Nam và Đông Nam Á, nơi rất nhiều team engineer làm việc trực tiếp với founder không rành công nghệ, với khách hàng doanh nghiệp truyền thống, hay với đối tác nước ngoài — kỹ năng này gần như quyết định việc bạn dừng lại ở mức senior IC hay tiến xa hơn.
Bài học này KHÔNG nói về viết tài liệu kỹ thuật (đã có Bài 9), không nói về email (Bài 8), không nói về thuyết trình cho lãnh đạo bằng 5 slide (Bài 33). Bài 52 tập trung vào một câu hỏi cốt lõi: khi người đọc không hiểu ngôn ngữ kỹ thuật của bạn, làm sao để họ vẫn hiểu đúng, quan tâm và hành động?
Khái niệm cốt lõi
Nguyên tắc số 1: Người phi kỹ thuật không quan tâm "cái gì", họ quan tâm "để làm gì cho tôi"
Kỹ sư có xu hướng mô tả giải pháp (chúng tôi migrate sang PostgreSQL, thêm cache layer Redis, refactor service X). Người phi kỹ thuật cần nghe tác động (trang web sẽ tải nhanh gấp 3 lần, khách hàng bớt bỏ giỏ hàng, chúng ta tiết kiệm 40 triệu/tháng tiền server).
Hãy nhớ công thức: Ngôn ngữ kỹ thuật mô tả cơ chế. Ngôn ngữ phi kỹ thuật mô tả kết quả. Khi viết cho người ngoài ngành, hãy dịch mọi thứ từ "cơ chế" sang "kết quả" mà họ đo lường được: tiền, thời gian, rủi ro, trải nghiệm khách hàng.
Nguyên tắc số 2: Xác định archetype người đọc trước khi viết một chữ nào
Không có "người phi kỹ thuật" chung chung. Có ít nhất ba nhóm rất khác nhau, và mỗi nhóm cần một loại thông điệp:
1. Lãnh đạo / Exec (CEO, founder, giám đốc). Họ muốn nghe về ROI và rủi ro. Câu hỏi trong đầu họ: "Việc này giúp công ty kiếm/tiết kiệm được gì? Nếu không làm thì nguy hiểm cỡ nào? Tốn bao nhiêu và bao lâu?". Họ đọc lướt, ít thời gian, ghét chi tiết. Với họ, hãy viết theo kiểu kết luận trước, lý do sau (BLUF — Bottom Line Up Front).
2. Khách hàng / người dùng cuối. Họ muốn nghe về giá trị và sự dễ dàng. Câu hỏi: "Cái này giúp tôi làm gì nhanh hơn/tốt hơn? Tôi có phải học lại không? Có làm hỏng thứ tôi đang dùng không?". Họ không quan tâm bạn thông minh cỡ nào, họ quan tâm cuộc sống của họ có dễ hơn không.
3. Đội Sales / Customer Success (CS) / các phòng ban nội bộ. Họ muốn thứ có thể dùng ngay để nói lại với khách. Câu hỏi: "Tôi giải thích tính năng này cho khách thế nào? Nó khác đối thủ ở đâu? Khi khách hỏi khó tôi trả lời sao?". Với nhóm này, bạn cần cung cấp ngôn ngữ mẫu để họ copy, chứ không phải giải thích nội bộ hệ thống.
Việc đầu tiên trước khi viết bất cứ thứ gì là hỏi: "Ai đọc cái này, và họ sẽ làm gì sau khi đọc xong?" Nếu không trả lời được câu này, bạn chưa nên viết.
Nguyên tắc số 3: "Lời nguyền của kiến thức" là kẻ thù lớn nhất
Curse of knowledge — khi bạn biết một thứ quá rõ, bạn quên mất cảm giác chưa-biết nó ra sao. Đây là lý do kỹ sư viết những câu như "chỉ cần cache invalidate cái endpoint là xong" mà không nhận ra 90% người đọc không hiểu một từ nào. Bạn phải chủ động hạ độ cao (altitude) của ngôn ngữ, và luôn giả định người đọc thông minh nhưng không có nền tảng kỹ thuật của bạn.
Nguyên tắc số 4: Dùng phép loại suy (analogy), không dùng thuật ngữ
Cách mạnh nhất để giải thích khái niệm kỹ thuật cho người ngoài ngành là gắn nó với thứ họ đã quen trong đời thường. "Database index giống như mục lục của một cuốn sách — thay vì lật từng trang để tìm, bạn tra mục lục rồi nhảy thẳng đến trang cần tìm." Một phép loại suy tốt tiết kiệm cả đoạn giải thích.
Tình huống thực tế
Tình huống 1: Bản cập nhật downtime gửi cho khách hàng doanh nghiệp
Một công ty SaaS về quản lý bán hàng tại TP.HCM (giả định: đặt tên là "BanHang.vn"), phục vụ khoảng 3.000 cửa hàng, gặp sự cố mất dịch vụ 47 phút vào giờ cao điểm buổi sáng. Bạn engineer, muốn gửi thông báo cho khách. Bản nháp đầu tiên của kỹ sư trực hệ thống viết:
> "Kính gửi quý khách, hệ thống gặp sự cố do connection pool bị exhausted khi một deadlock ở tầng database khiến các query bị queue lên, dẫn đến 503 hàng loạt. Chúng tôi đã restart service và scale thêm replica."
Khách hàng — phần lớn là chủ cửa hàng, không rành IT — đọc xong hoang mang hơn: "Deadlock là gì? Dữ liệu của tôi có mất không? Có bị hack không?". Bản viết lại theo tư duy phi kỹ thuật:
> "Sáng nay từ 8h03 đến 8h50, ứng dụng BanHang.vn bị gián đoạn, khiến anh/chị không đăng nhập và tạo đơn được. Nguyên nhân là hệ thống của chúng tôi quá tải cục bộ, không phải do lỗi bảo mật, và toàn bộ dữ liệu bán hàng của anh/chị vẫn an toàn nguyên vẹn. Chúng tôi đã khắc phục xong và tăng năng lực xử lý để tránh lặp lại. Với các đơn hàng bị ảnh hưởng trong khoảng thời gian này, anh/chị chỉ cần tải lại trang là dữ liệu hiển thị bình thường."
Bài học: Với khách hàng, ba câu hỏi cần trả lời NGAY và rõ ràng là: (1) Chuyện gì đã xảy ra với tôi? (2) Dữ liệu/tiền của tôi có sao không? (3) Giờ tôi phải làm gì? Nguyên nhân kỹ thuật chi tiết thuộc về báo cáo nội bộ (postmortem — xem Bài 24), không phải thư gửi khách.
Tình huống 2: Xin ngân sách kỹ thuật từ founder không rành công nghệ
Một startup fintech ở Hà Nội, đội engineer 8 người, muốn dành 6 tuần để trả nợ kỹ thuật (tech debt) trên hệ thống thanh toán. Tech lead ban đầu trình bày với CEO (dân tài chính, không phải dân code):
> "Codebase payment của mình coupling quá cao, không có test coverage, mỗi lần deploy là rủi ro regression. Cần refactor sang kiến trúc modular và thêm CI/CD pipeline với integration test."
CEO gật gù nhưng trong đầu nghĩ "6 tuần mà không ra tính năng nào cho khách? Không duyệt." Tech lead viết lại theo ngôn ngữ ROI và rủi ro:
> "Hiện tại mỗi lần chúng ta cập nhật phần thanh toán, có khoảng 1/4 khả năng phát sinh lỗi ngoài ý muốn vì code cũ chồng chéo. Tháng trước sự cố kiểu này khiến 1.200 giao dịch bị treo trong 2 giờ và một khách doanh nghiệp lớn dọa rời đi. Nếu đầu tư 6 tuần dọn dẹp phần này, tốc độ ra tính năng mới sau đó sẽ nhanh hơn khoảng 30%, và rủi ro sự cố thanh toán — thứ ảnh hưởng trực tiếp đến uy tín và giấy phép của mình — sẽ giảm mạnh. Đây là khoản đầu tư giảm rủi ro pháp lý và tăng tốc dài hạn."
Lần này CEO duyệt ngay. Bài học: Với exec, đóng khung mọi đề xuất kỹ thuật thành tiền, rủi ro, tốc độ. "Refactor" là ngôn ngữ của bạn; "giảm rủi ro sự cố thanh toán và tăng tốc 30%" là ngôn ngữ của họ. (Chủ đề giao tiếp về tech debt được đào sâu ở Bài 40 — ở đây ta chỉ tập trung khía cạnh dịch ngôn ngữ.)
Tình huống 3: Viết tài liệu tính năng cho đội Sales
Một công ty phần mềm logistics ở Singapore phục vụ thị trường Đông Nam Á ra mắt tính năng "tối ưu tuyến đường bằng thuật toán". Engineer viết tài liệu bàn giao cho Sales đầy công thức và tên thuật toán (Dijkstra, constraint solver). Đội Sales không dùng được vì không biết nói lại với khách thế nào. Product Marketing phối hợp với engineer viết lại thành một "cheat sheet" cho Sales:
> Khách hỏi: "Tính năng này giúp gì cho tôi?" → Nói: "Nó tự động sắp xếp thứ tự giao hàng để tài xế đi ít km nhất, giúp anh tiết kiệm khoảng 15–20% chi phí xăng và giao được nhiều đơn hơn mỗi ngày." > > Khách hỏi: "Có khác gì so với tài xế tự tính không?" → Nói: "Với 5 điểm giao thì con người tính được, nhưng từ 20 điểm trở lên số cách sắp xếp là hàng tỷ — phần mềm tính trong 2 giây thứ mà con người không thể."
Bài học: Đội Sales/CS không cần hiểu hệ thống hoạt động ra sao, họ cần câu chữ dùng được ngay với khách. Định dạng "khách hỏi → mình nói" là món quà quý giá bạn có thể tặng họ.
Hướng dẫn từng bước
Đây là quy trình 6 bước để viết bất kỳ nội dung nào cho đối tượng phi kỹ thuật:
Bước 1 — Xác định archetype và mục tiêu hành động. Viết ra một câu: "Người đọc là ___ (exec/khách hàng/sales), và sau khi đọc tôi muốn họ ___ (duyệt ngân sách / yên tâm / bán được hàng)." Cả bài phải phục vụ câu này.
Bước 2 — Viết kết luận trước (BLUF). Câu đầu tiên phải là thông điệp quan trọng nhất, không phải bối cảnh. So sánh: "Sau khi phân tích ba phương án..." (sai) với "Chúng ta nên chọn phương án B vì rẻ hơn 200 triệu và nhanh hơn 1 tháng" (đúng). Người phi kỹ thuật đọc lướt — đừng bắt họ đào tới cuối mới thấy điểm chính.
Bước 3 — Dịch mọi thuật ngữ sang tác động. Lập một danh sách nhỏ trong đầu: mỗi khi định viết một danh từ kỹ thuật (API, latency, migration, deploy), dừng lại và hỏi "cái này khiến điều gì tốt/xấu hơn cho người đọc?". Viết cái đó thay vì thuật ngữ. Nếu bắt buộc phải giữ thuật ngữ, giải thích ngắn ngay lần đầu bằng một phép loại suy.
Bước 4 — Neo vào con số họ quan tâm. Tiền (đồng), thời gian (giờ/ngày), phần trăm (nhanh hơn/rẻ hơn), số khách hàng bị ảnh hưởng. Con số cụ thể luôn mạnh hơn tính từ ("cải thiện đáng kể" thua "giảm thời gian tải từ 8 giây xuống 2 giây").
Bước 5 — Cắt bỏ không thương tiếc. Sau khi viết xong, gạch bỏ mọi câu mà người đọc không cần để hành động. Chi tiết kỹ thuật thú vị với bạn thường là nhiễu với họ. Nếu tiếc, đẩy chúng xuống mục "Chi tiết kỹ thuật (tùy chọn)" ở cuối hoặc một link riêng.
Bước 6 — Kiểm tra bằng "bài test người mẹ". Đọc lại và tự hỏi: nếu đưa cái này cho mẹ mình / một người bạn làm nghề hoàn toàn khác, họ có hiểu ý chính và biết phải làm gì không? Tốt nhất là thực sự nhờ một người phi kỹ thuật đọc thử và diễn đạt lại cho bạn nghe — chỗ nào họ hiểu sai là chỗ bạn viết chưa đạt.
Lỗi thường gặp & mẹo
Lỗi 1: Cho rằng đơn giản hóa là "hạ thấp" người đọc. Nhiều kỹ sư sợ viết dễ hiểu vì cảm giác như đang coi thường trí tuệ người đọc. Ngược lại: đơn giản hóa đúng cách là dấu hiệu bạn thực sự hiểu sâu. Người hiểu nửa vời mới phải trốn sau thuật ngữ.
Lỗi 2: Nhồi nhét chi tiết để chứng minh mình đã làm nhiều. Bạn muốn được ghi nhận, nên liệt kê mọi thứ đã làm. Nhưng exec đọc một danh sách 15 gạch đầu dòng kỹ thuật sẽ chỉ thấy rối, không thấy giá trị. Chọn 1–3 tác động lớn nhất và nói mạnh về chúng.
Lỗi 3: Dùng viết tắt và tiếng lóng nội bộ. "PR đó bị block vì flaky test trên staging" — với người ngoài đây gần như tiếng nước ngoài. Luôn giả định người đọc không biết bất kỳ từ viết tắt nào của team bạn.
Lỗi 4: Quên trả lời "vậy tôi phải làm gì bây giờ?". Nội dung hay đến mấy mà không có lời kêu gọi hành động (call to action) rõ ràng thì người đọc mắc kẹt. Luôn kết thúc bằng bước tiếp theo cụ thể.
Mẹo hay dùng:
- Quy tắc "nếu-thì cho khách". Khi thông báo sự cố hay thay đổi, luôn kèm "nếu anh/chị gặp X thì làm Y" để người đọc có việc cụ thể để bám vào thay vì lo lắng.
- Kỹ thuật "một tầng sâu hơn". Với mỗi thuật ngữ, chuẩn bị sẵn một câu giải thích. Nếu người đọc hỏi thêm, bạn có ngay; nếu không, bạn không làm loãng thông điệp chính.
- Đọc to lên. Nếu một câu khó đọc thành tiếng trơn tru, nó cũng khó hiểu khi đọc thầm.
- Dùng AI như một người đọc phi kỹ thuật thử nghiệm. Dán bản nháp vào và yêu cầu "giải thích lại cho tôi như thể tôi là giám đốc kinh doanh không biết code" — chỗ nào nó diễn giải lệch là chỗ cần sửa.
Bài tập thực hành
Bài 1 — Dịch thuật ngữ (10 phút). Lấy 5 câu mô tả công việc kỹ thuật gần đây của bạn (ví dụ: "tôi đã thêm rate limiting cho API"). Viết lại mỗi câu thành một câu tác động mà một người bán hàng hiểu được (ví dụ: "tôi chặn được tình trạng vài người dùng lạm dụng làm chậm hệ thống của mọi người khác"). So sánh hai phiên bản.
Bài 2 — Ba phiên bản, ba archetype (20 phút). Chọn một tính năng bạn vừa làm. Viết ba đoạn ngắn (mỗi đoạn 3–4 câu) giới thiệu nó: một cho CEO (nhấn ROI/rủi ro), một cho khách hàng cuối (nhấn giá trị/dễ dùng), một cho đội Sales (dạng "khách hỏi → mình nói"). Chú ý sự khác biệt trong cách chọn từ và trọng tâm.
Bài 3 — Viết lại thông báo sự cố (15 phút). Lấy một thông báo sự cố kỹ thuật bất kỳ (của bạn hoặc tìm mẫu), viết lại thành thông báo cho khách hàng không rành IT, đảm bảo trả lời đủ 3 câu hỏi: chuyện gì đã xảy ra với tôi, dữ liệu của tôi có sao không, giờ tôi làm gì.
Bài 4 — Bài test người thật (nếu có thể). Đưa một bản nháp bất kỳ cho một người bạn/đồng nghiệp ngoài ngành kỹ thuật, nhờ họ đọc rồi kể lại cho bạn nghe họ hiểu gì. Ghi lại những chỗ họ hiểu sai — đó là danh sách việc cần sửa của bạn.
Tóm tắt
Viết cho đối tượng phi kỹ thuật không phải là "làm cho ngu đi", mà là dịch từ ngôn ngữ cơ chế sang ngôn ngữ kết quả, cho đúng người, đúng thứ họ quan tâm. Ba điều cần nhớ:
- Xác định archetype trước khi viết. Exec cần ROI và rủi ro; khách hàng cần giá trị và sự dễ dàng; Sales/CS cần câu chữ dùng được ngay. Cùng một thông tin, ba cách kể khác nhau.
- Dịch mọi thuật ngữ thành tác động, neo vào con số. Không mô tả "chúng tôi làm gì", mà mô tả "điều đó khiến gì tốt hơn cho bạn" — bằng tiền, thời gian, rủi ro, trải nghiệm.
- Kết luận trước, cắt bỏ nhiễu, và luôn có bước hành động. Đọc lướt là mặc định của người phi kỹ thuật — hãy tôn trọng thời gian và sự chú ý của họ.