Tại sao BA cần 1 framework?

Khi mới vào nghề, chúng ta có xu hướng bắt đầu từ các kỹ thuật BA, học cách viết các tài liệu và làm sao để lấy yêu cầu. Bạn gặp may nếu ở công ty của mình cádfasdfó 1 quy trình chuẩn, 1 người leader luôn nói cho bạn biết phải làm gì.

Bạn không biết lý do tại sao mình làm việc này ở thời điểm này. Bởi vì bạn không có 1 cái nhìn toàn cảnh về những gì BA phải làm – 1 bộ khung công việc của BA, aliền với vòng đời của dự án.

Giai đoạn 1: Định hướng

Đây là bắt đầu bước vào 1 dự án mới hoàn toàn hoặc đã được bắt đầu trước đó. Chúng ta sẽ có rất nhiều câu hỏi mơ hồ trong đầu kiểu: Dự án này là gì? Tại sao cần làm dự án này? Đó là những câu hỏi tổng quan đầu tiên và việc của bạn là tìm 1 câu trả lời rõ ràng.

Đừng vội đi vào chi tiết quá sớm. Bạn muốn bắt tay ngay vào tìm vấn đề và làm giải pháp ngay từ ngày đầu tham gia dự án. Nhưng điều đó rất dễ khiến mọi thứ chệch hướng hoàn toàn.

Đây là thời điểm để bạn tìm hiểu về những điểm còn mù mờ trong dự án, những thứ mà “bạn không biết là mình không biết”.

Những câu hỏi bạn cần trả lời và việc cần làm trong giai đoạn này:

• Dự án này là gì? Mục tiêu lớn nhất của nó là gì?
• Vai trò của bạn trong dự án là gì? Bạn cần tạo ra những output nào để đáp ứng nhu cầu của stakeholder.
• Các stakeholder chủ chốt là ai? Bạn sẽ tiếp cận họ như thế nào để lấy business goal và xác định scope của dự án?
• Nắm được tình hình dự án cho đến thời điểm hiện tại. Tránh việc làm lại những thứ đã được làm rồi.
• Hiểu được những thứ hệ thống đang có và những gì hệ thống làm được

Bạn có thể vượt qua giai đoạn này nhanh chóng bằng cách phương pháp gợi ý sau:

• Trân trọng những buổi brief mà stakeholder, PM hoặc PO dành cho bạn, cố gắng khai thác và hỏi càng nhiều càng tốt.
• Nhanh chóng xác định được stakeholder chủ chốt và tạo kết nối tốt với họ. Tận dụng việc trao đổi thông tin với họ cả trong các buổi họp chính thức và các cuộc trò chuyện không chính thức (1 buổi ăn trưa hay chầu cafe).
• Đọc tài liệu: lục tìm, hỏi xin tất cả tài liệu có sẵn của dự án để hiểu hơn về dự án. Tất nhiên, hãy cẩn thận những tài liệu outdate và không còn sát với thực tế.

Giai đoạn 2: Xác định nhu cầu business

Khi đã có được những thấu hiểu cơ bản về dự án. Bước tiếp theo đó là xác định Business Goal. Đây là loại input quan trọng nhất để đảm bảo dự án không lệch hướng trong tất cả giai đoạn tiếp theo.

Technical team có thể đảm bảo việc sản phẩm cho ra đáp ứng được Product Backlog. Nhưng BA sẽ là người chịu trách nhiệm đặt vào backlog những tính năng, những story giúp giải quyết Business Goal. Đó chính là kim chỉ nam của dự án.

Những gì cần làm trong giai đoạn này:

• Xác định Goal theo từng cấp độ:
  • Business: Cấp độ cao nhất, là vấn đề/nhu cầu cốt lõi mà dự án phải giải quyết hoặc đạt được. Thường được đưa ra bởi các stakeholder có quyền quyết định cao nhất trong dự án.
  • User: Những mục tiêu cụ thể hơn cần đạt để hoàn thành Business goal. Thường đưa ra bởi những người sẽ trực tiếp sử dụng sản phẩm mà dự án tạo ra.
  • Function and Non-function: Những yêu cầu sơ lược hơn về mặt tính năng hoặc phi tính năng mà hệ thống cần đảm bảo. Thường đối với những dự án mà client là những tổ chức lớn, chuyên nghiệp. Ngoài việc dự án đáp ứng các business goal và user goal thì còn có thêm các tiêu chí mà sản phẩm phải đảm bảo khi bàn giao.
• Bạn có thể bắt đầu tạo tài liệu BRD từ những nhu cầu này.
• Luôn confirm lại cách hiểu của bạn với stakeholder để chắc chắn không hiểu sai. Đây là 1 input rất quan trọng.

Giai đoạn 3: Xác định phạm vi thay đổi

Một phạm vi dự án đã được thông qua bởi các stakeholder là thứ giúp cho bạn và team “an tâm” suốt dự án.

Phạm vi nghĩa là định ra biên giới giữa cái “Phải làm” và cái “Không làm”. Tất nhiên việc tuyệt đối rõ ràng như trắng và đen là bất khả thi. Sẽ luôn có 1 vùng xám “Nên làm” hoặc “Có thể sẽ làm”. Nhưng việc có một hình dung về quy mô dự án sẽ giúp team không đi quá xa khỏi vòng tròn này.

Những gì cần phải làm trong giai đoạn này:

• Bắt đầu tìm hướng tiếp cận giải pháp cho các vấn đề/nhu cầu. Đánh giá xem quy trình và công nghệ sẽ phải thay đổi như thế nào về mặt bản chất để đáp ứng Business Goal.
• Tạo ra những bản phác thảo về phạm vi dự án và liên tục trình bày cho stakeholder chủ chốt cả phía business và phía technical – cho đến khi họ sẵn sàng để ký và thông qua Scope Statement.

Giai đoạn 4: Lập kế hoạch BA chi tiết

Một kế hoạch BA chi tiết xác định các kết quả cụ thể mà BA cần tạo ra cùng với một ước tính thời gian hoàn thành. Dự án sẽ cần output gì từ bạn để có thể làm rõ yêu cầu từ business và công việc tiếp theo cần thực hiện.

Nhiệm vụ của giai đoạn này:

• Chọn được các format output phù hợp để làm rõ requirement. Việc lựa chọn phụ thuộc vào phạm vi dự án đã định nghĩa ở bước 3, dự án chạy theo kiểu waterfall hay agile, nhu cầu của technical team và các yếu tố khác của dự án.
• Xác định được danh sách cụ thể các kết quả BA cần đạt và những stakeholder sẽ tham gia và hỗ trợ quá trình thực hiện. (template excel cho BA Plan)
• Xác định thời gian thực hiện mỗi task.

Nếu không dành thời gian ra để tự lập 1 kế hoạch thực tế và đáng tin cậy thì sẽ có hàng tá kỳ vọng từ stakeholder được gán cho bạn. Thường là những kỳ vọng bất khả thi vì họ không đánh giá đầy đủ được tính phức tạp đến từ nhu cầu.

Giai đoạn 5: Viết detail requirement

Bắt đầu từ giai đoạn này, BA sẽ liên tục giao tiếp với các stakeholder để elicite requirement về các tính năng hoặc quy trình cần thay đổi. Mục đích là viết ra các tài liệu mô tả chi tiết requirement. Đây là output trực tiếp nhất mà team technical cần để phát triển tính năng.

Requirement cần đạt được các yếu tố: cụ thể, đầy đủ và chính xác. Requirement không đầy đủ sẽ dẫn đến việc team triển khai ngụp lặn trong mơ hồ và chắc chắn ảnh hưởng kết quả đầu ra.

Những gì cần làm ở giai đoạn này:

• Thực hiện liên tục việc Elicite stakeholder, có được thông tin cần thiết để thực hiện thay đổi.
• Phân tích các thông tin thu thập được và chuyển hóa nó thành các tài liệu chi tiết cần cho dự án
• Xác nhận các tài liệu đã có với business stakeholder và technical stakeholder để bổ sung những thiếu sót nếu có.

Mức độ hiệu quả mà tài liệu do BA tạo ra sẽ nói lên mức độ hiệu quả của BA đó. Những tài liệu hữu hiệu có giá trị đẩy dự án tiến về phía trước nhanh chóng.

Chú ý đến việc làm rõ những thứ mơ hồ, cắt gọn những gì phức tạp. Hướng tới những cột mốc nhỏ và hoàn thành 1 cách liên tục.

Giai đoạn 6: Hỗ trợ technical team

Giai đoạn 6 yêu cầu BA có sự tham gia vào quá trình team phát triển sản phẩm thực hiện dựa trên requirement đã có.

Những gì cần thực hiện

• BA review các bản thiết kế cho giải pháp, đảm bảo giải pháp đó đang đi đúng hướng requirement đã mô tả. Ngoài ra, có thể gợi ý thêm giải pháp giúp đáp ứng những nhu cầu mở rộng của dự án mà không làm tăng phạm vi kỹ thuật.
• Cập nhập, chia nhỏ hoặc đóng gói các tài liệu requirement chi tiết để phù hợp hơn trong quá trình phát triển.
• Tương tác với chuyên viên kiểm soát chất lượng (QA) để đảm bảo là họ hiểu đúng hướng về requirement. Có thể review qua test plan và test case để đảm bảo đã hiểu rõ nhu cầu.
• Sẵn sàng trả lời khi có ai đó đặt câu hỏi trong suốt quá trình thiết kế giải pháp, lập trình, test của dự án.
• Quản lý các yêu cầu thay đổi, đảm bảo các stakeholder liên quan đều tham gia vào quá trình quyết định thay đổi và tiếp cận với tài liệu mới nhất.
• Nếu có thể, BA sẽ là người lead các buổi UAT (User Acceptance Testing) để đảm bảo sản phẩm đáp ứng nhu cầu business.

Giai đoạn 7: Hỗ trợ business triển khai giải pháp

Sau khi team technical của bạn đã tạo ra 1 sản phẩm xịn sò, đáp ứng mọi nhu cầu business rồi. Nhưng business user không sử dụng sản phẩm đó đúng cách và quay trở lại quy trình, thói quen làm việc cũ. Như vậy sẽ gây lãng phí nguồn lực và không giải quyết được nhu cầu business ban đầu.

BA sẽ phải tham gia luôn vào công đoạn cuối cùng của dự án để hỗ trợ business:

• BA cần phân tích và xác định rõ business process sẽ phải thay đổi như thế nào để đáp ứng sự thay đổi mà project đã tạo ra.
• Hướng dẫn, huấn luyện end-user để chắc chắn họ nắm luồng mới và các thủ tục cần thiết. Hoặc nếu có chuyên viên training riêng biệt thì BA sẽ phối hợp với bộ phận này để tạo ra các tài liệu và chương trình huấn luyện phù hợp.

Những bước ở trên đây là để đảm bảo tất cả các business user sẵn sàng tiếp nhận sự thay đổi được tạo ra bởi dự án

Giai đoạn 8: Đánh giá giá trị giải pháp

Tất cả mọi công đoạn chi tiết của dự án đã hoàn thành, kỳ vọng business đã được thảo luận, những vấn đề cả lớn lẫn nhỏ đã được giải quyết, các mối quan hệ đã được xây dựng, thay đổi đã được quản lý, kỹ thuật đã triển khai, người dùng đã được huấn luyện để sử dụng.

Hàng đống công việc và tập trung vào kết quả đầu ra có thể khiến cho chúng ta mất đi cái nhìn tổng thể. Liệu chúng ta đã và đang đi đúng hướng chứ? Giải pháp mà chúng ta tạo ra có đáp ứng được những kỳ vọng business như đã dự kiến?

Nhiệm vụ chính của giai đoạn này là:

• Đánh giá tiến độ thực sự của dự án dựa trên mục tiêu business để thấy được những kỳ vọng nào đã được đáp ứng.
• Trao đổi kết quả tiến độ với project team
• Đề xuất thêm các giải pháp cho những vấn đề mới phát sinh trong quá trình thực hiện project.

Áp dụng Framework vào dự án của bạn

Đa số BA thường không có 1 khung sườn cụ thể vì dường như mỗi dự án lại đòi hỏi 1 nhiệm vụ và quy trình làm việc khác nhau. Việc không có framework khiến bạn phải luôn nghĩ về việc mình phải làm gì tiếp theo, phải tự “bịa” ra một nhiệm vụ mà bạn cho là phù hợp.

Với 1 Framework gợi ý như trên, bạn sẽ có 1 chỉ dẫn sơ lược nhất về những gì cần thực hiện xuyên suốt 1 dự án công nghệ.

Bạn hoàn toàn có thể thay đổi và áp dụng 1 cách linh hoạt Framework trên để thật sự match với quy trình làm việc của mình.