Chạy dự án: checklist tech PM đầy đủ
Checklist hub gắn mọi artifact trong series với nhau. Dùng để khởi đầu dự án, audit dự án giữa chừng, hoặc chuẩn bị handover.
Mục lục
Chương này là index của cả series. Mọi artifact bạn đã đọc đều map ở đây theo phase, kèm một dòng check và link đến chương định nghĩa. Danh sách này chạy theo ba cách: khởi đầu dự án đúng, audit dự án rắc rối, và để dự án sạch sẽ cho owner kế tiếp.
Khi nào checklist đầy đủ là quan trọng?
Có ba tín hiệu.
Khởi đầu dự án. Đi xuống danh sách lúc kickoff đảm bảo không artifact nền tảng nào bị bỏ sót.
Dự án bắt đầu căng thẳng. Khi schedule trượt hoặc niềm tin bào mòn, checklist lộ ra những artifact đang thiếu - thường là status report hoặc theo dõi rủi ro.
Handover hoặc audit. Khi dự án đổi tay hoặc có peer review, mỗi item chưa tick là một câu hỏi cần xử lý.
Cho một hack 1 tuần nội bộ, checklist đầy đủ là quá liều. Còn cho bất cứ thứ gì dài hơn, nó là một check trọng lực.
Cái giá khi bỏ audit là gì?
Có hai kịch bản.
Không có checklist giữa dự án. Team nghĩ mọi thứ đã có; thực ra không có decision log, risk register cũ 6 tuần, kickoff doc chưa bao giờ được cập nhật. Mỗi gap như vậy sẽ tốn thêm giờ về sau.
Handover không có checklist. Owner mới kế thừa một dự án mà gap artifact vô hình. Họ phát hiện ra từng mảnh thiếu mỗi tuần, và dự án bị regress mất một quý.
Checklist đầy đủ trông thế nào?
# Checklist Dự Án Tech PM
## Foundations (dựng lúc kickoff)
- [ ] Doc vai trò + RACI cho các quyết định lớn ([chương 1](/tech-pm/pm-vs-em-vs-tpm))
- [ ] Khoảng ước lượng có niềm tin ([chương 2](/tech-pm/estimation-fundamentals))
- [ ] RAID log với nhịp review tuần ([chương 3](/tech-pm/risk-and-issue-tracking))
- [ ] Bản đồ stakeholder và comms plan ([chương 4](/tech-pm/stakeholders-and-comms))
- [ ] Scope cố định với MoSCoW ([chương 5](/tech-pm/scope-and-tradeoffs))
## Methodology (chọn một, tài liệu hoá)
- [ ] Phương pháp đã chọn kèm lý do ([chương 8](/tech-pm/method-selection))
- [ ] Nhịp Sprint hoặc Kanban đã dựng ([chương 6](/tech-pm/scrum-essentials), [chương 7](/tech-pm/kanban-flow))
## Lifecycle (chạy trong dự án)
- [ ] Kickoff doc có sponsor ký ([chương 9](/tech-pm/discovery-and-kickoff))
- [ ] Roadmap (Now/Next/Later) đã đăng ([chương 10](/tech-pm/planning-and-roadmap))
- [ ] Daily standup kèm danh sách blocker ([chương 11](/tech-pm/sprint-execution))
- [ ] Checklist launch + plan rollback ([chương 12](/tech-pm/launch-and-handover))
- [ ] Runbook sự cố do ops sở hữu ([chương 13](/tech-pm/incident-and-rollback))
- [ ] Retrospective sau mỗi sprint ([chương 14](/tech-pm/retrospective-and-post-mortem))
## People (liên tục)
- [ ] 1-on-1 hàng tuần với mọi report ([chương 15](/tech-pm/one-on-ones))
- [ ] Loop tuyển tài liệu hoá; plan onboard cho mỗi nhân viên ([chương 16](/tech-pm/hiring-and-onboarding))
- [ ] Feedback hiệu suất trong 48h sau hành vi ([chương 17](/tech-pm/performance-and-feedback))
## Artifact (chạy đều, cập nhật đều)
- [ ] Status report tuần (RAG) đã gửi ([chương 18](/tech-pm/status-reports-that-work))
- [ ] ADR cho lựa chọn kiến trúc lớn ([chương 19](/tech-pm/decision-logs-and-adrs))
- [ ] Decision log cho lựa chọn không kiến trúc ([chương 19](/tech-pm/decision-logs-and-adrs))
## Hình dạng dự án (dùng case study phù hợp)
- [ ] Nếu cứu: plan cứu 30 ngày ([chương 20](/tech-pm/rescue-a-failing-project))
- [ ] Nếu MVP: timeline 12 tuần + giả thuyết ([chương 21](/tech-pm/greenfield-mvp-launch))
- [ ] Nếu hiện đại hoá: plan migration Strangler Fig ([chương 22](/tech-pm/legacy-modernisation))
- [ ] Nếu quản vendor: phase hợp đồng + tiêu chí chấp nhận ([chương 23](/tech-pm/vendor-managed-project))
## Đóng (đừng bỏ qua)
- [ ] Post-mortem viết nếu có sự cố P1/P2
- [ ] Doc handover hoàn tất và đã ký
- [ ] Bài học thêm vào [reference class](/tech-pm/estimation-fundamentals) của team
- [ ] Channel dự án archive; quyền sở hữu rõ ở production
Scale theo hình dạng dự án như thế nào?
flowchart TB
Start[Dự án khởi đầu?] --> Choice{Case nào?}
Choice -->|Hoàn toàn mới| MVP[Dùng case MVP 21<br/>timeline 12 tuần]
Choice -->|Thừa kế đổ vỡ| Rescue[Dùng case cứu 20<br/>plan 30 ngày]
Choice -->|Cũ sang mới| Legacy[Dùng case legacy 22<br/>strangler fig]
Choice -->|Team ngoài| Vendor[Dùng case vendor 23<br/>phase hợp đồng]
Choice -->|Dự án chuẩn| Standard[Dùng Foundations + Lifecycle<br/>chương 1-14]
MVP --> Common[Mọi hình chia<br/>nền artifact chung]
Rescue --> Common
Legacy --> Common
Vendor --> Common
Standard --> Common
Case study cho bạn hình; nền artifact thì phổ quát. Hãy chọn case phù hợp; rồi xếp lên nền.
Dùng checklist như một audit trông thế nào?
Walkthrough 30 phút cùng project lead:
# Audit Dự án — {{ Dự án }} — 2026-06-24
## Foundations (5 item)
- [x] Doc vai trò - cập nhật
- [x] Ước lượng - có, lần cập nhật cuối 6 tuần trước (đã cũ)
- [ ] RAID log - thiếu! Dự án đã chạy 3 tháng mà không có
- [x] Bản đồ stakeholder - có
- [x] Scope MoSCoW - có, nhưng 'Won't' đã bị vi phạm hai lần
## Đề xuất (top 3)
1. Dựng RAID log trong tuần này; review với team
2. Refresh ước lượng; đối soát với budget gốc
3. Re-xác nhận scope với sponsor; nêu lại danh sách Won't
## Mức rủi ro: Vàng
Dự án vẫn chạy được nhưng thiếu artifact để bắt vấn đề sớm.
Không có RAID và status report, bất ngờ là khả năng cao.
Bản audit là format artifact; chính cuộc trò chuyện mới quan trọng. Phần lớn dự án thật ra đã có phần lớn thứ; audit chỉ lộ ra 2-3 gap cần chú ý.
Dùng checklist có thể tự tạo ra những lỗi nào?
- Kịch tick. Mọi item đều tick nhưng artifact là sách trên kệ. Cách phòng: mỗi tick cần bằng chứng (link, ngày gần đây, owner cụ thể).
- Áp dụng kiểu cargo cult. Áp 30+ artifact cùng lúc; team kháng cự. Cách phòng: giới thiệu từng cái một, sau khi đã có nỗi đau cho lý do.
- Che lấp gap lãnh đạo. Checklist tồn tại, item được tick, nhưng team đang rối loạn. Cách phòng: artifact lộ rối loạn, không fix nó. Hãy dùng 1-on-1 và retro để xử vấn đề con người.
- Checklist bị cũ. Khi team và dự án trưởng thành, vài artifact trở thành không cần. Cách phòng: review checklist mỗi quý; điều chỉnh chuẩn của team.
Khi nào checklist là quá liều?
Có hai trường hợp.
Dự án một tuần, hai engineer. Hãy áp tinh thần của checklist (ước lượng, ship, retro) nhưng artifact chính thức là quá cỡ.
Team continuous-flow không có dự án. Team Platform / SRE / support dùng các artifact đứng của team (runbook, on-call, quy trình ticket), không phải checklist cấp dự án.
Checklist đầy đủ đáng cân nặng ở quy mô dự án + quy mô team + thời lượng. Dưới ngưỡng đó, hãy chạy nhẹ.
Đi tiếp từ đây như thế nào?
Chương cuối: kết luận - năm bài học sống sót qua mọi hình dạng dự án, kèm danh sách đọc đề xuất để tiếp tục phát triển.