Mở đầu — vì sao bài này quan trọng
Nếu bạn để ý kỹ, Scrum Guide 2020 — bản chính thức mà kỳ thi PSM I bám vào từng câu chữ — gần như không nói nhiều về stakeholders. Cả tài liệu chỉ nhắc đến từ "stakeholders" vài lần, và chủ yếu trong bối cảnh Sprint Review. Chính sự "ít ỏi" này lại tạo ra một cái bẫy lớn cho thí sinh: nhiều người tự suy diễn rằng stakeholders là một "vai trò" trong Scrum, rằng họ "tham gia Daily Scrum", hoặc rằng Product Owner "phải làm theo lệnh" của họ. Tất cả đều sai theo chuẩn "by the book".
Trong kỳ thi PSM I, stakeholders xuất hiện gián tiếp ở rất nhiều câu hỏi tình huống: ai được mời tới Sprint Review, ai quyết định nội dung Product Backlog khi stakeholders mâu thuẫn nhau, Scrum Master xử lý thế nào khi một stakeholder quyền lực muốn chen ngang Sprint. Hiểu đúng bản chất của stakeholders — họ là ai, họ KHÔNG phải là gì, họ tương tác với Scrum Team ở đâu và như thế nào — sẽ giúp bạn loại nhanh các đáp án sai và chọn đúng đáp án "theo Scrum Guide".
Bài này tập trung riêng vào khái niệm stakeholders: định nghĩa, vị trí của họ trong hệ thống Scrum, và cách Scrum Team tương tác với họ. Chúng ta sẽ không đi sâu vào cơ chế Sprint Review (đã có bài riêng) hay accountability của Product Owner (cũng có bài riêng), mà nhìn stakeholders như một "lực lượng bên ngoài" mà cả team phải biết cách làm việc cùng.
Khái niệm cốt lõi
Stakeholders là ai?
Định nghĩa đơn giản và chính xác nhất: stakeholders là bất kỳ ai bên ngoài Scrum Team có lợi ích (interest) liên quan đến sản phẩm. "Bên ngoài Scrum Team" là cụm từ then chốt. Scrum Team gồm ba accountabilities: Product Owner, Scrum Master, và Developers. Tất cả những người còn lại có quan tâm đến sản phẩm đều là stakeholders.
Các nhóm stakeholders thường gặp:
- End users — người trực tiếp sử dụng sản phẩm. Ví dụ: người dùng cuối của một ứng dụng đặt đồ ăn.
- Customers — người trả tiền mua sản phẩm. Lưu ý: customer và end user không phải lúc nào cũng là một người. Trong B2B, người ký hợp đồng mua phần mềm (customer) thường khác với nhân viên ngồi dùng phần mềm đó hằng ngày (end user).
- Business stakeholders — các bộ phận nội bộ có lợi ích: phòng kinh doanh, marketing, vận hành, tài chính.
- Sponsors / executives — lãnh đạo cấp cao rót ngân sách và kỳ vọng vào ROI.
- Subject matter experts (SME) — chuyên gia về lĩnh vực, ví dụ chuyên gia pháp lý, chuyên gia y tế, chuyên gia bảo mật.
- Đối tác bên ngoài — nhà cung cấp, cơ quan quản lý nhà nước (regulators), đối tác tích hợp hệ thống.
Stakeholders KHÔNG phải là gì
Đây là phần mà PSM I rất hay "gài". Bạn cần ghi nhớ thật chắc:
- Stakeholders KHÔNG phải là một thành viên của Scrum Team. Họ không nằm trong ba accountabilities. Họ không "thuộc về" team.
- Stakeholders KHÔNG quản lý hay chỉ đạo Scrum Team. Scrum Team là self-managing. Stakeholders không phân công công việc, không quyết định team làm gì trong Sprint.
- Stakeholders KHÔNG trực tiếp thêm/sắp xếp Product Backlog. Chỉ Product Owner mới có quyền quyết định nội dung và thứ tự (ordering) của Product Backlog. Stakeholders có thể đề xuất, gây ảnh hưởng, nhưng quyền quyết định cuối cùng thuộc về Product Owner.
- Stakeholders KHÔNG phải là người tham dự bắt buộc của mọi Scrum Event. Scrum Guide chỉ đề cập việc Product Owner có thể mời stakeholders tới Sprint Review để cùng inspect Increment và collaborate về bước tiếp theo. Daily Scrum là sự kiện của Developers; Sprint Planning, Retrospective về nguyên tắc là của Scrum Team.
Product Owner — "cầu nối" chính thức với stakeholders
Trong Scrum, Product Owner là điểm tiếp xúc chính giữa Scrum Team và stakeholders về mặt giá trị sản phẩm. Product Owner đại diện cho tiếng nói của nhiều stakeholders, tổng hợp các nhu cầu đôi khi mâu thuẫn, rồi đưa ra một Product Backlog được sắp xếp rõ ràng để tối đa hóa giá trị.
Điều này KHÔNG có nghĩa là Developers bị cấm nói chuyện với stakeholders. Trong thực tế, Developers thường xuyên trao đổi trực tiếp với end users hay SME để làm rõ yêu cầu — đó là điều lành mạnh và được khuyến khích vì nó tăng transparency. Nhưng về mặt quyền quyết định giá trị và thứ tự ưu tiên, Product Owner là người chịu trách nhiệm (accountable). Một stakeholder không thể "đi đường vòng" qua Product Owner để ép Developers làm việc khác.
Điểm giao thoa chính thức: Sprint Review
Sprint Review là sự kiện duy nhất mà Scrum Guide nói rõ stakeholders được mời tham gia. Tại đây, Scrum Team và các stakeholders chủ chốt cùng:
- Inspect Increment đã hoàn thành.
- Thảo luận về tiến độ hướng tới Product Goal.
- Điều chỉnh Product Backlog dựa trên những thay đổi của thị trường, nhu cầu mới, hoặc phản hồi từ chính stakeholders.
Vì sao quản lý stakeholders lại quan trọng?
Stakeholders nắm giữ ba thứ mà Scrum Team cần: thông tin (họ hiểu nhu cầu thật của thị trường), phản hồi (họ cho biết Increment có giá trị hay không), và đôi khi quyền lực/ngân sách (sponsors quyết định dự án tồn tại hay không). Một Scrum Team xuất sắc về kỹ thuật nhưng mù mờ về stakeholders sẽ tạo ra sản phẩm chạy tốt nhưng không ai cần. Đó là lý do transparency với stakeholders là một phần của empiricism.
Tình huống thực tế
Ví dụ 1 — Startup giao đồ ăn ở TP.HCM: ai mới là "stakeholder thật"?
Một startup giả định tên FoodFast tại TP.HCM phát triển ứng dụng giao đồ ăn. Scrum Team gồm 1 Product Owner, 1 Scrum Master và 6 Developers. Khi liệt kê stakeholders, Product Owner ban đầu chỉ nghĩ tới "khách hàng đặt món" (end users). Nhưng khi vẽ bản đồ stakeholders đầy đủ, họ nhận ra có ít nhất bốn nhóm:
- End users — người dùng đặt món qua app (khoảng 50.000 người dùng/tháng).
- Tài xế giao hàng — họ dùng app phiên bản tài xế; trải nghiệm tồi khiến họ bỏ nền tảng.
- Nhà hàng đối tác — họ là "customer" trả phí hoa hồng; nếu nhà hàng rời đi, không còn món để bán.
- Nhà đầu tư (sponsor) — quỹ đã rót 2 tỷ đồng, kỳ vọng tỷ lệ giữ chân người dùng (retention) tăng 15% trong quý.
Bài học: Stakeholders không chỉ là "người dùng cuối". Bỏ sót một nhóm stakeholders có thể khiến team tối ưu sai chỗ. Và lưu ý theo Scrum: chính Product Owner là người quyết định đưa vấn đề của nhà hàng lên Product Backlog — không phải nhà hàng tự "ra lệnh" cho Developers.
Ví dụ 2 — Ngân hàng số: stakeholder quyền lực muốn chen ngang Sprint
Một ngân hàng giả định VietBank đang xây dựng tính năng eKYC (định danh điện tử). Giữa Sprint, một Phó Tổng Giám đốc — một stakeholder rất quyền lực — gọi thẳng cho một Developer, yêu cầu "ưu tiên ngay" việc thêm một báo cáo cho ban điều hành, bỏ qua công việc đang dở trong Sprint Backlog.
Developer lúng túng vì người yêu cầu là sếp lớn. Scrum Master vào cuộc và xử lý theo đúng tinh thần Scrum:
- Giải thích rằng Sprint Backlog do Developers tự quản lý, và Sprint đang có một Sprint Goal cần bảo vệ.
- Hướng dẫn stakeholder mang yêu cầu này tới Product Owner, vì chỉ Product Owner mới quyết định việc đưa hạng mục mới vào Product Backlog và sắp xếp thứ tự.
- Nếu yêu cầu thực sự khẩn cấp đến mức làm Sprint Goal không còn ý nghĩa, đó là một cuộc thảo luận riêng (về việc có nên hủy Sprint hay không), nhưng quyết định không nằm ở việc một stakeholder gọi điện ép một Developer.
Ví dụ 3 — Dự án chính phủ điện tử ở Đông Nam Á: stakeholders mâu thuẫn nhau
Một dự án cổng dịch vụ công trực tuyến (giả định ở một tỉnh tại Việt Nam) có nhiều stakeholders với lợi ích trái ngược: Sở Thông tin muốn nhiều tính năng, người dân (end users) muốn đơn giản dễ dùng, còn bộ phận bảo mật (SME) muốn thắt chặt quy trình xác thực — điều khiến trải nghiệm phức tạp hơn.
Tại các Sprint Review, ba nhóm stakeholders này thường tranh luận gay gắt. Product Owner không thể làm hài lòng tất cả. Cách xử lý đúng: Product Owner lắng nghe tất cả, nhưng tự đưa ra quyết định cuối cùng về thứ tự Product Backlog dựa trên giá trị tổng thể và Product Goal. Product Owner giải thích minh bạch lý do ưu tiên, ví dụ: "Sprint tới tập trung luồng đăng nhập an toàn vì rủi ro lộ dữ liệu công dân là cao nhất, các tính năng tiện ích sẽ làm ở Sprint sau."
Bài học: Khi stakeholders mâu thuẫn, Scrum KHÔNG bầu chọn theo số đông cũng không để stakeholder mạnh nhất thắng. Một Product Owner có quyền lực thực sự (empowered) là người tổng hợp các tiếng nói rồi ra quyết định và chịu trách nhiệm. Vai trò của stakeholders là cung cấp đầu vào và phản hồi, không phải bỏ phiếu quản trị.
Hướng dẫn từng bước
Dưới đây là cách một Scrum Team làm việc với stakeholders một cách bài bản. Bạn có thể dùng quy trình này cả khi ôn thi (để hình dung tình huống) lẫn khi làm thật.
- Bước 1 — Lập bản đồ stakeholders (stakeholder mapping). Product Owner liệt kê tất cả các bên có lợi ích: end users, customers, sponsors, SME, đối tác, regulators. Phân loại theo mức độ ảnh hưởng và mức độ quan tâm để biết ai cần tương tác thường xuyên.
- Bước 2 — Xác định kênh tương tác chính. Về mặt giá trị sản phẩm và quyết định backlog, Product Owner là điểm tiếp xúc chính. Tuy nhiên, khuyến khích Developers trao đổi trực tiếp với SME/end users để làm rõ yêu cầu kỹ thuật, tăng transparency.
- Bước 3 — Mời stakeholders phù hợp tới Sprint Review. Không mời tất cả mọi người vào mọi buổi. Product Owner chọn những stakeholders chủ chốt cần thiết để inspect Increment và thu phản hồi có giá trị cho Sprint sắp tới.
- Bước 4 — Thu thập và "phiên dịch" phản hồi thành Product Backlog items. Phản hồi của stakeholders không tự động trở thành công việc. Product Owner sàng lọc, gộp, ưu tiên rồi đưa vào Product Backlog với thứ tự rõ ràng.
- Bước 5 — Bảo vệ Scrum Team trong Sprint. Scrum Master đảm bảo stakeholders không phá vỡ Sprint đang diễn ra (không chen ngang Developers, không ép thay đổi Sprint Backlog tùy tiện). Mọi thay đổi đi qua Product Owner.
- Bước 6 — Đóng vòng lặp phản hồi. Ở Sprint Review kế tiếp, cho stakeholders thấy phản hồi của họ đã được phản ánh ra sao. Điều này xây dựng niềm tin và duy trì sự tham gia.
Lỗi thường gặp & mẹo
Lỗi 1: Coi stakeholders là thành viên Scrum Team. Nhiều người trả lời sai câu hỏi "Scrum Team gồm những ai?" vì kể thêm stakeholders. Nhớ: Scrum Team chỉ có Product Owner, Scrum Master, Developers. Stakeholders luôn ở "bên ngoài".
Lỗi 2: Nghĩ rằng stakeholders trực tiếp ra lệnh cho Developers. Sai. Developers self-managing. Yêu cầu thay đổi sản phẩm đi qua Product Owner và Product Backlog.
Lỗi 3: Cho rằng stakeholders quyết định nội dung/thứ tự Product Backlog. Sai. Họ chỉ ảnh hưởng. Product Owner mới là người accountable cho việc đó.
Lỗi 4: Cho rằng stakeholders tham dự mọi event. Trong khuôn khổ "by the book", stakeholders gắn với Sprint Review. Đừng chọn đáp án nói stakeholders "phải dự Daily Scrum" — Daily Scrum là của Developers.
Lỗi 5: Lẫn lộn customer và end user. Trong B2B, người trả tiền và người dùng thường là hai nhóm khác nhau. Câu hỏi tình huống có thể gài chỗ này.
Mẹo thi cử:
- Khi thấy đáp án có dạng "stakeholder yêu cầu, Developer làm ngay" — gần như chắc chắn sai.
- Khi thấy "Product Owner lắng nghe stakeholders rồi tự quyết định ưu tiên" — gần như chắc chắn đúng.
- Khi thấy "Scrum Master bảo vệ team khỏi sự can thiệp giữa Sprint và giáo dục stakeholder" — đó là hành vi servant leadership đúng chuẩn.
- Ghi nhớ một câu thần chú: Stakeholders cung cấp đầu vào và phản hồi; Product Owner ra quyết định; Developers tự quản lý cách làm.
Bài tập thực hành
- Phân loại nhanh: Liệt kê một sản phẩm bạn biết (ví dụ ứng dụng ngân hàng bạn đang dùng). Hãy chỉ ra ít nhất 5 nhóm stakeholders khác nhau, và phân biệt rõ đâu là end user, đâu là customer, đâu là sponsor.
- Tình huống ra quyết định: Một stakeholder phòng marketing và một SME bảo mật đưa ra hai yêu cầu trái ngược nhau cho cùng một tính năng đăng nhập. Theo Scrum, ai là người ra quyết định cuối cùng về việc cái nào lên Product Backlog trước, và dựa trên tiêu chí gì? Viết câu trả lời 3–4 câu.
- Sửa lỗi đáp án: Cho câu trả lời sai sau và sửa lại cho đúng Scrum Guide: "Khi một giám đốc yêu cầu thêm tính năng giữa Sprint, Developers nên dừng công việc hiện tại và làm theo ngay vì ông ấy là sếp." Hãy viết lại đáp án đúng và giải thích vì sao.
- Câu hỏi tự luận ngắn: Theo Scrum Guide, stakeholders được mời tham gia chính thức vào sự kiện nào, và mục đích của sự tham gia đó là gì? Trả lời trong 2–3 câu.
- Vẽ sơ đồ: Vẽ một sơ đồ đơn giản đặt Scrum Team ở giữa, stakeholders ở vòng ngoài, và mũi tên thể hiện luồng tương tác (phản hồi đi vào, giá trị/Increment đi ra, và đường đi của yêu cầu thay đổi qua Product Owner).
Tóm tắt
- Stakeholders là bất kỳ ai bên ngoài Scrum Team có lợi ích liên quan đến sản phẩm: end users, customers, sponsors, SME, đối tác, regulators.
- Họ không thuộc Scrum Team, không quản lý team, không trực tiếp quyết định nội dung hay thứ tự Product Backlog.
- Product Owner là cầu nối chính về giá trị sản phẩm, tổng hợp nhu cầu của stakeholders rồi tự ra quyết định ưu tiên và chịu trách nhiệm.
- Developers vẫn có thể (và nên) trao đổi trực tiếp với stakeholders để làm rõ yêu cầu, nhưng vẫn giữ quyền self-managing.
- Sprint Review là điểm giao thoa chính thức: stakeholders được mời để cùng inspect Increment và collaborate về bước tiếp theo.
- Scrum Master bảo vệ team khỏi sự can thiệp giữa Sprint và giáo dục stakeholders về cách Scrum vận hành.
- Câu thần chú cho phòng thi: Stakeholders đưa đầu vào và phản hồi; Product Owner quyết định; Developers tự quản lý.