Table of Content
Chào mừng các bạn đến với phần tiếp theo của series về requirement elicitaion. Ở phần 1 và phần 2, mình có nói về một vài phương pháp tiếp cận để thu thập yêu cầu. Hôm nay, mình sẽ giới thiệu về bước tiếp theo, là công việc bạn sẽ cần làm ngay sau 2 bước trên: Đánh giá yêu cầu.
Tại sao phải đánh giá yêu cầu?
Lý do cho việc này là không phải bất cứ requirement nào stakeholders (là khách hàng hoặc các bên liên quan) đưa ra cũng có thể sử dụng được. Ý kiến của họ thường là chủ quan, dựa vào kinh nghệm cá nhân và có thể có hoặc không đem lại giá trị cho dự án của bạn. Đây là lúc bạn cần chắt lọc và tìm ra các thông tin thực sự có ích.
Đánh giá yêu cầu khi họp với Stakeholder
Tìm ra mục đích thực sự của tính năng được yêu cầu. Thu thập yêu cầu không chỉ là đặt câu hỏi và ghi chép lại thông tin nhận được. Bằng cách hỏi "Tính năng này để phục vụ cho mục đích gì", bạn có thể tìm ra mục tiêu sử dụng và xem xét tính năng mà khách hàng yêu cầu có phải là giải pháp tốt nhất chưa, đồng thời gợi ý những giải pháp tốt hơn (nếu có) để giải quyết vấn đề thực sự.
Ví dụ:
Khách hàng đưa ra yêu cầu cần luồng duyệt cho việc tạo account mới. Sau khi tìm hiểu, bạn biết được mục đích là để tránh tạo account rác trên hệ thống.
Với issue trên, bạn có thể gợi ý khách hàng việc sử dụng SMS OTP để verify lại tài khoản khi tạo mới, sẽ đơn giản hơn nhiều. Nếu khách tiếp tục lo ngại vấn đề về chi phí cho bên thứ 3 cung cấp dịch vụ SMS OTP, bạn có thể tiếp tục gợi ý giải pháp verify user qua email và phân tích cho họ hiểu dùng email sẽ không đủ chặt chẽ bằng điện thoại nhưng lại không tốn chi phí.
Đưa ra đánh giá ban đầu cho mỗi yêu cầu
Việc đánh giá sơ bộ yêu cầu thường không dành cho các bạn mới vào nghề và ít kinh nghiệm. Tuy nhiên, không phải là các bạn không thể làm được việc này. Có rất nhiều yêu cầu nghe đã thấy khá vô lý rồi. Và hiển nhiên, với những yêu cầu đó bạn hoàn toàn có thể đặt lại câu hỏi và đưa ra lời khuyên cho khách hàng.
Việc đánh giá yêu cầu thường xuất phát từ các câu hỏi như:
Yêu cầu liệu có khả năng thực hiện không?
Nếu có thì có mất nhiều thời gian không?
Nếu yêu cầu là cần thiết nhưng quá mất thời gian, effort để phát triển, liệu có cách thay thế nào không?
Ví dụ:
Khách hàng mong muốn áp dụng IoT vào việc tracking quãng đường di chuyển của tài xế và sử dụng AI để phân tích dữ liệu nhằm tối ưu hóa quãng đường và lộ trình di chuyển tùy theo hàng hóa, thời tiết…
-> Quá phức tạp và rối rắm, hãy khuyên khách hàng bóc tách yêu cầu trên thành các yêu cầu nhỏ hơn như:
Thực hiện tracking được xe sử dụng IoT.
Thu thập và lưu trữ tracking data, áp dụng AI...
Bạn nên đặt priority cho từng yêu cầu và tiến hành từng bước một.
Lọc thông tin
Nếu đã đọc phần 2 của mình thì hẳn bạn còn nhớ việc BA nên ghi lại Note cho cuộc họp (Minutes of meeting). Trong buổi họp, bạn thường sẽ không có thời gian đủ để phân loại xem chỗ nào ghi chỗ nào bỏ. Do vậy, Note của bạn sau cuộc họp thường sẽ là một mớ bòng bong. Đây cũng là lúc bạn nên lọc lại các thông tin đã ghi chép:
Thông tin có nằm trong nội dung buổi họp không?
Nếu không, thông tin có thuộc scope của dự án không?
Thông tin có ảnh hưởng đến các thông tin đã được thu thập từ trước không?
Nếu có thì ảnh hưởng như nào? Nếu có sự xung đột về thông tin thì cần xác minh với ai?
Thông tin khách hàng đưa cho đã đủ rõ ràng hay chưa? Nếu chưa thì cần hỏi lại ai?
Sau khi trả lời được tất cả các câu hỏi trên thì có lẽ các bạn đã có thêm 1 danh sách các câu hỏi và thắc mắc để bắt đầu lại từ phần 1 của series rồi. Hãy cứ tiếp tục cho đến khi bạn có trong tay các thông tin đã được xác minh rõ ràng và nằm trong scope phát triển. Đây là lúc mình sẽ bắt đầu phần tiếp theo trong Vòng đời quản lý yêu cầu (Requirement management life cycle).
Post liên quan cùng series:
Comments