Mở đầu — vì sao bài này quan trọng
Nếu bạn đang là Developer và muốn chuyển sang BA, thì User Story và PRD (Product Requirements Document) chính là hai "sản phẩm bàn giao" mà bạn sẽ viết ra mỗi ngày. Đây không phải kỹ năng phụ — nó là thước đo trực tiếp cho thấy bạn có làm được nghề BA hay không. Một BA viết user story mơ hồ sẽ khiến cả team dev đoán mò, tester không biết test cái gì, và Product Owner mất niềm tin.
Tin tốt là: với nền Developer, bạn có một lợi thế khổng lồ mà nhiều BA "thuần business" không có. Bạn đã đọc và viết hàng nghìn dòng spec kỹ thuật, hiểu thế nào là một yêu cầu rõ ràng (vì bạn đã từng chửi thầm những yêu cầu mơ hồ mà PM giao cho bạn), và bạn biết khi nào một câu mô tả còn thiếu điều kiện biên (edge case). Vấn đề duy nhất bạn cần khắc phục là: học cách diễn đạt yêu cầu theo ngôn ngữ giá trị nghiệp vụ thay vì ngôn ngữ giải pháp kỹ thuật.
Bài này tập trung hoàn toàn vào kỹ năng viết: cấu trúc một user story đúng chuẩn, viết acceptance criteria mà dev nào đọc cũng hiểu, và dựng một PRD đủ dùng nhưng không sa đà. Đây là bài thực hành "cầm bút", không phải lý thuyết suông.
Khái niệm cốt lõi
User Story là gì — và nó KHÔNG phải là gì
User Story là một mô tả ngắn gọn về một tính năng, viết từ góc nhìn của người dùng cuối, nhằm trả lời ba câu hỏi: Ai? Muốn gì? Để làm gì? Công thức kinh điển:
> Là [vai trò], tôi muốn [mục tiêu/hành động], để [giá trị/lý do].
Ví dụ: "Là một khách mua hàng trên Tiki, tôi muốn lưu nhiều địa chỉ giao hàng, để tôi có thể chọn nhanh địa chỉ phù hợp khi đặt đơn mà không phải gõ lại."
Điều quan trọng nhất — và là cái bẫy lớn nhất với Developer — là: User Story KHÔNG phải là một task kỹ thuật. Nó không phải "Thêm bảng user_addresses với khóa ngoại user_id". Đó là cách bạn nghĩ khi còn là dev. User Story diễn tả vấn đề và giá trị, còn việc thêm bảng nào là giải pháp — và giải pháp thuộc về team dev quyết định trong lúc thiết kế kỹ thuật, không phải thứ BA áp đặt sẵn.
Vế "để..." (mục đích) là phần mà dev hay bỏ qua nhất, nhưng lại quan trọng nhất. Nó cho dev hiểu vì sao, từ đó họ có thể đề xuất giải pháp tốt hơn cả cái bạn nghĩ ra.
Acceptance Criteria — nơi tư duy dev tỏa sáng
Acceptance Criteria (AC — tiêu chí chấp nhận) là danh sách điều kiện cụ thể để xác định story đã "xong". Đây chính là chỗ background Developer của bạn trở thành vũ khí. Bạn đã quen suy nghĩ về điều kiện biên, trạng thái lỗi, trường hợp dữ liệu rỗng — những thứ mà BA thuần business thường quên.
Định dạng phổ biến nhất là Given-When-Then (Gherkin):
> Given (cho trước bối cảnh) khách hàng đã đăng nhập và đang ở trang thanh toán > When (khi) khách bấm "Thêm địa chỉ mới" và điền đầy đủ thông tin hợp lệ > Then (thì) địa chỉ mới được lưu và hiển thị trong danh sách chọn
Một story tốt thường có nhiều AC, bao gồm cả luồng chính (happy path) lẫn luồng ngoại lệ: số điện thoại sai định dạng thì sao? Lưu quá 10 địa chỉ thì sao? Mất mạng giữa chừng thì sao? Là dev cũ, bạn nên tự hào liệt kê được những cái này.
PRD là gì và vị trí của nó
PRD (Product Requirements Document) là tài liệu mô tả tổng thể một sản phẩm hoặc một tính năng lớn (epic), trong khi User Story là đơn vị nhỏ để team triển khai. Hãy hình dung: PRD là "bản thiết kế ngôi nhà", còn các user story là "danh sách công việc từng phòng". Một PRD điển hình gồm: bối cảnh và vấn đề, mục tiêu và chỉ số đo lường thành công, phạm vi (in-scope / out-of-scope), các user story chính, yêu cầu phi chức năng, và các giả định/ràng buộc.
Lưu ý quan trọng: bài này chỉ đề cập PRD ở mức "viết và cấu trúc". Phân biệt sâu giữa BRD/FRD/SRS sẽ học ở bài về phân cấp tài liệu, còn chuẩn INVEST cho story học ở bài riêng — ở đây ta tập trung vào kỹ năng cầm bút viết ra một story và một PRD dùng được ngay.
Tình huống thực tế
Ví dụ 1: Anh Tuấn — viết story kiểu "ticket Jira của dev"
Anh Tuấn, 4 năm làm backend tại một fintech ở TP.HCM, chuyển sang BA. Story đầu tiên anh viết cho tính năng nhắc nợ thẻ tín dụng:
> "Tạo cron job chạy lúc 8h sáng, query các tài khoản có due_date trong 3 ngày tới, gọi API gửi SMS qua nhà cung cấp Viettel."
Product Owner đọc xong... không hiểu giá trị nằm ở đâu, còn team dev thì cảm thấy bị áp đặt giải pháp. Tại sao 8h sáng mà không phải giờ khác? Tại sao SMS mà không phải push notification rẻ hơn? Anh Tuấn đã viết giải pháp, không phải yêu cầu.
Sau khi được mentor góp ý, anh viết lại:
> "Là chủ thẻ tín dụng, tôi muốn được nhắc trước khi đến hạn thanh toán, để tôi không bị tính phí trễ hạn và phạt lãi."
Kèm AC: nhắc trước 3 ngày; nội dung gồm số tiền tối thiểu và hạn chót; khách đã thanh toán đủ thì không nhận nhắc nữa. Bài học: kênh gửi (SMS hay push) và giờ gửi trở thành chi tiết để team bàn bạc, và hóa ra dev đề xuất kết hợp push + SMS giúp giảm 40% chi phí so với phương án ban đầu của anh Tuấn. Khi bạn mô tả vấn đề thay vì giải pháp, team thông minh hơn cộng lại.
Ví dụ 2: Chị Lan tại một startup EdTech — AC quá sơ sài
Chị Lan chuyển từ frontend sang BA tại một startup học trực tuyến ở Hà Nội (giả định, ~50 nhân sự). Chị viết story rất chuẩn về mặt diễn đạt giá trị, nhưng AC chỉ có đúng một dòng: "Học viên đăng ký được khóa học." Kết quả: dev làm xong luồng đăng ký cơ bản, nhưng khi khóa học đã đầy chỗ thì hệ thống vẫn cho đăng ký, gây trùng lịch và phải hoàn tiền 23 trường hợp trong tuần ra mắt.
Mentor chỉ ra: chính nền dev của chị Lan đáng lẽ phải giúp chị nghĩ tới các trạng thái — khóa đã đầy, khóa đã đóng đăng ký, học viên đã đăng ký rồi bấm lại, thanh toán thất bại. Chị viết lại AC thành 6 điều kiện bao phủ các trạng thái này. Bài học: viết story hay mới là một nửa; AC đầy đủ mới ngăn được sự cố. Lợi thế dev của bạn nằm ở việc nghĩ ra edge case mà người khác bỏ sót — đừng lãng phí nó.
Ví dụ 3: PRD "tiểu thuyết 40 trang" ở một công ty outsourcing
Một BA mới chuyển từ dev tại công ty outsourcing phần mềm cho khách Nhật đã viết PRD dài 40 trang cho một tính năng giỏ hàng, đặc tả tới từng câu lệnh SQL và sơ đồ bảng. Khách hàng Nhật phản hồi: tài liệu khó duyệt, và khi yêu cầu thay đổi nhỏ thì phải sửa hàng chục chỗ vì spec quá cứng nhắc.
PRD bản sửa rút còn 8 trang: tập trung vào vấn đề, mục tiêu kinh doanh (tăng tỷ lệ chuyển đổi giỏ hàng từ 2.1% lên 3%), 7 user story chính kèm AC, và một mục yêu cầu phi chức năng (trang giỏ hàng tải dưới 2 giây). Phần thiết kế bảng dữ liệu được chuyển sang tài liệu kỹ thuật riêng của team dev. Bài học: PRD mô tả cái gì và tại sao, không phải làm như thế nào. Sự dư thừa kỹ thuật là thói quen dev khó bỏ nhất khi chuyển sang BA.
Hướng dẫn từng bước
Bước 1 — Xác định đúng vai trò (role). Đừng viết chung chung "người dùng". Hãy cụ thể: "khách vãng lai", "khách đã đăng nhập", "quản trị viên kho", "nhân viên CSKH". Vai trò càng rõ, AC càng dễ viết đúng.
Bước 2 — Viết vế "tôi muốn" ở mức hành động, không phải kỹ thuật. Thử nghiệm nhanh: nếu câu của bạn nhắc tới tên bảng, API, hay framework — bạn đang viết giải pháp. Viết lại theo góc nhìn người dùng đang cố đạt điều gì.
Bước 3 — Luôn viết vế "để" (giá trị). Nếu bạn không nghĩ ra được lý do, có thể tính năng đó không nên làm. Đây là bài kiểm tra giá trị miễn phí.
Bước 4 — Liệt kê Acceptance Criteria theo Given-When-Then. Bắt đầu từ happy path, rồi dùng tư duy dev để bổ sung: dữ liệu rỗng, dữ liệu sai định dạng, vượt giới hạn, lỗi mạng, quyền truy cập. Mỗi AC phải kiểm chứng được (testable) — tester đọc xong biết ngay phải test gì.
Bước 5 — Kiểm tra kích thước story. Nếu một story cần hơn vài ngày để làm, hãy tách nhỏ. Story lớn là dấu hiệu nó còn là epic.
Bước 6 — Dựng PRD bằng khung cố định. Dùng đúng các mục: (1) Bối cảnh & vấn đề; (2) Mục tiêu & chỉ số thành công; (3) Phạm vi in/out; (4) User stories chính; (5) Yêu cầu phi chức năng; (6) Giả định & ràng buộc; (7) Câu hỏi mở. Viết ngắn gọn, ưu tiên gạch đầu dòng hơn văn xuôi.
Bước 7 — Rà soát "đứng từ ghế dev". Đọc lại story như thể bạn là dev sắp code nó: bạn có đủ thông tin để bắt đầu không? Có chỗ nào phải đoán không? Nếu có, bổ sung trước khi bàn giao. Đây là siêu năng lực của bạn — bạn biết chính xác dev cần gì vì bạn từng là dev.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết giải pháp thay vì yêu cầu. Đây là lỗi số một của dev-turned-BA. Mẹo: gạch bỏ mọi danh từ kỹ thuật (bảng, endpoint, queue) trong story; nếu xóa đi mà câu vẫn đủ nghĩa với người dùng, bạn đã viết đúng.
Lỗi 2 — Bỏ trống vế "để". Mẹo: tự hỏi "nếu không có tính năng này, người dùng mất gì?" — câu trả lời chính là vế giá trị.
Lỗi 3 — AC chỉ có happy path. Mẹo: với mỗi story, cố ý nghĩ ra ít nhất 2 luồng "không vui" (lỗi, biên, quyền). Lập một checklist edge-case cá nhân và áp dụng mọi lúc.
Lỗi 4 — PRD quá dài, lẫn lộn chi tiết kỹ thuật. Mẹo: nếu một câu trả lời cho "làm như thế nào" thay vì "làm cái gì", chuyển nó sang tài liệu kỹ thuật của team dev.
Lỗi 5 — AC không kiểm chứng được, kiểu "hệ thống phải nhanh". Mẹo: lượng hóa — "trang tải dưới 2 giây với 1.000 người dùng đồng thời".
Lỗi 6 — Áp đặt thiết kế lên team dev. Mẹo: nhắc bản thân rằng vai trò mới của bạn là làm rõ vấn đề; để team đề xuất giải pháp và bạn cùng thẩm định. Bạn vẫn được dùng kiến thức kỹ thuật — nhưng để đối thoại, không để áp đặt.
Bài tập thực hành
Bài 1 — Chuyển hóa. Lấy story "kiểu dev" sau và viết lại thành user story chuẩn kèm tối thiểu 4 AC theo Given-When-Then: "Thêm field OTP vào màn login, gọi API SMS gateway, set timeout 60s." (Gợi ý: ai là vai trò? OTP giải quyết vấn đề gì cho họ?)
Bài 2 — Săn edge case. Cho story "Là khách hàng, tôi muốn áp mã giảm giá khi thanh toán, để tiết kiệm tiền." Hãy liệt kê ít nhất 6 AC, trong đó tối thiểu 4 cái là luồng ngoại lệ (mã hết hạn, mã không hợp lệ, mã đã dùng, đơn không đủ điều kiện tối thiểu...).
Bài 3 — Dựng PRD mini. Viết một PRD 1–2 trang cho tính năng "Lịch sử đơn hàng" của một app bán cà phê, dùng đúng 7 mục đã học. Tự đặt ra 2 chỉ số thành công có thể đo được.
Bài 4 — Tự phản biện. Đưa 3 story bạn vừa viết cho một người không có nền kỹ thuật (bạn bè, người thân) đọc. Nếu họ không hiểu giá trị của story, viết lại cho đến khi họ hiểu. Đây là bài luyện quan trọng nhất để cai "ngôn ngữ dev".
Tóm tắt
User Story và PRD là hai sản phẩm cốt lõi bạn sẽ viết hằng ngày trong vai trò BA. Với nền Developer, bạn có lợi thế thật sự ở phần Acceptance Criteria — khả năng nghĩ ra edge case và viết điều kiện kiểm chứng được — nhưng bạn cũng có điểm yếu cố hữu: thói quen viết giải pháp kỹ thuật thay vì yêu cầu nghiệp vụ.
Hãy ghi nhớ ba nguyên tắc: một, story diễn tả ai - muốn gì - để làm gì, luôn đủ cả ba vế; hai, AC phải bao phủ cả luồng chính lẫn luồng ngoại lệ và phải kiểm chứng được; ba, PRD trả lời cái gì và tại sao, không sa vào làm như thế nào — phần đó để team dev. Khi bạn mô tả vấn đề thật rõ thay vì áp đặt giải pháp, cả team sẽ tạo ra kết quả tốt hơn cái bạn nghĩ ra một mình. Đó chính là khoảnh khắc bạn thực sự trở thành một BA, chứ không còn là một dev viết ticket.