Trong thực tế, một dự án xem như là thất bại khi sản phẩm bàn giao không đáp ứng được yêu cầu của khách hàng. Vậy làm sao để “hiểu và làm đúng” yêu cầu đây? Và có bao giờ bạn nghe hay làm cái việc gọi là “Xác thực yêu cầu” chưa?
Thực chất mục tiêu của việc xác thực yêu cầu đó là các bên liên quan (stakeholders) đồng ý và phê duyệt các yêu cầu của họ sau khi các yêu cầu này được gợi mở, phân tích và tài liệu hoá. Qua đó người Phân tích nghiệp vụ (BA – Business Analyst) có thể “hiểu và làm đúng” các yêu cầu đặt ra.
Ở một số dự án theo mô hình Agile (hoặc các dự án có cách hoạt động tương tự) mặc dù việc xác thực yêu cầu không tham gia chính thức vào quy trình dự án, nhưng vẫn góp phần tăng thêm giá trị cho dự án. Bởi thông qua việc xác thực yêu cầu, thì người phân tích nghiệp vụ sẽ có được cái nhìn rõ ràng, chi tiết về yêu cầu, chính vì vậy mà sản phẩm bàn giao sẽ đáp ứng được mong đợi của khách hàng, sẽ không làm họ thất vọng. Và đây cũng là lý do tại sao mà một BA luôn tìm đến các bên liên quan để xác thực yêu cầu.
Dưới đây là một số “tuyệt chiêu” giúp bạn thực hiện việc này tốt hơn:
1. Đảm bảo rằng các bên liên quan hiểu được Tài liệu yêu cầu kỹ thuật (Requirements Specification Document – RSD).
Thật là may mắn nếu RSD được các bên liên quan xác thực. Nhưng bạn có chắc là họ hiểu nó? Câu trả lời là chưa chắc. Chắc chắn sẽ có một vài người vẫn xác thực tài liệu này mặc dù họ chưa hề đọc nó. Do đó, trước khi xác thực, bạn phải làm sao để các bên liên quan có thể hiểu và có được sự hợp tác từ họ.
Để làm cho việc xác thực yêu cầu dễ dàng hơn, các bên liên quan chỉ nên được yêu cầu xác thực vào những yêu cầu liên quan trực tiếp đến họ. Việc này sẽ tăng khả năng thành công, đồng thời cũng tác động tích cực lâu dài đến dự án.
Bí kíp: Nếu bạn có kế hoạch cho việc xác thực RSD, phải chắc chắn rằng các bên liên quan hiểu được nội dung của chúng. Bạn hãy thảo luận với họ về nội dung tài liệu, ghi chú lại vấn đề họ quan tâm, trả lời câu hỏi của họ, lấy ý kiến và làm cho họ cảm thấy mình có liên quan đến dự án. Điều này sẽ giúp tạo nên sự tin tưởng giữa bạn và các bên liên quan, và đảm bảo là bạn sẽ có được sự “xác thực trong hiểu biết” hơn là “xác thực trong thiếu hiểu biết” hoặc “xác thực miễn cưỡng”.
2. Không nên dành quá nhiều thời gian cho việc xác thực RSD.
Nhược điểm của việc xác thực yêu cầu là mất nhiều thời gian. Một chuyên viên phân tích nghiệp vụ thường dành phần lớn thời gian làm việc ở công ty để giải thích RSD cho các bên liên quan, để họ có thể hiểu trước khi nội dung được xác thực. Điều này tạo nên sự chậm trễ đáng kể cho dự án, và cái trường hợp nghiệt ngã nhất đó là các bên liên quan ở những vùng khó xác đinh (hay gọi vui là “vùng sâu vùng xa”) hoặc khác vùng địa lý. Vậy thì trong một núi việc, không lẽ người BA phải dành hết thời gian của mình chỉ để làm việc này?
Việc xác thực yêu cầu càng khó khăn hơn khi có những yêu cầu thay đổi. Vậy làm sao để một bên liên quan đồng ý và phê duyệt yêu cầu, mà yêu cầu đó không phải đến từ họ? Trong thực tế, bên liên quan được xem như là “người chủ quy trình” (Process owner), tức không có nghĩa là họ sẽ sẵn sàng chấp nhận thay đổi, thì nói chi đến việc xác thực yêu cầu.
Một số yêu cầu dự án có thể thay đổi vì một số lí do kỹ thuật, quy định hay những yêu cầu từ các phòng ban khác. Trừ khi lợi ích đó rõ ràng hoặc tác động của việc xác thực yêu cầu cực kì nhỏ (như không tồn tại), thì bạn đừng hy vọng là các bên liên quan sẽ cho bạn thời gian dễ dàng.
Bí kíp: Có được tất cả các bên liên quan tham gia ngay sau khi dự án bắt đầu. Nếu ngay từ ban đầu, bạn có được nhiều sự tham gia hơn, hợp tác nhiều hơn thì đó chính là thời điểm bạn nên thực hiện xác thực yêu cầu. Việc xác thực này cũng dễ dàng hơn khi những yêu cầu này đã được phát triển và được tài liệu hoá. Ngoài ra, các buổi đánh giá yêu cầu cũng nên được tổ chức để có thể nhận được sự đồng thuận chung và RSD được xác thực vào thời gian này.
3. Đừng “ngồi không” trong khi chờ yêu cầu được xác thực.
“Ngồi không” ở đây ám chỉ đến việc các nhà phát triển (Developer) sẽ không thể viết dù chỉ là một dòng code cho tới khi yêu cầu được xác thực. Trong một vài tổ chức, việc này vẫn xảy ra, một khi quá trình xác thực bị trì hoãn thì thì sẽ tạo ra thời gian nhàn rỗi cho các nhà phát triển (hoặc người phân tích nghiệp vụ) – những người được thuê để hoàn thành công việc. Trong một vài tình huống, các lập trình viên sẽ bắt đầu công việc trước khi các yêu cầu được xác thực. Điều này thật nguy hiểm. Tuy nhiên, nếu không làm như vậy, một khi dự án bị huỷ thì sẽ có lời biện minh cho việc này, đó là “Mặc dù RSD được xác nhận nhưng không đồng nghĩa là dự án sẽ không bị huỷ”.
“Tiến thoái lưỡng nan”, biết phải làm thế nào?
Bí kíp: “Kiên trì” giao tiếp với các bên liên quan để dễ dàng cho việc xác thực yêu cầu. Nếu cảm thấy việc xác thực chưa thể sẵn sàng, bạn nên bắt đầu tự hỏi là dự án này quan trọng như thế nào đối với các bên liên quan. Và nếu bạn lâm vào trường hợp gọi là “hết cách” (tất cả những cách để xác thực đều thất bại), thì hãy thông báo việc này đến cấp trên, có thể sử dụng những hành động mang tính chủ đích.
Khi việc xác thực thành công đúng như dự định, chắc chắn sẽ có được lợi ích. Quá trình xác thực được xem như là cơ hội để khám phá, cho phép các bên liên quan đặt câu hỏi và người phân tích nghiệp vụ có thể thấu hiểu được họ đang quan tâm những gì. Một lợi ích dễ dàng thấy được của việc xác thực yêu cầu đó là các bên liên quan sẽ nhận thức và nhận ra giải pháp luôn đi đôi với hành động.
(Nguồn tham khảo: BUSINESSANALYSTLEARNINGS)
CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.
Ban biên tập nội dung BAC.
Biên dịch: Ngô Nguyễn Thảo Phương – BAC