项目立项如何做好项目成员？PMO效率提升与操作步骤

2019 年我第一次独立主持跨 5 个部门的立项评审，会后把成员名单整理成一张 Excel 发到群里，收到 11 个“收到”。三个月后项目延期两周，复盘会上没有一个人承认自己是关键路径上的责任人，因为那张表里每个人的角色栏都只写了两个字：“参与”。从那次之后我给自己定了一条规矩：立项阶段的成员表，凡是角色写“参与”“支持”“配合”的，一律打回重写。这篇文章讲的，就是这条规矩后来长出来的一整套方法，以及 PMO 怎么把它变成能落地、能被工具承接的流程。

一、先给结论：立项阶段做成员，做的不是名单，而是承诺

我不太喜欢“项目成员管理”这个说法，它听起来像人事工作。立项阶段真正要解决的问题只有三个：谁对哪一段结果负责、他愿意为此投入多少、什么条件下他可以退出。这三件事没锁死，后面所有的进度会、周报、燃尽图，本质上都是在给一个不确定的承诺打补丁。

1. 合格立项成员表的四个必备字段

我带过的 PMO 团队里，判断一张立项成员表能不能通过，只看四个字段。缺任何一个，退回发起人补充，而不是由 PMO 代办。

• 角色（Role）：以“对什么结果负责”命名，例如“支付链路稳定性负责人”，而不是“技术部”“研发二组”“相关部门”。
• 投入承诺（Commitment）：一个具体数值或明确区间，例如 0.4 FTE、每周 16 小时、每个迭代 3 人天。不接受“参与”“有空就支持”。
• 责任边界（Accountable for）：这个人在项目里

  唯一不能被替代的产出是什么。

• 退出规则（Exit rule）：什么阶段、满足什么条件后可以退出或降低投入，退出时交接给谁。

2. 承诺要分两层：席位承诺和投入承诺

很多项目经理把这两件事混在一起，这是立项阶段最常见的结构性错误。席位承诺回答的是“这个角色在这个项目里有没有人”，投入承诺回答的是“这个人一个月里真正有多少时间花在这个项目上”。

席位承诺可以在立项会上当场拿到；投入承诺必须回到资源经理那里排完班才能给出。这两件事混在一起，直接导致两种典型后果：一种是人到场了，但 80% 的时间被原部门占着，项目里只剩一个挂在群里的名字；另一种是为了凑投入数字，拉了一个根本没有档期的人来挂名，启动第二周就换人。

3. PMO 的效率来自结构化前置，而不是过程催办

我见过不少 PMO 团队把精力花在每天催更新、每周催周报，效果往往一般。真正有效率的做法，是在立项环节一次性把字段定义清楚、把准入规则写死，后面系统里跑出来的就是干净数据，PMO 不需要事后再去对齐口径。

换句话说，PMO 的价值不在于催得多勤，而在于把不可复用的口头判断变成可复用的结构。当“角色不能写参与”变成模板里的硬校验，PMO 就从“签字机器”变成了“规则设计者”。

4. 一条我反复验证过的经验法则

在立项阶段每投入 1 小时的成员澄清对话（明确角色、投入、边界、退出规则），大致可以减少后期 8 到 12 小时的返工沟通和补救会议。这个数字来自我对自己跟进过的 60 多个立项项目的复盘观察，属于经验区间而非严格统计，不同组织的绝对值会有差异，但量级关系一直比较稳定。

它的解释也很朴素：立项时的一次澄清是“一对多、信息同步”的低成本场景；等到项目中期再澄清，就变成“多对多、带情绪、带追责”的高成本场景，沟通成本不是线性增长，而是成倍放大。

二、背景和真实场景：为什么立项成员总是“填完就忘”

回到真实的立项现场。大部分中大型组织的立项会，实际节奏是这样的：会议两小时，前 40 分钟讲背景和商业价值，中间 40 分钟讲范围和里程碑，最后 40 分钟打开一张成员提名表，逐行念名字，谁有异议当场提，没人提就算通过。会议结束时，一份 12 人的成员表诞生了，其中真正知道自己被写进去的，大概只有 3 到 4 个。

1. 三个关键角色的缺席

一场高效的立项成员确认会，必须有三个角色在场，而现实中他们经常缺席其中两个甚至三个。

（1）真正干活的人。架构、测试、运维、数据这类角色，往往由部门经理“代为答应”，本人事后才知道自己要背这个活。代人承诺在立项阶段最容易通过，也最容易在第一个迭代爆掉。

（2）真正排资源的经理。一个工程师能不能投 40%，取决于他手里已有的项目排期和值班安排，这个信息只有他的直接经理最清楚。立项会上如果资源经理缺席，投入承诺就是拍脑袋。

（3）真正担责的人。项目的第一责任人和发起人，在很多立项会上只是“挂名出席”，真正的决策由 PMO 代做。这种立项看起来很快，但一旦出现跨部门冲突，没有人有足够权威去拍板。

2. 资源池不可见是这一切的根源

我复盘过的大部分“立项成员填完就忘”的案例，根因都不是态度问题，而是信息问题：PMO 和项目经理看不到组织内真实的资源占用情况。当一个人已经被三个项目占了 80% 的时间，而立项表上看不到这条信息时，新项目只能靠“拍”来分配。

这也解释了为什么很多组织升级工具后，立项质量会突然变好，不是因为流程变严了，而是因为资源占用第一次变得可见了。

3. 一份“看起来合格”的立项成员表长什么样

下面这张表是我在某次评审中真实见到的，形式上完整无缺，实际上没有一个字段能被用来做管理动作。

这张表的问题不在格式，而在语义：四个人的“项目角色”完全相同，投入口径三种写法，“职责描述”里全部是模糊动词。它不能回答任何一个管理问题，比如谁对上线成功负责、王五的 30% 具体是哪 12 个小时、赵六什么时候可以退出。

三、常见误区拆解：七种看起来很专业的错误做法

这些误区有一个共同特点：它们在立项评审会上都显得很合理，甚至显得很专业，所以很难被当场指出。我把它们列出来，是因为我自己踩过其中至少四个。

1. 用职级代替角色

让总监、部长挂名，看起来能提升项目的重要性，实际上会稀释责任。当项目出问题时，追责链条会在“挂名领导”这一环卡住。我的判断是：立项成员表里，级别越高的人越不应该占据执行角色；他们应该出现在发起人和决策人的位置，且只有一两个。

2. 用“支持”代替“投入”

“支持”是一个没有物理意义的词。它既不能被排班，也不能被度量，更不能被追责。我在做立项准入时，会把“支持”“配合”“按需”这一类词全部列为禁用词，出现即退回。

3. 只定人，不定退出机制

项目成员不是只进不出的。一个测试负责人在开发阶段投 0.8，在稳定期只需要 0.2，如果立项时不说清楚，就会出现“人在项目里，活已经没了”的隐性成本。退出规则不是为了赶人，而是为了让资源可以按阶段流动。

4. 用加签代替信息透明

有些 PMO 发现立项质量差，第一反应是加审批节点：加一级签字、加一个评审会。结果是流程更长、参与者更不认真。真正的解法是让信息可见，把资源占用、成员负荷、历史项目变更记录放在立项页面上，让决策者看到事实，而不是增加签字的人。

5. 把立项通过率当成 PMO 的 KPI

这个陷阱非常隐蔽。一旦立项通过率变成考核指标，PMO 就会倾向于让所有项目都通过，立项质量反而下降。更合理的指标是立项后 30 天内的成员变更率，它直接反映立项时承诺的真实性。

6. 成员表在群里靠 Excel 流转

Excel 版本管理是立项阶段最大的信息损耗源。谁改了、改了什么、改完有没有通知到本人，全靠运气。我见过的极端案例是，某个项目在启动会上用的是三个月前的成员表版本，有两个人早就调岗了。

7. 一次性把全部成员锁死

这是与误区 3 相反的一种错误：为了严谨，要求立项时把所有 20 个成员全部确认。结果是立项周期被拉长到两三周，项目还没开始就已经消耗掉大量耐心。合理的做法是分层：立项阶段只锁核心，其余在启动后 10 个工作日内补齐。

四、专业判断逻辑：我是怎么判断一张立项成员表合格的

判断标准必须能被复用，否则 PMO 就变成了靠个人经验把关的岗位。我把判断逻辑拆成四层：准入判据、时间盒、三方对齐、矩阵结构适配。

1. 四条准入判据

这是我在任何组织里都会首先落地的部分，因为它可以被写进工具做自动校验，不依赖人的自觉。

1. 角色可执行判据：角色名称必须包含一个名词性结果对象（如“稳定性”“上线窗口”“数据迁移”），且能对应到唯一的产出物。
2. 投入可量化判据：投入必须是数值或带区间的数值，禁止出现形容词。
3. 责任唯一性判据：每一条关键交付路径上，有且只有一个第一责任人；其余只能标记为配合方。
4. 退出可执行判据：退出规则必须包含触发条件和交接对象，不能写“项目结束后自然退出”。

2. 分阶段承诺的时间盒

把成员确认切成两个时间盒，是我认为收益最高的一个改动。

第一个盒子在立项评审会内完成，只锁定 3 到 5 名核心成员，标准是他们直接决定项目能否启动。第二个盒子在项目启动后 10 个工作日内完成，锁定剩余成员，标准是他们决定项目能否按期交付。

这样做的好处是立项周期可控，同时不会因为赶时间而牺牲核心承诺的质量。我观察到的现象是：核心成员确认得越慢，项目整体反而越稳；核心成员确认得越快，启动后 30 天内的变更就越多。

3. 资源承诺的三方对齐

一次合格的投入承诺，必须有三个角色同时在场或至少被通知：成员本人、成员的直接经理、项目的交付负责人。三方信息不对称是立项后扯皮的根源。

我通常要求 PMO 在系统中保留三条独立确认记录，而不是一条“已通知”的勾选框。这三条记录本身就是后续复盘的证据。

4. 不同矩阵结构下的判断差异

强矩阵组织里，项目经理对成员的调配权较大，此时立项成员表要更强调投入的时间分配；弱矩阵组织里，资源掌握在职能经理手里，此时立项成员表要更强调职能经理的确认签字和优先级排序。

把这两种组织的立项标准混用，是很多集团型公司推行统一立项模板失败的真正原因。

五、PingCode 案例与数据观察：把立项成员确认搬进系统之后

2022 年我参与了一个约 800 人研发组织的项目管理体系改造。这家公司做软硬件一体产品，分四个事业部，项目类型包括产品迭代、客户定制、平台重构三类，此前长期使用海外的一款项目管理工具管理研发过程，立项环节则完全靠 Excel 和邮件流转。

当时最痛的问题不是研发过程，而是立项：一个跨事业部项目的成员确认平均要跑 4 个部门、耗时 6 到 9 天，且经常在启动后发现名单里有人根本不知道。最终他们选择把整套立项流程搬到 PingCode 上，采用的是私有化部署版本。

1. 为什么判断这个场景适合私有化部署

这家公司有硬件业务，立项材料里包含产品路线图和部分客户合同信息，加上他们有明确的数据合规要求，所以私有化部署是硬性条件而非偏好。

另外他们当时的存量数据在海外工具上，迁移成本是决策中的关键变量。之所以最终顺利切换，一个重要原因是 PingCode 支持从 Jira 平滑迁移，包括工作项类型、字段映射和历史数据的批量导入，这使得整个切换没有变成一次“重做项目管理系统”的运动。对于考虑国产替代的中大型组织，这是一个需要纳入评估的实务因素，而 PingCode 在这一点上确实是国产替代里比较有代表性的选择。

2. 立项模板的字段设计

我们没有把立项做成一张表单，而是做成了一个可校验的数据结构。核心字段如下，这个结构后来被复制到了同集团的另外两家子公司。

project:
name: "XX 中台重构一期"

sponsor: "李 XX" # 项目发起人，唯一

owner: "王 XX" # 交付第一责任人，唯一

core_members: # 立项阶段必须锁定，3-5 人

user: "赵 XX"

role: "核心链路架构负责人" # 角色，不是部门

commitment: 0.6 # 投入承诺，0-1 之间

accountable_for: "技术方案评审通过率"

backup: "钱 XX"

exit_rule: "进入稳定期后可降至 0.2"

confirmations:

"本人已确认"

"直接经理已确认"

"交付负责人已确认"

pending_members: # 启动后 10 个工作日内锁定

role: "测试负责人"

commitment: 0.4

approval:

"资源经理确认投入"

"PMO 校验字段完整性"

3. 用脚本做立项准入校验，而不是靠人眼

字段有了，下一步是让它自动生效。我们把准入规则写成了校验逻辑，在立项提交时自动运行，未通过不允许进入评审队列。这段伪代码后来成了这个组织 PMO 最常被复用的资产之一。

# 立项成员表准入校验（伪代码示意）
REQUIRED = ["role", "commitment", "accountable_for", "backup", "exit_rule"]

VAGUE_ROLES = {"参与", "配合", "协助", "支持", "相关部门"}

def check_members(members):

errors = []

for m in members:

for f in REQUIRED:

if not m.get(f):

errors.append(f'{m["user"]}: 缺少字段 {f}')

if m.get("role") in VAGUE_ROLES:

errors.append(f'{m["user"]}: 角色定义不可使用模糊词')

if not isinstance(m.get("commitment"), (int, float)):

errors.append(f'{m["user"]}: 投入承诺必须是数值')

core = [m for m in members if m.get("is_core")]

if len(core) > 5:

errors.append("核心成员超过 5 人，立项阶段难以形成有效承诺")

if not any(m.get("is_owner") for m in members):

errors.append("缺少唯一的交付第一责任人")

return errors

4. 迁移时立项部分怎么映射

从旧工具迁移时，我们把原系统中的项目类型、负责人字段、迭代归属做了字段映射；不可映射的部分（如原系统中的自由文本成员备注）统一进入归档字段，不做强行清洗。这一点很重要：迁移的目标是可用，不是完美还原。强行清洗历史数据，往往是迁移项目失控的开始。

5. 系统上线后观察到的变化

下面数据来自该项目上线前后的内部统计口径对比，样本为该组织 6 个月内新立项的 47 个项目，属于单组织观察数据，不宜直接外推到其他组织，但趋势我认为是有参考价值的。

• 立项成员确认周期：从平均 7.4 天下降到 3.1 天，主要收益来自三方确认记录在系统内可并行推进，不再依赖串行邮件。
• 启动后 30 天内的成员变更率：从 42% 下降到 13%。
• PMO 在立项环节的沟通工时：从每个项目平均 11.5 小时下降到 3.8 小时。
• 因成员问题导致的首个里程碑延期：从 9 个项目下降到 2 个项目。

需要说明的是，这些变化不是工具单独带来的，而是“字段结构 + 校验规则 + 系统承载”三者叠加的结果。工具的作用是让规则不再依赖人的记忆和自觉。

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

同一套方法在不同规模、不同结构下的落地方式差别很大。下面是我在实际项目中给出的分场景建议，你可以直接对照自己组织的情况取用。

1. 50 人以下团队：不要流程，要一张卡片

这个规模下引入完整立项流程通常得不偿失。建议只保留一张“项目启动卡片”，写明三件事：第一责任人是谁、每个人投入多少小时每周、什么条件下可以退出。卡片由项目经理在启动会上当面确认，不需要审批流。

2. 100 到 500 人组织：把准入判据做成模板校验

这是收益最明显的区间。组织已有一定复杂度，但流程还没有僵化。建议把本文第四章的四条准入判据固化到立项模板里，用工具做自动校验而不是人工审核。核心成员控制在 5 人以内，其余在启动后补齐。

3. 500 人以上或多事业部组织：先解决资源池可见性

这个规模下，立项成员问题的根因几乎总是资源不透明。建议的顺序是：先建立统一的人员与投入视图，再做立项模板规范化，最后才是流程与考核。顺序颠倒会导致模板越规范、执行越敷衍。

4. 强矩阵与弱矩阵的不同动作

强矩阵组织优先做投入的时间分配校验，确保一个人不会同时被三个项目各占 40%；弱矩阵组织优先做职能经理确认机制，因为投入承诺的签发权在职能线手里，没有这个环节，立项表就是一张意愿书。

5. 外包与合作方混编团队的特殊处理

混编团队里，外包成员的角色定义必须比内部成员更具体，因为他们往往不在内部沟通链路中，信息差会被放大。建议在立项阶段就明确外包成员的信息获取渠道、交付验收人和变更响应时限，并把这三项写进成员记录。

七、不同情况下的取舍

项目管理里没有免费的正确，每一个改进都要付出代价。这一节我想把代价说清楚，方便你做判断。

1. 立项严谨度与启动速度的取舍

每增加一条准入判据，立项周期都会变长。我的经验阈值是：立项阶段的总耗时不应超过项目总工期的 5%，超过这个比例，严谨度带来的收益会被启动延迟抵消。一个 3 个月的项目，立项最多花 4 到 5 天。

2. 集中管控与团队自治的取舍

统一模板能保证数据一致性，但会牺牲小团队的灵活性。折中方案是“统一字段、分场景模板”：字段结构统一，但不同项目类型使用不同的默认值和必填项，既保证可汇总，又不强迫所有团队填一样的东西。

3. 工具化与人工协调的取舍

工具能解决结构和留存问题，但解决不了跨部门政治问题。当两个事业部争夺同一个人时，再好的系统也只能显示冲突，无法替你决策。所以工具化的边界是：它能替代 80% 的信息传递，替代不了 20% 的取舍决策。

4. 私有化部署与云端 SaaS 的取舍

私有化部署在数据合规和定制深度上有明显优势，代价是需要自有运维能力和更长的上线周期；云端 SaaS 上线快、维护成本低，但对数据出境和深度定制有约束。判断标准很简单：如果立项材料涉及合同、客户数据或产品路线，优先私有化。

5. 迁移成本与长期收益的取舍

更换项目管理工具的短期成本包括数据迁移、流程重配和人员培训，通常在 4 到 12 周。是否值得，取决于你的立项流程是否已经严重依赖工具能力。如果当前工具无法做字段级校验和资源视图，那么迁移的收益会在立项变更率上直接体现出来。

八、总结与下一步

回到标题的问题：项目立项如何做好项目成员？我的答案可以压缩成三句话。第一，立项阶段要交付的不是一张名单，而是四类承诺，角色、投入、责任边界、退出规则。第二，PMO 的效率不来自催办频率，来自把判断变成结构，让规则内置到模板和系统里。第三，承诺的质量比承诺的速度重要得多，核心成员多花三天确认，可以省下后面几十人时的返工。

我唯一的独特主张是：把“成员变更率”而不是“立项通过率”作为衡量立项质量的指标。前者反映真实，后者只反映流程宽松程度。一个 PMO 如果能把立项后 30 天的成员变更率压到 15% 以内，后面几乎所有项目的管理难度都会下降一个量级。

下一步怎么做，我建议按这个顺序执行：

1. 先用本文的四条准入判据自评最近 5 个项目的立项成员表，统计不合格项集中在哪一条。
2. 把“角色模糊词”和“投入非数值”设为一票否决项，先只推这两条，跑一个月看立项周期变化。
3. 再引入核心成员数量上限和退出规则字段，把立项拆成两个时间盒。
4. 需要工具承接时，优先评估能否做字段级校验、三方确认留痕和资源占用视图这三项能力。
5. 三个月后统计立项后 30 天成员变更率，用它来判断这套方法在你的组织里是否真的生效。

如果这套方法在你的组织里跑通了，你会发现一件有意思的事：立项阶段变得更慢了一点，但整个项目的节奏反而变快了。这不是矛盾，这是把不确定性提前消化掉的结果。