Checklist sẵn sàng ra mắt
Mẫu & ví dụ Launch TemplatesChecklist theo mảng, mỗi dòng có bằng chứng và một người chủ, đọc màu trong buổi go/no-go 30 phút có người quyết được nêu tên trước.
Mẫu này giúp bạn
Hiểu rằng sẵn sàng ra mắt là chuyện của cả công ty chứ không riêng đội kỹ thuật, và một dòng checklist chỉ có giá trị khi có bằng chứng.
Lập checklist theo mảng có chủ từ kickoff, chép rủi ro từ pre-mortem thành dòng có bằng chứng, dùng màu vàng gắn với nấc thay vì tô xanh cho xong, chạy buổi go/no-go 30 phút có người quyết được nêu tên trước, và viết tiêu chí rollback bằng số.
Mẫu, ví dụ đã điền và cách dùng
Checklist sẵn sàng ra mắt dùng để làm gì?
Checklist ra mắt ở phần lớn các đội là một danh sách câu hỏi kiểu "Support sẵn sàng chưa?", và câu trả lời luôn là "rồi anh". Rồi đến ngày release, nhân viên tổng đài nghe khách hỏi về một tính năng họ chưa từng thấy. Checklist này khác ở một quy tắc: một dòng chỉ được tính là xanh khi có bằng chứng — một đường link, một con số, một buổi đã diễn ra có ngày giờ.
Mẫu chia theo mảng — engineering, QA, support, sales/CS, tài liệu, pháp lý, analytics, truyền thông — mỗi mảng có một người chủ có tên. Nó kết thúc bằng buổi go/no-go: mỗi chủ mảng đọc màu của mình, và một người được nêu tên từ trước ra quyết định. Kèm theo là tiêu chí rollback viết bằng số, vì đó là phần duy nhất của checklist còn quan trọng lúc 11 giờ đêm ngày release.
Checklist không thay cho pre-mortem. Pre-mortem tìm những cách dự án có thể thất bại, khi còn đổi được hướng; checklist kiểm xem các biện pháp đã chọn đã thật sự xong chưa, ngay trước khi bật. Một rủi ro lớn từ pre-mortem nên xuất hiện lại ở đây thành một dòng có bằng chứng.
Dành cho: PM · Product Owner · BA · Tech lead · QA lead · Support lead · Head of Product (tier 1)
Dùng khi: Mở từ buổi kickoff của mọi lần ra mắt tier 1 và tier 2, cập nhật hằng tuần, và chốt trong buổi go/no-go hai đến ba ngày trước nấc release đầu tiên có khách thật.
Khác gì với Definition of Done và pre-mortem?
| Kiểm cái gì | Khi nào | |
|---|---|---|
| Definition of Done | Một story đã code, review, test xong theo chuẩn của đội | Cuối mỗi story, trong sprint |
| Pre-mortem | Dự án có thể thất bại theo những cách nào, ai chủ mỗi rủi ro | Trước khi cam kết nguồn lực lớn |
| Checklist sẵn sàng ra mắt | Cả công ty — không chỉ đội kỹ thuật — đã sẵn sàng cho người dùng thật chưa | Mở từ kickoff, chốt ở go/no-go |
Một tính năng có thể đạt Definition of Done ở mọi story mà vẫn chưa sẵn sàng ra mắt: support chưa được đào tạo, pháp chế chưa duyệt điều khoản, event analytics bắn sai tên. Đó là khoảng trống checklist này lấp.
Bản trắng — copy và dán vào tài liệu của bạn
Bản đầy đủ cho tier 1. Với tier 2, giữ engineering, QA, support và analytics; các mảng không áp dụng thì ghi KAD kèm lý do chứ đừng xoá — để người đọc biết đã cân nhắc.
CHECKLIST SẴN SÀNG RA MẮT — [Tên tính năng] — Tier [1/2]
Người giữ checklist (PM): ......
Ngày go/no-go: ...... Nấc release đầu tiên: ...... (......%)
Ngày truyền thông ra ngoài: ......
Người quyết go/no-go: ......
Màu: XANH = có bằng chứng
VÀNG = có rủi ro, có kế hoạch xử lý, có hạn gắn với một nấc
ĐỎ = chưa xong, chưa có kế hoạch
KAD = không áp dụng (ghi vì sao)
ENGINEERING Chủ: ......
[ ] Tính năng nằm sau flag; đã thử tắt flag trên staging
Bằng chứng: ...... Màu: ......
[ ] Cảnh báo lỗi và độ trễ cho luồng mới đã bật
Bằng chứng: ...... Màu: ......
[ ] Đã thử tải ở mức ...... (gấp ...... lần dự kiến)
Bằng chứng: ...... Màu: ......
QA Chủ: ......
[ ] Luồng chính + luồng lỗi trên thiết bị thật: ......
Bằng chứng: ...... Màu: ......
[ ] Không còn lỗi mức nghiêm trọng; lỗi còn mở: ...... lỗi
Bằng chứng: ...... Màu: ......
SUPPORT Chủ: ......
[ ] Buổi đào tạo đã diễn ra (ngày, số người dự)
[ ] FAQ nội bộ 10 câu + macro trả lời
[ ] Đường chuyển ticket lên kỹ thuật, có tên người nhận
Bằng chứng: ...... Màu: ......
SALES / CS Chủ: ......
[ ] Tài liệu một trang: bán cho ai, không bán cho ai
[ ] Danh sách khách cần báo trước + người báo + ngày báo
Bằng chứng: ...... Màu: ......
TÀI LIỆU Chủ: ......
[ ] Trang trợ giúp + release note, có người ngoài đội đọc thử
Bằng chứng: ...... Màu: ......
PHÁP LÝ / TUÂN THỦ Chủ: ......
[ ] Dữ liệu cá nhân mới? Điều khoản mới? Đối tác cần báo?
Bằng chứng: ...... Màu: ......
ANALYTICS Chủ: ......
[ ] Event của hành động cốt lõi đã QA trên staging
[ ] Dashboard readout đã dựng, có mục tiêu đặt trước, có nhóm đối chứng
Bằng chứng: ...... Màu: ......
TRUYỀN THÔNG Chủ: ......
[ ] Nội dung thông báo đã duyệt; chỉ gửi sau nấc ......
Bằng chứng: ...... Màu: ......
TIÊU CHÍ ROLLBACK (bằng số, viết trước)
Kỹ thuật: ......
Sản phẩm (chỉ số bảo vệ): ......
Vận hành: ......
Người được quyền tắt flag, không cần họp: ......
KẾT LUẬN GO/NO-GO
Quyết định: GO / GO CÓ ĐIỀU KIỆN / NO-GO
Điều kiện (nếu có): ...... phải xong trước nấc ......
Người quyết: ...... Ngày: ......Từng ô điền gì, và vì sao ô đó tồn tại
| Ô | Điền gì | Bỏ trống thì hỏng ở đâu |
|---|---|---|
| Người quyết go/no-go | Một cái tên, ghi từ kickoff. Tier 2 thường là PM; tier 1 là Head of Product. | Không ghi trước thì buổi go/no-go thành cuộc tìm người dám chịu trách nhiệm, và mặc định trở thành "cứ ra mắt". |
| Bằng chứng | Một link, một con số, hoặc một buổi đã diễn ra có ngày. Không phải "rồi", "đã báo", "ok". | Đây là ô duy nhất phân biệt checklist này với một bảng cảm giác. Không có bằng chứng thì màu xanh không có nghĩa gì. |
| Màu VÀNG | Có rủi ro, kèm kế hoạch xử lý và hạn chót trước một nấc cụ thể. | Không có màu vàng, người ta sẽ tô xanh cho xong. Vàng cho phép nói thật mà không chặn cả lần ra mắt. |
| KAD — không áp dụng | Ghi rõ vì sao mảng đó không áp dụng. | Xoá dòng thì người đọc không biết đội đã cân nhắc hay đã quên. Pháp lý là mảng bị "quên" nhiều nhất. |
| Chủ mỗi mảng | Một người của chính mảng đó, không phải PM điền hộ. | PM điền hộ support là cách chắc chắn nhất để support biết tính năng mới từ khách hàng. |
| Thử tải | Mức tải đã thử, so với mức dự kiến ở nấc lớn nhất. | Lỗi chỉ xuất hiện ở quy mô thật là lý do số một khiến đội phải lùi nấc. |
| Danh sách khách cần báo trước | Tên khách, người báo, ngày báo. | Với B2B, một khách lớn biết về thay đổi từ nhân viên của họ chứ không từ account manager là một cuộc gọi khó chịu lên giám đốc. |
| Dashboard readout | Link dashboard đã có số liệu thử, có mục tiêu đặt trước và nhóm đối chứng. | Không dựng trước thì hai tuần sau không có gì để readout, và event sai tên không ai phát hiện kịp. |
| Tiêu chí rollback | Ngưỡng bằng số cho kỹ thuật, sản phẩm, vận hành, và tên người được quyền tắt. | Lúc sự cố, không ai muốn là người dừng thứ cả đội làm ba tháng. Ngưỡng viết sẵn biến quyết định thành thực thi. |
| Kết luận go/no-go | Một trong ba quyết định, kèm điều kiện nếu là "có điều kiện". | Không ghi lại thì một tuần sau không ai nhớ đã đồng ý ra mắt với điều kiện gì. |
Cách dùng từ kickoff đến go/no-go
- Ở kickoff: tạo bản checklist, điền người quyết và chủ từng mảng. Gửi cho từng chủ mảng và hỏi: "Dòng nào không đúng với mảng của bạn, dòng nào còn thiếu?" Mỗi đội từng bị đốt ở những chỗ khác nhau; hãy để họ tự thêm vào.
- Chép rủi ro từ pre-mortem vào. Mỗi rủi ro có biện pháp thành một dòng trong mảng tương ứng, kèm loại bằng chứng cần có. Ví dụ "wifi nhà máy yếu" thành "đã thử chế độ ngoại tuyến tại hiện trường, có biên bản".
- Hằng tuần: mỗi chủ mảng tự cập nhật màu. PM chỉ hỏi về các dòng đỏ và vàng. Một dòng đứng màu đỏ hai tuần liền là chủ đề của buổi họp tuần này, không phải của ngày go/no-go.
- Hai đến ba ngày trước nấc đầu tiên: buổi go/no-go 30 phút. Không thuyết trình. Mỗi chủ mảng đọc màu và bằng chứng trong một phút. Đỏ ở engineering, QA hoặc pháp lý là dừng. Đỏ ở tài liệu hay analytics có thể chấp nhận nếu nấc đầu nhỏ và việc đó được gắn làm điều kiện cho nấc sau.
- Người quyết nói quyết định thành lời, PM ghi vào mục kết luận. "Go có điều kiện" phải kèm điều kiện cụ thể và nấc mà điều kiện đó phải xong trước.
- Đọc lại tiêu chí rollback và tên người được tắt flag trước khi kết thúc buổi họp, để người trực đêm đó đã nghe tận tai.
- Sau ra mắt: ghi vào retro dòng nào đã xanh mà vẫn hỏng. Đó là dòng cần sửa câu hỏi hoặc sửa loại bằng chứng được chấp nhận.
Ví dụ đã điền đầy đủ
GiaoNhanh (giả định) là công ty giao hàng cho khoảng 45.000 shop online. Tính năng mới: shop rút tiền thu hộ (COD) về tài khoản ngân hàng ngay trong ngày, thay vì chờ đối soát hai lần mỗi tuần. Tier 1 vì chạm vào tiền và có ngân hàng đối tác. Đây là bản chụp lúc kết thúc buổi go/no-go.
CHECKLIST SẴN SÀNG RA MẮT — Rút COD trong ngày — Tier 1
Người giữ checklist (PM): Hiếu
Ngày go/no-go: 06/04 Nấc release đầu tiên: 09/04 (500 shop beta)
Ngày truyền thông ra ngoài: dự kiến 05/05, sau nấc 25%
Người quyết go/no-go: chị Linh (Head of Product)
ENGINEERING Chủ: Toàn (Tech lead)
[x] Flag cod_sameday; thử tắt trên staging 02/04: lệnh đang xử lý
vẫn hoàn tất, lệnh mới bị chặn Biên bản thử XANH
[x] Cảnh báo: lỗi gọi API ngân hàng trên 1% trong 10 phút; hàng
đợi lệnh rút trên 200 Link dashboard XANH
[x] Thử tải 3.000 lệnh/giờ, gấp 4 lần dự kiến ở nấc 25%
Báo cáo tải XANH
QA Chủ: Mai
[x] 46 ca kiểm: sai số tài khoản, ngân hàng bảo trì, rút hai lần
liên tiếp, Android tầm thấp Báo cáo test XANH
[~] Còn 3 lỗi mức trung bình: hiển thị phí sai khi số tiền dưới
50.000đ. Sửa xong 08/04 Danh sách lỗi VÀNG
SUPPORT Chủ: Ngọc
[x] Đào tạo 03/04, 38/42 người dự; 4 người ca đêm xem bản ghi
[x] FAQ 12 câu + 6 macro, có câu "tiền chưa về thì làm gì"
[x] Ticket về tiền chuyển thẳng nhóm Đối soát, người nhận: anh Phát
Link FAQ, quy trình XANH
SALES / CS Chủ: Dũng
[x] Tài liệu một trang: không chào cho shop chưa xác minh tài khoản
[~] 120 shop lớn cần AM gọi trước; đã gọi 74. Xong 15/04, trước nấc 25%
Bảng theo dõi VÀNG
TÀI LIỆU Chủ: Hiếu
[x] Trang trợ giúp + release note; 3 chủ shop beta đọc thử, sửa 2 chỗ
Link XANH
PHÁP LÝ / TUÂN THỦ Chủ: chị Hà (Pháp chế)
[x] Phụ lục hợp đồng với ngân hàng đối tác ký 28/03
[x] Điều khoản phí rút nhanh; shop đồng ý khi bật lần đầu
Email xác nhận XANH
ANALYTICS Chủ: Vy (Data)
[x] Event cod_withdraw_requested / _completed / _failed đã QA
trên staging, đúng tên theo tracking plan
[ ] Dashboard readout: mới có phễu, chưa có nhóm đối chứng
— ĐỎ
TRUYỀN THÔNG Chủ: Trang (Marketing)
KAD ở nấc beta — không truyền thông ra ngoài trước nấc 25%.
TIÊU CHÍ ROLLBACK
Kỹ thuật: lệnh rút thất bại trên 2% trong 1 giờ; BẤT KỲ lệnh nào
trừ tiền shop mà không chuyển đi
Sản phẩm: trên 15% shop đã bật quay lại đối soát thường mà chưa
hoàn tất lệnh rút nào
Vận hành: ticket về tiền trên 80/ngày (nhóm Đối soát xử lý được 60)
Người được quyền tắt flag: Toàn, hoặc kỹ sư trực tuần đó
KẾT LUẬN GO/NO-GO — 06/04
Quyết định: GO CÓ ĐIỀU KIỆN
Điều kiện: dashboard có nhóm đối chứng trước nấc 5% (16/04);
3 lỗi hiển thị phí sửa trước 09/04;
AM gọi đủ 120 shop trước nấc 25%.
Người quyết: chị Linh Ngày: 06/04Dòng analytics đỏ nhưng quyết định vẫn là go — vì nấc đầu là 500 shop beta đã đồng ý, nơi đội học bằng phản hồi trực tiếp và chưa cần nhóm đối chứng. Nhưng điều kiện được gắn vào nấc 5%: nếu tới 16/04 dashboard chưa xong thì không lên nấc. Đó là cách xử lý đúng một dòng đỏ — không giấu nó thành vàng, không để nó chặn cả lần ra mắt, mà gắn nó với một mốc cụ thể. Để ý thêm tiêu chí rollback kỹ thuật thứ hai: "bất kỳ lệnh nào". Với tiền, một ngưỡng phần trăm là không đủ.
Hiccups thường gặp và cách xử lý
| Hiccup | Vì sao xảy ra | Xử lý |
|---|---|---|
| Mọi dòng đều xanh, ra mắt vẫn hỏng | Màu được tô theo cảm giác của người điền | Bằng chứng là bắt buộc; dòng không có link hoặc con số mặc định là đỏ. |
| PM điền hộ mọi mảng | Nhanh hơn là đi hỏi từng người | Chủ mảng tự điền và tự đọc màu ở go/no-go; PM chỉ giữ checklist. |
| Go/no-go thành buổi thuyết trình 90 phút | Mỗi mảng trình bày lại toàn bộ công việc | Một phút mỗi mảng: màu, bằng chứng, rủi ro. Chỉ thảo luận dòng đỏ. |
| Dòng đỏ được đổi thành vàng phút cuối | Không ai muốn là người chặn lần ra mắt | Vàng chỉ hợp lệ khi có kế hoạch và hạn gắn với một nấc; không có thì vẫn là đỏ. |
| Pháp lý bị bỏ qua | "Tính năng nhỏ, đâu có đổi điều khoản" | Luôn giữ dòng pháp lý; nếu không áp dụng thì ghi KAD và lý do, để pháp chế có cơ hội phản đối. |
| Tiêu chí rollback chung chung | "Nếu lỗi nhiều thì tắt" | Ngưỡng bằng số và một người có tên; với tiền và dữ liệu, ngưỡng là "bất kỳ ca nào". |
| Checklist dùng lại nguyên xi cho mọi tính năng | Copy từ lần trước cho nhanh | Mỗi lần thêm dòng từ pre-mortem của chính tính năng đó; sau mỗi retro sửa bản gốc. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| PM | Giữ checklist, điều phối go/no-go, và đưa ra bằng chứng thay vì lời hứa khi lãnh đạo hỏi "đã sẵn sàng chưa" |
| Product Owner | Biến các dòng đỏ thành việc trong sprint cuối, trước khi chúng thành lý do lùi ngày |
| BA | Kiểm luồng lỗi và quy tắc nghiệp vụ trong mảng QA, và viết FAQ cho support từ tài liệu yêu cầu |
| Head of Product | Quyết go/no-go tier 1 dựa trên màu và bằng chứng, không dựa trên mức tự tin của người trình bày |
| Tech lead / Support lead | Có tiếng nói chính thức để chặn một lần ra mắt mà mảng của mình chưa sẵn sàng |
Definition of done
- Người quyết go/no-go và chủ từng mảng có tên từ kickoff.
- Mọi dòng xanh có bằng chứng là link, con số hoặc buổi đã diễn ra có ngày.
- Mọi dòng vàng có kế hoạch, hạn, và gắn với một nấc rollout cụ thể.
- Mảng không áp dụng được ghi KAD kèm lý do, không bị xoá.
- Rủi ro lớn từ pre-mortem xuất hiện thành dòng có bằng chứng.
- Tiêu chí rollback viết bằng số, có tên người được quyền tắt flag, và kết luận go/no-go được ghi lại.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.