Mở đầu — vì sao bài này quan trọng
Nếu bạn đang làm Sales/BD và muốn chuyển sang BA, có một kỹ năng cụ thể quyết định phần lớn ấn tượng đầu tiên của bạn với đội product và đội dev: khả năng viết User Story và Spec. Đây không phải lý thuyết trừu tượng — nó là "sản phẩm đầu ra" hàng ngày của một BA. Trong khi một Sales giỏi được đánh giá qua doanh số, một BA được đánh giá qua chất lượng tài liệu mô tả yêu cầu. Khi bạn nộp CV hoặc đi phỏng vấn, nhà tuyển dụng gần như chắc chắn sẽ đưa cho bạn một tình huống và yêu cầu "viết thử vài user story". Nếu bạn viết được rõ ràng, đúng chuẩn, bạn đã vượt qua 70% ứng viên tay ngang.
Tin vui là: người làm Sales có lợi thế tự nhiên ở phần này mà nhiều người không nhận ra. Mỗi ngày bạn đã đang "phiên dịch" nhu cầu mơ hồ của khách hàng thành đề xuất cụ thể. Bạn đã quen lắng nghe khách nói "tôi muốn tăng doanh thu" rồi đào sâu để hiểu họ thực sự cần gì. Đó chính xác là tư duy nền tảng của việc viết requirement. Bài này sẽ dạy bạn cách chuyển hóa kỹ năng đó thành định dạng chuẩn mà ngành phần mềm dùng: User Story và Specification. Chúng ta sẽ tập trung 100% vào KỸ NĂNG VIẾT — cấu trúc, ngôn từ, mức độ chi tiết — chứ không lan sang quy trình Agile hay cách thu thập yêu cầu (đó là việc của các bài sau).
Khái niệm cốt lõi
User Story là gì và vì sao nó khác đề xuất bán hàng
User Story là một câu mô tả ngắn gọn một tính năng từ góc nhìn của người sử dụng. Công thức kinh điển là:
> Là một [vai trò], tôi muốn [thực hiện điều gì], để [đạt được lợi ích gì].
Ví dụ: "Là một khách hàng mua hàng online, tôi muốn lưu nhiều địa chỉ giao hàng, để tôi không phải nhập lại mỗi lần đặt hàng."
Hãy để ý ba thành phần. Vai trò (ai) buộc bạn nghĩ về người dùng cụ thể chứ không nói chung chung "hệ thống cần...". Hành động (muốn gì) mô tả nhu cầu. Lợi ích (để làm gì) — phần quan trọng nhất và hay bị bỏ quên — giải thích "tại sao", giúp dev và product hiểu giá trị thật sự, từ đó họ có thể đề xuất giải pháp tốt hơn cả điều bạn nghĩ ra.
Khác biệt với đề xuất bán hàng nằm ở chỗ: trong Sales, bạn viết để thuyết phục một người ra quyết định mua. Trong User Story, bạn viết để mô tả chính xác cho người xây dựng làm đúng. Ngôn ngữ Sales thường có tính từ cảm xúc ("giải pháp tuyệt vời", "tối ưu vượt trội"); ngôn ngữ User Story phải trung tính, đo lường được, không hứa hẹn. Đây là điều chỉnh giọng văn đầu tiên bạn cần luyện.
Acceptance Criteria — phần "spec" làm story trở nên thực thi được
Một User Story chỉ là tiêu đề của câu chuyện. Phần "spec" thực sự nằm ở Acceptance Criteria (AC) — tiêu chí nghiệm thu — tức danh sách điều kiện cụ thể để xác định tính năng đã hoàn thành đúng. AC trả lời câu hỏi: "Làm sao biết được story này đã làm xong và làm đúng?"
Có hai cách viết AC phổ biến:
Cách 1 — Định dạng Gherkin (Given/When/Then):
- Given (bối cảnh): người dùng đã đăng nhập và có ít nhất 1 địa chỉ đã lưu
- When (hành động): người dùng chọn "Thêm địa chỉ mới" và điền đầy đủ thông tin
- Then (kết quả): hệ thống lưu địa chỉ mới và hiển thị trong danh sách
- Người dùng có thể lưu tối đa 10 địa chỉ
- Mỗi địa chỉ bắt buộc có: tên người nhận, số điện thoại, địa chỉ chi tiết
- Nếu để trống trường bắt buộc, hệ thống báo lỗi rõ ràng dưới ô đó
Spec rộng hơn: khi User Story là chưa đủ
Với tính năng đơn giản, một story kèm AC là đủ. Nhưng với nghiệp vụ phức tạp (ví dụ: tính phí vận chuyển theo vùng, theo trọng lượng, có khuyến mãi), bạn cần một Spec chi tiết hơn, gồm: mô tả nghiệp vụ, các quy tắc tính toán, dữ liệu đầu vào/đầu ra, và trường hợp biên. Story trả lời "cái gì và tại sao"; Spec bổ sung "chi tiết như thế nào". Người ex-Sales thường mạnh ở phần "tại sao" vì hiểu khách, nhưng cần luyện thêm sự tỉ mỉ ở phần "như thế nào".
Tình huống thực tế
Ví dụ 1 — Tiki: từ "khách phàn nàn" sang một User Story rõ ràng
Giả định bạn vừa chuyển sang BA tại một sàn TMĐT như Tiki. Đội Sales/đối tác báo lại: "Nhà bán hàng kêu ca không biết đơn nào sắp hết hạn xử lý, bị phạt oan." Một người tay ngang sẽ viết: "Hệ thống cần cảnh báo đơn hàng." Quá mơ hồ — dev sẽ hỏi lại hàng loạt câu.
Cách một BA viết:
> Là một nhà bán hàng trên sàn, tôi muốn nhận thông báo khi đơn hàng còn dưới 2 giờ là tới hạn xác nhận, để tôi xử lý kịp và tránh bị trừ điểm uy tín.
AC kèm theo: (1) Thông báo gửi qua cả app và email khi đơn còn đúng 2 giờ tới deadline. (2) Thông báo gửi lại lần cuối khi còn 30 phút. (3) Khi nhà bán đã xác nhận, dừng gửi thông báo cho đơn đó. (4) Nếu nhà bán tắt thông báo trong cài đặt, không gửi qua app nhưng vẫn gửi email.
Bài học: Lợi thế Sales của bạn là bạn hiểu nỗi đau "bị phạt oan" và tâm lý nhà bán. Nhưng giá trị BA nằm ở con số cụ thể "2 giờ", "30 phút" và việc lường trước tình huống "đã xác nhận" hay "đã tắt thông báo". Chính sự cụ thể đó biến lời phàn nàn thành thứ dev làm được ngay.
Ví dụ 2 — Một startup SaaS HR (giả định "PeopleX") và bẫy viết quá to
Tại một startup SaaS quản lý nhân sự, BA mới (xuất thân BD) viết một story khổng lồ: "Là quản lý, tôi muốn quản lý toàn bộ quy trình nghỉ phép của nhân viên." Nghe rất hợp lý theo tư duy bán hàng — vì bạn quen pitch trọn gói giải pháp. Nhưng dev không thể ước lượng nổi: "quản lý toàn bộ" là tạo đơn? duyệt? báo cáo? tính số ngày phép còn lại? tích hợp bảng lương?
BA có kinh nghiệm sẽ chẻ nhỏ (split) thành nhiều story độc lập:
- Là nhân viên, tôi muốn tạo đơn xin nghỉ phép, để gửi yêu cầu cho quản lý.
- Là quản lý, tôi muốn duyệt/từ chối đơn nghỉ, để kiểm soát nhân sự.
- Là nhân viên, tôi muốn xem số ngày phép còn lại, để lên kế hoạch nghỉ.
Ví dụ 3 — Ngân hàng số VN và sức mạnh của Acceptance Criteria chi tiết
Một BA chuyển từ vị trí bán bảo hiểm/banca sang làm tại một ngân hàng số được giao viết spec cho tính năng "chuyển tiền nhanh". Story rất đơn giản: "Là người dùng app, tôi muốn chuyển tiền cho số tài khoản khác, để thanh toán nhanh." Nhưng đây là nghiệp vụ tài chính, sai một ly đi một dặm.
Nhờ thói quen Sales luôn hỏi "điều gì có thể khiến khách từ chối / khiếu nại", BA này viết AC rất kỹ phần biên: (1) Nếu số dư không đủ, báo lỗi trước khi cho bấm xác nhận. (2) Giao dịch trên 10 triệu bắt buộc xác thực OTP/sinh trắc học. (3) Nếu mất kết nối giữa chừng, hiển thị "đang xử lý", không trừ tiền hai lần (chống trùng giao dịch). (4) Lưu nhật ký mọi giao dịch để đối soát.
Bài học: Sự cẩn trọng "lường trước khiếu nại" của dân Sales/banca chính là tài sản quý khi viết spec cho domain rủi ro cao. Tình huống lỗi và trường hợp biên thường là phần phân biệt một BA non tay với một BA đáng tin cậy.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay khi cần viết một bộ User Story + Spec:
Bước 1 — Xác định vai trò người dùng (ai). Liệt kê các nhóm người dùng khác nhau của tính năng. Đừng gộp tất cả thành "người dùng". Phân biệt khách mua, nhà bán, quản trị viên, nhân viên vận hành... Mỗi vai trò có nhu cầu riêng.
Bước 2 — Viết câu story theo công thức "Là... tôi muốn... để...". Bắt buộc điền đủ vế "để" (lợi ích). Nếu bạn không viết nổi vế lợi ích, có thể tính năng đó không thực sự cần thiết — đây là một bộ lọc giá trị rất hữu ích.
Bước 3 — Soi qua bộ lọc INVEST. Story có quá to không? Có độc lập không? Có kiểm thử được không? Nếu quá to, chẻ nhỏ như ví dụ PeopleX.
Bước 4 — Viết Acceptance Criteria. Bắt đầu từ luồng thuận lợi (happy path), rồi cố ý hỏi: "Còn nếu... thì sao?" Còn nếu để trống? Còn nếu vượt giới hạn? Còn nếu mất mạng? Mỗi câu "còn nếu" thường sinh ra một AC mới.
Bước 5 — Bổ sung Spec chi tiết nếu cần. Với nghiệp vụ có quy tắc tính toán hay nhiều điều kiện, thêm bảng quy tắc, ví dụ số liệu cụ thể, và mô tả dữ liệu vào/ra.
Bước 6 — Đọc lại bằng con mắt của dev. Tự hỏi: "Nếu tôi là lập trình viên chưa từng nói chuyện với khách, đọc tài liệu này tôi có làm được mà không cần hỏi thêm không?" Nếu còn phải đoán, viết tiếp cho rõ.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết giải pháp thay vì nhu cầu. Người ex-Sales hay viết "tôi muốn thêm nút màu xanh ở góc phải". Đó là chỉ định giải pháp, không phải nhu cầu. Hãy viết nhu cầu ("tôi muốn nhanh chóng quay lại trang chủ") và để dev/designer chọn giải pháp. Story mô tả "cái gì", không phải "thiết kế ra sao".
Lỗi 2 — Quên vế "để" (lợi ích). Thiếu phần này, đội product không biết ưu tiên thế nào. Luôn hỏi "để làm gì?" cho đến khi ra lợi ích thật.
Lỗi 3 — AC chỉ có happy path. Đây là lỗi phổ biến nhất. Mẹo: với mỗi story, ép bản thân viết ít nhất 1–2 AC cho trường hợp lỗi hoặc biên.
Lỗi 4 — Dùng ngôn ngữ marketing. Bỏ các từ "tối ưu", "mượt mà", "trải nghiệm tuyệt vời". Thay bằng tiêu chí đo được: "trang tải dưới 2 giây", "tối đa 10 mục".
Lỗi 5 — Story to như một dự án. Nếu một story cần hơn một tuần để làm, gần như chắc chắn nó cần được chẻ nhỏ.
Mẹo vàng cho dân Sales: Hãy tận dụng thói quen "hỏi đào sâu" của nghề bán hàng. Mỗi khi viết story, đặt đúng những câu hỏi bạn vẫn hỏi khách: "Anh/chị cần cái này để làm gì? Hiện tại đang vướng ở đâu? Nếu không có thì hậu quả là gì?" Câu trả lời chính là nguyên liệu cho vế lợi ích và cho các AC.
Bài tập thực hành
Hãy chọn một bối cảnh quen thuộc — ví dụ một ứng dụng giao đồ ăn như ShopeeFood hoặc GrabFood — và thực hiện:
- Viết 3 User Story cho 3 vai trò khác nhau (khách đặt món, tài xế, chủ quán) theo đúng công thức "Là... tôi muốn... để...". Bắt buộc điền đủ vế lợi ích.
- Chọn 1 trong 3 story và viết tối thiểu 5 Acceptance Criteria, trong đó có ít nhất 2 AC cho trường hợp lỗi/biên (ví dụ: quán hết món, tài xế hủy đơn, mất kết nối khi thanh toán).
- Soi story của bạn qua bộ lọc INVEST và tự đánh giá: story nào đang quá to? Hãy chẻ nó thành 2 story nhỏ hơn.
- Thử thách nâng cao: Viết một mini-spec cho quy tắc tính phí giao hàng (theo khoảng cách, theo khung giờ cao điểm, có mã giảm giá). Trình bày dưới dạng bảng quy tắc kèm 2 ví dụ số liệu cụ thể.
Tóm tắt
User Story và Spec là "sản phẩm đầu ra" hàng ngày của BA, và là phần nhà tuyển dụng kiểm tra trực tiếp nhất khi bạn chuyển nghề từ Sales/BD. Công thức cốt lõi là "Là [vai trò], tôi muốn [hành động], để [lợi ích]", đi kèm Acceptance Criteria cụ thể, đo lường được và bao gồm cả trường hợp lỗi. Người ex-Sales có ba lợi thế tự nhiên: hiểu nỗi đau người dùng (giúp viết vế lợi ích), quen hỏi đào sâu (giúp ra AC đầy đủ), và thói quen lường trước khiếu nại (giúp xử lý trường hợp biên). Điều cần luyện là điều chỉnh giọng văn từ "thuyết phục" sang "mô tả chính xác", chẻ nhỏ thay vì bán cả gói, và luôn đọc lại bằng con mắt của dev. Hãy dùng bộ lọc INVEST cho mỗi story và ép bản thân viết AC cho cả tình huống lỗi — đó là ranh giới giữa một BA tay ngang và một BA đáng tin cậy.