Sức khoẻ đội ngũ · Project Handbook

Vì sao đây là mục quản trị rủi ro

Mọi rủi ro khác trong sổ tay này đều có cách chặn bằng máy: quality gate chặn code xấu, cảnh báo chặn sự cố lan rộng, feature flag chặn thiệt hại.

Rủi ro kiệt sức thì không. Nó tích luỹ âm thầm, và khi nó nổ thì mất hàng tháng để hồi phục — người giỏi nghỉ việc, tri thức đi theo, người mới mất một quý để vào guồng. Không có sự cố kỹ thuật nào tốn kém bằng.

Và nó ăn thẳng vào chất lượng trước khi ăn vào con người: đội mệt là đội bỏ qua test, duyệt PR cho nhanh, và không buồn hỏi lại khi yêu cầu mơ hồ. Toàn bộ phần shift left trong sổ tay này chạy bằng sự tỉnh táo của con người.

Dấu hiệu sớm, quan sát được

Dấu hiệu	Nhìn ở đâu	Nghĩa là gì
PR được duyệt trong vài phút, không có nhận xét	Lịch sử PR	Không ai còn sức đọc kỹ
Test bị bỏ qua hoặc tắt ngày càng nhiều	Pipeline	Đang cắt chất lượng để kịp hạn
Commit sau 22 giờ, và cuối tuần	Lịch sử git	Làm ngoài giờ đã thành thường lệ
Cùng một người luôn xử lý sự cố	Sổ sự cố	Tri thức dồn vào một chỗ, người đó sắp gãy
Buổi cải tiến không ai nói gì	Biên bản	Đã hết tin là nói sẽ thay đổi được gì
Không ai nghỉ phép trong quý	Bảng chấm công	Dấu hiệu xấu, không phải dấu hiệu tốt
Nghỉ việc đột ngột	—	Đã muộn

Sáu dòng đầu là dấu hiệu để hành động. Dòng cuối là hậu quả.

Luật cứng

Không có văn hoá làm đêm. Việc gấp có thể có, nhưng gấp liên tục quá hai tuần nghĩa là kế hoạch sai, không phải người làm chậm.
Chỉ cam kết 70% sức chứa. Xem ưu tiên công việc. Đội chạy 100% thì không còn chỗ cho việc phát sinh, và việc phát sinh luôn có.
Người trực không nhận việc phát triển trong tuần trực. Trực là một công việc thật, không phải phần cộng thêm.
Trực ngoài giờ được bù nghỉ. Không bù thì sau ba tháng sẽ không còn ai nhận trực.
Nghỉ phép được duyệt, không bị hỏi khó. Một đội mà người nghỉ phép làm dự án đứng lại là một đội đang có lỗi thiết kế, không phải một đội chăm chỉ.
Không đổ lỗi cá nhân khi có sự cố. Xem phần không truy trách nhiệm trong xử lý sự cố.
Mỗi phần việc có ít nhất hai người hiểu. Một người duy nhất biết một module là rủi ro cho cả dự án và là gánh nặng cho chính người đó.

Chống dồn tri thức vào một người

Cách làm	Nhịp
Luân phiên người review giữa các module	Liên tục
Mỗi module có người phụ, thay được người chính	Ghi rõ trong bảng vai trò
Lập trình cặp khi làm phần khó hoặc phần lạ	Khi cần
Buổi chia sẻ 30 phút về một phần hệ thống	Hai tuần một lần
Ghi quyết định kỹ thuật	Xem cách ra quyết định

Phép thử: người chủ chốt nghỉ một tuần không báo trước, dự án có chạy tiếp được không? Trả lời "không" thì đó là rủi ro phải xử lý ngay, xếp ngang với nợ kỹ thuật nặng.

Việc nhàm và việc khó, chia cho công bằng

Mọi dự án đều có việc không ai thích: sửa bug cũ, dọn nợ kỹ thuật, viết tài liệu, trực, xử lý phiếu hỗ trợ.

Để một người gánh hết phần việc nhàm trong khi người khác luôn làm tính năng mới là cách chắc chắn nhất để mất người đó. Luân phiên có lịch, công khai, và ghi nhận việc nhàm ngang với việc mới trong lúc đánh giá.

Buổi một-một

Hai tuần một lần, 30 phút, giữa mỗi người và quản lý trực tiếp. Đây không phải buổi báo cáo tiến độ — tiến độ đã có ở chỗ khác.

Bốn câu hỏi:

Tuần vừa rồi việc gì làm em mất nhiều thời gian nhất mà đáng lẽ không cần?
Có gì đang chặn em mà em chưa nói ra?
Em muốn làm gì nhiều hơn, và ít hơn?
Em có đang phải làm ngoài giờ không, vì sao?

Điều kiện để buổi này có giá trị: những gì nói ra phải dẫn tới thay đổi thật, ít nhất đôi khi. Ba lần nói mà không thấy gì đổi thì lần thứ tư sẽ chỉ nhận được "em ổn".

Đo bằng số, nhưng cẩn thận

Ba con số nên theo dõi, đọc theo xu hướng chứ không theo điểm:

Chỉ số	Lấy ở đâu	Ngưỡng đáng lo
Tỷ lệ commit ngoài giờ hành chính	Lịch sử git	Vượt 15% và đang tăng
Số ngày phép chưa dùng	Bảng chấm công	Tăng đều qua các quý
Số việc chen ngang mỗi sprint	Bảng công việc	Vượt 20% sức chứa

Không dùng ba con số này để đánh giá cá nhân. Dùng để đánh giá cách tổ chức công việc. Người làm đêm nhiều không phải người chăm — thường là người đang bị giao quá tay, hoặc là người duy nhất biết làm một việc.

Khi đội đã mệt rồi

Không chữa được bằng một buổi ăn tối hay một lời cảm ơn. Cách chữa duy nhất là giảm tải thật:

Cắt phạm vi của sprint đang chạy, công khai, không âm thầm.
Dừng nhận việc mới trong ít nhất một sprint.
Dành một sprint cho nợ kỹ thuật và các việc đội tự chọn — thứ họ vẫn muốn sửa mà không bao giờ được ưu tiên.
Tìm và gỡ nguyên nhân gốc: hạn chót phi thực tế, quá nhiều việc chen ngang, hay thiếu người ở một vị trí then chốt.

Bỏ qua bước 4 thì ba bước đầu chỉ mua được vài tuần.