Business Analyst(BA) là người cần có nhiều kĩ năng khác nhau để làm việc tốt với nhiều bên liên quan. Tổ chức IIBA quốc tế cũng đã đưa bộ kĩ năng giao tiếp là một trong những kĩ năng quan trọng nhất của người BA. Trong kĩ năng giao tiếp thì có kĩ năng nghe, nói, đọc và kĩ năng viết (trình bày bằng chữ viết).
Có lẽ không riêng gì với nghiệp Business Analyst (BA) mà mỗi chúng ta đều nên có một thói quen dành thời gian phát triển bản thân các bạn héng? Nhất là tuổi trẻ còn sung sức, còn “ngày rộng tháng dài" phía trước để vươn tới. Tại sao mình lại ưu ái việc này cho tuổi trẻ hơn?
Tư duy hệ thống cần được áp dụng trong suốt quá trình làm việc của Business analyst. Hình mình họa dưới đây sẽ cho bạn biết được sự quan trọng và chu trình của việc tư duy hệ thống. Với mô hình này BA có thể áp dụng nhanh ở nhiều trường hợp khác nhau trong một dự án.
Kỹ năng viết dành cho BA, bạn hãy xem 5 lưu ý sau từ anh Nguyễn Thái Sơn: Hãy bắt đầu với WHY - Tại sao BA hay phải viết? #2. Khi mới đi làm, mình thường bắt đầu với WHAT, #3. Sau đó đến WHO, #4. Nghĩ tới đây rồi, giờ mới là HOW...Về requirements thì còn một loạt nguyên tắc riêng cho reqs nữa, ví dụ correct, complete, verifiable / testable, feasible, free-implementation,…
Trong BABOK cũng có nhắc tới các loại yêu cầu tuỳ vào đối tượng cung cấp: Yêu cầu người dùng, yêu cầu doanh nghiệp, hay yêu cầu giải pháp...Trong các mảng việc dự án mình từng tham dự thì yêu cầu giải pháp (solution requirements) là được phân tích và quản lý trực tiếp bởi các BA trực chiến dự án. Bởi ở đó tập trung các yêu cầu cụ thể để đội phát triển có thể thực hiện việc xây dựng giải pháp, bao gồm yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng (non-functional requirements). Đây cũng là loại yêu cầu phổ biến nhất bởi phần lớn dự án phát triển sản phẩm.
Trước khi chia sẻ với các bạn về những “đau thương" của BA khi làm một dự án lift & shift gần đây, mình cần phải nói rằng những chia sẻ này xuất phát từ kinh nghiệm cá nhân và các đồng nghiệp mình thường tương tác và thảo luận cùng trong suốt quá trình làm việc.
Để bắt đầu thì mình xin kể một dự án mình tham gia năm ngoái. Một ngày đẹp trời, sếp nói có khách hàng kia dự án sắp go-live mà giờ thiếu BA...qua đó coi có mần ăn gì được không thì mần, không mần được đừng về. Nói vui là như vậy, chứ đời consultant ở đâu có “khách" là đi chứ đâu có lựa chọn. Họ yêu cầu 1 technical BA để làm việc với team đang thực hiện công đoạn Data Migration.
Kinh nghiệm cả inhouse, outsource, offshore, offshore-outsource: mình đã từng trải qua từ lúc còn ở nhà. Nay xin được kể lể dông dài với các bạn. Mong nhận thêm chia sẻ từ các bạn nữa nhé. Bài viết này hi vọng sẽ giúp các bạn BA mới sáng tỏ hơn về con đường mình sẽ chọn, công ty mình sắp nhận lời hay đơn giản là tự tin “chiến đấu" ở bất cứ cty nào các bạn có cơ hội
Cơ hội luôn đến với mỗi người và điều quan trọng là chúng ta dũng cảm để nắm bắt chúng tốt. Ngoài việc nhìn những điều mất đi chúng ta cần nhìn nhiều hơn về những gì đạt được khi đưa ra một lựa chọn. Trong các khoản đầu tư, đầu tư vào giáo dục và sức khỏe là những khoản đầu tư luôn lãi. Việc đầu tư cho giáo dục, các khóa học sẽ tốn kém về thời gian và tiền bạc nhưng cũng sẽ mở ra cho bạn những cơ hội tuyệt vời vào tương lai.
CV tốt là bước đầu tiên giúp bạn có cơ hội phỏng vấn. Làm tốt CV cũng là một kĩ năng tổng hợp và trình bày dành cho BA. Việc có được công việc ngoài CV còn phụ thuộc vào năng lực, trình độ chuyên môn và đặc biết là tính cách, thái độ của ứng viên dành cho công việc và công ty.
Đối với chúng tôi, Testers làm BA rất giỏi. Về các kỹ năng, họ thực sự có nhiều điểm tương đồng - phân tích, giao tiếp và bí quyết thực hiện hệ thống kinh doanh. Trong bài viết này, tôi sẽ xem qua ba lý do tại sao tôi nghĩ tester trở thành BA tốt - xem bạn có đồng ý với suy nghĩ của tôi không.
Từ ‘use case’ thường hay được đưa vào các cuộc trò chuyện mà không nhất thiết phải có sự hiểu biết đúng đắn về nó. Vậy ‘use case’ thật sự liên quan đến gì? Use case trong ngữ cảnh Phân tích nghiệp vụ (business analysis) là bức tranh hoàn chỉnh về cách người dùng sẽ sử dụng một phần chức năng cụ thể cho một hệ thống mới hoặc thay đổi. Nó là một mô tả về các bước mà người dùng sẽ thực hiện một chức năng (và hệ thống sẽ thực hiện chức năng đó để thực hiện chức năng đó),