Table of Content
Thu thập yêu cầu nghiệp vụ là công việc "đi đầu" trong quy trình quản lý yêu cầu của BA. Trong bài này, mình sẽ cùng mọi người tìm hiểu về các bước cơ bản cho việc thu thập yêu cầu nói chung.
Requirement Elicitation là gì?
Trước khi đi vào nội dung chính thì mình muốn nói 1 chút về khái niệm "Thu thập requirement". Thường thì mọi người vẫn nghĩ rằng việc thu thập requirement sử dụng term "Gather Requirements" hay "Requirements Gathering" và phần lớn mọi người sẽ quen thuộc với 2 terms ở trên hơn. Nhưng thật ra với BA, "gather" hay thu thập không thì chưa đủ, nó phải là khơi gợi, phải là tìm tòi. BA sử dụng các kỹ năng của mình để tìm ra được vấn đề, tìm ra được mong muốn của stakeholder và requirements thực sự đằng sau những gì khách hàng cung cấp. Như vậy, "Requirement Elicitation" mới chính xác là khái niệm chỉ ra việc "thu thập requirement" của BA, trong đấy bao gồm cả việc "gather requirement".
Xác định được mình cần phải hỏi về cái gì
Ở bước này, việc đặt câu hỏi là một kỹ năng quan trọng với BA. Đặt câu hỏi đúng cách giúp bạn lấy thông tin được chính xác hơn, tiết kiệm cả công sức của người hỏi (bạn) và người trả lời (stakeholders).
Có nhiều bạn khi nhận dự án thì thấy mình có quá nhiều thứ không biết. Hoặc dự án có nhiều thứ để bạn hỏi đến nỗi… không biết phải bắt đầu từ đâu. Lúc này, các bạn BA nên phân loại các vấn đề thành từng module hoặc category và chọn ra 1 cái để làm trước theo thứ tự ưu tiên. (vd: module quản lý nhân sự, module thanh toán…)
Tìm đúng người để hỏi
Bạn phải biết được chính xác người mình cần hỏi cho đúng vấn đề mà bạn đã bóc tách ở trên, trừ khi bạn chỉ có 1 contact point duy nhất. Ví dụ, hỏi về thanh toán thì hãy tìm đến team finance hoặc kế toán mà hỏi, đừng hỏi CS.
Chuẩn bị câu hỏi
Có mục tiêu rồi, có người hỏi rồi, vậy bước tiếp theo thì bạn nên chuẩn bị sẵn một bộ câu hỏi xoay quanh vấn đề bạn định hỏi, xem là cái này từ đâu ra (làm sao để tạo được nó)? Nó xử lý vấn đề gì? Tạo ra rồi thì làm gì với nó?
Bạn chuẩn bị càng kỹ lưỡng thì việc "hết cái để hỏi" trong quá trình đi lấy requirements từ phía khách hàng sẽ càng khó xảy ra.
Làm nhiều thì quen tay, kinh nghiệm được sinh ra từ các lần đi hỏi sẽ giúp bạn khởi đầu cho 1 module khác 1 dự án khác tốt hơn. Nên tránh mắc lại các lỗi đã gặp nữa nhé.
---------------------------------------------------------------------------------
Post liên quan cùng series:
- "Đi họp"
Comments