Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 5 — Chuẩn bị Sprint & giao tiếp stakeholder bằng AI

Đã đọc 0/11 mục · còn khoảng 5 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.

Bối cảnh & vấn đề

Quanh mỗi sprint, PO phải soạn sprint goal, agenda planning, cập nhật tiến độ, viết release note, và trả lời email stakeholder. Đây là khối lượng viết lách khổng lồ và lặp lại. AI có thể sinh bản nháp cho tất cả, giúp bạn giữ giọng nhất quán và tiết kiệm hàng giờ mỗi sprint — miễn là bạn cấp đúng dữ liệu và kiểm lại số liệu.

Ba khu vực AI hỗ trợ mạnh nhất

  • Sprint goal & agenda: từ danh sách story ưu tiên, AI đề xuất một sprint goal mạch lạc và agenda planning có thời lượng.
  • Release note & changelog: từ danh sách item đã hoàn thành, AI viết release note theo giọng phù hợp người đọc (khách hàng vs nội bộ).
  • Email/cập nhật stakeholder: từ trạng thái thật, AI viết bản cập nhật ngắn gọn, minh bạch về rủi ro.

Ví dụ cụ thể

Cuối sprint bạn có 8 item đã done. Bạn dán tiêu đề 8 item vào AI, yêu cầu viết release note cho khách hàng (bỏ chi tiết kỹ thuật, nhấn lợi ích) và một bản cho nội bộ (kèm chi tiết kỹ thuật). Hai phút có hai bản nháp, bạn chỉ tinh chỉnh.

Prompt mẫu

Tôi là PO. Đây là các item đã hoàn thành trong sprint (tiêu đề):
- Đăng nhập bằng sinh trắc học
- Sửa lỗi mất giao dịch khi mất mạng
- Cải thiện tốc độ tải màn hình lịch sử
Viết 2 phiên bản release note tiếng Việt:
(A) Cho KHÁCH HÀNG: nhấn lợi ích, không dùng thuật ngữ kỹ thuật, giọng thân thiện.
(B) Cho NỘI BỘ: liệt kê thay đổi kỹ thuật, tác động, và điều QA cần chú ý.
KHÔNG thêm tính năng nào ngoài danh sách trên. Không phóng đại kết quả.

Câu "không thêm tính năng ngoài danh sách" và "không phóng đại" là rào chắn chống ảo giác — AI hay tự "tô hồng" hoặc thêm tính năng không có.

Các bước làm

  • Xuất danh sách item done từ Jira/Trello (chỉ tiêu đề, tránh dữ liệu nhạy cảm).
  • Chọn đối tượng đọc và giọng văn.
  • Chạy prompt, lấy bản nháp.
  • Đối chiếu từng dòng với thực tế: có đúng đã làm không, có phóng đại không.
  • Rà số liệu (ví dụ "nhanh hơn 30%") — chỉ giữ nếu bạn có bằng chứng.
  • Chốt, gửi, và lưu lại làm mẫu cho sprint sau.

Template tái dùng: Gói giao tiếp cuối sprint

Sprint Goal: [1 câu]
Đã hoàn thành: [danh sách item]
Chưa xong / dời sprint: [item + lý do]
Rủi ro & phụ thuộc nổi bật: [ ]
Release note (khách hàng): [ ]
Release note (nội bộ): [ ]
Cập nhật stakeholder (3 câu: tiến độ / rủi ro / cần hỗ trợ gì): [ ]

Sai lầm thường gặp

  • Để AI "tô hồng" tiến độ: AI phóng đại kết quả hoặc thêm số liệu bịa nghe hoành tráng — làm mất niềm tin khi stakeholder phát hiện. Luôn kiểm số.
  • Copy số liệu chưa kiểm: "tăng 40% hiệu năng" mà không có đo lường thật là rủi ro uy tín.
  • Rò rỉ thông tin roadmap: dán cả roadmap chưa công bố vào công cụ công cộng — rò rỉ dữ liệu chiến lược.
  • Một giọng cho mọi đối tượng: gửi bản kỹ thuật cho khách hàng hoặc bản marketing cho dev. Luôn chọn đúng phiên bản.
  • Phụ thuộc quá mức vào bản cập nhật tự động: mất khả năng tự tóm tắt và cảm nhận "sức khỏe" sprint.
<!--les-append-->

Chống tô hồng: một quy tắc cấu trúc

"AI tô hồng tiến độ" không sửa được bằng cách nhắc AI trung thực — nó sửa được bằng cách ép cấu trúc bản cập nhật:

> Viết bản cập nhật theo đúng bốn phần, mỗi phần tối đa 3 dòng: > 1. Đã hoàn thành và đã được nghiệm thu > 2. Đang vướng, và cần ai gỡ > 3. Thay đổi so với kế hoạch > 4. Phần còn lại đang đúng tiến độ > > Nếu phần 2 hoặc 3 trống, ghi rõ "không có" — không được bỏ mục.

Phần 2 và 3 là phần stakeholder thật sự cần, và là phần AI sẽ bỏ nếu bạn không ép. Câu cuối quan trọng: một bản cập nhật không có mục "đang vướng" đọc như mọi thứ đều ổn, và đó chính là cách niềm tin bị xói mòn khi sự thật lộ ra sau.

Phân biệt trong phần 1 cũng đáng nhấn: "đã hoàn thành" phải là đã được nghiệm thu, không phải "dev báo xong". Hai thứ này khác nhau và chúng hay bị gộp trong bản cập nhật cuối sprint.

Ba phiên bản cho ba đối tượng

"Một giọng cho mọi đối tượng" là sai lầm bài trên nêu. Cụ thể, ba phiên bản khác nhau về nội dung, không chỉ về giọng:

Đối tượngHọ cần biếtBỏ gì
Khách hàngCái gì dùng được bây giờ, làm thế nàoTên nội bộ, lý do kỹ thuật, số story
Ban lãnh đạoTiến độ so với cam kết, rủi ro, cần quyết gìChi tiết triển khai
Đội kỹ thuậtCái gì đổi, ảnh hưởng gì tới họNgôn ngữ marketing
Sai lầm hay gặp nhất: gửi bản cho ban lãnh đạo kèm số story hoàn thành. Số đó không nói gì về giá trị, và nó khiến người đọc kết luận sai — 12 story nhỏ nghe nhiều hơn 3 story lớn.

Với ban lãnh đạo, thay số story bằng: cái gì khách dùng được rồi, cái gì còn thiếu so với cam kết, quyết định nào đang cần họ.

Sprint goal: dấu hiệu một goal kém

AI đề xuất sprint goal rất nhanh và rất dễ ra một goal vô nghĩa. Ba dấu hiệu:

  • Nó là danh sách story viết lại thành câu. "Hoàn thành US-1, US-2 và US-3" không phải một goal.
  • Nó không nói ai được lợi gì. Một goal tốt trả lời: sau sprint này, ai làm được gì mà trước đây không làm được.
  • Không kiểm được đã đạt hay chưa. Nếu cuối sprint phải tranh luận xem có đạt goal không, goal viết chưa xong.
Phép thử nhanh: nếu bỏ một story ra khỏi sprint mà goal vẫn đạt, thì story đó không thuộc goal này — và đó là thông tin hữu ích khi phải cắt phạm vi giữa sprint.

Điều không nên giao cho AI

Nhắc lại một ranh giới: đừng để AI viết bản cập nhật khi tiến độ xấu. Đó là lúc từng chữ quan trọng, lúc cần bạn nhận trách nhiệm bằng giọng của chính mình, và lúc một bản nháp trôi chảy do máy viết dễ nghe như đang tránh vấn đề.

Dùng AI cho bản cập nhật thường lệ; tự viết bản cập nhật khi có tin xấu. <!--/les-append-->

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi