Bài viết gốc được xuất bản tại ITPrep - Cẩm nang & Cheat Sheet Phỏng vấn IT.
Trong thế giới phát triển phần mềm, làm ra code chạy được là một chuyện, nhưng thuyết phục được các bên liên quan (stakeholder) "rót tiền" và không "quay xe" requirement giữa chừng lại là một câu chuyện hoàn toàn khác.
Anh em Dev thường ghét viết document, nhưng đã bao giờ bạn hì hục code xong 1 tính năng rồi sếp bảo: "Hình như cái này không mang lại doanh thu"? Đó là lúc chúng ta thấy được sức mạnh của Business Case và BRD (Business Requirements Document).
Dù bạn là BA, PO hay Developer, hiểu được 2 "bảo bối" này sẽ giúp bạn làm việc có định hướng hơn, giảm thiểu tranh cãi và đảm bảo mọi người cùng nhìn về một hướng. Cùng mổ xẻ chi tiết nhé!
1. Business Case: Trả lời câu hỏi "TẠI SAO phải làm dự án này?"
Business Case (Trường hợp kinh doanh) là tài liệu được sử dụng ở cấp độ chiến lược, nhằm chứng minh lý do tại sao một dự án/tính năng mới nên được thực hiện. Nó trình bày chi phí, rủi ro, và đặc biệt là ROI (Tỷ suất hoàn vốn).
Nói theo ngôn ngữ của Dev: Đây là tài liệu để "xin tài trợ server, xin thêm resource" từ ban giám đốc.
Các thành phần cốt lõi:
- Tóm tắt điều hành (Executive Summary): Vấn đề là gì, giải pháp nào, lợi ích ra sao?
- Phân tích vấn đề/cơ hội: Tại sao hệ thống cũ đang làm mất tiền của công ty?
- Các lựa chọn thay thế: Có nên đập đi xây lại không, hay chỉ maintain?
- Phân tích lợi ích/chi phí: Tiền mây, tiền server, tiền trả cho Dev vs. Doanh thu mang lại.
- Phân tích rủi ro & Kế hoạch sơ bộ.
Ví dụ về một mục tiêu Business Case:
"Đề xuất triển khai hệ thống CRM mới. Dự kiến sẽ cải thiện 25% hiệu quả quản lý khách hàng, giảm 15% chi phí vận hành bộ phận CSKH và tăng 10% tỷ lệ giữ chân khách hàng trong 18 tháng, đóng góp trực tiếp vào lợi nhuận ròng."
2. BRD (Business Requirements Document): Trả lời câu hỏi "LÀM CÁI GÌ?"
Sau khi sếp duyệt Business Case và cấp tiền, team BA sẽ bắt tay vào viết BRD. Đây là cầu nối giữa nhu cầu nghiệp vụ của sếp và ngôn ngữ kỹ thuật của anh em Dev.
BRD mô tả chi tiết hệ thống sẽ làm được gì để đạt được mục tiêu kinh doanh đã chốt ở trên.
Cấu trúc một BRD tiêu chuẩn:
- Mục tiêu kinh doanh & Phạm vi (Scope): Cái gì làm trong Phase 1, cái gì để Phase 2 (giúp Dev không bị scope creep - phình to yêu cầu).
- Yêu cầu nghiệp vụ (Business Requirements): Các rules từ phía khách hàng.
- Yêu cầu chức năng (Functional Requirements): App phải có màn hình Login, giỏ hàng, thanh toán,...
- Yêu cầu phi chức năng (Non-Functional Requirements - NFR): Đây là phần anh em Dev hay bị dính đòn nhất! Bao gồm: Hiệu suất (chịu được 10k CCU), Bảo mật, Khả năng mở rộng,...
- Ràng buộc (Constraints) & Use Cases.
3. Ma Trận Quyết Định: Business Case vs BRD
Để dễ hình dung, anh em xem bảng so sánh "thần thánh" này:
| Tiêu chí | Business Case | BRD |
|---|---|---|
| Mục đích chính | Chứng minh giá trị, xin phê duyệt đầu tư. | Đặc tả yêu cầu chi tiết để team Dev code. |
| Thời điểm dùng | Trước khi dự án khởi động. | Sau khi dự án được duyệt, trước khi code. |
| Đối tượng đọc | Ban Giám đốc, Nhà đầu tư (C-level). | Team Dev, QA, Scrum Master, PM. |
| Câu hỏi trả lời | Tại sao chúng ta nên làm cái này? | Cái gì cần làm? Làm như thế nào? |
| Độ chi tiết | Tổng quan chiến lược, tiền bạc. | Cực kỳ chi tiết (luồng user, hiệu suất, chức năng). |
Tình huống thực tế: Công ty muốn tích hợp AI vào tổng đài.
👉 Team Business viết Business Case chứng minh AI giúp giảm 30% chi phí thuê nhân sự.
👉 Sếp duyệt xong, BA viết BRD mô tả AI cần nhận diện giọng nói ra sao, gọi API nào, lưu data ở đâu để team Dev bắt tay vào build.
4. Những Sai Lầm "Đi Vào Lòng Đất" Cần Tránh
Sai lầm với Business Case:
- "Ngáo" lợi ích, giấu rủi ro: Chỉ vẽ ra viễn cảnh màu hồng mà không tính đến chi phí bảo trì server hay technical debt.
- Thiếu data thực tế: Trình bày bằng "cảm giác" thay vì các con số định lượng.
Sai lầm với BRD (Dev cực ghét):
- Yêu cầu mơ hồ: Viết kiểu "Hệ thống phải chạy nhanh" (Nhanh là bao nhiêu ms? Với bao nhiêu user?). 👉 Khắc phục: Áp dụng nguyên tắc SMART cho NFR.
- Tài liệu "chết": Viết BRD xong quăng đó, giữa chừng họp đổi requirement liên tục nhưng không cập nhật vào file. Lúc QA test log bug thì lôi nhau ra cãi.
- Thiếu tiếng nói của Dev: BA tự chốt requirement với khách hàng mà không hỏi ý kiến Technical Lead xem có khả thi về mặt công nghệ hay không.
5. FAQ - Giải Đáp Nhanh
Q1: Business Case và Project Charter có giống nhau không?
Không. Business Case chứng minh giá trị (ROI). Project Charter là "giấy khai sinh" chính thức của dự án, cấp quyền cho PM được phép dùng nhân lực và ngân sách.
Q2: Làm Agile/Scrum thì có cần viết BRD không?
Trong Agile, BRD nguyên khối thường được đập nhỏ ra thành Product Backlog, Epics và User Stories. Nhưng tinh thần của nó (xác định Business Rule và NFR) thì bắt buộc phải có để Dev biết đường code.
Q3: Ai là người chịu trách nhiệm chính cho 2 file này?
Thường là Business Analyst (BA) hoặc Product Manager (PM). Tuy nhiên, để file chuẩn xác, luôn cần sự tư vấn kỹ thuật từ Tech Lead và phản hồi từ Stakeholder.
Lời Kết
Viết Business Case và BRD "chuẩn không cần chỉnh" là một nghệ thuật. Một Business Case tốt mang lại tiền và dự án, một BRD tốt giúp anh em Dev ngủ ngon mỗi đêm mà không lo bị khách hành hạ vì những yêu cầu "trên trời rơi xuống".
Sự đồng thuận từ đầu luôn rẻ hơn rất nhiều so với chi phí phải đập đi code lại!
💡 Khám phá thêm: Nếu bạn đang theo đuổi con đường Business Analyst, Product Owner hoặc muốn tìm hiểu thêm về cách giao tiếp hiệu quả trong team IT, đừng quên ghé thăm ITPrep.com.vn để gom thêm các cẩm nang, cheat sheet và kinh nghiệm thực chiến nhé!
Top comments (0)