Tiếng Việt: Agentic Delivery

9 giờ sáng thứ Hai, bạn đang PM cho 3 sprint chạy song song trên 2 squad. Squad A báo trong standup rằng feature thanh toán "đang on track", nhưng bạn không biết rằng tối qua tech lead đã âm thầm descope phần validate số thẻ quốc tế vì "không đủ thời gian" — không ai báo cho bạn, không ai cập nhật Jira, và QA vẫn đang viết test case cho scope cũ. Squad B thì ngược lại: engineering đã âm thầm mở rộng scope thêm một API mới mà không ai review, khiến sprint trễ 2 ngày mà chẳng ai phát hiện cho đến demo. Bạn dành 40% thời gian trong tuần chỉ để chạy qua chạy lại giữa Jira, Slack, Figma và email để ráp lại một bức tranh thật về việc gì đang thực sự xảy ra.

Đây là bài toán kinh điển của giai đoạn Deliver trong vòng lặp agentic PM (Discover → Define/Plan → Deliver → Measure): thông tin bị phân mảnh giữa Product, Engineering và QA, còn PM thì trở thành "human API" chạy đi thu thập và đối chiếu dữ liệu thủ công. Agentic delivery giải quyết vấn đề này bằng cách để AI agent liên tục quan sát Jira, GitHub, Slack, Confluence trong thời gian thực, tự động sinh ra context document, status update, risk alert, và phát hiện scope creep hay quality gap ngay khi nó xuất hiện — trong khi PM giữ vai trò ra quyết định tại các checkpoint go/no-go quan trọng. Điểm mấu chốt của topic này: kết quả cuối sprint không nằm im trong một retro deck bị lãng quên — nó được AI tự động đóng gói và bơm ngược lại vào giai đoạn Discovery, khép kín toàn bộ vòng lặp agentic PM.

Dùng AI Để Duy Trì Sự Đồng Bộ Giữa Product, Engineering Và QA Trong Suốt Quá Trình Delivery

Sự lệch pha giữa Product, Engineering và QA hiếm khi xảy ra vì thiếu thiện chí — nó xảy ra vì mỗi bên đang nhìn vào một nguồn sự thật khác nhau: PM nhìn PRD trên Confluence, engineer nhìn ticket Jira và code trên GitHub, QA nhìn test plan trên một sheet riêng. Khi 3 nguồn này không đồng bộ real-time, độ trễ thông tin (information lag) tích lũy thành rủi ro delivery.

Agentic workflow xử lý việc này bằng cách để một agent (chạy qua n8n hoặc Zapier, kết nối Jira, GitHub, Confluence, Slack qua API/webhook) đóng vai trò "lớp đồng bộ" (sync layer): mỗi khi có thay đổi ở một hệ thống — ticket đổi status, PR được mở, comment mới trên Confluence — agent đọc thay đổi đó, đối chiếu với acceptance criteria gốc, và bơm một bản tóm tắt đã chuẩn hoá vào kênh Slack chung của cả 3 bên. Con người không cần tự tổng hợp — AI làm việc tổng hợp, con người chỉ cần xác nhận hoặc phản bác.

Các Bước Thực Hành

1. Thiết lập một "single source of truth" ảo: dùng Claude Code hoặc Jira/Confluence AI để tạo một context document sống (living doc) cho mỗi sprint, tự động kéo dữ liệu từ epic, ticket, PR liên quan mỗi ngày.
2. Kết nối agent giám sát 3 kênh: cấu hình n8n webhook lắng nghe sự kiện từ Jira (status change), GitHub (PR opened/merged), Confluence (page edited). Mỗi sự kiện được agent phân loại: "cập nhật thường" vs "cần cảnh báo lệch pha".
3. Đối chiếu tự động với acceptance criteria: khi PR được mở, agent dùng GitHub Copilot hoặc Claude Code để so sánh code diff với acceptance criteria trong ticket Jira, gắn cờ nếu phát hiện thiếu implement hoặc implement khác spec.
4. Đẩy bản tóm tắt vào Slack AI channel chung: mỗi cuối ngày, agent tổng hợp thành 1 tin nhắn ngắn gọn: "Ticket PROD-142 chuyển sang In Review, PR #88 đã merge nhưng thiếu validate input theo AC #3 — cần QA xác nhận."
5. PM review và xác nhận checkpoint: PM đọc bản tóm tắt (5 phút/ngày thay vì 40 phút chạy qua các tool), quyết định có cần escalate hay không — đây là checkpoint human-in-the-loop, AI không tự ý báo cáo lên leadership.

Ví Dụ Prompt

Bạn là trợ lý đồng bộ delivery cho một agile squad.
Dữ liệu đầu vào: nội dung ticket Jira PROD-142 (bao gồm acceptance criteria),
diff của PR #88 trên GitHub, và log test case hiện tại trên Confluence QA page.

Nhiệm vụ:
1. So sánh acceptance criteria của ticket với những gì PR #88 thực sự implement.
2. Liệt kê các AC nào đã được đáp ứng, AC nào chưa, AC nào bị thay đổi ngầm (không có ghi chú trong PR description).
3. Kiểm tra xem QA test case hiện tại có còn khớp với scope thực tế của PR không.
4. Xuất kết quả dưới dạng bảng: AC | Trạng thái implement | Trạng thái test coverage | Rủi ro lệch pha (Có/Không) | Ghi chú.
5. Nếu phát hiện AC bị descope hoặc mở rộng ngoài scope ban đầu, đánh dấu "CẦN PM XÁC NHẬN".

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bạn là agent tổng hợp cuối ngày cho sprint đang chạy.
Dữ liệu: lịch sử thay đổi trạng thái Jira trong 24h qua, PR mới mở/merge trên GitHub,
và các comment mới trên Confluence sprint page.

Viết một bản tóm tắt Slack ngắn (dưới 150 từ) cho kênh #squad-a-sync gồm:
- 3 cập nhật quan trọng nhất trong ngày
- 1 cảnh báo lệch pha (nếu có) giữa những gì Product kỳ vọng và những gì Engineering đang build
- Đề xuất 1 hành động cụ thể cho PM (ví dụ: "cần xác nhận với tech lead về AC #3")

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Đừng để agent tự động gửi cảnh báo thẳng lên kênh có cả stakeholder cấp cao — luôn route qua một kênh nội bộ squad trước, để PM lọc nhiễu (false positive) trước khi escalate. Một agent quá nhạy sẽ tạo "alert fatigue" (mệt mỏi vì cảnh báo) khiến cả team bắt đầu bỏ qua cảnh báo thật.

AI Tự Động Tạo Context Document, Status Update Và Risk Alert Xuyên Suốt Sprint

Một trong những công việc tốn thời gian nhất nhưng ít giá trị sáng tạo nhất của PM là viết lại cùng một thông tin dưới nhiều định dạng khác nhau: status update cho sếp, context doc cho engineer mới join, risk log cho steering committee. Agentic delivery biến đây thành việc AI tự sinh ra các tài liệu này từ cùng một nguồn dữ liệu sprint, PM chỉ review và điều chỉnh giọng văn/mức độ chi tiết cho từng đối tượng.

Khác biệt với báo cáo thủ công truyền thống: tài liệu này không phải "chụp ảnh" một lần vào cuối tuần, mà được AI cập nhật liên tục (near real-time) khi có sự kiện mới, giữ context luôn "nóng" — bất kỳ ai (kể cả một PM mới join giữa sprint) đọc vào cũng nắm được đầy đủ bối cảnh trong 5 phút.

Các Bước Thực Hành

1. Định nghĩa 3 loại tài liệu cần AI sinh tự động: (a) Context document — bối cảnh đầy đủ của sprint cho người mới; (b) Status update — báo cáo ngắn gọn cho stakeholder; (c) Risk alert — cảnh báo có ngưỡng kích hoạt rõ ràng.
2. Cấu hình nguồn dữ liệu cho từng loại: context doc kéo từ PRD + Jira epic + Confluence; status update kéo từ burndown chart + Jira velocity; risk alert kéo từ blocker tag, comment có từ khoá "blocked", "delay", "risk".
3. Thiết lập tần suất sinh tự động: context doc cập nhật mỗi khi có thay đổi lớn (epic mới, scope đổi); status update sinh mỗi cuối ngày hoặc theo lịch 2 lần/tuần; risk alert sinh ngay khi ngưỡng bị chạm (real-time, không đợi lịch).
4. Định nghĩa ngưỡng kích hoạt risk alert rõ ràng — tránh AI "báo động giả" liên tục (xem bảng dưới).
5. Review & approve trước khi phát hành ra ngoài squad: PM luôn là checkpoint cuối trước khi risk alert hoặc status update đi đến stakeholder cấp cao — đây là go/no-go gate của human-in-the-loop.

Ví Dụ Prompt

Bạn là trợ lý viết context document cho sprint hiện tại.
Dữ liệu đầu vào: PRD gốc, Jira epic PROD-140 với các sub-ticket, lịch sử comment
trong 2 tuần qua, và biên bản 2 buổi sprint planning gần nhất.

Viết một Context Document gồm:
1. Mục tiêu sprint (1 câu)
2. Bối cảnh vì sao feature này quan trọng (2-3 câu, link tới OKR nếu có)
3. Scope hiện tại đã confirm (bullet list)
4. Scope đã bị loại bỏ hoặc hoãn (bullet list, kèm lý do)
5. Các quyết định kỹ thuật quan trọng đã chốt và ai chốt
6. Người liên hệ chính cho từng phần (PM, tech lead, QA lead)

Viết sao cho một người hoàn toàn mới join giữa sprint đọc xong hiểu được toàn bộ bối cảnh trong 5 phút.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bạn là trợ lý tạo risk alert tự động.
Dữ liệu: danh sách ticket có tag "blocked" quá 2 ngày, PR mở quá 3 ngày chưa review,
và burndown chart cho thấy velocity giảm hơn 20% so với sprint trước.

Nếu bất kỳ điều kiện nào ở trên đúng, tạo một Risk Alert gồm:
- Loại rủi ro (Blocker / Review delay / Velocity drop)
- Mức độ nghiêm trọng (Thấp/Trung bình/Cao) kèm lý do định lượng
- Ảnh hưởng dự kiến đến ngày release nếu không xử lý
- Đề xuất 1-2 hành động khắc phục cụ thể
- Người cần được thông báo (role, không cần tên cụ thể)

Nếu không có điều kiện nào đúng, trả lời "Không có rủi ro cần cảnh báo hôm nay."
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bảng dưới đây là ví dụ thiết lập ngưỡng kích hoạt risk alert để agent không gây nhiễu:

Mẹo: Luôn định nghĩa ngưỡng bằng con số cụ thể (48 giờ, 20%, 3 ngày) chứ không phải mô tả mơ hồ như "chậm trễ đáng kể" — AI cần điều kiện định lượng để tránh subjective judgment sai lệch giữa các lần chạy.

Dùng AI Phát Hiện Scope Creep, Rủi Ro Delivery Và Lỗ Hổng Chất Lượng Theo Thời Gian Thực

Scope creep hiếm khi xuất hiện dưới dạng một quyết định lớn, rõ ràng — nó len lỏi qua hàng chục quyết định nhỏ: một comment "thêm luôn cái này cho tiện", một PR "tiện thể" sửa luôn một module không liên quan, một QA "test luôn case edge này dù không có trong AC". Từng quyết định đơn lẻ đều hợp lý, nhưng cộng dồn lại có thể khiến sprint trễ 30-40% mà không ai nhận ra cho đến ngày cuối.

Con người rất khó phát hiện creep dạng này vì nó xảy ra rải rác qua nhiều công cụ, nhiều ngày. Đây chính là việc AI agent làm tốt hơn con người: liên tục đối chiếu (diff) giữa baseline đã chốt (scope tại thời điểm sprint planning) với trạng thái hiện tại, phát hiện độ lệch tích luỹ theo thời gian thay vì chỉ nhìn một lát cắt.

Các Bước Thực Hành

1. Chốt baseline scope ngay khi bắt đầu sprint: xuất snapshot Jira epic + acceptance criteria thành một tài liệu "đóng băng" (frozen doc) trong Confluence, làm điểm mốc so sánh.
2. Thiết lập agent so sánh định kỳ (daily diff): mỗi ngày, agent so sánh trạng thái hiện tại của epic/ticket với baseline, tính "delta score" — số lượng thay đổi không nằm trong baseline gốc.
3. Phân loại loại rủi ro phát hiện được: scope creep (thêm việc), scope cut ngầm (bớt việc không thông báo), quality gap (thiếu test coverage), dependency risk (phụ thuộc bên ngoài trễ).
4. Định lượng ảnh hưởng đến ngày release: agent ước tính số story point/effort phát sinh và so với capacity còn lại của sprint, đưa ra cảnh báo khả năng miss deadline theo %.
5. PM chủ trì buổi review nhanh (15 phút) với dữ liệu AI đã tổng hợp sẵn — quyết định giữ, cắt, hoặc dời scope là quyết định của con người, AI chỉ cung cấp bằng chứng để quyết định nhanh và có căn cứ hơn.

Ví Dụ Prompt

Bạn là agent phát hiện scope creep.
Dữ liệu: baseline scope document đã chốt ngày đầu sprint (đính kèm),
và trạng thái hiện tại của tất cả ticket con thuộc epic PROD-140.

So sánh và trả lời:
1. Những task/ticket nào KHÔNG có trong baseline nhưng đang được làm? (liệt kê, kèm người tạo và ngày tạo)
2. Những AC nào trong baseline đã bị âm thầm bỏ hoặc thu hẹp phạm vi?
3. Ước tính tổng effort phát sinh (story point) so với capacity còn lại của sprint.
4. Tính % khả năng sprint bị trễ nếu không xử lý các mục trên.
5. Đề xuất: mục nào nên giữ lại (do giá trị cao), mục nào nên dời sang sprint sau.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bạn là agent kiểm tra quality gap giữa development và QA.
Dữ liệu: danh sách PR đã merge trong 3 ngày qua, và danh sách test case
hiện có trên QA tracking sheet cho cùng feature.

Xác định:
1. PR nào đã merge nhưng chưa có test case tương ứng.
2. Test case nào đang test một behavior đã bị thay đổi bởi PR gần đây (test case lỗi thời).
3. Ước tính rủi ro để lọt bug ra production nếu release đúng hạn mà không xử lý gap này
   (Thấp/Trung bình/Cao, kèm lý do).
4. Đề xuất ưu tiên: gap nào cần xử lý trước khi release, gap nào có thể chấp nhận rủi ro.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Mẹo: Chạy diff scope so với baseline mỗi ngày, không phải mỗi tuần — creep tích luỹ theo cấp số cộng mỗi ngày trễ phát hiện; phát hiện ở ngày 2 sửa mất 30 phút, phát hiện ở ngày 8 có thể mất cả buổi họp căng thẳng với leadership.

Khép Kín Feedback Loop — Kết Quả Sprint Do AI Tổng Hợp Quay Lại Nuôi Dưỡng Giai Đoạn Discovery

Đây là bước mà hầu hết team dừng lại quá sớm: sprint kết thúc, có một buổi retro, mọi người nói vài câu cảm nhận, rồi cả team lao ngay vào sprint tiếp theo. Insight thực sự — feature nào được dùng, giả định nào trong Discovery đã sai, ước lượng effort nào lệch xa thực tế — bị chôn trong Jira, GitHub và Amplitude/Mixpanel mà không ai quay lại đào lên.

Agentic delivery đóng vòng lặp bằng cách để AI tự động tổng hợp "sprint outcome package" ngay sau khi sprint kết thúc, và chủ động route package đó đến đúng nơi trong giai đoạn Discovery của topic 02 — nghĩa là: dữ liệu thực tế từ delivery trở thành input có cấu trúc cho vòng discovery kế tiếp, không phải một tài liệu nằm im trong drive.

Các Bước Thực Hành

1. Định nghĩa "sprint outcome package" chuẩn hoá: gồm 4 phần — kết quả đạt được so với hypothesis ban đầu, dữ liệu sử dụng thực tế (Amplitude/Mixpanel), độ lệch ước lượng (estimate vs actual effort), và danh sách giả định đã bị chứng minh sai.
2. Tự động kéo dữ liệu hành vi người dùng sau khi feature go-live: agent query Amplitude/Mixpanel để lấy adoption rate, retention, drop-off point trong 3-7 ngày đầu.
3. Đối chiếu với hypothesis gốc từ Discovery: agent so sánh kết quả thực tế với giả định đã ghi trong PRD/opportunity brief ở topic 02, đánh dấu confirmed/rejected/inconclusive.
4. Định tuyến outcome vào đúng backlog Discovery: dùng n8n để tự động tạo một "Discovery input card" trên bảng Discovery (Jira/Linear) kèm link tới sprint outcome, gắn tag nguồn gốc để traceable.
5. PM host một "closing the loop" review ngắn (30 phút) mỗi 2 sprint: xác nhận insight nào đủ mạnh để đưa vào roadmap tiếp theo — đây là go/no-go gate cuối cùng, quyết định insight nào thực sự thay đổi hướng đi sản phẩm.

Ví Dụ Prompt

Bạn là agent tổng hợp sprint outcome để đưa vào Discovery.
Dữ liệu: hypothesis gốc từ opportunity brief (đính kèm), dữ liệu adoption/retention
từ Amplitude cho feature vừa go-live 5 ngày, và ghi chú từ buổi sprint retro.

Tạo Sprint Outcome Package gồm:
1. Hypothesis ban đầu là gì, và kết quả thực tế cho thấy CONFIRMED / REJECTED / CHƯA ĐỦ DỮ LIỆU
2. 3 con số quan trọng nhất từ dữ liệu sử dụng thực tế (kèm so sánh với mục tiêu đã đặt)
3. Độ lệch giữa effort ước lượng ban đầu và effort thực tế, cùng nguyên nhân chính
4. Danh sách giả định đã bị chứng minh sai và cần được kiểm tra lại trong Discovery tiếp theo
5. Đề xuất 2-3 câu hỏi Discovery cụ thể nên đưa vào sprint khám phá kế tiếp

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bạn là agent định tuyến insight từ delivery quay lại Discovery backlog.
Dữ liệu: Sprint Outcome Package vừa tạo ở trên.

Với mỗi insight bị REJECTED hoặc CHƯA ĐỦ DỮ LIỆU, tạo một Discovery Input Card gồm:
- Tiêu đề ngắn gọn (dạng câu hỏi cần khám phá)
- Bối cảnh: vì sao insight này xuất hiện, link tới sprint nào
- Mức độ ưu tiên đề xuất (dựa trên mức ảnh hưởng tới business metric)
- Loại nghiên cứu Discovery phù hợp (user interview / usability test / data analysis / competitive scan)

Xuất kết quả dạng bảng sẵn sàng import vào Jira/Linear.
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh.

Bảng dưới minh hoạ cách một outcome cụ thể được ánh xạ ngược vào Discovery:

Mẹo: Đừng để "closing the loop" trở thành một nghi thức hình thức mỗi retro — gắn nó với một artifact cụ thể (Discovery Input Card có chủ sở hữu, có deadline) để insight không chết trong slide retro; nếu không có ai chịu trách nhiệm đọc và hành động, vòng lặp không bao giờ thực sự khép kín.

Những Điểm Chính Cần Nhớ

• Agentic delivery không thay thế PM trong việc ra quyết định — nó loại bỏ công việc thu thập, đối chiếu, tổng hợp thông tin thủ công, để PM dồn thời gian vào các checkpoint go/no-go thực sự cần phán đoán con người.
• Đồng bộ Product-Engineering-QA hiệu quả nhất khi có một agent đóng vai trò "sync layer" liên tục đối chiếu Jira, GitHub, Confluence, đẩy bản tóm tắt lệch pha vào kênh chung mỗi ngày thay vì đợi standup.
• Context document, status update và risk alert nên được AI sinh từ cùng một nguồn dữ liệu sprint nhưng với ngưỡng kích hoạt và tần suất khác nhau — risk alert phải real-time, không đợi lịch cố định.
• Phát hiện scope creep hiệu quả đòi hỏi baseline được "đóng băng" ngay đầu sprint và diff hàng ngày với baseline đó — creep tích luỹ theo thời gian, phát hiện càng sớm chi phí sửa càng thấp.
• Sprint outcome chỉ có giá trị khi được đóng gói chuẩn hoá và định tuyến chủ động vào Discovery backlog dưới dạng Discovery Input Card có chủ sở hữu — nếu không, insight sẽ chết trong slide retro.
• Mọi cảnh báo và outcome AI tạo ra đều cần một điểm review của con người trước khi lan ra ngoài squad hoặc ảnh hưởng đến roadmap — đây là bản chất của human-in-the-loop trong agentic PM workflow, không phải là bước thừa mà là bước bảo vệ chất lượng quyết định.