Mở đầu — vì sao bài này quan trọng
Nếu bạn đang là Developer và muốn chuyển sang Business Analyst (BA), thì Requirements Gathering — quá trình thu thập và làm rõ yêu cầu — chính là kỹ năng "lõi" mà bạn buộc phải thành thạo. Đây là việc một BA làm gần như mỗi ngày, và cũng là nơi tạo ra khác biệt lớn nhất giữa một BA giỏi và một người chỉ biết "ghi chép lại những gì khách hàng nói".
Tin tốt là: với nền tảng kỹ thuật, bạn có một lợi thế mà nhiều BA "tay ngang" không có. Bạn đã quen đọc spec, đã biết một yêu cầu mơ hồ sẽ phá nát sprint như thế nào, và bạn hiểu hệ thống vận hành ra sao ở tầng dưới. Nhưng cũng chính nền tảng đó tạo ra một cái bẫy: bạn quen tư duy bằng technical specs (đặc tả kỹ thuật) thay vì business requirements (yêu cầu nghiệp vụ).
Bài học này tập trung đúng vào quá trình chuyển hóa đó: làm sao đi từ thói quen mô tả "hệ thống làm gì về mặt kỹ thuật" sang việc nắm bắt "doanh nghiệp cần gì và tại sao". Đây không phải bài về cách viết User Story (sẽ học ở bài sau) hay quản lý stakeholder (cũng là bài riêng) — mà là về hành động thu thập yêu cầu: hỏi đúng câu, đào đúng tầng, và biến những gì nghe được thành thông tin có giá trị cho dự án.
Khái niệm cốt lõi
Technical specs khác Business requirements ở điểm nào?
Hãy phân biệt rõ hai khái niệm này, vì đây là gốc rễ của mọi thứ.
Technical spec trả lời câu hỏi "Hệ thống được xây dựng như thế nào?". Ví dụ: "API trả về JSON với field status là enum gồm PENDING, APPROVED, REJECTED; lưu vào bảng transactions với index trên cột user_id."
Business requirement trả lời câu hỏi "Doanh nghiệp cần đạt được điều gì, và tại sao?". Ví dụ: "Khi khách hàng nộp hồ sơ vay, nhân viên thẩm định cần thấy được trạng thái hồ sơ theo thời gian thực để rút ngắn thời gian phản hồi từ 3 ngày xuống còn 1 ngày, nhằm tăng tỷ lệ giải ngân."
Bạn thấy sự khác biệt chứ? Technical spec nói về giải pháp. Business requirement nói về vấn đề và mục tiêu. Developer được huấn luyện để nhảy ngay vào giải pháp — đó là công việc của họ. Nhưng một BA giỏi phải kìm phản xạ đó lại, để hiểu trọn vẹn bài toán trước khi bàn cách giải.
Ba tầng của một yêu cầu
Trong BABOK (Business Analysis Body of Knowledge — khung kiến thức chuẩn của ngành BA), yêu cầu được phân tầng. Ở mức độ thực hành, bạn nên ghi nhớ ba tầng sau:
- Business requirements (yêu cầu nghiệp vụ) — mục tiêu cấp cao của tổ chức. Ví dụ: "Giảm tỷ lệ khách hàng rời bỏ giỏ hàng xuống dưới 60%."
- Stakeholder requirements (yêu cầu của bên liên quan) — nhu cầu cụ thể của từng nhóm người dùng/phòng ban. Ví dụ: "Khách hàng muốn thanh toán mà không cần tạo tài khoản."
- Solution requirements (yêu cầu giải pháp) — chia thành Functional (chức năng) và Non-Functional (phi chức năng). Ví dụ: "Hệ thống phải hỗ trợ guest checkout" và "Trang thanh toán tải dưới 2 giây."
"5 Whys" và kỹ thuật đào sâu
Khi một stakeholder nói "Tôi muốn thêm nút export Excel", phản xạ của một developer là nghĩ ngay đến thư viện nào để generate file .xlsx. Phản xạ của một BA là hỏi "Tại sao?". Hỏi đủ năm lần kiểu 5 Whys, bạn thường phát hiện ra yêu cầu thật nằm ở chỗ khác hẳn — có khi họ chỉ cần một dashboard, hoặc một báo cáo tự động gửi email hàng tuần, chứ không cần file Excel nào cả.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT tại TP.HCM: "Làm cho nó nhanh hơn"
Tại một công ty thương mại điện tử quy mô vừa ở Quận 1 (giả định, khoảng 80 nhân sự), một cựu backend developer mới chuyển sang vai trò BA nhận yêu cầu từ trưởng phòng vận hành: "Trang quản lý đơn hàng chậm quá, làm cho nó nhanh hơn đi."
Phản xạ dev cũ trỗi dậy: anh lập tức nghĩ đến việc thêm index database, cache Redis, phân trang lazy-load. Anh suýt viết luôn một technical spec đề xuất tối ưu query.
May là anh kịp dừng lại và đi gặp ba nhân viên vận hành để quan sát họ làm việc thực tế (kỹ thuật observation). Hóa ra "chậm" ở đây không phải vấn đề performance của hệ thống. Nhân viên phải mở 4 tab khác nhau, copy-paste mã đơn hàng giữa các màn hình để đối soát tồn kho và tình trạng giao hàng. Mỗi đơn mất khoảng 5 phút thao tác thủ công. Hệ thống chạy đủ nhanh — quy trình mới là thứ chậm.
Bài học: Từ "làm cho nó nhanh hơn", yêu cầu nghiệp vụ thật là "giảm số thao tác và số màn hình cần mở để xử lý một đơn hàng". Giải pháp cuối không phải tối ưu database, mà là gộp thông tin tồn kho và vận chuyển vào một màn hình duy nhất. Nếu anh giải theo phản xạ dev, anh đã tốn hai tuần tối ưu một thứ không ai phàn nàn.
Ví dụ 2 — Fintech Singapore: yêu cầu ẩn sau con số
Một công ty fintech ở Singapore làm ví điện tử cho thị trường Đông Nam Á. Đội sản phẩm nhận yêu cầu từ phòng compliance: "Cần lưu lại lịch sử mọi giao dịch trong 7 năm."
BA — vốn xuất thân từ data engineer — nếu chỉ ghi lại đúng câu này thì sẽ tạo ra một solution requirement đơn giản về retention policy. Nhưng cô đặt câu hỏi đào sâu: Lưu để làm gì? Ai sẽ truy xuất? Tần suất ra sao? Cần truy xuất nhanh hay chỉ cần khôi phục khi có yêu cầu?
Câu trả lời lộ ra ba nhóm nhu cầu hoàn toàn khác nhau: (1) compliance cần dữ liệu phục vụ audit của ngân hàng nhà nước, truy xuất hiếm nhưng phải đầy đủ và bất biến; (2) đội chống gian lận cần truy vấn nhanh dữ liệu 90 ngày gần nhất; (3) bộ phận chăm sóc khách hàng cần tra cứu giao dịch theo số điện thoại trong vòng 1 năm.
Bài học: Một câu "lưu 7 năm" thực ra gói ba stakeholder requirement với ba yêu cầu phi chức năng khác nhau hẳn về tốc độ và chi phí lưu trữ. Nếu xây theo cách hiểu ban đầu — nhét tất cả vào một kho lưu trữ "nóng" — chi phí hạ tầng sẽ đội lên nhiều lần một cách vô nghĩa. Việc đào sâu giúp tách yêu cầu thành các giải pháp lưu trữ phân tầng hợp lý.
Ví dụ 3 — Startup edtech: khi dev đọc vị được "yêu cầu bất khả thi"
Tại một startup edtech ở Hà Nội (giả định, sản phẩm học tiếng Anh), founder yêu cầu: "Tôi muốn hệ thống tự động chấm điểm phát âm của học viên giống hệt như giáo viên người bản ngữ, và phải chạy offline trên điện thoại đời cũ."
Đây là lúc lợi thế kỹ thuật của một BA-xuất-thân-dev tỏa sáng. Cô hiểu ngay rằng "giống hệt giáo viên bản ngữ" + "offline" + "máy đời cũ" là một bộ ràng buộc gần như mâu thuẫn. Thay vì gật đầu rồi để đội kỹ thuật vỡ trận sau hai sprint, cô tổ chức một buổi làm rõ yêu cầu, dùng kỹ thuật prototyping với một bản mô phỏng đơn giản để founder thấy sự đánh đổi giữa độ chính xác và tài nguyên thiết bị.
Qua trao đổi, yêu cầu thật được làm rõ: founder không cần "giống hệt bản ngữ", anh cần học viên cảm thấy có phản hồi tức thì để duy trì động lực học. Một mô hình chấm điểm gần đúng, chạy được offline, kèm gợi ý cải thiện là đủ đáp ứng mục tiêu kinh doanh (tăng tỷ lệ học viên hoàn thành bài).
Bài học: Nền tảng kỹ thuật giúp bạn phát hiện sớm những yêu cầu bất khả thi hoặc mâu thuẫn, và dẫn dắt stakeholder về một phạm vi khả thi — mà không làm họ cảm thấy bị từ chối. Đây là siêu năng lực riêng của dev-turned-BA.
Hướng dẫn từng bước
Dưới đây là quy trình thu thập yêu cầu bạn có thể áp dụng ngay cho dự án đầu tiên:
Bước 1 — Xác định và phân nhóm stakeholder. Trước khi hỏi, hãy biết bạn cần hỏi ai. Liệt kê những người chịu tác động hoặc có thông tin: người dùng cuối, quản lý nghiệp vụ, đội kỹ thuật, bộ phận compliance... Mỗi nhóm nhìn vấn đề từ một góc khác nhau.
Bước 2 — Hiểu bối cảnh nghiệp vụ (business context) trước. Đừng vội hỏi về tính năng. Hãy hỏi về mục tiêu: "Vấn đề lớn nhất hiện tại là gì?", "Thành công của dự án này được đo bằng con số nào?". Bạn đang tìm tầng business requirement.
Bước 3 — Chọn kỹ thuật elicitation phù hợp. Một số kỹ thuật phổ biến: interview (phỏng vấn 1-1, sâu nhưng tốn thời gian), workshop (gom nhiều stakeholder, tốt để giải quyết bất đồng), observation (quan sát người dùng làm việc thật — cực kỳ giá trị, như ví dụ 1), document analysis (đọc tài liệu/quy trình hiện có), và prototyping (làm bản mẫu để gợi yêu cầu). Tùy tình huống mà chọn.
Bước 4 — Hỏi "Tại sao" trước khi hỏi "Cái gì". Khi nghe một yêu cầu, luôn truy ngược lại động cơ đằng sau bằng kỹ thuật 5 Whys. Đây là nơi bạn tách giải pháp ra khỏi vấn đề.
Bước 5 — Ghi nhận cả yêu cầu functional lẫn non-functional. Đừng chỉ ghi "hệ thống làm gì". Hãy hỏi luôn về tốc độ, bảo mật, khối lượng dữ liệu, số người dùng đồng thời — những thứ mà với background kỹ thuật bạn vốn nhạy cảm hơn người khác.
Bước 6 — Xác nhận lại (confirmation). Tóm tắt những gì bạn hiểu và đọc lại cho stakeholder nghe: "Vậy điều anh/chị thực sự cần là... đúng không?". Việc này lọc ra hiểu lầm trước khi nó kịp thành code.
Bước 7 — Diễn đạt lại bằng ngôn ngữ nghiệp vụ. Viết lại yêu cầu sao cho cả người không kỹ thuật lẫn đội dev đều hiểu giống nhau. Đây là cầu nối — và là lý do vai trò BA tồn tại.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào giải pháp (solution-jumping). Đây là lỗi kinh điển của dev-turned-BA. Vừa nghe yêu cầu đã nghĩ tới kiến trúc, database, framework. Mẹo: tự đặt cho mình một luật cứng — không bàn giải pháp cho đến khi đã hỏi "tại sao" ít nhất ba lần.
Lỗi 2 — Mặc định mình đã hiểu vì mình rành kỹ thuật. Hiểu hệ thống không có nghĩa là hiểu nghiệp vụ. Một dev giỏi vẫn có thể không biết quy trình thẩm định tín dụng của ngân hàng vận hành ra sao. Mẹo: coi mình như người mới hoàn toàn về domain, đặt cả những câu hỏi "ngớ ngẩn".
Lỗi 3 — Dùng thuật ngữ kỹ thuật với người nghiệp vụ. Hỏi trưởng phòng kế toán về "idempotency của API" thì bạn sẽ nhận lại ánh mắt trống rỗng. Mẹo: dịch mọi thứ sang ngôn ngữ nghiệp vụ; giữ thuật ngữ kỹ thuật cho buổi làm việc với đội dev.
Lỗi 4 — Chỉ phỏng vấn người quản lý, bỏ qua người dùng thật. Quản lý mô tả quy trình "lý thuyết", còn người dùng cuối mới biết quy trình thực tế (thường khác xa). Mẹo: luôn dành thời gian quan sát hoặc phỏng vấn người trực tiếp thao tác.
Lỗi 5 — Không ghi nhận non-functional requirements. Vì quá tập trung vào chức năng, nhiều BA mới quên hỏi về hiệu năng, bảo mật, khả năng mở rộng — đến lúc go-live mới vỡ. Mẹo: tận dụng lợi thế kỹ thuật của bạn, luôn có một checklist non-functional sẵn để rà.
Bài tập thực hành
- Tách giải pháp khỏi vấn đề. Lấy ba câu yêu cầu sau và viết lại mỗi câu thành dạng business requirement (nêu vấn đề + mục tiêu, không nêu giải pháp): (a) "Thêm nút export PDF", (b) "Chuyển sang dùng microservices", (c) "Làm app mobile". Với mỗi câu, viết ra ba câu hỏi "tại sao" bạn sẽ đặt cho stakeholder.
- Đóng vai phỏng vấn. Nhờ một người bạn đóng vai chủ một quán cà phê muốn "làm một phần mềm quản lý". Dành 20 phút phỏng vấn họ, áp dụng đúng Bước 2 đến Bước 6 ở trên. Sau buổi đó, viết ra: đâu là business requirement, đâu là stakeholder requirement, đâu là solution requirement.
- Rà non-functional. Lấy một tính năng bất kỳ (ví dụ: "đăng nhập bằng số điện thoại"), liệt kê ít nhất năm yêu cầu phi chức năng liên quan (tốc độ, bảo mật, số người dùng đồng thời, khả năng phục hồi, tuân thủ quy định) mà một BA cần làm rõ.
Tóm tắt
Requirements Gathering là kỹ năng cốt lõi đầu tiên bạn cần làm chủ khi chuyển từ Developer sang BA. Điểm mấu chốt của bài này: technical spec mô tả giải pháp, còn business requirement mô tả vấn đề và mục tiêu — và công việc của BA là đi từ cái thứ hai trước, rồi mới đến cái thứ nhất.
Background kỹ thuật của bạn là con dao hai lưỡi: nó giúp bạn phát hiện yêu cầu mâu thuẫn, nhạy bén với non-functional requirements, và nói chuyện được với đội dev — nhưng cũng đẩy bạn vào bẫy solution-jumping. Hãy rèn thói quen hỏi "tại sao" trước khi nghĩ "làm thế nào", phân tầng yêu cầu theo BABOK, chọn đúng kỹ thuật elicitation, và luôn xác nhận lại bằng ngôn ngữ nghiệp vụ. Làm tốt việc thu thập yêu cầu, bạn đã đặt nền móng vững cho mọi tài liệu và quyết định phía sau của dự án.