Một status report tốt giúp người đọc nắm trong 30 giây: dự án đang ổn hay không, vì sao, và stakeholder cần làm gì. Phần chi tiết để sau.
Cấu trúc thường dùng:
- Trạng thái tổng (RAG) — Green: đúng kế hoạch; Amber: có rủi ro nhưng đang kiểm soát; Red: sẽ trễ mốc hoặc vượt ngân sách nếu không có quyết định.
- Tiến độ theo milestone — mốc nào đã xong, mốc sắp tới, % hoàn thành tính theo phạm vi chứ không theo cảm giác.
- Việc tuần này và tuần sau — 3–5 dòng, không liệt kê toàn bộ ticket.
- Rủi ro và issue chính — kèm owner và hành động đang làm.
- Cần quyết định hoặc hỗ trợ — mục quan trọng nhất: ai cần quyết điều gì, hạn khi nào.
- Chỉ số — effort thực tế so với kế hoạch, số bug đang mở theo mức độ, burnup nếu stakeholder quen đọc.
Nguyên tắc:
- Viết theo người đọc: lãnh đạo cần một trang; khách hàng kỹ thuật có thể cần thêm chi tiết.
- Trạng thái phải trung thực. Báo Green nhiều tuần rồi nhảy thẳng sang Red là dấu hiệu tin xấu bị giữ lại; kiểu báo cáo này hay được gọi là "watermelon report" (ngoài xanh, trong đỏ).
- Giữ định dạng cố định mỗi tuần để người đọc so được xu hướng.
Lưu ý: status report không thay cho việc báo ngay khi có sự cố lớn. Rủi ro chuyển thành issue nghiêm trọng vào thứ Ba thì gọi hoặc nhắn stakeholder ngay, không đợi báo cáo thứ Sáu.