Đây là bài thực hành tổng hợp, nơi bạn áp dụng toàn bộ kỹ năng đã học trong module này — viết user story, dựng PRD, chuyển đổi sang technical spec, kiểm tra chất lượng bằng INVEST — vào một tình huống duy nhất, xuyên suốt từ đầu đến cuối. Khác với các bài trước, nơi mỗi kỹ thuật được minh họa bằng ví dụ riêng lẻ, bài này theo sát MỘT feature brief thực tế từ lúc còn là ý tưởng thô cho đến khi trở thành một requirements package hoàn chỉnh, sẵn sàng bàn giao cho cả stakeholder kinh doanh lẫn đội engineering. Đây chính là quy trình bạn sẽ lặp lại trong công việc thật mỗi khi nhận một feature request mới.
Tình huống thực hành: bạn là Product Owner tại một ứng dụng ví điện tử tên "VíThông Minh". Ban lãnh đạo vừa yêu cầu xây dựng tính năng "Chương trình giới thiệu bạn bè" (Referral Program) — cho phép user hiện tại mời bạn bè dùng app, cả hai bên đều nhận thưởng khi bạn bè hoàn tất giao dịch đầu tiên. Đây là feature có độ phức tạp vừa phải, chạm đến nhiều module (Auth, Wallet, Notification, Fraud Detection), đủ tiêu biểu để bạn thực hành toàn bộ quy trình.
Bắt Đầu Từ Feature Brief Và Sinh Epic, User Story, Acceptance Criteria
Feature brief ban đầu bạn nhận được từ CEO, qua một tin nhắn Slack ngắn gọn: "Team Marketing đề xuất làm referral program, đối thủ đã có tính năng này 6 tháng nay, mình cần launch trong quý này. Ý tưởng chung: user mời bạn, cả hai nhận thưởng khi bạn hoàn tất giao dịch đầu tiên." Đây là dạng input thô kinh điển — đủ để hiểu ý tưởng lớn, nhưng thiếu gần như mọi chi tiết cần thiết để bắt đầu viết story.
Bước 1: Làm Giàu Feature Brief Trước Khi Đưa Vào AI
Trước khi prompt AI, bạn cần bổ sung ngữ cảnh tối thiểu: ai là actor (người giới thiệu — referrer, người được giới thiệu — referee), phần thưởng cụ thể là gì (giả sử: mỗi bên nhận 50.000đ vào ví khi referee hoàn tất giao dịch đầu tiên tối thiểu 100.000đ), và các ràng buộc đã biết (ngân sách thưởng giới hạn 500 triệu/tháng, cần cơ chế chống gian lận vì đã có tiền lệ ở đối thủ bị lợi dụng tạo tài khoản ảo).
Bước 2: Sinh Danh Sách Epic Từ Feature Brief Đã Làm Giàu
Bạn là một Product Owner giàu kinh nghiệm trong lĩnh vực ví điện tử.
Feature Brief:
- Tên: Chương trình Giới thiệu bạn bè (Referral Program).
- Mục tiêu kinh doanh: Tăng số lượng user mới qua kênh referral lên
15% tổng số user mới trong quý, giảm chi phí acquisition so với
quảng cáo trả phí.
- Cơ chế: User hiện tại (referrer) chia sẻ mã giới thiệu. Bạn bè
(referee) đăng ký bằng mã đó. Khi referee hoàn tất giao dịch đầu
tiên tối thiểu 100.000đ, cả referrer và referee đều nhận 50.000đ vào
ví.
- Ràng buộc: Ngân sách thưởng giới hạn 500 triệu đồng/tháng. Cần cơ
chế chống gian lận (đã có tiền lệ đối thủ bị lợi dụng tạo tài khoản
ảo để nhận thưởng). Launch trong quý này (10 tuần).
- Hệ thống hiện tại: có module Auth, Wallet, Notification, và một
Fraud Detection Engine cơ bản (rule-based, chưa có ML).
Hãy:
1. Đề xuất tối đa 4 Epic cần thiết để triển khai đầy đủ feature này,
mỗi epic có tên rõ ràng và mô tả 2-3 câu về phạm vi.
2. Với mỗi epic, liệt kê epic đó phục vụ trực tiếp phần nào của mục
tiêu kinh doanh (tăng trưởng user, chống gian lận, trải nghiệm
người dùng).
3. Đề xuất thứ tự ưu tiên triển khai các epic, có giải thích lý do
(epic nào là nền tảng bắt buộc phải có trước).
Trả lời bằng tiếng Việt.
Kết quả AI đề xuất (đã được review và chốt): Epic 1 — Tạo và chia sẻ mã giới thiệu, Epic 2 — Ghi nhận và thưởng khi giao dịch đầu tiên hoàn tất, Epic 3 — Cơ chế chống gian lận referral, Epic 4 — Dashboard theo dõi referral cho user. Thứ tự ưu tiên: Epic 1 và 2 là nền tảng bắt buộc (must-have cho launch), Epic 3 phải song song với Epic 2 vì rủi ro tài chính, Epic 4 có thể làm sau launch.
Bước 3: Sinh User Story Và Acceptance Criteria Cho Epic Ưu Tiên Cao Nhất
Dưới đây là Epic 2 — "Ghi nhận và thưởng khi giao dịch đầu tiên hoàn
tất" — thuộc Chương trình Giới thiệu bạn bè đã mô tả ở trên.
Hãy sinh 4 user story cho epic này, mỗi story theo format "Là một
[role], tôi muốn [goal], để [benefit]", kèm acceptance criteria dạng
Given-When-Then, bao phủ:
1. Story chính: ghi nhận giao dịch đầu tiên của referee đạt điều kiện
thưởng.
2. Story: thông báo cho cả hai bên khi thưởng được cộng vào ví.
3. Story: xử lý trường hợp referee hủy/hoàn tiền giao dịch đầu tiên
sau khi đã được ghi nhận (cần thu hồi thưởng hay không).
4. Story: giới hạn số lần một user có thể làm referrer nhận thưởng
trong một tháng (áp ngân sách 500 triệu/tháng).
Với mỗi story, đánh giá nhanh theo INVEST (điểm 1-5 cho Independent và
Testable), chỉ ra nếu có vấn đề cần lưu ý.
Trả lời bằng tiếng Việt, giữ Given-When-Then bằng tiếng Anh.
Một trong bốn story được sinh ra, đã qua chỉnh sửa:
Story: Là một hệ thống, tôi muốn tự động ghi nhận khi giao dịch đầu tiên của referee đạt điều kiện thưởng (tối thiểu 100.000đ), để referrer và referee được cộng thưởng đúng thời điểm mà không cần xử lý thủ công.
Acceptance Criteria:
- Given referee đã đăng ký bằng mã giới thiệu hợp lệ, When referee hoàn tất giao dịch đầu tiên có giá trị >= 100.000đ, Then hệ thống ghi nhận sự kiện "referral qualified" trong vòng 5 phút.
- Given sự kiện "referral qualified" đã ghi nhận, When Fraud Detection Engine không đánh dấu cặp referrer-referee là nghi ngờ gian lận, Then 50.000đ được cộng vào ví của cả hai bên, kèm thông báo push.
- Given giao dịch đầu tiên của referee dưới 100.000đ, When giao dịch hoàn tất, Then hệ thống KHÔNG ghi nhận sự kiện thưởng, không gửi thông báo.
Mẹo: Ở bước capstone này, luôn giữ một "nguồn sự thật" (source of truth) duy nhất cho feature brief đã làm giàu — mọi prompt sau đó trong toàn bộ quy trình nên trích dẫn lại đúng con số này (50.000đ, 100.000đ, 500 triệu/tháng), không để AI tự "nhớ nhầm" hoặc suy diễn số khác ở bước sau, một lỗi rất dễ xảy ra khi làm việc qua nhiều phiên chat riêng biệt.
Tạo PRD Và Technical Specification Bằng AI
Sau khi đã có epic và story nháp cho phần lõi của tính năng, bước tiếp theo là tổng hợp thành một PRD hoàn chỉnh để trình bày cho ban lãnh đạo và làm nền cho technical specification gửi engineering.
Bước 1: Dựng PRD Từ Epic Và Story Đã Có
Dựa trên 4 epic và các user story đã xây dựng cho Chương trình Giới
thiệu bạn bè (VíThông Minh):
[PASTE DANH SÁCH EPIC + STORY CHÍNH ĐÃ CÓ]
Hãy viết PRD đầy đủ theo cấu trúc: Tổng quan & Vấn đề, Mục tiêu &
Success Metrics, Đối tượng người dùng, User Flow chính (mô tả từng
bước từ chia sẻ mã đến nhận thưởng), Yêu cầu chức năng (đánh số FR),
Yêu cầu phi chức năng (đánh số NFR, đặc biệt chú ý chống gian lận và
giới hạn ngân sách), Ràng buộc & Rủi ro, Timeline đề xuất theo 10
tuần, Out of Scope cho v1, Câu hỏi mở còn tồn đọng.
Success Metrics cụ thể: tăng 15% user mới qua kênh referral trong quý,
tỷ lệ gian lận referral dưới 2% tổng số referral hợp lệ.
Trả lời bằng tiếng Việt, giữ FR/NFR ID bằng tiếng Anh.
Phần Out of Scope quan trọng cần AI làm rõ, ví dụ: "v1 KHÔNG hỗ trợ nhiều tầng referral (referral của referral — multi-level), KHÔNG hỗ trợ tùy chỉnh mức thưởng theo từng chiến dịch marketing riêng, KHÔNG hỗ trợ referral qua mạng xã hội tự động (chỉ chia sẻ link/mã thủ công)." Việc chốt rõ Out of Scope ngay từ PRD giúp tránh scope creep khi dev bắt đầu implement.
Bước 2: Chuyển PRD Thành Technical Specification
Dựa trên PRD ở trên, hãy viết Technical Specification cho Epic 2
("Ghi nhận và thưởng khi giao dịch đầu tiên hoàn tất"), theo cấu trúc:
1. Tổng quan kỹ thuật và các module bị ảnh hưởng (Wallet, Notification,
Fraud Detection Engine).
2. Data Model sơ bộ: entity "Referral" (referrer_id, referee_id, mã
giới thiệu, trạng thái: pending/qualified/rewarded/revoked, ngày
tạo, ngày qualified).
3. Luồng xử lý sự kiện: từ lúc referee hoàn tất giao dịch đầu tiên đến
lúc thưởng được cộng, mô tả các bước gọi giữa Wallet Service,
Referral Service, Fraud Detection Engine, Notification Service.
4. API Contract sơ bộ cho endpoint kiểm tra trạng thái referral (input/
output ở mức khái niệm, chưa cần chi tiết schema đầy đủ).
5. Yêu cầu phi chức năng cụ thể: thời gian xử lý sự kiện tối đa 5 phút,
khả năng xử lý đồng thời nếu có traffic tăng đột biến sau chiến
dịch marketing.
6. Câu hỏi mở cho engineering (ví dụ: Fraud Detection Engine hiện tại
có API để kiểm tra cặp referrer-referee theo thời gian thực không?).
Sau khi viết xong, hãy tự đóng vai một Backend Developer lần đầu đọc
spec này, liệt kê tối đa 6 câu hỏi cần hỏi lại trước khi estimate.
Trả lời bằng tiếng Việt, giữ thuật ngữ kỹ thuật bằng tiếng Anh.
Câu hỏi điển hình mà AI (đóng vai dev) đưa ra ở bước self-critique: "Trạng thái 'revoked' (thu hồi thưởng khi referee hoàn tiền giao dịch) có cần trigger việc trừ lại tiền đã cộng vào ví referrer không, hay chỉ đánh dấu để báo cáo?" — đây chính xác là loại câu hỏi cần được trả lời TRONG spec trước khi gửi cho dev thật, không phải để dev phát hiện ra giữa sprint.
Mẹo: Khi chuyển từ PRD sang technical spec cho một capstone nhiều epic, hãy làm từng epic một, không cố dồn cả 4 epic vào một technical spec khổng lồ. Mỗi epic nên có spec riêng, dễ review và dễ estimate độc lập — dồn chung khiến buổi review kỹ thuật kéo dài và khó tập trung vào chi tiết quan trọng của từng phần.
Chạy AI Quality Audit Trên Requirements Vừa Tạo
Trước khi bàn giao, toàn bộ package vừa tạo — epic, story, PRD, technical spec — cần qua một vòng audit chất lượng có hệ thống, áp dụng chính xác các kỹ thuật đã học ở bài 5 của module này.
Bước 1: Audit INVEST Cho Toàn Bộ Story Của Epic 2
Dưới đây là 4 user story của Epic 2 (Ghi nhận và thưởng):
[PASTE 4 STORY + ACCEPTANCE CRITERIA HOÀN CHỈNH]
Hãy chấm điểm 1-5 cho từng tiêu chí INVEST (Independent, Negotiable,
Valuable, Estimable, Small, Testable) của mỗi story. Với tiêu chí nào
dưới 4 điểm, trích dẫn cụ thể và đề xuất cách sửa.
Đặc biệt kiểm tra: story "giới hạn số lần referrer nhận thưởng trong
tháng" có phụ thuộc (Independent) vào story "ghi nhận giao dịch đầu
tiên" không? Nếu có, đề xuất cách viết lại để giảm phụ thuộc hoặc gộp
lại hợp lý.
Trả lời bằng tiếng Việt, dạng bảng.
Kết quả audit thực tế thường phát hiện: story "giới hạn số lần nhận thưởng trong tháng" và story "ghi nhận giao dịch đầu tiên" có phụ thuộc hai chiều — không thể test đầy đủ story giới hạn ngân sách nếu chưa có cơ chế ghi nhận, nhưng cũng không thể ghi nhận đúng nếu chưa có giới hạn ngân sách áp dụng đồng thời (referrer thứ 21 trong tháng phải bị từ chối thưởng ngay tại bước ghi nhận, không phải xử lý riêng sau). Giải pháp thực tế: gộp logic kiểm tra giới hạn ngân sách vào ngay trong acceptance criteria của story ghi nhận, thay vì tách thành hai story độc lập giả tạo.
Bước 2: Quét Ambiguity, Conflict, Gap Trên Toàn Bộ PRD Và Spec
Đây là PRD và Technical Specification hoàn chỉnh cho Chương trình
Giới thiệu bạn bè:
[PASTE PRD + TECHNICAL SPEC ĐẦY ĐỦ]
Hãy phân tích và phân loại vấn đề thành 3 nhóm:
1. AMBIGUITY: câu nào có thể hiểu theo nhiều cách.
2. CONFLICT: có mâu thuẫn nào giữa PRD và Technical Spec không (ví dụ
PRD nói một điều, spec kỹ thuật implement khác đi)?
3. GAP: tình huống thực tế có khả năng xảy ra nhưng không được đề cập
(ví dụ: một user tạo nhiều tài khoản để tự giới thiệu chính mình,
referrer và referee dùng chung một thiết bị, mã giới thiệu bị chia
sẻ công khai trên mạng xã hội ngoài dự kiến).
Đánh giá mức độ nghiêm trọng (Cao/Trung/Thấp) cho mỗi vấn đề tìm được,
ưu tiên các vấn đề liên quan đến rủi ro tài chính và gian lận.
Trả lời bằng tiếng Việt, dạng bảng.
Một gap điển hình được phát hiện ở bước này trong tình huống thực tế: PRD không nói rõ điều gì xảy ra nếu referrer TỰ tạo tài khoản referee bằng số điện thoại/CCCD khác nhưng dùng chung thiết bị — đây chính xác là loại gian lận phổ biến nhất ở các chương trình referral thực tế, và việc AI phát hiện gap này TRƯỚC khi launch, thay vì sau khi bị lợi dụng, tiết kiệm hàng trăm triệu đồng ngân sách thưởng bị lạm dụng.
Mẹo: Với capstone có yếu tố tài chính/thưởng như referral program, luôn dành riêng một lượt audit chỉ tập trung vào câu hỏi "làm sao một user có động cơ xấu có thể lợi dụng cơ chế này để trục lợi?" — đây là góc nhìn khác hẳn với audit chất lượng thông thường (đầy đủ, testable), cần được hỏi tường minh vì AI không tự động nghĩ tới góc độ "kẻ tấn công" nếu không được yêu cầu rõ.
Bàn Giao Requirements Package Sẵn Sàng Cho Stakeholder
Bước cuối cùng của capstone: đóng gói toàn bộ tài liệu — epic, story, PRD, technical spec, kết quả audit và các vấn đề đã xử lý — thành một package hoàn chỉnh, dễ tiếp cận cho cả stakeholder kinh doanh lẫn engineering, với traceability rõ ràng.
Cấu Trúc Một Requirements Package Hoàn Chỉnh
Một package sẵn sàng bàn giao nên có: (1) Executive Summary 1 trang cho lãnh đạo, (2) PRD đầy đủ cho stakeholder kinh doanh và design, (3) Technical Specification riêng cho từng epic dành cho engineering, (4) Traceability Matrix nối OKR -> Epic -> Story, (5) Change Log ghi lại các quyết định quan trọng đã chốt trong quá trình xây dựng (ví dụ quyết định gộp story để giải quyết vấn đề Independent ở bước audit), (6) Danh sách rủi ro đã biết và residual risk còn tồn đọng sau audit.
Các Bước Thực Hành
- Yêu cầu AI viết Executive Summary từ PRD đầy đủ, giới hạn nghiêm ngặt trong 1 trang, tập trung vào: vấn đề, giải pháp, success metrics, timeline, ngân sách rủi ro chính.
- Tổng hợp Traceability Matrix nối rõ: OKR tăng trưởng user -> 4 Epic -> các Story chính -> (để trống cột Test Case, sẽ điền khi QA bắt đầu viết test).
- Viết Change Log ghi lại quyết định đã điều chỉnh qua audit (ví dụ: "Gộp story giới hạn ngân sách vào story ghi nhận giao dịch, do phát hiện phụ thuộc hai chiều ở bước audit INVEST").
- Review package hoàn chỉnh với cả PO, tech lead, và đại diện Fraud/Risk trước khi coi là bản final, đặc biệt với feature có yếu tố tài chính như trường hợp này.
Ví Dụ Prompt
Dựa trên toàn bộ tài liệu đã xây dựng cho Chương trình Giới thiệu bạn
bè (PRD, Technical Spec của 4 epic, kết quả audit INVEST và
ambiguity/conflict/gap):
[PASTE TOÀN BỘ TÀI LIỆU ĐÃ CÓ]
Hãy tổng hợp thành Requirements Package hoàn chỉnh gồm:
1. Executive Summary (đúng 1 trang): vấn đề, giải pháp, 2 success
metrics chính, timeline 10 tuần, rủi ro tài chính chính (ngân sách
500 triệu/tháng, nguy cơ gian lận).
2. Traceability Matrix dạng bảng: OKR -> Epic -> Story chính (chưa cần
Test Case, để cột trống cho QA điền sau).
3. Change Log: liệt kê các quyết định quan trọng đã điều chỉnh trong
quá trình audit (ví dụ gộp story, bổ sung gap về gian lận), kèm lý
do ngắn gọn cho mỗi thay đổi.
4. Danh sách Residual Risk: rủi ro đã biết nhưng chấp nhận cho v1
(ví dụ chưa có ML-based fraud detection, chỉ có rule-based), kèm
khuyến nghị theo dõi sau launch.
Xuất dưới dạng có thể copy trực tiếp vào Confluence, có heading rõ
ràng, trả lời bằng tiếng Việt.
Mẹo: Trước khi gửi package cho stakeholder, tự hỏi một câu duy nhất: "nếu tôi vắng mặt 2 tuần ngay sau khi bàn giao, người khác có thể cầm package này lên và tiếp tục công việc mà không cần hỏi lại tôi không?" Nếu câu trả lời là không, đó là dấu hiệu package còn thiếu ngữ cảnh quan trọng, dù mọi mục lục nhìn có vẻ đầy đủ trên giấy.
Những Điểm Chính Cần Nhớ
- Một requirements package hoàn chỉnh đi theo trình tự: feature brief làm giàu -> epic -> story/acceptance criteria -> PRD -> technical spec -> quality audit -> package bàn giao — mỗi bước dùng đúng kỹ thuật AI đã học trong các bài trước của module.
- Luôn giữ một nguồn sự thật duy nhất cho các con số quan trọng (mức thưởng, ngưỡng giao dịch, ngân sách) xuyên suốt mọi prompt, tránh để AI "nhớ nhầm" qua các phiên chat riêng biệt.
- Với feature có yếu tố tài chính/thưởng, luôn dành một lượt audit riêng cho góc nhìn "kẻ lợi dụng cơ chế", không chỉ audit chất lượng thông thường.
- Audit INVEST thường phát hiện các phụ thuộc ẩn giữa các story tưởng chừng độc lập (ví dụ giới hạn ngân sách và ghi nhận giao dịch) — giải pháp thường là gộp logic lại thay vì cố giữ story tách rời một cách giả tạo.
- Package bàn giao cuối cùng cần đủ tự giải thích để người khác có thể tiếp tục công việc mà không cần hỏi lại người viết ban đầu.
Mẹo: Lưu lại toàn bộ capstone này (feature brief, mọi prompt đã dùng, output từng bước) như một "case study mẫu" cho chính bạn hoặc team — lần sau nhận một feature request tương tự, bạn có sẵn một quy trình đã chứng minh hiệu quả để tái sử dụng, thay vì phải suy nghĩ lại từ đầu cách cấu trúc prompt cho từng bước.