Cứu dự án sắp đổ: 30 ngày đầu

Dự án khó nhất mà một tech lead có thể kế thừa là dự án đã sắp đổ vào lúc họ nhận. Team kiệt sức, stakeholder mất niềm tin, và plan gốc đã trở thành hư cấu. Case study này đi qua plan cứu 30 ngày - đây cũng là chỗ các chương trước đó của series gộp lại khi áp dụng cùng lúc.

Khi nào một dự án thật sự cần cứu?

Có ba tín hiệu cần xuất hiện cùng lúc, mỗi cái đến từ một chương trước.

Status kẹt đỏ. Status report ở mức amber hoặc đỏ từ 3 tuần trở lên mà không có plan phục hồi. Trend mới là data; một tuần xấu vẫn là bình thường.

Ngày trượt theo cấp số. Commit gốc là 3 tháng; ETA hiện tại là 6+ tháng; ETA mới lại xuất hiện sau mỗi sprint. Ước lượng đã vỡ; cần re-plan.

Tinh thần team rõ giảm. Engineer im trong retro, 1-on-1 cho thấy dấu hiệu burnout, có rủi ro nghỉ việc trong team. Anh hùng không bền được lâu.

Nếu chỉ có một tín hiệu, vệ sinh dự án bình thường là đủ fix. Cả ba cùng lúc thì rơi vào phạm vi cần cứu.

Cái giá khi để dự án sắp đổ trôi tiếp là gì?

Có ba kiểu hệ luỵ còn tệ hơn cả việc cứu.

Sập tin cậy. Stakeholder dừng dự buổi demo vì không còn tin ngày nữa. Phục hồi tin cậy tốn thêm 6+ tháng kể cả sau khi dự án đã ship.

Engineer rời đi. Engineer mạnh nhất rời trước, vì họ có lựa chọn. Đến lúc lãnh đạo nhận ra, team đã thiếu đúng những người đáng lẽ cứu được.

Bẫy chi phí chìm. "Chúng ta đã 70% xong" trên một dự án còn một năm nữa. Cuộc trò chuyện cứu là chỗ lộ ra liệu nên xong, descope, hay giết. Không có nó, dự án sẽ kéo mãi.

Playbook cứu 30 ngày trông thế nào?

gantt
    title Plan Cứu 30 Ngày
    dateFormat YYYY-MM-DD
    section Tuần 1 Chẩn đoán
    Phỏng vấn stakeholder           :a1, 2026-06-20, 4d
    Review RAID                     :a2, 2026-06-22, 3d
    1-on-1 team                     :a3, 2026-06-20, 5d
    Doc chẩn đoán                   :a4, after a3, 2d
    section Tuần 2 Plan
    Workshop cắt scope              :b1, 2026-06-29, 3d
    Re-baseline với sponsor         :b2, after b1, 2d
    section Tuần 3 Ổn định
    Cài daily standup               :c1, 2026-07-06, 1d
    Cài status tuần                 :c2, 2026-07-06, 1d
    Ship win nhìn thấy được         :c3, 2026-07-09, 4d
    section Tuần 4 Reset
    Retro nhịp bình thường đầu      :d1, 2026-07-17, 1d
    Review sponsor                  :d2, after d1, 1d
    Trao lại tay lái                :d3, after d2, 1d

Bốn tuần, bốn phase. Chẩn đoán trước khi làm bất kỳ điều gì; re-plan với buy-in từ stakeholder; ổn định nhịp; rồi trao dự án trở lại nhịp khoẻ. Cứu kết thúc khi nhịp bình thường đã bền - không phải khi dự án ship.

Tuần 1 (chẩn đoán) trông thế nào trong artifact?

# Dự án {{ Tên }} — Chẩn đoán

## Tóm tắt stakeholder (từ phỏng vấn)
- Sponsor: muốn X vào Y; sẵn linh hoạt scope, không linh hoạt ngày
- Tech Lead: ước lượng sai; dependency Z bị trượt
- 3 engineer: tinh thần thấp; scope bị thêm giữa sprint; retro
  không có action item

## Trạng thái hiện tại
- Item Must gốc: 12; ship: 4; đang làm: 5; chưa bắt đầu: 3
- Ngày gốc: 2026-08-15; xu hướng hiện tại: 2026-12-01
- Top blocker: SDK vendor, capacity infra, lag design

## Highlight RAID
- 8 rủi ro mở, 3 issue, 2 dependency đang chặn
- 6 rủi ro đã hơn 30 ngày không cập nhật
- Không theo dõi giảm thiểu cho 4 trong 3 issue

## Quan sát team
- Standup chạy 45 phút, không tập trung
- Không có buổi retro nào trong 6 tuần qua
- Queue review pull request trung bình 5 ngày
- 2 engineer làm cuối tuần liên tục 3 sprint qua

## Chẩn đoán
Dự án thất bại vì (a) scope gốc vượt capacity 2 lần, (b) các
nhịp đã mục, (c) báo cáo cho stakeholder mang tính phòng thủ.

## Đề xuất
Cắt scope còn 6 Must, re-baseline ngày sang 2026-09-30, khởi
động lại kỷ luật standup/retro/status, ship một win nhìn thấy
được trong tuần 3 để xây lại tin cậy.

Bản chẩn đoán là artifact cho cuộc trò chuyện tuần 2 với sponsor. Không có nó, cuộc trò chuyện cứu chỉ là ý kiến; có nó, là data.

Cắt scope cho cứu trông thế nào?

Áp khung MoSCoW một cách tàn nhẫn:

# Cắt Scope Cứu — Dự án {{ Tên }}

## Must gốc (12 item)

| Item | Trạng thái | Quyết định | Lý do |
|------|------------|-----------|-------|
| Luồng refund | 80% | GIỮ MUST | Đã hứa với khách |
| Đa tiền tệ | 0% | HOÃN sang Q4 | Không khách hỏi |
| Subscription billing | 30% | HOÃN sang Q4 | Lớn hơn ước lượng |
| Admin audit log | 60% | GIỮ MUST | Tuân thủ |
| Stripe webhook idempotency | 100% | GIỮ MUST | Đã xong |
| Runbook customer support | 0% | HOÃN 2 tuần | Nhanh, làm sau |
| Dashboard hiệu năng | 0% | HOÃN sang Q4 | Chỉ nội bộ |
| ... | | | |

## Danh sách Must mới (6 item)
[các item giữ ở trên]

## Ngày mới
2026-09-30 (cũ 2026-08-15; +6 tuần)

## Cái sponsor cần duyệt
- Trượt ngày 6 tuần
- Giảm scope (6 item hoãn)
- Không thêm scope mới trong giai đoạn cứu

## Comms
- Sales: comms launch chỉnh; không công bố ngày cho đến khi
  sponsor duyệt
- Customer success: luồng refund vẫn hứa vào ngày X
- Team Eng: mục tiêu tập trung trong 6 tuần kế tiếp

Đây là một trade-off trung thực: 6 item bị hoãn để mua lại 6 tuần. Sponsor hoặc ký vào trade-off đó, hoặc dự án không có đường đi tiếp.

Tuần 3-4 cài lại kỷ luật ra sao?

flowchart LR
    Day0[Tuần 3 Ngày 0] --> Standup[Daily standup<br/>15 phút, focus blocker]
    Standup --> Status[Status thứ Sáu<br/>RAG, top 3 rủi ro]
    Status --> Retro[Retrospective tuần 4<br/>không đổ lỗi, action item]
    Retro --> Win[Ship win nhìn thấy<br/>nút refund live]
    Win --> Sponsor[Review sponsor<br/>handover]

Kỷ luật ở đây có nghĩa là các artifact từ chương lifecycle chạy đúng giờ. Cứu kết thúc khi team duy trì được standup, status report, và retro mà không cần người cứu dẫn dắt.

Cứu dự án có thể tự tạo ra những lỗi nào?

• Người cứu hoá anh hùng. PM làm 60 giờ/tuần trong giai đoạn cứu. Cách phòng: plan cứu phải bền từ ngày 1; nếu yêu cầu người cứu burnout, đó không phải plan.
• Cắt scope sau bị đảo. Sponsor đồng ý cắt, rồi tuần sau lại hỏi item về. Cách phòng: thoả thuận phải viết ra; muốn đảo cần cùng cuộc trò chuyện như khi cắt.
• Bất định trong team. Engineer không biết cứu đã thành công hay vẫn đang thất bại. Cách phòng: có cột mốc reset rõ ràng (tuần 4) - nơi cứu được tuyên bố hoàn tất và nhịp bình thường resume.
• Mode cứu vĩnh viễn. Dự án không bao giờ rời được giai đoạn cứu. Cách phòng: timeline 30 ngày; nếu không ổn được đến đó, dự án nên bị giết, không phải cứu mãi.

Khi nào cứu không phải câu trả lời đúng?

Có hai trường hợp.

Dự án nên bị giết. Đôi khi chẩn đoán lộ ra rằng dự án không còn giá trị nghiệp vụ, hoặc khối việc còn lại đã vượt quá đầu tư hợp lý. Câu trả lời trung thực là đề xuất giết, không phải cứu. Chi phí đã chìm rồi.

Team gốc cần đổi lãnh đạo. Đôi khi vấn đề nằm ở manager, không ở dự án. PM cứu không fix được tình huống này; cần partner HR đi cùng.

Playbook cứu áp dụng được khi dự án vẫn cứu được bằng kỷ luật và cắt scope. Dưới ngưỡng đó, cần can thiệp khác.

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

Case study tiếp theo: greenfield MVP launch - hình ngược lại, một dự án hoàn toàn mới không gánh nặng cũ. Sau đó, hiện đại hoá legacy và dự án quản vendor hoàn tất nhóm case study.