项目成员怎么做？产品经理流程优化：项目立项从0到1

我做产品经理第 6 年的时候，做过一次让自己挺没面子的复盘。我把过去三年经手的 27 个正式立项项目拉出来，按最终结果分了三堆：按期交付且达到预期指标的 9 个，延期或缩水交付的 12 个，中途停止或直接废弃的 6 个。然后我发现了一个很不舒服的规律，那 6 个被废弃的项目里，有 5 个在立项评审会上是全票通过的，评审时长平均只有 23 分钟。反倒是被反复挑战、拖了两三周才勉强通过的两个项目，最后都跑到了预期。

这个规律后来在我换的两家公司里反复出现。所以我现在看一个立项会开得好不好，不看 PPT 做得多漂亮，我看会议纪要里有没有被记下来的”反对意见”和”待验证前提”。如果一条都没有，我心里基本会给这个项目打个问号。

项目成员在立项阶段到底要做什么？这个问题大多数资料写得都很虚，通常停留在”配合项目经理完成立项材料”这一层。但真实情况是：立项阶段项目成员交出去的约束条件，决定了这个项目后面 80% 的返工量。这篇文章我想把”从 0 到 1″这个说法拆开讲清楚，尤其是从 -1 到 0 的那一段，也就是大多数团队都会跳过的那一段。

一、核心结论：立项不是申请资源，是给风险定价

先把结论摆出来：立项的本质动作不是”申请资源”，而是”给风险定价”。资源只是这个定价过程的输出物之一。

为什么这么说？因为一个项目之所以需要”立项”这道程序，从来不是因为它缺人缺钱，缺人缺钱的项目太多了，不可能每个都立项。真正需要立项的原因是：这件事的不确定性高到需要一群人对赌错的后果达成共识。共识没达成，立项会开成什么样都是白开。

1. 立项真正要回答的三个问题

我后来把立项判断浓缩成三个问题，任何立项材料如果回答不了这三个，就是没想清楚。

（1）这个问题真实存在吗，谁的痛，痛到什么程度，现在他们是怎么凑合解决的？注意最后一问。如果用户现在完全没有替代方案，通常说明这个问题还没痛到值得付费的程度。

（2）如果我们赌错了，损失上限是多少，什么时候能知道赌错了？这一问是整个立项里最容易被跳过的。止损点和验证时点应该写在立项书第一页，而不是写在风险管理章节的最后一段。

（3）谁在什么时间点承诺交付什么？注意是”承诺”而不是”负责”。负责是流程语言，承诺是人的语言。这两者的差别在项目后期会体现得非常明显。

2. 项目成员在立项阶段的角色被系统性低估

大多数团队里，立项被默认为产品经理和项目经理的事。开发、测试、设计、数据、运营这些角色，只在立项通过之后才被”拉进群里”，然后收到一份排期表。

这个顺序是反的。因为真正的约束条件不在产品经理手上，在项目成员手上。比如：现有架构能不能支持这个数据量、第三方接口的调用频率上限是多少、测试环境什么时候能排到、某个核心开发下个月要休假两周。这些东西产品经理猜不出来，只有具体干活的人知道。

我经手过一个项目，立项时预估 6 周上线，实际做了 14 周。原因不是需求变更，是立项时没人提一句：核心依赖的那个第三方支付通道，接入审批本身就要 3 到 4 周。这个信息在项目组里至少有两个人知道，但没人被问过。

3. “全票通过”为什么是危险信号

一个立项方案如果没有任何人提出实质性质疑，通常只有三种可能：参会的人没看懂、参会的人不关心、或者提出问题的人觉得提了也没用。

这三种情况里，第一种最危险。因为”没看懂”会伪装成”没意见”，会议纪要上是干净的，但执行阶段会以各种形式把不理解还回来，需求反复确认、方案反复推翻、范围反复收缩。

我现在给自己定了一条硬规矩：立项会如果没有产生至少两条被明确记录的反对意见或待验证前提，这个会就不算开完，要重开。这不是形式主义，是逼着参会的人真的去想。

二、背景和真实场景：两个立项的对照

抽象讲判断逻辑容易飘，我用两个真实项目做对照。这两个项目在同一家公司、同一批人、相邻的两个季度启动，外部条件差不多，结果差得很远。

1. 项目 A：23 分钟全票通过的”智能客服助手”

背景是客服团队反馈人力压力大，希望用 AI 做一层自动应答。立项材料做得很漂亮，12 页 PPT，包含市场规模引用、竞品截图、技术选型对比和一条漂亮的上线时间线。

评审会开到第 23 分钟，老板说了一句”方向没问题，先做起来”。散会。整个过程中，没有一个人问”客服团队实际有多少比例的咨询是重复问题”。

后来这个数字被翻出来是 19%，而且这 19% 里大部分是高风险的退款类咨询，根本不敢让机器直接答。项目做到第 11 周，范围从”自动应答”缩成”辅助话术推荐”，第 17 周，负责这个项目的两名开发被抽去做别的需求，项目事实上停掉了。

2. 项目 B：被拖了三周才通过的”对账中台”

项目 B 是财务和供应链之间的一堆线下对账表格要线上化。第一次评审会被否了，理由是”没讲清楚为什么不用现有工具改造”。第二次评审会上，供应链的负责人直接质疑：牵扯到 4 个部门的数据口径，谁负责定义？

这两次卡顿逼出了一件事，项目组花了三周时间，把 4 个部门的对账口径逐条对齐，做了一份 40 多行的字段映射表，并且在立项书里明确写了：如果口径无法在两周内达成一致，项目立即降级为试点。

最后的对账中台项目做了 5 个月，比预期长了 3 周，但四个部门的线下表格真的被替换掉了，月度对账工时从 26 人天降到 7 人天。

3. 两个项目的差距到底在哪里

表面上看，A 的立项效率高得多。但把时间轴拉长到半年，A 浪费了两个人近 4 个月的时间，加上机会成本，实际损失远超 B 那三周的论证成本。

差距不在方案质量，在于立项阶段有没有把”未知项”明确标记出来并指定验证方式。B 的立项书里有一节叫”尚未确认的前提”，列了 6 条；A 的立项书里这一节是空的。

三、拆解常见误区

我把这些年见过的立项问题归了五类。这五类误区有个共同特征：它们看起来都像是在提高立项质量，实际上是在稀释立项的判断力。

1. 误区一：把立项书写成 PRD 的加长版

最常见的一种。立项书里塞满了功能列表、页面流程、字段说明，甚至原型截图。看上去很完整，但看完之后你依然不知道”为什么现在要做这件事”。

立项书和 PRD 是两种文档，回答的问题完全不同。立项书回答”要不要做、赌什么、什么时候认输”，PRD 回答”怎么做出这个东西”。立项书里出现的功能描述，应该只是为了说明方案轮廓，而不是为了指导开发。

我的判断标准很简单：如果一份立项书删掉所有功能细节后还剩不到 30% 的内容，那它其实不是立项书。

2. 误区二：KPI 堆得越多，越说明没想清楚

见过一份立项书写了 11 个成功指标，从日活、转化率、客户满意度到代码覆盖率全覆盖。这种写法通常意味着提案人还没想清楚”这个项目成功的样子长什么样”。

立项阶段的指标应该是少而尖的。我建议最多三个：一个结果指标（业务上要变好什么）、一个过程指标（过程中我们能观测到什么）、一个反指标（什么事情变坏就说明我们做错了）。

反指标是最容易被忽略也最有价值的一环。比如做自动化客服，反指标可以是”人工介入率不低于某个阈值”。没有反指标的项目，很容易在数字上”成功”，在实际体验上失败。

3. 误区三：项目成员在立项阶段”没我什么事”

这个误区伤害最大，因为它同时伤害了项目质量和个人体验。项目成员被排除在立项之外，会导致两个后果：一是约束条件没有进入方案，二是成员对目标没有承诺感。

没有承诺感的执行是什么样子？就是”你让我做我就做”，遇到困难第一反应是上报而不是自己想辙。这不是态度问题，是因为他从没参与过”为什么要做这件事”的讨论。

让项目成员参与立项最有效的方式，不是让他听汇报，而是让他在立项会前提交一份约束清单。这份清单不需要长，但必须是具体的人写具体的约束。

4. 误区四：把评审会开成汇报会

汇报会的结构是”我讲你听”，评审会的结构应该是”我论证你质询”。很多立项会之所以开成汇报会，是因为材料在会前就已经发给老板单独过了一遍，会上只是走流程。

这种做法短期省时间，长期代价很大。因为其他部门的人失去了在决策前表达意见的机会，后面执行时他们的配合度会明显下降，他们没有被咨询过，自然也不会主动承担。

5. 误区五：里程碑按日期排，不按验证点排

典型的里程碑是”第 4 周完成设计，第 8 周完成开发，第 12 周上线”。这种排法的问题在于，它只描述动作，不描述验证。

我更喜欢把里程碑写成验证点形式：“第 4 周结束时，我们应该能证明这个方案在 20 条真实咨询上准确率达到 85%”。这种写法自带止损功能，达不到就是达不到，没法用”进度已完成 80%”糊弄过去。

四、专业判断逻辑：立项的四道闸门

讲完误区，我说一下我自己现在用的判断框架。它不复杂，就四道闸门，按顺序过，任何一道过不去，项目就不该开工。

1. 第一道闸门：问题真实性

这一关的核心是区分”有人说需要”和”确实有人在为此付出代价”。

我在这一关只问一个问题：现在没有这个方案的时候，用户是怎么解决的？他们为此付出了多少时间、钱或者风险？如果答案是”他们用 Excel 凑合”、”他们每天多花两个小时”，那是真实问题。如果答案是”他们好像也没觉得有什么不方便”，那基本可以停下了。

量化方式上，我倾向于记录三类数字：受影响的人数、每人次付出的时间成本、问题发生的频率。这三个数字乘起来，就是这个问题当前的”浪费总量”，也是这个项目理论上能创造的价值上限。

2. 第二道闸门：约束可行性

这一关是项目成员的主场。约束分四类，每一类都要有人认领。

• 技术约束：现有架构、数据规模、第三方依赖的接入周期与限额。
• 合规与安全约束：数据权限、审计要求、私有化部署环境下的网络与运维限制。
• 资源约束：核心人员的可用时间、测试环境排期、外部供应商交付周期。
• 组织约束：跨部门口径是否统一、决策人是否明确、是否存在利益冲突方。

我见过太多项目在第二关翻车，原因几乎都是同一个：约束是被”假设”出来的，不是被”问”出来的。产品经理在立项书里写”预计接入周期 3 天”，实际上没问过对接方。

3. 第三道闸门：退出机制

这一关最容易被跳过，也最能体现一个团队的成熟度。退出机制要写清楚三件事：什么条件下暂停、谁来判定、暂停后资源怎么处理。

一个可用的退出机制长这样：“如果第 6 周试点数据表明留存低于 X，项目降级为小范围试验，释放 50% 开发资源。”关键是”释放资源”这四个字，没有资源释放的暂停，只是把这个项目变成了幽灵项目。

4. 第四道闸门：角色承诺

最后一关，确认每个关键角色在立项书上”认领”了什么。注意不是”参与”，是认领具体交付物和时间承诺。

这里我要特别提醒一点：不要在立项阶段就做完整的 RACI 矩阵。那太重了，而且立项阶段的角色边界本来就在变。用一张轻量的表格就够：谁负责定义问题、谁负责技术方案、谁负责验收、谁在什么情况下必须被通知。

（1）四道闸门的检查清单

（2）一个可落地的立项门禁字段设计

如果把立项流程放到工具里，我建议至少把下面这些字段做成必填，否则不允许进入评审状态。这是我在一个 400 人规模的组织里实际用过的配置思路。

立项工作项必填字段

problem_evidence: 问题证据（量化数据或访谈结论原文）

value_ceiling: 价值上限测算（人数 × 频次 × 单位时间成本）

constraint_list: 约束清单（技术 / 合规 / 资源 / 组织，各至少一条）

constraint_owner: 每条约束的确认人

exit_condition: 退出条件（含阈值、判定人、资源处置方式）

verify_milestones: 验证型里程碑（每项须写"能证明什么"而非"做完什么"）

role_commitment: 角色承诺（角色名 + 认领物 + 承诺时间）

open_assumptions: 未确认前提清单

这套字段刚上线的时候被吐槽”太重”，但三个月后没人再提了。因为填这些字段的过程本身，就把很多不该做的项目挡在了门外。

五、案例与数据观察：100 人以上组织怎么把立项流程真正落地

前面讲的都是判断逻辑。这一节我讲落地，因为 100 人以上的组织和几十人团队的立项难点完全不同。

1. 为什么规模越大，立项越容易走形

小团队里，立项基本靠口头对齐，因为大家坐在一片区域，谁忙谁闲一眼能看见。一旦组织超过 100 人，出现三个新问题：

• 项目并行度提高，同一个人同时参与 3 到 5 个项目，资源承诺需要显性化。
• 跨部门依赖变多，约束条件分散在多个部门，靠产品经理一个个问效率极低。
• 决策链变长，立项从一个人的判断变成一个委员会的判断，信息在传递中损耗严重。

这三个问题叠加起来，就会出现”立项会上人人点头，执行阶段人人喊忙”的典型症状。

2. 我们是怎么把流程装进工具的

在一个 400 人规模、多个产品线并行的组织里，我参与过一次立项流程的数字化改造，用的就是 PingCode。选择它的直接原因是它面向中大型企业和 100 人以上组织的场景设计比较贴合，尤其是多项目并行下的资源与约束管理。

具体做法不复杂，核心是把”立项”做成一个独立的工作项类型，并配置状态机门禁：

1. 把立项书从一份文档变成一个带必填字段的工作项，字段内容就是上一节列的那八项。
2. 设置状态流转门禁，字段不完整时无法从”起草”进入”待评审”。
3. 把约束清单拆成子工作项，每条约束指派到具体的人，要求填写确认结论和确认时间。
4. 评审通过后，自动按验证型里程碑生成阶段任务，每个任务的完成标准必须是可验证的结论。
5. 项目结束后回填实际结果，形成”立项时的假设 vs 实际结果”的对照记录。

第五步是我认为最有价值的一步。没有这一步，团队永远不会知道自己的立项判断准不准。我们跑了大约半年之后，累积了 30 多条立项假设与实际结果的对照记录，这些记录后来成了新项目立项时的参考基准。

3. 数据观察：门禁上线前后的变化

改造前，立项评审平均时长 32 分钟，评审通过率 91%。改造后，评审时长上升到 74 分钟，通过率降到 68%。乍看是效率下降，但配套的另一组数据更能说明问题：上线后前 6 个月交付的项目中，发生重大范围变更的比例从 57% 降到 26%，立项阶段的平均返工次数从 2.4 次降到 0.9 次。

还有一点值得说：通过率降低并不意味着项目被砍掉了，其中大约三分之一是回到”约束确认”阶段补材料，两周后重新提交并通过对。这也解释了为什么评审时长会上升，不是流程变复杂，是评审变认真了。

4. 私有化部署和迁移场景里最容易踩的两个坑

中大型组织往往有私有化部署要求，这一层在立项阶段就必须确认，否则会在实施中期变成阻塞。我踩过两个坑，说出来给后面的人省点时间。

（1）把部署方式当成技术细节，而不是立项约束。私有化部署会直接影响升级节奏、插件可用性、运维人力投入，这些都会反过来影响项目的可行性和成本。立项书里必须明确部署形态和运维责任方。

（2）低估历史数据迁移的工作量。从既有工具迁移过来时，看似只是数据搬迁，实际要处理字段映射、状态机对齐、历史附件和权限模型的重建。如果原先用的是 Jira 这类工具，迁移时字段和状态的自定义程度越高，映射工作越重。这一点在选型阶段就值得确认清楚，支持平滑迁移的方案能省掉大量返工。

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

框架讲完了，落到具体角色和具体场景上，我给一些可以直接照做的动作。

1. 如果你是项目成员：立项前必须交出的四份约束清单

不要再等项目被”立项通过”之后才发言。在立项会之前，主动把这四份内容交出去，这是项目成员在立项阶段最有价值的贡献。

1. 时间约束：未来两个月里，你有哪些已经承诺出去的时间块？具体到周。
2. 技术约束：这个方案涉及的技术点上，有哪些是你确定做不到或者需要额外资源的？说清楚”做不到”还是”需要多久能做到”。
3. 依赖约束：需要哪些外部方配合？他们现在忙不忙？历史上他们响应速度怎么样？
4. 风险判断：如果这个项目最后失败了，你觉得最可能死在什么地方？

第四问尤其重要。经常干活的人对”这项目会怎么死”的直觉，往往比立项书里的风险章节准确得多。但只有被问，他们才会说。

2. 如果你是产品经理：把一次立项会拆成两次

我现在的习惯是把立项评审拆成两场，中间隔三到五天。

第一场只做一件事：让参会的人挑毛病，不讨论方案细节，也不要求当场表态。会后把收集到的问题归类，能当场回答的回答，回答不了的去确认。

第二场才做决策。这时候讨论的是”上次提出的这些问题，现在的答案是什么，剩下的未确认项怎么处理”。

这个拆法的好处是给了参会者一个”回去想想”的窗口。很多真实意见不会在会议现场产生，而是在散会后两三天里慢慢浮现。一次会就要求表态，收集到的往往是最表层的那部分意见。

3. 0-1 新产品和存量优化的立项重点完全不同

这两类项目的立项逻辑要分开看，混用会导致判断失误。

0-1 项目最常见的错误是”用存量优化的思路做新产品”，把方案做得很完整，然后一次性投入大量资源。而存量优化最常见的错误正相反，用新产品的心态做改造，忽略了兼容性和回滚成本。

4. 小团队和大组织的动作差异

50 人以下的团队，我不建议搞完整立项流程。你们的优势就是快，把立项压缩成一页纸加一次 30 分钟的对齐会就够了。重点只保留两样：问题的量化数据和退出条件。

100 人以上的组织，建议至少做到三条：约束清单必须由具体的人确认、里程碑必须是验证型的、立项假设要回填结果。这三条是整个立项体系里投入产出比最高的部分，其他环节可以慢慢补。

七、不同情况下的取舍

最后讲取舍。立项这件事没有标准答案，只有不同条件下的权衡。下面四组取舍是我被问得最多的。

1. 速度 vs 严谨：什么时候可以绕过完整立项

我的判断线是”可逆性”。如果这件事做错了可以在两周内回退，且损失可控，那就不要立项，直接做。这类事情包括文案调整、小范围功能实验、内部流程微调。

反过来，只要涉及三类情况之一，就必须走完整立项：一是不可逆投入（比如数据迁移、架构改造），二是跨部门资源承诺（需要别人腾出时间），三是对外承诺（已经跟客户或合作方说过时间点）。

速度的价值上限是几天，可逆性的价值上限是几个月。这两者不对等。

2. 文档 vs 口头对齐：什么样的组织必须写下来

一个粗略的判断标准：如果参与项目的人超过 8 个，或者项目周期超过 6 周，就必须有书面立项材料。低于这个门槛，靠口头对齐加上一份要点清单是可以的。

原因不是流程要求，是记忆力。人的短期共识很难维持超过几周，尤其是当参与者同时在多个项目上时。书面材料的作用不是”给别人看”，是给三个月后的自己看，那时候你已经忘了当时为什么这么判断。

3. 自研 vs 采购：立项阶段就该算清楚

这个取舍在立项阶段经常被含糊带过，最后变成”先自研试试，不行再买”。这种拖延的代价往往比直接决策更大。

我的经验是算一笔三年账：自研的投入包括开发人力、后续维护、升级适配、人员流动带来的知识损失；采购的投入包括许可费用、实施费用、定制开发、以及流程适配成本。多数情况下，如果这个能力不是你们的核心竞争力，三年账算下来采购通常更划算。

但如果涉及数据主权、合规审计或者深度定制需求，自研或者私有化部署的方案就变得必要。这时候立项阶段要明确的是运维责任归属和长期成本曲线，而不仅仅是一次性的建设成本。

4. 全面立项 vs 快速试错：用”两个池子”分开管

我见过最有效的一种做法，是把项目分成两个池子管理：探索池和交付池。

探索池里的项目不要求完整立项，只要求写清楚”我们想验证什么假设、用多长时间、花多少资源”，验证失败就关掉，团队不会因此被追责。交付池里的项目必须走完整立项，因为它一旦启动就要占用大量资源和跨部门协调。

关键机制是”进入交付池需要重新立项”。探索阶段验证成功的东西，不能直接顺着惯性变成正式项目，必须重新走一遍四道闸门。这一步能过滤掉大量”因为已经做了一半所以硬着头皮做下去”的项目。

八、回到最初的问题：项目成员到底该怎么做

写到这里，我想把开头那个问题正面回答一下。

项目成员在立项阶段的核心动作不是”配合”，而是把你手上的真实约束条件，在决策之前交到决策者面前。这件事只有你能做，产品经理猜不出来，项目经理问不全，领导更不可能知道。

具体来说就是四件事：说清楚你未来两个月能给出多少时间、说清楚哪些技术点你确定做不到、说清楚你需要谁配合以及他们靠不靠谱、说清楚你觉得这项目最可能死在哪里。

这四件事加起来可能只需要你半小时，但它能改变的是一整个项目后面几个月走向。

我对”从 0 到 1″这个说法有一点自己的理解。多数人把 0 到 1 理解成”从没有到做出来”，但我更倾向于认为，真正的 0 到 1 发生在立项阶段：从”一团模糊的诉求”变成”一组被验证过的前提”。代码还没写一行，但这件事最难的部分已经完成了。

所以下一步你可以做三件小事：

1. 把手上正在参与的项目翻出来，看看立项材料里有没有”尚未确认的前提”这一节。如果没有，现在补也来得及。
2. 在下一次立项会之前，主动给产品经理发一条消息，把你这边的约束条件列出来。不用等别人问。
3. 给团队加一条简单规矩：立项会如果没有产生至少两条被记录的反对意见，就重开一次。

最后一条听着像形式主义，但它是我试过的、成本最低也最有效的立项质量杠杆。因为它逼着所有人真的去想”这件事可能会怎么失败”，而这恰恰是立项这件事最原始的初衷。