Product Review & Kickoff Facilitation

Delivery

Chạy kickoff và các buổi review sao cho ra được quyết định: mục tiêu, non-goals, RACI, ba cổng review, pre-read và nhật ký quyết định.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Delivery cho PM/PO — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Delivery, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Hiểu kickoff, review và họp cập nhật là ba loại khác nhau, và biết một kickoff cần chốt mục tiêu, non-goals, chỉ số thành công, vai trò, rủi ro và mốc. Biết review chỉ có ý nghĩa khi có một người quyết được nêu tên.

Khi đã làm được

Viết tài liệu kickoff gửi trước và dùng buổi họp để tìm chỗ bất đồng; tổ chức ba cổng review (vấn đề, giải pháp, ra mắt) với đúng thứ cần mang ở mỗi cổng; dùng pre-read, người quyết có tên và nhật ký quyết định; và briefing sếp cùng stakeholder trước mỗi buổi review quan trọng để không ai bị bất ngờ trong phòng họp.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/8 mục · còn khoảng 9 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Họp nhiều mà không có quyết định

Một PM ở công ty cỡ vừa có thể dành 15 giờ mỗi tuần trong họp. Phần lớn các buổi đó kết thúc bằng câu "để em tổng hợp rồi gửi lại", và tuần sau lại họp về đúng chủ đề ấy. Vấn đề hiếm khi là con người. Vấn đề là buổi họp không được thiết kế để ra quyết định: không ai biết họp để quyết gì, ai quyết, và cần biết gì trước khi vào phòng.

Kỹ năng này gồm hai loại buổi họp quan trọng nhất của một PM: kickoff (mọi người đồng ý làm gì và vì sao) và review (một người có thẩm quyền quyết đi tiếp hay không, ở từng mốc). Hai loại này khác hẳn buổi cập nhật tình hình, và nhầm lẫn giữa chúng là nguyên nhân của nhiều giờ họp vô ích.

Loại họp	Mục đích	Kết quả phải có	Nếu thiếu
Kickoff	Đồng thuận mục tiêu, phạm vi, vai trò trước khi làm	Tài liệu kickoff đã được mọi bên xác nhận	Ba tuần sau mới phát hiện mỗi người hiểu một kiểu
Review	Ra một quyết định ở một mốc	Quyết định có ghi lại: đi tiếp, sửa, dừng	Đội làm tiếp trên một giả định chưa ai duyệt
Cập nhật tình hình	Chia sẻ thông tin	Không cần quyết định	Nên thay bằng tin nhắn hoặc tài liệu

Quy tắc nhanh: nếu buổi họp không có quyết định nào cần đưa ra, nó có thể là một tin nhắn. Nếu có quyết định mà không biết ai quyết, nó sẽ là một cuộc tranh luận.

Kickoff: sáu thứ phải được đồng ý trước khi viết dòng code đầu tiên

Kickoff không phải buổi giới thiệu dự án. Nó là buổi chốt những điều mà nếu hiểu sai, cả đội sẽ làm sai trong nhiều tuần. PM chuẩn bị tài liệu, gửi trước, và dùng buổi họp để tìm chỗ bất đồng — không phải để đọc tài liệu.

Mục	Câu hỏi	Vì sao không được bỏ
Mục tiêu	Vấn đề gì của ai, vì sao giải quyết bây giờ?	Không có, đội tối ưu cho điều mình đoán
Không làm (non-goals)	Những gì nghe liên quan nhưng chúng ta cố ý không làm lần này?	Không có, phạm vi phình theo mỗi buổi họp
Chỉ số thành công	Đo bằng gì, bao nhiêu thì đạt, khi nào đo?	Không có, ra mắt xong không biết thành công hay không
Vai trò (RACI)	Ai làm, ai chịu trách nhiệm cuối cùng, ai được hỏi ý kiến, ai chỉ cần được báo?	Không có, mọi quyết định thành cuộc họp
Rủi ro	Ba rủi ro lớn nhất và ai theo dõi?	Không có, rủi ro được phát hiện khi đã thành sự cố
Mốc	Các mốc review, ngày ra mắt dự kiến, tầng launch	Không có, không ai biết khi nào được góp ý

Non-goals là mục bị xem nhẹ nhất và có giá trị nhất. Viết "lần này không hỗ trợ hoàn tiền một phần" ngay từ đầu tiết kiệm được ba cuộc tranh luận về sau, khi sales hứa với khách. Nó cũng cho người khác cơ hội phản đối bây giờ, khi còn rẻ.

Về RACI: chỉ cần một chữ A cho mỗi loại quyết định lớn — phạm vi, thiết kế, kỹ thuật, ngày ra mắt. Hai chữ A cho một quyết định nghĩa là không ai quyết.

Chương trình kickoff 60 phút: 10 phút PM tóm tắt vấn đề và mục tiêu; 15 phút hỏi đáp về phạm vi và non-goals; 10 phút về chỉ số thành công; 10 phút RACI; 10 phút rủi ro và mốc; 5 phút chốt những điểm còn mở, ai trả lời, trước ngày nào.

Mẫu tài liệu kickoff — ví dụ đã điền

Bối cảnh (giả định): một công ty outsourcing ở Đà Nẵng xây ứng dụng đặt lịch bảo dưỡng cho một chuỗi đại lý xe máy với 60 cửa hàng. PM phía công ty outsourcing viết tài liệu này và gửi cho cả đội lẫn đại diện khách hàng hai ngày trước kickoff.

KICKOFF — Đặt lịch bảo dưỡng online — v1.2 — gửi trước 2 ngày

1. VẤN ĐỀ VÀ MỤC TIÊU
Khách đặt lịch qua điện thoại; tổng đài quá tải giờ cao điểm, 25% cuộc gọi
nhỡ (số liệu của khách, tháng 6). Mục tiêu: khách tự đặt lịch trên Zalo
Mini App và web; giảm cuộc gọi đặt lịch.

2. KHÔNG LÀM LẦN NÀY
- Thanh toán trước online (giai đoạn 2)
- Ứng dụng iOS/Android riêng
- Đồng bộ với phần mềm kho phụ tùng
- Đặt lịch cho xe ô tô

3. CHỈ SỐ THÀNH CÔNG (đo sau 8 tuần)
- 30% lịch hẹn đến từ kênh online (hiện tại 0%)
- Cuộc gọi đặt lịch giảm 20%
- Tỉ lệ khách đến đúng hẹn >= 80% (bảo vệ: không được giảm so với đặt qua điện thoại)

4. VAI TRÒ
Quyết định              | R (làm)       | A (chốt)          | C (hỏi ý)      | I (báo)
Phạm vi, ưu tiên        | PM            | Giám đốc vận hành khách | Tech lead | Đội
Thiết kế giao diện      | Designer      | PM                | 3 quản lý cửa hàng | Khách
Kiến trúc kỹ thuật      | Tech lead     | Tech lead         | IT của khách   | PM
Ngày ra mắt             | PM            | Giám đốc vận hành khách | Đội, QA | Tổng đài

5. RỦI RO
- API lịch của phần mềm cửa hàng hiện tại chưa có tài liệu — Chủ: Tech lead
- Quản lý cửa hàng không cập nhật lịch trống — Chủ: PM + khách
- Duyệt Zalo Mini App mất thời gian hơn dự kiến — Chủ: Tech lead

6. MỐC
Tuần 2: problem review (đã có sẵn số liệu cuộc gọi)
Tuần 4: solution review với prototype
Tuần 9: launch review, pilot 5 cửa hàng — Tier 2
Tuần 12: mở 60 cửa hàng

ĐIỂM CÒN MỞ (trả lời trước thứ Sáu)
- Cửa hàng có được từ chối lịch online không? — Khách trả lời
- Nhắc lịch qua SMS hay ZNS? Ai trả phí? — Khách trả lời

Để ý mục "Điểm còn mở": kickoff tốt không giả vờ đã có hết câu trả lời. Nó ghi câu hỏi, người trả lời và hạn. Và chỉ số bảo vệ ở mục 3 ngăn đội tối ưu số lịch online bằng cách làm khách đặt bừa rồi không đến.

Ba cổng review: vấn đề, giải pháp, ra mắt

Thay vì một buổi "review thiết kế" mơ hồ khi mọi thứ đã gần xong, chia thành ba cổng. Mỗi cổng trả lời một câu hỏi khác nhau, và mang sai thứ tới sai cổng là cách nhanh nhất để lãng phí một buổi họp — mang giao diện hoàn chỉnh tới buổi bàn về vấn đề khiến mọi người góp ý màu nút thay vì hỏi có nên làm không.

Cổng	Câu hỏi	Mang theo	Không mang	Người quyết
Problem review	Vấn đề này có thật, đủ lớn, và đáng làm bây giờ không?	Bằng chứng: số liệu, trích phỏng vấn, ticket; ai bị ảnh hưởng; vì sao bây giờ; mục tiêu đo được	Giải pháp, giao diện	Head of Product hoặc người sở hữu ngân sách
Solution review	Hướng giải pháp này có giải được vấn đề, khả thi, và đáng chi phí không?	2–3 phương án đã cân nhắc và vì sao chọn một; prototype hoặc luồng; ước lượng thô; rủi ro chính từ pre-mortem	Thiết kế pixel hoàn chỉnh	PM chốt, sau khi nghe design và tech lead
Launch review	Đã sẵn sàng đưa tới người dùng chưa?	Checklist launch có bằng chứng; kết quả beta; release plan; tiêu chí rollback	Tranh luận lại phạm vi	Người đã được nêu tên trong kickoff

Cổng thường bị bỏ qua là problem review, vì đội nóng lòng đi vào giải pháp. Nhưng đây là cổng rẻ nhất để nói không: dừng ở đây tốn hai tuần nghiên cứu; dừng ở launch review tốn ba tháng xây.

Với công ty nhỏ, ba cổng không cần ba buổi họp trang trọng. Có thể là ba tài liệu một trang và ba cuộc trao đổi 30 phút với sếp. Điều quan trọng là thứ tự: đồng ý vấn đề trước, rồi mới đến giải pháp, rồi mới đến ra mắt.

Làm cho review ra được quyết định

Ba công cụ biến một buổi review từ "góp ý" thành "quyết định":

Pre-read. Tài liệu gửi trước ít nhất một ngày làm việc, dài không quá hai trang, mở đầu bằng quyết định cần đưa ra và đề xuất của bạn. Mười phút đầu buổi họp dành cho đọc im lặng — vì thực tế phần lớn người dự sẽ không đọc trước, và thừa nhận điều đó tốt hơn giả vờ.
Người quyết có tên. Ghi ngay dòng đầu pre-read: "Người quyết: chị Lan, Head of Product." Những người khác được góp ý, nhưng buổi họp kết thúc bằng câu của người quyết. Nếu người quyết không dự được, dời buổi họp — đừng họp để rồi họp lại.
Nhật ký quyết định. Một bảng chung, mỗi quyết định một dòng. Sau ba tháng, khi có người hỏi "sao hồi đó lại chọn vậy?", câu trả lời nằm ở đó thay vì trong trí nhớ của ai đó đã nghỉ việc.

Ngày	Quyết định	Phương án đã loại	Lý do	Người quyết	Xem lại khi
12/8	Pilot 5 cửa hàng ở Đà Nẵng trước, không mở cả 60	Mở toàn bộ cùng lúc	Quản lý cửa hàng cần thời gian làm quen; tổng đài muốn so sánh hai nhóm	Giám đốc vận hành khách	Sau 3 tuần pilot
19/8	Nhắc lịch qua ZNS, không qua SMS	SMS	Rẻ hơn khoảng một nửa với lượng tin dự kiến; khách đã có Zalo OA	PM	Nếu tỉ lệ nhận tin dưới 85%

Cột "Xem lại khi" làm cho quyết định không phải là vĩnh viễn — và vì vậy dễ chốt hơn. Người ta chấp nhận một quyết định chưa hoàn hảo dễ hơn nhiều khi biết nó sẽ được xem lại ở một điều kiện cụ thể.

Cuối mỗi buổi review, đọc to: "Quyết định là... Việc tiếp theo là... do ai, trước ngày nào." Nếu không đọc được câu này, buổi họp chưa xong.

Làm việc với stakeholder và với sếp trực tiếp

Không ai trong buổi review nên nghe một điều quan trọng lần đầu tiên trong phòng họp. Một người lãnh đạo bị bất ngờ trước mặt người khác sẽ phản ứng để bảo vệ mình, không phải để giúp dự án. Vì vậy phần lớn công việc của review diễn ra trước review.

Ai	Gặp trước để	Hình thức
Sếp trực tiếp	Thống nhất đề xuất; biết sếp sẽ ủng hộ hay đặt câu hỏi gì	Briefing 15 phút, 1–2 ngày trước
Người quyết	Không để họ bất ngờ với đề xuất hay rủi ro lớn	Gửi pre-read sớm, hỏi có muốn trao đổi trước không
Người có thể phản đối	Nghe lo ngại của họ khi còn sửa được đề xuất	Gặp riêng, hỏi "anh lo nhất điều gì?"
Đội làm	Chắc chắn đề xuất phản ánh đúng ước lượng và rủi ro của họ	Đọc nháp pre-read cùng tech lead và designer

Briefing với sếp — năm câu đủ dùng:

"Thứ Năm em sẽ xin quyết định về... Đề xuất của em là..."
"Lý do chính là... Phương án em đã loại là... vì..."
"Rủi ro lớn nhất em thấy là..., và em định xử lý bằng..."
"Người em nghĩ sẽ có ý kiến khác là..., vì... Em đã nói chuyện với họ / định nói chuyện trước."
"Anh/chị thấy có gì em đang thiếu, hoặc có gì anh/chị không thoải mái ủng hộ không?"

Câu cuối quan trọng nhất. Nếu sếp có điều không thoải mái, bạn muốn biết điều đó trong phòng riêng hôm thứ Ba, không phải trong phòng họp hôm thứ Năm.

Với BA và PO làm việc với khách hàng outsourcing, "sếp" thường gồm cả đại diện khách. Một cuộc gọi ngắn trước buổi demo hay review với khách để báo trước chỗ chưa xong và chỗ cần họ quyết sẽ đổi một buổi họp căng thẳng thành một buổi làm việc.

Lỗi thường gặp

Lỗi	Vì sao xảy ra	Làm thay bằng
Kickoff thành buổi đọc slide	PM trình bày thay vì tìm chỗ bất đồng	Gửi trước; dùng thời gian họp cho câu hỏi và điểm còn mở
Không có non-goals	Sợ nói "không" với stakeholder	Viết non-goals từ đầu; nói không lúc rẻ nhất
Review mà không ai quyết	Không ghi tên người quyết; người quyết vắng	Tên người quyết ở dòng đầu pre-read; vắng thì dời
Mang giao diện tới problem review	Muốn cho thấy tiến độ	Mỗi cổng mang đúng thứ của cổng đó
Quyết xong rồi quên, ba tháng sau cãi lại	Không có nhật ký quyết định	Mỗi quyết định một dòng, có lý do và điều kiện xem lại
Sếp phản đối trước mặt mọi người	Sếp nghe đề xuất lần đầu trong phòng họp	Briefing 15 phút trước mỗi review quan trọng
Hai người cùng là "A"	RACI viết cho có	Một chữ A cho mỗi loại quyết định

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

Nhìn lịch họp tuần này. Với mỗi buổi bạn chủ trì, viết một dòng: quyết định cần đưa ra là gì, ai quyết. Buổi nào không viết được, đổi thành tin nhắn hoặc tài liệu.
Viết non-goals cho dự án đang chạy — ít nhất bốn dòng — và gửi cho đội cùng stakeholder chính. Xem có ai phản đối không. Nếu có, bạn vừa tránh được một cuộc tranh luận về sau.
Lập nhật ký quyết định cho dự án của bạn, điền ngược 5 quyết định gần nhất mà bạn còn nhớ lý do. Bạn sẽ ngạc nhiên vì đã quên bao nhiêu.
Trước buổi review tiếp theo, làm briefing 15 phút với sếp theo năm câu ở trên. Sau buổi review, so xem có bao nhiêu câu hỏi của sếp bạn đã chuẩn bị sẵn.
Viết pre-read hai trang cho quyết định sắp tới, mở đầu bằng quyết định cần đưa ra và đề xuất. Nhờ một đồng nghiệp đọc và hỏi: "Đọc xong, bạn biết mình đang được hỏi gì chưa?"