- vừa được xem lúc

3 dạng comment dễ khiến BA rơi vào bẫy… tưởng đã done rồi

0 0 2

Người đăng: ITBA Mentor

Theo Viblo Asia

Không phải bug, không phải logic sai, không phải thiếu tài liệu Nhiều pha toang trong dự án bắt đầu chỉ từ… một câu comment tưởng vô hại.

1. Những comment tưởng vô hại, nhưng khiến BA “đóng task” trong vô thức

Một vài câu thường gặp: “Tạm ổn rồi, mai check nốt” “Cái này để release sau nhé” “Không tái hiện được bug”

Dev nói vậy, Test gật đầu, và bạn… nghĩ là done. Nhưng thật ra: “Tạm ổn” = vẫn còn bug “Để sau” = không có task chính thức “Không tái hiện được bug” = chưa hiểu gốc rễ, không phải bug biến mất

📌 Sai lầm BA thường gặp:

  • Bỏ qua bước Verify Requirements – BABOK 7.2
  • Không Confirm Transition Requirements – BABOK 7.6
  • Tưởng đã xong, nhưng mới xong 80%

✅ Cách làm đúng:

  • Yêu cầu Dev/Test cung cấp bằng chứng rõ ràng: log, API, kết quả test
  • Walkthrough lại với Tester các edge case
  • Nếu “để sau” → phải tạo task riêng, log rõ ràng, assign người xử lý cụ thể

2. “Khách bảo bỏ rồi” – Nhưng không ai log lại

  • Nghe từ PM. Nghe từ Dev. Nghe từ PO.
  • Không thấy task update, nhưng vì “nghe chắc rồi” → bạn tự gỡ khỏi flow.
  • Không cập nhật tài liệu. Không hỏi lại. Không có gì để backup.

2 tuần sau, khách hỏi: “Ủa, sao phần đổi mã giảm giá không thấy đâu?” “Chị có bảo bỏ hả? Không nhớ vậy nha…”

📌 Sai lầm BA thường gặp:

  • Không Maintain Requirements – BABOK 5.3
  • Không Trace Requirements – BABOK 4.2
  • Không có xác nhận chính thức

✅ Cách làm đúng:

  • Mọi thay đổi cần có email, task hoặc comment rõ ràng
  • Không update tài liệu nếu chưa có xác nhận
  • Ghi lại tất cả lời nói miệng vào Sổ Ghi Lời Rì Rầm 📝

3. “Bug này chắc user không gặp đâu” – Tự an ủi, tự loại khỏi backlog

  • Bug không rõ nguyên nhân
  • Dev/Test bảo: “hiếm lắm”
  • Bạn tin. lờ. bỏ.
  • Đến lúc user gặp thật → hệ thống xử lý sai → thiệt hại thật

📌 Sai lầm BA thường gặp:

  • Không Assess Risks – BABOK 10.3
  • Không làm Business Rules Analysis – BABOK 10.4
  • Không trace bug về requirement gốc

✅ Cách làm đúng:

  • Không bỏ qua bug nào nếu chưa rõ nguyên nhân
  • Trace lại rule → có hở không? Case nào chưa xử lý?
  • Dùng dữ liệu thật để test lại thay vì giả định “chắc không sao đâu”

Tổng kết

BA không sai vì tin người khác nói BA chỉ sai khi dừng lại ở đó Nghe là một chuyện. 📌 Xác nhận – xác minh – log lại → mới là phần BA phải làm đến cùng

Bình luận

Bài viết tương tự

- vừa được xem lúc

ĐỐI VỚI BUSINESS ANALYST, KỸ NĂNG MỀM CHÍNH LÀ KỸ NĂNG CỨNG MỚI

Bài viết dưới đây là những dòng chia sẻ của anh Arvind Arcot về tầm quan trọng của những kỹ năng mềm cần phải học và rèn luyện như những kỹ năng cứng khác. Với kinh nghiệm dày dặn của mình, anh Arvind nhận định rằng một người BA thực thụ sẽ thấy rằng: Các kỹ năng cứng về tài liệu hóa, khơi gợi yêu c

0 0 32

- vừa được xem lúc

Business Analysis: Planning and Ensuring Success (Phần 3)

Plan Business Analysis Governance. .

0 0 49

- vừa được xem lúc

Introductory knowledge of Business Analyst

1. Business Analysis (phân tích nghiệp vụ) là gì.

0 0 44

- vừa được xem lúc

Không “ xuất thân” IT, làm thế nào để trở thành 1 Business Analyst "chất" ? (Phần 1)

Vừa học vừa viết. Xuất thân là 1 Non.

0 0 22

- vừa được xem lúc

Top 5 công cụ & phần mềm phân tích dữ liệu tốt nhất năm 2023

Nếu như bạn vừa mới tìm hiểu về ngành data analysis (Phân tích dữ liệu), và đang băn khoăn không biết nên lựa chọn công cụ phù hợp nào để hỗ trợ cho công việc BA của mình, BAC sẽ thống kê top 5 công c

0 0 25

- vừa được xem lúc

11 Kỹ thuật thu thập yêu cầu cho Agile Product Teams

Trong quá trình phát triển các sản phẩm Agile, việc hiểu rõ yêu cầu của người dùng là một bước tiền đề để đảm bảo sản phẩm đáp ứng được nhu cầu thực tế. Để thu thập yêu cầu một cách hiệu quả thì nhóm

0 0 28