Kỹ năng làm rõ yêu cầu (Requirement Elicitation) dành cho IT Business Analyst (Phần 3)

Trong hai bài viết trước chúng ta đã đi sâu vào việc hệ thống hóa một quy trình hoàn chỉnh để có thể thực hiện bước khai thác thông tin (Requirement Elicitation) khách hàng hiệu quả. Trong bài viết cuối của chuỗi bài viết lần này, chúng ta sẽ đi sâu vào những kỹ năng cơ bản để khai thác thông tin phục vụ cho dự án của một IT Business Analyst.

Các kỹ thuật làm rõ yêu cầu dành cho IT Business Analyst

Có rất nhiều cách để có được thông tin trong quá trình tìm hiểu và tìm ra nhu cầu chính xác từ phía khách hàng. Dưới đây là một số kỹ thuật thu thập thông tin và khơi gợi nhu cầu phổ biến dành cho các IT Business Analyst:

• Interview (Phỏng vấn): Đây là phương thức lấy thông tin trực tiếp thông qua việc giao tiếp với các bên liên quan. Có hai phương thức phỏng vấn chính, đây là face-to-face (trao đổi trực tiếp) hoặc Customer site visit (đi gặp trực tiếp khách hàng). Mặc dù đây là một phương pháp dễ thực hiện, tuy nhiên BA cũng cần lưu ý rằng đôi khi lời nói có thể chỉ dựa vào cảm tính và không thực sự chính xác. Do đó, BA cần có sự chuẩn bị trước khi gặp khách hàng cũng như có kỹ năng đào sâu vào trọng tâm thay vì chỉ hỏi những câu hỏi mang tính mơ hồ và hời hợt.
• Workshop (Nhóm thảo luận): Đây là là hình thức tổ chức buổi làm việc nhóm với nhiều bên liên quan để cùng nhau làm rõ yêu cầu, giải quyết mâu thuẫn và thống nhất phạm vi. BA đóng vai trò điều phối, đảm bảo cuộc họp diễn ra hiệu quả, đúng trọng tâm và mang lại kết quả cụ thể.
• Brainstorming (Tìm ý tưởng): Đây là lúc đội ngũ phát triển và thậm chí là khách hàng có thể ngồi cùng nhau để lên ý tưởng cho một vấn đề. Điều quan trọng trong quá trình lên ý tưởng là sự ghi nhận ý tưởng của mọi người trong nhóm, có được góc nhìn đa chiều để cho ra một giải pháp phù hợp nhất với vấn đề đang gặp phải.
• Focus Group (Nhóm tập trung): Cũng giống như các phương phát tìm kiếm thông tin trước đó, tuy nhiên focus group lại tập trung vào một nhóm đối tượng hoặc một nhóm vấn đề. Đây là phương pháp được thực hiện khi BA cần nhiều thông tin cụ thể về một chủ đề hoặc một chức năng trong thời gian ngắn. Phương pháp này sẽ giúp cho BA có được một lượng lớn thông tin về một vấn đề hay một tính năng cụ thể trong thời gian ngắn.
• Document Review (Đọc tài liệu): Đây cũng là một phương pháp quan trọng giúp BA hiểu được bối cảnh hiện tại của hệ thống hoặc quy trình nghiệp vụ. Các tài liệu cần xem xét có thể bao gồm: BRD, SRS, tài liệu đặc tả hệ thống, quy trình nội bộ, văn bản pháp luật liên quan, cũng như các trao đổi qua email hoặc chat.Survey (Khảo sát): thường là làm product, điền form hoặc chữ, có câu hỏi đóng hoặc mở.
• Survey (Khảo sát): Đây là phương pháp được sử dụng khi cần lấy ý kiến của nhiều người trong thời gian ngắn, thường được áp dụng trong giai đoạn phát triển sản phẩm. Câu hỏi trong khảo sát có thể dạng đóng (trắc nghiệm) hoặc dạng mở (viết tự do), tùy vào mục tiêu thu thập dữ liệu.
• Observation (Quan sát): là phương pháp theo dõi trực tiếp cách người dùng tương tác với hệ thống hoặc thực hiện công việc. BA có thể áp dụng các dạng quan sát như: naturalistic (tự nhiên), participant (tham gia cùng người dùng), hoặc structured (theo kịch bản sẵn). Việc quan sát giúp thu thập được các hành vi và nhu cầu thực tế mà người dùng có thể không diễn đạt được qua lời nói. (Lưu ý người ta thường có xu hướng giả tạo và làm khác đi khi biết mình được quan sát.
• Interface Analysis (Phân tích giao diện): là quá trình xem xét các phản hồi của người dùng, dữ liệu từ thử nghiệm sử dụng (user testing), hoặc cuộc họp đánh giá với đội phát triển để xác định những điểm chưa hợp lý trong giao diện và trải nghiệm người dùng. Phương pháp này thường giúp phát hiện các vấn đề thực tế trong quá trình sử dụng hệ thống, từ đó đề xuất giải pháp cải tiến hiệu quả hơn.
• Prototype (Bản dùng thử): Đây là lúc các BA cho người dung cuối trải nghiệm phiên bản dùng thử giới hạn với những tính năng cơ bản được yêu cầu. Trong quá trình sử dụng thử sản phẩm, các BA có thể dễ dàng nhận biết những yêu cầu về tính năng hay phi tính năng nào chưa được đáp ứng, đặc biệt khi phát triển những phần mềm đòi hỏi độ chính xác cao và nhiều tính năng. Phương pháp này rất phù hợp dành cho những stakeholders không hiểu rõ về những yêu cầu công nghệ dưới dạng viết và cần sử dụng thử phiên bản thật của sản phẩm.

Đọc thêm: Vòng đời phát triển sản phẩm (Software Life Cycle Development) và vai trò của IT Business Analyst

Các lưu ý khi thực hiện việc làm rõ yêu cầu từ khách hàng

Trong quá trình khơi gợi yêu cầu từ phía khách hàng, có một số những lưu ý giúp cho BA tiếp cận khách hàng hiệu quả và tránh những xung đột về giao tiếp:

Chuẩn bị trước khi gặp mặt khách hàng: Việc chuẩn bị trước các phần câu trả lời là một bước quan trọng giúp Business Analyst (BA) định hình hướng đi trong quá trình khơi gợi yêu cầu. Điều này không chỉ giúp quá trình giao tiếp trở nên hiệu quả hơn mà còn đảm bảo rằng mọi thông tin cần thiết đều được thu thập đầy đủ. Nếu như không có sự chuẩn bị, buổi gặp mặt khách hàng và stakeholders có thể trở nên lan man và không có kết quả.

Xác định rõ vai trò của khách hàng: Khách hàng và stakeholders thường chỉ xác nhận các thông tin hoặc yêu cầu mà họ biết, chứ không phân tích sâu vấn đề. Vì vậy, trách nhiệm phân tích và đưa ra các đầu ra phù hợp thuộc về BA. BA không nên dựa vào các mẫu có sẵn, mà cần tùy chỉnh cách tiếp cận dựa trên bối cảnh và nhu cầu thực tế cà cần hiểu rằng các bên liên quan không có nghĩa vụ dự đoán hoặc hiểu chính xác những gì BA cần. Vai trò của BA là làm rõ các yêu cầu thông qua việc đặt câu hỏi và yêu cầu hỗ trợ, chứ không ép buộc stakeholder thực hiện bất kỳ điều gì.

Chủ động làm rõ thông tin: BA cần lưu ý sẽ có những yêu cầu từ phía khách hàng rõ ràng, nhưng bên cạnh đó cũng sẽ có những yêu cầu hoặc chưa rõ ràng, hoặc chưa phù hợp và có thể làm ảnh hưởng tới cả hệ thống. Việc của BA là cần tìm hiểu kỹ về yêu cầu của khách hàng và phân tích để đưa ra những giải pháp phù hợp hơn hoặc rõ ràng hơn, thay vì chỉ tiếp nhận thông tin một cách thụ động.

Văn bản hóa thông tin: Khơi gợi yêu cầu là một hoạt động phân tích lặp đi lặp lại, đòi hỏi BA phải đặt câu hỏi ngay khi có điều gì chưa rõ ràng. Với những thông tin được truyền tải qua giao tiếp, BA cần văn bản hóa lại bằng email hoặc chat để giảm thiểu rủi ro và bảo vệ bản thân khỏi những xung đột tiềm ẩn trong tương lai. Điều này không chỉ tạo sự minh bạch mà còn là một bước quan trọng để xây dựng sự tin tưởng và hợp tác giữa BA và khách hàng.

Đọc thêm: BACCM – Mô hình cơ bản dành cho các Business Analyst

Kết

Tóm lại, việc làm rõ yêu cầu từ khách hàng không chỉ là một nhiệm vụ kỹ thuật mà còn là một nghệ thuật trong giao tiếp và phân tích. Business Analyst cần không ngừng rèn luyện kỹ năng, nâng cao sự nhạy bén và linh hoạt trong cách tiếp cận từng tình huống cụ thể. Sự hợp tác chặt chẽ, minh bạch và sự tin tưởng sẽ là nền tảng vững chắc để đảm bảo rằng sản phẩm cuối cùng không chỉ đáp ứng mà còn vượt qua mong đợi của các bên liên quan.