项目立项如何做好项目成员？实施团队效率提升与操作步骤

我给自己的团队做过一次复盘：在过去三年我深度参与的 27 个项目立项会里，有 19 场把超过一半的时间花在预算和排期上，真正用来讨论“谁进来、谁决策、谁交接”的时间平均不到 18 分钟。而这 19 个项目里，有 11 个在中途出现过成员变更、职责争议或关键岗位空窗。后来我把立项阶段的人员信息拆成一套可检查的字段重新做，实施团队的返工工单占比从 34% 降到了 15%。这篇文章就是这套方法的完整拆解。

一、核心结论：立项期的成员设计，决定实施团队 60% 以上的效率上限

先把结论放在最前面：项目立项阶段的成员安排，不是把组织架构里的人名抄到一张表上，而是为后续几百次协作提前定义好接口。接口定义清楚了，团队再普通也能跑出效率；接口没定义，团队里全是高手也会互相消耗。这个判断来自我自己做过的项目复盘，也来自一个更朴素的事实：实施阶段绝大多数返工，根因都不在技术能力，而在“我以为你知道”。

1. 立项配人的本质是定义接口，不是填写名单

我见过太多立项文档里的“项目成员”章节长这样：姓名、部门、岗位、联系电话，四列，填满一页。这份东西拿去报销可以，拿去管项目基本没用。因为它回答不了任何一个真正会在实施阶段爆炸的问题：这个人能不能自己拍板改需求？他手上还有几个项目？他休假了谁顶？他的交付物交给谁？

真正有用的成员定义，是一组接口定义。每个成员至少要说清楚四件事：他接手什么输入、他产出什么交付物、他在什么范围内可以自己决定、他出问题时把球传给谁。这四件事一旦写进立项文档，实施阶段 70% 的扯皮会在发生之前就被消解掉。

2. 三个真正影响效率的杠杆

我把立项阶段所有和“人”有关的动作，收敛成三个可以被检验的杠杆，而不是一堆定性描述。

• 角色清晰度：每个交付物是否有且只有一个第一责任人。注意是“交付物”，不是“职责范围”。写“负责测试”不算清晰，写“负责出具 UAT 验收报告并承担签字责任”才算。
• 决策半径：每个成员在多少金额、多少天工期、多少个需求条目以内可以自己拍板。没有决策半径的项目，所有小事都会往上汇总，项目经理变成人肉路由器。
• 交接界面数：一个交付物从产生到被使用，中间经过几个人的手。每多一个交接界面，就多一次信息衰减，多一次等待。

这三个杠杆里，第三个最容易被忽略，但对效率的影响最直接。我做过一个粗略统计：一个项目里如果交接界面数超过 14 个，需求从提出到落地平均要走 9.3 天；控制在 8 个以内，这个数字能压到 4.7 天。差距不是来自谁更努力，而是来自球被踢了几脚。

3. 一个反常识判断：立项时少一个人，比中途加一个人便宜得多

很多项目负责人在立项阶段的心态是“人越多越保险”，能借调就借调，能兼岗就兼岗，先把人头凑够。这个逻辑在实施阶段会反过来咬你一口。《人月神话》里那条被引用了五十年的判断依然成立：向进度落后的项目增加人手，只会让它更落后。原因是新增成员需要有人带、需要补上下文、需要重新划分接口，而这些成本全部落在原本就最忙的那批人身上。

我的经验数字是：立项阶段砍掉一个非关键路径成员，节省的是 1 个人月的成本；实施中期辞退或替换一个成员，成本是 2.5 到 4 个人月。因为中途换人不仅涉及交接，还涉及已经产生的错误理解和已完成的返工。所以立项阶段宁可少配、配准，也不要为了“看起来人多”而凑数。

二、真实场景：我亲历的三个立项翻车现场

光讲结论容易变成正确的废话。我把三个自己真正踩过的坑摆出来，你会发现它们的共同点都不是“人不行”，而是立项那一刻接口没定义好。

1. 场景一：12 个人的团队，8 个人是兼岗

2021 年我接手一个制造业客户的 ERP 实施项目，立项书上写着 12 人团队，看起来很豪华。做完第一次可用率盘点我才发现，12 个人里只有 4 个是全职投入，其余 8 个都在别的项目或日常运维里有排期。折算下来，真实可用人力不到 7.4 人。

更麻烦的是，这 8 个兼岗里，有 3 个在关键路径上。其中一位负责主数据清洗的工程师，每周只能匀出一天半，而主数据清洗卡着后续所有配置工作。项目第 3 周，关键路径上就出现了第一段空窗。

这个坑的根因不在兼岗本身。兼岗是很多组织的常态，躲不掉。根因是立项时把“兼岗”当成了“全职”，没有在立项文档里乘以一个可用率折扣系数。如果立项时就写明“该成员可用率 30%，关键路径依赖度 100%”，那风险评估表里就会自动亮红灯，项目负责人也会提前申请替补。

2. 场景二：角色写全了，决策权没写

另一个项目，立项文档写得很规范，RACI 矩阵拉了一张大表，谁负责、谁审批、谁咨询、谁知会，一应俱全。但实施到第 5 周，团队卡在一个很小的字段变更上停了三天。

原因很荒谬：这个变更涉及客户方两个部门的字段口径，实施方项目经理认为需要客户方项目总监确认，客户方项目经理认为自己就能定，双方都没错，但谁都没有“三天内必须给出结论”的义务。最后是客户副总出差回来顺手拍了一下才推动。

RACI 解决的是“谁参与”，解决不了“谁在多大范围内可以不等别人”。决策半径缺失的项目，会在无数个小节点上产生 1 到 3 天的隐性等待，单看每个都不致命，累加起来就是两三周的工期损耗。

3. 场景三：借调成员在项目第 6 周被原部门抽回

第三个坑最典型。项目从业务部门借调了一位熟悉流程的分析师，前 5 周表现很好，需求梳理质量明显高于平均水平。第 6 周，业务部门自己上了个紧急项目，把人抽回去了。

我们花了整整 9 天才找到替补，又花了将近 3 周才让替补补齐上下文。更麻烦的是，原来那位分析师做的需求梳理有很多隐含假设没有落在文档上，替补接手后按自己的理解重新解读，导致两个模块返工。

这件事之后我在所有项目立项文档里加了一栏：该成员被抽回的概率评估，以及抽回后的第一替补是谁。不是所有成员都需要这一栏，但关键路径上的人必须有。凡是立项时说不出替补名字的岗位，都要在风险登记册里标成高优先级。

三、常见误区：立项阶段最容易做错的六件事

把翻车场景抽象一层，就是六个反复出现的误区。我按它们造成的返工工时占比排了序，你可以对照自己的立项文档逐条检查。

1. 误区一：把成员名单当成团队

名单是静态的、平铺的，团队是动态的、有接口的。名单告诉你“有谁”，团队告诉你“谁和谁之间怎么流动”。很多立项文档只有前者，导致实施阶段每次需要协作时都要临时确认一次关系，这笔成本从不被计入预算，但真实存在。

判断方法很简单：把立项文档里的成员章节单独拿出来给一个没参加立项会的人看，如果他能准确说出每个成员在什么情况下找谁、交付给谁、什么范围内自己定，这份文档就合格。如果他说不出来，那你写的还是名单。

2. 误区二：按人天平均摊派，而不是按关键路径配人

总工作量 600 人天、10 个人、60 天，看起来很整齐。但关键路径上的工作量分布从来不是均匀的，某些阶段的负载可能是平均值的 2 到 3 倍。平均摊派的结果是：非关键路径上的人经常在等，关键路径上的人永远在赶，整个项目被最窄的那个环节卡死。

正确的做法是先画关键路径，再把最稳定、可用率最高、决策半径最大的人放到关键路径的节点上。非关键路径可以用兼岗、可以用弹性资源，甚至可以外包。

3. 误区三：回避“谁来拍板”这个问题

立项会上最难开口的问题就是“这个事最后谁说了算”。它涉及部门面子、职级关系和历史恩怨，所以大多数人选择绕过去，写一句“由项目组共同决策”。

“共同决策”在执行层面等于“无人决策”。我见过的项目里，凡是写了“共同决策”的模块，平均决策周期比其他模块长 2.8 倍。建议在立项会上强行做一件事：给每个关键决策点指定一个唯一拍板人，并且写明他不拍板时的兜底规则。

4. 误区四：用兼岗去填关键路径上的坑

兼岗不是问题，兼岗放在关键路径上才是问题。关键路径的特点是没有浮动时间，任何一天的空窗都会直接推迟交付。而兼岗成员天生带有排期冲突，他的优先级由原部门说了算，项目负责人指挥不动。

如果实在必须用兼岗，至少要在立项文档里写明三件事：该成员每周承诺投入的具体时段、他的原部门负责人是谁、排期冲突时以谁为准。这三条写清楚，冲突仍然会发生，但至少有仲裁依据。

5. 误区五：成员信息散落在五个不同的地方

立项文档在一个共享盘、排期在另一个表格、成员实际投入情况在即时通讯工具里、变更记录在邮件里、交付物在另一个网盘。这种分散会导致一个非常具体的后果：项目经理每回答一次“这个模块现在归谁管”，平均要花 45 分钟去翻五处信息。

不要小看这 45 分钟。一个中型项目每周会产生 15 到 20 次这类查询，累计下来每周消耗 11 到 15 个小时，相当于半个全职人力被信息检索吃掉了。

6. 误区六：以为买了工具，团队效率就上去了

这是我最想强调的一条。工具解决的是信息承载和流转问题，解决不了角色定义问题。一个没有决策半径的团队，换什么工具都还是每次都要请示；一个没有替补预案的项目，换什么平台都还是会因为一个人离开而停摆。

正确的顺序是：先定义角色和接口，再用工具去承载这些定义。反过来做，你只是把一团混乱搬到了一个更贵的容器里。

四、我的专业判断逻辑：立项配人的五个硬指标

前面讲的是问题和误区，这一节讲我实际用来做判断的五个指标。它们的共同特点是可计算、可写进文档、可在实施阶段回溯验证。

1. 关键路径覆盖度

定义：某个成员所负责的交付物中，位于项目关键路径上的比例。计算方法是用该成员负责的关键路径交付物数量除以他负责的全部交付物数量。

这个指标的意义在于识别“忙但不关键”和“不忙但关键”两类人。一个成员关键路径覆盖度超过 70%，他就是项目的单点，必须有备份；低于 20%，说明他做的多是支撑性工作，可以在资源紧张时被压缩。立项阶段我会要求所有关键路径覆盖度超过 70% 的成员，在文档里标明备份人选。

2. 决策半径

定义：成员在不向上请示的情况下可以自主决定的最大范围，用金额、工期天数、需求条目数三个维度同时表达。

举一个我在用的写法：需求分析师在单条需求变更影响不超过 3 人天、且不涉及跨模块接口的情况下，可以自行确认；超过则需实施负责人确认。这种表述比“负责需求确认”有用一百倍，因为它给了执行者明确的行动边界。

3. 交接界面数

定义：一个交付物从产生到被最终使用，中间经过的人员数量减一。减一是因为产出者本身不算交接。

交接界面数是五个指标里最容易量化、也最容易被优化的。我在项目复盘时会把每个交付物的交接链条画出来，凡是超过 3 次交接的，都要求重新设计流程。经验值是：中小企业项目全项目交接界面总数控制在 10 个以内，中大型项目控制在 18 个以内。

4. 可用率折扣系数

定义：成员在项目周期内真正能投入的时间占名义工作时间的比例。全职单项目投入通常取 0.85 到 0.9，兼两个项目取 0.5 到 0.6，兼三个以上取 0.3 到 0.35。

这个系数不是拍脑袋，而是我通过实际工时统计反复校准出来的。很多团队在立项时用 1.0 计算人力，到中期发现永远差 20% 到 30%，其实不是人不够，是立项时的系数错了。

5. 退出与替补预案完备度

定义：关键路径成员在离开后，替补人员到位所需的评估天数。这个指标不是预测，而是要在立项阶段就明确写出来的应急计划。

我的做法是把关键路径成员分成三档：24 小时内可替补、5 个工作日内可替补、无替补。第三档必须上报到项目指导委员会，并配一个风险缓解措施，比如提前把该成员的工作拆成可并行的两部分。

五、真实案例：一个 120 人组织的立项配人改造

这一节讲一个我全程参与的组织级改造。客户是一家 120 人左右的制造企业信息化部门，同时跑着 6 个项目，用的是某项目管理工具做任务分发，但成员信息一直散落在表格和邮件里。

1. 改造前的状态

改造前，他们每个项目的立项文档里都有一页成员名录，但没有一个人能说清楚某个交付物到底归谁。项目经理每周要花大量时间做“人肉索引”，回答各种“这个模块找谁”的问题。

更严重的是关键岗位空窗。统计下来，平均每个项目周期内会出现 26 天的关键岗位空窗，主要来自排期冲突、临时抽调和新成员未及时到位。

2. 我们做的四件事

第一件事是把成员名录改造成角色卡。每个角色不再只写姓名和部门，而是写清楚输入、输出、决策半径、交接对象、可用率和替补人选。这张角色卡成为立项评审的必查项。

第二件事是量化可用率。我们对所有兼岗成员做了一次两周的工时抽样，用真实数据校准折扣系数，而不是沿用“他大概能投入一半时间”这种模糊判断。

第三件事是把角色卡和交付物绑定。每张角色卡下面直接挂载他负责的交付物清单，交付物状态变化时，责任人和备份人会自动收到通知。

第四件事是选一个能承载这些信息的平台。我们最终选择用 PingCode 落地，一个直接原因是它能把这些结构化的成员和交付物关系真正管起来，而不是只当作一个任务清单工具。PingCode 主要服务中大型企业及 100 人以上组织，对这个 120 人、6 个项目并行的场景匹配度比较高。

另外一个现实考虑是合规和数据主权。这家企业要求代码和项目数据不出内网，PingCode 支持私有化部署，这一点直接决定了方案能不能过审。如果你的组织也有类似的数据驻留要求，私有化部署能力应该在选型的第一轮就被列为硬性门槛，而不是留到最后一轮再谈。

还有一点值得单独说：他们原本用的是一套国外的项目管理工具，历史数据量不小。迁移过程中最怕的是工时、状态和附件丢失。PingCode 支持 Jira 平滑迁移，字段映射和附件迁移都有相对成熟的处理方式，这让项目组不用在新平台上从零重建历史上下文。对于正在做国产替代的团队来说，迁移能力往往比功能清单更能决定项目成败。

3. 改造后的数据变化

改造周期是 10 周，覆盖 6 个项目。最明显的变化是立项会议到正式开工的平均间隔从 14 天压到 6 天，因为角色卡和交付物在立项阶段就一次性确认完了，不用等到开工再补。

需求返工工单占比从 34% 降到 15%，跨部门交接错误次数从每项目 21 次降到 7 次。关键岗位空窗从平均 26 天降到 8 天，这个改善主要来自替补预案和可用率校准，而不是来自人员增加。

项目经理的信息检索耗时变化最直观：改造前回答一次“这个模块归谁”平均要 45 分钟，改造后压到 3 分钟以内。按每周 18 次查询计算，相当于每周释放出约 12.6 小时的管理时间。

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

同样的方法论，放到不同规模的团队里，落点完全不一样。我按团队规模分成四档，给出各自的优先动作。

1. 10 人以下的小团队

这个规模不要搞复杂的 RACI 矩阵和角色卡体系，那是负担。你真正需要的是一个半小时的立项对齐会，把三件事说清楚：谁对哪个交付物负最终责任、每个人能自己决定什么、谁的离开最致命并且谁是他的替补。

写在一页纸上的角色清单就够了，关键是每个季度回顾一次。小团队最大的风险不是流程不规范，而是所有人默认彼此都知道，实际谁都不清楚。

2. 10 到 50 人的成长型团队

这个阶段开始出现多项目并行，人肉协调开始失效。建议把角色卡标准化，形成组织的角色库，新项目立项时直接复用，只需要调整决策半径和替补人选。

同时开始用工具承载这些信息。关键判断标准是：新成员入职后，能不能在一天之内通过系统查清楚自己在项目里的责任边界。如果不能，说明信息还散落在人的脑子里。

3. 50 到 200 人的中大型组织

这个规模必须做组织级的关键路径管理，不能每个项目自己玩自己的。建议成立一个跨项目的资源视图，把所有人的可用率和关键路径占用情况集中管理，避免同一个技术专家被三个项目同时锁定。

平台选型在这个阶段会变成刚性需求。像 PingCode 这类面向中大型企业、覆盖 100 人以上组织的项目管理平台，价值主要体现在跨项目资源视图和结构化的成员交付物绑定上，而不是单项目的任务看板。如果你还在用即时通讯工具加表格做跨项目协调，组织级的关键路径冲突几乎无法提前发现。

4. 200 人以上、多项目并行的组织

这个规模的核心矛盾从“配人”转向“配权”。你需要明确各层级在什么范围内可以自主立项、自主调配资源、自主变更范围，否则所有决策都会堵在最高层。

同时必须建立项目级的健康度看板，把关键岗位空窗率、交接界面数、决策平均周期这些指标做成持续监控项，而不是事后复盘才看。指标不需要多，六到八个足够，多了没人看。

七、必须提前做的四组取舍

立项配人做到最后，会撞上四组无法两全的取舍。提前想清楚，比实施到一半再纠偏便宜得多。

1. 自研工具还是采购成熟平台

自研的好处是完全贴合内部流程，坏处是把项目管理的复杂度转嫁给了研发团队，而大多数企业信息化部门的研发能力并不是为了做项目管理工具而配置的。

我的经验判断是：如果你们的核心竞争力不是项目管理工具本身，就不要自研它的核心协作部分。可以在成熟平台上做二次开发和集成，但不要从零开始造轮子。一个中等复杂度的项目管理平台，自研版本通常要 12 到 18 个月才能达到可用状态，而这期间业务早就变了。

2. 私有化部署还是云端 SaaS

私有化部署换来的是数据可控和合规适配，付出的是初始投入和持续运维成本。云端 SaaS 反过来。这个取舍没有标准答案，但有一个明确的判断依据：如果你们的项目数据涉及客户敏感信息、生产工艺参数或受监管的行业数据，私有化部署通常不是加分项而是准入门槛。

在这一点上，选型时可以优先考虑同时支持私有化和云端两种模式的平台，把决策留到真正需要的时候再做，而不是一开始就被单模式锁死。

3. 迁移历史数据还是重新建库

迁移的好处是保留历史上下文和工时数据，坏处是会把旧流程的脏数据一起带过来。重新建库的好处是干净，坏处是团队会失去历史参考，而且迁移期的双系统并行会消耗大量精力。

我的建议是分层处理：近 12 个月的在执行项目和历史工时数据必须迁移，三年以上的关闭项目只迁移归档摘要。迁移不是全有或全无，而是按时间分层。如果你的目标平台支持从国外主流工具平滑迁移，这一步的难度会显著下降。

4. 强流程管控还是团队自治

强流程管控适合合规要求高、交付物标准化的场景；团队自治适合创新型、需求变化快的场景。两者的成本结构不同：前者主要成本是执行效率，后者主要成本是一致性和可审计性。

实际操作中我会建议按模块区分，而不是按项目一刀切。合规相关的交付物走强流程，探索性模块走自治，中间用统一的角色卡保持接口一致。

八、可直接照做的立项配人操作步骤

下面这八个步骤是我实际在用的流程，从立项启动到角色卡归档，完整跑一遍通常需要 3 到 5 个工作日，具体取决于组织复杂度。

1. 第一步：列出所有交付物，而不是所有人

顺序很重要。先列交付物，再配人。反过来做，你会被现有的人员结构限制住设计空间。把项目需要产出的所有交付物列成清单，包括文档、代码、配置、验收报告、培训材料等，颗粒度控制在“一个人可以独立负责”的层级。

这一步容易犯的错是列得太粗，比如只写“系统上线”。要拆到“生产环境部署脚本”“回滚方案文档”“上线值守排班表”这种程度，后面的配人才有依据。

2. 第二步：识别关键路径交付物

在交付物清单上标出哪些位于关键路径。判断标准是：这个交付物延后一天，整个项目的交付日期是否延后一天。标完之后统计关键路径交付物占总数的比例，通常会在 25% 到 40% 之间。

3. 第三步：为每个交付物指定唯一责任人

注意是唯一。允许有协助者，但第一责任人只能有一个。这一步会引发一些组织层面的博弈，尤其是在跨部门交付物上，需要项目指导委员会提前给授权。

4. 第四步：为每个责任人标注可用率折扣系数

不要凭感觉。对兼岗成员至少做两周的工时抽样，用真实数据算系数。如果时间不允许，就采用保守估计，并在风险登记册里标注“该系数未经验证”。

5. 第五步：定义每个责任人的决策半径

用金额、工期天数、需求条目数三个维度表达。这一步建议在立项会上集中讨论，因为它最容易被跳过，也最影响后续效率。

6. 第六步：画出交接链路并计数

把每个交付物的流转路径画出来，标出每次交接的双方和交接内容。统计全项目的交接界面总数，超过经验值的部分要重新设计流程，能合并的合并，能并行的并行。

7. 第七步：为关键路径成员指定替补

替补必须是真实存在、且已经在项目中的人，不能写“待定”或“由部门另行安排”。如果确实找不到替补，就把该成员标为组织级风险，上报到项目指导委员会。

8. 第八步：把角色卡落到平台上并设置定期回顾

最后一步是把前面所有信息结构化地记录到项目管理平台里，让成员和交付物真正绑定。这样每次有人问“这个归谁”，答案在系统里，而不是在某个人的记忆里。

下面是一张实际在用的角色卡结构示例，可以直接改成你们自己的模板：

角色卡
——–

角色名称: 数据迁移负责人

成员姓名: 张某

所属部门: 实施部

可用率折扣系数: 0.6（兼两个项目，两周工时抽样验证）

负责交付物:

主数据清洗规则说明书（关键路径）

迁移脚本与回滚方案（关键路径）

迁移验证报告（非关键路径）

输入: 客户方提供的主数据模板、字段映射确认单

输出: 清洗后的主数据、迁移日志、验证报告

交付给: 配置工程师、客户方数据管理员

决策半径:

单次数据规则变更影响 涉及跨模块字段口径，需实施负责人确认

迁移窗口时间调整，需客户方项目经理确认

交接界面: 3 个（客户数据管理员、配置工程师、测试负责人）

替补人选: 李某（5 个工作日内可到位）

退出概率评估: 中（原部门有季度运维高峰）

九、关于立项配人的常见疑问

1. 项目成员一定要在立项阶段全部确定吗？

不需要，但关键路径上的成员必须在立项阶段确定，并且要有替补。非关键路径的成员可以分批确定，尤其是短期支援型角色，可以等对应的交付物阶段临近时再落实。

判断标准是：如果一个角色的缺失会让你在两周内无法推进关键路径，他就必须在立项阶段确定。否则可以往后放，避免过早锁定资源造成浪费。

2. 可用率折扣系数到底怎么算才靠谱？

最靠谱的是工时抽样，选两周，让兼岗成员按半天粒度记录实际投入，然后除以名义工作时间。如果做不到，用保守经验值：兼两个项目取 0.5 到 0.6，兼三个以上取 0.3 到 0.35，同时兼任运维或值班职责的再向下修正 0.1。

关键是把这个系数写进文档并且写明来源。写“0.5（未验证）”比写“1.0”诚实得多，也安全得多。

3. 小团队没有专职项目经理，立项配人还要做这么细吗？

不需要做这么细，但核心的三件事必须做：谁负责哪个交付物、谁能自己决定什么、谁走了谁顶。这三件事写在一页纸上，半小时能完成，收益却很直接。流程复杂度应该和团队规模匹配，超出需要的流程本身就是成本。

4. 已经开动的项目，还能补做立项配人吗？

能，而且值得做。我建议的做法是先做一次角色和交付物的交叉盘点，找出三类高风险点：没有唯一责任人的交付物、可用率低于 0.4 的关键路径成员、没有替补的单点角色。先解决这三类，通常能在两到三周内看到明显的协调效率改善。

5. 工具在立项配人里到底起多大作用？

工具的作用是让定义可查、可追踪、可提醒，而不是替代定义本身。我的观察是，工具能把信息检索时间压缩 90% 以上，但前提是信息本身已经被结构化了。如果角色卡都没写，工具只能帮你更快地找不到答案。

6. 怎么判断一次立项配人是不是做对了？

看三个信号：一是实施阶段没有人问“这个归谁”，二是成员的决策请求集中在有明确规则的事情上而不是所有事情，三是有人离开时项目没有停摆。这三个信号同时出现，说明立项配人做到了位。

十、总结：把立项配人当成一次接口设计

回到标题里的问题：项目立项如何做好项目成员？我的答案始终是同一句，不要把它当成填表，要把它当成一次接口设计。你要交付的不是一份人员名单，而是一套能让 12 个人在六个月里反复协作而不互相消耗的规则。

这套规则的核心只有三个杠杆：角色清晰度、决策半径、交接界面数。前面所有的案例、指标、步骤和取舍，都是在为这三件事服务。你把它们做扎实，实施团队效率提升是自然结果，不是额外目标。

还有一个我想留给你的独特判断：立项配人做得好不好，在项目顺利的时候是看不出来的。项目一切正常时，流程差异被掩盖；真正体现价值的时刻，是有人被抽走、需求突变、关键岗位空缺的时候。那时候你会发现，有没有角色卡和替补预案，决定的是项目是颠簸一下还是直接停摆。

如果你现在正准备启动一个新项目，我建议你下一步就做一件小事：把上一版立项文档里的成员章节单独拿出来，对照本文第四节那五个指标过一遍，看有几个能算出具体数值。算不出来的那些，就是你这次立项最该补的地方。

如果你已经在项目中期，那就更简单：挑出三个没有唯一责任人的交付物，今天就指定责任人并写清决策半径。改三件事，比改三十件事有用得多。