Stakeholder và comms: RACI, đối tượng, nhịp độ
Cách map stakeholder vào ma trận RACI, quyết định ai nghe gì với nhịp nào, và viết comms plan ngăn họp 'tôi không biết'.
Mục lục
Lý do phần lớn dự án trông có vẻ hỗn loạn không phải vì việc engineering quá khó, mà vì chưa ai map ra ai cần biết cái gì. Một stakeholder nào đó bị bất ngờ, ghé qua "giúp một tay", và một giờ giải thích đã ngốn mất cả buổi chiều của team. Chương này giới thiệu hai artifact - ma trận RACI và comms plan - giúp ngăn cái giờ đó xảy ra ngay từ đầu.
Khi nào việc map stakeholder chính thức bắt đầu mang lại giá trị?
Có ba tín hiệu chính.
Có hơn 5 người quan tâm tới kết quả. Dưới năm người, bạn vẫn nhớ tên hết và một channel Slack là đủ phủ comms. Vượt qua đó, bạn không còn giữ được trong đầu việc ai đã nghe gì vào lúc nào.
Có phụ thuộc đa chức năng. Sales muốn chốt ngày launch, Legal cần review điều khoản, Bảo mật cần ký phê duyệt, Marketing cần asset thương hiệu. Mỗi bên là một đối tượng có nhu cầu thông tin và nhịp khác nhau.
Việc giao hàng có khách hàng hoặc lãnh đạo nhìn thấy. Khi một VP hoặc khách hàng sẽ đánh giá kết quả, họ cần cảm thấy được thông báo đầy đủ - tức là phải có comms plan, chứ không phải các bản update ngẫu nhiên.
Nếu dự án nội bộ, team nhỏ, và bạn có thể đọc tên hết mọi stakeholder trong một hơi thở, hãy bỏ qua phần chính thức hoá và dùng một channel Slack là đủ.
Cái giá khi không map stakeholder là gì?
Có ba kiểu lỗi kinh điển.
Họp bất ngờ. Một VP đọc về dự án của bạn từ slide bán hàng và kéo bạn vào một "buổi alignment". Buổi đó tiêu tốn nửa ngày của team chỉ để chuyển ngữ cảnh. Nếu có comms plan từ trước, VP đã có tên trong danh sách digest hàng tháng và sẽ không bị bất ngờ.
Phải làm lại quyết định. Engineering ship xong tính năng; Legal vào review sau khi đã ship và yêu cầu thay đổi. Hai tuần làm lại. Cách phòng: xếp Legal vào nhóm Consulted ở khâu scope, chứ không chỉ là Informed.
Tiếng to thắng tiếng nhỏ. Một stakeholder thống trị mọi buổi review vì không có giọng nói nào khác được mời chính thức. PM rốt cuộc chỉ phục vụ ưu tiên của một người, thay vì phục vụ ưu tiên của cả dự án.
Ma trận RACI tối thiểu trông thế nào?
Với một team 5 người, một bảng markdown duy nhất cho mỗi dự án là đủ:
# RACI — {{ Tên dự án }}
R = Responsible (làm việc) - nhiều
A = Accountable (duyệt) - đúng một
C = Consulted (hỏi trước) - vài
I = Informed (báo sau) - nhiều
| Item / Quyết định | Sponsor | TL | PM | EM | QA | Design | Legal | Sales |
|-------------------------|---------|----|----|----|----|--------|-------|-------|
| Go / no-go dự án | A | C | R | C | - | - | C | I |
| Kiến trúc (DB lưu) | I | A | I | C | - | - | - | - |
| Scope tính năng | A | C | R | C | C | C | - | C |
| Ngày launch | A | C | R | C | C | - | I | C |
| Copy hiển thị user | I | - | C | - | - | A | C | C |
| Chính sách giữ data | I | C | C | - | - | - | A | - |
| Quyết định tuyển | I | C | - | A | - | - | - | - |
| Chọn vendor | A | C | R | - | - | - | C | - |
Lỗi lớn nhất là có hai A trên cùng một hàng. Ma trận sẽ trở nên vô dụng khi câu trả lời là "cả hai cùng quyết". Khi không chọn được duy nhất một người, hãy escalate lên sponsor và ép ra câu trả lời.
Comms plan trông thế nào?
Đối tượng được map vào nhịp và channel cụ thể:
# Comms Plan — {{ Tên dự án }}
## Đối tượng
| Đối tượng | Thành viên | Nhịp | Channel | Định dạng |
|------------------|----------------------|-------------|---------------------|----------------------|
| Team đang làm | Engineer, TL, QA, Design | Hàng ngày | #project-{{name}} | Note standup |
| Review dự án | Trên + EM, PM | Tuần | sync 30 phút + doc | Status report (RAG) |
| Stakeholder | Trên + Sales, Legal, Marketing | 2 tuần | Email digest | Exec summary 1 trang |
| Sponsor lãnh đạo | VP / CTO | Tháng | sync 15 phút | Top 3 rủi ro + ETA |
| Khách / công khai | Customer success | Khi launch | Release notes | Cái gì đổi |
## Trigger escalation (bỏ qua nhịp)
- Trượt schedule > 1 tuần: báo sponsor trong 24h
- Rủi ro nghiêm trọng thành sự thật: báo sponsor ngay
- Cắt scope: báo mọi C và A trước khi quyết
- Sự cố production: xem [chương incident](/tech-pm/incident-and-rollback)
Phần "trigger escalation" là phần bị bỏ qua nhiều nhất. Đó chính là cái biến comms plan từ một thứ trình diễn thành một công cụ quản lý rủi ro thật sự. Khi có chuyện, bạn đã thoả thuận sẵn từ trước về việc ai cần được thông báo.
Scale lên đa team như thế nào?
flowchart TB
Active[Ngày: team đang làm<br/>standup] --> Project[Tuần: review dự án<br/>status report]
Project --> Cross[2 tuần: sync xuyên team<br/>roadmap]
Cross --> Org[Tháng: review tổ chức<br/>initiative top]
Org --> Exec[Quý: review lãnh đạo<br/>portfolio]
Mỗi tầng đều tóm tắt lại tầng phía dưới. Một status report của dự án sẽ trở thành một đoạn ngắn trong sync xuyên team; sync xuyên team lại trở thành một slide trong review của tổ chức. Kỹ năng cần có ở đây là nén thật tàn nhẫn: lãnh đạo không muốn đọc một RAID log đầy đủ; họ chỉ muốn ba rủi ro đang cần hành động của họ.
Comms plan có thể tạo ra những lỗi nào?
- RACI tạo ra rồi quên. Template được điền lúc kickoff rồi không ai tham chiếu lại. Cách phòng: mỗi khi sắp đưa ra một quyết định, hãy mở RACI để kiểm tra xem ai cần có mặt trong cuộc họp. Cập nhật RACI khi dự án thay đổi.
- Nhịp họp như diễn kịch. Cuộc họp status một giờ mỗi tuần mà chẳng ai đặt câu hỏi - tất cả chỉ ngồi xem slide. Cách phòng: chỉ họp khi có quyết định cần làm; còn lại thì gửi doc.
- Stakeholder im lặng. Một stakeholder có tên trong danh sách phân phối nhưng không bao giờ đọc email. Đến khi launch, họ xuất hiện với những quan ngại bất ngờ. Cách phòng: cứ mỗi 4 tuần, hỏi thẳng từng người I/C "bạn có nhận được cái cần thiết từ các bản update này không" - nếu không, hãy thay đổi định dạng.
- Comms quá liều. Gửi email mỗi ngày cho lãnh đạo. Trong đầu họ sẽ unsub, và bạn mất luôn channel để dùng khi thật sự cần. Hãy khớp nhịp với nhu cầu của từng đối tượng.
Khi nào RACI là quá liều?
Có hai trường hợp.
Dự án chỉ có hai người. RACI lúc này là gánh nặng. Cả hai cùng quyết mọi thứ; comms plan đơn giản chỉ là một DM trên Slack.
Team rất tự chủ với charter rõ ràng. Một team platform sở hữu mảng việc của mình hoàn toàn thì không cần RACI cho việc thường xuyên; chỉ cần dùng RACI khi ra quyết định xuyên team.
Ma trận này chỉ thật sự đáng đầu tư khi trách nhiệm còn mơ hồ - mà với những dự án vượt 3+ chức năng thì gần như luôn luôn là vậy.
Đi tiếp từ đây như thế nào?
Chương tiếp theo: scope và đánh đổi - cách phản ứng khi stakeholder muốn nhiều hơn, nhanh hơn, mà vẫn giữ nguyên budget. Sau đó, các chương về phương pháp (Scrum cơ bản) sẽ nói về nhịp chạy bên trong team.