# Kỹ năng giao tiếp kỹ thuật (Technical Communication): Khi lập trình viên phải giải thích thuật toán cho sếp kinh doanh
8/9/2026 · 6p đọc
title: # Kỹ năng giao tiếp kỹ thuật (Technical Communication): Khi lập trình viên phải giải thích thuật toán cho sếp kinh doanh
Phần 4 — Thái độ công việc và văn hóa làm việc | Bài 13/15
Mở đầu: Giỏi kỹ thuật thôi là chưa đủ, nếu không ai hiểu bạn đang nói gì
Một trong những khác biệt lớn nhất giữa lập trình viên truyền thống và AI FDE là tần suất phải giao tiếp với người không có nền tảng kỹ thuật. Lập trình viên backend có thể làm việc phần lớn thời gian chỉ với đồng nghiệp kỹ thuật. Nhưng AI FDE — do bản chất công việc là triển khai giải pháp AI cho bài toán kinh doanh cụ thể — thường xuyên phải giải thích, thuyết trình, và thuyết phục những người ra quyết định (product manager, C-level, khách hàng doanh nghiệp) hiểu và tin tưởng vào giải pháp kỹ thuật của mình.
Nếu bạn không thể giải thích rõ ràng vì sao một giải pháp AI tốn kém hơn dự kiến, hoặc vì sao AI đôi khi trả lời sai, bạn sẽ khó nhận được sự ủng hộ cần thiết để triển khai và duy trì giải pháp đó — dù bản thân giải pháp có tốt đến đâu về mặt kỹ thuật.
1. Vì sao giao tiếp kỹ thuật với người không chuyên lại khó?
Vấn đề không nằm ở việc người nghe "không đủ thông minh để hiểu" — mà nằm ở việc ngôn ngữ kỹ thuật và ngôn ngữ kinh doanh vận hành theo hai logic khác nhau:
- Người làm kỹ thuật thường tư duy theo cơ chế: "hệ thống hoạt động như thế nào".
- Người ra quyết định kinh doanh thường tư duy theo kết quả: "điều này ảnh hưởng gì đến chi phí, doanh thu, rủi ro, hoặc trải nghiệm khách hàng".
Khi một AI FDE giải thích một khái niệm kỹ thuật (RAG, token, latency...) bằng chính ngôn ngữ kỹ thuật, người nghe không chuyên dễ bị "ngợp" thông tin và không thể đưa ra quyết định đúng — không phải vì họ kém, mà vì thông tin chưa được chuyển đổi sang ngôn ngữ họ cần.
2. Cách chuyển đổi khái niệm kỹ thuật sang ngôn ngữ lợi ích kinh doanh
Ví dụ: Giải thích RAG (Retrieval-Augmented Generation)
Cách giải thích kỹ thuật (dành cho đồng nghiệp kỹ thuật):
"Hệ thống sẽ chuyển đổi tài liệu thành vector embedding, lưu trữ trong vector database, khi có câu hỏi sẽ truy xuất các đoạn văn bản liên quan nhất theo độ tương đồng cosine, sau đó đưa vào context của LLM để sinh câu trả lời."
Cách giải thích cho người không chuyên (dành cho C-level):
"Thay vì để AI tự bịa câu trả lời, hệ thống sẽ tìm đúng đoạn thông tin liên quan trong tài liệu nội bộ của công ty trước, rồi mới để AI dựa vào đó để trả lời — giúp giảm đáng kể tình trạng AI trả lời sai hoặc bịa thông tin."
Ví dụ: Giải thích chi phí vận hành LLM (token cost)
Cách giải thích cho người không chuyên:
"Mỗi lần AI xử lý một yêu cầu, chi phí sẽ phụ thuộc vào lượng thông tin AI phải 'đọc' và 'viết ra' — giống như trả tiền theo số từ. Nếu chúng ta để AI đọc toàn bộ tài liệu công ty mỗi lần trả lời, chi phí sẽ tăng rất nhanh khi số lượng người dùng tăng lên. Vì vậy nhóm kỹ thuật cần tối ưu để chỉ đưa đúng phần thông tin cần thiết, giúp giữ chi phí ở mức hợp lý khi mở rộng quy mô."
Ví dụ: Giải thích độ trễ (latency)
Cách giải thích cho người không chuyên:
"AI càng phải xử lý nhiều thông tin để đưa ra câu trả lời chính xác, thời gian phản hồi sẽ càng lâu. Đây là sự đánh đổi giữa tốc độ và độ chính xác — nhóm kỹ thuật cần cân bằng dựa trên việc trải nghiệm người dùng cần nhanh đến mức nào."
3. Nguyên tắc chung khi giao tiếp kỹ thuật với người không chuyên
Bắt đầu từ kết quả/tác động, không bắt đầu từ cơ chế
Người ra quyết định kinh doanh quan tâm đến "điều này nghĩa là gì đối với họ" trước khi quan tâm đến "nó hoạt động thế nào". Hãy mở đầu bằng tác động (chi phí, rủi ro, lợi ích), sau đó mới giải thích cơ chế nếu họ cần biết thêm.
Dùng phép so sánh, ẩn dụ quen thuộc
Chuyển các khái niệm trừu tượng (vector, embedding, context window) thành hình ảnh gần gũi với đời sống hoặc kinh doanh quen thuộc — miễn là phép so sánh không làm sai lệch bản chất kỹ thuật quan trọng.
Chuẩn bị sẵn câu trả lời cho câu hỏi "vậy rủi ro là gì"
Người ra quyết định kinh doanh gần như luôn quan tâm đến rủi ro trước khi quan tâm đến tính năng. Một AI FDE giỏi giao tiếp sẽ chủ động nêu rõ giới hạn/rủi ro của giải pháp AI (khả năng sai, chi phí biến động, thời gian triển khai) trước khi được hỏi, thể hiện sự minh bạch và đáng tin cậy.
Tránh dùng thuật ngữ khi không cần thiết
Không phải mọi chi tiết kỹ thuật đều cần được đề cập khi nói chuyện với người không chuyên. Hãy tự hỏi: "Chi tiết này có ảnh hưởng đến quyết định của người nghe không?" Nếu không, có thể lược bỏ để giữ thông điệp gọn gàng, dễ hiểu.
4. Luyện tập kỹ năng này như thế nào?
- Thực hành giải thích lại kiến thức kỹ thuật mình vừa học cho một người không cùng ngành (bạn bè, người thân) — nếu họ hiểu được, khả năng cao bạn cũng có thể giải thích tốt cho một product manager hay khách hàng.
- Ghi chú lại các phép so sánh/ẩn dụ hiệu quả mỗi khi bạn nghĩ ra hoặc nghe được một cách giải thích dễ hiểu — xây dựng dần một "kho ẩn dụ" cá nhân.
- Xin phản hồi từ người nghe không chuyên — hỏi trực tiếp "phần nào anh/chị thấy khó hiểu" thay vì tự cho rằng mình đã giải thích đủ rõ.
- Quan sát cách các senior giỏi giao tiếp trình bày vấn đề kỹ thuật trong các buổi họp liên phòng ban — đây là cơ hội học hỏi thực tế quý giá, liên hệ với thói quen quan sát senior đã nhắc ở Bài 10.
Kết luận
Kỹ năng giao tiếp kỹ thuật không phải là một "kỹ năng mềm phụ" — với một AI FDE, đây là kỹ năng cốt lõi quyết định giải pháp kỹ thuật tốt của bạn có được tin tưởng, được đầu tư, và được đưa vào thực tế hay không. Khả năng chuyển đổi ngôn ngữ kỹ thuật (RAG, token, latency) thành ngôn ngữ lợi ích kinh doanh không chỉ giúp bạn làm việc hiệu quả hơn với các bên liên quan, mà còn là một trong những yếu tố giúp bạn tiến xa hơn trong sự nghiệp, vượt ra khỏi vai trò thuần túy kỹ thuật.
Bài tiếp theo: "Quản trị cái tôi trong công việc: Từ 'sinh viên bảo thủ' đến 'kỹ sư biết lắng nghe phản hồi'"