Kỹ năng 'Soft Skills' bị lãng quên: Giao tiếp hiệu quả cho Developer

Tôi từng thấy nhiều Developer cực giỏi (Technical Expert), code như thần, nhưng sự nghiệp cứ dậm chân tại chỗ. Ngược lại, có những người kỹ thuật chỉ ở mức khá, nhưng thăng tiến rất nhanh lên Tech Lead, Engineering Manager.

Sự khác biệt nằm ở Soft Skills, đặc biệt là Kỹ năng giao tiếp. Dev chúng ta thường mắc bệnh “nói tiếng người ngoài hành tinh”. Khi PM (Project Manager) hỏi “Tại sao tính năng này chậm?”, ta trả lời: “Tại vì cái ORM nó đang bị N+1 query và race condition ở Redis lock…”. PM nghe xong: ”?!?”.

Hôm nay tôi muốn chia sẻ vài kinh nghiệm “biên dịch” ngôn ngữ Dev sang ngôn ngữ Loài người.

1. Giải thích kỹ thuật cho Non-Tech (ELI5)

Khi nói chuyện với CEO, Marketing, hay Khách hàng, họ không quan tâm công nghệ X hay Y. Họ quan tâm: Chi phí, Thời gian và Rủi ro.

• Đừng nói: “Em phải refactor lại legacy code chỗ này vì nó vi phạm nguyên tắc SOLID.”
• Hãy nói: “Hệ thống hiện tại giống như ngôi nhà móng yếu, nếu xây thêm tầng 2 (tính năng mới) thì nguy cơ sập rất cao. Em cần 3 ngày để gia cố móng trước, sau này xây thêm gì cũng nhanh hơn.” -> Dùng phép ẩn dụ (Metaphor).

2. Nghệ thuật báo tin xấu (Delay)

Delay là chuyện cơm bữa. Nhưng cách báo delay quyết định bạn là Senior hay Junior.

• Bad: (Im lặng đến phút chót mới báo) “Anh ơi hôm nay không xong đâu.”
• Good: (Báo sớm + Kèm giải pháp) “Anh ơi, em phát hiện một lỗi phát sinh từ API bên thứ 3. Khả năng cao là trễ deadline 1 ngày. Em đề xuất mình cắt giảm phần UI animation trước để kịp release tính năng chính vào ngày mai. Anh thấy sao?”

Khi bạn đưa ra lựa chọn (Trade-off), sếp sẽ thấy bạn đang kiểm soát tình hình chứ không phải đang than vãn.

3. Lắng nghe trước, phản biện sau

Dev có cái tôi (Ego) rất lớn về giải pháp của mình. Khi Code Review bị chê, phản ứng đầu tiên thường là xù lông bảo vệ. Hãy thử thay đổi tư duy: Code review không phải là chê bạn, mà là đang tìm lỗi cho sản phẩm.

Khi tranh luận giải pháp:

• Đừng nói: “Cách của anh sai rồi, cách này mới đúng.”
• Hãy nói: “Em hiểu ý anh muốn tối ưu bộ nhớ. Tuy nhiên, nếu làm cách này thì khả năng mở rộng sau này hơi khó. Anh nghĩ sao nếu mình dùng strategy pattern ở đây?“

4. Documentation cũng là giao tiếp

Viết docs cẩu thả là một dạng giao tiếp thiếu tôn trọng đồng nghiệp. Một chiếc Pull Request (PR) chất lượng luôn đi kèm mô tả rõ ràng: Làm cái gì? Tại sao làm? Test thế nào? Screenshots minh họa. Đồng nghiệp review code của bạn sẽ thầm cảm ơn vì bạn đã tiết kiệm thời gian đọc hiểu cho họ.

Kết luận

Code chạy đúng là trách nhiệm với máy tính. Giao tiếp đúng là trách nhiệm với con người. Trong kỷ nguyên AI, máy viết code ngày càng giỏi hơn bạn. Thứ duy nhất giữ giá trị của bạn lại chính là khả năng kết nối, thấu hiểu và giải quyết vấn đề cùng con đội nhóm. Hãy rèn luyện nó ngay hôm nay, bắt đầu từ việc nhắn tin Slack rõ ràng hơn.