6 yêu cầu quan trọng nhất các Business Analyst cần nắm (Phần 2)

Tiếp tục với các yêu cầu quan trọng nhất trong các dự án của Business Analyst. Để không bỏ lỡ kiến thức, các bạn có thể bắt đầu từ phần đầu tiên của bài viết trước khi tiếp tục.

Tham khảo: 6 yêu cầu quan trọng nhất các Business Analyst cần nắm (Phần 1)

Business Analyst cần thực hành nhiều kỹ năng

1. Khám phá các yêu cầu phi chức năng

Mọi người thường tập trung vào chức năng của sản phẩm khi thảo luận về các yêu cầu nhưng đó chỉ là một phần của giải pháp. Các yêu cầu phi chức năng (non-functional) đóng góp nhiều vào sự hài lòng của người dùng và tính phù hợp để sử dụng.

Khi nói về các yêu cầu phi chức năng, mọi người thường nghĩ đến các thuộc tính chất lượng, đôi khi được gọi là “-ilities”. Các đặc tính của sản phẩm này bao gồm khả năng sử dụng, bảo trì, bảo mật, độ tin cậy và nhiều đặc điểm khác. Để giúp các nhà thiết kế đưa ra giải pháp phù hợp nhất, BA cần thảo luận về các yêu cầu phi chức năng như một phần của việc khơi gợi yêu cầu.

Các nhà phát triển không trực tiếp triển khai các yêu cầu liên quan đến an toàn, độ tin cậy, tính di động, bảo mật hoặc các đặc điểm khác. Thay vào đó, các thuộc tính này đóng vai trò là nguồn gốc của nhiều yêu cầu chức năng và thúc đẩy các quyết định thiết kế. Bảng dưới chỉ ra các loại thông tin kỹ thuật có thể xảy ra mà các loại thuộc tính chất lượng khác nhau sẽ tạo ra.

Một thách thức khác là không thể tối ưu hóa tất cả các yếu tố chất lượng mong muốn cùng một lúc. Các nhà thiết kế phải đưa ra quyết định cân bằng giữa các thuộc tính khác nhau. Do đó, nhóm cần xác định cái nào là quan trọng nhất đối với sự thành công của khách hàng và tối ưu hóa những cái đó. Chỉ định cẩn thận các thuộc tính chất lượng cho phép bạn tạo ra một sản phẩm làm hài lòng người dùng, không chỉ đơn thuần là làm những gì nó phải làm.

2. Xem lại các yêu cầu

Làm thế nào để bạn biết nếu yêu cầu của bạn là chính xác? Làm thế nào bạn có thể biết liệu họ có đủ rõ ràng để tất cả các thành viên trong nhóm biết phải làm gì với họ và các bên liên quan khác biết những gì mong đợi trong giải pháp? Cho dù bạn chọn cách thể hiện kiến thức yêu cầu như thế nào, đôi khi nó vẫn mơ hồ, không đầy đủ hoặc đơn giản là không chính xác.

Một trong những phương pháp thực hành chất lượng mạnh mẽ nhất hiện có là đánh giá ngang hàng các yêu cầu. Triệu tập một số đồng nghiệp để xem xét cả yêu cầu văn bản và sơ đồ. Những người tham gia dự án khác nhau, BA, nhà thiết kế, nhà phát triển, người kiểm tra, người dùng sẽ tìm thấy các loại vấn đề khác nhau trong quá trình đánh giá này.

Đánh giá yêu cầu đặt ra một số thách thức cụ thể. Thay vì chỉ mời mọi người xem qua các yêu cầu, hãy cung cấp một số khóa đào tạo để người đánh giá biết cách tham gia hiệu quả và có thể tìm thấy nhiều vấn đề nhất có thể.

Một thực hành xác nhận các yêu cầu liên quan là viết các bài kiểm tra khái niệm dựa trên các yêu cầu. Yêu cầu kiểm tra là điều bạn có thể làm sớm trong mỗi chu kỳ phát triển để phát hiện ra nhiều lỗi trước khi chúng được chuyển thành mã. Yêu cầu và bài kiểm tra là những quan điểm bổ sung cho cùng một kiến thức.

Các yêu cầu mô tả sản phẩm phải hoạt động như thế nào trong các điều kiện nhất định, các bài kiểm tra mô tả cách để biết liệu nó có biểu hiện các hành vi chính xác hay không.

3. Kế hoạch thay đổi yêu cầu

Cho dù bạn hiểu vấn đề đến đâu và bạn chuẩn bị các yêu cầu cẩn thận đến mức nào, chúng sẽ không hoàn hảo, đầy đủ hoặc tĩnh. Thế giới thay đổi xung quanh chúng ta khi chúng ta làm việc. Người dùng mới và ý tưởng mới xuất hiện.

Các quy tắc kinh doanh xuất hiện và phát triển. Các dự án chắc chắn sẽ phát triển vượt ra ngoài phạm vi hình dung ban đầu của chúng. Mọi nhóm phải lường trước những thay đổi về yêu cầu và thiết lập cơ chế để đối phó với chúng mà không làm lệch các cam kết của nhóm.

Khi bạn biết kết quả của dự án không được xác định đầy đủ và có khả năng thay đổi nhiều, một cách tiếp cận nhanh và gia tăng là một cách tốt để đối phó với nó. Bạn dự định xây dựng các yêu cầu và giải pháp theo một loạt các phần nhỏ, mong đợi hướng thay đổi và chấp nhận sự không chắc chắn về những gì bạn sẽ có ở cuối và khi nào bạn sẽ có.

Khi mức độ thay đổi có thể xảy ra ít nghiêm trọng hơn, hãy lập kế hoạch để thích ứng với một số tăng trưởng (cùng với rủi ro, ước tính không chính xác và các sự kiện bất ngờ) bằng cách xây dựng các vùng đệm dự phòng vào lịch trình phát triển.

Thiết lập quy trình thay đổi yêu cầu để những người phù hợp có thể nhận được thông tin phù hợp để đưa ra quyết định kinh doanh tốt về những thay đổi được đề xuất sẽ kết hợp để gia tăng giá trị với mức độ gián đoạn tối thiểu.

Tuy nhiên, đừng sử dụng kỳ vọng thay đổi để biện minh cho việc bỏ qua suy nghĩ về yêu cầu. Việc đáp ứng các yêu cầu quá mức thường chỉ ra rằng các mục tiêu không rõ ràng hoặc phương pháp khơi gợi không hiệu quả.

Mong rằng hai phần của bài viết đã mang đến cho bạn đọc những thông tin hữu ích. Các nội dung mới sẽ được cập nhật thường xuyên, đừng quên đón đọc tại BAC’s Blog.

Nguồn tham khảo: 
https://www.modernanalyst.com/

Nhu cầu đào tạo doanh nghiệp