Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao dự án BA đầu tiên: xây một tính năng đặt lịch hẹn cho một phòng khám. Bạn hăng hái đi phỏng vấn bác sĩ, viết một tài liệu yêu cầu thật đẹp, trình lên. Rồi đến ngày demo, chị kế toán trưởng đứng dậy nói: "Nhưng tính năng này làm sao khớp với quy trình thu phí của chúng tôi? Sao không ai hỏi tôi cả?". Dự án đứng hình. Toàn bộ phần liên quan tới thanh toán phải làm lại.
Bạn không sai vì viết tài liệu dở. Bạn sai vì đã bỏ sót một stakeholder quan trọng ngay từ đầu.
Đây chính là lý do stakeholder mapping — lập bản đồ các bên liên quan — là một trong những kỹ năng đầu tiên mà một BA Junior phải nắm chắc. Nó không hào nhoáng như viết user story hay vẽ BPMN, nhưng nó quyết định việc bạn có thu thập yêu cầu đúng người, đúng lúc, đúng cách hay không. Trong bài này, tôi sẽ hướng dẫn bạn cách nhận diện, phân loại và lên chiến lược làm việc với từng nhóm stakeholder — bằng đúng những công cụ mà BA chuyên nghiệp dùng, nhưng được diễn giải cho người mới bắt đầu.
Khái niệm cốt lõi
Stakeholder là ai?
Định nghĩa ngắn gọn nhất: stakeholder là bất cứ ai bị ảnh hưởng bởi hoặc có ảnh hưởng đến dự án của bạn.
Nghe thì đơn giản, nhưng chữ "bất cứ ai" mới là chỗ khiến người mới sảy chân. Rất nhiều BA Junior chỉ nghĩ đến những người họ nhìn thấy trong các buổi họp: khách hàng, sếp, dev, tester. Nhưng stakeholder rộng hơn nhiều. Nó bao gồm cả những người "vô hình":
- Người bị ảnh hưởng nhưng không ngồi trong phòng họp — ví dụ nhân viên tổng đài sẽ phải dùng hệ thống mới mỗi ngày.
- Người có quyền phủ quyết nhưng ít xuất hiện — ví dụ trưởng phòng bảo mật, phòng pháp chế, phòng tài chính.
- Người ở bên ngoài tổ chức — cơ quan quản lý nhà nước, đối tác tích hợp API, nhà cung cấp cổng thanh toán.
- Internal (nội bộ): ban lãnh đạo, product owner, đội phát triển, phòng ban nghiệp vụ (kế toán, vận hành, chăm sóc khách hàng), phòng pháp chế, bảo mật.
- External (bên ngoài): khách hàng cuối, đối tác, nhà cung cấp, cơ quan quản lý (ví dụ Ngân hàng Nhà nước với dự án fintech).
Vì sao phải "map" chứ không chỉ "list"?
Liệt kê ra một danh sách stakeholder chỉ là bước một. Vấn đề là: bạn không thể đối xử với tất cả họ như nhau. Bạn không có đủ thời gian để họp một-một hàng tuần với 40 con người. Nếu bạn dành thời gian ngang nhau cho tất cả, bạn sẽ vừa làm phiền những người không quan tâm, vừa bỏ bê những người thực sự nắm quyền sinh sát dự án.
Vậy nên bạn cần lập bản đồ — sắp xếp họ theo mức độ quyền lực (power) và mức độ quan tâm (interest), rồi từ đó quyết định đầu tư bao nhiêu công sức và theo cách nào cho mỗi người.
Power/Interest Grid (ma trận Mendelow)
Đây là công cụ kinh điển nhất, do giáo sư Aubrey Mendelow đề xuất. Bạn vẽ một ma trận 2x2, trục ngang là Interest (mức độ quan tâm đến dự án), trục dọc là Power (quyền lực, khả năng tác động lên dự án):
Interest THẤP Interest CAO
┌─────────────────────┬─────────────────────┐
Power CAO │ KEEP SATISFIED │ MANAGE CLOSELY │
│ (làm hài lòng) │ (quản lý sát sao) │
├─────────────────────┼─────────────────────┤
Power THẤP │ MONITOR │ KEEP INFORMED │
│ (theo dõi) │ (giữ thông tin) │
└─────────────────────┴─────────────────────┘
Bốn nhóm, bốn chiến lược khác nhau:
- Manage Closely (Power cao – Interest cao): Đây là những người quan trọng nhất. Bạn phải làm việc sát sao, họp thường xuyên, hỏi ý kiến trước mọi quyết định lớn. Ví dụ: Product Owner, sponsor dự án, trưởng phòng nghiệp vụ chính.
- Keep Satisfied (Power cao – Interest thấp): Họ có quyền lực lớn nhưng không quan tâm chi tiết. Đừng làm phiền họ bằng tiểu tiết, nhưng phải giữ họ hài lòng — nếu họ khó chịu, một câu nói của họ có thể chặn cả dự án. Ví dụ: giám đốc tài chính, trưởng phòng pháp chế.
- Keep Informed (Power thấp – Interest cao): Họ rất quan tâm nhưng ít quyền. Họ thường là người dùng cuối, nhân viên nghiệp vụ. Hãy cập nhật thông tin đều đặn cho họ — họ là nguồn insight vàng và là người ủng hộ bạn.
- Monitor (Power thấp – Interest thấp): Chỉ cần theo dõi, không tốn nhiều công sức. Nhưng đừng quên họ hoàn toàn — vị trí trên bản đồ có thể thay đổi.
RACI — một lớp bổ sung
Sau khi có ma trận Mendelow, với những người tham gia trực tiếp vào công việc, bạn có thể dùng thêm ma trận RACI để làm rõ vai trò trong từng hoạt động cụ thể:
- R (Responsible): người trực tiếp làm.
- A (Accountable): người chịu trách nhiệm cuối cùng, người "chốt".
- C (Consulted): người được hỏi ý kiến (hai chiều).
- I (Informed): người chỉ cần được thông báo (một chiều).
Tình huống thực tế
Ví dụ 1: Dự án app đặt vé xem phim tại một cụm rạp
Bối cảnh: Một chuỗi rạp chiếu phim ở TP.HCM (giả định tên "CineStar") muốn làm app đặt vé mới. Bạn là BA Junior duy nhất trong dự án. Ban đầu bạn chỉ liệt kê 4 stakeholder: Product Owner, đội dev (5 người), quản lý rạp, và... khách hàng.
Sau khi ngồi lại làm stakeholder mapping nghiêm túc, danh sách phình lên 11 người/nhóm. Bạn phát hiện ra:
- Đội thu ngân tại quầy (Power thấp – Interest cao): họ sẽ bị ảnh hưởng trực tiếp vì khách đặt online sẽ đến quầy lấy vé. Trước đó không ai hỏi họ.
- Phòng kế toán (Power cao – Interest thấp): họ cần app xuất hóa đơn điện tử đúng chuẩn để đối soát. Nếu bỏ sót, app không đưa vào vận hành được.
- Đối tác cổng thanh toán VNPay (External, Power cao trong phạm vi thanh toán): tích hợp của họ quyết định luồng thanh toán.
Bài học: Danh sách stakeholder ban đầu của bạn gần như luôn thiếu. Con số tăng từ 4 lên 11 không phải là bạn "vẽ vời", mà là bạn đang thấy được bức tranh thật.
Ví dụ 2: Dự án ví điện tử — khi power thay đổi giữa chừng
Bối cảnh: Một startup fintech (giả định "PayGo") làm ví điện tử. BA Junior xếp phòng Compliance (tuân thủ pháp lý) vào ô "Monitor" vì trong 2 tháng đầu, dự án chỉ làm giao diện, chưa đụng đến tiền thật, và phòng này gần như không xuất hiện.
Đến sprint 6, dự án bắt đầu xây luồng nạp/rút tiền liên kết ngân hàng. Đột nhiên yêu cầu của Ngân hàng Nhà nước về KYC (định danh khách hàng), hạn mức giao dịch, chống rửa tiền trở thành yếu tố sống còn. Phòng Compliance nhảy vọt từ "Monitor" lên thẳng "Manage Closely".
Diễn giải: BA giỏi không coi bản đồ stakeholder là thứ vẽ một lần rồi treo lên tường. Bản đồ này sống và thay đổi theo từng giai đoạn dự án. Người hôm nay ở góc "Monitor" có thể tuần sau nắm quyền phủ quyết.
Bài học: Hãy xem lại stakeholder map ở đầu mỗi giai đoạn/sprint lớn. Đặc biệt trong domain nhạy cảm như banking, insurance, healthcare — các bên pháp lý và bảo mật gần như luôn quan trọng hơn bạn tưởng lúc đầu.
Ví dụ 3: Hai "sếp" mâu thuẫn nhau
Bối cảnh: Dự án làm hệ thống quản lý kho cho một công ty thương mại điện tử. Có hai người quyền lực cao: Giám đốc Vận hành muốn quy trình xuất kho thật nhanh, tối giản thao tác; Giám đốc Tài chính muốn thêm nhiều bước kiểm soát, xác nhận để tránh thất thoát. Cả hai đều ở ô "Manage Closely". Yêu cầu của họ mâu thuẫn trực tiếp.
Diễn giải: Đây là lúc stakeholder mapping bộc lộ giá trị thật. Vì đã biết cả hai đều quyền lực cao và quan tâm cao, BA không tự ý chọn phe. Thay vào đó, bạn xác định ai là Accountable (người chốt cuối) — trong trường hợp này là Sponsor dự án — và tổ chức một buổi họp ba bên để thống nhất mức độ đánh đổi giữa tốc độ và kiểm soát, trước khi viết một dòng yêu cầu nào.
Bài học: Stakeholder map giúp bạn dự báo xung đột trước khi nó xảy ra, thay vì bị động dập lửa. Khi hai người "Manage Closely" có lợi ích trái ngược, việc của BA là đưa xung đột lên đúng người có quyền quyết định, không phải tự gánh.
Hướng dẫn từng bước
Đây là quy trình 6 bước bạn có thể áp dụng ngay cho dự án đầu tiên.
Bước 1 — Brainstorm danh sách stakeholder. Ngồi xuống (lý tưởng là cùng PO hoặc mentor) và liệt kê mọi cái tên/nhóm bạn nghĩ ra. Dùng câu hỏi gợi mở: Ai sẽ dùng sản phẩm? Ai trả tiền cho dự án? Ai xây nó? Ai có thể chặn nó? Ai bị ảnh hưởng dù không tham gia? Có ai bên ngoài công ty liên quan không? Đừng lọc lúc này — cứ ghi hết.
Bước 2 — Gom nhóm và bổ sung thông tin. Với mỗi stakeholder, ghi lại: tên/vai trò, phòng ban, họ quan tâm điều gì ở dự án, và nỗi lo của họ là gì. Đây là lúc bạn nghĩ tới cả những người "vô hình" đã nói ở trên.
Bước 3 — Đánh giá Power và Interest. Với mỗi người, cho điểm quyền lực (cao/thấp) và mức quan tâm (cao/thấp). Mẹo: quyền lực = họ có thể dừng hoặc thay đổi dự án không? Quan tâm = kết quả dự án ảnh hưởng tới công việc hằng ngày của họ nhiều hay ít?
Bước 4 — Đặt lên ma trận Mendelow. Vẽ ô 2x2 và đặt từng người vào đúng góc. Đừng cầu toàn — vị trí gần đúng là đủ để ra quyết định.
Bước 5 — Xác định chiến lược tương tác cho từng nhóm. Với mỗi góc, ghi rõ: tần suất liên lạc (họp tuần? báo cáo tháng? email khi cần?), kênh nào (họp trực tiếp, Slack/Teams, email), và ai phụ trách giữ liên lạc. Với các hoạt động cụ thể, cân nhắc lập thêm ma trận RACI.
Bước 6 — Rà soát định kỳ. Đặt lịch xem lại bản đồ ở đầu mỗi sprint lớn hoặc mỗi giai đoạn. Cập nhật khi có người mới tham gia, người rời đi, hoặc khi bối cảnh dự án chuyển sang phần nhạy cảm hơn (như ví dụ PayGo).
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn thấy người trong phòng họp. Đây là lỗi phổ biến nhất của fresher. Mẹo: sau khi có danh sách, tự hỏi "Còn ai dùng sản phẩm mà tôi chưa nói chuyện? Còn ai có thể nói KHÔNG mà tôi chưa gặp?".
Lỗi 2 — Nhầm "chức danh to" với "power cao trong dự án này". Một CEO có chức to, nhưng nếu ông ấy giao toàn quyền cho PO thì trong phạm vi dự án này, power thực tế của ông ấy có thể thấp. Ngược lại, một anh IT admin chức nhỏ nhưng nắm quyền truy cập hệ thống lại có power rất cao. Hãy đánh giá quyền lực trong bối cảnh dự án cụ thể, không theo sơ đồ tổ chức.
Lỗi 3 — Coi bản đồ là bất biến. Như ví dụ PayGo, vị trí stakeholder thay đổi theo giai đoạn. Mẹo: ghi ngày lập bản đồ và đặt nhắc rà soát.
Lỗi 4 — Đối xử đồng đều với tất cả. Gửi cùng một báo cáo dài 10 trang cho cả CEO lẫn nhân viên nhập liệu là lãng phí và phản tác dụng. Người "Keep Satisfied" cần bản tóm tắt cấp cao; người "Keep Informed" cần chi tiết nghiệp vụ.
Lỗi 5 — Chia sẻ bản đồ một cách vụng về. Bản đồ stakeholder chứa đánh giá về quyền lực và mức quan tâm của con người — khá nhạy cảm. Mẹo: đây là công cụ làm việc nội bộ của bạn và team, đừng chiếu nguyên bản lên màn hình trước mặt chính các stakeholder. Không ai vui khi thấy mình bị xếp vào ô "Monitor".
Mẹo vàng cho fresher: Với mỗi stakeholder quan trọng, hãy ghi thêm một dòng "điều họ sợ nhất ở dự án này". Hiểu nỗi lo của họ (sợ mất việc, sợ thêm việc, sợ lộ sai sót cũ, sợ bị đánh giá) giúp bạn giao tiếp trúng đích hơn bất kỳ kỹ thuật nào.
Bài tập thực hành
Hãy chọn một trong hai kịch bản sau và làm đầy đủ:
Kịch bản A: Trường đại học của bạn muốn xây một app đăng ký học phần mới thay cho hệ thống cũ chậm và hay treo.
Kịch bản B: Một quán cà phê chuỗi muốn làm app tích điểm thành viên và đặt đồ uống trước.
Với kịch bản đã chọn, hoàn thành các nhiệm vụ:
- Liệt kê ít nhất 10 stakeholder, phân rõ internal và external. Cố tình bao gồm ít nhất 2 stakeholder "vô hình" (không ngồi họp nhưng bị ảnh hưởng).
- Với mỗi stakeholder, ghi một câu về điều họ quan tâm và nỗi lo lớn nhất của họ.
- Vẽ ma trận Mendelow 2x2 và đặt cả 10+ người vào đúng ô.
- Viết chiến lược tương tác cho từng nhóm (tần suất, kênh liên lạc).
- Chọn một hoạt động cụ thể (ví dụ "chốt yêu cầu luồng thanh toán") và lập một bảng RACI nhỏ với 4–5 người.
- Câu hỏi nâng cao: Chỉ ra một stakeholder mà vị trí của họ trên bản đồ sẽ thay đổi ở giai đoạn sau của dự án, và giải thích vì sao.
Tóm tắt
- Stakeholder là bất cứ ai bị ảnh hưởng bởi hoặc ảnh hưởng đến dự án — bao gồm cả những người "vô hình" không ngồi trong phòng họp.
- Đừng chỉ list, hãy map: bạn không thể đối xử với mọi stakeholder như nhau vì thời gian có hạn.
- Ma trận Mendelow (Power/Interest) chia stakeholder thành 4 nhóm với 4 chiến lược: Manage Closely, Keep Satisfied, Keep Informed, Monitor.
- RACI bổ sung lớp làm rõ vai trò (Responsible, Accountable, Consulted, Informed) cho từng hoạt động cụ thể.
- Đánh giá quyền lực theo bối cảnh dự án, không theo chức danh trên sơ đồ tổ chức.
- Bản đồ stakeholder là tài liệu sống — rà soát lại ở đầu mỗi giai đoạn, đặc biệt trong domain nhạy cảm như fintech, banking, insurance.
- Nó là công cụ nội bộ, nhạy cảm — dùng để định hướng giao tiếp, đừng phô ra trước mặt chính stakeholder.