Giao tiếp: Kỹ năng sinh tồn của Senior Developer

Có một nghịch lý phổ biến trong ngành phần mềm: Khi bạn là Junior (mới vào nghề), 90% thời gian của bạn dành cho việc viết code (coding). Nhưng khi bạn trở thành Senior (lâu năm), tỷ lệ đó đảo ngược hoàn toàn. Bạn chỉ còn code khoảng 20-30%, phần lớn thời gian còn lại là họp hành, review code, hướng dẫn đàn em (mentoring) và giải thích giải pháp cho sếp hoặc khách hàng. Lúc này, kỹ năng quyết định mức lương của bạn không còn nằm ở việc bạn gõ phím nhanh bao nhiêu, mà là bạn giao tiếp hiệu quả đến mức nào.

Rất nhiều lập trình viên giỏi kỹ thuật (Technical skills) bị kẹt mãi ở mức lương trung bình hoặc không thể lên chức Leader/Manager chỉ vì họ thiếu kỹ năng giao tiếp. Họ là những "ngôi sao cô đơn" (lone wolves), làm việc rất tốt một mình nhưng lại là thảm họa khi làm việc nhóm.

1. Tại sao Code giỏi là chưa đủ?

Phần mềm ngày nay quá phức tạp để một người có thể xây dựng toàn bộ. Chúng ta làm việc theo team (nhóm). Giao tiếp chính là "chất bôi trơn" giúp cỗ máy team vận hành trơn tru.

• Tránh làm sai yêu cầu: Một Dev giỏi giao tiếp sẽ hỏi kỹ PM (Product Manager) và Designer để hiểu rõ nghiệp vụ (Business logic) trước khi bắt tay vào code. Ngược lại, Dev kém giao tiếp sẽ lẳng lặng code theo ý hiểu của mình, để rồi 2 tuần sau phải đập đi làm lại vì... hiểu sai ý sếp.
• Giải quyết xung đột (Conflict): Trong code review, tranh cãi là chuyện thường tình. Người giao tiếp kém sẽ biến cuộc tranh luận kỹ thuật thành cuộc công kích cá nhân ("Code của mày rác quá!"). Người giao tiếp giỏi sẽ đưa ra góp ý mang tính xây dựng ("Đoạn này logic hơi phức tạp, mình nghĩ dùng Strategy Pattern sẽ dễ bảo trì hơn, bạn thấy sao?").

2. Kỹ năng "Phiên dịch" cho người ngoại đạo

Đây là kỹ năng phân biệt giữa Senior và Junior. Khách hàng, Sếp kinh doanh hay Marketing không hiểu về "Microservices", "Docker" hay "Memory Leak". Họ chỉ quan tâm đến: "Tại sao web chậm?", "Bao giờ xong tính năng này?", "Tại sao tốn nhiều tiền server thế?".

Nhiệm vụ của bạn là phải "phiên dịch" các vấn đề kỹ thuật phức tạp sang ngôn ngữ đời thường mà họ hiểu được. Ví dụ:

• Thay vì nói: "Database bị deadlock do race condition khi nhiều transaction ghi cùng lúc." (Khách hàng nghe xong ngất xỉu).
• Hãy nói: "Hệ thống đang bị tắc nghẽn giống như ngã tư đường giờ cao điểm. Chúng tôi cần phân luồng lại để xe chạy thông thoáng hơn." (Khách hàng gật gù hiểu ngay).

3. Lắng nghe chủ động (Active Listening)

Giao tiếp không chỉ là nói, mà còn là nghe. Nhiều Dev mắc bệnh "cái tôi lớn" (Ego), luôn cho rằng giải pháp của mình là nhất và gạt phăng ý kiến người khác. Lắng nghe chủ động là khi bạn thực sự tập trung vào những gì người khác nói, không ngắt lời, và đặt câu hỏi để làm rõ vấn đề.

Khi bạn lắng nghe, bạn học được từ đồng nghiệp. Khi bạn lắng nghe khách hàng, bạn hiểu nỗi đau (pain point) của họ. Một giải pháp kỹ thuật hoàn hảo nhưng không giải quyết được nỗi đau của khách hàng thì cũng vứt đi.

4. Viết tài liệu (Documentation)

Giao tiếp không chỉ bằng lời nói (Verbal), mà còn bằng văn bản (Written). Code là để cho máy chạy, còn Document là để cho người đọc. Một dự án không có tài liệu giống như một mê cung không bản đồ. Khi bạn nghỉ việc, người vào sau sẽ nguyền rủa bạn nếu bạn để lại một đống code rối rắm mà không có một dòng chú thích nào.

Kỹ năng viết email, viết báo cáo tiến độ (Daily Report), viết mô tả Pull Request (PR) rõ ràng, mạch lạc là những điểm cộng cực lớn trong mắt sếp.

Kết luận

Đừng để định kiến "Dân IT lầm lì, ít nói" kìm hãm sự nghiệp của bạn. Hãy bước ra khỏi vùng an toàn (Comfort Zone), tập thuyết trình trước đám đông, tập viết blog chia sẻ kiến thức, tập cafe chém gió với anh em Sales/Marketing. Khi kỹ năng mềm của bạn tiệm cận với kỹ năng cứng, đó là lúc bạn trở thành một Tech Lead thực thụ mà bất kỳ công ty nào cũng săn đón.