Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một loạt buổi phỏng vấn, workshop và đã có trong tay một mớ user story rất "ngon". Nhưng khi bạn đem đống đó đi gặp Giám đốc tài chính để xin ngân sách, ông ấy hỏi: "Dự án này giải quyết bài toán kinh doanh gì? Tôi bỏ 2 tỷ ra thì thu lại được gì?" — và bạn ấp úng. Đó chính là khoảng trống mà BRD và PRD lấp vào.
Trong thực tế làm BA tại Việt Nam, hai loại tài liệu này là thứ phân biệt một BA "ghi chép yêu cầu" với một BA "dẫn dắt dự án". User story (đã học ở Bài 6) trả lời câu hỏi làm cái gì cho người dùng. Nhưng trước khi viết được một dòng user story nào, ai đó phải trả lời được tại sao công ty nên làm dự án này (BRD) và sản phẩm cụ thể trông như thế nào (PRD). Đây là tầng tài liệu cao hơn, nơi BA giao tiếp với cả lãnh đạo lẫn đội phát triển.
Nhiều BA mới đi làm nhầm lẫn BRD, PRD, FRD, SRS thành một mớ hỗn độn. Trong bài này, chúng ta tập trung sâu vào BRD và PRD — hai tài liệu bạn sẽ viết nhiều nhất trong giai đoạn đầu dự án. Hiểu rõ hai cái này, bạn sẽ biết viết tài liệu nào, cho ai đọc, và với mức chi tiết ra sao. Đây là kỹ năng tạo ra uy tín nghề nghiệp rất nhanh.
Khái niệm cốt lõi
BRD — Business Requirements Document là gì?
BRD là tài liệu cấp cao mô tả nhu cầu kinh doanh (business need) mà dự án phải đáp ứng. Nó trả lời câu hỏi "TẠI SAO" và "CÁI GÌ ở tầm chiến lược", chứ không đi vào "LÀM NHƯ THẾ NÀO". Người đọc chính của BRD là ban lãnh đạo, project sponsor, các phòng ban liên quan — những người quyết định có rót tiền và nguồn lực hay không.
Một BRD chuẩn thường gồm các phần:
- Executive Summary — Tóm tắt 1 đoạn ngắn: chúng ta đang giải quyết vấn đề gì, vì sao cấp thiết, và kỳ vọng kết quả. Đây là phần lãnh đạo đọc kỹ nhất, đôi khi là phần duy nhất họ đọc.
- Business Objectives — Mục tiêu kinh doanh, nên gắn với số đo cụ thể (ví dụ: giảm thời gian xử lý đơn hàng từ 48h xuống 12h).
- Project Scope — Phạm vi: cái gì NẰM TRONG và đặc biệt là cái gì NẰM NGOÀI (out of scope). Phần out-of-scope quý hơn vàng vì nó chặn scope creep.
- Stakeholders — Ai liên quan, vai trò gì.
- Business Requirements — Các yêu cầu ở mức nghiệp vụ, không phải tính năng. Ví dụ: "Hệ thống phải cho phép khách hàng tự theo dõi trạng thái đơn hàng" — chưa nói màn hình hay nút bấm nào.
- Assumptions & Constraints — Giả định và ràng buộc (ngân sách, thời gian, công nghệ, pháp lý).
- Success Metrics — Làm sao biết dự án thành công.
PRD — Product Requirements Document là gì?
PRD là tài liệu mô tả sản phẩm cụ thể sẽ được xây để đáp ứng business need trong BRD. Nó trả lời "SẢN PHẨM NÀY LÀM GÌ, CHO AI, VỚI HÀNH VI RA SAO". Người đọc chính của PRD là Product Owner, đội dev, đội QA, designer. PRD là cầu nối giữa tầm nhìn kinh doanh (BRD) và việc thực thi kỹ thuật.
Một PRD điển hình (đặc biệt theo phong cách Agile hiện đại) gồm:
- Mục tiêu sản phẩm (Product goal) và vấn đề người dùng đang gặp.
- Personas / đối tượng người dùng.
- User flows — luồng người dùng đi qua sản phẩm.
- Features & requirements — danh sách tính năng, thường kèm mức ưu tiên (Must/Should/Could — mô hình MoSCoW).
- Functional requirements — mô tả từng tính năng hoạt động ra sao, đôi khi kèm acceptance criteria gọn.
- Non-functional requirements — hiệu năng, bảo mật, khả năng mở rộng.
- Out of scope, release plan, open questions.
Phân biệt nhanh để khỏi nhầm
Cách tôi hay dạy học viên nhớ: BRD là "tại sao và cái gì ở tầm doanh nghiệp"; PRD là "sản phẩm cụ thể làm gì". BRD do BA viết hướng tới sponsor. PRD do BA hoặc Product Owner viết hướng tới đội xây dựng. Trong nhiều startup Việt Nam làm Agile thuần, BRD bị gộp luôn vào phần đầu PRD; nhưng trong doanh nghiệp lớn (ngân hàng, bảo hiểm, tập đoàn) thì BRD vẫn là tài liệu độc lập, có chữ ký phê duyệt hẳn hoi vì liên quan ngân sách và kiểm toán.
Lưu ý: FRD, SRS sẽ được học sâu ở các bài sau trong khóa — ở bài này chúng ta cố tình không lấn sang đó. Bạn chỉ cần nắm: FRD/SRS đi sâu hơn PRD về mặt kỹ thuật chi tiết.
Tình huống thực tế
Ví dụ 1: BRD cứu một dự án ngân hàng khỏi "đốt tiền"
Một ngân hàng tầm trung tại TP.HCM (gọi là VietPay Bank) muốn xây app cho khách hàng tự mở tài khoản online. Ban đầu phòng IT nhảy vào code luôn vì "ai chẳng biết mở tài khoản là gì". Sau 3 tháng và khoảng 1,5 tỷ đồng, sản phẩm ra mắt nhưng tỷ lệ khách hoàn tất quy trình chỉ 18%.
Khi BA được mời vào, cô ấy viết một BRD ngược (retroactive) và phát hiện business need thật chưa bao giờ được định nghĩa rõ. Trong Executive Summary, mục tiêu kinh doanh thực sự đáng lẽ phải là: "Giảm chi phí mở tài khoản tại quầy (đang ở mức ~120.000đ/khách) và tăng số tài khoản mới của nhóm khách 22–35 tuổi thêm 30% trong 12 tháng." Nhưng đội IT đã tối ưu cho... nhân viên ngân hàng, không phải khách hàng trẻ. Phần Success Metrics trong BRD nếu được viết từ đầu sẽ ép cả nhóm đo "tỷ lệ hoàn tất eKYC" — chỉ số mà không ai theo dõi.
Bài học: BRD không phải thủ tục giấy tờ. Nó buộc cả tổ chức đồng thuận vì sao làm trước khi tiêu tiền. Một đoạn Executive Summary và Success Metrics rõ ràng đáng giá hàng tỷ đồng.
Ví dụ 2: PRD mơ hồ khiến đội dev và BA "đánh nhau"
Một công ty thương mại điện tử ở Hà Nội (gọi là ShopFast) làm tính năng "đổi trả hàng tự động". BA viết PRD nhưng phần Functional Requirements chỉ ghi: "Khách hàng có thể yêu cầu đổi trả sản phẩm." Đội dev đọc xong làm theo cách hiểu của họ: cho đổi trả MỌI sản phẩm, MỌI lúc.
Khi sang sprint review, BA mới tá hỏa vì chính sách công ty là chỉ đổi trả trong 7 ngày, không áp dụng cho hàng giảm giá trên 50%, và phải còn nguyên tem. Đội dev bức xúc: "PRD đâu có ghi mấy cái đó." Họ đúng. Hậu quả: mất thêm 2 sprint để làm lại, khoảng 3 tuần trễ tiến độ.
BA sau đó viết lại PRD với từng functional requirement rõ ràng kèm điều kiện: thời hạn 7 ngày, danh sách loại trừ, trạng thái sản phẩm, và quan trọng nhất là một bảng các trường hợp ngoại lệ. Cô cũng thêm phần "Open Questions" để những điểm chưa chốt được hiển thị rõ thay vì giả định ngầm.
Bài học: PRD mơ hồ không tiết kiệm thời gian — nó dời chi phí sang giai đoạn dev đắt đỏ hơn nhiều. Mỗi functional requirement nên kiểm được bằng câu hỏi: "Một dev chưa từng dự họp có hiểu đúng và làm đúng không?"
Ví dụ 3: Gộp BRD vào PRD trong startup — khi nào hợp lý
Một startup fintech ở Singapore phục vụ thị trường Đông Nam Á làm theo Agile thuần, đội chỉ 12 người. Họ không tách BRD riêng mà gói gọn business context vào trang đầu của PRD: một đoạn "Why now", một bảng OKR quý, rồi đi thẳng vào product goal và features. Cách này hiệu quả vì cả đội ngồi chung, sponsor là chính CEO, không có quy trình kiểm toán bắt buộc.
Khi startup này được một tập đoàn lớn của Nhật mua lại, đối tác Nhật yêu cầu BRD độc lập có phê duyệt chính thức cho mọi sáng kiến trên 50.000 USD. Lúc này cách "gộp" không còn dùng được, BA phải học cách tách lớp tài liệu trở lại.
Bài học: Mức độ trang trọng của tài liệu phụ thuộc vào bối cảnh tổ chức, không có công thức cứng. BA giỏi biết điều chỉnh độ "nặng" của tài liệu cho phù hợp với quy mô và văn hóa doanh nghiệp.
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để viết BRD rồi PRD cho một sáng kiến mới.
Bước 1 — Xác định bạn cần BRD, PRD, hay cả hai. Nếu dự án cần xin ngân sách lớn, liên quan nhiều phòng ban, hoặc có yêu cầu kiểm toán: viết BRD riêng. Nếu là tính năng nội bộ trong sản phẩm đã có, đội nhỏ: có thể chỉ cần PRD với phần business context ngắn ở đầu.
Bước 2 — Viết Executive Summary của BRD trước tiên. Gói gọn trong 4–6 câu: vấn đề kinh doanh, mức độ cấp thiết, đối tượng hưởng lợi, kết quả kỳ vọng. Viết phần này đầu tiên buộc bạn làm rõ tư duy. Nếu không viết nổi đoạn này, nghĩa là bạn chưa hiểu dự án.
Bước 3 — Định nghĩa Business Objectives gắn số đo. Tránh mục tiêu chung chung kiểu "cải thiện trải nghiệm khách hàng". Thay vào đó: "Tăng tỷ lệ giữ chân khách hàng tháng từ 60% lên 70% trong Q3." Mỗi mục tiêu cần đo được (đây là tinh thần SMART).
Bước 4 — Khoanh vùng Scope, đặc biệt là Out-of-scope. Liệt kê rõ những gì KHÔNG làm trong phạm vi này. Ví dụ: "Tích hợp ví điện tử không nằm trong phase 1." Đây là tấm khiên chống scope creep mạnh nhất bạn có.
Bước 5 — Chuyển từ Business Requirements (BRD) sang Product Features (PRD). Với mỗi business requirement, hỏi: "Sản phẩm cần có tính năng gì để đáp ứng?" Một business requirement có thể đẻ ra nhiều tính năng. Đây là điểm BA dễ mắc lỗi nhất — nhảy thẳng vào tính năng mà quên gốc nghiệp vụ.
Bước 6 — Viết Functional Requirements trong PRD đủ rõ để kiểm chứng. Mỗi yêu cầu nên có điều kiện, ngoại lệ, và quy tắc nghiệp vụ (business rules) đi kèm. Áp dụng MoSCoW để ưu tiên.
Bước 7 — Thêm Non-functional, Assumptions, Open Questions. Đừng giấu điều chưa biết. Một mục "Open Questions" trung thực giúp cả đội thấy rủi ro sớm.
Bước 8 — Review với stakeholder và lấy sign-off. Tài liệu chưa được duyệt thì chưa có giá trị ràng buộc. Tổ chức một buổi walkthrough, ghi nhận phản hồi, cập nhật và xin xác nhận.
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn tầng tài liệu. Nhồi chi tiết kỹ thuật (tên bảng, endpoint) vào BRD, hoặc viết BRD chung chung không số liệu rồi gọi đó là PRD. Mẹo: trước mỗi câu, tự hỏi "câu này dành cho sponsor hay cho dev đọc?".
Lỗi 2 — Bỏ qua Out-of-scope. BA chỉ ghi cái sẽ làm. Hậu quả là mỗi khi ai đó "tiện thể thêm tính năng", không có gì để từ chối. Mẹo: luôn dành một mục riêng cho out-of-scope, viết nó cẩn thận như viết phần in-scope.
Lỗi 3 — Mục tiêu không đo được. "Nâng cao hiệu quả" là khẩu hiệu, không phải mục tiêu. Mẹo: mọi objective phải kèm con số hiện tại (baseline) và con số mục tiêu.
Lỗi 4 — Functional requirement quá mơ hồ. "Hệ thống xử lý thanh toán" — xử lý cái gì, lỗi thì sao, refund ra sao? Mẹo: dùng "kiểm thử tưởng tượng" — nếu bạn không nghĩ ra cách QA test yêu cầu này, nghĩa là nó chưa đủ rõ.
Lỗi 5 — Coi tài liệu là sản phẩm cuối, viết xong cất tủ. BRD/PRD là tài liệu sống. Mẹo: dùng công cụ cộng tác (Confluence) để cập nhật liên tục thay vì file Word gửi email rồi mỗi người giữ một bản khác nhau.
Mẹo vàng: Trước khi viết, hỏi sponsor một câu duy nhất — "Nếu dự án này thành công, 6 tháng sau bạn sẽ chỉ vào con số nào để khoe với sếp của bạn?" Câu trả lời chính là Success Metrics và là xương sống của cả BRD lẫn PRD.
Bài tập thực hành
Bối cảnh: Một chuỗi cà phê 40 cửa hàng tại Việt Nam muốn xây app tích điểm và đặt món trước cho khách. Hiện khách phải xếp hàng trung bình 8 phút vào giờ cao điểm, và chương trình tích điểm bằng thẻ giấy có tỷ lệ khách quay lại chỉ 25%.
- Viết Executive Summary cho BRD (4–6 câu): nêu vấn đề kinh doanh, mức cấp thiết, kết quả kỳ vọng.
- Liệt kê 3 Business Objectives có số đo (kèm baseline và target).
- Viết phần Scope: ít nhất 3 mục in-scope và 3 mục out-of-scope.
- Chuyển 1 business requirement thành 2–3 product features trong PRD.
- Chọn 1 feature và viết Functional Requirements rõ ràng kèm ít nhất 2 business rule và 1 trường hợp ngoại lệ.
- Tự kiểm: đưa phần functional requirement của bạn cho một người không biết đề bài đọc — họ có hiểu đúng để làm không?
Tóm tắt
BRD và PRD là hai tầng tài liệu nền tảng mà BA dùng để dẫn dắt giai đoạn đầu dự án. BRD trả lời "tại sao và cái gì ở tầm doanh nghiệp", viết bằng ngôn ngữ kinh doanh, hướng tới sponsor và lãnh đạo, với Executive Summary và Success Metrics là trái tim. PRD trả lời "sản phẩm cụ thể làm gì", hướng tới đội xây dựng, với functional requirements đủ rõ để dev làm đúng và QA test được.
Ba điều cần khắc cốt: (1) đừng trộn tầng — mỗi câu phục vụ một đối tượng đọc; (2) mục tiêu phải đo được, scope phải có phần out-of-scope; (3) mức độ trang trọng của tài liệu tùy bối cảnh tổ chức — startup có thể gộp, doanh nghiệp lớn cần tách. Viết tốt hai tài liệu này, bạn không còn là người ghi chép yêu cầu mà trở thành người định hình dự án ngay từ gốc.