我复盘过一个延期 97 天才交付的客户系统替换项目，把所有延误事件倒排回时间轴后发现：超过六成的时间损失，根因不在开发阶段，而在立项阶段。目标没被真正对齐、关键干系人没签字、验收口径没写死、预算审批人和需求拍板人不是同一个人。项目成员当时各自埋头写自己那份文档，项目负责人忙着把立项报告做得漂亮，没人负责把”承诺”这件事变成可核对的清单。
这篇文章我想反过来讲：立项不是项目负责人的独角戏，也不是项目成员的填表作业。它是一次”把模糊想法压缩成可执行承诺”的集体动作。我会按我做过的十几个中大型项目立项的实操路径，说清楚项目成员在立项期到底该做什么、项目负责人该抓哪几根线、哪些动作看起来专业其实是白费功夫。
一、先说核心结论：立项的本质是锁定承诺，不是审批通过
大多数人对立项的理解停留在”报告批了、预算给了、项目启动会开了”。但按这个标准立项成功的项目，后面照样翻车。我后来把立项重新定义成一句话：立项是把一组不可逆的承诺，在信息最少的时候，尽可能准确地写下来，并让有决策权的人签字。
1. 项目负责人在立项期只干三件事
第一件是拿目标共识。不是”我们要做一个新系统”这种共识，而是”到了某个时间点，哪个业务指标必须变化多少”这种共识。区别在于前者无法验证，后者可以吵架。
第二件是拿资源承诺。资源不是”大概给 5 个人”，而是”哪 5 个人、什么时候到位、每周投入多少、谁有权把他们抽走”。我见过太多立项书写着”研发投入约 200 人天”，实际执行时连固定的人都没有。
第三件是拿验收口径。验收口径必须在立项阶段写死，而不是等到交付前再谈。口径晚一天确定，返工成本就多一层。
2. 项目成员在立项期提供三类不可替代的输入
很多项目成员在立项期处于”等待被分派”的状态，这是最浪费的。立项期的信息密度最高、纠错成本最低，项目成员此时的三类输入，价值远超后期加班。
- 工作量与依赖估算：不是估算总人天，而是估算关键路径上的依赖和不确定性。哪个模块必须等外部接口，哪个环节要等安全评审，这些只有一线成员清楚。
- 风险清单：立项期的风险清单应该是”如果我做这件事，最先卡在哪里”，而不是从模板库复制二十条通用风险。
- 干系人地图：谁真的会用、谁只是名义上支持、谁会在验收会上突然反对，项目成员往往比负责人更早知道。
3. 立项质量的分水岭：最晚决策时间点有没有写进计划
这是我最想强调的一个判断。一个立项方案是否成熟，不看它写得多完整，而看它有没有标出”最晚决策时间点”。比如”最晚在第 6 周确认是否接入统一身份认证，否则登录模块要返工两周”。写了这个，立项才叫闭环；没写，立项只是意向书。
二、背景与真实场景：一个立项阶段埋雷的完整过程
我把上面说的那个延期 97 天的客户系统替换项目拆开讲，因为它的每个环节都很典型。
1. 项目背景：看起来条件全都具备
这是一家中型制造企业，约 600 人，销售团队 120 人。老系统用了 7 年，业务部门抱怨报表导出慢、移动端体验差，管理层希望借替换的机会把销售流程统一。预算是批的，项目负责人是 IT 部门的一位资深经理，项目成员从 IT、销售运营、财务各抽了几个人，看起来资源齐备。
立项报告写了 38 页，包含业务现状、目标架构、实施计划、风险应对。这份报告后来被管理层当成范本，但它恰恰是问题的开始。
2. 立项阶段真实的六个节点
我把当时的时间线还原出来，你会发现”立项”实际上由六个不同性质的动作组成，而每个动作由不同角色主导。混在一起做，就会出问题。
| 节点 | 主导角色 | 真实产出 | 当时的问题 |
|---|---|---|---|
| 机会识别 | 业务发起人 | 一页纸痛点说明 | 痛点被写成”系统老旧”，无法量化 |
| 价值假设 | 项目负责人 | 预期收益测算 | 收益数字是倒推的，没人认领 |
| 范围圈定 | 项目负责人 + 业务 | 功能清单 | 清单是”老系统有什么”而不是”必须有什么” |
| 估算与排期 | 项目成员 | 工作量与里程碑 | 估算基于最理想情况，无缓冲 |
| 资源确认 | 管理层 | 人力与预算批复 | 批的是总额，没批到人 |
| 验收口径 | 业务 + 财务 | 验收标准 | 拖到上线前两周才谈，直接推翻三项范围 |
3. 真正的爆点：验收口径迟到
项目上线前两周，财务负责人提出：报表必须支持按项目维度分摊成本，而这一条从未在任何文档里出现过。理由是”我们一直这么做的”。项目成员当场估算，这个需求要动数据模型，至少两周，而且会牵动已经测完的六个模块。
这就是典型的立项阶段失误：把最贵的决策拖到了最便宜的时间点之后。如果在立项阶段让财务负责人参与一次两小时的口径确认会，这个需求要么被明确排除，要么在架构设计时就预留出来，成本可能是 3 人天。
三、拆解五个高频误区：看起来专业，其实在制造风险
我参与过评审的立项方案超过 50 份，发现误区高度集中。下面五条，几乎每一份出问题的立项书都能对上号。
1. 误区一：把立项等同于写一份立项报告
报告是产物，不是目的。我见过项目负责人花三周打磨报告排版，却没和任何一个关键干系人做过一次一对一确认。报告写得再漂亮，也只是一个人的假设集合。
判断标准很简单：如果立项报告里的每一条结论都能追溯到某次具体会议的某个人当面确认，这份报告才算立得住。追溯不到的，就是个人推测。
2. 误区二：需求在立项阶段越全越好
这是最贵的误区。立项阶段追求需求完整性，会把项目拖进”永远在收集需求”的状态，而且收集来的需求有大量是执行阶段才发现不成立的。
更合理的做法是把需求分成三档：必须做（立项即锁定）、应该做（设计阶段确认）、可以做（上线后评估）。立项只用把第一档敲死，第二档留接口，第三档不写进承诺。
3. 误区三：项目成员在立项期是”待分派”状态
项目成员如果只在启动会后才知道自己要做什么，那立项阶段的估算就是负责人拍的，不是算的。我更推荐的做法是：立项阶段就让 2 到 3 名核心项目成员参与范围讨论，只参与其中一次，时间成本两小时，但估算质量完全不同。
4. 误区四：把立项会开成汇报会
汇报会的结构是”我讲、你听、你点头”。立项会应该是”我提三个需要你决策的问题，你当场给答案”。如果一场立项会开完，没有任何一个人的原有立场被改变，这场会基本无效。
我自己开立项会的固定动作是：会前把三个必须当场决策的问题发给参会人，会上不允许多讲背景，直接进入决策。这三个问题通常是范围边界、验收口径、资源到位时间。
5. 误区五：没有退出机制
几乎所有立项方案都默认项目必须走到最后，所以没写什么情况下该停。结果是项目已经明显不成立了，还在一层层加人。
一个成熟的立项方案应该包含止损条款：在哪个里程碑、用哪个指标、由谁判定、什么条件下终止或缩范围。这不是悲观，这恰恰让早期投入变得可控。
四、专业判断逻辑：立项决策的四层漏斗
我判断一个立项该不该批，不看文档，按四层漏斗走。任何一层过不去，后面都不用看。
1. 第一层：价值假设是否可验证
价值假设必须能回答”什么时候、看哪个数、变成什么样”。如果只能回答”提升效率、改善体验”，它就不是假设，是愿望。
我在评审时常用的追问是：“这个指标上个月是多少？”如果答不上来，说明基线不存在，后面的收益测算都是无源之水。
2. 第二层：约束条件是否真实
约束包括人、钱、时间、合规、技术。这一层最容易出问题的地方是，约束被写成区间而不是具体值。”大约 5 个人”不是约束，”固定 4 人，其中后端 2 人，第 3 周到位”才是约束。
3. 第三层：干系人是否有决策权
关键干系人必须满足两个条件：能拍板，且愿意承担拍板的后果。我见过业务对接人非常配合，但真正的决策权在另一位副总手里，直到验收阶段才出场，直接推翻范围。
4. 第四层：失败成本是否可承受
这一层最常被跳过。要问的是：如果项目在第 8 周被判定失败，已经投入的资源和已产生的沉没成本，组织能不能接受？如果答案是”不能接受”，那这个项目就不该按当前方案立项，而应该拆成更小的试点。
五、项目负责人带项目成员做立项的七步实操
下面这套流程我在不同规模的组织里跑过十几轮，从 30 人小团队到 3000 人规模的企业都适用。区别只在每一步的耗时和参与人数，步骤本身没变过。
1. 第一步：一页纸问题定义（项目负责人主导，1 天）
只写三件事：现在发生了什么、它造成了什么可量化的损失、如果不做会怎样。不写解决方案。这一页纸的目的是防止立项一开始就跳到”我们要建一个平台”。
2. 第二步：干系人地图（项目负责人 + 项目成员，2 天）
把干系人分成四类：决策人、使用者、受影响者、评审人。每类至少写一个具体姓名，写不出名字的说明还没调研清楚。
- 决策人：有权批准范围、预算、验收口径变化的人，通常是 1 到 2 人。
- 使用者：每天真正操作的人，他们的抵触是最常见的失败原因。
- 受影响者：流程被改变但不用新系统的人，容易被忽略，却常在验收时发声。
- 评审人：安全、合规、财务、法务等有否决权的角色。
3. 第三步：范围三档拆分（项目负责人 + 业务 + 项目成员，3 天）
把需求拆成必须做、应该做、可以做三档。必须有明确的判定依据，我常用的依据是：不做这一条，项目目标是否无法达成。回答”是”才进第一档。
4. 第四步：估算与关键路径（项目成员主导，3 到 5 天）
这一步必须由项目成员主导，负责人只做校验。重点不是总人天，而是关键路径上的依赖项和不确定性。每个依赖项都要标注”最晚确认时间”。
5. 第五步：资源落实到人（项目负责人主导，2 天）
把人力写成”姓名 + 角色 + 投入比例 + 到位时间 + 调度权归属”。这一步往往会触发一次尴尬的对话，但越早越好。
6. 第六步：验收口径对齐会（项目负责人 + 决策人，半天）
这是整条流程里性价比最高的一步。用两小时把验收标准逐条读给决策人听，逐条确认。我统计过，这一步平均能提前暴露 4 到 6 条口径分歧。
7. 第七步：立项章程与止损条款（项目负责人主导，1 天）
把前六步的结论压缩成一份可执行的章程，包含里程碑、最晚决策时间点、止损条件。下面是我常用的章程骨架，可以直接改成你们组织的模板。
项目立项章程（精简版）
────────────────────────────
问题定义
当前状况：
可量化损失：
不做的后果：
价值假设
目标指标： 基线值： 目标值：
验证时间点： 数据来源： 认领人：
范围
必须做（立项锁定）：
应该做（设计阶段确认）：
可以做（上线后评估）：
明确不做：
资源承诺
人力：姓名 / 角色 / 投入比例 / 到位时间
预算：金额 / 审批人 / 释放节奏
调度权归属：
关键路径与最晚决策时间点
依赖项： 最晚确认时间： 负责人：
未确认的后果：
验收口径
验收标准（逐条可测）：
验收人：
止损条款
检查里程碑：
判定指标：
判定人：
触发后的动作（缩范围 / 暂停 / 终止）：
────────────────────────────
六、工具落地：立项信息怎样才能不流失
流程再对，如果信息最后落在几个人的文档和聊天记录里，三个月后照样找不到。我用过纯文档、表格、以及项目管理平台三种载体，差别相当明显。
1. 立项信息流失的三个高发点
第一是口径变更。验收口径在会上改了，但改的版本没同步给项目成员，导致按旧口径开发。第二是资源变更。人走了、被抽走了，排期没跟着变。第三是最晚决策时间点过期。时间点到了没人提醒，风险悄悄变成事实。
这三个高发点的共同特征是：它们都是”时间触发”而不是”人触发”的事件。只要依赖人记得，就一定会漏。所以立项信息必须落到有提醒机制、有变更记录、有权限控制的系统里，而不是靠文档版本号。
2. 以 PingCode 为例：立项信息如何变成可追踪对象
在中大型企业场景下，我接触较多的落地方式是 PingCode。它主要服务中大型企业及 100 人以上组织，这正好是立项复杂度最高的区间，跨部门多、决策链长、合规要求高。
我通常会把立项章程拆成平台里的几类对象来管理，而不是整份塞在一个文档里：
- 目标与价值假设：建成一条带基线值和目标值的记录，指定认领人，到期自动提醒。避免收益数字写完就没人管。
- 范围三档：拆成独立需求项并打上”必须/应该/可以”标签，验收口径直接挂在需求项下。口径变更时，变更历史可追溯。
- 关键路径依赖：每个依赖项建一个带”最晚确认时间”的任务，挂在里程碑下。时间点到了未关闭，看板自动标红。
- 止损检查点：作为独立里程碑存在，附带判定指标和判定人，而不是写在文档里的免责声明。
这样做的直接好处是，立项不再是”一份文件的生命周期”，而是”一组持续被追踪的承诺”。项目成员打开平台就知道自己承诺了什么、什么时候要确认什么。
3. 私有化部署与迁移场景下的额外考量
如果组织属于金融、制造、能源等对数据边界敏感的类型，立项数据往往不能出内网。PingCode 支持私有化部署，这一点在立项阶段就要确认，因为部署方式会直接影响项目排期，私有化环境准备通常要额外 2 到 4 周，这个时间必须写进关键路径。
另一个常见场景是从 Jira 迁移。很多中大型企业立项时的第一个决策就是”继续用 Jira 还是换掉”，而迁移本身就是一个需要立项的子项目。PingCode 支持 Jira 平滑迁移，是国产替代的常见选择，但迁移不是点一下按钮，立项阶段就要把工作项映射、自定义字段丢失、历史附件迁移、权限体系重建四件事列清楚。
我经手过一个约 800 人的研发组织做迁移，他们的实际耗时构成是这样的：字段与工作流映射占大头，历史数据迁移和权限重建次之，真正被低估的是并行验证期，新旧系统同时运行的四周里，团队效率会下降，这部分成本必须在立项时预留。
七、不同情况下的行动建议
立项没有唯一正确姿势，取决于组织规模、项目类型和当前成熟度。下面按几种常见情形分开说。
1. 如果你是 100 人以下组织里的项目负责人
不要照搬大企业的立项流程，会把自己拖死。你可以只做三件事：一页纸问题定义、一次两小时的验收口径对齐会、一份带动最晚确认时间的里程碑表。这三件事做完，立项质量已经能超过大多数同级组织。
项目成员的参与方式也要简化：只让 1 到 2 名核心成员参与范围和估算，其他人在启动会上同步即可。
2. 如果你是 100 人以上组织的项目负责人
七步流程基本要全走，但重点放在干系人地图和资源落实到人。这个规模下，失败原因极少是技术问题，多半是”某个人没被提前拉进来”或”某个人被抽走了但没人知道”。
工具层面建议尽早把立项章程结构化，用一个统一的平台承载，而不是分散在文档工具里。对中大型企业而言，像 PingCode 这类面向 100 人以上组织的项目管理平台，能把立项承诺变成可追踪对象，比单纯管文档更贴合实际。
3. 如果你是项目成员，想知道自己在立项期该主动做什么
给你三个可以立刻做的动作：
- 主动要一份范围清单，逐条标注你认为有技术不确定性或依赖外部条件的项，附上你的判断依据。
- 找出你经验里最容易在后期返工的三个点，写进风险清单，并给出建议的最晚确认时间。
- 告诉项目负责人，你觉得哪个部门或哪个人可能在使用环节出问题，哪怕只是直觉。
这三个动作加起来不超过半天，但往往能改变整个项目的走向。
4. 如果你正在做平台迁移类立项
额外加两条：一是把并行验证期明确写进排期，并承认这段时间的效率损失；二是把迁移过程中的数据校验标准写进验收口径，否则上线后出现数据对不上，责任说不清。
八、不同情况下的取舍：没有全都要的立项
立项阶段最难的从来不是”该做什么”，而是”放弃什么”。我列几个高频冲突，以及我的取舍判断。
1. 范围完整与交付时间冲突
取时间。理由很简单：晚交付的范围完整，业务价值会被时间成本吃掉；先交付再迭代，至少能拿到真实反馈。立项时明确写”第一版不做哪些”，比写”第一版做哪些”更有价值。
2. 资源充足与启动速度冲突
如果资源到位需要三个月，而市场窗口只有一个月，那应该缩小范围先启动，而不是等人齐。小范围快速启动的风险，通常低于大范围延迟启动的风险。
3. 验收口径严格与干系人关系冲突
取严格。我见过项目负责人为了不让业务方为难，把验收标准写得模糊，结果交付时更难堪。写清楚不是不信任，而是保护双方。
4. 平台统一与团队习惯冲突
在工具选择上，统一平台带来的可追溯性收益，通常大于短期内团队重新学习的成本。但迁移节奏可以分阶段，不必一次全切。
| 冲突场景 | 常见选择 | 我的判断 | 关键理由 |
|---|---|---|---|
| 范围完整 vs 交付时间 | 保范围 | 保时间 | 反馈价值高于初始完整度 |
| 资源充足 vs 启动速度 | 等人齐 | 缩范围先启动 | 窗口期损失不可逆 |
| 口径严格 vs 关系融洽 | 写得模糊 | 写严格 | 模糊口径的代价在交付时支付 |
| 平台统一 vs 团队习惯 | 各自保留 | 分阶段统一 | 可追溯性收益长期累积 |
| 立项详尽 vs 快速试错 | 详尽 | 按失败成本决定 | 失败成本高则必须详尽 |
九、关于立项的高频疑问
1. 立项阶段要不要做原型？
看失败成本。如果做错方向的代价很高，做一个低保真原型确认范围边界是划算的；如果失败成本可控，把原型推到设计阶段更高效。判断依据是第四层漏斗，不是流程惯例。
2. 项目成员该不该参与立项评审会？
至少一名核心成员应该在场。原因不是让他发言，而是让他听到决策人对验收口径的原话。经过转述的口径，信息损耗非常大。
3. 立项章程写完之后还需要维护吗？
需要，但只维护三类字段：验收口径、资源到位情况、最晚决策时间点。其他内容可以冻结，这三类必须持续更新，因为它们是最容易随时间失效的部分。
4. 没有历史基线数据，价值假设还能做吗？
能做，但要降级处理：先花一周建立基线，或者把目标从”提升多少”改成”在某个时间点前把基线测出来”。承认基线缺失，比编造一个收益数字更专业。
十、总结：立项是把话说清楚，把责任落到人
回到开头那个延期 97 天的项目。如果重来一次，我不会去优化那份 38 页的立项报告，我会做四件事：和财务负责人开一次两小时的口径会、把范围清单从”老系统有什么”改成”必须做什么”、把人力写到具体姓名和到位时间、在章程里加上一条止损条款。
这四件事加起来不超过五天。它们不会让立项报告更好看，但会让项目少走三个月弯路。
我的核心判断是：立项阶段最有价值的产出不是文档，而是”被明确说出口的承诺”和”被明确排除的范围”。前者决定项目有没有人负责，后者决定项目会不会失控。项目负责人的职责是把这两件事逼出来，项目成员的职责是让这两件事基于事实。
如果你现在手上正好有一个待立项的项目，下一步可以这样做：今天先写一页纸问题定义，明天约三个决策人各聊二十分钟，本周内把范围拆成三档。这三步做完，你已经跑赢了大多数立项流程。
如果你所在的组织有 100 人以上、跨部门协作复杂，再补一步：把立项章程结构化到统一的项目管理平台里，让每一条承诺都有归属人、有截止时间、有变更记录。文档会过期，机制不会。
常见问题解答（FAQ）
文章包含AI辅助创作：项目成员怎么做？项目负责人实操方法：项目立项从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/284973
读者评论
作为一线开发，让2-3名核心成员参与范围讨论这条我认同，但落地难点不在成员愿不愿意，在部门经理肯不肯放人，那两小时在排期表里就是无产出时间。还有估算关键路径依赖的前提是外部接口对接人已经定了，否则估出来的只是空气。
最晚决策时间点这条最实用，我准备直接抄进模板。但退出机制我保留意见：跟客户或老板谈止损条款，很容易被理解成项目还没开始你就想跑。我一般写成里程碑复评点，实质一样，阻力小很多，评审时也更容易过。
验收口径那段读着有点不舒服，好像责任都在财务。多数情况其实是负责人从没找财务对过口径，报表出来才第一次问。另外口径最好直接写成几条可执行的验收用例，谁签字谁认，比支持成本分摊这种话管用得多。