Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Business Analyst (BA) giàu kinh nghiệm rằng "kỹ năng nào quyết định bạn là một BA giỏi hay dở?", thì có lẽ tám người sẽ trả lời: khả năng thu thập yêu cầu — Requirements Gathering. Đây là công việc cốt lõi, là lý do doanh nghiệp cần đến một BA thay vì để lập trình viên tự đoán khách hàng muốn gì.
Với bạn — sinh viên mới ra trường đang muốn bước vào nghề BA — đây cũng chính là bài học "phá băng" quan trọng nhất. Nhiều bạn nghĩ requirements gathering là một kỹ năng cao siêu chỉ dành cho người có nhiều năm kinh nghiệm. Sự thật thì ngược lại: bạn đã âm thầm luyện kỹ năng này suốt bốn năm đại học mà không hề hay biết. Mỗi lần bạn phỏng vấn một người cho bài tiểu luận, mỗi lần bạn làm khảo sát cho đồ án tốt nghiệp, mỗi lần bạn ngồi cãi nhau với nhóm để làm rõ đề bài giảng viên giao — đó đều là những phiên bản sơ khai của requirements gathering.
Bài học này sẽ giúp bạn hiểu bản chất của việc thu thập yêu cầu, biến những kỹ năng bạn đã có thành ngôn ngữ chuyên nghiệp, và cầm tay chỉ việc để bạn thực hiện một phiên thu thập yêu cầu đầu tiên đúng bài bản. Đây là nền tảng để sau này bạn viết được User Story, tài liệu BRD/SRS (những nội dung sẽ học ở các bài sau). Nếu gốc rễ này không vững, mọi thứ phía sau sẽ chông chênh.
Khái niệm cốt lõi
Requirements Gathering là gì?
Requirements Gathering (còn gọi là Requirements Elicitation — khơi gợi yêu cầu) là quá trình tìm hiểu, khám phá và ghi nhận những gì các bên liên quan (stakeholders) thực sự cần ở một sản phẩm hoặc dự án. Từ khóa quan trọng ở đây là "thực sự cần" — vì điều khách hàng nói ra thường khác với điều họ thật sự muốn, và cả hai lại khác với điều họ thực sự cần.
Có một câu nói kinh điển trong nghề: "Khách hàng bảo họ muốn một con ngựa nhanh hơn, nhưng điều họ cần là một chiếc ô tô." Nhiệm vụ của BA không phải là chép lại lời khách hàng, mà là đào sâu để hiểu vấn đề gốc rễ đằng sau lời nói đó.
Ba tầng của một yêu cầu
Khi thu thập yêu cầu, bạn nên phân biệt ba tầng để không bị lạc:
- Business Requirement (Yêu cầu nghiệp vụ): Mục tiêu lớn của doanh nghiệp. Ví dụ: "Giảm 30% thời gian xử lý đơn hàng để tăng năng lực bán hàng."
- Stakeholder / User Requirement (Yêu cầu người dùng): Nhu cầu cụ thể của từng nhóm người dùng. Ví dụ: "Nhân viên kho cần thấy danh sách đơn hàng cần đóng gói ngay khi đăng nhập."
- Functional / Solution Requirement (Yêu cầu chức năng): Hệ thống phải làm gì cụ thể. Ví dụ: "Hệ thống hiển thị danh sách đơn hàng trạng thái 'Chờ đóng gói', sắp xếp theo thời gian đặt hàng tăng dần."
Functional và Non-functional
Yêu cầu còn được chia thành hai loại. Functional requirement trả lời câu hỏi "hệ thống làm gì?" — ví dụ: người dùng đăng nhập bằng số điện thoại. Non-functional requirement trả lời câu hỏi "hệ thống làm tốt đến mức nào?" — ví dụ: trang phải tải trong 2 giây, hệ thống chịu được 5.000 người dùng đồng thời. Ở bài này bạn chỉ cần nhận biết sự khác nhau; phần non-functional sẽ được đào sâu ở một bài chuyên biệt sau.
Lợi thế "ngầm" của sinh viên mới ra trường
Đây là điều tôi muốn bạn nhớ nhất. Bạn không đến với nghề này bằng con số không. Những kỹ năng bạn đã tích lũy chính là vốn liếng để thu thập yêu cầu:
- Kỹ năng nghiên cứu và tổng hợp tài liệu: làm khóa luận nghĩa là bạn biết cách đọc nhiều nguồn và rút ra ý chính — chính là kỹ năng document analysis.
- Kỹ năng đặt câu hỏi khảo sát: bạn từng thiết kế bảng hỏi cho môn phương pháp nghiên cứu — đó là nền tảng của kỹ thuật survey.
- Kỹ năng phỏng vấn: bạn từng phỏng vấn người quen cho bài tập — đó chính là interview, kỹ thuật elicitation quan trọng nhất.
- Sự tò mò và không sợ hỏi "ngu": đây là vũ khí bí mật. BA lâu năm đôi khi ngại hỏi vì sợ bị coi là không hiểu. Người mới thì được phép hỏi mọi thứ — hãy tận dụng đặc quyền đó.
Tình huống thực tế
Ví dụ 1 — Chép nguyên lời khách hàng: bài học của một fresher tại một fintech ở TP.HCM
Minh, một bạn mới tốt nghiệp ngành Hệ thống thông tin, vào làm BA thực tập tại một công ty fintech chuyên ví điện tử tại Quận 1, TP.HCM. Task đầu tiên của Minh là làm rõ yêu cầu cho tính năng "lịch sử giao dịch". Trưởng nhóm nghiệp vụ nói: "Anh muốn màn hình lịch sử hiển thị tất cả giao dịch của khách."
Minh ghi lại y nguyên và chuyển cho dev. Dev làm ra một danh sách hiển thị toàn bộ giao dịch từ lúc mở tài khoản. Khi demo, trưởng nhóm nghiệp vụ nhíu mày: "Sao khách có 3.000 giao dịch mà bắt họ cuộn hết vậy? Anh cần họ lọc được theo tháng, tìm theo số tiền, và tải sao kê PDF chứ." Toàn bộ phải làm lại, trễ hai tuần.
Bài học: Chữ "tất cả" trong lời khách hàng không phải là một yêu cầu — nó là một cái bẫy. Nếu Minh hỏi thêm chỉ một câu — "Khi khách vào màn hình này, họ thường đang cần tìm điều gì?" — cậu đã khám phá ra nhu cầu lọc, tìm kiếm và xuất sao kê ngay từ đầu. Đừng bao giờ dừng ở lời nói bề mặt; hãy hỏi về ngữ cảnh và mục đích sử dụng.
Ví dụ 2 — Bỏ sót stakeholder: dự án nội bộ của một chuỗi cà phê
Một chuỗi cà phê giả định, gọi là "Cà Phê Sớm", có 40 chi nhánh ở Hà Nội, muốn xây một app đặt hàng nội bộ để các cửa hàng đặt nguyên liệu từ kho trung tâm. BA phụ trách chỉ ngồi phỏng vấn phòng Vận hành ở trụ sở. Phòng Vận hành mô tả một quy trình rất gọn gàng, BA viết yêu cầu và team code xong sau hai tháng.
Khi triển khai thực tế, các quản lý cửa hàng phản ứng dữ dội: app bắt họ nhập đơn theo từng mã sản phẩm, trong khi thực tế họ quen đặt theo "combo nguyên liệu" mỗi sáng và thường phải sửa đơn lúc đông khách. Ngoài ra, phòng Kế toán cũng cần app xuất được số liệu để đối soát công nợ — nhưng chẳng ai hỏi họ. Dự án phải chỉnh sửa lớn suốt ba tháng sau đó.
Bài học: Requirements gathering không chỉ là hỏi đúng câu, mà còn là hỏi đúng người. Trước khi bắt đầu, hãy vẽ ra bản đồ tất cả các bên liên quan: người dùng trực tiếp (quản lý cửa hàng), người quản lý (phòng vận hành), và những người bị ảnh hưởng gián tiếp (kế toán). Bỏ sót một nhóm stakeholder thường tốn kém hơn cả việc hiểu sai một yêu cầu.
Ví dụ 3 — Sức mạnh của việc quan sát: một dự án cho phòng khám
Lan, một BA junior, được giao làm rõ yêu cầu cho phần mềm quản lý một phòng khám tư ở Đà Nẵng. Thay vì chỉ ngồi họp, Lan xin phép đến ngồi quan sát quầy lễ tân trong một buổi sáng đông bệnh nhân. Cô phát hiện điều mà không ai nói trong cuộc họp: lễ tân phải vừa nghe điện thoại đặt lịch, vừa thu tiền, vừa tra hồ sơ giấy — và cứ mỗi lần chuyển giữa ba việc, họ mất thông tin.
Nhờ quan sát này (kỹ thuật gọi là observation), Lan đề xuất phần mềm phải cho phép lưu nháp thông tin bệnh nhân đang nhập dở và quay lại sau — một yêu cầu không hề xuất hiện trong bất kỳ cuộc phỏng vấn nào.
Bài học: Con người thường không kể cho bạn nghe những gì họ làm theo thói quen, vì với họ đó là điều hiển nhiên. Quan sát trực tiếp giúp bạn thấy những "yêu cầu ẩn" mà phỏng vấn không bao giờ khai thác được.
Hướng dẫn từng bước
Dưới đây là quy trình sáu bước để thực hiện một phiên thu thập yêu cầu đầu tiên. Bạn có thể áp dụng ngay cho một mock project hay một dự án thật.
Bước 1 — Xác định bối cảnh và mục tiêu. Trước khi hỏi ai bất cứ điều gì, hãy tự trả lời: Dự án này giải quyết vấn đề kinh doanh gì? Ai là người quyết định thành công? Nếu bạn không biết, đây là câu hỏi đầu tiên bạn cần đặt cho quản lý dự án.
Bước 2 — Lập bản đồ stakeholder. Liệt kê mọi bên liên quan: ai dùng trực tiếp, ai quản lý, ai bị ảnh hưởng. Với mỗi nhóm, ghi chú họ quan tâm điều gì. Bước này giúp bạn không lặp lại lỗi ở Ví dụ 2.
Bước 3 — Chọn kỹ thuật phù hợp. Không phải lúc nào cũng dùng phỏng vấn. Các kỹ thuật phổ biến cho người mới: interview (phỏng vấn 1-1, sâu), survey (khảo sát nhiều người, nhanh), document analysis (đọc tài liệu, quy trình hiện có), observation (quan sát công việc thực tế), và workshop (họp nhóm để thống nhất). Với dự án nhỏ, phỏng vấn cộng đọc tài liệu thường là đủ để bắt đầu.
Bước 4 — Chuẩn bị câu hỏi mở. Đây là bước quyết định chất lượng. Ưu tiên câu hỏi mở (bắt đầu bằng "Anh/chị thường...", "Điều gì xảy ra khi...", "Vì sao...") thay vì câu hỏi đóng chỉ trả lời có/không. Hãy chuẩn bị theo kỹ thuật 5 Why — hỏi "tại sao" liên tiếp để đào đến gốc rễ vấn đề. Ví dụ: "Vì sao anh cần báo cáo này?" → "Để họp với sếp." → "Vì sao cuộc họp cần nó?" → cứ thế đến khi chạm nhu cầu thật.
Bước 5 — Thực hiện và ghi chép. Trong buổi phỏng vấn, hãy lắng nghe nhiều hơn nói (nguyên tắc 80/20: khách nói 80%, bạn nói 20%). Ghi lại nguyên văn những từ ngữ nghiệp vụ họ dùng. Khi nghe xong một ý quan trọng, hãy diễn đạt lại bằng lời của bạn: "Vậy để em hiểu đúng, ý anh là..." — kỹ thuật này gọi là paraphrasing, giúp xác nhận bạn không hiểu sai.
Bước 6 — Tổng hợp và xác nhận lại. Sau buổi thu thập, hãy viết lại yêu cầu thành danh sách rõ ràng và gửi cho stakeholder xác nhận. Đừng bao giờ cho rằng "mình nghe là đủ hiểu". Việc xác nhận bằng văn bản (confirmation) giúp tránh tình trạng mỗi người nhớ một kiểu.
Lỗi thường gặp & mẹo
Lỗi 1 — Đóng vai "thư ký" thay vì "thám tử". Người mới thường chỉ chép lại lời khách. Hãy nhớ: nhiệm vụ của bạn là điều tra, không phải ghi tốc ký. Luôn hỏi thêm "tại sao" và "để làm gì".
Lỗi 2 — Hỏi câu dẫn dắt (leading question). Ví dụ: "Anh muốn nút này màu xanh đúng không?" Câu này áp đặt câu trả lời. Thay vào đó hãy hỏi: "Anh hình dung màn hình này trông thế nào?"
Lỗi 3 — Sợ hỏi vì ngại lộ ra mình không hiểu. Đây là lỗi giết chết BA mới. Một câu hỏi ngây thơ đúng lúc còn giá trị hơn cả tuần đoán mò. Hãy mạnh dạn hỏi: "Anh giải thích giúp em thuật ngữ này với ạ?"
Lỗi 4 — Không phân biệt nhu cầu (need) và giải pháp (solution). Khi khách nói "tôi cần một nút xuất Excel", đó là giải pháp họ nghĩ ra. Nhu cầu thật có thể là "tôi cần chia sẻ số liệu với đối tác". Biết đâu một link chia sẻ còn tốt hơn file Excel.
Mẹo vàng: Sau mỗi buổi thu thập, hãy tự hỏi ba câu: (1) Mình đã hiểu vấn đề gốc chưa? (2) Còn stakeholder nào mình chưa hỏi không? (3) Có yêu cầu nào mâu thuẫn nhau không? Ba câu này giúp bạn lọc ra 80% lỗ hổng trước khi chúng thành vấn đề lớn.
Bài tập thực hành
Bài tập 1 — Đóng vai thám tử. Chọn một app bạn dùng hằng ngày (ví dụ Grab, Shopee, MoMo). Chọn một tính năng bất kỳ và viết ra ba tầng yêu cầu: Business Requirement, User Requirement, Functional Requirement. Mục tiêu là luyện tư duy phân tầng.
Bài tập 2 — Thiết kế bộ câu hỏi phỏng vấn. Giả sử bạn được giao làm rõ yêu cầu cho một app đặt lịch cắt tóc tại một tiệm ở địa phương bạn. Hãy viết 8 câu hỏi mở để phỏng vấn chủ tiệm, trong đó có ít nhất một chuỗi "5 Why". Nhờ một người bạn đóng vai chủ tiệm và thử phỏng vấn thật.
Bài tập 3 — Bản đồ stakeholder. Với app cắt tóc ở trên, hãy liệt kê tất cả stakeholder (chủ tiệm, thợ, khách hàng, thu ngân...) và ghi mỗi nhóm quan tâm điều gì. So sánh xem bạn có bỏ sót nhóm nào không.
Bài tập 4 — Xác nhận lại. Sau khi phỏng vấn ở Bài tập 2, hãy viết lại toàn bộ yêu cầu thu được thành một danh sách gạch đầu dòng rõ ràng và gửi cho "chủ tiệm" xác nhận. Ghi nhận xem có điểm nào bạn đã hiểu sai không.
Tóm tắt
Requirements Gathering là trái tim của nghề BA, và tin vui là bạn đã có sẵn nền tảng từ những năm đại học. Hãy khắc cốt ghi tâm vài điều: yêu cầu có ba tầng (nghiệp vụ, người dùng, chức năng) và bạn phải luôn hiểu tầng trên trước khi chạm tầng dưới; điều khách hàng nói ra không phải là điều họ thật sự cần, nên nhiệm vụ của bạn là đào sâu bằng câu hỏi mở và kỹ thuật 5 Why; và đừng bao giờ bỏ sót stakeholder hay bỏ qua sức mạnh của việc quan sát trực tiếp.
Quy trình sáu bước — xác định bối cảnh, lập bản đồ stakeholder, chọn kỹ thuật, chuẩn bị câu hỏi, thực hiện và ghi chép, rồi xác nhận lại — sẽ là kim chỉ nam cho mọi phiên thu thập yêu cầu đầu tiên của bạn. Hãy nhớ: một BA giỏi không phải người ghi chép nhanh nhất, mà là người đặt câu hỏi đúng nhất và tò mò lâu nhất. Khi bạn đã thu thập được yêu cầu sạch sẽ, bước tiếp theo là biến chúng thành tài liệu và User Story — và đó chính là hành trình ở những bài học kế tiếp.