Blog

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 đó),

Tư duy thiết kế là một khái niệm được giới thiệu lần đầu tiên vào những năm 1960 và gần đây đã đạt được rất nhiều thu hút trong thế giới kinh doanh. Được thông qua bởi nhiều công ty FTSE 500 cao cấp như IBM, Apple và Google để tăng cường đổi mới và cải tiến sản phẩm và dịch vụ, tư duy thiết kế đang trở thành một phần của hoạt động hàng ngày trong các tổ chức trên toàn hệ thống.

10 trách nhiệm hàng đầu của một Business Analyst mà bất cứ BA nào cũng phải nắm

Bạn là một chuyên viên viên Phân tích nghiệp vụ (Business Analyst – BA)? Và bạn luôn muốn công việc của mình hiệu quả hơn?