Mở đầu — vì sao bài này quan trọng
Khi còn là developer, danh sách "người liên quan" trong công việc của bạn khá ngắn: team lead, vài đồng nghiệp trong squad, có khi thêm một PM. Bạn nhận ticket, code, review, merge, done. Nhưng khi bước sang vai trò BA, bạn đột nhiên đứng giữa một mạng lưới chằng chịt những con người với động cơ, quyền lực và mức độ quan tâm rất khác nhau: sponsor muốn dự án xong sớm để báo cáo lên ban giám đốc, Dev Lead muốn requirement rõ ràng để không phải làm lại, Compliance muốn mọi thứ tuân thủ quy định, còn end-user thì chỉ muốn công cụ dễ dùng. Nếu bạn xử lý sai một trong những người này, dự án có thể trật bánh dù requirement của bạn viết hoàn hảo đến đâu.
Đây chính là điểm nhiều developer mới chuyển sang BA vấp ngã. Tư duy kỹ thuật dạy chúng ta rằng "đúng là đúng" — code chạy hay không chạy. Nhưng trong thế giới stakeholder, một quyết định có thể "đúng về mặt kỹ thuật" mà vẫn thất bại vì bạn không đưa đúng người vào đúng thời điểm, hoặc làm mất lòng một nhân vật có quyền phủ quyết.
Bài này trang bị cho bạn hai công cụ nền tảng của BA chuyên nghiệp: Power-Interest Grid để phân loại stakeholder và quyết định cách "đối nhân xử thế" với từng nhóm, và RACI Matrix để xác định rõ ai làm gì, ai quyết, ai cần được hỏi ý kiến, ai chỉ cần biết thông tin. Đây là kỹ năng "mềm" nhưng có cấu trúc rõ ràng — rất hợp với người có nền kỹ thuật như bạn.
Khái niệm cốt lõi
Stakeholder là ai?
Theo BABOK v3, stakeholder là bất kỳ cá nhân hay nhóm nào có quan hệ với sự thay đổi, nhu cầu, hoặc giải pháp mà bạn đang làm việc. Họ có thể bị ảnh hưởng bởi dự án, có khả năng ảnh hưởng đến dự án, hoặc cả hai. Lưu ý: stakeholder không chỉ là người "ngồi họp với bạn". Một trưởng phòng vận hành không bao giờ xuất hiện trong sprint review nhưng có quyền chặn go-live vẫn là stakeholder cực kỳ quan trọng.
Một thói quen tốt là phân stakeholder thành ba vòng:
- Vòng trong (core): trực tiếp tham gia hằng ngày — Dev Lead, QA Lead, Product Owner.
- Vòng giữa (influencing): không làm hằng ngày nhưng có quyền quyết hoặc phê duyệt — Sponsor, trưởng phòng nghiệp vụ, Compliance.
- Vòng ngoài (peripheral): bị ảnh hưởng nhưng ít quyền lực trực tiếp — end-user, bộ phận chăm sóc khách hàng, đối tác tích hợp.
Power-Interest Grid (Lưới Quyền lực — Quan tâm)
Đây là công cụ phân loại stakeholder theo hai trục:
- Power (Quyền lực): khả năng của họ tác động đến số phận dự án — phê duyệt ngân sách, phủ quyết, điều phối nguồn lực.
- Interest (Mức độ quan tâm): họ quan tâm đến kết quả dự án đến đâu, dự án ảnh hưởng đến công việc của họ nhiều hay ít.
| Interest THẤP | Interest CAO | |
|---|---|---|
| Power CAO | Keep Satisfied (Giữ hài lòng) | Manage Closely (Quản lý sát sao) |
| Power THẤP | Monitor (Theo dõi) | Keep Informed (Cập nhật thông tin) |
- Manage Closely: nhóm quan trọng nhất. Sponsor, Product Owner. Cần họp đều, báo cáo chi tiết, lấy ý kiến trước mọi quyết định lớn.
- Keep Satisfied: quyền cao nhưng chưa quan tâm nhiều — ví dụ một giám đốc khối có thể can thiệp nếu thấy rủi ro. Đừng làm phiền họ bằng tiểu tiết, nhưng phải báo cáo gọn, đúng lúc để họ không "bất ngờ phật ý". Sai lầm phổ biến là bỏ quên nhóm này cho đến khi họ nổi giận.
- Keep Informed: quan tâm cao nhưng ít quyền — end-user, đội support. Họ là nguồn requirement và feedback vàng. Cập nhật đều, lắng nghe, vì họ là "đại sứ" lan tỏa sự ủng hộ hoặc phản đối trong tổ chức.
- Monitor: ít quyền, ít quan tâm. Theo dõi nhẹ nhàng, không tốn quá nhiều công sức, nhưng vẫn để mắt vì vị trí của họ có thể thay đổi.
RACI Matrix (Ma trận trách nhiệm)
Power-Interest cho bạn biết "đối xử thế nào", còn RACI cho bạn biết "ai chịu trách nhiệm gì cho từng hoạt động". RACI là viết tắt của:
- R — Responsible (Người thực hiện): người trực tiếp làm công việc. Có thể có nhiều R cho một hoạt động.
- A — Accountable (Người chịu trách nhiệm cuối cùng): người ký duyệt, người chịu trách nhiệm thành bại. Mỗi hoạt động chỉ được có ĐÚNG MỘT chữ A — đây là quy tắc vàng. Nhiều A nghĩa là không ai thực sự chịu trách nhiệm.
- C — Consulted (Người được tham vấn): người được hỏi ý kiến TRƯỚC khi làm, trao đổi hai chiều.
- I — Informed (Người được thông báo): người được báo kết quả SAU khi xong, một chiều.
Ví dụ một RACI Matrix điển hình cho dự án phần mềm:
| Hoạt động | Sponsor | BA | Dev Lead | QA Lead | Ops | Compliance |
|---|---|---|---|---|---|---|
| Phê duyệt phạm vi dự án | A | R | C | I | I | C |
| Thu thập & viết requirement | I | A/R | C | C | C | C |
| Thiết kế giải pháp kỹ thuật | I | C | A/R | C | C | I |
| Lập kế hoạch & thực thi test | I | C | C | A/R | I | C |
| Phê duyệt go-live | A | R | C | C | C | C |
| Vận hành & hỗ trợ sau go-live | I | C | C | I | A/R | I |
Tình huống thực tế
Tình huống 1: Dự án ví điện tử tại một fintech ở TP.HCM
Một fintech (gọi là MoMoPay để dễ hình dung, tình huống giả định) triển khai tính năng "chia hóa đơn" cho ví điện tử. Hùng — một developer 4 năm kinh nghiệm vừa chuyển sang BA — phụ trách requirement. Anh tập trung toàn bộ thời gian làm việc với Dev Lead và Product Owner vì đó là những người anh quen từ thời còn code. Sau 6 tuần, requirement gần xong, anh tự tin trình bày trong buổi review.
Đúng lúc đó, trưởng phòng Risk & Compliance xuất hiện và đặt câu hỏi: "Tính năng này có lưu lại lịch sử ai nợ ai không? Theo quy định của Ngân hàng Nhà nước về phòng chống rửa tiền, mọi giao dịch chia tiền trên 20 triệu cần có cảnh báo và lưu vết." Cả phòng im lặng. Hùng đã không xếp Compliance vào nhóm "Keep Satisfied / Consulted", và giờ phải làm lại một phần lớn requirement, trễ 3 tuần.
Bài học: Trong fintech, banking, healthcare — Compliance luôn ở ô "Power cao". Dù họ không quan tâm tiểu tiết hằng ngày (Interest thấp ban đầu), họ có quyền phủ quyết go-live. Phải đưa họ vào RACI ở vai trò Consulted ngay từ giai đoạn elicitation, không đợi đến review.
Tình huống 2: Hai người cùng nghĩ mình là "người quyết" tại một công ty logistics
Một công ty logistics ở Bình Dương (giả định) làm hệ thống quản lý kho mới. Linh — BA từ nền dev — vẽ RACI nhưng để hai chữ A cho hoạt động "Phê duyệt thiết kế quy trình kho": một A cho Giám đốc Vận hành, một A cho Giám đốc Công nghệ. Cô nghĩ làm vậy cho "công bằng".
Hậu quả: khi cần chốt quy trình nhập kho, Giám đốc Vận hành duyệt phương án A, Giám đốc Công nghệ duyệt phương án B. Hai người không ai chịu nhường, mỗi người nghĩ mình có quyền quyết cuối. Dự án treo 2 tuần chỉ vì một quyết định lẽ ra mất 1 buổi. Cuối cùng Linh phải đưa lên Sponsor để phân định: Vận hành là Accountable (vì kho là nghiệp vụ của họ), Công nghệ chuyển thành Consulted.
Bài học: Quy tắc "một A duy nhất" không phải lý thuyết suông. Khi bạn thấy mình muốn ghi hai chữ A, đó là tín hiệu bạn chưa làm rõ ai thực sự là chủ của quyết định. Hãy đẩy câu hỏi đó lên cấp cao hơn để chốt, đừng né tránh.
Tình huống 3: Bỏ quên "Keep Informed" tại một startup edtech
Một startup edtech ở Hà Nội (giả định) làm tính năng chấm điểm tự động cho giáo viên. Team tập trung vào Sponsor và Dev, ra mắt đúng hạn, kỹ thuật hoàn hảo. Nhưng họ quên mất nhóm giáo viên thực tế dùng sản phẩm — nhóm Interest cao, Power thấp, đáng lẽ phải "Keep Informed" và thu thập feedback liên tục.
Kết quả: tính năng yêu cầu giáo viên nhập đáp án theo định dạng cứng nhắc mà không ai hỏi họ trước. Sau 2 tuần, chỉ 12% giáo viên dùng. Đội support nhận hơn 300 ticket phàn nàn. Sản phẩm "đúng" nhưng vô dụng vì BA bỏ quên nhóm đại sứ người dùng.
Bài học: Nhóm "Keep Informed" tuy ít quyền nhưng quyết định sự sống còn của giải pháp ở khâu adoption. Đừng đánh đồng "ít quyền lực" với "không quan trọng".
Hướng dẫn từng bước
Bước 1 — Lập danh sách stakeholder (Stakeholder list). Brainstorm tất cả cá nhân/nhóm liên quan. Tự hỏi: Ai dùng giải pháp? Ai phê duyệt ngân sách? Ai bị ảnh hưởng quy trình? Ai có quyền chặn? Ai cung cấp dữ liệu/hệ thống bạn cần tích hợp? Đừng bỏ sót vòng ngoài.
Bước 2 — Chấm điểm Power và Interest. Với mỗi stakeholder, cho điểm Power (1–5) và Interest (1–5). Đặt họ lên lưới 2x2. Dùng dữ liệu thật, không đoán theo chức danh — đôi khi một chuyên viên nghiệp vụ kỳ cựu có Power thực tế cao hơn cấp quản lý mới.
Bước 3 — Xác định chiến lược cho từng ô. Manage Closely / Keep Satisfied / Keep Informed / Monitor. Ghi rõ tần suất giao tiếp, kênh giao tiếp (họp, email, báo cáo), và mức độ chi tiết phù hợp cho từng nhóm.
Bước 4 — Liệt kê các hoạt động/quyết định chính của dự án. Đây là các dòng của RACI: phê duyệt scope, viết requirement, thiết kế, test, go-live, vận hành...
Bước 5 — Điền RACI cho từng hoạt động. Quy tắc kiểm tra: mỗi dòng có ĐÚNG một A; mỗi dòng có ít nhất một R; tránh để một người vừa là C vừa là I cho cùng một việc; tránh một dòng quá nhiều C (sẽ làm chậm quyết định).
Bước 6 — Validate với chính stakeholder. Đưa RACI cho các nhân vật chủ chốt xác nhận: "Anh có đồng ý mình là người duyệt cuối khâu này không?" Đây là bước nhiều BA bỏ qua, nhưng nó tránh được tình huống 2 ở trên.
Bước 7 — Cập nhật định kỳ. Mỗi cột mốc lớn (đầu sprint quan trọng, trước go-live), rà lại cả Power-Interest Grid lẫn RACI. Stakeholder mới xuất hiện, vai trò thay đổi — tài liệu phải sống.
Lỗi thường gặp & mẹo
Lỗi 1: Coi stakeholder analysis là việc làm một lần rồi cất tủ. Đây là lỗi tư duy "tài liệu chết". Hãy coi nó như một file config được version control — cập nhật khi context thay đổi.
Lỗi 2: Để nhiều chữ A. Như tình huống 2. Một A duy nhất cho mỗi hoạt động. Không có ngoại lệ.
Lỗi 3: Nhầm Consulted với Informed. Consulted là trao đổi hai chiều, trước khi làm; Informed là thông báo một chiều, sau khi xong. Để Compliance vào "Informed" thay vì "Consulted" là công thức dẫn tới làm lại.
Lỗi 4: Dồn quá nhiều C vào một hoạt động. Nếu một quyết định cần tham vấn 6 người, nó sẽ tê liệt. Cân nhắc kỹ ai THẬT SỰ cần được hỏi.
Lỗi 5 (rất phổ biến với dev mới chuyển): chỉ giao tiếp với người mình thấy thoải mái. Dev cũ thường thân với Dev Lead, QA, và né các cuộc trò chuyện với nhân vật nghiệp vụ/quản lý. Tình huống 1 và 3 đều xuất phát từ đây. Hãy ý thức và chủ động bước ra khỏi vùng an toàn kỹ thuật.
Mẹo 1: Kết hợp hai công cụ — Power-Interest cho bạn biết tần suất và cách giao tiếp, RACI cho bạn biết nội dung trách nhiệm. Một stakeholder "Manage Closely" trên lưới thường là người mang chữ A hoặc C trong RACI.
Mẹo 2: Với nhóm "Keep Satisfied" (quyền cao, quan tâm thấp), gửi báo cáo một trang, dạng dashboard, tập trung vào rủi ro và mốc lớn. Đừng gửi cho họ chi tiết user story.
Mẹo 3: Lưu stakeholder analysis ngay trong Confluence/Notion của dự án, gắn link trong mọi tài liệu requirement, để cả team cùng tham chiếu.
Bài tập thực hành
Hãy chọn một dự án bạn từng tham gia (thời còn làm dev cũng được) và làm các việc sau:
- Liệt kê tối thiểu 8 stakeholder, bao gồm cả những người bạn ít tiếp xúc (nghiệp vụ, vận hành, tuân thủ, end-user).
- Vẽ Power-Interest Grid đặt 8 người này vào 4 ô. Với mỗi ô, viết một câu chiến lược giao tiếp (tần suất + kênh + mức chi tiết).
- Xây RACI Matrix với ít nhất 6 hoạt động (phê duyệt scope, viết requirement, thiết kế, test, go-live, vận hành). Tự kiểm tra: mỗi dòng đúng một A? Mỗi dòng có R? Có dòng nào quá nhiều C không?
- Tự phản biện: Có stakeholder nào bạn từng vô tình bỏ quên trong dự án thật không? Nếu phân tích lại từ đầu, bạn sẽ đưa họ vào ô nào, vai trò RACI nào? Viết một đoạn ngắn rút kinh nghiệm.
Tóm tắt
Stakeholder Analysis là kỹ năng tách biệt một BA chuyên nghiệp với một người chỉ biết viết requirement. Hai công cụ cốt lõi:
- Power-Interest Grid phân loại stakeholder theo quyền lực và mức độ quan tâm, từ đó quyết định chiến lược giao tiếp: Manage Closely, Keep Satisfied, Keep Informed, Monitor. Nhớ rằng vị trí stakeholder thay đổi theo giai đoạn dự án.
- RACI Matrix làm rõ ai Responsible, ai Accountable (chỉ một người duy nhất), ai Consulted, ai Informed cho từng hoạt động. Đây là bản đồ trách nhiệm tránh tình trạng "tưởng người kia làm".