Mở đầu — vì sao bài này quan trọng
Trong suốt thời gian làm Customer Service, bạn đã viết ra hàng nghìn dòng ghi chú. Mỗi ngày bạn tạo ticket, log lại cuộc gọi, note vào CRM, gửi email nội bộ cho team Ops. Bạn nghĩ đó chỉ là "ghi chép cho xong việc". Nhưng thực ra bạn đã có một tài sản quý mà rất nhiều người mới vào nghề BA phải mất cả năm mới rèn được: thói quen viết lại thông tin cho người khác đọc và hành động.
Vấn đề là: cách bạn viết ticket và cách một BA viết spec (specification — tài liệu đặc tả yêu cầu) khác nhau về bản chất, chứ không chỉ khác về độ dài hay format. Một ticket giỏi và một spec giỏi phục vụ hai loại độc giả khác nhau, giải quyết hai loại rủi ro khác nhau, và được đánh giá theo hai tiêu chuẩn khác nhau.
Đây chính là "khoảng trống kỹ năng" khiến nhiều ex-CS bị loại trong 3 tháng thử việc BA. Họ viết tài liệu mà dev đọc xong vẫn phải hỏi lại 15 câu, QA không biết test cái gì, còn compliance thì không tìm thấy điều họ cần. Không phải vì họ dốt, mà vì họ đang viết spec bằng "cơ bắp" của một CS agent.
Bài này sẽ giúp bạn chuyển dịch một cách có ý thức: từ tư duy tài liệu kiểu ticket sang tư duy tài liệu kiểu spec. Đây là kỹ năng nền tảng — nó khác với việc viết User Story (Bài 4, Bài 22) hay elicit requirements (Bài 16). Bài này tập trung vào một câu hỏi duy nhất: làm sao để tài liệu bạn viết ra trở nên có cấu trúc, đầy đủ và đủ chuẩn để cả một đội ngũ kỹ thuật lẫn tuân thủ tin tưởng và hành động theo được.
Khái niệm cốt lõi
Ticket-style và Spec-style khác nhau ở đâu
Hãy bắt đầu bằng một bảng so sánh mà tôi luôn dùng khi kèm cặp học viên ex-CS:
| Khía cạnh | Ticket-style | Spec-style |
|---|---|---|
| Độc giả | CS/Ops nội bộ, người đã biết context | Dev, QA, Compliance, PM — người KHÔNG biết context |
| Mục tiêu | Giải quyết 1 case cụ thể, càng nhanh càng tốt | Định nghĩa hành vi hệ thống cho MỌI case |
| Vòng đời | Sống vài ngày rồi đóng | Sống nhiều tháng, được tham chiếu lại |
| Ngôn ngữ | Kể chuyện, chủ quan ("khách bực lắm") | Khẳng định, kiểm chứng được ("hệ thống phải...") |
| Tính đầy đủ | Chỉ cần đủ để xử lý case này | Phải phủ happy path + edge case + lỗi |
| Đo lường thành công | Case được đóng, khách hài lòng | Dev build đúng, QA test được, không hiểu nhầm |
Ba trục chuyển dịch bạn phải nắm
Trục 1: Từ "cái gì đã xảy ra" sang "cái gì phải xảy ra". Ticket ghi: "Khách hàng Nguyễn Văn A không nhận được mã OTP khi đăng nhập". Spec ghi: "Khi người dùng yêu cầu OTP, hệ thống phải gửi mã trong vòng 30 giây; nếu quá 30 giây chưa gửi được, hiển thị nút 'Gửi lại' và log sự cố vào hệ thống monitoring".
Trục 2: Từ cụ thể một case sang bao phủ toàn bộ trường hợp. CS xử lý case-by-case. BA phải hỏi: "Còn nếu khách nhập sai OTP 3 lần thì sao? Nếu OTP hết hạn thì sao? Nếu khách đổi số điện thoại giữa chừng thì sao?" Đây là tư duy coverage — phủ hết các nhánh.
Trục 3: Từ ngôn ngữ cảm tính sang ngôn ngữ kiểm chứng được. "Trang load hơi chậm" không phải là spec. "Trang phải load xong (First Contentful Paint) dưới 2 giây với kết nối 4G" mới là spec. Mỗi câu trong spec lý tưởng phải trả lời được câu hỏi: "Làm sao QA kiểm tra được câu này đúng hay sai?"
Cấu trúc xương sống của một spec chuẩn
Một spec tốt gần như luôn có các phần sau. Bạn không cần thuộc lòng, nhưng cần hiểu tại sao mỗi phần tồn tại:
- Context / Background: Bối cảnh, vấn đề nghiệp vụ. Đây là nơi bạn "bơm context" cho người không biết gì — chính là chỗ ex-CS mạnh nhất vì bạn hiểu nỗi đau khách hàng.
- Scope (In / Out): Cái gì nằm trong phạm vi, cái gì rõ ràng KHÔNG làm. Phần "Out of scope" cực kỳ quan trọng để tránh scope creep.
- Functional Requirements: Hệ thống phải làm gì, mô tả bằng câu "The system shall / Hệ thống phải...".
- Business Rules: Các quy tắc nghiệp vụ (ví dụ: "Đơn trên 5 triệu phải qua duyệt của trưởng nhóm").
- Acceptance Criteria: Điều kiện nghiệm thu — thường viết theo Given/When/Then.
- Edge cases & Error handling: Các trường hợp biên và cách xử lý lỗi.
- Non-functional: Hiệu năng, bảo mật, tuân thủ (đây là chỗ Compliance đọc).
- Open questions / Assumptions: Câu hỏi chưa có lời giải, giả định đang dùng. Ghi ra minh bạch chứ không giấu.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT Tiki — từ ticket hoàn tiền sang spec hoàn tiền
Chị Trâm, một Team Lead CS tại một sàn thương mại điện tử lớn ở TP.HCM, được kéo sang team Product làm BA. Nhiệm vụ đầu tiên: viết spec cho tính năng "hoàn tiền tự động khi hủy đơn".
Bản nháp đầu tiên của chị Trâm trông y hệt một ticket dài:
> "Khách hủy đơn thì mình hoàn tiền lại cho khách. Thường khách hủy trong ngày thì hoàn nhanh, còn hủy sau khi đã giao cho shipper thì phức tạp hơn, phải chờ shipper trả hàng về kho. Nhiều khách phàn nàn hoàn tiền lâu quá."
Dev đọc xong hỏi lại 12 câu. "Hoàn về đâu — ví điện tử hay thẻ?", "Bao lâu là nhanh?", "Trạng thái đơn nào thì cho hủy?", "Phí ship có hoàn không?". Chị Trâm nhận ra: bản nháp của chị mô tả cảm nhận, không mô tả hành vi hệ thống.
Bản viết lại theo spec-style:
> Business Rule BR-01: Đơn hàng chỉ được hủy khi ở trạng thái Pending hoặc Confirmed. Đơn ở trạng thái Shipping trở đi không cho hủy qua self-service, phải tạo yêu cầu trả hàng.
>
> FR-01: Khi đơn được hủy hợp lệ, hệ thống phải khởi tạo giao dịch hoàn tiền trong vòng 1 giờ.
>
> BR-02: Tiền hoàn về đúng phương thức thanh toán gốc. Nếu thanh toán bằng ví TikiNow → hoàn tức thì. Nếu bằng thẻ tín dụng → hoàn trong 3–7 ngày làm việc (theo quy định của cổng thanh toán).
>
> AC: Given đơn hàng thanh toán bằng ví, When khách hủy ở trạng thái Confirmed, Then số dư ví tăng đúng bằng số tiền đã trả (gồm phí ship nếu chưa giao) trong vòng 60 giây, And khách nhận thông báo push xác nhận.
Bài học rút ra: Chị Trâm không cần "thông minh hơn" — chị cần chuyển mỗi câu tường thuật thành một quy tắc kiểm chứng được. Chính kiến thức CS giúp chị biết "phí ship có hoàn không" là câu hỏi khách hay thắc mắc — nhưng chỉ khi viết nó thành business rule rõ ràng thì kiến thức đó mới dùng được cho dev.
Ví dụ 2: Ngân hàng số Cake/Timo — spec cho compliance đọc
Anh Đức làm CS tại một ngân hàng số ở Việt Nam, chuyển sang BA cho mảng onboarding tài khoản. Anh viết spec cho luồng eKYC (xác thực danh tính điện tử). Ở môi trường ngân hàng, spec không chỉ có dev và QA đọc — mà cả bộ phận Compliance và Rủi ro đọc, vì họ phải đối chiếu với quy định của Ngân hàng Nhà nước.
Bản nháp kiểu CS của anh Đức chỉ mô tả trải nghiệm khách: "Khách chụp CCCD, chụp selfie, rồi hệ thống duyệt." Compliance trả lại ngay với câu hỏi: "Dữ liệu sinh trắc học lưu ở đâu, giữ bao lâu, ai được truy cập?"
Anh Đức học được rằng với spec-style trong ngành nhạy cảm, phần Non-functional & Compliance phải viết tường minh:
> NFR-Compliance-01: Dữ liệu sinh trắc học (ảnh khuôn mặt) được mã hóa AES-256 khi lưu trữ, chỉ giữ tối đa theo thời hạn cho phép và được xóa tự động sau khi hết mục đích xử lý, phù hợp Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. > > NFR-Audit-01: Mọi lần truy cập hồ sơ eKYC phải được ghi log (ai, khi nào, mục đích) và lưu vào hệ thống audit trail, truy xuất được tối thiểu theo yêu cầu thanh tra.
Bài học rút ra: Cùng một tính năng, nhưng spec phải phục vụ NHIỀU độc giả. Ex-CS thường chỉ nghĩ đến khách hàng cuối. BA phải mở rộng "danh sách độc giả": dev cần logic, QA cần điều kiện test, compliance cần đối chiếu quy định, còn PM cần thấy scope. (Chi tiết về Nghị định 13, PDPL bạn sẽ học sâu ở Bài 44 — ở đây chỉ cần nhớ nguyên tắc: spec phải "nói được ngôn ngữ" của mọi độc giả.)
Ví dụ 3: Grab Việt Nam — khi thiếu edge case làm sập tính năng
Một BA ex-CS tại một công ty gọi xe (tạm gọi bối cảnh Grab) viết spec cho tính năng "hủy chuyến và tính phí hủy". Vì quen tư duy CS xử lý case-by-case, bạn ấy chỉ viết happy path: "Khách hủy sau 5 phút tài xế đã nhận → tính phí hủy 10.000đ."
Khi lên production, sự cố tràn ra: khách hủy nhưng tài xế cũng vừa bấm hủy cùng lúc — hệ thống tính phí cả hai bên. Khách ở vùng không có tài xế nào nhận, hủy sau 5 phút vẫn bị tính phí. Khách hủy do tài xế đi sai đường — vẫn bị tính phí, gây làn sóng khiếu nại ngược về chính team CS cũ.
Nguyên nhân gốc: spec thiếu edge case coverage. BA đã không hỏi đủ các nhánh "còn nếu...". Bản vá sau đó bổ sung ma trận trường hợp:
| Trường hợp | Ai hủy | Đã có tài xế nhận? | Tính phí? |
|---|---|---|---|
| A | Khách | Chưa | Không |
| B | Khách | Rồi, <2 phút | Không (grace period) |
| C | Khách | Rồi, >2 phút | Có |
| D | Tài xế | — | Không tính khách |
| E | Cả hai gần đồng thời | Rồi | Ưu tiên bên bấm trước |
Hướng dẫn từng bước
Đây là quy trình 7 bước bạn có thể áp dụng ngay để biến một mớ ticket/note CS thành một spec chuẩn:
- Gom nguyên liệu thô. Lấy các ticket, ghi chú CRM, phàn nàn liên quan đến tính năng bạn cần đặc tả. Đây là "quặng" — vẫn còn lẫn cảm xúc và câu chuyện.
- Xác định độc giả. Tự hỏi: ai sẽ đọc tài liệu này? Dev? QA? Compliance? PM? Danh sách độc giả quyết định những phần bạn bắt buộc phải có.
- Viết Context trước. Dùng thế mạnh CS: mô tả vấn đề nghiệp vụ và nỗi đau khách hàng bằng vài câu súc tích, kèm số liệu ("mỗi tháng có ~800 ticket than phiền về X").
- Chốt Scope (In/Out). Ghi rõ cái gì làm, cái gì KHÔNG làm trong lần này. Đây là hàng rào chống scope creep.
- Chuyển narrative thành requirement. Với mỗi câu tường thuật trong ticket, viết lại thành câu "Hệ thống phải...". Chuyển mọi tính từ cảm tính ("nhanh", "dễ") thành con số đo được.
- Quét edge case và error. Với mỗi requirement, đặt câu hỏi: "Còn nếu... thì sao?" ít nhất 3 lần. Lập ma trận trường hợp nếu logic phân nhánh nhiều.
- Viết Acceptance Criteria + Open questions. Mỗi requirement quan trọng phải có AC dạng Given/When/Then. Cuối cùng, liệt kê thẳng thắn các giả định và câu hỏi còn treo.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết spec như kể chuyện. Dấu hiệu: nhiều câu bắt đầu bằng "Khách hàng thường...", "Đôi khi...". Mẹo: chuyển sang cấu trúc "Hệ thống phải..." + "Nếu X thì Y".
Lỗi 2 — Bỏ quên "Out of scope". Không ghi rõ cái gì không làm → dev tự suy diễn, hoặc stakeholder tưởng có mà không có. Mẹo: luôn có một mục Out of scope, dù chỉ một dòng.
Lỗi 3 — Dùng tính từ mơ hồ. "Nhanh", "thân thiện", "ổn định" không test được. Mẹo: mỗi tính từ phải đi kèm con số hoặc điều kiện đo lường.
Lỗi 4 — Chỉ viết happy path. Đây là lỗi kinh điển của ex-CS quen xử lý từng case. Mẹo: đặt câu hỏi "còn nếu..." tối thiểu 3 lần cho mỗi luồng chính.
Lỗi 5 — Giấu điều mình chưa chắc. Vì sợ trông thiếu chuyên nghiệp, BA mới hay lấp liếm chỗ chưa rõ. Mẹo: mục "Open questions" là dấu hiệu của BA trưởng thành, không phải yếu kém.
Lỗi 6 — Một spec cho tất cả nhưng không phần nào rõ. Mẹo: gắn nhãn phần nào dành cho ai (ví dụ đánh dấu mục Compliance) để mỗi độc giả tìm nhanh phần của họ.
Mẹo vàng cho ex-CS: Giữ lại "giọng khách hàng". Trong phần Context, hãy trích một câu khách hàng thật (dạng ẩn danh) từ ticket. Nó khiến spec của bạn có sức thuyết phục mà BA thuần kỹ thuật khó có được — đó là lợi thế cạnh tranh nghề nghiệp của bạn.
Bài tập thực hành
Bài tập 1 — Dịch ticket sang requirement. Lấy đoạn ticket sau và viết lại thành 3 câu requirement dạng "Hệ thống phải...": > "Nhiều khách gọi lên than là đặt hàng xong không thấy email xác nhận đâu, phải đợi cả tiếng, có người còn không nhận được luôn nên đặt lại thành 2 đơn."
Gợi ý: nghĩ về thời gian gửi, cơ chế retry, và chống tạo đơn trùng.
Bài tập 2 — Quét edge case. Cho tính năng "đổi mật khẩu qua email". Liệt kê ít nhất 6 edge case/error case cần đưa vào spec (ví dụ: link hết hạn, dùng lại link cũ, email không tồn tại...).
Bài tập 3 — Viết Acceptance Criteria. Chọn một tính năng bạn từng xử lý nhiều ticket khi làm CS. Viết Context (kèm 1 con số + 1 trích dẫn khách hàng ẩn danh) và 3 acceptance criteria dạng Given/When/Then.
Bài tập 4 — Định danh độc giả. Với tính năng ở Bài tập 3, liệt kê 4 nhóm độc giả sẽ đọc spec và một câu hỏi mà mỗi nhóm sẽ đặt ra. Đây là cách rèn tư duy "spec phục vụ nhiều độc giả".
Hãy làm ít nhất Bài tập 1 và 3 rồi so sánh với đồng môn — bạn sẽ thấy ngay khoảng cách giữa narrative và specification thu hẹp nhanh thế nào.
Tóm tắt
Structured documentation không phải là học một template mới, mà là một cú chuyển dịch tư duy: từ kể lại một case đã xảy ra (ticket) sang quy định hành vi hệ thống phải xảy ra (spec). Ba trục chuyển dịch cần thuộc nằm lòng là: từ "đã xảy ra" sang "phải xảy ra", từ một case sang bao phủ mọi case, và từ ngôn ngữ cảm tính sang ngôn ngữ kiểm chứng được.
Một spec chuẩn có xương sống rõ ràng: Context, Scope, Functional Requirements, Business Rules, Acceptance Criteria, Edge cases, Non-functional/Compliance, và Open questions. Nó phục vụ nhiều độc giả — dev cần logic, QA cần điều kiện test, compliance cần đối chiếu quy định.
Điều đáng mừng là: bạn không bắt đầu từ con số không. Kho ticket và trí nhớ CS của bạn chứa đầy edge case, nỗi đau khách hàng và những câu hỏi oái oăm mà một BA thuần kỹ thuật phải mất nhiều năm mới góp nhặt được. Structured documentation chính là cây cầu biến kho tài sản đó thành thứ mà cả đội ngũ kỹ thuật lẫn tuân thủ tin tưởng và hành động theo. Hãy viết mỗi spec như thể người đọc vừa lười vừa bận — nếu họ hiểu đúng ngay lần đầu, bạn đã thành công.