两年前我参与过一次事业部级的项目复盘：同一个部门在两年内正式立项 37 个项目，立项评审通过率 100%，项目章程、预算表、里程碑计划一应俱全。但真正按期交付的只有 14 个，按期率不到 38%。把所有延期和失败项目拉出来做交叉归因，最集中的原因不是技术方案失误，而是立项时写进章程的那份”项目成员表”，在第三个月就已经名存实亡。
这件事让我改变了对”项目立项”的理解。立项阶段真正决定项目命运的，不是范围写得多细、预算算得多准，而是你有没有在那一刻把”人”这件事，做成一份可执行、可追责、可变更的制度。成员名单只是结果，成员制度才是原因。
下面我把这套东西拆成三份契约、五个动作、七个步骤，以及不同组织情况下的取舍，尽量写成可以直接照着改的东西。
一、核心结论：立项时”做好项目成员”，本质是签下三份契约、跑通五个动作
1. 三份契约：资源契约、决策契约、变更契约
大多数公司的立项文档里只有”项目组织架构图”，那东西是给评审会看的，不是给执行用的。真正能约束行为的，是三份书面契约。
资源契约解决”人从哪来、来多少、来多久”。它必须写清楚：每个角色由哪个部门出人、投入比例是多少 FTE、从第几周进入到第几周退出、峰值期是哪几个月、原部门的哪些任务要为其让路。没有这一段，”支持项目”就是一句礼貌用语。
决策契约解决”谁拍板、谁能否决、争议几天内升级到谁”。立项阶段最容易被忽略的是否决权。谁对范围有否决权、谁对技术方案有否决权、谁对上线时间有否决权，这三件事如果立项时不定，执行期就会变成”谁都提意见，谁都不负责”。
变更契约解决”人走了怎么办、需求变了成员配置要不要跟着变”。项目成员不是静态集合。成员离职、被抽调、部门重组都必然发生，真正专业的做法是在立项时就写好替补规则与响应时限。
2. 五个动作：把契约变成动作
- 角色定义，不只是任务，而是包含决策权、审批权、知会范围的完整角色卡。
- 投入承诺，FTE × 时间段 × 峰值，部门负责人书面确认，而不是口头答应。
- 决策链与升级路径，每一级争议都带处理时限，超时自动升级。
- 运行机制，例会节奏、看板、工时填报、风险上报通道。
- 绩效与退出，成员在项目中的评价口径，以及退出、替补、结项释放规则。
3. 一条判断线：制度重量必须匹配项目风险
我见过两种极端。一种是所有项目都用同一套模板，包括三个月的内部小工具升级，也要求签投入承诺书、开周例会、填工时，结果团队把制度当形式，一周后全部停摆。另一种是几百人规模的跨部门项目，立项时只写了一句”由各部门配合”，结果三个月内资源冲突十七次。
制度不是越重越好，而是要和项目的不确定性、跨部门数量、外部依赖、合规刚性匹配。这一点在第四节展开。
二、背景与真实场景：立项会上没有反对意见，半年后没有人可用
1. 立项会的”和谐”是一种危险信号
立项评审会上最典型的画面是：项目经理讲完计划，各部门负责人点头，签字，散会。没有人反对，因为反对需要理由，而”我们部门最近也忙”在立项会上说出口，显得格局不够。
但资源承诺从来不是签字那一刻成立的，而是在第一个冲突周成立的。当项目需求与部门 KPI 撞车，签字那张纸的实际权重，取决于它在制度链条里的位置。如果它只是一份会议纪要附件，它大约等于零。
2. 三种最典型的”成员失效”场景
（1）三方签字，实际到岗两个人
某制造企业的一个产线数字化项目，立项时确认核心成员 9 人。第 4 周实际能稳定参与的是 2 人，其余 7 人被原部门的月度交付任务压住。项目经理找到部门负责人，对方说”我确实答应支持，但这个月的订单必须先出”。这句话在制度上是无可指摘的，因为立项文件里没有写”优先级顺序”。
（2）跨部门”共享成员”被原部门任务吞掉
共享成员的问题不在于能力，而在于时间归属。一个人名义上投 50%，实际是”原部门优先，剩余时间给项目”。剩余时间通常出现在晚上十点以后，而项目的协作环节全部发生在白天。于是投入比例看起来达标，有效协作却几乎为零。
（3）立项时没定替补，成员离职项目停摆六周
核心架构师在第 9 周离职。因为没有替补规则，招聘、面试、知识转移、上手熟悉一共花了六周。这六周里项目并没有暂停，而是所有人都在等一个决定，最终以压缩测试周期收尾，上线后返工率上升。
3. 为什么立项是锁定成员成本最低的窗口
项目立项是组织中极少数”所有相关方必须到场并且必须表态”的场合。这个窗口一关，后面每一次要人都变成一次单独谈判，成本至少翻三倍。
更关键的是路径依赖。项目运行到第 45 天左右，会形成一个事实上的资源格局：谁在做什么、谁说话算数、谁的会议必须参加。这个格局一旦形成，后面再想改，改的不是排班表，而是人的心理预期和部门的面子。所以我的判断是：立项阶段投入在成员制度上的 1 个人天，大约等于执行期补救的 5 到 8 个人天。
三、拆解六个常见误区
1. 误区一：把成员名单当成成员制度
名单回答”有谁”，制度回答”谁在什么条件下必须做什么、不做什么会怎样”。只交名单的项目，执行期会出现角色重叠，两个人都以为对方在推进；或者出现责任真空，没有人认为这件事归自己。
我在评审时常用一个提问检验：“如果这个角色空缺两周，项目会先出现什么症状？”答不上来的，说明这个角色在制度上是虚的。
2. 误区二：把部门负责人的口头支持当资源承诺
口头支持没有优先级信息。真正的资源承诺必须包含一句关键的话：”当项目任务与本部门任务冲突时，优先级是 X”。没有这句，等于没有承诺。
3. 误区三：责任矩阵只写执行角色，不写审批和知会
很多团队用 RACI，但只填了 R（执行）和 A（负责），C（咨询）和 I（知会）空着。结果是关键决策点反复返工：做完了才被告知”这个要提前过某某部门”。C 和 I 不是行政细节，它们决定了返工率。
4. 误区四：KPI 不落地，双线汇报变成双线躲责
成员同时向项目经理和部门负责人汇报，如果两边的评价口径不打通，成员会本能地优先满足掌握其绩效的一方。这不是态度问题，是激励结构问题。项目成员制度如果不同时改评价口径，它永远只是建议。
5. 误区五：没有退出与替补机制
立项时大家默认所有成员会待到最后一天。现实是成员变动率在一年期项目里通常达到 25% 到 40%。没有替补规则，每一次变动都会变成一次危机。
6. 误区六：制度越厚越好
我见过一份 42 页的项目管理制度，覆盖了所有可能的风险，结果团队只看了前两页。制度厚度和执行率之间不是正相关，通常是倒 U 型。超过某个临界点，每增加一页，执行率反而下降。
| 误区 | 立项时的典型话术 | 事后代价 | 正确做法 |
|---|---|---|---|
| 名单当制度 | “成员先这么定，后面再细” | 角色重叠、责任真空 | 立项前完成角色卡，含决策权 |
| 口头支持当承诺 | “我们部门全力支持” | 执行期被原部门任务吞掉 | 书面 FTE 承诺 + 优先级条款 |
| 缺 C 与 I | “知会范围影响不大” | 关键决策点返工 | RACI 四项全部填满 |
| KPI 不打通 | “双线汇报更灵活” | 成员优先满足原部门 | 项目评价占成员绩效明确权重 |
| 无替补规则 | “核心成员不会走” | 停摆数周、交付质量下滑 | 每个关键角色至少一名备份 |
| 制度过厚 | “制度要覆盖所有情况” | 执行率下降、制度空转 | 按项目复杂度分档配置 |
四、专业判断逻辑：用四个维度决定成员制度的重量
1. 四个判断维度
我通常用四个维度给项目打分，总分 100，得分决定采用哪一档成员制度。
- 需求不确定性（0 至 30 分），需求会不会在半年内发生结构性变化。
- 跨部门数量（0 至 30 分），需要几个部门真实出人，而不是挂名。
- 外部依赖强度（0 至 20 分），供应商、合作方、监管方是否在关键路径上。
- 交付与合规刚性（0 至 20 分），延期或不合规的后果有多严重。
这四个维度的逻辑是：不确定性决定制度要不要有弹性，跨部门数量决定制度要不要有强制力，外部依赖决定制度要不要有缓冲，合规刚性决定制度要不要留痕。
2. 三档成员制度模式
轻量模式（复杂度 0 至 30 分）：角色卡简化为一张表，投入承诺以邮件确认，双周例会，不做工时填报。适合部门内项目、周期三个月以内的工具类项目。
标准模式（复杂度 31 至 65 分）：完整角色卡、书面 FTE 承诺、周例会、风险上报通道、关键角色有备份。适合大多数跨部门业务系统项目。
强矩阵模式（复杂度 66 分以上）：成员进入项目后绩效主要由项目评价，部门负责人只保留专业指导权；双周向管理层汇报资源到位情况；关键角色必须有正式备份且备份同步参与评审。
3. 责任矩阵的最小可用集
我建议在 RACI 基础上加两个标记：D（决策权，谁最终拍板）和 V（否决权，谁能否决）。原因是 RACI 只能表达”参与方式”，表达不了”权力边界”，而项目里真正会卡住的往往正是权力边界。
最小可用集的判断标准是：每一个关键决策点上，必须有且只有一个 D；V 可以为零，但一旦存在，必须写明否决的理由边界，否则会变成无限否决。
4. 投入承诺的可执行写法
“某某投入 50%”是不可执行的，因为 50% 没有说明时间段和优先级。可执行的写法包含四个要素：
- 时间跨度：从第几周进入到第几周退出。
- 投入强度：分阶段的 FTE，例如第 1 至 4 周 0.8，第 5 至 12 周 0.5。
- 峰值承诺：关键评审和上线窗口期的临时全投入安排。
- 优先级条款：与部门任务冲突时的处理顺序。
五、案例与数据观察：一家约 300 人制造企业的立项成员制度改造
1. 案例背景
这家企业大约 300 人，同时有 18 个在研项目，其中 6 个跨三个以上部门。改造之前的状态很有代表性：立项评审 100% 通过，成员到位率按周统计平均 61%，工时填报覆盖率 34%，跨部门资源冲突的平均处理时长 9.5 天，项目按期交付率 46%。
最典型的症状是”会议决议无人执行”。项目周会做出的决定，到下周检查时经常得到”我们部门还没排上”的回复。
2. 我们做了四件事
- 角色卡改造。把原来的岗位名称列表换成含决策权、否决权、知会范围的角色卡，每个关键决策点明确唯一 D。
- 投入承诺书面化。引入分阶段 FTE 和优先级条款，由部门负责人签字，同时报管理层备案。
- 决策链时限化。争议 3 个工作日内未解决自动升级至项目发起人，超过 5 个工作日由管理层裁定。
- 制度落到系统里。把角色、权限、迭代节奏、工时和风险上报配置进项目管理平台，让制度有可追溯的执行记录。
3. 为什么选平台时我在意的是这三件事
制度写在文档里只能靠人记，配置进系统才会自动生效。这家企业在选型时同时评估了几款工具，最终选择 PingCode。我参与这个决定的判断依据有三条，写出来供参考。
第一是私有化部署能力。制造企业的项目数据包含工艺参数和供应链信息，不能简单放在公有环境。PingCode 支持私有化部署，这一点直接决定了方案能否过信息安全评审。
第二是迁移成本。他们原本使用 Jira，积累了多年的项目模板、工作流和历史数据。PingCode 支持 Jira 平滑迁移，立项模板、成员角色、审批流程可以相对完整地平移，避免了”制度换了、历史断了”的尴尬。
第三是组织规模匹配度。PingCode 主要服务中大型企业及 100 人以上组织，角色权限、跨部门视图、工时与资源视图这些能力，恰好是这家企业最缺的部分，也是国产替代方案里比较完整的选择。
需要说明的是，工具只解决”制度可执行”，不解决”制度是否合理”。如果角色卡本身没有决策权定义，再好的平台也只能记录混乱。
4. 改造后的数据变化
改造后第 6 个月统计：关键角色到位率从 61% 升到 93%，工时填报覆盖率从 34% 升到 88%，立项评审平均周期从 11 天缩短到 6 天，跨部门资源冲突处理时长从 9.5 天降到 3.2 天，项目按期交付率从 46% 升到 74%。
这里我要强调一个反常识的观察：立项评审周期缩短了，不是因为评审变松，而是因为角色和决策权提前明确了，评审会上不再需要现场争论”这事谁负责”。质量的提升和速度的提升在这件事上并不矛盾。
六、落地操作：七步走完立项成员制度
1. 步骤一：给项目做复杂度评分
用第四节的四个维度打分，先确定档位。这一步通常 1 到 2 小时，参与人只需要项目经理和一位有经验的 PMO。先定档，再定制度，能避免”小项目上重流程”这种最常见的浪费。
2. 步骤二：定义角色卡，包含决策权
角色卡不是岗位说明书，它要回答”这个角色在什么决策上有最终话语权”。建议每个项目不超过 8 个角色，每个关键决策点唯一 D。
3. 步骤三：签投入承诺书
承诺书由项目经理起草、部门负责人签字、管理层备案。核心字段是分阶段 FTE 和优先级条款。这一步是整份制度的重心，也是最容易被打折的一步。
4. 步骤四：设计决策链与升级时限
把项目里可能出现的争议分类：范围争议、技术方案争议、资源争议、进度争议。每类指定第一处理人和升级对象，并写明时限。没有时限的升级路径等于没有路径。
5. 步骤五：配置运行机制
- 例会节奏：标准模式周会 45 分钟，强矩阵模式周会加双周资源对齐会。
- 看板与可视化：任务状态、阻塞项、风险项必须可见。
- 工时与资源视图：用于发现投入衰减，这是最容易被忽略的早期预警指标。
- 风险上报通道：任何成员可以直接上报阻塞，不需要经过部门负责人。
6. 步骤六：把制度落到系统里
制度只有变成系统里的权限、字段、流程和提醒，才会真正执行。下面是一份可以直接改成 YAML 导入的角色卡模板，我们在项目里通常按这个结构建档。
role_card:
project: 产线数字化一期
complexity_score: 68
mode: strong_matrix
roles:
name: 项目经理
owner: PMO
fte_plan: [{week: 1-4, fte: 1.0}, {week: 5-24, fte: 0.8}]
decision_right: [范围变更审批, 里程碑调整]
veto_right: [需求插入排期]
backup: 张某某
name: 业务负责人
owner: 生产部
fte_plan: [{week: 1-6, fte: 0.5}, {week: 7-24, fte: 0.3}]
decision_right: [业务规则确认]
veto_right: [上线验收]
escalation_days: 3
escalation:
level_1: 项目经理 -> 业务负责人 （3 个工作日）
level_2: 项目发起人 （5 个工作日）
level_3: 管理层例会裁定
performance:
project_weight: 0.4
review_cycle: monthly
这份模板的价值在于：它把决策权、否决权、时段 FTE、升级时限、绩效权重放在同一个结构里。任何一个字段空着，执行期都会以某种形式暴露出来。
7. 步骤七：设定复盘与退出机制
建议在项目第 4 周做一次”成员制度健康度检查”，只看四个数：角色到位率、工时填报率、阻塞项平均停留时长、成员变动次数。第 4 周的这四个数，基本能预测项目后半程的走势。
退出机制同样要提前写：成员在什么条件下可以退出、退出前需要完成哪些交接、替补成员多久内到位。写在立项文件里的退出规则叫制度，写在离职邮件里的退出规则叫事故。
七、不同情况下的取舍
1. 强矩阵还是弱矩阵
强矩阵的资源约束力强，代价是部门负责人的专业指导意愿下降，因为人已经”不归他管”了。我的判断是：当项目延期成本明显高于部门短期产出损失时，选强矩阵；否则选标准模式。不要为了管理上的整齐，把所有项目都推成强矩阵，那会让部门经理逐渐退出技术把关。
2. 全职成员还是兼职成员
全职成员效率高，但组织成本也高，而且容易在项目间歇期产生闲置。兼职成员成本低，但协作延迟高。一个实用的折中是：关键路径上的角色用全职，支撑性角色用兼职并明确时段。让一个人在同一个项目里既做关键路径又只投 30%，是最容易出问题的组合。
3. 内部成员还是外部供应商成员
外部成员的约束来自合同而不是制度，所以对他们的管理重点不是角色卡，而是交付接口和验收标准。经验上，外部成员参与的部分，需求描述要精确到可以验收的程度，否则争议几乎必然发生。
4. 制度刚性还是响应速度
制度的每一层审批都在消耗响应速度。取舍的原则是：对不可逆决策加刚性，对可逆决策减刚性。比如架构选型是难逆的，值得多层评审；周报格式是可逆的，完全可以随时调整，不需要制度规定。
5. 平台重配置还是轻模板
平台配置越深，制度执行越有保障，但迁移和调整成本也越高。我的经验是：角色体系、权限、升级流程值得深配置，因为它们变动频率低；报告字段、标签体系保持轻量，因为它们经常要改。
| 取舍场景 | 倾向选择 A | 倾向选择 B | 代价与注意 |
|---|---|---|---|
| 矩阵强度 | 强矩阵（延期成本高） | 标准模式（部门指导重要） | 强矩阵会削弱部门技术把关 |
| 投入方式 | 关键路径用全职 | 支撑角色用兼职并定时段 | 关键路径兼职是高风险组合 |
| 成员来源 | 内部成员（用制度约束） | 外部成员（用合同约束） | 外部成员需求描述必须可验收 |
| 制度刚性 | 不可逆决策加审批 | 可逆决策走简化流程 | 分不清可逆性会导致两头都慢 |
| 平台配置 | 角色权限深配置 | 报告标签保持轻量 | 深配置提高迁移与调整成本 |
八、总结与下一步
如果要我用三句话总结这件事：第一，立项阶段的核心产出不是成员名单，而是资源、决策、变更三份契约。名单会过时，契约会持续生效。
第二，制度重量必须匹配项目复杂度。轻量模式跑不动跨部门项目，强矩阵模式会压垮小项目。判断依据是四个维度打分，不是管理层的偏好。
第三，成员制度必须落到系统里，并且带时限、带权重、带备份。没有时限的流程、没有权重的考核、没有备份的角色，在项目中期都会失效。
下一步我给一个可以直接执行的 30 天清单：第 1 周，对当前在研项目做复杂度评分，重新分档；第 2 周，为复杂度 31 分以上的项目补齐含决策权的角色卡；第 3 周，推动部门负责人签署分阶段 FTE 承诺书，并把决策链时限写进项目章程；第 4 周，把角色、权限、升级流程配置进项目管理平台，同时做一次成员制度健康度检查，只看角色到位率、工时填报率、阻塞停留时长和成员变动次数这四个数。
这四周做完，你会发现立项会上的气氛变了：不再是一致点头，而是有人开始认真讨论”这个角色到底谁拍板”。那种讨论虽然不太和谐，但它恰恰是项目能交付的信号。
常见问题解答（FAQ）
1. 项目立项时，项目成员到底该由项目经理挑，还是由部门经理指派？
我做了几年项目，每次立项最头疼的就是要人：我明确说要一个能独立扛模块的后端，部门经理却塞给我一个刚转岗的，说先练练手。结果项目延期两个月，复盘时又变成我排期不合理。所以我很想知道，选人这件事到底该谁说了算，有没有既不撕破脸又能保住交付的办法。
比较务实的做法是分权：项目经理有关键角色的否决权，部门经理有非关键角色的指派权。立项前先出“角色，能力要求，投入比例，关键交付物”四列表，向资源部门提交需求单，只写能力和级别要求，不点名到人，避免变成人身攻击。
关键角色（架构、测试负责人、核心模块开发）项目经理可以否决，但要给出书面理由，且同一角色最多否两次，第三次必须接受指派并同步调整排期。判断依据很简单：项目经理对交付结果负责，就必须对关键角色有人事建议权；但矩阵型组织里完全选人权不现实，所以用“有限否决+排期联动”来兜底。
真正要防的不是人不行，而是人被换了排期却不改。
2. 立项阶段怎么给项目成员定投入比例和考核权重，才能避免挂名不干活？
我们项目立项时拉了十几个人进群，人人都说支持，真到干活的时候，一半人说自己手上还有别的项目。我在周会上问进度，对方说“我这周实在抽不开身”，我又没有他的考核权，只能干着急。这种情况到底该怎么在立项时就用制度堵住。
核心是在立项文件里把“角色，投入比例，关键交付物，考核权重”四件事写死，缺一项就不算立项完成。投入比例用可核算的口径，不写“参与”“支持”这类虚词，半个人力就写每周20小时，四分之一人力写每周10小时。
考核权重建议占该成员个人绩效的15%到30%，由项目经理评分、部门经理复核，权重低于10%基本等于免责声明，高于40%又会和其本职工作打架。识别挂名有个可执行的数据口径：连续两周该成员在项目管理平台里的工时记录为零，或者约定的关键交付物没有进入评审，就触发资源预警，由项目发起人约谈双方负责人。
注意，工时不是用来监控人的，是用来在冲突发生时提供事实依据，这一步没有留痕，后面所有协调都会变成口头扯皮。
3. 立项会上让成员签字承诺，是不是形式主义？怎么签才有用？
我们公司立项会搞过签字仪式，每个人在一张承诺书上签名，气氛很热烈。三个月后项目出问题，翻出那张纸，上面只写了“本人承诺积极配合项目工作”，等于什么都没承诺。我就在想，签字这件事到底是走形式，还是我打开方式不对。
签字本身没问题，问题在于签的内容太软。承诺书应该签的是责任矩阵和变更条款，不是决心书。具体三块：第一，用RACI写清每个人对哪些交付物负责执行、哪些负责批准、哪些只是被告知，颗粒度到交付物而不是到岗位；
第二，写明投入比例和冲突时的优先级顺序，比如本职工作和项目任务撞车时，由谁的上级来裁决、几个工作日内给答复；第三，写明变更条件，什么情况下可以调整承诺，调整需要谁批准。判断依据是：签字的价值不在于道德约束，而在于后续出现分歧时有一个可回溯的基线。
落地时把责任矩阵和承诺记录一起放进立项纪要，并在项目管理平台里建立对应的角色和权限，让纸面承诺和系统里的任务分派对得上，否则签字当天有效，第二天就失效。
4. 立项后核心成员被抽调或离职，制度上该怎么兜底？
我们有个项目做到一半，主程被调去救另一个更紧急的项目，交接只用了半天，结果后面三个月都在还技术债。还有一次是测试负责人直接离职，账号和测试数据都没交出来。我想知道，这种人力变动不可能完全避免，那制度设计上应该提前埋哪些防线。
至少埋三道防线。第一道是备份角色，立项时每个关键角色必须指定一名B角，B角投入10%左右用于同步，参与关键评审、能读懂设计文档，不是挂个名字。第二道是资源变更流程，抽调关键角色必须部门负责人和项目发起人双签，并且申请人要同时提交替补人选和时间表，只批“抽人”不批“补人”的申请一律驳回。
第三道是把人力稳定性纳入部门经理的考核，比如关键角色非计划变更次数、变更后的交付影响天数，这些数据从项目管理平台的成员变更记录里导出就能算，不用额外填表。针对离职风险，立项后两周内要求关键设计文档、环境账号、外部依赖联系人清单完成归档，并做一次交接演练，让B角真正跑一遍流程。
经验上，最贵的不是人走了，而是人走了以后没人知道系统为什么这么设计，所以文档和演练要趁项目还顺利的时候做，出事了再补通常已经来不及。
文章包含AI辅助创作：项目立项如何做好项目成员？管理层制度设计与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/281542
读者评论
个复盘项目的数据我觉得只能当经验参考，不太适合当基准。角色与决策权定义清晰度和按期交付率同向，也可能是因果倒置：往往是资源到位、管理成熟的项目，才写得出清晰的角色卡。实际立项时，部门不给人，项目经理连决策权都拿不到，表格再细也白搭。
书面FTE承诺我经历过，但部门负责人签字后仍可能失效，因为签字不挂钩部门预算和考核。冲突时还是原部门KPI优先。要真落地，得把项目优先级写进部门季度目标，或者用内部工时结算。小项目轻量化这点赞同，我们给三个月工具升级填工时，两周后就没人填了。
强矩阵模式我持保留意见。如果项目经理不能影响奖金和晋升，绩效主要由项目评价只会变成表面配合，成员实际还是听部门负责人。替补机制也是，稀缺架构师很难提前备份，写进表里的备份往往也满负荷。建议只对关键路径和可交接模块做备份，别每个关键角色都配。