Launch Planning & Release Management

Deploy, release, launch — ba việc khác nhau

Ở nhiều đội, chữ "launch" được dùng cho cả ba việc, và đó là gốc của rất nhiều buổi ra mắt hỏng. Deploy là đưa code lên production. Release là bật tính năng cho người dùng thấy. Launch là làm cho đúng người biết, hiểu và bắt đầu dùng nó — một sự kiện kinh doanh, có support, sales, marketing và số liệu đi kèm.

Code có thể đã deploy hai tuần trước, nằm sau một feature flag. Release có thể đi từng nấc 5%, 25%, 100%. Launch có thể là một email gửi khách hàng vào sáng thứ Ba sau khi release đã chạy ổn một tuần. Tách ba việc ra cho bạn quyền chọn thời điểm cho từng việc, thay vì dồn mọi rủi ro vào một đêm.

Dòng cuối là lý do launch cần kế hoạch riêng. Code rút lại được trong năm phút. Một thông báo đã gửi tới 200.000 người dùng thì không.

Không phải launch nào cũng cần cùng một mức chuẩn bị. Phân tầng giúp bạn không đối xử với một nút mới như với một sản phẩm mới, và ngược lại.

Quy tắc chọn tầng: tầng được quyết bởi tác động lên khách hàng và rủi ro, không bởi công sức kỹ thuật. Đổi giá gói SaaS có thể chỉ là sửa một dòng cấu hình, nhưng nó là tier 1. Một tính năng mất ba tháng để xây nhưng chỉ dành cho đội nội bộ có thể là tier 3. Chốt tầng ngay ở buổi kickoff, vì nó quyết định ai cần được mời và cần bao nhiêu tuần chuẩn bị.

Checklist sẵn sàng launch — hỏi bằng bằng chứng, không bằng cảm giác

Checklist thường hỏi "Support đã sẵn sàng chưa?" và nhận về câu "rồi anh". Câu đó không có giá trị gì. Một dòng checklist chỉ tính khi có bằng chứng: một đường link, một con số, một buổi đã diễn ra. Nếu không chỉ ra được bằng chứng, dòng đó chưa xanh.

Go/no-go: một buổi 30 phút, hai đến ba ngày trước ngày release. Mỗi chủ mảng đọc màu của dòng mình: xanh, vàng (có rủi ro, có kế hoạch xử lý), đỏ. Một dòng đỏ ở Engineering, QA hoặc Pháp lý là dừng. Một dòng đỏ ở Tài liệu có thể chấp nhận nếu rollout bắt đầu ở 5% và tài liệu xong trước nấc 25%. Người quyết là người được nêu tên từ trước — thường là PM cho tier 2, Head of Product cho tier 1.

CHECKLIST LAUNCH — [Tên tính năng] — Tier [1/2/3]
Ngày go/no-go: ____   Ngày release 5%: ____   Ngày launch (truyền thông): ____
Người quyết go/no-go: ____

Mảng          | Câu hỏi                                   | Bằng chứng (link) | Chủ | Màu
Engineering   | Flag tắt được, cảnh báo đã bật             |                   |     |
QA            | Luồng chính + luồng lỗi, không lỗi nghiêm trọng |              |     |
Support       | Đào tạo xong, FAQ, đường chuyển ticket     |                   |     |
Sales / CS    | Tài liệu một trang, danh sách khách báo trước |                |     |
Tài liệu      | Hướng dẫn, release note, đã có người đọc thử |                 |     |
Pháp lý       | Dữ liệu cá nhân, điều khoản, đối tác       |                   |     |
Analytics     | Event đã QA, dashboard readout             |                   |     |

Tiêu chí rollback (viết trước, bằng số): ____
Người được quyền tắt flag: ____

Release plan và rollout theo từng nấc

Feature flag là công cụ quan trọng nhất của người làm launch, vì nó tách quyết định kỹ thuật (code đã lên chưa) khỏi quyết định sản phẩm (ai được thấy). Với flag, bạn có thể bật cho nhân viên trước, rồi một nhóm khách beta, rồi từng phần trăm người dùng — và tắt trong vài giây nếu có chuyện, không cần chờ một lần deploy mới.

Tiêu chí rollback phải viết trước, bằng số, và có tên người được quyền bấm. Lúc 11 giờ đêm, khi lỗi đang tăng và mọi người đang mệt, không ai muốn là người quyết định dừng một thứ cả đội đã làm ba tháng. Nếu quy tắc đã viết sẵn, việc tắt flag không còn là quyết định — nó là thực thi.

• Tiêu chí kỹ thuật: tỉ lệ lỗi của luồng mới vượt một ngưỡng (ví dụ 2% request), độ trễ vượt ngưỡng, có sự cố mất hoặc sai dữ liệu — bất kể tỉ lệ bao nhiêu.
• Tiêu chí sản phẩm: chỉ số bảo vệ xấu đi rõ rệt — ví dụ tỉ lệ thanh toán thành công giảm quá 1 điểm phần trăm so với nhóm chưa bật.
• Tiêu chí vận hành: ticket support liên quan vượt mức đội xử lý được trong ngày.
• Không rollback được thì sao: một số thay đổi không đảo ngược được (đổi cấu trúc dữ liệu, gửi thông báo, đổi giá). Ghi rõ những phần này và xử lý chúng bằng cách khác: chuyển đổi dữ liệu có bản sao lưu, đổi giá có giai đoạn chuyển tiếp.

Ví dụ đã điền — tính năng "Trả sau" của một ví điện tử cỡ vừa (công ty và số liệu là giả định, để minh hoạ):

RELEASE PLAN — "Trả sau" (mua trước, trả cuối tháng) — Tier 1
Mục tiêu: 8% người dùng đủ điều kiện kích hoạt trong 6 tuần; tỉ lệ nợ quá hạn dưới 3%.
Flag: pay_later_enabled (theo user_id, có danh sách loại trừ)

Nấc 0 — Nội bộ, 300 nhân viên, 5 ngày
  Lên nấc khi: không lỗi chặn; đối soát với ngân hàng đối tác khớp 100%.
Nấc 1 — Beta, 2.000 khách có lịch sử giao dịch tốt, đã đồng ý, 2 tuần
  Lên nấc khi: 60% khách beta hoàn thành một giao dịch; không khiếu nại về phí.
Nấc 2 — 5% người dùng đủ điều kiện, 3 ngày
Nấc 3 — 25%, 1 tuần
Nấc 4 — 100%, sau khi đọc chỉ số nợ quá hạn của nhóm 25%.

Rollback (tắt flag ngay, không cần họp):
  - Lỗi đối soát với ngân hàng đối tác: bất kỳ ca nào
  - Tỉ lệ giao dịch Trả sau thất bại > 3% trong 1 giờ
  - Tỉ lệ thanh toán thường thành công giảm > 1 điểm so với nhóm chưa bật
Người được quyền tắt: PM trực, Tech lead trực (một trong hai).
Phần không đảo ngược được: khoản đã cho vay vẫn phải thu theo điều khoản;
  tắt flag chỉ chặn khoản vay mới.

Truyền thông nội bộ trước, khách hàng sau

Quy tắc số một: không ai trong công ty được biết về tính năng mới từ khách hàng. Một nhân viên tổng đài nghe khách hỏi về thứ mình chưa từng thấy sẽ đoán, và câu trả lời đoán đó là trải nghiệm đầu tiên của khách với tính năng của bạn.

Hai loại truyền thông có hai mục đích khác nhau. Truyền thông nội bộ nói về cái gì có thể hỏng và gọi ai. Truyền thông khách hàng nói về điều gì thay đổi với họ và họ được gì. Một bản tin dùng chung cho cả hai thường quá kỹ thuật với khách và quá hời hợt với support.

Với khách doanh nghiệp, đặc biệt trong dự án outsourcing hay SaaS B2B, một thay đổi giao diện nhỏ có thể buộc khách đào tạo lại hàng trăm nhân viên. Báo trước bằng ảnh chụp màn hình, cho họ môi trường thử, và cho họ một ngày bật cụ thể — đừng để họ phát hiện vào sáng thứ Hai.

Ngày launch: phòng điều phối

"Phòng điều phối" (mission control) không cần là một căn phòng. Nó là ba thứ: một kênh chat duy nhất cho mọi tín hiệu, một tài liệu ghi các mốc và quyết định, và một danh sách tên — ai nhìn cái gì, ai được quyết cái gì.

Trình tự một ngày launch tier 1 điển hình:

• Hôm trước: chốt danh sách trực, kiểm lại flag trên production ở trạng thái tắt, gửi tin nhắn cho support về giờ bật.
• Giờ bật: chọn buổi sáng đầu tuần, không bao giờ chiều thứ Sáu hay trước kỳ nghỉ — khi có chuyện, bạn cần đủ người.
• +1 giờ, +4 giờ, cuối ngày: chỉ huy ghi trạng thái ngắn vào kênh: các chỉ số, ticket, quyết định. Ba dòng là đủ.
• Cuối ngày: quyết định giữ nấc, lên nấc hay lùi lại — ghi lý do vào nhật ký.

Readout kết quả và retro sau launch

Launch chưa xong khi tính năng đã bật 100%. Nó xong khi bạn trả lời được câu hỏi đã đặt ra từ đầu: chúng ta có đạt mục tiêu không, và học được gì. Không có readout, đội sẽ chuyển sang việc tiếp theo và không ai biết lần ra mắt vừa rồi thành công hay chỉ là "đã xong".

Hai mốc readout: sau 2 tuần (người dùng có thử không, có hỏng gì không) và sau 6 tuần (người dùng có quay lại không, chỉ số kinh doanh có dịch chuyển không). Con số tuần đầu gần như luôn đẹp vì tò mò; con số tuần thứ sáu mới nói thật.

READOUT 6 TUẦN — "Trả sau"
Mục tiêu đặt ra: 8% người dùng đủ điều kiện kích hoạt; nợ quá hạn < 3%.
Kết quả: 6,1% kích hoạt; nợ quá hạn 2,2%.
Đánh giá: chưa đạt mục tiêu kích hoạt, đạt mục tiêu rủi ro.

Điều chúng ta học:
  1. 70% người kích hoạt đến từ màn hình thanh toán, chỉ 4% từ banner trang chủ.
  2. Người dùng dưới 25 tuổi kích hoạt gấp đôi nhóm còn lại nhưng hạn mức đầu
     quá thấp để mua món họ muốn (trung vị giỏ hàng gấp 1,6 lần hạn mức).
  3. 30% ticket là hỏi "tại sao tôi không đủ điều kiện" — màn hình từ chối thiếu lý do.

Quyết định:
  - Giữ tính năng, bỏ banner trang chủ, đầu tư điểm chạm ở màn hình thanh toán.
  - Thử nghiệm hạn mức đầu cao hơn cho nhóm có lịch sử tốt (cần rủi ro duyệt).
  - Viết lại màn hình từ chối, có lý do và cách cải thiện.
Ngày readout tiếp: sau 4 tuần thử nghiệm hạn mức.

Retro sau launch khác retro sprint: nó nhìn vào cả quy trình ra mắt, không chỉ việc của đội kỹ thuật. Bốn câu hỏi đủ dùng:

• Điều gì xảy ra đúng như kế hoạch, và vì sao — để giữ lại cho lần sau.
• Điều gì làm chúng ta bất ngờ — kỹ thuật, khách hàng, nội bộ.
• Tín hiệu nào lẽ ra đã báo trước, mà chúng ta không nhìn — đây là đầu vào cho pre-mortem lần sau.
• Sửa gì trong checklist và release plan mẫu của đội, để lần sau không phải nhớ.

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Phân tầng ba thứ sắp ra mắt của đội bạn. Với mỗi thứ, viết một câu vì sao nó thuộc tầng đó. Nếu cả ba đều là tier 1, đọc lại quy tắc chọn tầng.
• Lấy checklist ở trên, điền cho tính năng gần nhất sắp ra mắt. Đếm có bao nhiêu dòng bạn chưa chỉ ra được bằng chứng. Đó là danh sách việc của tuần này.
• Viết tiêu chí rollback bằng số cho một tính năng đang chạy. Đưa cho tech lead xem và hỏi: nếu chạm ngưỡng này lúc 11 giờ đêm, anh có tắt không? Nếu câu trả lời là "còn tuỳ", tiêu chí chưa đủ rõ.
• Hỏi support: "Lần ra mắt gần nhất, các bạn biết về nó khi nào và từ ai?" Câu trả lời sẽ cho bạn biết truyền thông nội bộ đang ở đâu.
• Tìm một tính năng đã ra mắt 1–2 tháng trước mà chưa có readout. Viết readout theo mẫu ở trên, kể cả khi số liệu chưa đẹp. Gửi cho sếp trực tiếp của bạn.