Kỹ năng không ai dạy nhưng quyết định 50% thành bại của BA
Nhiều bạn mới học IT Business Analyst thường nghĩ:
“BA giỏi là người viết User Story tốt, vẽ flow đẹp, biết SRS, biết API, biết SQL…”
Đúng.
Nhưng chưa đủ.
Vì khi vào dự án thật, bạn sẽ nhận ra một sự thật hơi phũ:
Requirement không tự nhiên mà rõ.
Stakeholder cũng không tự nhiên mà hợp tác.
Và đó là lúc kỹ năng Stakeholder Management trở thành thứ quyết định bạn làm BA “êm” hay “toang”.
1️⃣ Stakeholder Management là gì?
Hiểu đơn giản:
Stakeholder Management là cách BA làm việc, giao tiếp, khai thác, điều phối và giữ sự đồng thuận với những người liên quan đến dự án.
Stakeholder có thể là:
Product Owner
Business Owner
End-user
Dev
QA
Designer
Operations
Compliance
Customer Support
Vendor / đối tác ngoài
BA không chỉ “hỏi stakeholder lấy yêu cầu”.
BA phải biết:
Ai là người ra quyết định?
Ai là người dùng thật?
Ai có tiếng nói ảnh hưởng?
Ai có thể phản đối?
Ai cần được cập nhật thường xuyên?
=> Một yêu cầu đúng về mặt logic nhưng sai stakeholder cũng có thể khiến dự án thất bại.
2️⃣ Vì sao Stakeholder Management quan trọng với BA?
Vì BA đứng giữa nhiều nhóm người có mục tiêu khác nhau.
Ví dụ trong một dự án E-commerce:
Business muốn tăng doanh thu
User muốn checkout nhanh
Dev muốn scope rõ
QA muốn AC test được
CSKH muốn giảm ticket khiếu nại
Finance muốn đối soát đúng tiền
Nếu BA chỉ nghe một bên, requirement rất dễ lệch.
=> BA giỏi không chỉ hỏi “anh/chị muốn gì?”
=> BA giỏi hỏi “yêu cầu này ảnh hưởng tới ai, và ai cần đồng thuận?”
3️⃣ 5 lỗi BA mới hay mắc khi làm việc với stakeholder
❌ Lỗi 1: Chỉ nghe người nói to nhất
Trong cuộc họp, thường sẽ có người nói nhiều, nói mạnh, có chức vụ cao.
BA mới rất dễ nghĩ:
“Người này nói vậy chắc là đúng.”
Nhưng thực tế, người hiểu quy trình nhất đôi khi lại là người vận hành hằng ngày, CSKH, kế toán, QA hoặc user thật.
✅ Cách xử lý:
Đừng chỉ hỏi người quyết định.
Hãy xác minh thêm với người thực thi.
Câu hỏi nên dùng:
“Ai là người trực tiếp dùng hoặc xử lý bước này hằng ngày?”
“Mình có cần confirm thêm với team vận hành không?”
❌ Lỗi 2: Không phân biệt decision-maker và user thật
Người duyệt yêu cầu chưa chắc là người dùng hệ thống.
Ví dụ:
Manager muốn dashboard nhiều chỉ số
Nhưng nhân viên vận hành chỉ cần 3 field để xử lý nhanh
Nếu BA không phân biệt, sản phẩm có thể “đẹp với sếp” nhưng “khó dùng với user thật”.
✅ Cách xử lý:
Luôn tách rõ:
Decision-maker: người phê duyệt
End-user: người dùng thật
Influencer: người ảnh hưởng quyết định
Subject Matter Expert: người hiểu nghiệp vụ sâu
=> Mỗi nhóm cần câu hỏi khác nhau.
❌ Lỗi 3: Họp xong không follow-up
Đây là lỗi rất phổ biến.
BA họp xong, ghi chú đầy đủ, nhưng không gửi recap.
Một tuần sau, stakeholder nói:
“Anh đâu có nhớ là đã chốt vậy?”
✅ Cách xử lý:
Sau mỗi buổi họp, gửi recap ngắn:
Những điểm đã thống nhất
Những điểm còn mở
Ai chịu trách nhiệm phần nào
Deadline confirm
In-scope / Out-of-scope nếu có
Ví dụ:
Hi team,
Sau buổi trao đổi hôm nay, em recap lại:
1. Đã thống nhất:
- User có thể thanh toán bằng ví điện tử.
- Payment timeout sau 60s sẽ hiển thị trạng thái Processing.
2. Cần confirm thêm:
- Có cho retry payment không?
- Retry tối đa mấy lần?
3. Owner:
- Anh A confirm business rule retry trước 17h ngày mai.
=> Recap không phải hình thức.
Recap là “bảo hiểm” cho BA.
❌ Lỗi 4: Không quản lý kỳ vọng
Stakeholder thường nói:
“Cái này đơn giản mà.”
“Thêm cái này chắc nhanh thôi.”
“Làm luôn trong phase này nhé.”
BA mới hay gật đầu vì ngại từ chối.
Nhưng sau đó:
Dev báo effort lớn
QA cần test regression
Deadline bị ảnh hưởng
Scope phình ra
✅ Cách xử lý:
BA không nên nói “không làm được” ngay.
Hãy nói theo hướng trade-off:
“Mình có thể làm, nhưng cần đánh giá impact. Nếu đưa vào phase này, mình cần xem phần nào sẽ bị lùi hoặc scope nào cần giảm.”
=> Stakeholder Management không phải chiều stakeholder.
Nó là giúp stakeholder hiểu cái giá của quyết định.
❌ Lỗi 5: Không xử lý conflict giữa stakeholder
Trong dự án thật, stakeholder thường không thống nhất.
Ví dụ:
Sales muốn user đăng ký thật nhanh
Compliance muốn xác minh nhiều bước
Product muốn UX mượt
Security muốn kiểm soát rủi ro
Nếu BA chỉ ghi nhận từng ý kiến riêng lẻ, requirement sẽ mâu thuẫn.
✅ Cách xử lý:
BA cần đưa conflict ra ánh sáng bằng câu hỏi:
“Trong trường hợp này, ưu tiên của mình là giảm friction hay tăng bảo mật?”
“Nếu chỉ chọn một, bên mình ưu tiên conversion hay compliance?”
“Ai là người có quyền quyết định cuối cùng cho rule này?”
=> BA không né conflict.
BA giúp team chốt conflict thành decision.
4️⃣ Framework nhanh: Stakeholder Map cho BA mới
Trước khi bắt đầu dự án, hãy lập bảng đơn giản:
StakeholderVai tròMức ảnh hưởngMức quan tâmCần làm gìBusiness OwnerQuyết định mục tiêuCaoCaoCập nhật thường xuyênEnd-userNgười dùng thậtTrung bìnhCaoInterview/observeDev LeadĐánh giá kỹ thuậtCaoTrung bìnhReview requirement sớmQA LeadTest & qualityTrung bìnhCaoChốt AC/edge caseComplianceKiểm soát rủi roCaoTrung bìnhConfirm rule bắt buộc
Chỉ cần bảng này, BA sẽ biết:
Ai cần hỏi?
Ai cần confirm?
Ai cần update?
Ai có thể block dự án?
5️⃣ 7 câu hỏi “cứu mạng” khi làm việc với stakeholder
Newbie BA nên lưu lại 7 câu này:
Ai là người ra quyết định cuối cùng cho yêu cầu này?
Ai là người trực tiếp sử dụng chức năng này?
Nếu không làm yêu cầu này, rủi ro lớn nhất là gì?
Yêu cầu này ảnh hưởng đến team/hệ thống nào khác không?
Có rule nào bắt buộc phải tuân theo không?
Phần nào nằm ngoài scope ở phase này?
Mình đã có thể chốt quyết định này chưa, hay cần thêm ai confirm?
=> Hỏi đúng 7 câu này, bạn sẽ giảm rất nhiều buổi họp vòng.
6️⃣ Dấu hiệu bạn đang quản lý stakeholder tốt
Bạn biết mình đang làm tốt khi:
Stakeholder ít “đổi ý bất ngờ” hơn
Dev/QA ít hỏi lại hơn
Scope rõ hơn
Decision được ghi nhận rõ ràng
Conflict được chốt thay vì treo
Mọi người biết ai chịu trách nhiệm phần nào
BA giỏi không làm cho mọi người luôn đồng ý.
BA giỏi làm cho mọi người hiểu rõ điều gì đã được quyết định và vì sao.
=> Kết
Stakeholder Management là kỹ năng ít được dạy bài bản, nhưng quyết định rất lớn đến thành bại của BA.
Vì cuối cùng, BA không chỉ làm việc với tài liệu.
BA làm việc với con người.
Một requirement tốt không đến từ một buổi hỏi đáp may mắn.
Nó đến từ việc BA biết:
Hỏi đúng người
Chốt đúng lúc
Follow-up rõ ràng
Quản lý kỳ vọng
Và biến mâu thuẫn thành quyết định
=> Nếu bạn là newbie ITBA, hãy học Stakeholder Management càng sớm càng tốt.
Vì trong dự án thật, kỹ năng này có thể quyết định 50% thành bại của bạn.
Trọn bộ kiến thức BA cho người mới bắt đầu + hướng dẫn áp dụng thực hành dự án để ghi vào CV (Quà tặng hơn 30 khóa ở đây):
=> https://www.facebook.com/groups/3514587515337829/posts/3618897148240198/
Đã có kiến thức BA cơ bản thì học các Khóa học chuyên sâu về các domain cùng case study thực tế: Bảo hiểm - ERP - Banking - E-commerce - Chính Phủ (GOV) - Logistis, tìm hiểu tại đây:
https://www.facebook.com/groups/3514587515337829/posts/3714548542008391
