Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng mà mọi PM đều phải học, thường là theo cách đau đớn nhất: viết PRD đẹp đến đâu, design lung linh đến đâu, code chạy ngon đến đâu — tất cả đều có thể đổ sông đổ biển trong đúng 30 phút cuối cùng trước khi bấm nút "ship". Cái khoảnh khắc chuyển từ "tính năng đã build xong" sang "tính năng đang chạy trên tay người dùng thật" là khoảnh khắc nguy hiểm nhất trong vòng đời sản phẩm. Và nó nguy hiểm không phải vì code dở, mà vì có quá nhiều thứ nhỏ nhặt bị bỏ sót: cờ tính năng quên bật, dashboard quên dựng, đội Support không biết tính năng mới tồn tại, hay đơn giản là không ai biết phải làm gì khi mọi thứ cháy nổ.
Pre-launch checklist chính là tấm lưới an toàn cho khoảnh khắc đó. Nó là tài liệu biến "hy vọng mọi thứ ổn" thành "đã xác nhận mọi thứ ổn". Trong loạt bài về review và shipping, đây là bài tập trung riêng vào danh sách kiểm tra trước khi phóng — khác với Bài 45 (Engineering Review), Bài 47 (Run-of-Show của buổi họp review), hay Bài 49 (Post-launch review sau khi đã ship). Ở đây chúng ta nói về 7 ngày, 1 ngày, và vài giờ cuối cùng trước go-live: chính xác cần kiểm tra gì, theo thứ tự nào, và ai chịu trách nhiệm cho từng mục.
Là PM, bạn không phải người viết code hay dựng monitoring. Nhưng bạn là người duy nhất nhìn thấy toàn cảnh — và vì thế, bạn là người sở hữu checklist này. Một checklist tốt giúp bạn ngủ ngon đêm trước launch. Một checklist tệ (hoặc không có) khiến bạn phải thức trắng đêm sau launch để dập lửa.
Khái niệm cốt lõi
Pre-launch checklist là gì và không phải là gì
Pre-launch checklist là một danh sách các điều kiện phải đạt được trước khi tính năng được mở cho người dùng thật. Mỗi mục phải có ba thuộc tính: kiểm chứng được (có thể trả lời rõ ràng đạt/không đạt, không mơ hồ), có chủ sở hữu (một người chịu trách nhiệm, không phải "cả team"), và gắn với thời điểm (T-7 ngày, T-1 ngày, hay T-0 giờ launch).
Nó không phải là bản tóm tắt PRD, không phải là to-do list công việc còn dang dở, và không phải là nơi để bàn xem có nên ship hay không. Đến lúc dùng checklist này, quyết định ship đã được thông qua; checklist chỉ trả lời một câu: "Chúng ta đã sẵn sàng về mặt vận hành chưa?"
Bốn nhóm điều kiện cần kiểm tra
Một checklist trưởng thành thường gom theo bốn nhóm rủi ro:
Nhóm 1 — Chất lượng sản phẩm. Toàn bộ acceptance criteria đã pass QA. Các edge case quan trọng (offline, race condition, permission) đã được test. Cross-browser, cross-device đã chạy. Không còn bug nào ở mức P0/P1 (chặn launch).
Nhóm 2 — Khả năng quan sát (observability). Monitoring và alerting đã live trước khi launch, không phải dựng sau. Bạn cần nhìn thấy hệ thống đang thở như thế nào ngay từ phút đầu tiên — error rate, latency, các analytics event đo lường success metric đã bắn đúng.
Nhóm 3 — Khả năng kiểm soát (controllability). Feature flag đã deploy và đang ở trạng thái off. Kế hoạch rollout (mở dần theo phần trăm) đã rõ. Quan trọng nhất: kế hoạch rollback đã được viết ra giấy, đã test, và ai cũng biết cách thực thi trong 5 phút.
Nhóm 4 — Sẵn sàng vận hành & con người. Đội Support biết tính năng mới, có sẵn macro trả lời và FAQ. Các bên liên quan (legal, marketing, sales nếu là B2B) đã được thông báo. Có người trực launch (on-call) rõ ràng. Có kênh liên lạc khẩn (war room/Slack channel) đã lập sẵn.
Vì sao "feature flag off" và "rollback documented" là hai dòng quan trọng nhất
Trong ý định gốc của bài này có bốn dòng, và hai dòng đáng giá nhất là Feature flag deployed (off) và Rollback plan documented. Lý do: chúng quyết định bạn xử lý khủng hoảng nhanh đến đâu.
Khi flag đã deploy sẵn ở trạng thái off, việc launch chỉ là bật một công tắc — và quan trọng hơn, việc hủy launch cũng chỉ là tắt một công tắc, không cần redeploy, không cần chờ build, không cần đánh thức cả đội kỹ thuật lúc 2 giờ sáng. Còn rollback plan được viết ra giấy nghĩa là khi sự cố xảy ra — lúc adrenaline đang cao, đầu óc đang rối — bạn không phải nghĩ xem làm gì, bạn chỉ làm theo. Sự khác biệt giữa 5 phút và 50 phút downtime thường nằm ở chỗ kế hoạch đã được viết sẵn hay chưa.
Tình huống thực tế
Ví dụ 1 — Ví điện tử Việt Nam và cái flag quên bật
Một ví điện tử lớn tại Việt Nam (gọi là "VPay") chuẩn bị ra mắt tính năng "chia hóa đơn" (split bill) cho dịp lễ. Code đã xong, QA đã pass, design đẹp. Đội build dùng feature flag, nhưng checklist của họ chỉ ghi chung chung "deploy tính năng". Đêm launch, kỹ sư deploy code lên production — và vì flag mặc định trong code là on, tính năng bật ngay lập tức cho 100% người dùng, thay vì mở dần 5%.
Hậu quả: một edge case về làm tròn số tiền (chia 100.000đ cho 3 người ra 33.333,33đ) gây lệch số dư ở khoảng 0,2% giao dịch. Với hàng trăm nghìn giao dịch mỗi giờ, đó là hàng trăm khiếu nại đổ về trong 40 phút. Đội phải rollback bằng cách redeploy phiên bản cũ — mất gần 35 phút vì phải chờ build và qua quy trình approve khẩn.
Bài học: dòng checklist phải cụ thể đến mức kiểm chứng được. Không phải "deploy tính năng" mà là "Feature flag split_bill đã deploy, đã xác nhận trạng thái OFF trên dashboard production, screenshot đính kèm". Một dòng mơ hồ là một dòng vô dụng. Nếu flag đã ở trạng thái off và đã được verify bằng mắt, sự cố này chỉ ảnh hưởng 5% và rollback chỉ tốn một cú click.
Ví dụ 2 — Sàn TMĐT Đông Nam Á và đội Support bị bỏ rơi
Một sàn thương mại điện tử khu vực Đông Nam Á tung tính năng "trả góp 0% qua đối tác tài chính" cho giỏ hàng trên 2 triệu đồng. Về kỹ thuật, mọi thứ hoàn hảo: flag bật đúng cách, rollout 10% rồi 50% mượt mà, monitoring xanh. PM tự tin báo cáo launch thành công.
Nhưng họ quên một nhóm trong checklist: sẵn sàng vận hành. Đội Customer Support hoàn toàn không biết tính năng này tồn tại. Khi khách hàng hỏi "tại sao đơn trả góp của tôi bị từ chối", agent Support mò mẫm, trả lời sai, escalate lung tung. CSAT (chỉ số hài lòng) của tuần đó rớt 8 điểm — không phải vì tính năng dở, mà vì không ai chuẩn bị cho tuyến đầu. Phải mất ba ngày mới ổn định, sau khi PM gấp rút viết FAQ và đào tạo nhanh đội Support.
Bài học: checklist không chỉ là kỹ thuật. Một launch "thành công về kỹ thuật" vẫn có thể là thảm họa về trải nghiệm nếu con người vận hành chưa sẵn sàng. Dòng "Support đã có FAQ + macro trả lời, đã xác nhận với trưởng nhóm Support" phải nằm trong checklist T-7, ngang hàng với "monitoring live".
Ví dụ 3 — Startup SaaS và buổi kiểm tra T-7 cứu một bàn thua
Một startup SaaS B2B Việt Nam làm phần mềm quản lý kho, sắp ship tính năng "đồng bộ tồn kho đa chi nhánh". PM ở đây làm đúng bài: chạy checklist T-7 ngày một cách nghiêm túc. Khi rà đến mục "Monitoring + alerting live", họ phát hiện alert cho error rate đã dựng, nhưng ngưỡng cảnh báo (threshold) chưa được cấu hình — nghĩa là dù có lỗi cũng không ai nhận thông báo. Họ cũng phát hiện rollback plan mới chỉ là "rollback nếu có vấn đề", chưa có các bước cụ thể.
Vì phát hiện sớm 7 ngày, đội có thời gian: cấu hình threshold (error rate > 1% trong 5 phút thì page on-call), viết rollback plan chi tiết thành 4 bước, và diễn tập thử rollback trên staging. Đến ngày launch, một sự cố thật xảy ra — đồng bộ bị nghẽn ở một chi nhánh có dữ liệu cũ lỗi. Alert bắn đúng sau 4 phút, on-call thực thi rollback theo đúng kịch bản đã diễn tập, downtime chỉ 6 phút.
Bài học: giá trị lớn nhất của checklist T-7 không phải để tick cho đẹp, mà để phát hiện lỗ hổng khi vẫn còn thời gian sửa. Một checklist chạy đúng ngày launch chỉ giúp bạn biết mình sắp chết; một checklist chạy trước 7 ngày giúp bạn tránh được cái chết đó.
Hướng dẫn từng bước
Dưới đây là khung checklist theo mốc thời gian. Hãy biến nó thành template của riêng bạn và tái sử dụng cho mọi launch.
T-7 ngày — Rà soát mức độ sẵn sàng
Mục tiêu của mốc này là phát hiện vấn đề khi còn kịp sửa. Chạy buổi review riêng, đi qua từng mục:
- [ ] Toàn bộ acceptance criteria đã pass QA, có biên bản test.
- [ ] Các edge case trọng yếu (offline, race, permission, lỗi mạng) đã được test.
- [ ] Không còn bug P0/P1 đang mở. Danh sách bug P2 còn lại đã được chấp nhận có ý thức.
- [ ] Monitoring đã live: dashboard error rate, latency, throughput đã dựng và đang chạy.
- [ ] Alerting đã live: alert đã cấu hình kèm ngưỡng cụ thể và đã test bắn thử một lần.
- [ ] Analytics event đo success metric đã được kiểm tra bắn đúng (xem Bài 36 về event spec).
- [ ] Feature flag đã được tạo và deploy lên production, xác nhận trạng thái OFF.
- [ ] Rollback plan đã được viết thành các bước cụ thể, có chủ sở hữu.
- [ ] Đội Support đã được brief, có FAQ và macro trả lời nháp.
- [ ] Các bên liên quan (legal, marketing, sales) đã được thông báo lịch launch.
T-1 ngày — Xác nhận lần cuối
Mục tiêu của mốc này là khóa mọi thứ lại, không còn thay đổi lớn:
- [ ] Bản build cuối đã lên production (sau flag, chưa bật).
- [ ] Đã diễn tập (dry-run) bật flag trên môi trường staging hoặc với cohort nội bộ.
- [ ] Đã diễn tập rollback ít nhất một lần — bấm giờ xem mất bao lâu.
- [ ] Lịch rollout đã chốt: bật theo % nào, mỗi bước chờ bao lâu, ai quyết định lên bước tiếp.
- [ ] Người trực launch (on-call) và người ra quyết định (decision owner) đã được chỉ định rõ.
- [ ] Kênh war room (Slack channel/group) đã lập, đã mời đủ người.
- [ ] FAQ Support đã final và đã đẩy cho đội Support.
T-0 — Giờ launch
- [ ] Xác nhận tất cả người liên quan có mặt trong war room.
- [ ] Xác nhận dashboard monitoring đang mở và xanh ở trạng thái nền (baseline).
- [ ] Bật flag ở mức rollout đầu tiên (ví dụ 5%).
- [ ] Quan sát 15–30 phút: error rate, latency, các event chính, phản hồi đầu tiên.
- [ ] Nếu xanh: lên bước rollout tiếp theo theo lịch. Nếu đỏ: thực thi rollback theo kịch bản.
- [ ] Ghi lại mọi quan sát bất thường để phục vụ post-launch review (Bài 49).
Nguyên tắc xuyên suốt
Mỗi dòng phải có ô tick, một cái tên, và một thời điểm. Nếu một mục không thể trả lời rõ ràng đạt/không đạt, hãy viết lại cho cụ thể hơn. Và đừng cho phép ai "tự tick hộ" — người chủ sở hữu mục đó phải tự xác nhận.
Lỗi thường gặp & mẹo
Lỗi 1 — Checklist mơ hồ, không kiểm chứng được. "Đã test kỹ", "monitoring ổn", "Support đã biết" là những dòng vô dụng. Thay bằng "Error rate alert đã cấu hình ngưỡng 1%/5 phút và đã bắn thử thành công lúc 14h ngày X". Mẹo: với mỗi dòng, tự hỏi "làm sao tôi chứng minh được mục này đã xong?". Nếu câu trả lời là một screenshot, một link, hay một biên bản — dòng đó tốt.
Lỗi 2 — Chạy checklist quá muộn. Nhiều PM chỉ mở checklist vào đúng ngày launch. Lúc đó phát hiện lỗ hổng cũng không sửa kịp, dẫn đến hoặc liều ship hoặc hoãn launch trong hỗn loạn. Mẹo: T-7 là để sửa, T-1 là để xác nhận, T-0 là để thực thi. Đừng dồn hết vào phút chót.
Lỗi 3 — Bỏ quên con người và vận hành. Như ví dụ sàn TMĐT, một launch hoàn hảo về kỹ thuật vẫn sập về trải nghiệm nếu Support, legal, marketing không sẵn sàng. Mẹo: luôn có ít nhất một nhóm "sẵn sàng vận hành" trong checklist, đừng để nó toàn màu kỹ thuật.
Lỗi 4 — Rollback plan tồn tại trên giấy nhưng chưa ai diễn tập. Một kế hoạch chưa test là một giả thuyết, không phải kế hoạch. Mẹo: bắt buộc dry-run rollback ít nhất một lần và bấm giờ. Nếu rollback mất hơn 10 phút, đó là tín hiệu kiến trúc của bạn (hoặc flag setup) có vấn đề cần sửa trước.
Lỗi 5 — Một checklist khổng lồ dùng cho mọi loại launch. Launch đổi màu nút bấm và launch hệ thống thanh toán không cần cùng độ nghiêm ngặt. Mẹo: phân tầng theo rủi ro. Có "checklist nhẹ" cho thay đổi nhỏ và "checklist đầy đủ" cho tính năng rủi ro cao. Gắn độ nghiêm ngặt với mức độ ảnh hưởng nếu hỏng.
Mẹo vàng — Biến checklist thành template tái sử dụng. Sau mỗi launch, hãy bổ sung vào template những dòng mà lần này bạn ước mình đã có. Checklist tốt nhất là checklist được mài giũa qua từng lần ship, kết tinh kinh nghiệm đau thương của những launch trước (kết nối với Bài 60 về thư viện template).
Bài tập thực hành
Bài 1 — Viết checklist thật cho tính năng của bạn. Chọn một tính năng bạn đang hoặc sắp ship. Viết pre-launch checklist đầy đủ theo ba mốc T-7 / T-1 / T-0. Yêu cầu: mỗi dòng phải kiểm chứng được, có tên chủ sở hữu, và bao phủ cả 4 nhóm rủi ro (chất lượng, observability, controllability, vận hành). Mục tiêu tối thiểu 15 dòng.
Bài 2 — "Soi" một checklist tồi. Lấy đoạn checklist sau và viết lại cho cụ thể, kiểm chứng được:
- "Đã test xong tính năng."
- "Monitoring đã set up."
- "Có flag rồi."
- "Sẽ rollback nếu cần."
Bài 3 — Thiết kế kịch bản rollback. Cho tính năng ở Bài 1, viết rollback plan chi tiết: dấu hiệu nào kích hoạt rollback (ngưỡng cụ thể), ai có quyền ra quyết định, các bước thực thi theo thứ tự, và thời gian mục tiêu hoàn thành. Sau đó tự hỏi: nếu người chủ trì đang ngủ lúc 3 giờ sáng, người khác có làm theo được không?
Tóm tắt
Pre-launch checklist là tấm lưới an toàn cho khoảnh khắc nguy hiểm nhất trong vòng đời sản phẩm: lúc chuyển từ "đã build xong" sang "đang chạy thật". Là PM, bạn sở hữu checklist này vì bạn là người duy nhất nhìn thấy toàn cảnh.
Những điểm cốt lõi cần nhớ:
- Mỗi dòng checklist phải kiểm chứng được, có chủ sở hữu, và gắn với thời điểm (T-7 / T-1 / T-0). Dòng mơ hồ là dòng vô dụng.
- Bao phủ đủ bốn nhóm rủi ro: chất lượng sản phẩm, khả năng quan sát (monitoring/alerting), khả năng kiểm soát (feature flag off + rollback), và sẵn sàng vận hành (Support, legal, on-call).
- Hai dòng quý giá nhất: feature flag đã deploy ở trạng thái OFF và rollback plan đã viết ra giấy và đã diễn tập. Chúng quyết định bạn dập lửa trong 5 phút hay 50 phút.
- Chạy checklist sớm: T-7 để sửa, T-1 để xác nhận, T-0 để thực thi. Đừng dồn vào phút chót.
- Đừng quên con người. Một launch hoàn hảo về kỹ thuật vẫn sập nếu đội tuyến đầu chưa sẵn sàng.