title: "Xây dựng tài liệu "khách hàng yêu thích": Đừng viết cho mình, hãy viết cho họ"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 22
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "10 phút"
tags: ["BRD", "tài liệu dự án", "kỹ năng viết", "giao tiếp khách hàng", "business analyst", "requirements documentation"]

Xây dựng tài liệu "khách hàng yêu thích": Đừng viết cho mình, hãy viết cho họ

Bạn có bao giờ dành ba tuần viết một tài liệu 80 trang, gửi đi, rồi nhận lại đúng một câu trả lời: "OK, em xem giúp chị bản tóm tắt được không, tài liệu dài quá chị chưa đọc hết"? Nếu có, bạn không đơn độc — đó là số phận của phần lớn tài liệu BA viết ra. Vấn đề không nằm ở việc tài liệu thiếu thông tin, mà ở chỗ nó được viết theo cấu trúc thuận tiện cho người viết, chứ không theo thứ tự câu hỏi mà người đọc thực sự quan tâm.

🎯 Kỹ thuật cốt lõi: Viết theo câu hỏi của người đọc, không theo quy trình của người viết

Cấu trúc tài liệu BA truyền thống thường đi theo trình tự thu thập thông tin: bối cảnh dự án → phạm vi → actor/role → quy trình nghiệp vụ hiện tại (as-is) → quy trình đề xuất (to-be) → yêu cầu chức năng → yêu cầu phi chức năng → phụ lục. Đây là trình tự HỢP LÝ VỚI NGƯỜI VIẾT — nó phản ánh cách BA đã điều tra và tổng hợp thông tin. Nhưng nó gần như ngẫu nhiên đối với người đọc, vì mỗi người đọc tài liệu với một câu hỏi khác nhau trong đầu, và câu hỏi đó hiếm khi là "quy trình as-is trông như thế nào".

Kỹ thuật cốt lõi ở đây gọi là viết theo "câu hỏi của độc giả" (reader's question-driven structure) — thay vì tổ chức tài liệu theo quy trình nội bộ, hãy liệt kê trước các câu hỏi mà TỪNG nhóm người đọc sẽ đặt ra khi cầm tài liệu lên, rồi thiết kế cấu trúc để mỗi mục trả lời đúng một câu hỏi, theo đúng thứ tự ưu tiên của họ. Ba bước để áp dụng framework này cho bất kỳ tài liệu nào:

Liệt kê độc giả và câu hỏi của họ. Với mỗi nhóm sẽ đọc tài liệu (CEO/sponsor, trưởng phòng nghiệp vụ, kế toán/vận hành, đội kỹ thuật đối tác…), viết ra 3-5 câu hỏi họ thực sự muốn biết. Sponsor hỏi "cái này giải quyết vấn đề gì và tốn bao nhiêu", trưởng phòng nghiệp vụ hỏi "công việc hàng ngày của nhân viên tôi thay đổi ra sao", kế toán hỏi "số liệu báo cáo có còn đúng như cũ không".
Xếp câu hỏi theo tần suất và mức độ quan trọng, không theo trình tự thu thập. Câu hỏi được hỏi nhiều nhất, bởi người có quyền quyết định cao nhất, phải nằm ở đầu tài liệu — bất kể nó được BA điều tra ra ở giai đoạn nào của dự án.
Mỗi mục = một câu hỏi = một câu trả lời trực tiếp trong 1-2 câu đầu, rồi mới đến chi tiết. Không bắt người đọc phải tự suy luận câu trả lời từ một bảng dữ liệu hay một sơ đồ luồng phức tạp.

Nói ngắn gọn: cấu trúc quy trình nội bộ tối ưu cho việc SOẠN THẢO, cấu trúc câu hỏi độc giả tối ưu cho việc ĐƯỢC ĐỌC. Một tài liệu chỉ có giá trị khi nó được đọc.

Bối cảnh (Situation)

(Tình huống minh hoạ tổng hợp từ các dự án tư vấn/CNTT phổ biến tại Việt Nam, không phải case cụ thể của một công ty có thật, số liệu chỉ mang tính minh hoạ.)

Chị H., BA của một dự án triển khai hệ thống quản lý bán hàng cho một chuỗi cửa hàng bán lẻ vừa và nhỏ, vừa hoàn thành giai đoạn khảo sát kéo dài sáu tuần với kho, thu ngân, kế toán, marketing và ban giám đốc. Kết quả là một BRD (Business Requirements Document) dày 78 trang, tổ chức theo chuẩn công ty vẫn dùng: Chương 1 giới thiệu dự án, Chương 2 mô tả tổ chức, Chương 3 là 24 quy trình nghiệp vụ hiện tại (as-is) vẽ bằng BPMN, Chương 4 là quy trình đề xuất (to-be), Chương 5 liệt kê 156 yêu cầu chức năng đánh số theo module, Chương 6 là yêu cầu phi chức năng, và ba phụ lục.

Chị gửi tài liệu qua email cho anh T., Giám đốc vận hành kiêm sponsor chính của dự án phía khách hàng, kèm lời đề nghị "anh xem và cho ý kiến trước cuộc họp phê duyệt thứ Năm tuần sau". Đến chiều thứ Tư, chị nhận lại một tin nhắn ngắn: "Chị đọc được khoảng 15 trang thì hơi rối, em tóm tắt lại giúp chị mấy điểm chính được không? Cuộc họp mai chị cần biết dự án này giải quyết được gì cho vận hành cửa hàng, còn phần kỹ thuật để đội IT bên chị xem sau." Đội dự án đã bỏ ra sáu tuần khảo sát và ba tuần viết tài liệu, nhưng người quyết định phê duyệt gần như không đọc nó.

Thách thức (Task)

Vấn đề của chị H. không phải là tài liệu thiếu thông tin — ngược lại, nó có thể còn đầy đủ hơn mức cần thiết. Vấn đề là tài liệu không được thiết kế để TRẢ LỜI đúng câu hỏi mà từng người đọc thực sự đang mang trong đầu khi mở file ra.

Anh T., với vai trò sponsor, không cần biết chi tiết 156 yêu cầu chức năng đánh số theo module ngay từ đầu — anh cần biết trong 5 phút đầu tiên: "Hệ thống này giải quyết vấn đề gì cho tôi, chi phí vận hành có thay đổi không, nhân viên có phải đào tạo lại nhiều không, rủi ro lớn nhất là gì". Những câu trả lời đó nằm rải rác ở trang 3, trang 34, trang 61 và trang 75 — người đọc bình thường không đủ kiên nhẫn để lật tìm.

Cái khó ở đây là: nếu chị H. xử lý sai — chỉ đơn giản viết một bản tóm tắt điều hành (executive summary) ngắn dán lên đầu tài liệu cũ mà không đổi cấu trúc gốc — thì vấn đề sẽ lặp lại ở lần tài liệu tiếp theo, và tệ hơn, khách hàng sẽ hình thành thói quen "không cần đọc tài liệu BA, chỉ cần nghe BA trình bày miệng". Điều đó làm suy yếu vai trò của tài liệu như một cam kết phạm vi được ký duyệt chính thức — nếu sau này phát sinh tranh cãi về phạm vi, tài liệu không ai đọc kỹ sẽ không bảo vệ được BA lẫn dự án. Rủi ro thực sự là mất đi công cụ quản trị phạm vi (scope) quan trọng nhất của cả dự án.

Hành động (Action)

Chị H. quyết định không sửa nhỏ mà viết lại toàn bộ cấu trúc tài liệu theo kỹ thuật câu hỏi của độc giả. Các bước chị làm:

Bước 1 — Lập bảng "Độc giả × Câu hỏi" trước khi đụng vào nội dung cũ. Chị liệt kê bốn nhóm sẽ đọc tài liệu này: Ban giám đốc/sponsor, Trưởng bộ phận vận hành, Kế toán trưởng, và Đội kỹ thuật đối tác. Với mỗi nhóm, chị viết ra 3-4 câu hỏi thực họ từng hỏi trong các buổi khảo sát — không phải câu hỏi chị đoán, mà câu hỏi đã NGHE thấy họ hỏi. Ví dụ nhóm sponsor: "Dự án này giải quyết vấn đề gì?", "Chi phí, thời gian triển khai bao lâu?", "Rủi ro lớn nhất nếu làm, và nếu không làm thì sao?".

Bước 2 — Thiết kế lại mục lục theo thứ tự ưu tiên của câu hỏi, không theo trình tự khảo sát. Thay vì mở đầu bằng "giới thiệu dự án và phạm vi khảo sát" (thứ tự thuận cho người viết), chị mở đầu bằng một trang duy nhất tên "Tóm tắt cho người quyết định" trả lời thẳng 4 câu hỏi của sponsor bằng ngôn ngữ không kỹ thuật, kèm một bảng so sánh "trước và sau" ngắn gọn. Mục lục mới của tài liệu trở thành:

Mục 1: Vấn đề đang giải quyết là gì, và giải pháp tổng quan (dành cho sponsor)
Mục 2: Công việc hàng ngày của từng vị trí sẽ thay đổi ra sao (dành cho trưởng bộ phận) — trình bày bằng bảng "trước đây làm X, sau này làm Y", không phải bằng sơ đồ BPMN
Mục 3: Số liệu, báo cáo, đối soát có đảm bảo không (dành cho kế toán)
Mục 4: Chi tiết yêu cầu chức năng đầy đủ, ký hiệu module, ràng buộc kỹ thuật (dành cho đội kỹ thuật) — đây mới là nơi đặt 156 yêu cầu cũ, gần như giữ nguyên
Phụ lục: Toàn bộ sơ đồ BPMN as-is/to-be chi tiết, cho ai cần tra cứu sâu

Bước 3 — Mỗi mục mở đầu bằng câu trả lời trực tiếp, rồi mới đến bằng chứng/chi tiết. Ví dụ Mục 2 không mở bằng "Quy trình bán hàng hiện tại gồm 5 bước sau đây", mà mở bằng: "Nhân viên thu ngân sẽ KHÔNG phải nhập lại tồn kho thủ công cuối ngày nữa — hệ thống tự đối chiếu. Thời gian chốt ca dự kiến giảm từ 25 phút xuống 5 phút." Sau đó mới là quy trình chi tiết cho ai muốn xem kỹ.

Bước 4 — Thêm "đường dẫn đọc" (reading path) ngay đầu tài liệu. Chị viết một khung nhỏ ngay trang đầu: "Nếu anh/chị chỉ có 10 phút, đọc Mục 1. Nếu anh/chị phụ trách vận hành, đọc thêm Mục 2. Đội kỹ thuật đọc Mục 4 và Phụ lục." Điều này thừa nhận công khai rằng không ai cần đọc hết, và hướng dẫn họ đọc đúng phần của mình thay vì bỏ cuộc giữa chừng.

Bước 5 — Kiểm tra lại bằng cách tự đặt mình vào vai người đọc. Trước khi gửi, chị H. in riêng Mục 1 ra, tự hỏi: "Nếu tôi là anh T., đọc một mình trang này trong thang máy 3 phút, tôi có trả lời được câu hỏi 'dự án này để làm gì và có nên phê duyệt không' không?" Chị chỉnh sửa cho đến khi câu trả lời là có.

Kết quả (Result)

Tài liệu mới giữ nguyên nội dung kỹ thuật cũ — không thiếu yêu cầu chức năng nào — chỉ đổi cấu trúc trình bày. Anh T. đọc xong Mục 1 (2 trang) trong 10 phút, hỏi thêm ba câu qua điện thoại, rồi phê duyệt đúng lịch — điều tài liệu cũ đã không làm được. Trưởng bộ phận vận hành, người trước đó chưa từng mở BRD, lần đầu đọc hết Mục 2 và phát hiện một tình huống ngoại lệ (hàng trả lại không qua thu ngân chính) mà đội khảo sát đã bỏ sót — phát hiện chỉ đến được vì tài liệu đủ dễ đọc để bà xem kỹ.

Điều chưa hoàn hảo: viết lại theo cấu trúc mới tốn thêm gần một tuần làm việc của chị H. — chi phí này cần được tính vào kế hoạch dự án ngay từ đầu, không phải làm thêm giờ khi đã trễ. Đội kỹ thuật đối tác cũng hơi khó chịu vì "phần của họ" (Mục 4) bị đẩy xuống cuối thay vì đứng đầu như thói quen cũ — chị H. phải giải thích rằng thứ tự tài liệu phản ánh ai cần đọc trước để ra quyết định, không phản ánh mức độ quan trọng của công việc.

📋 Áp dụng ngay

Trước khi viết bất kỳ tài liệu nào, dành 15 phút lập bảng "Nhóm độc giả × 3 câu hỏi thực họ từng hỏi" — lấy từ những gì bạn đã NGHE, không đoán.
Đặt câu trả lời trực tiếp (1-2 câu, ngôn ngữ không kỹ thuật) ở đầu mỗi mục, đẩy chi tiết/bằng chứng xuống sau.
Thêm một khung "đường dẫn đọc" ở đầu tài liệu, chỉ rõ ai nên đọc phần nào — đừng ngại thừa nhận không ai cần đọc hết.
Chuyển toàn bộ nội dung kỹ thuật thuần tuý (BPMN chi tiết, đặc tả API, bảng dữ liệu dài) xuống phụ lục, giữ phần thân tài liệu cho quyết định và tác động.
Tự kiểm tra bằng cách đọc lại mục quan trọng nhất trong vai người bận rộn nhất — nếu họ không thể trả lời câu hỏi của mình sau khi đọc, viết lại.

💡 Bài học đúc rút (Key Takeaway): Một tài liệu đầy đủ mà không ai đọc thì giá trị thực tế bằng không. Việc của BA không phải là ghi lại mọi thứ mình biết theo trình tự mình đã tìm hiểu ra, mà là sắp xếp lại kiến thức đó theo trình tự câu hỏi mà người đọc thực sự mang trong đầu — viết cho người đọc, không viết cho chính mình.

🔗 Kỹ năng liên quan

Kỹ thuật ghi chú thông minh — nền tảng để có nguyên liệu chính xác trước khi tổ chức lại thành tài liệu
Kỹ năng Visual Thinking — công cụ trình bày trực quan hỗ trợ cấu trúc theo câu hỏi độc giả
Nghệ thuật "Dịch thuật" — kỹ năng chuyển ngôn ngữ kỹ thuật sang ngôn ngữ người đọc, bổ trợ trực tiếp cho bài này

Bài trước: Kỹ thuật ghi chú thông minh · Bài tiếp theo: Quản trị kỳ vọng về thời gian