Mở đầu — vì sao bài này quan trọng
Nếu bạn đang làm Marketing và muốn chuyển sang BA (Business Analyst), thì User Story và PRD chính là hai "ngôn ngữ" bạn buộc phải nói thành thạo. Lý do rất đơn giản: ở các bài trước bạn đã học cách lắng nghe khách hàng và thu thập yêu cầu (requirements gathering). Nhưng thu thập xong rồi để đâu? Bạn không thể đưa cho lập trình viên một file ghi chú lộn xộn hay một slide đẹp đẽ kiểu pitch deck. Bạn phải biến những gì mình hiểu thành tài liệu mà cả đội phát triển (dev), kiểm thử (QA) và lãnh đạo đều đọc được và hành động được.
Tin vui là dân Marketing có lợi thế tự nhiên ở đây mà nhiều người không nhận ra. Cả đời làm Marketing, bạn đã viết ad copy nhắm đúng "nỗi đau" của khách hàng, đã vẽ chân dung khách hàng (customer persona), đã suy nghĩ theo kiểu "khách hàng muốn gì, để làm gì, vì sao". Đó chính xác là cấu trúc của một User Story tốt. Bạn cũng đã từng viết campaign brief — một tài liệu mô tả mục tiêu, đối tượng, thông điệp, ngân sách và cách đo lường. PRD (Product Requirements Document) về bản chất là một bản brief, chỉ khác là dành cho sản phẩm phần mềm thay vì chiến dịch quảng cáo.
Bài học này sẽ chỉ cho bạn cách "dịch" tư duy Marketing sẵn có thành User Story chuẩn và PRD chuyên nghiệp — hai sản phẩm đầu ra (deliverable) mà nhà tuyển dụng BA luôn yêu cầu bạn thể hiện trong portfolio và phỏng vấn.
Khái niệm cốt lõi
User Story là gì
User Story (câu chuyện người dùng) là một mô tả ngắn gọn về một nhu cầu của người dùng, viết theo góc nhìn của chính người dùng đó. Đây là đơn vị công việc nhỏ nhất mà đội Agile làm việc hàng ngày. Công thức kinh điển:
> Là một [vai trò người dùng], tôi muốn [thực hiện điều gì đó], để [đạt được giá trị/lợi ích nào đó].
Tiếng Anh là: "As a [role], I want [goal], so that [benefit]."
Ví dụ: "Là một khách mua hàng lần đầu, tôi muốn được lưu giỏ hàng kể cả khi chưa đăng nhập, để tôi không phải chọn lại sản phẩm sau khi tạo tài khoản."
Hãy để ý cấu trúc ba phần này quen thuộc đến mức nào với dân Marketing. Phần "Là một..." chính là persona. Phần "tôi muốn..." là hành vi mong muốn (giống bạn xác định call-to-action). Phần "để..." là động cơ, là "why" — đúng cái mà mọi marketer giỏi luôn đào sâu khi viết content. Bạn không học cái gì mới hoàn toàn; bạn đang đổi định dạng của một kỹ năng đã có.
Acceptance Criteria — phần làm nên User Story chuyên nghiệp
Một User Story chỉ là lời mời gọi để trò chuyện. Nó chưa đủ để dev biết khi nào thì "xong". Vì vậy mỗi story phải kèm Acceptance Criteria (AC) — tiêu chí nghiệm thu, tức danh sách điều kiện cụ thể để khẳng định tính năng đã làm đúng.
Định dạng phổ biến nhất là Given–When–Then (Cho trước – Khi – Thì):
- Given (cho trước): bối cảnh ban đầu.
- When (khi): hành động người dùng thực hiện.
- Then (thì): kết quả mong đợi.
- Given khách chưa đăng nhập và đã thêm 2 sản phẩm vào giỏ, When khách tạo tài khoản và đăng nhập, Then 2 sản phẩm đó vẫn còn nguyên trong giỏ hàng.
- Given giỏ hàng có sản phẩm đã hết hàng, When khách đăng nhập, Then hệ thống hiển thị cảnh báo "sản phẩm đã hết hàng" cho mục đó.
PRD là gì và khác gì User Story
PRD (Product Requirements Document) là tài liệu lớn hơn, mô tả toàn bộ một tính năng hoặc một sản phẩm: bối cảnh, vấn đề cần giải quyết, đối tượng, phạm vi, các yêu cầu chức năng và phi chức năng, chỉ số đo lường thành công, và những gì nằm ngoài phạm vi (out of scope).
Quan hệ giữa hai thứ này: PRD là bức tranh tổng thể của ngôi nhà; User Story là từng viên gạch. Một PRD thường được "bẻ nhỏ" (break down) thành nhiều User Story để đội Agile triển khai dần qua các sprint. Marketer hãy hình dung: PRD giống như chiến lược chiến dịch tổng thể cả quý, còn User Story giống như từng mẩu nội dung, từng post, từng email cụ thể bạn sản xuất để chạy chiến dịch đó.
Một PRD gọn gàng thường gồm các phần: Bối cảnh & vấn đề; Mục tiêu & chỉ số thành công (success metrics); Đối tượng người dùng/persona; Phạm vi (in scope) & ngoài phạm vi (out of scope); Yêu cầu chức năng (functional requirements) — thường liệt kê dưới dạng User Story; Yêu cầu phi chức năng (hiệu năng, bảo mật...); Giả định & rủi ro; và Câu hỏi còn bỏ ngỏ (open questions).
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán "bỏ giỏ hàng"
Giả sử bạn là cựu marketer vừa vào làm BA tại một sàn thương mại điện tử kiểu Tiki. Đội Growth báo cáo tỷ lệ bỏ giỏ hàng (cart abandonment) ở bước thanh toán lên tới 68%, cao hơn mức trung bình ngành khoảng 70% nhưng nguyên nhân của họ rất cụ thể: nhiều khách phải nhập lại địa chỉ giao hàng từ đầu mỗi lần mua.
Với tư duy Marketing cũ, bạn sẽ nghĩ ngay đến việc chạy email remarketing nhắc khách quay lại. Nhưng với mũ BA, bạn xác định gốc rễ là vấn đề sản phẩm và viết User Story:
> Là một khách hàng đã từng mua hàng, tôi muốn hệ thống tự điền sẵn địa chỉ giao hàng đã lưu, để tôi hoàn tất thanh toán nhanh mà không phải gõ lại.
AC kèm theo: Given khách đã có ít nhất một địa chỉ lưu trong tài khoản, When khách vào bước thanh toán, Then địa chỉ mặc định được điền sẵn và khách có thể chọn địa chỉ khác hoặc thêm mới.
Bài học rút ra: marketer thường dừng ở việc "kéo khách quay lại", còn BA phải đi xa hơn một bước — loại bỏ ma sát (friction) trong sản phẩm để khách không bỏ đi ngay từ đầu. Cùng một dữ liệu, hai vai trò cho ra hai loại giải pháp khác nhau, và BA viết giải pháp đó thành story để dev làm được.
Ví dụ 2 — Một fintech kiểu MoMo viết PRD cho tính năng "Nhắc đóng tiền điện"
Một ví điện tử nội địa muốn ra tính năng nhắc người dùng đóng tiền điện hàng tháng. Là BA, bạn không lao vào viết story ngay mà soạn một PRD ngắn để mọi người đồng thuận trước.
Phần Bối cảnh & vấn đề: 40% người dùng từng trễ hạn đóng tiền điện ít nhất một lần trong 6 tháng; mỗi lần trễ là một lần họ rời ứng dụng để xử lý ở kênh khác. Mục tiêu: tăng tỷ lệ thanh toán hóa đơn điện qua app thêm 15% trong quý, đo bằng số giao dịch tiền điện thành công. Phạm vi: chỉ làm nhắc cho hóa đơn điện, chưa làm nước và internet (out of scope). Yêu cầu chức năng được liệt kê thành các story: cho phép người dùng bật/tắt nhắc, gửi push notification trước hạn 3 ngày, hiển thị số tiền dự kiến. Yêu cầu phi chức năng: push phải gửi trong vòng 5 phút kể từ thời điểm hẹn; tuân thủ quy định bảo vệ dữ liệu cá nhân khi xử lý thông tin hóa đơn.
Bài học rút ra: PRD buộc bạn nói rõ "không làm gì" cũng quan trọng như "làm gì". Marketer hay tham lam ôm hết mọi ý tưởng vào một chiến dịch; BA giỏi biết cắt phạm vi để đội kịp giao hàng đúng sprint. Phần "out of scope" thường cứu cả dự án khỏi trễ hạn.
Ví dụ 3 — Khi marketer viết story quá to: trường hợp Shopee Live
Một BA mới chuyển từ Marketing viết story: "Là người bán, tôi muốn livestream bán hàng với đầy đủ tính năng, để tăng doanh số." Nghe rất "campaign", nhưng đội dev lắc đầu vì story này to bằng cả một dự án ba tháng — đây là một Epic, không phải User Story.
BA có kinh nghiệm sẽ chẻ nó ra: story 1 — người bán tạo được lịch livestream; story 2 — người xem thả tim và bình luận; story 3 — người xem thêm sản phẩm vào giỏ ngay trong lúc xem; story 4 — hiển thị số người đang xem. Mỗi story nhỏ, làm xong trong vài ngày, kiểm thử được độc lập.
Bài học rút ra: kích thước story quan trọng ngang nội dung. Một story tốt phải vừa đủ nhỏ để hoàn thành trong một sprint. Marketer quen tư duy "chiến dịch lớn" cần luyện thói quen bẻ nhỏ — giống như chia một chiến dịch quý thành các post hàng tuần.
Hướng dẫn từng bước
Bước 1 — Xác định đúng persona người dùng. Trước khi viết "Là một...", hãy hỏi: ai thực sự dùng tính năng này? Đừng viết chung chung "Là một người dùng". Hãy cụ thể: khách mua lần đầu, người bán nhỏ lẻ, nhân viên kho. Kỹ năng vẽ persona trong Marketing dùng được nguyên xi ở đây.
Bước 2 — Viết phần "tôi muốn" tập trung vào nhu cầu, không phải giải pháp. Sai lầm phổ biến: "tôi muốn một nút màu xanh ở góc phải". Đó là giải pháp, không phải nhu cầu. Đúng phải là "tôi muốn nhanh chóng quay lại sản phẩm vừa xem". Để dev và designer tự do tìm cách tốt nhất.
Bước 3 — Luôn viết phần "để..." (so that). Đây là phần quan trọng nhất và cũng hay bị bỏ quên. Nếu bạn không nêu được giá trị, có thể tính năng đó không đáng làm. Marketer vốn ám ảnh chuyện "why", hãy giữ thói quen đó.
Bước 4 — Viết Acceptance Criteria theo Given–When–Then. Mỗi story nên có từ 3 đến 7 AC, bao gồm cả trường hợp thuận lợi (happy path) lẫn trường hợp lỗi (ví dụ sản phẩm hết hàng, mất mạng). AC là hợp đồng giữa bạn và đội dev/QA.
Bước 5 — Kiểm tra story bằng tiêu chí INVEST. Story tốt nên: Independent (độc lập), Negotiable (có thể thương lượng), Valuable (có giá trị), Estimable (ước lượng được công sức), Small (đủ nhỏ), Testable (kiểm thử được). Nếu story to như Epic, hãy bẻ nhỏ.
Bước 6 — Gom các story liên quan vào một PRD. Viết phần bối cảnh, mục tiêu, success metrics, phạm vi và out of scope. Đặt các story vào mục yêu cầu chức năng. Thêm yêu cầu phi chức năng và open questions để mời gọi phản hồi từ đội.
Bước 7 — Đưa cho stakeholder review. PRD không phải tài liệu một chiều. Hãy gửi cho Product Owner, dev lead, QA đọc và góp ý trước khi chốt. Đây là kỹ năng giao tiếp mà marketer làm campaign brief đã quen.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết story theo ngôn ngữ kỹ thuật của hệ thống thay vì người dùng. Ví dụ "Là hệ thống, tôi muốn lưu record vào database". Đó không phải User Story. Hãy luôn đứng ở góc nhìn con người dùng sản phẩm.
Lỗi 2 — Nhồi nhiều nhu cầu vào một story. Nếu phần "tôi muốn" có chữ "và", rất có thể bạn đang gộp hai story. Tách ra.
Lỗi 3 — Quên trường hợp lỗi trong AC. Marketer quen viết kịch bản đẹp; BA phải nghĩ cả lúc xấu: mất mạng, nhập sai, hết hàng, hết hạn. Đây là điểm yếu kinh điển của người mới chuyển nghề.
Lỗi 4 — PRD dài lê thê như một bài luận. Mục tiêu của PRD là để mọi người đọc nhanh và đồng thuận, không phải khoe chữ. Dùng gạch đầu dòng, bảng, và giữ mỗi phần ngắn gọn.
Mẹo: tận dụng kỹ năng storytelling Marketing để viết phần bối cảnh PRD thật thuyết phục — nêu số liệu nỗi đau, kể câu chuyện người dùng cụ thể. Một PRD mở đầu bằng "68% khách bỏ giỏ ở bước nhập địa chỉ" mạnh hơn nhiều so với "chúng ta cần cải thiện checkout".
Mẹo: giữ một thư viện template story và PRD của riêng bạn. Mỗi lần viết một story tốt, lưu lại làm mẫu. Đây cũng là nguyên liệu quý cho portfolio BA sau này.
Bài tập thực hành
- Viết 3 User Story hoàn chỉnh cho một tính năng "đặt lịch hẹn spa qua app" (gợi ý bám bối cảnh ngành làm đẹp Việt Nam). Mỗi story phải đủ ba phần Là một / tôi muốn / để, và kèm ít nhất 3 Acceptance Criteria theo Given–When–Then, trong đó có ít nhất 1 trường hợp lỗi.
- Kiểm tra story bằng INVEST. Lấy 3 story vừa viết, tự chấm từng tiêu chí I-N-V-E-S-T xem đạt hay không. Story nào trượt "Small", hãy bẻ nhỏ.
- Soạn một PRD một trang cho tính năng spa nói trên: bối cảnh & vấn đề (kèm một con số giả định hợp lý), mục tiêu & success metric, persona, in scope, out of scope, và 3 story ở câu 1 đặt vào mục yêu cầu chức năng. Thêm ít nhất 1 yêu cầu phi chức năng và 2 open questions.
- Tự phản biện: đọc lại PRD và chỉ ra một thứ bạn cố tình để "out of scope". Giải thích vì sao cắt nó lại giúp đội giao hàng đúng hạn.
Tóm tắt
User Story và PRD là hai deliverable cốt lõi đầu tiên mà một BA xuất thân Marketing cần làm chủ. User Story dùng công thức Là một / tôi muốn / để, kèm Acceptance Criteria theo Given–When–Then, và phải đạt tiêu chí INVEST — đặc biệt là đủ nhỏ để hoàn thành trong một sprint. PRD là tài liệu tổng thể gói các story đó lại cùng bối cảnh, mục tiêu, success metrics, phạm vi và những gì nằm ngoài phạm vi.
Điều đáng mừng là bạn không bắt đầu từ con số không. Kỹ năng vẽ persona, đào sâu "why", viết brief thuyết phục và tư duy đo lường từ Marketing chuyển thẳng vào công việc này. Việc của bạn chỉ là đổi định dạng và bổ sung tư duy về trường hợp lỗi cùng kích thước công việc. Hãy luyện viết story và PRD đều đặn — đây chính là những mẫu vật bạn sẽ trưng ra trong portfolio và phỏng vấn BA ở các bài sau.