Product Management
Đăng nhập
ESC

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

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

Bài 3 — Phát hiện phụ thuộc & rủi ro sớm bằng AI

Vấn đề

Phụ thuộc (dependency) là kẻ giết sprint thầm lặng: story cần API của đội khác, chờ design duyệt, chờ legal, chờ dữ liệu từ hệ thống bên thứ ba. Nếu phát hiện vào giữa sprint, bạn không còn đường xoay. PO giỏi biến Planning thành nơi 'soi' phụ thuộc và rủi ro trước khi cam kết.

Vấn đề là quét thủ công tốn thời gian và dễ sót — mô tả story thường dài, phụ thuộc bị chôn trong ghi chú. Đây đúng là việc AI làm tốt: đọc nhanh, tìm mẫu, phân loại.

Hai loại cần soi

  • Phụ thuộc: điều kiện bên ngoài phải có trước khi story hoàn thành (đội khác, bên thứ ba, tài nguyên).
  • Rủi ro: điều có thể xảy ra làm hỏng kế hoạch (thiếu rõ yêu cầu, độ phức tạp kỹ thuật cao, người duy nhất biết việc đó nghỉ).

Ví dụ cụ thể

Bạn có 10 story. Dán mô tả cho AI, nó trả về ma trận: story #2 phụ thuộc team Data (chờ bảng mới), #5 rủi ro cao vì 'chưa rõ luồng thanh toán hoàn tiền', #8 phụ thuộc bên thứ ba (SMS gateway). AI còn gợi ý: #5 nên đưa vào refinement thêm trước khi cam kết. Bạn tách #5 ra khỏi sprint, xử lý phụ thuộc #2 và #8 ngay — sprint vào guồng sạch sẽ.

Prompt mẫu

Vai trò: Bạn là trợ lý quản lý rủi ro sprint.
Dưới đây là danh sách story dự kiến (mỗi story có mã và mô tả).
Hãy tạo một bảng gồm các cột: [Mã story] | [Loại: Phụ thuộc/Rủi ro/Không] | [Chi tiết] | [Bằng chứng: trích câu trong mô tả] | [Mức độ: Cao/Trung/Thấp] | [Hành động đề xuất cho PO].

Quy tắc:

  • Chỉ gắn cờ khi có bằng chứng trong mô tả. KHÔNG suy diễn phụ thuộc không có căn cứ.
  • Nếu không chắc, ghi 'cần xác minh' thay vì khẳng định.
  • Với mỗi phụ thuộc bên ngoài, đề xuất người/đội cần liên hệ.
[dán danh sách story ở đây]

Các bước làm

  • Gom mô tả tất cả story dự kiến vào một khối văn bản (ẩn thông tin nhạy cảm).
  • Chạy prompt soi phụ thuộc/rủi ro ở trên.
  • Rà bảng kết quả, kiểm tra từng bằng chứng — loại bỏ cảnh báo sai (ảo giác).
  • Với phụ thuộc bên ngoài: liên hệ đội liên quan NGAY trong ngày, xác nhận thời điểm sẵn sàng.
  • Với rủi ro 'chưa rõ yêu cầu': đưa story về refinement, không cam kết vội.
  • Cập nhật bảng, đưa vào ghi chú Planning làm 'danh sách theo dõi phụ thuộc'.

Template — 'Ma trận phụ thuộc & rủi ro'

StoryLoạiChi tiếtBằng chứngMức độAi xử lýHạn
#__Phụ thuộcChờ API Payment'cần endpoint...'CaoPO → team Xngày __
#__Rủi roYêu cầu mơ hồ'chưa rõ...'TBvề refinementtrước Planning
Quy tắc vàng: không cam kết story có phụ thuộc Cao chưa được xác nhận.

Mẹo nâng cấp: nhờ AI xếp thứ tự xử lý

Sau khi có ma trận, hãy hỏi thêm: 'Trong các phụ thuộc bên ngoài này, cái nào cần liên hệ sớm nhất dựa trên thời gian phản hồi thường thấy của đội khác, và soạn giúp tôi tin nhắn ngắn gọn gửi từng đội.' AI sẽ sắp thứ tự và viết nháp tin nhắn để bạn gửi ngay trong ngày — rút ngắn vòng chờ. Nhưng nhớ: AI không biết đội Payment thực tế phản hồi nhanh hay chậm, nên hãy tự điều chỉnh thứ tự theo kinh nghiệm của bạn.

Sai lầm thường gặp

  • Tin mọi cảnh báo AI đưa ra. AI dễ ảo giác phụ thuộc — ví dụ thấy chữ 'thanh toán' liền suy ra 'phụ thuộc team Payment' dù không có. Luôn kiểm bằng chứng trích dẫn.
  • Bỏ sót phụ thuộc ẩn không có trong chữ. AI chỉ thấy điều được viết ra. Kiến thức ngầm ('story này luôn cần DBA review') phải do bạn bổ sung.
  • Rò rỉ dữ liệu nhạy cảm. Mô tả story có thể chứa thông tin hợp đồng, tên khách. Ẩn danh trước khi dán vào công cụ công cộng.
  • Phụ thuộc quá mức, quên vai trò con người. Việc gọi điện, thương lượng thứ tự ưu tiên với đội khác là kỹ năng của PO — AI không làm thay được.
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