项目立项如何做好项目成员？研发团队风险控制与操作步骤

我带过的一个项目，立项评审会上五个人签字确认了成员名单，三个月后其中一个核心模块停摆了两周。原因不是技术难，是立项文件里写着的那位架构师同时挂在另外两个项目上，谁也没写清楚他一周到底能投多少时间。事后复盘，项目经理说了一句让我记到现在的话：我们立项时定了”谁参与”，但从没定”谁离开时项目还能不能跑”。

这就是《项目立项如何做好项目成员？研发团队风险控制与操作步骤》这个题目真正的难点。大部分团队的立项文档里，成员那一栏就是一张名字表：姓名、角色、投入比例。看起来规范，实际上什么都没约束住。而在我过去几年参与或复盘的十几个中大型研发项目里，真正在中期出问题的几乎都不是技术选型错了，而是立项期的人员结构里埋了雷，单点依赖、接口空白、退出条件缺失。

这篇文章我打算把这件事讲透：立项阶段到底应该怎么”做成员”，怎么把人的不确定性转成可管理的工程问题，以及在 20 人团队、百人组织、多产品线公司里分别应该怎么取舍。文中涉及具体数字的部分我会标注口径和来源，属于推演的会明确说明是模拟数据。

一、核心结论：立项期的成员设计是风险对冲，不是人员排班

1. 立项阶段真正决定成败的，不是谁参与，而是谁离开时项目还能不能跑

我先给一个可能有点反常识的判断：立项评审时最值得花时间的，不是确认”这个项目需要三个前端两个后端一个算法”，而是回答”如果这三个人里有一个下个月被调走、离职或者被更高优先级项目抽走，项目会怎么样”。

绝大多数立项会的讨论顺序是：目标 → 范围 → 排期 → 人员。人员永远放在最后，因为大家默认它是”填进去就行”的一栏。但从风险传导的顺序看恰好相反：排期是从人员能力推导出来的结果，人员这一栏一旦模糊，排期就是虚构的。

我更愿意把立项期的成员设计理解成一次风险对冲设计：你花的不是排班时间，而是买保险的时间。保险本身不产生任何功能，但它决定了你在事故发生的那一刻，损失的是两周还是两个月。

2. 成员设计必须交出四份可评审的交付物，而不是一张名单

如果立项评审最终要签字，我认为成员部分至少要交出四份东西，缺任何一份都不该通过评审。

• 角色交付物映射表：每个角色对应哪些可验收的交付物，而不是对应哪些任务。
• 单点依赖清单：哪些能力只有一个人具备，他不可用时会发生什么。
• 接口契约表：角色之间交接什么、多久交接一次、交接完成的判定标准是什么。
• 退出与替换预案：关键角色不可用时的触发条件、交接窗口和知识留存方式。

这四份东西的名字听起来很重，但真正填起来，一个有经验的项目经理半天就能拉出初稿。真正难的不是写，是团队在立项阶段是否愿意当面承认”人是可能会走的”。

这四份交付物里，前三份解决的是”当下能不能跑”，第四份解决的是”出事之后多久能恢复”。它们的价值不在立项当天体现，而是在项目第 3 到第 6 个月的项目中期，也就是新鲜感消退、资源开始被争夺的那个阶段。

3. 为什么百人以上组织必须把这一步提前到排期之前

50 人以下的团队，成员设计做得糙一点通常也能扛住，因为沟通成本低，出了问题大家抬头喊一嗓子就能对齐。但组织一旦超过 100 人、项目跨越两个以上部门，信息就不再是”喊一嗓子”能传递的了，它必须被写下来、被确认、被追踪。

这也是我在服务中大型研发组织时一个很明确的体会：规模越大，立项期成员设计的边际收益越高。它节省的不是一个人的时间，而是几十次跨部门对齐会议，以及因为责任不清而反复回滚的需求。

二、三个真实翻车现场：立项期的成员决策是怎么把风险埋进去的

下面三个案例都来自我实际参与或深度复盘的研发项目。为了不暴露具体公司，我对业务场景做了模糊处理，但结构性问题和关键数字保留了原始记录。

1. 案例一：明星阵容拼盘，两个月后没人对接口负责

某电商中台重构项目，立项时为显示重视程度，把四个部门的骨干都拉进了项目组：架构师来自基础架构部，前端来自交易团队，算法来自数据团队，后端来自中台团队。评审会上每个人都表态”全力支持”，成员名单漂亮得像一份公司技术委员会的名单。

问题出在第二个月。算法侧要向后端交付特征工程的数据结构，后端要向前端交付查询接口，但这两条链路上没有任何一个角色被明确指定为”接口负责人”。算法认为自己只负责模型效果，后端认为字段定义该由算法给出，前端则一直在等后端冻结接口。

最后这个模块延期 34 天，复盘时统计的返工工时约 220 人时，其中超过一半花在了三次接口重定义上。这个项目的成员名单没有任何问题，问题在于名单上没有”接口”这个角色。

2. 案例二：把”某人熟悉”当成”系统可维护”

某制造企业的生产系统改造项目，核心的旧系统只有一位入职九年的工程师真正熟悉。立项时他顺理成章被列为技术负责人，所有人的判断都是”有他在就稳了”。

但立项文件里没有一条要求他做知识转移。第六个月，他被抽调去支援另一个优先级更高的国产化替代项目，交接只用了三天。接手的新同事让本地构建流程重新跑通，花了整整五周。

这个案例的教训不是”不该依赖老员工”，而是立项时必须区分”这个人现在能兜住”和”这个系统在他离开后还能不能维护”，这是两个完全不同的风险等级。前者靠人，后者靠沉淀。

3. 案例三：没写退出条件，中期换人把两个月拖成四个月

某金融行业的风控模块项目，立项时明确写着”由某同事负责风控规则引擎直到上线”。到了第四个月，他被调去做一个合规专项，项目组的处理方式是”临时找人顶上”。

问题是这个模块的规则库里有大约 30% 的判定逻辑只存在于他个人的本地笔记里，代码里连注释都没有对应说明。新接手的人光是把这些隐性规则还原出来，就花了近三周，整个模块延期 58 天。

如果立项时写过一条”该角色不可用时的交接窗口为 5 个工作日，交接物必须包含规则映射表和本地脚本入库记录”，这三周至少能压缩到一周以内。

4. 这三个案例的共同结构

把三个案例并排看，会发现它们的失败结构高度一致：立项时都有一份看起来完整的成员名单，都缺少单点依赖识别，都把跨角色协作默认为”到时候自然会协调”，都没有定义触发条件和交接窗口。

它们不是管理能力问题，而是立项阶段的成员设计缺少标准动作。这一点很关键，因为如果是能力问题，你只能换人；如果是流程缺失，你补上一套动作就能覆盖大部分团队。

三、立项期成员设计最常见的六个误区

1. 误区一：把成员名单当成成员设计

这是最普遍的一个。名单回答的是”谁在这个项目里”，成员设计回答的是”谁对什么负责、谁不可替代、谁走了怎么办”。前者是一页纸的信息，后者是一套可执行的结构。

判断方法很简单：把你的立项文档成员页拿给一个不相干的人看，如果他说不出”哪个角色出问题会导致什么后果”，那这份文档就只是名单。

2. 误区二：按工时占比分人，而不是按决策权分人

很多立项文档写的是”某某 30% 投入”。但 30% 投入到底意味着什么？是每周 1.5 天的开发时间，还是拥有 30% 的需求决策权？两者差别巨大。

我在复盘时发现，技术方案反复摇摆的项目，往往不是人手不够，而是决策权没有落到具体角色头上。三个人各占 30% 投入，等于三个人的决策权都是 0。

3. 误区三：只评估个人能力，不评估协作带宽

一个技术能力 9 分、但同时挂在 3 个项目上的人，实际可用带宽可能只有 2 分。立项时如果只填”能力评价：优秀”，这个信息就被完全掩盖了。

我的做法是在成员表里强制加一列”当前并行项目数”，并要求超过 2 个并行项目的成员，必须在立项评审上说明时间分配方案。

4. 误区四：风险登记表写成许愿清单

常见写法是”风险：人员流失；应对措施：加强沟通、提高满意度”。这不是风险登记，这是愿望表达，因为它没有触发条件和责任人。

一条合格的成员风险记录应该是这样的：风险=架构负责人被抽调；触发条件=其被指派参与其他项目立项；应对动作=启动备份人接管，5 个工作日内完成决策记录交接；责任人=项目经理。有触发条件、有动作、有责任人、有时限，才叫风险控制。

5. 误区五：立项会上回避”谁不进这个项目”

这一点在跨部门项目里特别明显。立项会上所有人都在讨论”要拉谁进来”，没人讨论”应该把谁排除在外”。结果是项目组越来越大，职责越来越含糊，每个模块都有三四个”参与人”。

成员设计的另一半价值，恰恰在于明确谁不在项目组里。边界不清楚，协作成本就会无限膨胀。

6. 误区六：把”加人”当成风险的解决方案

项目一延期，最常见的反应是加人。但对于已经进入中期的研发项目，加人的边际收益极低，新人需要熟悉上下文，而这个上下文往往只存在于现有成员的脑子里。

我更认同的做法是：中期把资源投向”接口梳理”和”知识交接”，而不是投向”增加人手”。前者解决的是信息传递效率，后者只是增加了沟通节点。

四、专业判断逻辑：用”角色，接口，风险”三张表把成员问题变成可管理问题

讲完误区和案例，接下来是我自己在项目里反复用的一套判断工具。它的核心思路只有一句话：把”人”的问题，翻译成”角色、接口、风险”三类结构化信息。因为人的忠诚度、情绪、职业规划都无法在立项文档里被约束，但角色边界、接口标准、退出条件可以。

1. 角色风险矩阵：先识别单点依赖，再谈人员配置

第一张表是角色风险矩阵。它的作用是回答”这个项目里，哪些角色是不能出问题的”。

我会给每个角色打一个「单点依赖指数」，取值 0 到 1，由三个因子相乘得出：该角色独有知识的占比、该角色在关键路径上的位置权重、以及从内部或市场上找到替代者的难度。指数越高，说明这个角色越危险。

实际使用中我发现一个规律：单点依赖指数超过 0.7 的角色，如果立项时没有指定备份人，中期出问题的概率会显著上升。这个阈值不是理论推导出来的，是我在多个项目复盘后形成的一个经验参照线。

2. 接口契约表：把”配合”翻译成可验收的交接物

第二张表是接口契约表。它要解决的是”两个角色之间到底交接什么”这个问题。

大部分项目在立项时写的是”前端与后端密切配合””算法与工程协同推进”这类话。这些话在评审会上听起来很和谐，但执行时等于什么都没说。接口契约表要求每一对相邻角色必须写清楚三件事：交接物是什么、交接频率是多少、验收标准是什么。

这张表最大的作用不是给别人看，而是逼着团队在立项阶段就把”我以为你会给我”变成”我们约定你什么时候给我”。

3. 退出预案表：给每个关键角色写一份”不可用说明书”

第三张表是退出预案表。它回答的是”如果这个角色明天不能用了，我们怎么办”。

这张表要写四列：触发条件、备份人、交接窗口、必填交接物。其中最容易漏掉的是”必填交接物”，如果只写”做好交接”，实际结果就是三天时间交接了个邮箱密码。

我通常会要求必填交接物里至少包含三类东西：决策记录（为什么这么设计）、未决风险清单（哪些坑还没填）、本地化知识（脚本、笔记、临时方案）。第三类是最容易被忽略的，也是恢复成本最高的。

4. 三张表之间怎么联动

这三张表不是独立的三份文档，而是有明确因果链的：角色风险矩阵识别出高单点依赖的角色，接口契约表定义这些角色与上下游的交接标准，退出预案表则基于前两张表给出不可用时的恢复路径。

换句话说，角色风险矩阵决定”防谁”，接口契约表决定”怎么防”，退出预案表决定”防不住时怎么救”。三张表齐了，立项评审时的成员部分才算是真正可评审的。

五、可直接照做的七步操作法

1. 第一步：从交付物倒推角色，不从组织架构倒推

大部分团队定成员的顺序是”看看有哪些部门，每个部门出个人”。这个顺序天然会带来岗位冗余和职责空白，因为组织架构是为长期运营设计的，不是为某个具体项目设计的。

正确的顺序是：先把项目要交付的东西列出来，然后问”每一个交付物，谁签字负责”，最后把签字责任归并成角色。这样做出来的角色数量通常会比”按部门凑”少 20%，30%，但职责清晰度会高很多。

2. 第二步：给每个角色打单点依赖指数

按上一节说的方法，对每个角色打分。实操中不必过于精确，三个因子各打 0，1 分，相乘即可。

打完分之后做一次排序，把指数最高的两到三个角色拎出来，在立项评审上单独讨论。这一步的价值在于把”感觉上有点危险”变成”纸面上确实是最高风险”。

3. 第三步：定义接口契约与交接物

把上一步识别出的高风险角色作为起点，向上下游各推一层，定义接口契约。经验上，一个 10 人左右的项目组，需要明确定义的接口通常在 8，12 对之间，再多就说明角色切分过细了。

每一条接口契约都要有验收标准。没有验收标准的接口约定，等于没有约定。

4. 第四步：做一次缺席压力测试

这是我认为最有价值、也最容易被跳过的一步。具体做法是：在立项评审会上，随机指定一个关键角色”今天开始不可用”，然后让团队现场推演接下来两周会发生什么。

如果推演结果是”我们也不知道会发生什么”，那就说明这个角色的退出预案完全没有。这一步通常只需要 20 分钟，但它暴露问题的效率远高于任何文档检查。

5. 第五步：写退出与替换预案

针对上一步暴露出来的空白，补齐退出预案。重点是把”必填交接物”写具体，不要写”做好交接”。

我的建议是每个关键角色的交接物不超过五项，但每一项都必须是可验证的实物：一份文档、一个仓库权限、一份脚本、一次面对面的评审记录。

6. 第六步：把人员风险设为立项评审的硬门槛

这一步是让前面五步真正生效的关键。如果人员风险只是”建议项”，它永远会被排期压力挤掉。

我建议设两条硬门槛：一是单点依赖指数均值不得高于 0.6；二是关键角色的退出预案覆盖率不得低于 90%。不达标就不进入排期阶段。这条规则一开始会让人觉得麻烦，但执行两三个项目之后，团队反而会主动在立项前把表填好。

7. 第七步：把角色、权限、交接物落到工具里

最后一步是把前面六步的结论固化到项目管理平台中。写在文档里的角色定义，会随着人员变动慢慢失效；只有落到系统里的角色和权限关系，才能被持续校验。

具体包括：角色与成员绑定、权限按角色分配、交付物与角色关联、成员变更时自动触发交接清单。这一步的详细做法我放在下一节讲。

六、工具落地观察：为什么成员设计必须”进系统”而不是”进文档”

1. 表格化管理的三个失效点

我见过不少团队确实做了角色矩阵和退出预案，但都存在一个共享文档里。半年后回头看，这些文档基本都停止了更新。

表格化管理的失效通常出现在三个地方：一是成员变动时没人更新角色绑定，导致文档和现实脱节；二是权限分配和角色定义是两套东西，角色变了权限没变；三是交接物清单无法自动触发，全靠人记得去要。

这三个失效点的共同特征是：它们都发生在”人已经很忙”的时刻，而人在忙的时候不会主动去维护文档。

2. 平台化落地到底解决了什么

这也是为什么我在这类项目里，会建议中大型组织把成员设计落到项目管理平台上，而不是停在文档层。以我实际用过的 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在成员与角色管理上解决的是几个很具体的问题。

第一是角色和权限的绑定关系。在平台里，角色不是文档里的一个词，而是对应一组实际权限：能看哪些迭代、能改哪些工作项、能审批哪些变更。当项目成员发生调整时，改的是角色归属，权限会自动跟着走。

第二是交付物与角色的关联。前面说的接口契约表，如果只是文档里的一张表，很快就会被遗忘；但如果每个交付物在工作项里都挂着一个”责任人”字段，那么责任人变更时，系统会直接把待交接的交付物列出来。

第三是成员维度的负荷可见性。一个成员同时挂在几个项目、每个项目分配多少工时，在平台上是可聚合的，这样”并行项目数超过 2″这类立项约束条件才有可能被自动检查，而不是靠项目经理记忆。

3. 一个角色与退出预案的落地示例

下面这个配置示例是我在项目里常用的结构，用来把角色、单点依赖、交接物和风险门槛写成一件事。它不是任何平台的真实配置格式，但结构可以直接映射到大多数项目管理平台的自定义字段和流程规则里。

# 立项成员设计配置示例（结构示意，非特定平台真实语法）
project: 交易中台重构

roles:

id: arch-01

name: 架构负责人

deliverables: [领域边界文档, 接口契约基线]

single_point_dependency: 0.90 # 0-1，越高越危险

backup: arch-02

handover_window: 5 工作日

handover_artifacts:

决策记录（为什么这样切领域）

未决风险清单

本地验证脚本入库记录

id: risk-03

name: 风控规则开发

deliverables: [规则库, 回放用例集]

single_point_dependency: 0.75

backup: be-07

handover_window: 3 工作日

handover_artifacts:

规则映射表

本地笔记转入仓库的记录

risk_gates:

name: 单点依赖指数均值

threshold: "= 90%"

on_fail: 禁止进入排期阶段

这份配置真正有意思的地方在于最后两行的 risk_gates。前面所有的角色定义和交接物清单，如果没有一个卡点规则来强制执行，最终都会退化成”填了但没人看”。把立项门槛写成可自动校验的规则，才是成员设计从文档走向工程的分界线。

4. 迁移期的成员风险往往被严重低估

还有一个场景值得单独说：当团队从既有工具迁移到新平台时，迁移本身就是一个高风险的成员变动事件。

我参与过的一次迁移中，原平台的字段配置、自动化规则、权限组设置，很大一部分只存在于两位管理员的操作习惯里，没有文档。如果迁移前不做一次”角色与权限的知识交接”，迁移过程本身就会造成权限错配和流程中断。

在这一点上，PingCode 支持私有化部署，也支持从 Jira 平滑迁移，对要求数据不出内网、同时又不想在迁移期把流程推倒重来的中大型团队来说，是一个值得优先评估的国产替代选项。不过我要强调：工具能降低迁移的操作成本，但降不掉”谁负责迁移后权限校验”这个成员设计问题。工具替代不了角色定义。

七、数据观察：我跟踪的 12 个立项项目说明了什么

接下来这部分是我个人样本的整理结果。要提前说明：12 个项目的样本量很小，不具备统计显著性，我分享它的价值在于呈现趋势和结构，而不是给出结论性数字。

1. 分组对比：做了成员风险设计 vs 没做

这 12 个项目按立项期是否完成角色风险矩阵、接口契约表、退出预案三件事，分成两组：A 组 5 个项目全部做完，B 组 7 个项目只做了部分或完全没做。

结果差异最大的是”关键人缺位导致的延期天数”：A 组平均 4 天，B 组平均 18 天。差距的来源不是 A 组没有发生关键人变动，事实上 A 组 5 个项目中有 2 个也发生了，但因为有备份人和交接窗口，恢复时间被压缩到了可控范围。

另一个值得注意的指标是单点依赖指数均值：A 组 0.52，B 组 0.78。这个差异不是巧合，因为 A 组在立项时就会主动下调高风险角色的依赖度，比如给架构角色配一个备份人，或者把部分决策权拆出去。

2. 单点依赖指数与延期天数的关系

如果把 12 个项目按立项时识别出的最高单点依赖指数排序，再对应它们的实际延期天数，会看到一条不算陡峭但方向明确的斜线。

指数在 0.6 以下的项目，延期天数基本都在 10 天以内；指数在 0.75 以上的项目，延期天数普遍超过 20 天，最高的两个超过了 60 天。这条线里有两个偏离点：一个是高指数但延期的项目，原因是那个高依赖角色恰好是团队里最稳定的资深成员；另一个是低指数但仍然延期的项目，原因是外部供应商变更。

这两个偏离点恰好说明了成员设计的边界：它管理的是内部不确定性，管不了外部意外。但反过来说，如果连内部不确定性都不管，那项目就只剩运气了。

3. 一个容易被忽略的指标：交接文档完整率

在这 12 个项目里，交接文档完整率与实际恢复时间的关系，比单点依赖指数还要紧密。

A 组的完整率平均 88%，B 组 41%。B 组中两个严重延期的项目，完整率分别是 22% 和 31%，也就是说，这些项目里超过三分之二的关键知识从未被写下来过。

这个发现改变了我的一个判断：过去我以为成员设计的关键是”配好备份人”，现在我认为关键是”把知识从人脑里搬出来”。没有备份人，你只是恢复慢；没有知识沉淀，你根本恢复不了。

八、不同情况下的行动建议

理论讲完了，下面按团队规模和场景给具体建议。这一节我刻意区分了几种典型情况，因为同一条建议放在 20 人团队和 300 人组织里，执行成本差别很大。

1. 20 人以下的小团队：做减法，只做两件事

小团队不需要三张表。我建议只做两件事：一是明确每个模块的”唯一责任人”，二是给这个责任人指定一个临时备份，哪怕备份人只是知道去哪问。

小团队的优势是沟通成本低，所以不需要把接口契约写得很正式，但”谁是第一责任人”必须是明确的，不能出现两人共管一个模块的情况。

2. 50，150 人的中型研发组织：完整执行七步法，重点是门槛

这个规模区间是我认为成员设计收益最高的区间。团队已经大到无法靠口头协调，但还没大到有专职的项目管理办公室。

建议完整执行上一节的七步法，尤其是第六步的硬门槛。因为在这个规模下，排期压力已经足够大，任何”建议项”都会被牺牲。

工具层面，这个规模的团队通常也开始遇到权限管理和多项目负荷分配的问题，把角色定义落到平台上会比放在文档里省很多事。

3. 300 人以上的多产品线组织：把成员设计变成组织级标准

到了这个规模，单个项目的成员设计已经不是问题了，真正的问题是不同项目之间的人员争抢。

我的建议是把单点依赖指数和并行项目数做成组织级的可视化指标，每季度评审一次。具体来说，需要识别出”同时挂在三个以上高优先级项目里的关键角色”，这类人是组织级的风险点，不是某个项目的问题。

4. 外包与混合团队：把接口契约做强，把退出预案件做薄

外包团队的特点是人员流动性天然更高，退出预案的边际价值反而下降，因为你知道他们会走，已经在心里做好了准备。

这类团队真正需要加强的是接口契约：交付物格式、验收标准、验收人、验收时限，都要写得比内部团队更死。因为跨组织边界的沟通成本远高于内部。

5. 强合规与私有化部署场景：先确认工具能力，再谈流程落地

金融、制造、能源等行业常要求代码和项目数据不出内网。这类场景下，成员设计的流程可以照搬，但工具选择需要额外注意私有化部署能力、权限审计能力以及迁移可行性。

我在实际项目中的做法是：先确认平台能否支持内网部署和细粒度角色权限，再决定把多少成员设计规则写进系统。如果工具不支持角色与权限的绑定，那这部分规则就只能继续放在文档里，并接受它迟早会失效的现实。

九、不同情况下的取舍

1. 冗余度 vs 启动速度

成员设计做得越细，立项到启动的时间就越长。我见过一个团队为了做完整的三张表，把立项周期从两周拉到了五周，结果市场窗口错过了。

我的取舍原则是：只对单点依赖指数高于 0.7 的角色做完整预案，其余角色做简化处理。一个项目里真正的高风险角色通常不超过三个，把资源集中在这三个上，既能控制风险，也不会拖慢启动。

2. 深度专精 vs 可替换性

这是最让人纠结的一组取舍。把某个模块做得极深、交给一个人长期负责，效率是最高的；但这个人一走，损失也是最大的。

我的判断标准是模块的”变更频率”。变更频率高的模块，倾向于保证可替换性，宁可牺牲一点深度；变更频率低、逻辑稳定的模块，可以允许深度专精，但要强制做知识沉淀。

3. 工具统一 vs 团队既有习惯

把成员设计落到平台上，意味着团队要改变原有的工作习惯。我见过因为强行统一工具而导致核心成员抵触、最终项目延期的案例。

我的建议是分两步走：第一步只把”角色，权限，交付物”这三类信息迁移到平台，其他流程暂时不动；等团队适应之后，再逐步把交接清单和风险门槛也搬进去。一次性全量迁移，失败概率远高于渐进迁移。

4. 自建 vs 采购

有些组织会考虑自建一套成员与权限管理系统。我的经验是：除非你有非常特殊的合规要求，否则不建议自建。因为这类系统的复杂性不在功能，而在长期维护，角色权限模型一旦变化，自建系统的改造成本会迅速超过采购成本。

对于有私有化部署要求、同时又希望缩短落地周期的中大型组织，评估成熟的国产平台（例如前面提到的 PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台）通常是更务实的选择。前提是把它当作规则的执行载体，而不是把它当成解决方案本身。

十、总结：立项期成员设计的独特价值，以及你的下一步

回到最初那个问题：项目立项如何做好项目成员？我的答案是，不要把这件事当成”填名单”，而要把它当成”设计一套在你最不希望的事情发生时仍然能运转的结构”。

这套结构由三张表组成：角色风险矩阵告诉你防谁，接口契约表告诉你怎么防，退出预案表告诉你防不住时怎么救。它们共同支撑起一句话：成员的稳定性你控制不了，但角色的可替换性你可以设计。

这也是我在这篇文章里最想强调的独特判断。市面上讲项目成员的文章，大多在讲怎么选人、怎么激励、怎么分工，本质都是在提高”人在的时候表现更好”。但研发项目的真实风险，往往出现在”人不在的时候”。立项阶段是唯一一个你还有余力为这种时刻做准备的窗口。

如果你现在就有一个即将立项或刚立项的项目，我建议按这个顺序动手：先花 30 分钟列出所有交付物和对应的签字责任人；再花 20 分钟给每个角色打一次单点依赖指数；然后挑出指数最高的两到三个角色，做一次缺席压力测试；最后把结论整理成退出预案，并把角色、权限、交接物落到你正在使用的项目管理平台里。

整个过程加起来不超过两个小时，但它可能替你省下的，是项目中期那三到五周的失控时间。而这三到五周，往往就是项目能不能按期交付的分界线。