Business Requirements Document(BRD)

Khách muốn cái gì, và vì sao họ cần cái đó. BRD trả lời đúng hai câu đó. Nó không nói màn hình có mấy nút, không nói API trả về mã lỗi nào. Người ký duyệt BRD thường là giám đốc khối nghiệp vụ hoặc ban dự án — những người bạn không thể bắt ngồi đọc 80 trang đặc tả trường dữ liệu.

BRD chốt "làm cái này để được gì" ở tầng nghiệp vụ, và là căn cứ để duyệt ngân sách với phạm vi trước khi ai đó viết dòng code đầu tiên.

Vì sao nó quan trọng

Vì đây là chỗ duy nhất phạm vi được viết ra bằng ngôn ngữ mà cả khách lẫn ban lãnh đạo cùng ký. Sau này khi khách đòi thêm tính năng, câu hỏi đầu tiên luôn là: cái đó có nằm trong BRD không. Nếu không, nó thành Change Request, có báo giá, có timeline. Một dự án không có BRD được ký là một dự án mà phạm vi thuộc về người nói to nhất trong cuộc họp.

Chỗ này mỗi công ty một kiểu. Product team trong nước nhiều nơi bỏ hẳn BRD, thay bằng một trang PRD trên Confluence cộng backlog. Bên outsourcing cho khách Nhật hay khách ngân hàng thì BRD vẫn là tài liệu bắt buộc, có bản in, có chữ ký tươi.

Trong BRD có gì

1. Bối cảnh và vấn đề kinh doanh — hiện tại đang đau ở đâu, đau bao nhiêu tiền.
2. Mục tiêu kèm chỉ số đo được — "giảm thời gian mở tài khoản từ 25 phút xuống dưới 7 phút", không phải "nâng cao trải nghiệm".
3. Phạm vi in / out — cột "out of scope" quan trọng ngang cột "in scope", và thường cứu bạn nhiều hơn.
4. Danh sách bên liên quan kèm vai trò duyệt.
5. Yêu cầu nghiệp vụ đánh mã BR-01, BR-02... để về sau còn truy vết.
6. Quy trình As-Is và To-Be, thường kèm sơ đồ.
7. Giả định, ràng buộc, phụ thuộc — ví dụ "phụ thuộc API định danh của bên thứ ba, dự kiến sẵn sàng tháng 3".
8. Trang ký duyệt.

So sánh BRD / FRD / SRS — nhìn từ phía người ký

Lưu ý cho bạn nào đang ôn phỏng vấn: theo IEEE 830 và cách IIBA dùng, SRS là tài liệu gộp cả functional lẫn non-functional. Thị trường VN thì rất nhiều nơi gọi luôn cái tài liệu FRD của họ là SRS, và ngược lại. Đi phỏng vấn cứ trả lời theo chuẩn, rồi thêm một câu "thực tế mỗi công ty gọi một kiểu" là an toàn.

Ví dụ thực tế

BRD dự án eKYC của một ngân hàng cỡ vừa dày 22 trang, nhưng phần quyết định số phận dự án gói trong ba dòng mục tiêu: giảm thời gian mở tài khoản trung bình từ 25 phút tại quầy xuống dưới 7 phút trên app; đưa tỷ lệ hồ sơ mở online lên 38% tổng số hồ sơ mới trong 12 tháng; cắt được 6 nhân sự nhập liệu ở back office.

Phần out of scope có đúng một dòng cứu cả dự án: "Không bao gồm mở tài khoản cho khách hàng doanh nghiệp và người nước ngoài trong giai đoạn 1." Tháng thứ tư, khối khách hàng doanh nghiệp nhảy vào đòi làm luôn cho pháp nhân. BA mở BRD ra, chỉ vào dòng đó. Kết quả là một CR riêng, thêm 6 tuần, có ngân sách riêng, thay vì đội dev âm thầm gánh thêm.

Mẹo khi đi làm

Đừng viết BRD một mình rồi gửi email xin duyệt. Làm ngược lại: viết nháp phần mục tiêu và phạm vi, đặt lịch một buổi 90 phút, chiếu lên màn hình rồi sửa trực tiếp trước mặt các bên. Người ta khó cãi cái mình vừa cùng gõ vào.

Và mỗi mục tiêu trong BRD phải có một con số. Chủ đầu tư không đưa nổi con số nào nghĩa là họ chưa thật sự biết mình muốn gì — điều bạn cần biết ngay tuần thứ hai, lúc còn kịp ngồi hỏi lại.