Status report chạy được: RAG, tuần, một trang

Status report là artifact để stakeholder tin tưởng dự án mà không cần dự mọi cuộc họp. Làm tốt, một report tuần thay được mười tin nhắn DM ad-hoc và ba buổi "sync nhanh". Làm tệ, nó trở thành một cuốn sách trên kệ không ai đọc. Chương này giới thiệu format một trang và kỷ luật cần để giữ cho nó hữu dụng.

Khi nào status report viết bắt đầu trả lại giá trị?

Có ba tín hiệu chính.

Có hơn 5 stakeholder quan tâm. Dưới năm người, bạn có thể DM từng người. Trên năm, cùng một câu trả lời cần được gửi async cho nhiều người - bản đồ stakeholder ở chương 4 cho biết là ai.

Dự án dài hơn 6 tuần. Dưới mức đó, kickoff doc và nhịp demo là đủ phủ comms. Trên mức đó, status report tuần lộ ra trôi trượt sớm hơn các buổi demo.

Stakeholder không nằm trong nhịp ngày của bạn. Sponsor, team partner, customer success - những người không thấy standup hằng ngày. Status report là cửa sổ duy nhất họ có.

Nếu dự án ngắn, team nhỏ và hoàn toàn nội bộ, status tuần là gánh nặng. Một thread Slack là đủ.

Cái giá khi bỏ status hoặc làm status tệ là gì?

Có ba kiểu lỗi thường gặp.

Sponsor bị bất ngờ ở demo. "Tôi không hề biết các bạn trễ." PM nghĩ chuyện đó là hiển nhiên, nhưng không ai tài liệu hoá. Tin cậy mòn dần.

Quyết định kẹt ở standup. "Chúng tôi cần câu trả lời từ Legal" - được nêu trong standup, không bao giờ được escalate, và chặn cả team trong hai tuần. Phần "quyết định cần" trong status report là chỗ để bắt được tình huống đó.

Trôi status. Lúc nào cũng Xanh. Đến khi có gì sai, việc nhảy thẳng từ Xanh sang Đỏ là một cú sốc. Khi mức Vàng được dùng thật sự, đường trôi sẽ nhìn thấy được.

Một status report tối thiểu trông thế nào?

# Status: {{ Tên dự án }} — Tuần 2026-06-18

## Headline
🟡 **Vàng** — Luồng refund đúng tiến độ launch 8/7; trễ Stripe
SDK tạo rủi ro 1 tuần. Đang xử lý phương án giảm thiểu.

## Cái đã ship tuần này
- Nút refund live sau feature flag (100% nội bộ, 5% prod)
- Template email refund đã được Design và Legal duyệt
- API endpoint pass cổng hiệu năng ở 1K req/s

## Top 3 rủi ro
1. **Stripe SDK v3 release trượt sang 12/7** (Vàng)
   Owner: Bob. Giảm thiểu: build adapter trên v2; chuyển khi
   GA. Trạng thái: đã làm 60%.
2. **QA env flaky 2 ngày tuần trước** (Vàng)
   Owner: Carol cùng Infra. Giảm thiểu: pod test riêng ship
   thứ Tư. Trạng thái: theo dõi.
3. **Runbook customer support cần Legal ký** (Xanh)
   Owner: PM. Trạng thái: review đã lên lịch thứ Ba.

## Quyết định cần
- Xác nhận template comms launch trước thứ Tư
- Duyệt phân bổ Designer 50% cho launch QA tuần 1/7

## Tuần tới
- Ramp luồng refund tới 25% user
- Buổi training cho customer support
- Dry-run cuối cho quy trình rollback

---
Đúng tiến độ cho: launch 8/7
Tin cậy: 75% (tuần trước 85%)

Template dài dưới 1 trang là có chủ đích. Headline chính là pitch thang máy; nếu sponsor chỉ đọc đến đó rồi dừng, họ vẫn có câu trả lời mình cần.

Quy tắc quyết định RAG trông thế nào?

flowchart TB
    Q1{Có kịp ngày<br/>và scope đã cam kết?}
    Q1 -->|Có, không lo| Green[🟢 Xanh]
    Q1 -->|Có, có rủi ro đã nêu| Amber[🟡 Vàng]
    Q1 -->|Không, cần can thiệp| Red[🔴 Đỏ]
    style Green fill:#dcfce7
    style Amber fill:#fef3c7
    style Red fill:#fee2e2

Quyết định mang tính binary trên trục ngày + scope, nhưng có ba mức trên trục tin cậy. Xanh nghĩa là không cần xử lý gì lúc này; Vàng nghĩa là vấn đề đã được nêu cùng phương án giảm thiểu; Đỏ nghĩa là team không kịp target nếu không có giúp đỡ (thêm thời gian, bớt scope, hoặc thêm người).

Kỷ luật quan trọng: đừng bao giờ đi Xanh khi đáng lẽ phải là Vàng. Sai lầm phổ biến nhất là muốn "trông cho tốt" với Xanh rồi đến lúc launch lại đi giải thích vì sao ngày trượt.

Status report scale lên đa team như thế nào?

flowchart TB
    TeamA[Status Team A] --> Program[Status chương trình<br/>rollup 1 trang]
    TeamB[Status Team B] --> Program
    TeamC[Status Team C] --> Program
    Program --> Exec[Status cho lãnh đạo<br/>3 dòng]

Mỗi team gửi status riêng; program lead rollup thành một report chương trình dài một trang; sau đó nén lại còn 3 dòng cho buổi review tháng của lãnh đạo. Nén phải tàn nhẫn: lãnh đạo chỉ cần nhận RAG xấu nhất xuyên cả chương trình cộng top 3 rủi ro tổng.

Status report có thể tự tạo ra những lỗi nào?

• Luôn Xanh. RAG không bao giờ chuyển cho đến khi launch đã trượt. Cách phòng: định nghĩa trigger rõ ràng - trượt 1 ngày = Vàng, trượt 1 tuần = Đỏ. Ép thay đổi xảy ra.
• Cùng một bản boilerplate mỗi tuần. "Mọi thứ ổn, không có blocker." Không ai đọc sau tuần thứ 3. Cách phòng: yêu cầu ít nhất một fact mới mỗi tuần - hoặc dự án này không cần report.
• Status như danh sách điều ước. "Có lẽ ship trước 15/7" mà không có cơ sở. Cách phòng: mọi tuyên bố cần có nguồn - cột mốc ship, demo, hoặc metric.
• Rủi ro xoay vòng nhưng không giải quyết. Cùng top 3 rủi ro xuất hiện tuần này qua tuần khác mà không đóng. Cách phòng: mỗi rủi ro có owner + giảm thiểu + ngày hạn; nếu không có tiến triển trong 2 tuần, escalate.

Khi nào status report viết là quá liều?

Có hai trường hợp.

Team async-first với Slack công khai. Nếu mọi thứ đã ở trong channel công khai và sponsor đọc hằng ngày, report tuần sẽ trùng lặp. Hãy chuyển sang summary tháng.

Team công cụ nội bộ. Một team platform chạy continuous flow (Kanban) sẽ báo cáo throughput và cycle time theo tháng, chứ không phải status dự án theo tuần.

Một report đáng 30 phút công sức khi stakeholder không nằm trong channel ngày của bạn và dự án có end-state rõ ràng.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: decision log và ADR - artifact ghi lại vì sao dự án đưa ra các lựa chọn mà bạn nhìn thấy trong status report. Sau đó, các case study sẽ đưa mọi artifact bạn đã học vào hành động trên những hình dạng dự án thật.