#Kỹ năng giao tiếp cho lập trình viên

Tham khảo và biên soạn ngắn gọn từ bài viết gốc trên CNBlogs.

Lập trình viên thường cần sự tập trung cao khi code, nhưng phát triển một sản phẩm luôn liên quan đến product manager, designer, frontend, backend, tester, quản lý và người dùng. Vì vậy, giao tiếp là một phần quan trọng của công việc kỹ thuật.

#1. Giao tiếp với product manager

Product manager tập trung vào nhu cầu người dùng, trải nghiệm, thị trường và chỉ số sản phẩm. Lập trình viên tập trung vào thiết kế kỹ thuật, kiến trúc, khả năng triển khai và bảo trì. Hai góc nhìn khác nhau dễ dẫn đến “鸡同鸭讲” — cùng nói nhưng không cùng hiểu.

Cách cải thiện:

• Product manager nên nắm kiến thức kỹ thuật ở mức đủ để trao đổi.
• Lập trình viên nên hiểu mục tiêu sản phẩm và bối cảnh người dùng.
• Khi nhận yêu cầu chưa hợp lý, hãy hỏi mục tiêu, lợi ích và chỉ số kỳ vọng thay vì phản đối ngay.
• Sau khi phát hành, cùng xem lại dữ liệu để biết giải pháp có đạt mục tiêu hay không.

#Làm rõ yêu cầu

Nhu cầu người dùng có thể bị sai lệch qua nhiều lớp truyền đạt. Hãy liên tục xác nhận bằng cách:

1. Nhìn vấn đề từ nhiều góc độ.
2. Hỏi lại để sửa các giả định sai.
3. Thiết kế giải pháp đủ linh hoạt để điều chỉnh khi hiểu biết thay đổi.

#2. Giao tiếp với quản lý

Khi nhận nhiệm vụ, nên thống nhất mục tiêu, phạm vi và thời hạn; lập kế hoạch ước tính trước khi bắt đầu. Trong quá trình thực hiện:

• báo sớm khi gặp trở ngại;
• cập nhật tiến độ định kỳ;
• xác nhận mọi việc đã có người xử lý và có phản hồi;
• sau khi hoàn thành, tổng kết kết quả và bài học.

Buổi trao đổi một-một là cơ hội để thảo luận khó khăn, định hướng học tập và phát triển nghề nghiệp. Hãy chuẩn bị trước các câu hỏi và ví dụ cụ thể.

#3. Đặt câu hỏi kỹ thuật hiệu quả

Khi cần hỗ trợ xử lý bug, một câu hỏi tốt nên gồm:

1. Môi trường: phiên bản ngôn ngữ, framework và hệ điều hành.
2. Bối cảnh: mục tiêu chức năng cần xây dựng.
3. Mã nguồn tối thiểu có thể tái hiện lỗi; loại bỏ thông tin nhạy cảm.
4. Thông báo lỗi đầy đủ và các bước tái hiện.
5. Những gì đã thử và kết quả nhận được.
6. Cập nhật lại cách lỗi được sửa để người khác có thể tham khảo.

Có thể xem thêm How-To-Ask-Questions-The-Smart-Way. Khi hỏi trong cộng đồng, hãy giữ thái độ lịch sự và cởi mở.

#4. Giảm hao hụt thông tin

Thông tin đi qua nhiều bước: ý định → lời nói hoặc văn bản → điều người nghe tiếp nhận → điều họ hiểu → hành động. Ở mỗi bước, thông tin có thể bị thiếu hoặc diễn giải khác đi.

Để giảm sai lệch:

• viết lại mục tiêu và quyết định sau cuộc họp;
• dùng ví dụ, tiêu chí nghiệm thu và dữ liệu cụ thể;
• yêu cầu người nhận nhắc lại cách họ hiểu nhiệm vụ;
• phản hồi sớm thay vì chờ đến cuối dự án.

#5. Tạo môi trường giao tiếp an toàn

Một cuộc trao đổi hiệu quả cần không gian phù hợp, ít bị gián đoạn và đủ riêng tư khi vấn đề nhạy cảm. Nếu hai bên đang đối lập, hãy hạ mức căng thẳng trước khi bàn giải pháp.

Khi nghe một phát biểu, cần phân biệt đó là:

• Sự kiện: điều có thể kiểm chứng.
• Quan điểm: cách đánh giá hoặc kết luận của một người.
• Cảm nhận: trải nghiệm và cảm xúc cá nhân.

#6. Diễn đạt rõ ràng hơn

#Pyramid Principle

Trình bày theo cấu trúc “kết luận trước, lý do sau” giúp người nghe nhanh chóng nắm ý chính. Các luận điểm bên dưới cần giải thích hoặc chứng minh cho kết luận phía trên.

Một cấu trúc đơn giản để trình bày là:

1. Bối cảnh: tình huống hiện tại.
2. Vấn đề: điều đang cản trở mục tiêu.
3. Câu hỏi: cần quyết định hoặc giải quyết điều gì.
4. Trả lời: đề xuất, lý do và bước tiếp theo.

#Nonviolent Communication

Nonviolent Communication tập trung vào bốn bước:

1. Quan sát sự kiện, không gán nhãn hay phán xét.
2. Nói rõ cảm nhận của mình.
3. Nêu nhu cầu phía sau cảm nhận đó.
4. Đưa ra yêu cầu cụ thể, có thể thực hiện.

Cách này giúp cuộc trao đổi tập trung vào nhu cầu và giải pháp thay vì đổ lỗi, so sánh hoặc ép buộc.

#Kết luận

Giao tiếp tốt không làm giảm thời gian code; nó giúp giảm hiểu lầm, làm rõ yêu cầu và tránh phải sửa sai về sau. Lập trình viên nên luyện tập ba thói quen: xác nhận mục tiêu, phản hồi sớm và trình bày có cấu trúc.