Stakeholder là ai? Cách xác định và làm việc với Stakeholder

Stakeholder là gì? Là ai trong dự án?

Định nghĩa

Stakeholder, hay bên liên quan, là bất kỳ cá nhân, nhóm hoặc tổ chức nào có quan hệ với nhu cầu, sự thay đổi hoặc giải pháp mà dự án đang xử lý. Họ có thể ảnh hưởng, bị ảnh hưởng, hoặc chỉ đơn giản là cho rằng mình bị ảnh hưởng — cả ba trường hợp đều khiến họ trở thành người BA phải tính đến. Mỗi bên mang một lợi ích, kỳ vọng và mối quan tâm riêng.

Danh sách này rộng hơn nhiều so với khách hàng và nhà đầu tư. Người sẽ dùng sản phẩm, người vận hành hệ thống sau khi bàn giao, người quản lý có mục tiêu chiến lược gắn với dự án, cơ quan pháp lý ra quy định phải tuân thủ, cộng đồng chịu tác động — tất cả đều nằm trong đó.

Vì sao stakeholder quan trọng trong dự án phần mềm

• Nguồn cung cấp thông tin và yêu cầu: Họ hiểu rõ vấn đề kinh doanh cần giải quyết, nhu cầu thực tế của người dùng và các yêu cầu chức năng, phi chức năng của hệ thống.
• Phản hồi và xác nhận: Stakeholder cho ý kiến về các giải pháp được đề xuất và xác nhận sản phẩm có đáp ứng kỳ vọng hay không.
• Yếu tố ảnh hưởng: Mức độ ủng hộ hoặc phản đối của họ tác động trực tiếp đến tiến độ, phạm vi và kết quả cuối cùng.
• Người dùng tương lai: Với dự án hướng người dùng, người dùng cuối thường là nhóm quan trọng nhất vì sản phẩm sinh ra để phục vụ họ. Nhưng đừng mặc định điều đó đúng ở mọi dự án — với dự án tuân thủ hay tích hợp hệ thống nền, cơ quan quản lý hoặc chủ quy trình mới là bên có tiếng nói nặng nhất.

Hiểu rõ ai là stakeholder và mức độ liên quan của từng người là nền tảng để BA khơi gợi yêu cầu chính xác và xây dựng giải pháp phù hợp.

Các loại stakeholder bạn sẽ gặp

Cách phân loại phổ biến nhất là chia theo nội bộ và bên ngoài. Nhưng phải nói rõ trước một điều mà nhiều tài liệu bỏ qua: nội bộ hay bên ngoài là xét từ tổ chức bạn đang đứng, không phải thuộc tính cố định của một vai trò.

Bạn làm cho công ty outsource thì toàn bộ phía khách hàng — kể cả sponsor và người dùng cuối của họ — đều là bên ngoài. Bạn làm in-house thì chính sponsor và phòng ban dùng hệ thống lại là nội bộ, còn nhà thầu phần mềm mới là bên ngoài. Cùng một người, hai dự án, hai nhóm khác nhau. Vì vậy hãy đọc danh sách dưới đây như ví dụ theo bối cảnh, đừng học thuộc như bảng phân loại cứng.

Thường là stakeholder nội bộ:

• Project team (BA, Project Manager, Developer, Tester…): những người trực tiếp tham gia xây dựng và triển khai giải pháp.
• Ban quản lý / Người tài trợ (Sponsor): những người có quyền quyết định về nguồn lực, ngân sách và định hướng chiến lược. Ở dự án outsource, sponsor lại nằm phía khách hàng.
• Bộ phận kiểm soát nội bộ, pháp chế, an ninh thông tin: đặt ra ràng buộc mà giải pháp phải tuân theo, giống vai trò của cơ quan quản lý nhưng ở trong nhà.

Thường là stakeholder bên ngoài:

• Người mua (purchaser): bên ký hợp đồng và trả tiền cho dự án.
• Khách hàng: bên sử dụng sản phẩm, dịch vụ của doanh nghiệp và có những quyền mà doanh nghiệp phải đáp ứng. Không phải lúc nào khách hàng cũng là người bỏ tiền mua.
• Người dùng cuối (End-users): nhóm trực tiếp thao tác với hệ thống hằng ngày. Nhóm này nằm trong hay ngoài tuỳ góc nhìn: công ty mua phần mềm cho nhân viên dùng thì với công ty đó, người dùng cuối là nhân viên nội bộ; còn với đội làm phần mềm, họ là bên ngoài.
• Đối tác: các công ty hợp tác hoặc tích hợp với hệ thống của bạn.
• Nhà cung cấp: cung cấp dịch vụ hoặc thành phần cần thiết cho dự án.
• Cơ quan quản lý: đưa ra các quy định mà dự án phải tuân thủ, ví dụ quy định về bảo mật dữ liệu.
• Cộng đồng: những nhóm người có thể bị ảnh hưởng, thường gặp ở dự án liên quan đến môi trường hoặc xã hội.

Nhận diện được các bên này là bước đầu tiên để không bỏ sót ai, và cũng để không bỏ sót mối quan tâm nào của họ.

Xác định stakeholder — bước đầu tiên quan trọng

Sau khi hiểu stakeholder là ai nói chung, việc tiếp theo của BA là xác định stakeholder cụ thể cho từng dự án. Việc này nên làm càng sớm càng tốt.

Vì sao phải xác định cho đủ

Bỏ sót một stakeholder quan trọng đồng nghĩa với bỏ lỡ những yêu cầu thiết yếu, hoặc không lường trước được phản đối sẽ nổ ra về sau. Hậu quả thường thấy là change request dồn dập ở giai đoạn cuối, chậm tiến độ, nặng hơn là dự án đổ.

Không ai lập được danh sách hoàn hảo ngay từ ngày đầu, và cũng đừng đặt mục tiêu đó. Việc cần làm là lập một danh sách đủ rộng càng sớm càng tốt, rồi rà lại ở mỗi mốc dự án và mỗi khi có thay đổi về phạm vi hay tổ chức.

Các kỹ thuật để xác định stakeholder

• Brainstorming: ngồi lại với project team và các thành viên chủ chốt để cùng liệt kê tất cả những ai có thể liên quan.
• Phân tích cấu trúc tổ chức: xem sơ đồ tổ chức của công ty khách hàng hoặc công ty bạn để nhận diện các phòng ban và vị trí liên quan trực tiếp hoặc gián tiếp.
• Phân tích tài liệu dự án: tài liệu ban đầu, đề xuất dự án, hợp đồng, báo cáo hiện có thường nhắc đến các bên liên quan chính.
• Phỏng vấn các stakeholder đã biết: khi nói chuyện với những người đầu tiên, hãy hỏi họ xem còn ai khác cần được tham vấn. Cách này thường lôi ra được những cái tên không xuất hiện ở bất kỳ sơ đồ tổ chức nào.
• Vẽ phạm vi giải pháp (scope model): phác ranh giới hệ thống rồi nhìn xem ai đứng ngoài ranh giới đó mà vẫn gửi hoặc nhận dữ liệu. Mỗi mũi tên đi qua ranh giới thường ứng với một stakeholder.

Đây là những kỹ thuật tiêu biểu, không phải danh sách đầy đủ. BABOK còn mô tả các kỹ thuật khác như Stakeholder List, Map hoặc Personas để lưu lại kết quả nhận diện.

Trên thực tế, phần lớn dự án chỉ xác định các stakeholder liên quan trực tiếp, và danh sách vẫn dài ra khi dự án chạy — đó là chuyện bình thường, miễn là bạn có nhịp rà lại.

Phân tích stakeholder và ma trận Quyền lực / Sự quan tâm

Có danh sách rồi thì tới câu tiếp theo: trong đống người đó, ai là người bạn phải để mắt nhất? Không phải ai cũng có tiếng nói như nhau, và không phải ai cũng quan tâm dự án ở cùng một mức.

Nói trước cho đỡ hoang mang: ở dự án thật, phần lớn BA junior làm việc này bằng cách nói chuyện, nhớ mặt và vài dòng note, chứ không mở file nào ra vẽ. Bản bài bản thường là việc của PM hoặc BA lead. Nhưng cách nghĩ bên dưới thì bạn dùng gần như mỗi ngày, và tên của nó hay bị hỏi khi phỏng vấn, nên biết vẫn hơn.

Ma trận Quyền lực / Sự quan tâm

Cách nghĩ đó là xếp người theo hai trục: họ quyết hoặc chặn được đến đâu (Quyền lực), và họ để tâm tới dự án đến đâu (Quan tâm). Bốn ô, bốn kiểu cư xử:

Phỏng theo Power–Interest Grid, hay được gọi là ma trận Mendelow. Nhãn bốn ô có vài biến thể giữa các tài liệu, dưới đây là bản hay gặp nhất.

• Quyền lực cao / Quan tâm cao — Quản lý chặt chẽ (Manage Closely). Nhóm phải bám sát nhất: hỏi sớm, cập nhật đều. Ví dụ: sponsor, khách hàng chính.
• Quyền lực cao / Quan tâm thấp — Giữ hài lòng (Keep Satisfied). Quyết được nhưng không muốn nghe chi tiết. Cập nhật ngắn, đúng hẹn, đừng dội thông tin. Ví dụ: lãnh đạo cấp cao không trực tiếp tham gia.
• Quyền lực thấp / Quan tâm cao — Luôn thông báo (Keep Informed). Không quyết được, nhưng hiểu nghiệp vụ sâu nhất. Hỏi kỹ và báo đầy đủ. Ví dụ: người dùng cuối, nhân viên trực tiếp vận hành.
• Quyền lực thấp / Quan tâm thấp — Giám sát tối thiểu (Monitor). Báo khi cần, vậy thôi. Ví dụ: các phòng ban ít liên quan.

Một điều quan trọng hơn cả bốn cái ô: ô nào là do bạn đánh giá, không phải do chức danh quyết. Đội thu ngân nghe thì có vẻ quyền lực thấp, nhưng nếu họ là người ký nghiệm thu UAT thì họ nằm ở ô “Quản lý chặt chẽ” ngay từ đầu. Ông trưởng phòng ở đầu bài cũng vậy — trên sơ đồ tổ chức, ông ấy chẳng liên quan gì tới dự án. Nên khi xếp ai vào ô nào, bám vào thứ kiểm chứng được: ai phê duyệt, ai nắm ngân sách, ai chặn được dự án.

Ma trận này không phải RACI. RACI lập theo từng đầu việc để phân ai làm, ai chịu trách nhiệm cuối, ai cần hỏi, ai chỉ cần báo — chuyện đó để một bài riêng. Ở đây ta đang xếp con người, không xếp công việc.

Ghi lại: bảng note stakeholder

Phân tích xong mà để trong đầu thì tuần sau quên. Không cần biểu mẫu gì cả — một bảng trong Excel hay Notion, năm cột, là đủ dùng. Tên bài bản của nó là stakeholder register, nhưng bản của bạn chỉ cần thế này:

Cột Thái độ là thứ ma trận không nói cho bạn biết: hai trục kia cho biết ai đáng để ý, chứ không cho biết người đó đang ủng hộ hay đang chống. Một người quyền lực cao đang phản đối cần cách tiếp cận khác hẳn người quyền lực cao đang ủng hộ. Và vì bảng này là đánh giá về người thật, hãy dùng từ trung tính — đừng ghi “khó tính” hay “hay chống đối” vào file mà cả công ty mở được.

Làm việc và quản lý stakeholder

Khi đã xác định và phân tích xong, phần việc chiếm nhiều thời gian nhất mới bắt đầu: làm việc với họ, mỗi ngày, suốt dự án. Đây không phải vài cuộc gặp riêng lẻ mà là một chu trình chạy suốt vòng đời dự án — giao tiếp, thu phản hồi, rồi điều chỉnh lại cách tương tác khi vai trò hoặc mức ảnh hưởng của họ thay đổi.

Nền tảng là giao tiếp

• Lắng nghe chủ động: nghe cả lý do đằng sau câu nói — động lực, mối quan tâm, và cả cảm xúc mà người ta không nói thẳng ra.
• Dùng ngôn ngữ phù hợp với người nghe: BA là cầu nối ngôn ngữ, cần diễn đạt được thông tin kỹ thuật cho đội dự án và chuyển sang văn phong nghiệp vụ dễ hiểu cho khách hàng.
• Truyền đạt rõ ràng và kịp thời: thông tin phải chính xác, dễ hiểu, và đến đúng lúc người ta còn kịp dùng nó.

Tương tác khi khơi gợi yêu cầu

Stakeholder là nguồn cung cấp chính các yêu cầu cho dự án. BA cần dùng các kỹ thuật khơi gợi phù hợp như phỏng vấn, workshop, khảo sát. Quan trọng nhất là biết đặt câu hỏi mở, câu hỏi thăm dò, và đủ kiên nhẫn làm rõ cho tới khi hiểu được nhu cầu gốc rễ chứ không dừng ở câu trả lời đầu tiên.

Quản lý kỳ vọng và xử lý mâu thuẫn

Quản lý kỳ vọng: thiết lập cách hiểu chung về phạm vi, tiến độ và kết quả mong đợi ngay từ đầu, rồi thông báo kịp thời mỗi khi có thay đổi ảnh hưởng đến những thứ đó.

Xử lý mâu thuẫn: mâu thuẫn giữa các stakeholder, hoặc giữa stakeholder với project team, là chuyện khó tránh. BA giữ vai trò trung gian: lắng nghe quan điểm các bên, phân tích nguyên nhân gốc rễ và tìm phương án dung hòa. Một điểm cần rõ ngay từ đầu dự án: BA không mặc nhiên là người chốt. Ai có quyền phê duyệt phải xác định theo governance của dự án — có nơi là PO, có nơi là sponsor, cũng có nơi chính BA giữ quyền đó. Đừng suy ra thẩm quyền từ chức danh; hỏi thẳng và ghi lại.

Duy trì quan hệ suốt vòng đời dự án

Chữ "quản lý" trong stakeholder management không mang nghĩa điều khiển. Nó là quản lý mối quan hệ và quản lý luồng thông tin, gồm bốn việc lặp đi lặp lại:

• Lập kế hoạch giao tiếp: xác định tần suất, kênh liên lạc và nội dung cần chia sẻ với từng nhóm — chính là cột cuối trong bảng note ở trên.
• Thực hiện giao tiếp: gửi báo cáo tiến độ định kỳ, tổ chức họp cập nhật, phản hồi câu hỏi đúng lúc người ta còn cần.
• Thu phản hồi và giải quyết vấn đề: xử lý nhanh các vướng mắc phát sinh, đừng để dồn tới cuối sprint.
• Đánh giá lại định kỳ: cập nhật lại bảng note và vị trí trên ma trận khi vai trò, quyền lực, sự quan tâm hoặc thái độ của họ thay đổi. Có thay đổi tổ chức phía khách hàng là phải rà lại ngay.

Kết luận

Điều đáng nhớ nhất là thứ tự: xác định trước, phân tích sau, rồi mới chọn cách tương tác. Nhảy thẳng sang bước giao tiếp khi chưa biết ai thực sự có quyền chốt là lý do phổ biến khiến yêu cầu bị lật ở phút cuối, đúng như tình huống mở đầu bài này.

Việc làm được ngay ở dự án bạn đang tham gia: trả lời bốn câu này.

• Ai là người phê duyệt kết quả? Bạn đã nói chuyện trực tiếp với họ chưa?
• Ai sẽ vận hành hệ thống sau khi bàn giao? Họ đã được hỏi ý kiến chưa?
• Ai chịu tác động hằng ngày mà bạn chưa từng gặp mặt?
• Ai có thể chặn dự án lại, dù không nằm trong danh sách chính thức nào?

Câu thứ tư thường là câu khó nhất, và cũng là câu cứu bạn ở vòng UAT.