Hiểu biết thêm BA

Nhìn chung vài trò của BA khá rộng không chỉ liên quan đến lĩnh vực IT (Information Technology – CNTT) mà còn liên quan đến nhiều lĩnh vực khác như ngân hàng, bảo hiểm, logistic, hàng không, chuỗi cung ứng…Đối với BA trong công ty outsouce, nhiệm vụ của BA thường liên quan đến các nội dung cụ thể như:Giao tiếp với khách hàngThu thập các yêu cầu dự ánXác định phạm vi của dự án (scope of the project)Phân tích yêu cầu và mô tả tài liệu cho dự ánKiểm tra nghiệm thu dự ánQuản lý tài liệu dự ánBên cạnh BA các công ty IT outsouce, còn có các BA ở những dự án ERP (Enterprise Resource Planning).Các dự án ERP tương đối phức tạp, liên quan đến phân tích quy mô lớn và thay đổi phạm vi tổ chức mà đòi hỏi cần được thực hiện và duy trì. Các doanh nghiệp thường cảm thấy khó khăn đối với các chức năng có trong hệ thống.Trong quá trình xây dựng hệ thống ERP cho doanh nghiệp BA thường tham gia và đóng vai trò ở các mảng như:Định nghĩa các quy trìnhThay đổi việc quản lýĐịnh nghĩa các yêu cầuMô tả giao diện các hệ thốngKiểm traNgoài BA làm ở dự án các công ty IT, các công ty triển khai ERP thì hiện nay BA ở các công ty mới khởi nghiệp về kinh doanh, công nghệ cũng khá phổ biến:Với công cuộc cách mạng 4.0, phong trào khởi nghiệp ở tất cả các lĩnh vực đời sống, xã hội diễn ra vô cùng mạnh mẽ. Đặc điểm chung của các doanh nghiệp này là áp dụng CNTT giải quyết các bài toán kinh doanh. Ngoài đội ngũ phát triển phần mềm (developer, QC, QA, PM..) các doanh nghiệp start up cũng có sự xuất hiện của BA. Việc chuyên nghiệp hóa quy trình sản xuất phần mềm, nghiên cứu thị trường cho việc phát triển sản phẩm thì sự xuất hiện của BA đóng vai trò rất quan trọng trong sự thành công của sản phẩm, giúp tiết kiệm rất nhiều chi phí và thời gian.Thông thường các công ty khởi nghiệp thì quy trình, mô hình hoạt động, business còn chưa rõ ràng và tương đối lộn xộn, thường xuyên thay đổi để đáp ứng với nhu cầu thị trường. Ở các công ty start up thì điểm thuận lợi đó chính là sự linh hoạt, scope tương đối nhỏ, đội ngũ phát triển thường không quá lớn và có sự tương tác cao. Điểm bất lợi của các doanh nghiệp start up đó chình là chưa thật sự định hình rõ ràng mô hình business, quy trình hoạt động giữa các bộ phận cũng chưa thật sự rõ ràng và chuyên nghiệp, nguồn lực và tài chính và nhân sự cũng tương đối hạn hẹp vào từng giai đoạn. 

Một câu hỏi khá hay và được nhiều bạn đang làm tester quan tâm. Để trả lời cho câu hỏi này thì chúng ta cùng đi phân tích thế mạnh của các bạn đang làm tester khi chuyển sang BA như thế nào nhé. Lý do Tester tiếp cận nhanh khi trở thành Business Analyst là gì?Tester có khả năng phân tích:Khi nhận một dự án thì Tester được yêu cầu đọc, phân tích và xem xét các tài liệu đặc tả yêu cầu. Kỹ năng phân tích của Tester có thể giúp Business Analyst chỉ ra sự không rõ ràng trong các đặc tả yêu cầu nếu có.Tester cũng có kỹ năng giao tiếp tốtTrong các dự án Tester đều được làm việc và trao đổi với các vị trí khác như Developer, BA, PM,… về những vấn đề trong quy trình mà họ nhìn thấy. Trao đổi về các vấn đề môi trường thử nghiệm và quy trình thủ công mà người dùng doanh nghiệp có. Tester cũng đảm bảo rằng các kết quả kiểm tra được ghi lại trong các công cụ kiểm tra để bất kỳ ai đọc nó cũng hiểu được những gì sai với hệ thống.Có kiến thức hệ thống chuyên sâu:Tester luôn chú ý đến chi tiết và nắm rõ về hệ thống phần mềm được xây dựng, thậm chí còn tốt hơn các BA và chắc chắn là nhiều hơn Quản lý dự án. Tester thông qua công việc đảm bảo chất lượng của họ để biết lý do một kịch bản thất bại. Điều này làm cho một Tester một BA rất tốt.Các kiến thức khi Tester chuyển sang Business AnalystTiếp tục củng cố kiến thức về phần mềm, đây cũng chính là điểm mạnh của một Tester trong quá trình chuyển đổi sang BA.Tiếp tục phát triển khả năng chú ý chi tiết và hiểu biết sâu sắc về cách hệ thống phần mềm được xây dựngPhát triển hơn lợi thế có liên quan đến BA như thấu hiểu lợi ích của khách hàng, khả năng phân tích, đánh giá các tài liệu về yêu cầuTester là người đánh giá, thông qua các yêu cầu về phần mềm, điều này giúp cho họ có thể liên kết với các yêu cầu của khách hàng khi đảm nhận vị trí BATester có nhiệm vụ lưu lại các báo cáo lỗi liên quan đến dự án, phát triển kỹ năng lưu trữ này sẽ giúp rất nhiều trong công việc của BAMột Tester trong dự án cũng phải làm việc với rất nhiều bộ phận, hãy tận dụng nó để luyện tập khả năng giao tiếp thật tốt, đây cũng là một trong những kỹ năng quan trọng của một BA.

Trả lời:Chuyên viên phân tích nghiệp vụ (Business Analyst – BA) yêu cầu phải thực hiện được các công việc sau:+ Thu thập thông tin+ Viết tài liệu+ Quản lý các yêu cầu+ Tổ chức các cuộc họp+ Nghiên cứu tính khả thi/phù hợp+ Là cầu nối giữa các nhóm chức năng và nhóm kỹ thuật

Trả lời: Sự thật là có rất nhiều dự án phần mềm thất bại mỗi năm, mặc dù có những tiến bộ về trong phát triển phần mềm và phân tích nghiệp vụ. Với vai trò là người đào tạo và cố vấn cho các nhà phân tích nghiệp vụ, tôi thường gặp phải những trường hợp sau:Một dự án phần mềm nội bộ trông có vẻ diễn ra rất tốt đẹp cho đến khi người BA đưa ra bản dùng thử các giải pháp cho các bên tham gia dự án nhưng chỉ để nghe BA nói về phần mềm không thôi, đó là một lỗi lớn sẽ ngăn cản phần mềm không được thay đổi những chi tiết quan trọng hướng người dùng khi đưa vào sử dụng.Một ứng dụng đã được thông qua quá trình kiểm thử bởi người dùng, nhưng có hàng trăm phản hồi xin hỗ trợ gửi đến vào ngay tuần đầu tiên khi đưa phần mềm vào sử dụng, bởi vì người dùng đòi hỏi phải cải thiện nâng cao hệ thống chỉ cần một cú nhấp chuột sẽ hoàn thành bước thực hiện.Hơn 50% các chức năng trong hệ thống chưa được sử dụng đến, trong khi đó hàng loạt các yêu cầu thay đổi liên tục được đưa ra, vì người dùng muốn đầu tư vào các tính năng mới khi họ được tối ưu hóa quy trình làm việc.Sau khi tham gia nhiều dự án phần mềm phức tạp có giá trị kinh tế lớn, tôi đúc kết những lý do để làm nên một dự án thành công:

Dưới đây là những thách thức:Agile đòi hỏi BA tạo ra các yêu cầu nhanh hơn bằng cách phân tích thông qua quan sát hay thử nghiệm-và-lỗi thay vì cố gắng để tìm ra tất cả các sự kiện trước khi bắt đầu phát triểnTài liệu Yêu cầu nghiệp vụ tổng quan không được yêu cầu và mức độ chi tiết khác nhau.