Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa chuyển từ Marketing sang BA, được giao dự án đầu tiên: xây tính năng "đặt lịch hẹn" cho một app fitness. Bạn viết user story rất chuẩn, vẽ wireframe đẹp, requirement rõ ràng. Nhưng đến ngày demo, ông Giám đốc Vận hành đứng dậy: "Cái này không ai hỏi ý kiến tôi, mà nó đụng thẳng vào quy trình của trung tâm." Sponsor cau mày. Dev đã code xong một nửa. Dự án trễ ba tuần để làm lại.
Vấn đề ở đây không nằm ở kỹ thuật phân tích. Nó nằm ở chỗ bạn đã bỏ sót một người có quyền lực thực sự, hoặc hiểu sai ai mới là người ra quyết định. Đây chính là lý do Stakeholder Management (quản lý các bên liên quan) được coi là kỹ năng "sống còn" của BA, đôi khi còn quan trọng hơn cả kỹ năng viết tài liệu.
Tin tốt cho người làm Marketing: bạn đã có sẵn một phần cơ bắp này. Khi chạy một campaign, bạn phải làm việc với Brand, Sales, Pháp chế, Agency, Ban giám đốc — mỗi bên một kỳ vọng khác nhau, một mức độ quyền lực khác nhau. Bạn đã biết "đọc vị" ai cần được hỏi ý kiến trước, ai chỉ cần thông báo sau. Bài học này sẽ giúp bạn hệ thống hóa bản năng đó thành hai công cụ chuẩn mực của BA: RACI Matrix và Influence Map (bản đồ ảnh hưởng / Power-Interest Grid).
Khái niệm cốt lõi
Stakeholder là ai, và vì sao phải "quản lý"
Stakeholder là bất kỳ cá nhân hay nhóm nào có ảnh hưởng đến dự án, hoặc bị dự án ảnh hưởng. Họ không chỉ là người trả tiền (sponsor) hay người dùng cuối, mà còn gồm cả những người "tưởng như ngoài lề" nhưng có quyền chặn dự án: đội Pháp chế, Bảo mật, Vận hành, hay thậm chí một trưởng phòng nghiệp vụ có tiếng nói trong nội bộ.
"Quản lý" ở đây không mang nghĩa kiểm soát con người, mà là chủ động điều phối kỳ vọng, thông tin và quyết định sao cho đúng người tham gia đúng việc, đúng lúc. BA là cầu nối — và cầu nối thì phải biết hai bờ sông có ai đứng.
RACI Matrix — ai làm gì trên từng đầu việc
RACI là một bảng phân vai cực kỳ gọn, trả lời câu hỏi: với mỗi hoạt động/quyết định, ai đóng vai trò nào? Bốn chữ cái là bốn vai:
- R — Responsible (Người thực thi): người trực tiếp làm việc đó. Một hoạt động có thể có nhiều R.
- A — Accountable (Người chịu trách nhiệm cuối cùng): người duyệt, người "chốt", người sẽ bị hỏi nếu sai. 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 chỉ cần biết kết quả, trao đổi một chiều.
| Hoạt động | Sponsor (GĐ SP) | BA | Dev Lead | QA Lead | Pháp chế | Vận hành |
|---|---|---|---|---|---|---|
| Duyệt phạm vi & ngân sách | A | R | C | I | C | I |
| Thu thập & viết requirement | A | R | C | C | C | C |
| Thiết kế giải pháp kỹ thuật | I | C | A/R | C | I | I |
| Kiểm thử UAT | I | R | C | A | C | C |
| Duyệt go-live | A | R | C | C | C | C |
Influence Map / Power-Interest Grid — ai đáng dành thời gian
RACI cho bạn biết vai trò trên đầu việc, nhưng không nói cho bạn biết nên đầu tư bao nhiêu công sức giao tiếp với từng người. Đó là việc của Power-Interest Grid (ma trận Quyền lực – Mức độ quan tâm), một dạng Influence Map. Bạn đặt mỗi stakeholder lên một lưới hai trục:
- Trục dọc: Power (quyền lực, khả năng tác động/chặn dự án).
- Trục ngang: Interest (mức độ quan tâm, dự án ảnh hưởng đến họ nhiều không).
- Quyền cao – Quan tâm cao → Manage Closely (Quản lý sát sao): đây là nhóm quan trọng nhất. Họp định kỳ, báo cáo kỹ, lấy ý kiến sớm. Ví dụ: Sponsor, trưởng phòng nghiệp vụ chủ chốt.
- Quyền cao – Quan tâm thấp → Keep Satisfied (Giữ hài lòng): quyền lớn nhưng chưa để tâm. Đừng làm họ khó chịu, báo cáo gọn, đừng "dội bom" thông tin. Ví dụ: một Phó TGĐ tài chính.
- Quyền thấp – Quan tâm cao → Keep Informed (Cập nhật thường xuyên): họ rất quan tâm và có thể là nguồn thông tin nghiệp vụ quý giá. Ví dụ: nhân viên vận hành trực tiếp dùng hệ thống.
- Quyền thấp – Quan tâm thấp → Monitor (Theo dõi): giao tiếp tối thiểu, đừng tốn năng lượng.
Hai công cụ này bổ trợ nhau: Influence Map giúp bạn lên chiến lược giao tiếp; RACI giúp bạn phân vai cụ thể trên từng việc.
Tình huống thực tế
Ví dụ 1 — Tiki: bỏ sót đội Chăm sóc khách hàng
Một BA tại một sàn TMĐT lớn (giả định theo bối cảnh Tiki) phụ trách dự án đổi chính sách hoàn hàng từ 7 ngày lên 30 ngày. Cô lập RACI rất chuẩn cho Sponsor, Dev, QA. Nhưng cô để đội Chăm sóc khách hàng (CSKH) ở vai "I — chỉ thông báo".
Khi tính năng lên production, tổng đài CSKH bị quá tải: khách gọi hỏi dồn dập vì kịch bản trả lời chưa được cập nhật, hệ thống ticket chưa có category mới cho hoàn hàng 30 ngày. Trưởng phòng CSKH — một người có quyền lực nội bộ rất lớn vì trực tiếp đo NPS — gửi email phản ánh lên Ban giám đốc. Dự án bị xem là "thành công kỹ thuật nhưng thất bại vận hành".
Bài học: trên Power-Interest Grid, CSKH đáng lẽ phải nằm ở ô Quyền cao – Quan tâm cao (Manage Closely), và trong RACI họ phải là C — Consulted ở khâu thiết kế quy trình, không phải chỉ I. BA đã đánh giá thấp quyền lực của một phòng ban "tưởng như chỉ nhận lệnh".
Ví dụ 2 — Ngân hàng số: hai chữ "A" gây tê liệt
Một BA tại một ngân hàng số ở TP.HCM làm dự án tích hợp eKYC (định danh điện tử). Trong RACI, ở dòng "Duyệt luồng định danh", anh để cả Giám đốc Sản phẩm và Giám đốc Tuân thủ (Compliance) đều là A. Lý do nghe rất hợp lý: "cả hai đều quan trọng mà."
Hậu quả: khi cần chốt luồng, GĐ Sản phẩm muốn rút gọn bước để tăng tỷ lệ chuyển đổi, GĐ Tuân thủ muốn thêm bước xác minh để an toàn pháp lý. Hai người đùn đẩy, không ai chịu là người quyết định cuối cùng. Quyết định treo 10 ngày, sprint trễ.
BA xử lý bằng cách họp lại và làm rõ: Accountable duy nhất là GĐ Sản phẩm (người sở hữu KPI sản phẩm), còn GĐ Tuân thủ chuyển thành C có quyền phủ quyết về mặt pháp lý (consulted với "veto right"). Tức GĐ Sản phẩm chốt, nhưng không được vi phạm ranh giới Compliance vạch ra. Quyết định thông suốt ngay sau đó.
Bài học: quy tắc "một A duy nhất" không phải lý thuyết suông. Khi vi phạm, dự án sẽ kẹt ở chính khâu cần tốc độ nhất.
Ví dụ 3 — Startup Edtech: dùng Influence Map để "đi đường vòng"
Một BA tại startup edtech (khoảng 40 người) cần thuyết phục founder kiêm CEO đầu tư làm lại hệ thống quản lý lớp học. CEO rất bận, quyền lực tuyệt đối nhưng mức quan tâm tới chủ đề kỹ thuật này lại thấp — nằm ở ô Keep Satisfied. Mọi nỗ lực đặt lịch họp trực tiếp đều bị hoãn.
Khi vẽ Influence Map, BA nhận ra CTO là người CEO tin tưởng tuyệt đối về quyết định công nghệ. Thay vì cố "leo" thẳng lên CEO, BA dành thời gian trình bày dữ liệu với CTO trước: số liệu cho thấy giáo viên mất trung bình 6 giờ/tuần thao tác thủ công vì hệ thống cũ. CTO bị thuyết phục, và chính CTO mang đề xuất lên CEO trong cuộc họp lãnh đạo. Dự án được duyệt trong một buổi.
Bài học: Influence Map không chỉ phân loại stakeholder, nó còn lộ ra đường ảnh hưởng. Đôi khi con đường ngắn nhất tới người ra quyết định lại đi vòng qua người họ tin tưởng.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay từ dự án đầu tiên:
- Lập danh sách stakeholder (brainstorm rộng). Đừng vội lọc. Liệt kê mọi phòng ban, vai trò có thể liên quan: người trả tiền, người dùng, người vận hành, người duyệt, người bị ảnh hưởng gián tiếp. Mẹo từ Marketing: hãy hỏi "ai sẽ phàn nàn nếu việc này làm sai?" — câu này thường lôi ra những stakeholder ẩn.
- Đánh giá Power và Interest cho từng người. Cho điểm Cao/Thấp hai trục, đặt họ lên Power-Interest Grid. Với người ở ranh giới, hãy chọn mức cao hơn để an toàn (thừa cẩn thận hơn thiếu).
- Chọn chiến lược giao tiếp theo từng ô. Manage Closely / Keep Satisfied / Keep Informed / Monitor. Ghi rõ kênh và tần suất: ví dụ "Sponsor — họp 30 phút mỗi sprint"; "Vận hành — bản tin tuần qua email".
- Liệt kê các hoạt động/quyết định chính của dự án theo dòng thời gian: duyệt phạm vi, thu thập requirement, thiết kế, kiểm thử, go-live, đo lường sau go-live.
- Lập RACI: gán R-A-C-I cho từng ô. Kiểm tra hai điều bắt buộc: mỗi dòng có đúng một A; không dòng nào toàn I (nếu chẳng ai làm thì việc đó không xảy ra).
- Xác thực ma trận với chính các stakeholder. Đây là bước hay bị bỏ. Gửi RACI cho Sponsor và các trưởng nhóm xác nhận: "Anh đồng ý mình là người duyệt cuối khâu này chứ?" Việc xác nhận tránh hiểu lầm về quyền hạn sau này.
- Cập nhật liên tục. Stakeholder thay đổi giữa dự án — sếp mới về, phòng ban tái cấu trúc. Coi cả hai bản đồ là tài liệu sống, rà lại mỗi giai đoạn lớn.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Accountable với Responsible. Người mới thường nghĩ "ai làm nhiều nhất là A". Sai. A là người duyệt và chịu trách nhiệm cuối, thường là cấp quản lý; R là người xắn tay làm. BA thường là R, hiếm khi là A.
Lỗi 2 — Để nhiều A trên một dòng. Như ví dụ ngân hàng số, đây là nguyên nhân số một gây tê liệt quyết định. Luôn ép về một A.
Lỗi 3 — "Lạm phát" chữ C. Tham vấn quá nhiều người làm dự án chậm như rùa. Hỏi: người này thật sự cần được hỏi ý kiến trước, hay chỉ cần biết sau? Nếu chỉ cần biết, họ là I.
Lỗi 4 — Đánh giá sai quyền lực vì nhìn chức danh. Quyền lực thực tế (informal power) nhiều khi nằm ở một người không to chức nhưng được sếp tin, hoặc một trưởng nhóm vận hành lâu năm. Người Marketing vốn nhạy với "ai thực sự gật đầu thì campaign mới chạy" — hãy dùng đúng giác quan đó.
Mẹo 1 — Dùng "ngôn ngữ" của từng stakeholder. Với Sponsor nói về ROI và rủi ro; với Dev nói về độ rõ của requirement; với Vận hành nói về tác động quy trình. Đây chính là tư duy "đúng thông điệp cho đúng audience" của Marketing.
Mẹo 2 — Hẹn 1-1 với nhóm Manage Closely sớm. Đừng đợi tới buổi họp chung. Một cốc cà phê 15 phút với trưởng phòng nghiệp vụ trước khi viết requirement giúp bạn tránh hàng tuần làm lại.
Mẹo 3 — Lưu RACI ngay trong tài liệu dự án (Confluence/PRD), không để rời rạc. Khi có tranh cãi về "ai được quyết", bạn chỉ cần mở bảng ra.
Bài tập thực hành
Hãy chọn một dự án giả định: một chuỗi cà phê (giả định: The Coffee House) muốn ra mắt tính năng "tích điểm & đổi quà" trong app. Bạn là BA phụ trách.
- Liệt kê tối thiểu 8 stakeholder (gợi ý: GĐ Marketing, GĐ Vận hành chuỗi, IT/Dev, đội cửa hàng/barista, Tài chính, CSKH, đối tác ví điện tử, khách hàng thành viên). Với mỗi người, ghi một câu họ "quan tâm điều gì nhất".
- Vẽ Power-Interest Grid đặt 8 stakeholder vào 4 ô. Giải thích ngắn vì sao bạn xếp đội barista vào ô nào — họ quyền thấp nhưng là người trực tiếp thao tác tích điểm tại quầy.
- Lập RACI cho 5 hoạt động: duyệt phạm vi, viết requirement, thiết kế cơ chế tích điểm, kiểm thử UAT tại cửa hàng mẫu, duyệt go-live. Đảm bảo mỗi dòng đúng một A.
- Tình huống xử lý: GĐ Marketing (Sponsor, A khâu duyệt) muốn go-live trước Tết, nhưng Tài chính (C) cảnh báo cơ chế đổi quà có thể lỗ nếu không giới hạn. Dựa trên RACI và Influence Map, bạn sẽ điều phối quyết định này thế nào? Viết 4–5 câu.
Tóm tắt
Stakeholder Management là kỹ năng giúp BA biến một requirement đúng kỹ thuật thành một dự án thật sự thành công. Hai công cụ cốt lõi:
- RACI Matrix phân vai trên từng đầu việc: Responsible (làm), Accountable (chốt — duy nhất một người), Consulted (hỏi ý kiến trước), Informed (báo sau).
- Influence Map / Power-Interest Grid quyết định bạn đầu tư giao tiếp vào ai: Manage Closely, Keep Satisfied, Keep Informed, Monitor — và lộ ra đường ảnh hưởng giữa các bên.
Người từ Marketing có lợi thế tự nhiên ở bài này: bạn đã quen "đọc vị" các bên, dùng đúng thông điệp cho đúng người, và biết ai mới thực sự gật đầu để mọi thứ chạy. Hãy hệ thống hóa bản năng đó bằng RACI và Influence Map — đó là lúc bạn tư duy như một BA thực thụ.