Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Designer, chắc chắn bạn đã yêu empathy map. Đó là công cụ đẹp, gọn, giúp bạn đặt mình vào vị trí người dùng: họ nghĩ gì, cảm thấy gì, nhìn thấy gì, làm gì. Empathy map là "vũ khí" khiến các buổi workshop design trở nên sống động và khiến team đồng cảm với end-user.
Nhưng khi bạn bước sang vai trò BA (Business Analyst), có một sự thật hơi phũ phàng bạn cần chấp nhận sớm: end-user không phải là người duy nhất bạn phải làm hài lòng, và thường không phải là người quyết định dự án sống hay chết. Người ký duyệt ngân sách, ông trưởng phòng vận hành sợ thay đổi quy trình, anh trưởng nhóm dev lo về technical debt, chị kế toán cần đối soát, bên compliance sợ rủi ro pháp lý — tất cả họ đều là "bên liên quan" (stakeholder), và mỗi người có quyền lực, lợi ích, nỗi lo khác nhau. Một feature tuyệt vời cho end-user hoàn toàn có thể chết yểu vì bạn quên mất anh trưởng phòng vận hành, người có quyền phủ quyết.
Đây chính là lý do bài học này quan trọng. Empathy map dạy bạn đồng cảm với một người. Stakeholder analysis matrix dạy bạn quản lý mọi người — một cách có hệ thống, có chiến lược. Với một ex-Designer, đây không phải là học lại từ đầu, mà là một cú "nâng cấp phần cứng": bạn giữ lại năng lực thấu cảm vốn có, nhưng mở rộng nó ra toàn bộ mạng lưới những người ảnh hưởng đến dự án. Nắm được kỹ năng này, bạn chuyển từ "người vẽ giải pháp" sang "người điều phối kỳ vọng" — và đó là ranh giới thật sự giữa Designer và BA.
Khái niệm cốt lõi
Stakeholder là ai, và tại sao nhiều hơn bạn tưởng
Stakeholder là bất kỳ cá nhân hay nhóm nào bị ảnh hưởng bởi hoặc có ảnh hưởng đến dự án/giải pháp của bạn. Định nghĩa này rộng một cách có chủ đích. Trong tư duy Design, bạn quen chia người dùng thành persona. Trong tư duy BA, bạn phải nghĩ theo lớp:
- Người dùng trực tiếp (end-user): người thao tác trên sản phẩm — cái mà empathy map của bạn thường tập trung.
- Người mua/ký duyệt (sponsor, budget holder): người trả tiền, có thể chẳng bao giờ dùng sản phẩm.
- Người vận hành/hỗ trợ: đội chăm sóc khách hàng, vận hành, IT support — những người "sống chung" với sản phẩm sau khi ra mắt.
- Người kiểm soát: legal, compliance, security, kế toán — thường xuất hiện muộn và có quyền phanh gấp.
- Đội thực thi: dev, QA, UX, DevOps — những người biến requirement thành hiện thực.
- Bên ngoài: đối tác tích hợp, nhà cung cấp thanh toán, cơ quan quản lý (ví dụ Ngân hàng Nhà nước với sản phẩm fintech).
Empathy map và stakeholder matrix bổ sung nhau như thế nào
Đừng nghĩ bạn phải vứt empathy map đi. Hãy hình dung mối quan hệ thế này:
- Stakeholder analysis là bản đồ toàn cảnh — liệt kê mọi bên, định vị họ theo quyền lực và lợi ích.
- Empathy map là kính lúp — dùng để đào sâu vào một stakeholder quan trọng cụ thể khi bạn cần hiểu động cơ của họ.
Power/Interest Grid — ma trận nền tảng
Công cụ kinh điển nhất là Power/Interest Grid (còn gọi là ma trận Mendelow), chia stakeholder theo hai trục:
- Power (Quyền lực): khả năng tác động đến quyết định, ngân sách, hoặc phanh dự án.
- Interest (Mức độ quan tâm): mức độ họ bị ảnh hưởng bởi kết quả và độ chú ý họ dành cho dự án.
| Interest thấp | Interest cao | |
|---|---|---|
| Power cao | Keep Satisfied (giữ hài lòng) | Manage Closely (quản lý sát) |
| Power thấp | Monitor (theo dõi) | Keep Informed (giữ thông tin) |
- Manage Closely: nhóm ưu tiên số một — họp thường xuyên, xin ý kiến, mời vào quyết định lớn.
- Keep Satisfied: quyền lực lớn nhưng chưa quan tâm — đừng làm phiền quá nhiều, nhưng phải đảm bảo họ luôn hài lòng để họ không bất ngờ phản đối.
- Keep Informed: quan tâm cao nhưng ít quyền lực — thường là end-user, đội vận hành; giữ họ được cập nhật để có đồng minh.
- Monitor: theo dõi nhẹ, không tốn nhiều công.
RACI — bổ sung chiều "vai trò"
Power/Interest cho biết cách đối xử, nhưng chưa nói ai chịu trách nhiệm gì. Đó là lúc dùng RACI:
- R (Responsible): người trực tiếp làm.
- A (Accountable): người chịu trách nhiệm cuối cùng, ký duyệt (chỉ một người cho mỗi việc).
- C (Consulted): người được hỏi ý kiến hai chiều.
- I (Informed): người được thông báo một chiều.
Tình huống thực tế
Ví dụ 1 — Startup fintech VN: khi end-user không phải người quyết định
Một startup ví điện tử tại TP.HCM (giả định tên "PayVio", quy mô ~40 người) muốn thêm tính năng "chia hóa đơn nhóm" (split bill). Bạn là BA vừa từ Designer chuyển sang. Theo bản năng Design cũ, bạn vẽ ngay empathy map cho persona "sinh viên đi ăn nhóm" — họ muốn chia tiền nhanh, không muốn tính toán thủ công.
Nhưng khi làm stakeholder analysis, bức tranh mở rộng hẳn:
- Giám đốc Sản phẩm (Power cao, Interest cao → Manage Closely): lo tính năng này có kéo được số giao dịch không.
- Trưởng nhóm Compliance (Power cao, Interest ban đầu thấp → Keep Satisfied): khi biết tính năng liên quan chuyển tiền giữa các cá nhân, đột nhiên Interest tăng vọt vì lo ngại rủi ro rửa tiền (AML) và hạn mức giao dịch theo quy định.
- Đội Vận hành/CSKH (Power thấp, Interest cao → Keep Informed): họ sẽ nhận hàng loạt câu hỏi "sao tiền chưa vào" nếu luồng xử lý chậm.
- Đối tác ngân hàng tích hợp (Power cao, bên ngoài): giới hạn số lần gọi API mỗi giây.
Ví dụ 2 — Agency TP.HCM: mâu thuẫn giữa client và end-user
Một agency phần mềm ở Hà Nội nhận dự án xây app đặt lịch khám cho một chuỗi phòng khám tư nhân. BA (ex-UX Designer) làm empathy map cho bệnh nhân lớn tuổi: họ cần giao diện đơn giản, chữ to, ít bước.
Nhưng stakeholder analysis lộ ra một mâu thuẫn kinh điển:
- Chủ chuỗi phòng khám (nhà tài trợ, Power cực cao): muốn thu thập tối đa thông tin bệnh nhân để làm marketing → yêu cầu form đăng ký dài, nhiều trường bắt buộc.
- Bệnh nhân lớn tuổi (end-user, Power thấp nhưng Interest cao): form dài khiến họ bỏ cuộc giữa chừng.
- Lễ tân phòng khám (người vận hành, Power thấp): họ mới là người nhập liệu thay bệnh nhân qua điện thoại, nên trải nghiệm thật khác hoàn toàn giả định ban đầu.
Bài học: Stakeholder analysis giúp BA nhận ra "người dùng thật" của giao diện nhập liệu là lễ tân, không phải bệnh nhân — một insight mà empathy map một-persona không bao giờ chỉ ra. BA dùng matrix để làm rõ với chủ phòng khám: "Nếu ưu tiên marketing, chúng ta đánh mất lễ tân — người tạo ra 60% booking." Đây là lúc dữ liệu và ma trận stakeholder biến một cuộc tranh luận cảm tính thành quyết định có cơ sở.
Ví dụ 3 — Dự án nội bộ ngân hàng: sức mạnh của RACI
Tại một ngân hàng lớn ở Việt Nam, đội chuyển đổi số muốn số hóa quy trình phê duyệt tín dụng. Có tới 8 phòng ban liên quan. Vấn đề không phải là "ai quan tâm" mà là "ai được quyền quyết cái gì" — mọi cuộc họp đều rơi vào tình trạng ai cũng có ý kiến nhưng không ai chốt.
BA lập một bảng RACI cho từng nhóm quyết định:
- Quy tắc phê duyệt tín dụng: Phòng Rủi ro là A, Phòng Tín dụng là C, IT là I.
- Giao diện màn hình phê duyệt: BA là R, Trưởng phòng Vận hành là A, end-user (chuyên viên tín dụng) là C.
- Tích hợp core banking: IT là A/R, BA là C.
Hướng dẫn từng bước
Đây là quy trình thực hành để chuyển từ tư duy empathy map sang stakeholder analysis matrix hoàn chỉnh.
Bước 1 — Brainstorm danh sách stakeholder (đừng lọc vội). Dùng chính kỹ năng workshop của Designer: mời team, dán sticky note, liệt kê mọi bên có thể liên quan. Đặt câu hỏi kích thích: "Ai trả tiền? Ai dùng? Ai vận hành sau khi ra mắt? Ai có thể nói KHÔNG? Ai ở bên ngoài công ty?" Mục tiêu ở bước này là bao phủ, không phải chính xác.
Bước 2 — Nhóm và loại trùng. Gộp các cá nhân thành nhóm vai trò (ví dụ "5 chuyên viên tín dụng" → nhóm "End-user tín dụng"). Ghi rõ tên người đại diện cho mỗi nhóm để sau này còn biết liên hệ ai.
Bước 3 — Đánh giá Power và Interest. Với mỗi stakeholder, cho điểm Power (1–5) và Interest (1–5). Đừng làm một mình — hãy hỏi PM, hỏi người đã làm dự án tương tự. Lưu ý: Interest có thể thay đổi theo thời gian (như Compliance trong ví dụ PayVio), nên đây là tài liệu sống.
Bước 4 — Đặt lên Power/Interest Grid. Vẽ lưới 2×2, đặt từng stakeholder vào ô tương ứng. Với nhóm "Manage Closely", cân nhắc vẽ thêm empathy map riêng để hiểu sâu động cơ — đây là chỗ kỹ năng Designer của bạn tỏa sáng.
Bước 5 — Gán chiến lược engagement cho từng ô. Ghi rõ: tần suất giao tiếp, kênh (họp 1-1, email, báo cáo tuần), thông điệp chính. Ví dụ: "Trưởng phòng Vận hành — họp 1-1 mỗi tuần, tập trung vào rủi ro quy trình."
Bước 6 — Bổ sung RACI cho các quyết định then chốt. Với những quyết định dễ gây tranh cãi, lập bảng RACI để làm rõ ai R/A/C/I. Nhớ nguyên tắc: mỗi việc chỉ có một chữ A.
Bước 7 — Rà soát định kỳ. Stakeholder analysis không phải làm một lần rồi cất. Rà lại ở mỗi mốc lớn của dự án, vì quyền lực và lợi ích dịch chuyển liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn end-user (di chứng của tư duy Designer.) Đây là bẫy phổ biến nhất với ex-Designer. Bạn quá quen đặt end-user làm trung tâm nên quên rằng sponsor và người kiểm soát mới thường quyết định dự án. Mẹo: Sau khi liệt kê stakeholder, tự hỏi "Ai có thể giết dự án này?" — người đó gần như chắc chắn nằm ngoài empathy map của bạn.
Lỗi 2 — Nhầm "người ồn ào nhất" với "người quyền lực nhất." Người nói nhiều trong họp chưa chắc có quyền quyết. Mẹo: Tách bạch Power (quyền quyết thật sự) khỏi Interest (mức độ ồn ào, quan tâm).
Lỗi 3 — Coi matrix là tài liệu tĩnh. Nhiều BA làm xong rồi để đó. Interest của Compliance, Legal thường tăng vọt khi dự án chạm vào rủi ro. Mẹo: Đặt lịch rà soát ở mỗi milestone.
Lỗi 4 — Bỏ quên "stakeholder ẩn." Đội vận hành, CSKH, lễ tân — những người "sống chung" với sản phẩm sau go-live — thường bị bỏ sót vì họ không xuất hiện trong giai đoạn thiết kế. Mẹo: Luôn hỏi "Sau khi ra mắt, AI phải xử lý hậu quả hằng ngày?"
Lỗi 5 — Chia sẻ matrix công khai một cách ngây thơ. Bảng ghi "ông A: Power cao, cần quản lý sát vì hay phản đối" mà lọt vào tay ông A thì rất tế nhị. Mẹo: Stakeholder analysis là tài liệu nội bộ của BA và PM, không dán lên Confluence công khai.
Mẹo tận dụng nền Design: Kỹ năng visualize và facilitate workshop của bạn là lợi thế lớn. Buổi lập stakeholder map có thể chạy y như một buổi affinity mapping — sticky note, phân nhóm, thảo luận. Bạn đã có sẵn "cơ bắp" này, chỉ cần đổi đối tượng từ user insight sang stakeholder.
Bài tập thực hành
Chọn một dự án bạn từng tham gia (hoặc một dự án giả định: "app giao đồ ăn cho một chuỗi bún bò ở Huế").
- Liệt kê tối thiểu 8 stakeholder thuộc ít nhất 4 lớp khác nhau (end-user, sponsor, vận hành, kiểm soát, thực thi, bên ngoài). Với mỗi người, ghi một câu về lợi ích và nỗi lo của họ.
- Cho điểm Power và Interest (1–5) cho từng stakeholder, rồi đặt tất cả lên một Power/Interest Grid 2×2. Ghi chiến lược engagement cho mỗi ô.
- Chọn một stakeholder ở ô "Manage Closely" và vẽ một empathy map đầy đủ (Think / Feel / See / Do) cho họ. So sánh: empathy map này khác gì so với empathy map bạn từng vẽ cho end-user?
- Lập một bảng RACI cho 3 quyết định then chốt của dự án. Đảm bảo mỗi quyết định chỉ có đúng một chữ A.
- Viết một đoạn phản tư ngắn (150–200 từ): trong dự án này, stakeholder nào bạn suýt bỏ sót nếu chỉ dùng tư duy empathy map một-persona? Điều đó nói lên điều gì về sự khác biệt giữa Designer và BA?
Tóm tắt
Empathy map và stakeholder analysis matrix không phải là hai công cụ đối lập — chúng là hai độ phóng đại khác nhau của cùng một năng lực thấu cảm. Empathy map soi sâu vào một người; stakeholder matrix bao quát mọi bên liên quan và định vị họ theo quyền lực và lợi ích.
Với một ex-Designer, cú chuyển dịch cốt lõi là: đừng để end-user che khuất tầm nhìn của bạn về sponsor, người kiểm soát và người vận hành — những người thường mới thực sự quyết định số phận dự án. Dùng Power/Interest Grid để xây chiến lược giao tiếp (Manage Closely, Keep Satisfied, Keep Informed, Monitor), và RACI để làm rõ trách nhiệm ở từng quyết định. Khi cần đào sâu một stakeholder quan trọng, hãy lấy empathy map ra dùng như một kính lúp — đó là lúc kỹ năng Design cũ của bạn trở thành vũ khí, chứ không phải giới hạn.
Cuối cùng, hãy nhớ: stakeholder analysis là tài liệu sống. Quyền lực và lợi ích dịch chuyển theo từng giai đoạn dự án, nhất là khi rủi ro pháp lý hay compliance xuất hiện. BA giỏi không phải người vẽ được matrix đẹp một lần, mà là người liên tục cập nhật nó và hành động đúng theo những gì nó chỉ ra.