Mở đầu — vì sao bài này quan trọng
Trong nhiều khóa học Scrum, chúng ta được dạy rằng Scrum Master phục vụ ba đối tượng: Developers, Product Owner và tổ chức. Nhưng khi bước vào thực tế, bạn sẽ nhanh chóng nhận ra rằng "tổ chức" không phải một khối đồng nhất — nó là một mạng lưới chằng chịt những con người với quyền lực, lợi ích và kỳ vọng khác nhau. Họ chính là các stakeholder (bên liên quan). Và phần lớn những thất bại của một Scrum Team không đến từ kỹ thuật hay quy trình, mà đến từ việc quản lý sai kỳ vọng và quan hệ với các stakeholder này.
Ở cấp độ PSM I, bạn được học rằng Sprint Review là nơi stakeholder tham gia. Nhưng ở cấp độ PSM II, câu hỏi không còn là "khi nào stakeholder xuất hiện", mà là: Stakeholder gồm những ai? Họ có lợi ích gì, đôi khi mâu thuẫn với nhau? Vai trò của Scrum Master ở đâu trong việc kết nối họ với Scrum Team mà không biến mình thành "người đưa tin" hay "lá chắn" thái quá?
Đây là một kỹ năng tinh tế. Làm tốt, bạn giúp team có được sự tin tưởng, ngân sách và không gian để làm việc hiệu quả. Làm sai, team bạn sẽ bị micromanage, bị thay đổi ưu tiên liên tục, hoặc tệ hơn — bị cắt ngân sách vì stakeholder không thấy được giá trị. Bài học này sẽ giúp bạn phân loại stakeholder, hiểu lợi ích của từng nhóm, và định vị đúng vai trò Scrum Master trong mối quan hệ này.
Khái niệm cốt lõi
Stakeholder là ai, và không phải ai
Stakeholder là bất kỳ cá nhân hoặc nhóm nào có lợi ích trong sản phẩm hoặc bị ảnh hưởng bởi kết quả công việc của Scrum Team. Điều quan trọng cần phân biệt ngay: Product Owner KHÔNG phải stakeholder — PO là thành viên Scrum Team, là người đại diện cho stakeholder và quản lý Product Backlog. Tương tự, Developers và Scrum Master cũng không phải stakeholder theo nghĩa Scrum Guide dùng. Stakeholder là những người ở bên ngoài Scrum Team nhưng quan tâm đến đầu ra của nó.
Sự nhầm lẫn này rất phổ biến ở học viên Việt Nam, vì trong nhiều công ty, sếp trực tiếp vừa là người duyệt ngân sách (stakeholder), vừa can thiệp vào backlog (lấn sân PO). Tách bạch rõ vai trò là bước đầu tiên.
Phân loại stakeholder theo lợi ích
Hãy hình dung ba nhóm stakeholder chính, mỗi nhóm có một "lợi ích" rất khác nhau:
Sponsors (Nhà tài trợ) — đây là những người cấp ngân sách cho công việc. Họ có thể là giám đốc khối, CFO, hoặc một khách hàng doanh nghiệp đã ký hợp đồng. Lợi ích của họ là ROI (lợi tức đầu tư): tiền bỏ ra có sinh lời không, có đúng tiến độ chiến lược không. Sponsor thường không quan tâm bạn dùng Scrum hay Kanban; họ quan tâm "khi nào tôi thấy giá trị tương xứng với số tiền đã chi". Với sponsor, ngôn ngữ giao tiếp phải là kết quả kinh doanh và outcome, không phải velocity hay số story points.
End users (Người dùng cuối) — đây là những người trực tiếp sử dụng sản phẩm hằng ngày. Lợi ích của họ là trải nghiệm và giá trị sử dụng: sản phẩm có dễ dùng không, có giải quyết được vấn đề của họ không. Điều thú vị là end user thường là nhóm bị "quên" nhất, vì họ không có tiền và không ngồi trong phòng họp. Một Scrum Master giỏi sẽ luôn tìm cách đưa tiếng nói của end user vào Sprint Review.
Customers (Khách hàng) — đây là những người trả tiền mua sản phẩm, và họ có thể KHÁC với end user. Đây là một phân biệt quan trọng mà PSM II đặc biệt nhấn mạnh. Ví dụ kinh điển: với một phần mềm quản lý bệnh viện, customer là ban giám đốc bệnh viện (người ký hợp đồng mua), còn end user là các điều dưỡng, bác sĩ thực sự gõ phím mỗi ngày. Lợi ích của customer là giá trị thương mại và sự phù hợp với nhu cầu tổ chức của họ. Khi customer và end user khác nhau, sẽ luôn có nguy cơ xung đột: customer muốn báo cáo quản trị đẹp, end user muốn thao tác nhanh gọn.
Ngoài ba nhóm trên, trong thực tế bạn còn gặp các stakeholder nội bộ như: bộ phận Pháp chế/Compliance, bộ phận Vận hành (Ops), đội Marketing, đội Bán hàng — mỗi nhóm đều "kéo" sản phẩm về phía lợi ích của họ.
Vai trò của Scrum Master: cầu nối, không phải người gác cổng
Đây là điểm tinh tế nhất. Scrum Master KHÔNG sở hữu mối quan hệ với stakeholder — đó là việc của Product Owner. PO là người chịu trách nhiệm tối đa hóa giá trị sản phẩm và là cầu nối chính với stakeholder. Vậy Scrum Master làm gì?
Vai trò của Scrum Master là giúp toàn bộ hệ thống tương tác hiệu quả hơn:
- Coach PO cách giao tiếp và quản lý kỳ vọng stakeholder.
- Facilitate (điều phối) các sự kiện như Sprint Review để stakeholder và team đối thoại trực tiếp, thay vì để PO làm "người đưa tin" một chiều.
- Gỡ bỏ những impediment xuất phát từ stakeholder (ví dụ: stakeholder liên tục yêu cầu thay đổi giữa Sprint).
- Giáo dục stakeholder về Scrum: vì sao họ không nên can thiệp giữa Sprint, vì sao empiricism (kinh nghiệm thực chứng) lại tốt hơn kế hoạch cố định.
Tình huống thực tế
Tình huống 1: Khi sponsor và end user mâu thuẫn — công ty fintech ở TP.HCM
Một công ty fintech tại TP.HCM (tạm gọi là "MoMoney") phát triển ứng dụng cho vay tiêu dùng. Sponsor là CEO, người đã cam kết với nhà đầu tư rằng sẽ đạt 100.000 khoản vay được giải ngân trong quý. Sponsor liên tục gây áp lực lên team: "Đẩy nhanh luồng đăng ký, bỏ bớt bước xác minh để tăng tỉ lệ chuyển đổi."
Trong khi đó, end user — những người vay tiền — lại phản hồi rằng luồng đăng ký quá rối, nhiều người bị từ chối oan, và app báo lỗi liên tục.
Scrum Master, thay vì chỉ truyền tải áp lực của CEO xuống team, đã làm hai việc. Thứ nhất, anh coach PO chuẩn bị dữ liệu cho Sprint Review: tỉ lệ hoàn tất đăng ký chỉ 38%, và 60% người bỏ giữa chừng là do lỗi kỹ thuật, không phải do quy trình quá chặt. Thứ hai, anh mời hai end user thật (qua bản ghi phỏng vấn) vào trình bày tại Sprint Review để CEO nghe trực tiếp.
Kết quả: CEO nhận ra rằng "đẩy nhanh" mà bỏ chất lượng sẽ làm tỉ lệ hoàn tất giảm chứ không tăng. Team được ưu tiên fix lỗi kỹ thuật trước. Sau hai Sprint, tỉ lệ hoàn tất tăng lên 61%, và số khoản vay thực tế vượt mục tiêu của sponsor.
Bài học: Khi lợi ích của sponsor (số lượng, tốc độ) và end user (chất lượng, trải nghiệm) mâu thuẫn, Scrum Master không chọn phe. Vai trò của bạn là tạo ra minh bạch bằng dữ liệu và tiếng nói trực tiếp để stakeholder tự đưa ra quyết định tốt hơn.
Tình huống 2: Khi customer khác end user — dự án phần mềm cho chuỗi bán lẻ
Một công ty gia công phần mềm tại Hà Nội xây dựng hệ thống POS (điểm bán hàng) cho một chuỗi siêu thị mini có 200 cửa hàng. Customer ở đây là phòng IT và ban lãnh đạo chuỗi — họ ký hợp đồng, họ trả tiền. End user là nhân viên thu ngân tại quầy.
Trong các buổi làm việc, customer (phòng IT) liên tục yêu cầu thêm tính năng báo cáo quản trị phức tạp: dashboard doanh thu theo giờ, theo SKU, theo nhân viên. Họ gần như không quan tâm đến màn hình thu ngân. Kết quả là sau 4 Sprint, hệ thống có dashboard rất đẹp nhưng nhân viên thu ngân mất trung bình 12 giây cho mỗi giao dịch — quá chậm vào giờ cao điểm, gây ùn tắc khách hàng.
Scrum Master nhận ra vấn đề: tiếng nói của end user hoàn toàn vắng mặt. Cô đề xuất với PO tổ chức một buổi quan sát thực địa (Gemba) tại 3 cửa hàng, và mời 2 thu ngân trưởng tham gia Sprint Review. Khi customer (ban lãnh đạo) tận mắt thấy hàng dài khách chờ vì hệ thống chậm, ưu tiên thay đổi ngay lập tức. Họ nhận ra: dashboard đẹp đến đâu cũng vô nghĩa nếu cửa hàng mất khách.
Bài học: Khi customer trả tiền nhưng không phải người dùng, họ thường định nghĩa "giá trị" sai lệch. Scrum Master phải chủ động đưa end user vào vòng phản hồi, nếu không PO sẽ chỉ tối ưu cho người la to nhất (customer), bỏ quên người dùng thật.
Tình huống 3: Stakeholder can thiệp giữa Sprint — startup edtech Đông Nam Á
Tại một startup edtech ở khu vực Đông Nam Á, có một stakeholder là Giám đốc Marketing thường xuyên nhắn trực tiếp cho Developers qua Slack: "Em ơi, làm gấp cho chị cái banner khuyến mãi này, mai chị chạy campaign rồi." Việc này xảy ra gần như mỗi tuần, phá vỡ Sprint Goal và khiến team không bao giờ hoàn thành được cam kết.
Scrum Master không trách Developers, cũng không "cấm" Giám đốc Marketing. Thay vào đó, anh làm ba việc: (1) trò chuyện riêng với Giám đốc Marketing để hiểu áp lực của chị — hóa ra chị bị KPI campaign hằng tuần; (2) coach chị cách đưa nhu cầu vào Product Backlog qua PO thay vì nhắn thẳng Dev; (3) đề xuất PO dành một phần năng lực mỗi Sprint cho các yêu cầu marketing khẩn (một dạng "buffer"). Đồng thời, anh giúp team minh bạch hóa cái giá của việc ngắt quãng bằng cách cho thấy số Sprint Goal bị lỡ.
Sau một tháng, các yêu cầu đột xuất giảm 70%, và những yêu cầu thật sự khẩn được xử lý có trật tự qua PO.
Bài học: Stakeholder can thiệp giữa Sprint thường không phải vì "xấu tính" mà vì họ có áp lực riêng và chưa hiểu cách làm việc với Scrum Team. Scrum Master giải quyết bằng thấu hiểu + giáo dục + thiết kế lại luồng, không phải bằng việc dựng rào chặn.
Hướng dẫn từng bước
Đây là quy trình thực tế để quản lý quan hệ stakeholder một cách có hệ thống:
Bước 1 — Lập bản đồ stakeholder (Stakeholder Mapping). Cùng PO liệt kê tất cả stakeholder, phân loại theo nhóm (sponsor, customer, end user, nội bộ). Với mỗi người, ghi rõ: họ quan tâm điều gì, họ có quyền lực gì, và mức độ ảnh hưởng đến sản phẩm. Một công cụ kinh điển là ma trận Power/Interest (Quyền lực/Quan tâm): người quyền lực cao + quan tâm cao thì phải quản lý sát; người quyền lực thấp + quan tâm thấp thì chỉ cần thông tin định kỳ.
Bước 2 — Xác định ai sở hữu mối quan hệ. Nhắc lại: PO sở hữu quan hệ stakeholder, không phải bạn. Vai trò bạn là làm cho mối quan hệ đó hiệu quả. Hãy ngồi với PO để xem họ đang giao tiếp với stakeholder nào, có lỗ hổng nào (ví dụ: end user bị bỏ quên).
Bước 3 — Tối ưu Sprint Review thành nơi đối thoại hai chiều. Đừng để Sprint Review thành buổi "trình diễn" một chiều. Thiết kế nó để stakeholder thực sự đưa feedback, đặt câu hỏi, và cùng PO điều chỉnh Product Backlog. Đây là sự kiện quan trọng nhất cho quan hệ stakeholder.
Bước 4 — Giáo dục stakeholder về empiricism. Nhiều stakeholder quen với mô hình "cam kết một lần, giao đúng kế hoạch". Hãy kiên nhẫn giải thích vì sao điều chỉnh dựa trên feedback lại cho kết quả tốt hơn, vì sao họ không nên thay đổi giữa Sprint.
Bước 5 — Hướng tới team tự giao tiếp. Mục tiêu dài hạn là team đủ trưởng thành để Developers trao đổi trực tiếp với stakeholder khi cần, không phụ thuộc Scrum Master hay PO làm trung gian mọi lúc.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến mình thành lá chắn tuyệt đối. "Mọi yêu cầu phải qua tôi" nghe có vẻ bảo vệ team nhưng phá hủy minh bạch và làm team yếu đi. Mẹo: hãy là bộ lọc thông minh giai đoạn đầu, rồi rút lui dần khi team trưởng thành.
Lỗi 2 — Lẫn lộn vai trò với PO. Scrum Master tự đi đàm phán scope với stakeholder là lấn sân PO. Mẹo: nếu bạn thấy mình đang quyết định cái gì được làm, hãy dừng lại — đó là việc của PO. Bạn lo cách hệ thống tương tác.
Lỗi 3 — Quên nhóm end user. Vì end user không có tiền và không ngồi họp, họ dễ bị bỏ quên. Mẹo: luôn đặt câu hỏi "Người dùng thật nghĩ gì?" trong mỗi Sprint Review, và tìm cách đưa dữ liệu hoặc tiếng nói của họ vào.
Lỗi 4 — Giao tiếp sai ngôn ngữ với từng nhóm. Nói velocity với sponsor là vô nghĩa; nói ROI với end user cũng lạc đề. Mẹo: với sponsor dùng ngôn ngữ outcome/ROI, với end user dùng ngôn ngữ trải nghiệm, với customer dùng ngôn ngữ giá trị thương mại.
Lỗi 5 — Coi mọi can thiệp của stakeholder là "kẻ thù". Mẹo: đằng sau mỗi yêu cầu khó chịu thường có một áp lực hợp lý. Thấu hiểu trước, giáo dục sau.
Bài tập thực hành
- Lập bản đồ stakeholder cho dự án của bạn. Vẽ ma trận Power/Interest và đặt tất cả stakeholder vào đó. Đánh dấu những ai bạn đang giao tiếp tốt và những ai bị bỏ quên (đặc biệt là end user).
- Phân tích một xung đột lợi ích. Chọn một tình huống mà hai nhóm stakeholder của bạn có lợi ích mâu thuẫn (ví dụ: sponsor muốn nhanh, end user muốn chất lượng). Viết ra: dữ liệu nào bạn có thể đưa ra để tạo minh bạch, và bạn sẽ thiết kế Sprint Review thế nào để họ tự đối thoại.
- Đóng vai coach PO. Viết kịch bản một cuộc trò chuyện 1-on-1 trong đó bạn coach PO cách từ chối khéo léo một stakeholder muốn nhồi thêm scope giữa Sprint, mà vẫn giữ được quan hệ tốt.
- Tự kiểm tra vai trò. Liệt kê 5 việc bạn đang làm với stakeholder trong tuần qua. Với mỗi việc, tự hỏi: đây là việc của Scrum Master, của PO, hay đang lấn sân? Điều chỉnh nếu cần.
Tóm tắt
Stakeholder không phải một khối đồng nhất — họ là sponsor (quan tâm ROI), end user (quan tâm trải nghiệm), customer (quan tâm giá trị thương mại, và có thể khác end user), cùng nhiều nhóm nội bộ. Mỗi nhóm có lợi ích riêng, đôi khi mâu thuẫn nhau. Product Owner — không phải Scrum Master — là người sở hữu mối quan hệ với stakeholder. Vai trò của Scrum Master là làm cho hệ thống tương tác đó hiệu quả: coach PO, facilitate Sprint Review thành đối thoại hai chiều, gỡ impediment từ stakeholder, giáo dục họ về empiricism, và hướng tới một team đủ trưởng thành để tự giao tiếp.
Hãy nhớ ba nguyên tắc cốt lõi: (1) đừng làm lá chắn tuyệt đối — minh bạch quan trọng hơn sự "bảo vệ"; (2) đừng quên end user — họ là nhóm dễ bị bỏ rơi nhất; (3) thấu hiểu trước khi giáo dục — mỗi can thiệp của stakeholder thường ẩn chứa một áp lực hợp lý. Làm tốt mối quan hệ stakeholder, bạn không chỉ bảo vệ được team mà còn mở ra ngân sách, niềm tin và không gian để team thực sự tạo ra giá trị.