Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Stakeholder là ai, cách xác định cho đủ, cách phân tích bằng ma trận Quyền lực / Sự quan tâm, và cách làm việc với từng nhóm suốt vòng đời dự án.
Một BA lấy yêu cầu đầy đủ từ người dùng, viết tài liệu chỉn chu, dev làm đúng tài liệu. Đến vòng UAT thì một trưởng phòng chưa từng xuất hiện trong dự án đọc qua và bảo quy trình này không dùng được vì vướng qua bộ phận của họ. Cả tính năng làm lại. Chuyện này xảy ra không phải vì BA phân tích kém, mà vì thiếu một cái tên trong danh sách bên liên quan.
Đó là lý do stakeholder — bên liên quan — là thứ BA phải nắm trước khi nắm bất cứ kỹ thuật phân tích nào. Bài viết này trả lời ba câu hỏi: stakeholder là gì, làm thế nào để xác định họ, và làm việc với họ ra sao.
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 đó.
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á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ộ:
Thường là stakeholder bên ngoà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ọ.
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.
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.
Đâ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.
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.
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.
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.
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:
Tên / Nhóm | Quan tâm chính | Duyệt hoặc chặn được gì | Thái độ | Cách giữ liên lạc |
|---|---|---|---|---|
Chị Lan, TP. Vận hành | Không muốn tăng thao tác cho nhân viên | Duyệt mọi thay đổi quy trình kho | Trung lập | Họp 1-1, 2 tuần/lần |
Đội thu ngân (12 người) | Máy phải chạy nhanh giờ cao điểm | Không duyệt gì, nhưng họ kêu là sếp nghe | Ủng hộ | Demo cuối sprint |
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.
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.
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: 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.
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:
Đ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.
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.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận