[Tâm Sự Code] Kỹ năng làm việc nhóm: Làm sao để không trở thành "tội đồ" của team?

Chào anh em, sau một chuỗi bài hardcore "đấm nhau" với RAM, CPU, Multi-threading và Garbage Collection, hôm nay chúng ta sẽ tạm gác lại những dòng code khô khan để bàn về một thứ "mềm" hơn nhưng lại quyết định 50% sự sống còn của anh em trong nghề: Soft skills - Kỹ năng làm việc nhóm.

Nhiều anh em coder thuần (đặc biệt là mấy tay to kĩ thuật) thường có một ảo tưởng: "Tao code giỏi, tao fix bug nhanh là được, giao tiếp làm mẹ gì cho mất thời gian".

Nhưng thực tế vả vào mặt rất phũ phàng: Một thằng code giỏi nhưng "toxic" (độc hại) có thể phá nát tinh thần của cả một team. Hôm nay, dưới góc nhìn của một thằng Backend từng bị team chửi vì đổi API không báo trước, mình sẽ định nghĩa lại chữ "Làm việc nhóm" cho anh em IT. Nó không phải là rủ nhau đi nhậu hay "gọi dạ bảo vâng", mà là cách làm việc để không "bóp dái" đồng đội lúc 2 giờ sáng!

1. Giao tiếp bằng Document, không phải bằng... miệng

Một kịch bản kinh điển ở mọi công ty:

• Frontend: "Ê backend, cái API login mầy trả về user_id hay userId vậy?"
• Backend: "user_id nhé bro!"
• Hôm sau đổi requirement, Backend âm thầm đổi thành id cho nó gọn. Tối hôm đó deploy, Frontend oẳng, app crash tung tóe.

Làm việc nhóm với tư duy của một kĩ sư giỏi là bảo vệ cái "Contract" (Giao kèo) giữa các team. Đừng bao giờ giao tiếp API bằng miệng hay ném qua tin nhắn Slack. Hãy dùng Swagger, Postman, hay bất kì tool document nào. Khi bạn sửa một field, đổi kiểu dữ liệu từ int sang string, việc đầu tiên là update Document và tag những người liên quan vào.

Tôn trọng thời gian của Frontend và Tester chính là đỉnh cao của làm việc nhóm!

2. Nghệ thuật Code Review: Hãy "chửi" code, đừng "chửi" người

Mỗi khi bạn tạo một Pull Request (PR), team sẽ vào soi code của bạn. Đây là lúc dễ xảy ra xích mích nhất.

• Junior xem PR: Thấy code lởm nhưng sợ mất lòng, nhắm mắt comment "LGTM - Looks Good To Me" (Code ngon) rồi Approve. Hậu quả: Bug trôi thẳng lên Production.
• Senior toxic xem PR: "Mày viết cái đống rác rưởi gì đây? Về học lại cơ bản đi!". Hậu quả: Junior thù hằn, nhụt chí, team chia rẽ.

Người làm việc nhóm xịn sẽ review code thế này:

Thay vì nói "Hàm này viết ngu quá", hãy nói: "Hàm này anh thấy độ phức tạp đang là O(n^2), nếu data lên 1 triệu dòng thì có thể gây nghẽn RAM. Em xem xét dùng HashMap để tối ưu xuống O(1) thử xem nhé." Tách bạch rõ ràng: Mục tiêu của chúng ta là làm cho Source Code tốt lên, chứ không phải dìm hàng người viết ra nó.

3. Quản lý Source Code: Đừng cậy "bố đời" mà git push -f

Làm việc nhóm thể hiện rõ nhất qua cách anh em dùng Git.

• Đang làm feature A, kẹt logic, sang nhánh dev pull code mới về rồi push đè lên luôn (Force push) làm bay màu code của thằng ngồi bên cạnh.
• Commit message thì viết kiểu: "fix bug", "update", "done", "asdasdasd". Nửa năm sau server sập, check lại lịch sử Git không ai biết cái commit đó sửa cái gì để mà rollback.

Một người đồng đội tốt là người biết chia nhánh (Branching), biết viết Commit Message rõ ràng (VD: fix(auth): xử lý lỗi sai múi giờ khi user đăng nhập), và tuyệt đối không bao giờ force push lên các nhánh chung như develop hay main.

4. Thái độ khi hệ thống sập: Blame Culture vs Post-Mortem

Đây là lúc "nhân cách" làm việc nhóm lộ diện rõ nhất. Khi một con bug lọt lên Production làm thất thoát tiền của công ty, team sẽ chia làm 2 loại:

• Loại "Blame Culture" (Văn hóa đổ lỗi): "Hôm qua thằng nào merge cái PR này?"
• "Tại thằng Tester không test kĩ!"
• "Tại BA viết spec không rõ ràng!"
• -> Cãi nhau cả ngày, bug vẫn nằm đó, sếp đuổi việc cả đám.
• Loại "Post-Mortem" (Khám nghiệm tử thi):
• Tất cả xúm lại, người check log, người rollback code, ưu tiên Cứu Hệ Thống Trước. Sau khi sóng gió qua đi, team ngồi lại họp. Nhưng câu hỏi không phải là "Lỗi tại ai?" mà là:
• "Tại sao quy trình CI/CD của chúng ta lại để lọt con bug này?"
• "Làm sao để việt khóa Unit Test chạy tự động chặn đứng lỗi này vào ngày mai?"
• Nhớ kĩ: Khi hệ thống lỗi, đó là lỗi của Hệ thống và Quy trình, không phải lỗi của một cá nhân. Nếu một thằng Junior có thể làm sập cả Database Production, thì lỗi lớn nhất thuộc về thằng Senior đã cấp quyền cho nó!

Tổng kết

Tóm lại, Teamwork của anh em IT chính là tính Kỷ Luật. Bạn viết code dễ đọc cho người đi sau maintain, bạn viết document rõ ràng cho Frontend đỡ cực, bạn review code có tâm để team cùng tiến bộ. Làm được những điều đó, dù bạn không phải người code giỏi nhất, bạn vẫn luôn là "hòn đá tảng" mà mọi công ty đều săn đón.

Hành trình từ kĩ thuật cứng đến kĩ năng mềm chúng ta đều đã lướt qua. Ở bài viết tới, mình muốn đưa anh em vào một "chiến trường" thực sự, nơi tổng hòa cả kĩ thuật (Hard) và tâm lý (Soft).

Hãy tưởng tượng: Đêm thứ 6, anh em đang nhâm nhi cốc bia thì điện thoại reo: "Hệ thống sập rồi, user không vào được app!". Anh em sẽ làm gì đầu tiên?

👉 Bài sau: Bí kíp sinh tồn khi Production Incident - Kịch bản xử lý khủng hoảng từ số 0.

Anh em thấy góc nhìn về Soft Skills này thế nào? Để lại comment chém gió bên dưới nhé! Đừng quên upvote nếu thấy bài viết chạm đúng "nỗi đau" của team anh em!