二、项目启动与团队组建：干系人识别、角色分工与沟通计划

项目启动会一开，事情就真得开始往前推了。说实话，很多数据保护项目在启动阶段就开始埋坑，后面再想填回来，代价高得吓人。我个人习惯，拿到授权后的第一件事不是画PPT，而是先把人认清楚——谁是给资源的，谁是来帮忙的，谁是来挑毛病的。

你想想看，数据保护项目天然就牵扯多个部门。IT、法务、业务、风控，每家都有自己的小算盘。如果启动阶段没把这些关系理清楚，后面开会就是大型甩锅现场。

干系人识别：别漏掉那个不发言的人

干系人识别，说白了就是弄清楚谁会受影响、谁有话语权、谁能让你项目黄掉。我见过最惨的案例，项目经理从头到尾只跟IT部门沟通，结果交付验收时，法务跳出来说方案不合规。项目立刻停摆，返工整整两个月。

干系人识别一般分三步走：

1. 列出全量清单——把所有可能沾边的人都写下来，宁多勿少
2. 评估影响力和兴趣度——画一个四象限图，把干系人填进去
3. 制定沟通策略——高影响力高兴趣的人要重点管理，低影响力低兴趣的人定期同步就行

我曾经在金融项目里，把财务部的预算分析员也列进了干系人清单。同事还笑我小题大做。结果这位分析员在中期审核时提了一条资金划拨的意见，差点导致项目断粮。要不是提前跟她对过需求，那一下真扛不住。

下面这个表格是我们常用的干系人分类表，你可以直接拿来用：

角色分工：RACI矩阵是救命工具

团队搭起来之后，最怕的就是责任不清。我早期带项目时吃过这亏——一份数据分类报告，技术说该业务做，业务说这是技术活，来回扯皮一周。

后来我强制团队用RACI矩阵（责任分配矩阵）来定分工。RACI四个字母代表：

• R（Responsible）——实际干活的人
• A（Accountable）——最终拍板的人
• C（Consulted）——需要征求意见的人
• I（Informed）——只需要知道结果的人

这里要注意：一个任务只能有一个A，但可以有多个R。如果A太多，等于没人拍板。我曾经就踩过这个坑——给数据脱敏任务设了两个A，结果两个人互相等对方决策，活硬是拖了两周。

下面是我们项目里的典型团队角色和对应职责：

沟通计划：别让信息砸在手里

团队配齐了，责任也划清了，接下来最关键的一步：怎么让所有人保持在同一个频道上。

沟通计划不是写一纸公文就完事。它要回答几个实际问题：

• 什么信息，用什么渠道，以什么频率，给什么人看？
• 谁负责产出，谁负责审批？
• 出了异常，升级路径是什么？

我建议把沟通计划分成三类：

1. 例行沟通——每日站会、周报、月汇报。这些是固定节奏，不能断
2. 事件驱动沟通——遇到风险、变更、里程碑交付时，即时触发
3. 存档式沟通——会议纪要、决策记录、验收报告，全部纳入文档管理

举个例子，我们在数据保护项目中常用的沟通矩阵：

这里特别提醒一下：沟通计划写出来不是摆设。我见过太多项目，启动阶段弄了一份漂亮的沟通计划，后面就把文件锁在共享盘里吃灰。记住，沟通计划至少每两周要审视一次，看看有没有人掉队、有没有信息盲区。

本章核心逻辑一览

启动阶段做扎实，后面至少省一半精力。干系人识别解决的是“跟谁对齐”，角色分工解决的是“谁干什么”，沟通计划解决的是“信息怎么流动”。这三件事互相咬合，缺一不可。

下面这张图总结了本章的知识体系，你一看就明白：