Tôi từng được tham gia phỏng vấn với mấy anh chị leader team BA lúc trước. Họ thường hỏi ứng viên câu hỏi là: Theo em khi nào thì BA hoàn tất việc thu thập yêu cầu?

Câu trả lời thường thấy nhất là: Không bao giờ kết thúc?

Và thường câu trả lời này đến từ các bạn Fresher, Junior còn ít kinh nghiệm.

Có thể do bạn không hình dung được toàn cảnh mình phải làm gì (What to do) trong 1 dự án. Hoặc bạn biết phải làm gì những không biết để làm xong việc đó thì phải cho ra output nào, đạt những yêu cầu nào .

Thực ra có thể việc của BA có thể rất nhiều, rất dàn trải và không có định hướng. Nhưng nếu giữ mindset là việc sẽ ở đó và còn hoài thì mỗi sáng thức dậy đến công ty đi làm là một áp lực khủng khiếp. Nên hãy thay đổi tư duy, để nhìn thấy đâu là những thứ mà BA có thể kê cao gối ngủ khi đã bàn giao xong.

Tóm lại, BA có thể làm xong việc hay không? Câu trả lời là CÓ!

Các tiêu chí để gọi là xong:

1. Output phù hợp với từng giai đoạn.
2. Output đạt chất lượng (chính xác, rõ ràng, không dư thừa)
3. Output đúng deadline
4. Output của BA cần được confirm bởi stakeholder liên quan để chính thức khép lại 1 task của BA.
   

1. Output phù hợp giai đoạn

Để thấy được toàn bộ các giai đoạn của dự án và nhiệm vụ của BA thì bạn hãy xem lại bài viết về BA Framework. Hãy đảm bảo bạn đã nắm được chiếc “xương sườn” này thật chắc. Đây là nền tảng cho những thứ khác bám vào.

Có thể chia các giai đoạn của dự án ra thành

Khởi động – Tiến hành xây dựng giải pháp – Bàn giao giải pháp.

BA đều cần tham gia 3 giai đoạn này, và output của BA sẽ là input của các bộ phận khác trong team phát triển.

Việc lựa chọn output nào trong từng giai đoạn là rất quan trọng. Trong giai đoạn Khởi động, nếu bạn chọn tạo ra quá nhiều những document đi sâu vào mô tả chi tiết giải pháp thì có thể dễ dàng miss business requirement và dần dần lạc lối. Hoặc nếu đã bước qua giai đoạn bàn giao rồi mà vẫn quanh quẩn đi tổng hợp meeting minute thì quá là không ổn.

2. Output đạt chất lượng

Các output sau khi đã được xác định rồi thì cần phải được xây dựng thật chất lượng.

Có 1 vài yếu tố để nói lên chất lượng output của BA

Đúng – Đừng sai
Đủ – Đừng thừa, đừng thiếu
Rõ – Đừng phức tạp, đừng khó hiểu

Đây là kỹ năng mà BA cần phải rèn dũa qua thời gian. Đôi khi biết được mình phải làm gì là một chuyện. Làm ra output với một chất lượng đảm bảo lại là chuyện khó hơn và cần đổ mồ hôi để thành thạo.

Đúng

Gặp đúng người, hỏi đúng câu hỏi, lấy đúng thông tin, truyền đạt đúng ý nghĩa, sử dụng đúng format tài liệu… Một chữ Đúng này yêu cầu rất nhiều yếu tố cộng hưởng với nhau.

Đủ

Những kỹ thuật tránh miss requirement đọc thêm ở đây.

BA cần đề cao tính tối giản của tài liệu nhưng KHÔNG BAO GIỜ được miss requirement.

Việc viết 1 tài liệu đủ thông tin nhưng vẫn đơn giản mất thời gian hơn nhiều so với việc nhồi cả đống thông tin không sàng lọc vào 1 nồi lẩu thập cẩm. Điều đó phụ thuộc nhiều vào việc BA chọn đúng format để cấu trúc thông tin cho tài liệu đó, áp dụng các tuyệt kỹ đánh index, highlight keyword, reference, ….

Dev đọc vào 1 tài liệu và cảm thấy có đầy đủ input mà họ cần để bắt tay vào làm. Không cảm thấy rối rắm bởi các thông tin gây nhiễu. Tester cảm thấy nhìn vào document là có đủ input để viết test case,… Đó chính là khoảnh khắc “Oh Yeah!” mà BA mang lại.

Rõ

1 tổ chức, 1 dự án có hàng tá con người, mỗi người lại có background, cách diễn đạt, mục tiêu làm việc riêng. Nó giống như hàng đống vector đang kéo ra vô số hướng. Khi các vector không cùng hướng, chúng sẽ triệt tiêu lẫn nhau. Kết quả cuối cùng là dự án, tổ chức đó đứng yên hoặc tệ hơn là đi lùi.

Tác dụng của BA khi được thuê về là gom các vector đó về cùng 1 hướng.

10 người đọc 1 tài liệu và hiểu như nhau. Đó là rõ. Nếu 2 người đọc cùng 1 dòng nhưng lại hiểu theo 2 ý, vậy là chưa đạt.

Đọc thêm về cách viết requirement rõ như ban ngày ở đây.

3. Output đúng deadline

Cái này thì dễ hiểu rồi. Output của BA là input của nhiều bộ phận khác trong team. Hãy đảm bảo đúng deadline đã cam kết với team trong BA Plan. Cách viết BA Plan xem thêm ở đây.

Đôi khi bạn không kiểm soát hoàn toàn được các deadline của mình do bị phụ thuộc bởi sự hợp tác của stakeholder của mình. Hãy chủ động trong việc này, nhận định tình hình và tìm sự trợ giúp để đảm bảo hoàn thành được deadline sớm nhất có thể.

4. Output cần được confirm bởi stakeholder

Bạn viết document ra là để stakeholder xài. Vậy thì bạn cần sự xác nhận của chính người dùng cuối của các document hay tổng quát hơn là output của bạn.

Để đạt được sự confirm từ họ, ngay từ bước định hướng bạn đã phải biết stakeholder của mình kỳ vọng gì ở bạn rồi. Và bạn biết rõ khi output được tạo ra, nó đáp ứng trực tiếp cái mà stakeholder cần, kể cả về nội dung lẫn hình thức phù hợp với stakeholder.

Mục số 4 này có thể xem như là điều kiện đủ để BA hoàn thành công việc của mình một cách toàn vẹn. Bởi vì stakeholder sẽ chỉ thực sự signed-off 1 tài liệu hay output nào đó khi nó đúng, đủ, rõ và phù hợp với mong đợi của họ.

Okay, ngay khi nhận được sự confirm từ stakeholder. Bạn đã gạch bỏ được 1 task trong todolist của mình rồi đó.