Mở đầu — vì sao bài này quan trọng
Là một developer, bạn đã viết và đọc vô số tài liệu kỹ thuật: API spec, README, sequence diagram, schema database, ticket Jira mô tả "fix bug ở hàm calculateDiscount()". Bạn nghĩ bằng ngôn ngữ của hệ thống — function, class, endpoint, table. Đó là một tài sản quý. Nhưng khi chuyển sang vai trò BA, bạn sẽ sớm phát hiện ra một nghịch lý: chính cái thế mạnh "viết tài liệu kỹ thuật giỏi" lại có thể trở thành cái bẫy lớn nhất khiến bạn thất bại trong những tháng đầu.
Vì sao? Vì khách hàng, business owner, hay anh trưởng phòng kế toán mà bạn phỏng vấn không quan tâm hàm nào được gọi. Họ quan tâm: "Tại sao cuối tháng tôi vẫn phải ngồi đối soát công nợ bằng tay đến 9 giờ tối?". Nhiệm vụ của BA không phải mô tả hệ thống làm gì, mà là làm rõ business cần gì và vì sao. Bài học này dạy bạn cách "dịch ngược": lấy tư duy viết technical docs sẵn có và chuyển hóa nó thành kỹ năng viết business requirements — thứ mà stakeholder phi kỹ thuật đọc được, đồng ý được, và ký duyệt được.
Đây không phải bài về cách viết User Story (Bài 4 và 19 lo phần đó), cũng không phải về phân loại requirements functional/non-functional (Bài 18). Bài này tập trung vào một việc rất cụ thể: chuyển dịch tư duy và văn bản từ technical document sang business requirement document, một kỹ năng bản lề mà dân dev-turned-BA thường bỏ qua.
Khái niệm cốt lõi
Technical Docs và Business Requirements khác nhau ở "điểm nhìn"
Hãy hình dung cùng một tính năng "đăng nhập bằng số điện thoại" được nhìn từ hai góc:
- Technical doc trả lời câu hỏi HOW: gọi API
POST /auth/otp, gửi OTP 6 chữ số qua SMS gateway, lưu token vào Redis với TTL 300 giây, validate bằng JWT. - Business requirement trả lời câu hỏi WHAT và WHY: người dùng cần đăng nhập nhanh mà không phải nhớ mật khẩu, vì 40% khách bỏ giỏ hàng ở bước tạo tài khoản. Yêu cầu: hệ thống cho phép xác thực bằng mã gửi về điện thoại, hết hạn sau 5 phút để đảm bảo an toàn.
Ba tầng trừu tượng bạn phải đi ngược
Dân dev quen đi từ trên xuống: requirement → design → code. Làm BA, bạn thường phải đi ngược lại hoặc đứng ở tầng cao nhất:
- Business need (nhu cầu kinh doanh) — vấn đề hoặc cơ hội. "Giảm thời gian xử lý đơn hàng".
- Business requirement (yêu cầu nghiệp vụ) — điều hệ thống/quy trình phải đáp ứng để giải quyết nhu cầu đó, diễn đạt bằng ngôn ngữ nghiệp vụ. "Hệ thống phải tự động phân bổ đơn cho kho gần khách nhất".
- Technical specification (đặc tả kỹ thuật) — cách hiện thực. "Thuật toán Haversine tính khoảng cách từ tọa độ kho đến địa chỉ giao".
"Dịch" technical detail thành business value
Kỹ năng cốt lõi của bài này là translation — phiên dịch. Mỗi chi tiết kỹ thuật đều có một "business why" đứng sau. Nhiệm vụ của bạn là lôi cái "why" đó ra ánh sáng:
| Technical detail | Business requirement tương ứng |
|---|---|
| "Cache kết quả 15 phút" | "Báo cáo doanh thu hiển thị trong 2 giây để quản lý xem nhanh trên điện thoại" |
"Index trên cột created_at" | "Nhân viên tra cứu lịch sử giao dịch 90 ngày không phải chờ quá 3 giây" |
| "Retry 3 lần khi gọi cổng thanh toán" | "Khách không bị tính tiền hai lần khi mạng chập chờn" |
Tình huống thực tế
Ví dụ 1: Tiki và "tài liệu không ai ký"
Hùng là backend developer 4 năm tại một công ty e-commerce ở TP.HCM (bối cảnh tương tự Tiki), được cất nhắc làm BA cho dự án "tối ưu quy trình hoàn hàng". Tuần đầu, Hùng nộp một tài liệu 12 trang đầy sequence diagram, mô tả các endpoint POST /returns, trạng thái state machine PENDING → APPROVED → REFUNDED, và cấu trúc bảng return_requests.
Trưởng phòng vận hành — người phải ký duyệt — đọc xong lắc đầu: "Anh không hiểu cái này. Tôi chỉ cần biết khi khách trả hàng vì sản phẩm lỗi, ai duyệt, mất bao lâu, và khi nào tiền về tài khoản khách." Tài liệu của Hùng đúng về mặt kỹ thuật nhưng vô dụng về mặt nghiệp vụ, vì nó không trả lời câu hỏi mà người duyệt quan tâm.
Hùng viết lại. Lần này anh mở đầu bằng bối cảnh nghiệp vụ: "Hiện 60% yêu cầu hoàn hàng bị xử lý chậm quá 48 giờ, gây 1.200 ticket khiếu nại/tháng." Rồi liệt kê yêu cầu bằng ngôn ngữ business: "BR-01: Khi lý do trả hàng là 'sản phẩm lỗi' và giá trị dưới 500.000đ, hệ thống tự động duyệt mà không cần quản lý xét tay." State machine vẫn còn đó, nhưng nằm ở phụ lục kỹ thuật, không phải phần chính.
Bài học: Cùng một lượng hiểu biết kỹ thuật, nhưng khi đóng gói bằng ngôn ngữ nghiệp vụ và đặt "vì sao" lên đầu, tài liệu từ "không ai ký" thành "duyệt trong một buổi họp".
Ví dụ 2: Fintech và cái bẫy "tôi biết hệ thống chạy thế nào"
Một startup fintech tại Hà Nội (gọi là MoMoLite cho dễ hình dung) thuê Linh — cựu fullstack dev — làm BA cho tính năng "chia hóa đơn nhóm". Vì Linh quá rành kỹ thuật, cô viết requirement như sau: "Hệ thống tạo một split_session, mỗi thành viên là một participant với amount_owed, đồng bộ real-time qua WebSocket."
Đội dev đọc xong code y hệt. Nhưng khi demo, business owner hỏi: "Nếu một người trong nhóm rời đi giữa chừng thì sao? Nếu tổng tiền lẻ không chia đều thì ai chịu phần dư? Người tạo nhóm có được hủy không?" — Không có câu trả lời nào trong tài liệu. Linh đã mô tả cấu trúc dữ liệu nhưng bỏ sót hàng loạt quy tắc nghiệp vụ (business rules) vì cô vội nghĩ bằng schema thay vì nghĩ bằng tình huống của người dùng.
Phải làm lại sprint, trễ 3 tuần. Lần này Linh dùng một mẹo đơn giản: với mỗi technical concept, cô tự hỏi "Nếu mình giải thích cái này cho mẹ mình — người bán tạp hóa — thì mình nói gì?". Câu trả lời buộc cô diễn đạt bằng tình huống thật, và chính lúc đó các business rule còn thiếu mới lộ ra.
Bài học: Sự thành thạo kỹ thuật khiến bạn nghĩ "mình đã hiểu hết rồi" và viết tắt phần nghiệp vụ. Nhưng business requirement đầy đủ phải bao trọn các tình huống ngoại lệ mà schema không tự nói ra.
Ví dụ 3: Reverse-engineer hệ thống legacy ở một ngân hàng
Tại một ngân hàng cỡ vừa ở Việt Nam, Đức — dev có kinh nghiệm đọc code — được giao "viết business requirement cho hệ thống tính lãi tiết kiệm hiện tại" vì tài liệu gốc đã thất lạc, chỉ còn code COBOL và stored procedure 15 năm tuổi. Đây là tình huống dev-turned-BA tỏa sáng: Đức đọc được code, nhưng anh không chỉ chép lại logic.
Anh đọc stored procedure, phát hiện công thức interest = principal rate days / 365, rồi truy ngược: "365 hay 360? Nếu năm nhuận thì sao? Có làm tròn không, làm tròn lên hay xuống?". Mỗi dòng code anh chuyển thành một business rule có thể kiểm chứng với phòng nghiệp vụ: "BR-12: Lãi suất tính theo số ngày thực gửi, mẫu số cố định 365 ngày kể cả năm nhuận; số tiền lãi làm tròn xuống đến đồng." Phòng kế toán xác nhận một quy tắc, và bất ngờ phát hiện một quy tắc sai tồn tại nhiều năm — code làm tròn lên, gây thiệt cho ngân hàng.
Bài học: Khả năng đọc technical detail của dev là vũ khí mạnh khi reverse-engineer, nhưng giá trị BA nằm ở chỗ chất vấn mỗi chi tiết bằng câu hỏi nghiệp vụ, không phải sao chép logic thành tài liệu.
Hướng dẫn từng bước
Đây là quy trình chuyển một technical doc (hoặc tư duy kỹ thuật trong đầu bạn) thành business requirement chuẩn:
- Xác định độc giả thật sự. Trước khi viết một chữ, hỏi: "Ai sẽ đọc và ai sẽ ký duyệt cái này?". Nếu đó là người phi kỹ thuật, mọi thuật ngữ như endpoint, cache, queue phải biến mất khỏi phần chính.
- Trích "business why" cho từng chi tiết kỹ thuật. Lấy technical doc gốc, đi qua từng dòng, tự hỏi "Cái này phục vụ mục đích kinh doanh gì?". Nếu một chi tiết không có "why" nghiệp vụ rõ ràng, có thể nó thuộc về technical spec, không phải business requirement — hãy đẩy nó xuống phụ lục.
- Viết lại theo cấu trúc nghiệp vụ. Mỗi yêu cầu nên có dạng: Bối cảnh/lý do → Hành vi mong muốn → Điều kiện và quy tắc → Tiêu chí thành công. Tránh động từ kỹ thuật ("gọi", "trả về JSON"); dùng động từ nghiệp vụ ("phê duyệt", "thông báo", "ghi nhận").
- Truy lùng các business rule ẩn. Với mỗi điều kiện trong code (if/else, validation, default value), hỏi "Quy tắc nghiệp vụ nào đứng sau?". Đây là nơi dev hay bỏ sót — biến điều kiện kỹ thuật thành quy tắc kinh doanh tường minh, có mã số (BR-01, BR-02...) để dễ truy vết.
- Diễn đạt phi giải pháp (solution-agnostic). Mô tả cần gì chứ không làm thế nào. Thay vì "dùng Redis cache", viết "kết quả tra cứu hiển thị dưới 2 giây". Điều này giữ cho đội dev quyền tự do thiết kế và giúp stakeholder tập trung vào giá trị.
- Tách bạch các lớp tài liệu. Phần đầu là business requirement cho người ra quyết định; phụ lục kỹ thuật (diagram, schema) dành cho đội dev. Đừng trộn lẫn — đó chính là lỗi của Hùng ở ví dụ 1.
- Kiểm chứng với người nghiệp vụ, không phải với đội dev. Đọc to từng yêu cầu cho stakeholder business. Nếu họ gật đầu hiểu ngay, bạn đã dịch thành công. Nếu họ hỏi lại "nghĩa là sao?", bạn còn dính ngôn ngữ kỹ thuật.
Lỗi thường gặp & mẹo
Lỗi 1 — Mô tả giải pháp thay vì yêu cầu. "Hệ thống dùng message queue Kafka" không phải business requirement, đó là quyết định kiến trúc. Mẹo: nếu xóa tên công nghệ đi mà câu vẫn còn nghĩa cho người kinh doanh thì giữ; nếu mất nghĩa thì đẩy xuống technical spec.
Lỗi 2 — Bỏ sót quy tắc ngoại lệ. Dev quen nghĩ "happy path" rồi để validation lo phần còn lại. BA phải hỏi đủ "what if": người dùng rời nhóm, mạng rớt, số âm, trùng dữ liệu. Mẹo: với mỗi yêu cầu, viết ít nhất hai tình huống ngoại lệ trước khi coi là xong.
Lỗi 3 — Viết quá dài, quá kỹ thuật. Tài liệu 12 trang đầy diagram khiến người duyệt bỏ cuộc. Mẹo: phần business requirement chính nên đọc được trong 10 phút; đẩy chi tiết kỹ thuật vào phụ lục.
Lỗi 4 — Dùng thuật ngữ kỹ thuật như mặc định. "Idempotent", "webhook", "soft delete" — bạn hiểu, nhưng kế toán trưởng thì không. Mẹo: lập một bảng thuật ngữ (glossary) và luôn diễn đạt bằng tình huống thật.
Lỗi 5 — Quên truy vết (traceability). Khi không đánh số yêu cầu, lúc thay đổi không ai biết cái gì liên kết cái gì. Mẹo: đánh mã BR-xx ngay từ đầu và liên kết mỗi requirement với business need mà nó phục vụ.
Mẹo vàng tận dụng nền dev: Khả năng đọc code và reverse-engineer là siêu năng lực của bạn. Khi tài liệu thất lạc, bạn có thể đọc hệ thống legacy và tái dựng requirement — điều mà BA thuần nghiệp vụ không làm được. Nhưng nhớ: luôn chất vấn logic bằng câu hỏi nghiệp vụ, đừng chỉ sao chép.
Bài tập thực hành
Bài 1 — Dịch ngược. Lấy một đoạn technical doc bạn từng viết (hoặc đoạn sau): "API GET /orders?status=pending trả về danh sách đơn, phân trang 20 bản ghi, cache 5 phút." Viết lại thành 2–3 business requirement có mã BR, với "business why" rõ ràng, không chứa thuật ngữ kỹ thuật ở phần chính.
Bài 2 — Truy lùng business rule. Cho đoạn pseudo-code:
if (order.total > 2000000 && customer.tier == "GOLD") {
discount = 0.15;
} else if (order.total > 2000000) {
discount = 0.10;
} else {
discount = 0;
}
Bài 3 — Reverse-engineer. Chọn một tính năng quen thuộc trong app bạn hay dùng (ví dụ "đặt lại mật khẩu" của Shopee). Đóng vai BA viết 5 business requirement mô tả tính năng đó mà không nhắc đến bất kỳ công nghệ nào. Sau đó tự kiểm tra: đưa cho một người phi kỹ thuật đọc, họ có hiểu hết không?
Tóm tắt
Chuyển từ technical docs sang business requirements là kỹ năng bản lề của hành trình dev-to-BA. Cốt lõi không phải vứt bỏ kiến thức kỹ thuật, mà đổi điểm nhìn: từ HOW (hệ thống làm thế nào) sang WHAT/WHY (nghiệp vụ cần gì và vì sao). Hãy luôn xác định độc giả thật sự, trích "business why" cho từng chi tiết kỹ thuật, viết theo ngôn ngữ nghiệp vụ phi giải pháp, truy lùng các business rule ẩn, tách bạch tài liệu nghiệp vụ với phụ lục kỹ thuật, và kiểm chứng với người business chứ không phải đội dev.
Ba câu chuyện — Hùng với "tài liệu không ai ký", Linh với cái bẫy "tôi biết hệ thống chạy thế nào", và Đức reverse-engineer hệ thống ngân hàng — đều chỉ ra cùng một sự thật: nền tảng kỹ thuật của bạn là vũ khí mạnh, nhưng chỉ khi bạn biết dịch nó thành ngôn ngữ và giá trị mà người ra quyết định kinh doanh hiểu được. Khi bạn làm chủ kỹ năng phiên dịch này, bạn không còn là dev viết tài liệu — bạn đã trở thành cây cầu thực thụ giữa business và công nghệ.