Ngày nay, các dự án CNTT có thể khác nhau về nguồn lực, khung thời gian, mục tiêu và phạm vi dự án. Nhưng tất cả đều có chung một rủi ro là nếu giải pháp đã phát triển không đáp ứng được nhu cầu kinh doanh của khách hàng, thì dự án này coi như thất bại. Đây là lúc Business Analyst (BA) bước vào. Bằng cách sử dụng các kỹ thuật và công cụ khác nhau, BA mô tả nhu cầu kinh doanh bằng ngôn ngữ dễ hiểu cho cả 2 bên: Bộ phận Kinh doanh và thành viên đội dự án.

Những thách thức kinh điển mà Business Analyst phải đối mặt:

1. Quan niệm sai lầm về phạm vi công việc của BA

Rất thường xuyên xảy ra sự khác nhau giữa chức năng thực tế của BA và những thứ họ thực sự nên thực hiện. Nó là điển hình cho các dự án với khách hàng chưa có kinh nghiệm cho các dự án phát triển.

Giải pháp khả thi

Trước khi bắt đầu dự án, cần phải đồng ý với khách hàng về trách nhiệm của BA và các sản phẩm dự kiến được giao. BA phải đảm bảo rằng khách hàng hiểu ý nghĩa của tất cả các thuật ngữ (Wireframe, URS, SRS, v.v.). Ví dụ: khách hàng thường không thể phân biệt được sự khác biệt giữa  wireframe, mock-up và prototype. Đối với nhiều người những từ này là từ đồng nghĩa. Sự khác biệt được đánh dấu trong biểu đồ dưới đây.

Ngoài ra, khách hàng thường nghĩ rằng wireframe/ mock-up/ prototype là các thuật ngữ đồng nghĩa với việc thiết kế/design và do đó, họ yêu cầu áp dụng các kiểu, định dạng, lề, v.v. mà những yêu cầu ấy vượt quá trách nhiệm của một BA.

Như chúng ta có thể thấy, việc phê duyệt các sản phẩm dự kiến và nội dung của chúng là rất quan trọng đối với cả BA và khách hàng.

2. Các thông số kỹ thuật được tạo không đáp ứng nhu cầu của nhóm phát triển

Những cạm bẫy có thể là những trường hợp sau:

• Những yêu cầu rất mơ hồ và không rõ ràng.
• BA không hiểu cấp độ mô tả của yêu cầu cần thiết cho lập trình viên.
• Không đủ thời gian để phân bổ cho việc thu thập các yêu cầu và phát triển tài liệu đặc tả nghiệp vụ hoặc kỹ thuật.

Giải pháp khả thi

• Thảo luận và xác định với team dự án và khách hàng về cấp độ mô tả của yêu cầu cần thiết.
• Tạo và áp dụng “Danh sách kiểm tra yêu cầu” giúp xác định xem các yêu cầu có đầy đủ, chính xác, có thể xác minh và nhất quán hay không.
• Sử dụng các kỹ thuật mô hình hóa để xác định thông tin còn thiếu và bổ sung các chi tiết cần thiết.
• Tiết lộ các yêu cầu tổng quan trước, sau đó bắt đầu với các yêu cầu chi tiết
• Xem xét các yêu cầu bởi kỹ sư kiểm thử phần mềm ở những giai đoạn đầu. Kỹ sư kiểm thử sẽ kiểm tra các yêu cầu đối với một số vấn đề về chất lượng và tính xác thực.
• Các yêu cầu được review bởi lập trình viên.

Mỗi BA đều quen thuộc với tình huống khi các bên liên quan thay đổi yêu cầu của họ. Nó có thể xảy ra vài lần một tuần hoặc thậm chí một ngày. Tình huống khó xử chính đối với BA là có nên chấp nhận và áp dụng các thay đổi hay bỏ qua chúng.

3. Thay đổi yêu cầu hoặc thay đổi từ nhu cầu kinh doanh

Thay đổi yêu cầu trong quá trình triển khai dự án thường gây nhiều thách thức cho đội dự án. BA và PM là người thường phải đối diện để giải quyết. Có quá nhiều thay đổi có thể gây ảnh hưởng đến mục tiêu của dự án và nhiều khi là nguồn cơn của dự án thất bại.

Giải pháp khả thi

Đầu tiên và quan trọng nhất, BA nên hiểu lý do của những thay đổi như vậy. Dưới đây, bạn có thể tìm thấy một vài nguyên nhân phổ biến nhất và các giải pháp khả thi:

4. Xung đột với các bên liên quan

Xung đột giữa BA và các bên liên quan có thể xảy ra khi một nhóm đề xuất cách tiếp cận mới liên quan tới quy trình kinh doanh hiện tại.

Giải pháp khả thi: Trước hết, nhóm cần hiểu lý do của sự phản kháng đối với giải pháp mới.

Có hai tình huống kháng cự có thể xảy ra:

• BA đã bỏ lỡ một số tính năng quan trọng hoặc không cân nhắc hay xem xét một số nhu cầu hoặc yêu cầu quan trọng.
• Người dùng không muốn thay đổi quy trình làm việc và học các giải pháp hay tính năng mới.

5. Các quy trình không được tài liệu hóa

Trong trường hợp thứ nhất, BA nên nghiên cứu lại quy trình và các yêu cầu để chuẩn bị một giải pháp thích hợp. Trong trường hợp thứ hai, BA nên chuẩn bị tài liệu về tình huống kinh doanh cho người dùng và trình bày chúng, mô tả giải pháp mới và trả lời các câu hỏi của người dùng. Tài liệu cần có đủ các chi tiết để chứng minh cách tiếp cận do người ra quyết định đề xuất.

BA đã quen với việc thiếu tài liệu về dự án hoặc các quy trình và thủ tục được tài liệu hóa sơ sài. Lúc đầu, có vẻ như mọi người dùng đều thực hiện công việc của họ theo cùng một cách, nhưng khi ngày càng có nhiều chi tiết được làm rõ, các giai đoạn quy trình thực tế có thể khác nhau của người dùng này với người dùng khác. Vì vậy, các yêu cầu từ các nguồn khác nhau xung đột lẫn nhau.

Giải pháp khả thi: Để giải quyết xung đột, BA nên xác định người dùng hệ thống chính và những người ra quyết định. Sau đó, một dữ liệu với mô tả được tạo ra để thể hiển sự khác biệt giữa các quy trình dành cho người dùng với các vai trò khác nhau. Tài liệu này phải được trình bày cho stakeholder để xác định xem các quá trình được mô tả có phù hợp với giải pháp hay không. BA phải tập trung vào nhu cầu kinh doanh hơn là vị trí của người dùng.

Apex Global có thể giúp các BA vượt qua các thách thức đó. Apex Global hiện đang cung cấp 2 khoá đào tạo liên quan đến các thách thức trên:

• Khoá đào tạo “Business Analysis In Practice” phù hợp với những BA thực hành công việc thu thập yêu cầu nghiệp vụ chi tiết, phân tích, đặc tả và quản lý yêu cầu thông suốt dự án. 
• Khoá đào tạo “Business Analysis Professional” phù hợp với những Senior BA, ERP Consultant, Manager muốn thực hành phương pháp luận để giải quyết vấn đề để tạo ra dự án (theo đúng giáo trình của BABOK3). Vẫn có hoạt động thu thập yêu cầu ở mức tổng quan, phân tích chiến lược, phát giải pháp đề xuất dự án hoặc tư vấn 1 giải pháp.

Các khóa đào tạo được tổ chức về Business Analysis public (offline, online – virtual class) và inhouse cho doanh nghiệp. Khoá được các doanh nghiệp hàng đầu chọn lựa triển khai Inhouse tiêu biểu như: ACB bank, DMSpro, Gimasys, Techcombank, LienVietPostBank, MSB, CMC TSSG…

(Khai giảng khóa inhouse Business Analysis Professional cho doanh nghiệp CMC TSSG)

Vũ Lâm Thi – Thành viên đội tư vấn đào tạo Apex Global

(Bài viết tham khảo một số nguồn trên internet)