Chủ đề hôm nay hơi khác một chút so với mấy bài System Design thường thấy. Nó nói về việc làm sao truyền đạt ý tưởng và chi tiết kỹ thuật của bạn cho một nhóm đối tượng không chuyên để đạt hiệu quả tối đa.

Bạn đã bao giờ thấy khó khăn khi phải giải thích một khái niệm công nghệ cho ai đó mà cả đời chưa từng nhìn một dòng code nào chưa?

Ừ thì, ai trong chúng ta cũng từng trải qua tình huống đó ít nhất một lần.

Có thể với một dev mới thì hơi khó tưởng tượng, nhưng sự thật là rất nhiều đồng nghiệp của bạn sẽ đến từ các lĩnh vực không liên quan đến công nghệ. Và bạn sẽ phải trao đổi với họ khá thường xuyên. Trong một số vị trí, việc giao tiếp này thậm chí còn cực kỳ quan trọng.

Tuy nhiên, có một điều chắc chắn:

Nếu muốn phát triển sự nghiệp như một lập trình viên, bạn phải học cách nói chuyện về mấy thứ kỹ thuật với những người không rành công nghệ.

Tin mình đi – đây chính là chìa khóa để bạn thành công, dù bạn làm trong một công ty hay đang làm freelancer.

Nhưng nói thật, việc này không khó như chúng ta hay tưởng.

Trong suốt những năm qua, mình luôn dựa vào một thứ mình gọi là Communication Iceberg (tảng băng giao tiếp) để truyền đạt ý tưởng hiệu quả nhất có thể. Cái “tảng băng” này chứa nhiều công cụ giúp mình trừu tượng hóa phần kỹ thuật, đồng thời vẫn giữ cho cuộc trò chuyện với người không chuyên thú vị, đặc biệt trong những tình huống có thể ảnh hưởng lớn đến sự nghiệp.

Tuy nhiên, quan trọng là phải hiểu khi nào và làm sao sử dụng những công cụ này. Và đó chính là những gì chúng ta sẽ bàn trong bài viết này.

Để dễ hiểu hơn, mình sẽ chia các mẹo này thành hai nhóm:

 

1 – Những mẹo chung

Một vài điều bạn nhất định phải làm khi giải thích khái niệm lập trình cho người không chuyên:

  • Dùng ví dụ so sánh – Thay vì dùng mấy từ như “server” và “request”, hãy liên hệ với ví dụ thực tế như “nhân viên phục vụ” và “gọi món” trong nhà hàng.

  • Tránh dùng viết tắt và thuật ngữ khó hiểu – Khi có thể, hãy dùng ngôn ngữ đơn giản để giải thích một khái niệm, thay vì dùng viết tắt hoặc jargon.

  • Giải thích bằng hình ảnh – Dùng công cụ trực quan như flowchart, sơ đồ hoặc biểu đồ thay vì giải thích dài dòng.

  • Kể chuyện – Ai cũng thích nghe chuyện. Chúng là công cụ mạnh mẽ để thu hút sự chú ý của người nghe. Ví dụ, thay vì nói “version control”, hãy kể câu chuyện về một nhóm dev chia sẻ code và theo dõi các thay đổi như thế nào.

  • Tập trung vào bức tranh tổng thể – Đừng nhảy ngay vào chi tiết sâu của một khái niệm kỹ thuật. Hãy bắt đầu từ bức tranh lớn rồi từ từ dẫn dắt người nghe tìm hiểu những phần phức tạp hơn.

  • Khuyến khích đặt câu hỏi – Đừng biến mình thành cái máy khi giải thích. Càng khuyến khích người khác đặt câu hỏi, bạn càng giúp họ tham gia vào cuộc trò chuyện và hiểu vấn đề tốt hơn.

Dưới đây là một sơ đồ giúp bạn hình dung rõ hơn về những chiến lược này:

2 – Những mẹo dành cho từng vai trò cụ thể

Những mẹo chung có thể giúp bạn tiến xa.

Nhưng một tổ chức được tạo thành từ nhiều vai trò khác nhau. Mọi người đến từ nhiều nền tảng, họ có mục tiêu hoặc ưu tiên riêng tùy vào vị trí của mình.

Theo kinh nghiệm của mình, nếu bạn hiểu rõ đối tượng và điều chỉnh thông điệp cho phù hợp, hiệu quả sẽ tăng lên rất nhiều.

Dưới đây là một số gợi ý cho các nhóm cụ thể:

Managers (Quản lý)

Khi nói chuyện với quản lý, hãy tập trung vào tác động kinh doanh của công việc kỹ thuật bạn đang làm.

Luôn dùng dữ liệu và số liệu để thuyết phục, thay vì chỉ dựa vào niềm tin.

Đừng nói kiểu này:

“Chúng ta nên dùng công nghệ này vì nó rất hay và mang tính tương lai.”

Hãy thử nói thế này:

“Nếu triển khai công nghệ này, chúng ta sẽ tiết kiệm được 50.000 đô chi phí vận hành mỗi quý, đồng thời tăng hiệu suất thêm 20%. Khoản tiết kiệm này có thể tái đầu tư vào các mảng khác để thúc đẩy tăng trưởng.”

Đây là một sơ đồ chi tiết hơn về cách bạn có thể thu thập thông tin bằng cách kết hợp các bên liên quan:

(Bạn có thể thử tương tác với sơ đồ này trên Eraser.io)

 

Sales Team (Đội ngũ bán hàng)

Sales chỉ quan tâm đến một thứ – bán hàng.
Khi nói chuyện với họ về công việc kỹ thuật, hãy nhấn mạnh cách nó giúp họ đạt mục tiêu.

Ví dụ:

“Bản nâng cấp phần mềm mới sẽ cho phép đội sales truy cập dữ liệu khách hàng theo thời gian thực, giúp họ có thông tin cần thiết để chốt deal nhanh hơn.”

Cách này gắn trực tiếp phần mềm của bạn với KPI của họ và tăng cơ hội dự án của bạn được tài trợ.

 

Clients (Khách hàng)

Khách hàng giống như người mua tiềm năng cho sản phẩm công nghệ của bạn. Họ có thể chính là lý do sản phẩm tồn tại.

Khi trao đổi với khách hàng, tránh dùng jargon và hãy dùng ngôn ngữ đơn giản để giải thích. Tập trung vào kết quả cuối cùng và lợi ích mang lại.

Đừng nói thế này:

“Chúng tôi đang dùng AWS Lambda để tạo serverless functions.”

Hãy thử nói thế này:

“Chúng tôi đang xây một hệ thống có thể xử lý hàng triệu request mà không phải lo lắng về khả năng tải của server, nghĩa là ứng dụng của bạn sẽ chạy mượt và gần như không có downtime.”

Chỉ nên nói về thuật ngữ kỹ thuật sau khi đã làm rõ lợi ích chính và chỉ khi thực sự cần.

General Audience (Đối tượng chung)

Là một lập trình viên, có lúc bạn sẽ phải chia sẻ kiến thức và kinh nghiệm với một nhóm đông người. Trong những trường hợp này, bạn không thể mong đợi tất cả mọi người đều hiểu chuyên môn của bạn.

Hãy dùng ví dụ hoặc tình huống thực tế để giải thích khái niệm kỹ thuật.

Ví dụ, giải thích API security cho người ngoài ngành khá khó.

Hãy tạo ví dụ như:

“Giống như việc bạn khóa cửa nhà để ngăn trộm, API cũng cần bảo vệ bằng một mã đặc biệt. Cùng ý tưởng đó, nhưng thay vì chìa khóa vật lý, bạn dùng một mã số đặc biệt – hình dung như vậy sẽ dễ hiểu hơn.”