Business Analyst hay được gọi ngắn gọn là BA, đóng vai trò quan trọng và không thể thiếu trong SCRUM. Nhà phân tích nghiệp vụ (BA) đóng vai trò là mối liên kết giữa chủ sở hữu sản phẩm (product owner), khách hàng và đội ngũ kỹ thuật IT (technical IT team). Đối với dự án Scrum, trong một số trường hợp, BA có thể là product owner hoặc team member. Nếu BA là product owner, họ sẽ trở thành điểm liên lạc giữa team scrum và các bên liên quan, đảm bảo rằng các yêu cầu của khách hàng được đáp ứng. Nếu BA là thành viên của đội (team member), họ sẽ hỗ trợ team trong việc phát triển và đảm bảo rằng các yêu cầu được hiểu rõ và đáp ứng đúng cách. 
 
Ngay sau đây, BAC sẻ giải thích vô cùng chi tiết vai trò nổi bật của Business Analyst (BA) trong Scrum đồng thời chứng minh lý do tại sao họ là một phần không thể thiếu trong quá trình phát triển dự án. Hãy cùng BAC khám phá ngay nhé!
 
1. Trách nhiệm của một Business Analyst 
Có rất nhiều vai trò của Business Analyst trong Scrum và có một số trách nhiệm nhất định mà BA phải tuân thủ. Dưới đây là một số trách nhiệm được lựa chọn trong số đó:
  • Làm đẹp product backlog dựa trên sự ưu tiên được cung cấp bởi chủ sở hữu sản phẩm.
  • Phân tích nhu cầu của khách hàng và tìm ra các giải pháp phù hợp để giải quyết chúng.
  • Tạo yêu cầu dưới dạng user stories với các tiêu chí chấp nhận phù hợp.
  • Nếu như user stories đã được tạo bởi chủ sở hữu sản phẩm (với tiêu chí chấp nhận), thì đánh giá lại chúng để đảm bảo rằng mọi quy tắc nghiệp vụ đều được bao phủ, đề cập đầy đủ và các tiêu chí chấp nhận đáp ứng chức năng của user story.
  • Làm việc với chủ sở hữu sản phẩm và các bên liên quan để hiểu phạm vi, đề xuất cải tiến cho yêu cầu, vv.
  • Chuẩn bị tài liệu như wireframes, design flow, UI,.. khi cần thiết.
  • Ngoài ra, Business Analyst còn là một thành viên quan trọng tham gia trong các phiên động não (brainstorming sessions) khi team gặp nhau để thảo luận về backlog của sprint sắp tới. BA hướng dẫn team, giúp họ hiểu yêu cầu, thậm chí đôi khi phải phê duyệt việc triển khai.
  • BA cũng làm việc chặt chẽ với các chuyên viên QA như phân tích phạm vi kiểm thử, chuyển đổi các use cases thực tế thành các test cases, cung cấp thông tin chi tiết để kiểm tra các chức năng phức tạp,... Song song đó, BA cũng tham gia vào cuộc họp lập kế hoạch để giúp team ước tính bằng cách giúp họ hiểu về luồng (flow), tính phức tạp và phụ thuộc của dự án.
Như vậy, BA luôn phải tiếp tục học hỏi về các xu hướng mới đang diễn ra trên thị trường, luôn sáng tạo, liên tục đổi mới và cập nhật về lĩnh vực kinh doanh cho sản phẩm.
 
2. Nhà phân tích nghiệp vụ với tư cách là chủ sở hữu sản phẩm (Product Owner)
Tùy thuộc vào khách hàng và công ty, có thể xảy ra trường hợp một số công ty có nhà phân tích nghiệp vụ làm chủ sở hữu sản phẩm. Trong tình huống này, BA đóng vai trò là đầu mối liên hệ cho tất cả các truy vấn. Sau đó BA trở thành  trung gian giữa team và các bên liên quan (stakeholders).
 
BA phải hiểu các yêu cầu của các bên liên quan cùng với suy nghĩ của họ về việc đưa doanh nghiệp phát triển và doanh nghiệp nên phát triển cái gì đồng thời triển khai hành động như thế nào. Sau đó, dựa trên yêu cầu của các bên liên quan, BA phải tạo tài liệu, user stories, sắp xếp thứ tự ưu tiên cho các stories, giúp team hiểu rõ chúng bằng cách trả lời các câu hỏi về chúng,...
 
Điều quan trọng nhất cần lưu ý ở đây là điều này chỉ được khuyến khích khi BA làm việc tại doanh nghiệp và không bị giới hạn bởi khoảng cách địa lý và múi giờ để tránh những "khoảng cách trong giao tiếp". Vì nếu BA với tư cách chủ sở hữu làm việc online, thì không thể tiếp cận họ nhanh chóng và cách duy nhất để giao tiếp là qua email, tin nhắn hay cuộc gọi, điều này có thể dẫn đến những vấn đề tiềm ẩn về thiếu sót thông tin, tọa khoảng cách và đôi khi thậm chí là sự sai lệch thông tin.
 
Với vai trò như chủ sở hữu sản phẩm, BA nên ngồi làm việc trong văn phòng công ty, bên cạnh team để dễ dàng tiếp cận và tiến độ công việc không bị ảnh hưởng. Từ quan điểm của BA, họ sở hữu sản phẩm thay mặt cho các bên liên quan / khách hàng, đưa ra các quyết định thích hợp và thậm chí cần học hỏi những kỹ năng mới, bao gồm học một số kỹ thuật phát triển.
 
Việc sở hữu một nhà phân tích nghiệp vụ với tư cách như một chủ sở hữu sản phẩm là một lợi thế vì BA hiểu rất rõ về sản phẩm, đồng thời cũng có thể thương lượng mức độ ưu tiên và phạm vi của các nhiệm vụ.
 
3. Nhà phân tích kinh doanh với tư cách là thành viên nhóm (Team member)

Trường hợp khác là BA làm việc như một thành viên trong team vì chủ sở hữu sản phẩm sẽ không có mặt mọi lúc. Ở vị trí này BA sẽ giúp các đồng nghiệp xử lý công việc tồn đọng.
 
Sở hữu một BA làm thành viên trong nhóm sẽ có lợi hơn vì nhóm kỹ thuật thấy dễ dàng và thoải mái khi giao tiếp với BA để làm rõ và thảo luận về các vấn đề dễ dàng hơn. BA cũng làm việc chặt chẽ với đội QA để kiểm thử, phân tích phạm vi, bao phủ các use cases, bất kỳ yêu cầu tiềm ẩn hoặc phụ thuộc hay tác động cụ thể nào đến dự án.
 
Đôi khi tiêu chí chấp nhận được viết bởi chủ sở hữu sản phẩm có thể mơ hồ và không rõ ràng, sau đó với tư cách là một thành viên trong nhóm, BA có trách nhiệm viết các tiêu chí chấp nhận chi tiết và giải thích rõ ràng hơn. Nếu team cần thêm thông tin, thì BA cũng tạo tài liệu wireframe, tài liệu luồng... để giúp nhóm hiểu yêu cầu hơn.
 
Trong các dự án quy mô lớn, nơi các module được phân phối giữa các team, có một BA cho nhiều team cũng là một lợi thế lớn. Vì BA giống nhau giữa các team nên họ có thể nghĩ về khả năng tương tác của các module, các tính năng mới hoặc  bản cập nhật mới sẽ ảnh hưởng như thế nào đến các module khác.
Do đó, điều này sẽ giúp ích rất nhiều cho các nhóm kỹ thuật trong việc xem xét các khía cạnh vì không phải lúc nào các user stories hoặc các tiêu chí chấp nhận đề cập đến những điều này.
 
4. Tầm quan trọng và vai trò của các nhà phân tích nghiệp vụ trong nhóm SCRUM
Vai trò của Business Analyst trong SCRUM rất quan trọng đối với thành công của một dự án. Sự tham gia của họ bắt đầu từ việc hiểu nhu cầu của khách hàng cho đến Sprint Demo. Họ là điểm liên lạc đầu tiên của đội kỹ thuật. BA càng quan trọng hơn trong các giai đoạn đầu của một dự án mới và các dự án quy mô lớn.
 
Chủ sở hữu sản phẩm không phải lúc nào cũng là một người diễn giải giỏi, đôi khi họ xuất phát từ nền tảng kỹ thuật và do đó, BA có trách nhiệm viết các stories, acceptance, wireframes,...
Chẳng hạn như trong dự án, PO không tốt với việc tài liệu hóa, anh ta mô tả user stories chỉ có 2-3 dòng và tiêu chí chấp nhận chỉ là 1 dòng. Lúc này chính Business Analyst là người sửa đổi chúng, giải thích, làm cho chúng dễ hiểu và được mô tả rõ hơn. Thậm chí đôi khi, PO viết các user stories có 21 hoặc nhiều hơn 21 story, và khi đó Business Analyst phải dành thêm thời gian và tốn nhiều nỗ lực để phân chia và ưu tiên chúng với chủ sở hữu sản phẩm.
 
Bạn có thể tưởng tượng điều gì sẽ xảy ra nếu không có Business Analyst, và chủ sở hữu sản phẩm của bạn đã tạo ra một user story như sau 'Là một khách hàng, tôi muốn thực hiện tất cả các hoạt động ngân hàng cho tài khoản của mình', với tiêu chí chấp nhận như:
  • Khách hàng có thể đăng nhập.
  • Khách hàng có thể thực hiện các giao dịch trong tài khoản của mình.
  • Khách hàng có thể tải xuống các báo cáo lịch sử giao dịch.
Có thể thấy, user story này thậm chí sẽ chứa hơn 34 điểm story, do đó cần phải chia nhỏ hơn nữa. Mọi thứ sẽ trở nên tồi tệ hơn đối với nhóm kỹ thuật nếu không cung cấp sơ đồ luồng (flow diagrams) và màn hình giao diện người dùng - UI screens (sẽ được tạo trong tương lai) phù hợp.
Điều này sẽ dẫn đến một cuộc chạy nước rút thất bại và do đó, một dự án thất bại. Trừ khi Chủ sở hữu sản phẩm là Nhà phân tích kinh doanh được đào tạo/thực hành, nếu không thì cần phải có một người trong nhóm.
 
Có thể thấy, user story này sẽ có thể cần hơn 34 story, do đó cần phân chia nó thêm. Việc điều tồi tệ hơn cho đội kỹ thuật nếu không cung cấp các sơ đồ luồng hoặc màn hình UI (để tạo) đúng cách. Điều này sẽ dẫn đến một sprint không thành công và từ đó kéo theo một dự án thất bại. Trừ khi chủ sở hữu sản phẩm là một Business Analyst đã được đào tạo và có kinh nghiệm thực hành nếu không thì hẳn cần phải có thành viên trong team với tư cách BA. Là một BA, đừng bỏ lỡ những kiến thức quan trọng để nâng cấp sự nghiệp tại BAC's Blog bạn nhé!
Nguồn tham khảo:

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

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.
 
 

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