Retro sau ra mắt

Retro sau ra mắt dùng để làm gì?

Retro sprint nhìn vào hai tuần làm việc của một đội. Retro sau ra mắt nhìn vào cả quy trình đưa một thứ tới người dùng — từ lúc chốt tier đến readout — và có mặt những người không bao giờ dự retro sprint: support, sales, marketing, pháp chế, data.

Mẫu đi qua bốn câu hỏi: điều gì diễn ra đúng kế hoạch và vì sao; điều gì làm chúng ta bất ngờ; tín hiệu nào lẽ ra đã báo trước mà không ai nhìn; và sửa gì trong checklist, release plan, tiêu chí tier của đội để lần sau không phải nhớ. Câu cuối là lý do buổi retro tồn tại: một bài học không đi vào mẫu dùng chung sẽ bị quên trước lần ra mắt tiếp theo.

Retro này không tìm người có lỗi. Một lần ra mắt hỏng hầu như luôn là kết quả của một quy trình để lọt — một dòng checklist hỏi sai, một tiêu chí rollback không ai đọc — chứ không phải của một người lười. Khi mọi người sợ bị đổ lỗi, họ giấu đúng những thông tin mà retro cần.

Dành cho: PM (điều phối) · Tech lead · Support lead · Sales/CS · Marketing · Data · Head of Product cho tier 1

Dùng khi: Một đến hai tuần sau khi lên 100%, sau readout 2 tuần — đủ gần để mọi người còn nhớ, đủ xa để thấy hậu quả. Bắt buộc cho tier 1, cho mọi lần phải rollback, và cho mọi lần có sự cố mức 2 trở lên.

Khác gì với retro sprint và postmortem sự cố?

Nếu lần ra mắt có sự cố, postmortem kỹ thuật làm riêng trước và đem kết luận vào retro. Retro không đào lại nguyên nhân gốc của lỗi code; nó hỏi vì sao quy trình ra mắt đã không bắt được lỗi, hoặc không giảm được tác động của nó.

Bản trắng — copy và dán vào tài liệu của bạn

Buổi 60 phút. Mỗi người điền mục 2 riêng trước buổi họp; trong buổi chỉ gom nhóm, thảo luận và chốt mục 4.

RETRO SAU RA MẮT — [Tên tính năng] — Tier [......]
Ngày: ......   Người điều phối: ......
Người dự (mỗi mảng ít nhất một người): ......

1. DÒNG THỜI GIAN (PM chuẩn bị trước)
   Kickoff: ......   Go/no-go: ......   Các nấc: ......
   Sự cố / rollback: ......
   Readout 2 tuần — kết quả so với mục tiêu: ......

2. MỖI NGƯỜI VIẾT RIÊNG, TRƯỚC BUỔI HỌP
   2a. Diễn ra đúng kế hoạch, và vì sao: ......
   2b. Làm chúng ta bất ngờ (kỹ thuật / khách hàng / nội bộ): ......
   2c. Tín hiệu lẽ ra đã báo trước mà không ai nhìn: ......

3. GOM NHÓM TRONG BUỔI HỌP
   Chủ đề | Số người nêu | Thuộc bước nào của quy trình
     (tier / pre-mortem / checklist / release plan /
      truyền thông / ngày ra mắt / readout)

4. SỬA GÌ TRONG MẪU CỦA ĐỘI (tối đa 5)
   Sửa gì | Ở tài liệu nào | Người sửa | Hạn
   ......

5. GIỮ LẠI CHO LẦN SAU
   ......

6. CẦN NGƯỜI CẤP TRÊN GIẢI QUYẾT
   ......

KIỂM LẠI MỤC 4 VÀO NGÀY: ......   Người kiểm: ......

Từng ô điền gì, và vì sao ô đó tồn tại

Cách chạy buổi retro 60 phút

• Ba ngày trước: PM gửi dòng thời gian và mẫu trống. Nhờ mỗi người viết mục 2 riêng. Nói rõ trong lời mời: buổi này sửa quy trình, không đánh giá cá nhân.
• 0–5 phút: đọc dòng thời gian. Hỏi "có ai thấy thiếu mốc nào không?" và sửa ngay.
• 5–25 phút: mỗi người đọc ý của mình, PM gom nhóm. Chưa tranh luận. Mỗi chủ đề ghi số người cùng nêu.
• 25–45 phút: với ba chủ đề nhiều người nêu nhất, hỏi "bước nào của quy trình đã để lọt?" Nếu câu trả lời là tên một người, hỏi tiếp: "Quy trình nào lẽ ra đã giúp người đó không phải nhớ?"
• 45–55 phút: chốt mục 4. Mỗi thay đổi ghi rõ tài liệu nào, dòng nào, ai sửa, hạn. Tối đa năm thay đổi — nhiều hơn sẽ không ai làm.
• 55–60 phút: đọc lại mục 4 và 6. Người điều phối gửi biên bản trong ngày.
• Hai tuần sau: kiểm mục 4. Ở retro tiếp theo, mở lại danh sách thay đổi của lần trước trước khi làm bất cứ điều gì khác.

Ví dụ đã điền đầy đủ

Tiếp nối ví dụ HọcVui (giả định) — lộ trình cá nhân hoá phải lùi từ nấc 25% về 5% vì tỉ lệ hoàn thành bài kiểm tra đầu vào tụt trên điện thoại Android cũ. Retro diễn ra hai tuần sau khi lên 100%, có 9 người dự.

RETRO SAU RA MẮT — Lộ trình cá nhân hoá — Tier 2
Ngày: 15/07   Người điều phối: Khoa (PM)
Người dự: Nhung (Tech lead), 2 kỹ sư, Mai (QA), Hằng (Support lead),
  Tú (Marketing), Vân (Data), cô Lan (giáo viên nội dung), Khoa

1. DÒNG THỜI GIAN
   Kickoff 08/04 | Nội bộ 16/05 | Go/no-go 17/05 | Beta 20/05
   5% 02/06 | 25% 06/06 | LÙI về 5% 10/06, 21:00 | 25% lại 17/06
   50% A/B 24/06 | 100% 30/06
   Readout 2 tuần: hoàn thành 5 bài trong 14 ngày đạt 35,1% (mục tiêu
   36%), cao hơn nhóm đối chứng 3,8 điểm.

2. 9 bản viết riêng, gộp vào mục 3.

3. GOM NHÓM (số người nêu)                            Bước
   A. Lùi nấc diễn ra êm, không ai phải gọi ai (7)     Release plan
   B. Bài kiểm tra tải chậm trên Android cũ, QA
      không bắt được (5)                               Checklist
   C. Support nhận 30 ticket "bài quá dễ" ở beta,
      không chuyển cho đội sản phẩm vì nghĩ là
      phản hồi bình thường (3)                         Truyền thông nội bộ
   D. Giáo viên nội dung biết sau cùng, khi phụ
      huynh hỏi (2)                                    Tier / truyền thông
   E. Dashboard có nhóm đối chứng từ trước go/no-go,
      readout làm trong một buổi (4)                   Checklist

   Về B, mục 2c: Data đã thấy thời gian tải bài nghe ở phân vị 90 là
   6,8 giây trên Android 9 từ nấc beta. Nhưng không dòng nào trong
   checklist hỏi về thiết bị tầm thấp, nên con số không được đem ra
   go/no-go.
   Về C, mục 2c: Support có số liệu, nhưng không có kênh nào để báo
   "tín hiệu lạ" cho PM trong lúc rollout.

4. SỬA GÌ TRONG MẪU CỦA ĐỘI
   - Checklist, mảng QA: thêm dòng "luồng chính trên 3 thiết bị tầm
     thấp phổ biến nhất của người dùng (theo analytics); tải ở phân
     vị 90 dưới 3 giây"                              Mai, 22/07
   - Release plan mẫu: thêm mục "tín hiệu support phải báo ngay cho
     PM trong lúc rollout", kèm 3 ví dụ              Khoa, 22/07
   - Kênh release: support lead có mặt mặc định từ nấc beta
                                                     Hằng, làm ngay
   - Tiêu chí tier: thêm "thay đổi mà giáo viên hoặc phụ huynh nhìn
     thấy" vào điều kiện tier 2                      Khoa, 31/07

5. GIỮ LẠI CHO LẦN SAU
   - Tiêu chí rollback bằng số và quyền tắt của tech lead: Nhung tắt
     lúc 21 giờ, không cần họp, mất 4 phút.
   - Nhóm đối chứng dựng trước go/no-go.

6. CẦN NGƯỜI CẤP TRÊN
   - Đội không có điện thoại Android tầm thấp để thử. Đề xuất mua 4
     máy, khoảng 9 triệu. Gửi chị Phương (Head of Product).

KIỂM LẠI MỤC 4 VÀO NGÀY: 29/07   Người kiểm: Khoa

Chú ý cách nhóm B được xử lý. Câu dễ nói nhất là "QA đã không test kỹ". Retro hỏi tiếp: checklist có dòng nào yêu cầu thử trên thiết bị tầm thấp không? Không có. Và tín hiệu đã có sẵn từ nấc beta, nằm trong dashboard của data, nhưng không có đường nào đưa nó tới go/no-go. Kết quả là một dòng mới trong checklist, có ngưỡng bằng số — chứ không phải một lời nhắc "lần sau cẩn thận hơn". Lần ra mắt tiếp theo của HọcVui sẽ không phải nhớ điều này; mẫu đã nhớ hộ.

Hiccups thường gặp và cách xử lý

Vì sao vai trò của bạn cần cái này

Definition of done

• Dòng thời gian được gửi trước và được cả phòng xác nhận.
• Mỗi người viết riêng trước buổi họp, kể cả support và sales.
• Mỗi chủ đề được gắn với một bước của quy trình ra mắt.
• Có ít nhất một tín hiệu lẽ ra đã báo trước, ghi lại làm đầu vào cho pre-mortem lần sau.
• Tối đa năm thay đổi cụ thể trong mẫu của đội, mỗi thay đổi có người và hạn.
• Có ngày kiểm lại, và hai tuần sau các thay đổi đã được kiểm.