[Góc Quản Trị] Nghệ Thuật Giải Quyết Bài Toán "Nhân Viên Chểnh Mảng": Khi Lead Dev Không Cần Dùng Đến "Thiết Quân Luật"

Trong hành trình chuyển giao từ một Developer giỏi chuyên môn sang vai trò Lead Dev, có một sự thật mà ai cũng phải thừa nhận: Đọc lỗi code thì dễ, nhưng "đọc lỗi" con người thì khó hơn gấp trăm lần.

1. Chuyển đổi tư duy: Quản trị Kết quả thay vì Quản lý Hành vi (Output over Micro-management)

Một trong những bài toán đau đầu nhất mà các Lead thường gặp phải là tình trạng nhân viên lơ là trong giờ làm việc: lướt điện thoại, ra ngoài ăn uống quá lâu, hay "ôm" task cao su. Phản xạ tự nhiên của nhiều quản lý mới là bực tức và dùng lời nói công kích cá nhân (kiểu như: "Sao dạo này em lười thế?", "Em làm việc thiếu chuyên nghiệp quá"). Tuy nhiên, cách làm này không những không giải quyết được vấn đề mà còn tạo ra tâm lý chống đối ngầm, phá vỡ sợi dây liên kết trong team.

Trước khi "bắt tội" một ai đó, hãy lùi lại một bước và nhìn vào bức tranh tổng thể. Sự chểnh mảng của họ có thực sự ảnh hưởng đến tiến độ dự án không?

• Có một thực tế là, những lập trình viên có năng lực tốt thường giải quyết task rất nhanh. Sự rảnh rỗi của họ đôi khi đến từ việc Lead chưa giao việc đúng tầm. Nếu họ lướt điện thoại nhưng vẫn hoàn thành xuất sắc công việc, điều bạn cần làm là đánh giá lại năng lực và mở rộng phạm vi công việc cho họ.
• Tuy nhiên, nếu hành vi lơ là đi kèm với việc trễ deadline, sinh ra nhiều bug, hoặc block tiến độ của người khác, thì đây là lúc bạn cần can thiệp một cách chuyên nghiệp.

2. Góp ý không gây tổn thương với mô hình SBI

Nguyên tắc tối thượng trong quản trị là: Khen ngợi công khai, góp ý riêng tư. Hãy thiết lập một buổi họp 1-on-1 (một đối một) và tuyệt đối tránh việc dán nhãn tính cách nhân viên. Thay vào đó, hãy dùng dữ liệu và mô hình SBI (Situation - Behavior - Impact) để phản hồi:

1. Situation (Tình huống): Chỉ ra bối cảnh cụ thể. ("Trong giai đoạn chạy nước rút của Sprint tuần này...")
2. Behavior (Hành vi): Mô tả hành vi một cách khách quan, không phán xét. ("Anh thấy em thường vắng mặt ở chỗ ngồi vào giữa giờ làm và tiến độ của module Payment đang bị chậm 2 ngày.")
3. Impact (Tác động): Giải thích hậu quả của hành vi đó lên tập thể. ("Việc này khiến team QA không có bản build để test đúng hạn, và các bạn khác phải OT để gánh phần việc tồn đọng.")

Bằng cách này, bạn đang tấn công vào "Vấn đề" chứ không phải "Con người". Nhân viên sẽ nhận ra mức độ nghiêm trọng của sự việc mà không cảm thấy lòng tự trọng bị xúc phạm.

3. Khám phá "Tảng băng chìm" qua việc Lắng nghe

Sau khi đưa ra nhận định, hãy biến cuộc trò chuyện thành một buổi gỡ rối. Hãy hỏi: "Em có đang gặp khó khăn gì cản trở công việc không? Anh có thể hỗ trợ gì để em tập trung và làm tốt hơn?"

Đằng sau thái độ chán nản thường có những "tảng băng chìm" mà nhìn qua code bạn không thể thấy:

• Họ đang bị kẹt ở một technical bug quá khó nhưng ngại hỏi (sợ bị đánh giá là kém).
• Họ cảm thấy công việc hiện tại quá lặp đi lặp lại và mất đi động lực (burnout).
• Họ đang gặp biến cố lớn trong gia đình dẫn đến mất tập trung.

Việc lắng nghe chân thành từ một người Lead không chỉ giúp tìm ra gốc rễ vấn đề, mà còn biến bạn từ một người "sếp hay soi mói" thành một người đồng hành đáng tin cậy.

4. Dùng hệ thống để tạo áp lực tích cực (Peer Pressure)

Cách tốt nhất để trị bệnh lười không phải là đi theo dõi từng người, mà là tạo ra một môi trường minh bạch nơi sự lười biếng không có chỗ để trốn.

• Minh bạch hóa trên bảng Jira/Trello: Trong các buổi Daily Scrum, hãy để tiến độ công việc nói lên tất cả. Ai đang làm tốt, ai đang giậm chân tại chỗ sẽ hiện rõ trên bảng trạng thái. Áp lực đồng trang lứa (Peer pressure) tự nhiên sẽ buộc những cá nhân chểnh mảng phải chấn chỉnh lại thái độ để không bị tụt lại phía sau.
• Thiết lập Definition of Done (Định nghĩa hoàn thành): Hãy làm rõ với team rằng, task chỉ được tính là "xong" khi đã code xong, test pass và merge thành công. Việc quản lý chặt chẽ đầu ra sẽ triệt tiêu tư duy "làm đối phó".

💡 Tạm kết

Quản lý con người chưa bao giờ là một bài toán có code mẫu (boilerplate) để copy-paste. Một Lead Dev giỏi là người biết dùng cái uy của kỷ luật để duy trì hệ thống, nhưng lại dùng cái tình của sự thấu hiểu để giữ chân nhân tài. Khi bạn xây dựng được một quy trình minh bạch và văn hóa tôn trọng lẫn nhau, các thành viên sẽ tự động "vào guồng" mà không cần đến bất kỳ lời nhắc nhở gay gắt nào.