Mở đầu — vì sao bài này quan trọng
Khi còn làm Sales/BD, bạn đã quá quen với việc "viết để bán": proposal, pitch deck, email follow-up. Mục tiêu duy nhất là thuyết phục người đọc gật đầu và ký hợp đồng. Nhưng khi chuyển sang BA, bản chất của việc viết thay đổi hoàn toàn. Tài liệu BA không phải để thuyết phục — nó tồn tại để loại bỏ sự mơ hồ. Một câu mô tả requirement viết sai một chữ có thể khiến đội dev xây nhầm tính năng, làm trễ sprint, và đốt tiền của doanh nghiệp.
Có một thực tế đau lòng mà tôi muốn bạn ghi nhớ: trong rất nhiều dự án phần mềm tại Việt Nam, phần lớn lỗi không nằm ở code, mà nằm ở requirement không rõ ràng. Dev code đúng những gì tài liệu viết, nhưng tài liệu viết sai ý stakeholder. Đó là lý do tại sao "documentation hiệu quả" không phải là kỹ năng phụ — nó là năng lực lõi của một BA giỏi.
Tin tốt cho bạn — người từ nền Sales — là bạn đã có sẵn một thứ rất quý: khả năng "đọc" người đọc. Một Sales giỏi biết nói với CEO khác với nói với nhân viên mua hàng. Trong BA, kỹ năng đó chính là nền tảng của một nguyên tắc cốt lõi: viết tài liệu nào, cho đối tượng nào, độ dài bao nhiêu. Bài này sẽ dạy bạn cái đó.
Khái niệm cốt lõi
Documentation taxonomy — phân loại tài liệu BA
Người mới thường gom tất cả vào một file Word khổng lồ gọi là "tài liệu dự án". Đó là sai lầm. BA chuyên nghiệp phân loại tài liệu theo đối tượng đọc (audience) và mục đích. Hãy ghi nhớ bảng phân loại nền tảng sau:
| Tài liệu | Đối tượng đọc | Mục đích | Độ dài tham khảo |
|---|---|---|---|
| BRD (Business Requirements Document) | C-level, sponsor, lãnh đạo nghiệp vụ | Trả lời "Tại sao làm dự án này?" — mục tiêu kinh doanh, phạm vi, ROI | 5–10 trang |
| SRS (Software Requirements Specification) | Dev, QA, BA, kiến trúc sư | Trả lời "Hệ thống phải làm gì và như thế nào?" — yêu cầu chức năng + phi chức năng | 15–50 trang |
| FRD (Functional Requirements Document) | Dev, QA | Mô tả chi tiết từng chức năng cụ thể, luồng xử lý | 5–20 trang |
| User Story / Acceptance Criteria | Dev, QA, Product Owner | Đơn vị làm việc nhỏ trong Agile | 1 thẻ Jira / story |
| Wireframe + chú thích | Dev, designer, stakeholder | Mô tả giao diện và tương tác | Theo màn hình |
Ba lớp tài liệu theo "altitude"
Tôi muốn bạn hình dung tài liệu BA như chụp ảnh từ máy bay ở các độ cao khác nhau:
- Tầm cao (BRD): nhìn toàn cảnh — vì sao, mục tiêu kinh doanh, ai hưởng lợi.
- Tầm trung (SRS/FRD): nhìn từng khu vực — hệ thống có những chức năng gì, quy tắc ra sao.
- Tầm thấp (User Story, AC): nhìn từng ngôi nhà — chi tiết hành vi cụ thể mà dev code.
Nguyên tắc viết "đủ và không thừa"
Documentation hiệu quả không phải là viết nhiều. Nó là viết vừa đủ để không ai phải hỏi lại, và không thừa đến mức không ai chịu đọc. Có ba tiêu chí vàng:
- Clear (rõ ràng): một câu chỉ có một cách hiểu. Tránh từ mơ hồ như "nhanh", "thân thiện", "linh hoạt".
- Concise (súc tích): cắt mọi câu không thêm thông tin. Đây là nơi ex-Sales hay mắc bệnh "viết hoa mỹ".
- Consistent (nhất quán): cùng một khái niệm phải gọi cùng một tên trong toàn bộ tài liệu. Đừng lúc gọi "khách hàng", lúc gọi "user", lúc gọi "người dùng cuối".
Tình huống thực tế
Tình huống 1 — Lỗi "gửi nhầm tài liệu cho nhầm người" tại một startup SaaS TP.HCM
Một công ty SaaS quản lý kho hàng ở Quận 1, TP.HCM (khoảng 40 nhân sự) thuê một BA mới — vốn là Sales Manager chuyển sang. Trong dự án xây module báo cáo tồn kho, anh viết một tài liệu duy nhất dài 38 trang, trộn lẫn cả mục tiêu kinh doanh lẫn chi tiết kỹ thuật, rồi gửi cho cả CEO lẫn đội dev.
Kết quả: CEO mở file, thấy trang 3 đã bắt đầu nói về "API endpoint" và "database schema", liền đóng lại và không bao giờ phê duyệt phạm vi. Trong khi đó, đội dev đọc lướt phần đầu nói về "tăng trưởng doanh thu 20%" rồi bỏ qua, dẫn đến hiểu sai về quy tắc tính tồn kho ở trang 25. Sprint đầu tiên xây sai logic, tốn 2 tuần làm lại, thiệt hại ước tính khoảng 60 triệu đồng chi phí nhân sự.
Diễn giải: vấn đề không phải anh viết kém — 38 trang đó nội dung khá đầy đủ. Vấn đề là anh không phân tách tài liệu theo audience. Lẽ ra phải tách thành một BRD 6 trang cho CEO (chỉ nói mục tiêu, phạm vi, lợi ích) và một SRS 30 trang cho đội kỹ thuật.
Bài học: Đừng bao giờ để một người đọc phải lội qua nội dung không dành cho họ. Tài liệu sai audience = tài liệu không ai dùng.
Tình huống 2 — "Living document" cứu một dự án fintech tại Hà Nội
Một công ty fintech ví điện tử tại Hà Nội triển khai tính năng "trả góp qua thẻ". BA của dự án — một bạn từng làm BD mảng ngân hàng — áp dụng nguyên tắc single source of truth (một nguồn sự thật duy nhất): toàn bộ requirement được đặt trên Confluence, mỗi user story trên Jira đều link tới mục business rule tương ứng trên Confluence, không ai gửi tài liệu qua email hay Zalo nữa.
Giữa dự án, phòng pháp chế yêu cầu thay đổi: lãi suất trả góp phải hiển thị rõ theo Thông tư của Ngân hàng Nhà nước. Vì tài liệu là "living" (sống, cập nhật liên tục) và có traceability, BA chỉ mất nửa ngày để: cập nhật business rule trên Confluence, hệ thống tự thông báo cho mọi story bị ảnh hưởng, và đánh dấu 4 màn hình cần sửa. Không có gì bị bỏ sót.
Diễn giải: Tài liệu Word gửi qua email là tài liệu "chết" — mỗi người giữ một phiên bản, không ai biết bản nào mới nhất. Khi requirement thay đổi (mà nó luôn thay đổi), tài liệu chết gây ra hỗn loạn.
Bài học: Documentation hiệu quả không phải là một file hoàn hảo lúc đầu, mà là một hệ thống dễ cập nhật khi mọi thứ thay đổi. Confluence + Jira với link hai chiều là chuẩn công nghiệp.
Tình huống 3 — Một câu mơ hồ làm lệch cả tính năng
Tại một công ty thương mại điện tử ở Đông Nam Á, BA viết acceptance criteria: "Hệ thống phải xử lý đơn hàng nhanh". Dev hiểu "nhanh" là dưới 5 giây và tối ưu theo đó. Nhưng stakeholder kỳ vọng "nhanh" nghĩa là phản hồi tức thì dưới 1 giây cho khách hàng VIP. Đến UAT (kiểm thử nghiệm thu), mâu thuẫn nổ ra, và phải redesign phần caching, trễ go-live 3 tuần.
Diễn giải: từ "nhanh" là một non-functional requirement không được định lượng. Đáng lẽ phải viết: "Đơn hàng của khách VIP phải được xác nhận trong vòng ≤ 1 giây ở 95% trường hợp (p95)".
Bài học: Mọi tính từ định tính ("nhanh", "ổn định", "dễ dùng") đều là cái bẫy. Documentation hiệu quả luôn định lượng mọi thứ có thể đo được.
Hướng dẫn từng bước
Đây là quy trình thực chiến để tạo bộ tài liệu hiệu quả cho một tính năng:
Bước 1 — Xác định audience trước khi viết một chữ. Hỏi: ai sẽ đọc cái này? Sếp duyệt ngân sách? Dev code? QA test? Mỗi đối tượng = một loại tài liệu với độ sâu khác nhau. Đừng viết khi chưa trả lời câu này.
Bước 2 — Bắt đầu từ tầm cao xuống tầm thấp. Viết BRD trước (mục tiêu, phạm vi), được sponsor duyệt, rồi mới triển khai xuống SRS/FRD, cuối cùng mới chẻ nhỏ thành user story. Làm ngược lại sẽ khiến bạn xây chi tiết cho thứ chưa được duyệt phạm vi.
Bước 3 — Dùng template chuẩn, đừng viết từ trang trắng. Mỗi loại tài liệu nên có khung cố định. Ví dụ SRS gồm: Mục đích → Phạm vi → Yêu cầu chức năng → Yêu cầu phi chức năng → Business rules → Giả định & ràng buộc. Template giúp bạn không quên mục và giúp người đọc biết tìm thông tin ở đâu.
Bước 4 — Định lượng mọi thứ. Thay "tải nhanh" bằng "≤ 2 giây", thay "nhiều người dùng" bằng "1.000 user đồng thời". Con số là kẻ thù của sự mơ hồ.
Bước 5 — Thêm hình ảnh khi chữ không đủ. Một sơ đồ luồng (flowchart), một wireframe, một bảng quyết định (decision table) thường thay thế được cả trang văn xuôi. Quy tắc: nếu phải mô tả luồng có nhiều nhánh if-else bằng chữ, hãy vẽ.
Bước 6 — Thiết lập traceability. Mỗi requirement chi tiết phải có ID (ví dụ FR-012) và link ngược lên mục tiêu kinh doanh. Điều này cho phép phân tích tác động khi có thay đổi.
Bước 7 — Đưa lên single source of truth và review. Đặt tài liệu trên Confluence/Jira, không phát tán qua email. Tổ chức một buổi walkthrough cho dev và QA để họ đặt câu hỏi — câu hỏi của họ chính là chỗ tài liệu còn mơ hồ.
Bước 8 — Cập nhật liên tục. Khi requirement đổi, sửa ngay nguồn gốc và đánh version. Tài liệu lỗi thời còn nguy hiểm hơn không có tài liệu, vì nó tạo niềm tin sai.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết kiểu Sales: hoa mỹ, thuyết phục. Ex-Sales hay viết "Tính năng tuyệt vời này sẽ mang lại trải nghiệm liền mạch". Dev đọc xong không biết phải code gì. Mẹo: sau khi viết mỗi câu, tự hỏi "dev có thể biến câu này thành code không?". Nếu không, viết lại.
Lỗi 2 — Một tài liệu cho tất cả mọi người. Như tình huống 1. Mẹo: luôn tách BRD (cho sếp) khỏi SRS (cho kỹ thuật).
Lỗi 3 — Dùng tính từ định tính. "Nhanh", "thân thiện", "ổn định". Mẹo: gạch chân mọi tính từ trong tài liệu, và biến mỗi cái thành con số đo được.
Lỗi 4 — Tài liệu chết gửi qua email/Zalo. Mỗi người một phiên bản. Mẹo: chỉ có một nguồn sự thật, mọi nơi khác chỉ là link tới nó.
Lỗi 5 — Viết quá dài vì sợ thiếu. Tài liệu 50 trang mà không ai đọc còn tệ hơn 10 trang ai cũng đọc. Mẹo: sau khi viết xong, cắt 20% — gần như luôn cắt được mà không mất thông tin.
Lỗi 6 — Không có mục lục, không có ID requirement. Người đọc lạc lối. Mẹo: mọi tài liệu trên 5 trang phải có mục lục; mọi requirement phải có ID duy nhất.
Mẹo vàng tận dụng nền Sales: kỹ năng đọc đối tượng của bạn là siêu năng lực. Trước khi viết, hãy "pitch ngược": hình dung người đọc, họ cần gì, họ ghét đọc gì. Một Sales giỏi không bao giờ đưa nhầm tài liệu — hãy mang chính bản năng đó vào nghề BA.
Bài tập thực hành
- Phân loại tài liệu: Lấy một tính năng giả định — "thêm chức năng đặt lịch hẹn online cho một phòng khám". Liệt kê 3 loại tài liệu bạn cần viết, ứng với 3 đối tượng đọc khác nhau, và ghi rõ độ dài ước tính cho mỗi loại.
- Sửa câu mơ hồ: Viết lại 3 câu sau thành requirement định lượng, rõ ràng:
- Viết mini-BRD: Soạn một BRD dài tối đa 1 trang cho tính năng phòng khám ở bài 1, gồm 4 mục: Mục tiêu kinh doanh, Phạm vi, Lợi ích kỳ vọng (có con số), Ràng buộc. Tự kiểm: liệu một giám đốc bận rộn có đọc hết trong 3 phút không?
- Tự rà soát: Lấy lại một proposal/email bạn từng viết thời làm Sales. Đếm số tính từ hoa mỹ và số câu mang tính thuyết phục thay vì thông tin. Đây là "thói quen Sales" bạn cần cai khi viết tài liệu BA.
Tóm tắt
- Tài liệu BA tồn tại để loại bỏ sự mơ hồ, không phải để thuyết phục. Đây là chuyển dịch tư duy lớn nhất từ Sales sang BA.
- Phân loại tài liệu theo audience: BRD (5–10 trang) cho C-level, SRS (15–50 trang) cho dev/QA, FRD (5–20 trang) cho chi tiết chức năng. Độ dài tỉ lệ nghịch với cấp bậc người đọc.
- Viết theo ba tầm "altitude" — cao (vì sao), trung (làm gì), thấp (làm thế nào) — và đảm bảo traceability liên kết chúng.
- Ba tiêu chí vàng: Clear, Concise, Consistent. Định lượng mọi thứ, loại bỏ tính từ mơ hồ.
- Dùng single source of truth (Confluence + Jira) để tài liệu là "living document" dễ cập nhật, không phát tán file chết qua email.
- Tận dụng siêu năng lực ex-Sales: khả năng đọc đối tượng. Luôn hỏi "ai đọc cái này?" trước khi viết một chữ.