Đối với BA, công việc quan trọng nhất chính là lấy được nhiều requirement nhất của user, càng nhiều, càng thầm kín càng tốt. Và một trong những thuật ngữ đẹp đẽ được dùng cho công việc này đó là Requirement Elicitation. Hay Việt hóa là: khơi gợi, đào bới, moi móc nhu cầu từ user.
Nói tóm lại, đó là quá trình để ông BA đi cạ nhau với user, với người nắm giữ và phát sinh mọi nhu cầu cho dự án, từ đó moi được từ miệng user những thông tin giá trị, cái họ cần, cái họ kỳ vọng, làm cơ sở hình thành nên Scope của dự án (phạm vi) và tạo ra requirement chi tiết cho team phát triển làm.
Thường thì quá trình này hay được gán với những buổi workshop dài đằng đẵng, mời đủ kiểu stake holder, từ giám đốc đến nhân viên vệ sinh, làm thành 1 đại hội, 1 festival lấy requirement kéo dài từ sáng sớm đến chiều tối. Nhưng thực ra trong đa số trường hợp quá trình này bao gồm nhiều những session nhỏ kết hợp với nhau, mỗi lần chỉ có sự tham gia của 1 vài stakeholder nhất định. Đòi hỏi BA phải vận dụng linh hoạt tùy tình huống.
Dưới đây tôi sẽ chia sẻ 5 kỹ thuật moi móc requirement từ stakeholder để bạn có thể áp dụng tùy hoàn cảnh.
Top 5 kỹ thuật moi móc requirement
1. Quan sát
Kỹ thuật đầu tiên đó là soi mói bằng mắt thường. Hãy ngồi bên cạnh user nếu bạn được tiếp cận với họ, hoặc cũng có thể qua 1 phần mềm share màn hình online nào đó.
Ngồi ngay ngắn và xem user làm việc thực tế. Bạn có thể yêu cầu họ vừa làm, vừa giải thích các bước mà họ đang thực hiện. Ví dụ như: Tôi phải làm gì để tạo 1 sản phẩm mới, hoặc các bước nào tôi cần làm để hủy 1 đơn hàng.
Nhìn 1 cách trực tiếp vào quy trình làm việc hiện tại của user và đặt những câu hỏi tại sao. Đừng sợ rằng bạn sẽ hỏi “Ngu”. Hãy luôn hỏi lý do tại sao họ bấm vào nút đó, họ nghĩ gì trong đầu khi làm thế. Cố gắng thấu hiểu được logic công việc và làm rõ các logic đó bằng câu hỏi.
Câu hỏi ngu duy nhất là câu hỏi mà bạn không hỏi.
Hãy đặt ra 1 vài tình huống giả định khác ngoài “happy case” mà user đang trình diễn. Nếu tôi không bấm vào nút này mà bấm vào bên ngoài thì sao, nếu tài liệu nặng hơn mức cho phép thì sẽ thế nào.
2. Sử dụng sơ đồ, nguyên mẫu
Phương pháp thứ hai tôi muốn chia sẻ với bạn là Sử dụng nguyên mẫu để xác định với user những thứ họ cần.
Đây là một cách tuyệt vời để nói chuyện với user và làm rõ requirement nhanh chóng. Hãy mô tả lại cách bạn hiểu business logic của họ thông qua
- Sơ đồ workflow: khi cần mô tả lại 1 quy trình phức tạp gồm 1 hoặc nhiều đối tượng tham gia
- 1 bản wireframe: khi cần mô tả luồng thao tác và các component hiển thị trên 1 màn hình thiết bị.
- 1 sơ đồ mối quan hệ thực thể (ERD): khi cần mô tả mối quan hệ giữa các đối tượng tồn tại trong hệ thống và 1 vài thuộc tính cơ bản của chúng
Từ những mô hình này, bạn có thể trực quan hóa toàn bộ business hoặc 1 số khía cạnh cần làm rõ. Tiếp theo là cho phép user feedback lại dựa trên cái bạn đã vẽ. Cách này có thể giúp bạn khám phá ra những thông tin bất ngờ, những kỳ vọng lạ lẫm mà trước nay bạn không nghĩ tới.
Bạn có thể làm một bản nháp đơn giản của những mô hình trên, tùy theo nhu cầu mô tả và mức độ thành thạo của user.
3. Phỏng vấn theo bộ câu hỏi chuẩn bị trước
Kỹ thuật thứ 3 là phỏng vấn theo check list. Liệt kê danh sách những câu hỏi mà bạn cần làm rõ. Gửi trước danh sách này cho stakeholder để họ có thời gian xem xét và chuẩn bị.
Để thực hiện phỏng vấn, bạn sẽ cần meeting với stakeholder, và cuộc họp sẽ sử dụng danh sách câu hỏi này như agenda. Các stakeholder chịu trách nhiệm sẽ trả lời câu hỏi của bạn theo thứ tự.
Việc tạo ra 1 danh sách câu hỏi và cho stakeholder có thời gian để chuẩn bị sẽ giúp bạn có được những câu trả lời rõ ràng hơn nhiều so với hỏi một cách ngẫu nhiên.
Tất nhiên, hãy giới hạn thời gian buổi họp, đặt câu hỏi có trọng tâm để tránh người trả lời lan man sang các khía cạnh khác.
4. Đọc tài liệu
Khi bạn tham gia vào một dự án thuộc 1 domain lạ lẫm, bạn cần dành thời gian để hỏi xin và đọc các tài liệu liên quan để có 1 nền tảng cơ bản. Các tổ chức, công ty, dự án thường có những tài liệu đã tồn tại trước
Cách này không đòi hỏi phải tương tác với stakeholder, chỉ cần đọc và đọc. Rồi từ những thứ đọc được, bạn tạo ra các sơ đồ, nguyên mẫu, tạo check list câu hỏi, giúp cho việc quan sát trở nên cụ thể và rõ ràng hơn.
Cách này có thể tiết kiệm rất nhiều thời gian của bạn và của stakeholder khỏi những cuộc họp lê thê. Nếu stakeholder của bạn là cực kỳ bận rộn, khó để tiếp cận thì hãy ưu tiên phương pháp này để có sự chuẩn bị tốt nhất trước khi book 1 buổi họp quý giá.
Nhưng lưu ý nhé, việc đọc tài liệu luôn là phương pháp tham khảo để tiếp tục thực hiện các phương pháp khác. Bạn sẽ không muốn dính vô cảnh đọc trúng 1 tài liệu đã out date từ đời nào, quy trình quy chuẩn đã khác xa với thực tế vận hành thì lúc đó xem như xu cà na.
Luôn nhớ verify lại với user về những gì bạn đọc được và cách mà bạn hiểu về tài liệu đó. Đừng vội đưa ra kết luận hay đúc kết một giả định sai lầm.
5 Khảo sát và dùng bảng câu hỏi
Bây giờ là kỹ thuật cuối cùng trong những kỹ thuật Elicite Requirement. Đây là cách thức tuyệt vời đề tương tác, lấy thông tin từ những stakeholder bạn không có cơ hội tiếp xúc trực tiếp nhiều.
Tạo ra 1 bảng khảo sát là cách để thu thập được thông tin một cách khách quan hơn. Trong đa số trường hợp, người ta sẵn sàng chia sẻ nhiều câu hỏi mang tính cá nhân hơn khi viết vào 1 bảng khảo sát thay vì trả lời trực tiếp. Nhưng ngược lại, phương pháp này cũng có nhược điểm là thông tin ghi nhận được thỉnh thoảng sẽ không rõ ràng, có để diễn giải khi không có ngữ cảnh cụ thể.
Hãy kết hợp các kỹ thuật
Hãy chọn cho mình kỹ thuật phù hợp nhất tùy theo tình huống và dự án cụ thể một cách thông minh. Mỗi kỹ thuật đều có điểm mạnh và điểm yếu, 1 BA giỏi sẽ biết lựa cơm gắp mắm, chọn đúng tool cho đúng mục đích. Đó là sơ lược những kỹ thuật lấy yêu cầu mà tôi biết. Chia sẻ thêm nếu bạn có thêm kỹ thuật nào khác nhé.
