项目负责人管理方法大全：项目负责人项目立项入门指南落地清单

我接手过一个 27 人的交付型项目组，立项评审通过了三次，立项书前后写了 42 页，PPT 改到第 9 版。立项后第 78 天，这个项目被公司层面的经营会叫停。复盘的时候，所有人都在讨论”执行力””资源不足””需求变更”，但真正的问题就一条：立项时有三条关键假设没有任何人验证过，客户预算是否真的在当年、业务方的流程是否真的能改、以及那个唯一懂老系统的工程师会不会在三个月内离职。

这三条假设，只要有一条提前 30 天被拿出来当众问一句，这个项目就不会浪费 78 天和 6 个人力。

这件事之后，我对”项目负责人管理方法”的理解发生了根本性变化。项目负责人最值钱的能力，不是把项目做成，而是在还能撤退的时候，把不确定性摊到桌面上，逼组织做出一个清醒的决定。这就是立项的全部意义。这篇文章我会把立项这件事从”填模板”拉到”做决策”的层面，给你一套可以直接落地的清单，也会讲清楚在不同组织规模、不同驱动来源下，立项动作应该怎么裁剪、哪里可以省、哪里一分都不能省。

一、核心结论：立项的本质是把不确定性提前到还能撤退的时候

先把结论摆在最前面，后面所有内容都是为这个结论提供论据和操作方法。

1. 立项不是行政流程，是一次风险定价

大多数公司把立项做成了”申请预算的公文流程”：填一张表，走三级审批，盖个章，项目就算成立了。这套流程解决的是”钱从哪出、谁签字”的问题，完全不解决”这件事值不值得做、做不成谁负责”的问题。

我自己的判断标准很简单：一个立项流程如果不能让某个项目被否决，那它就不是立项流程，是报销流程。我见过太多组织的立项通过率是 100%，一年 47 个项目全部通过。这不是好事，这说明立项这个环节没有承担任何筛选职能，所有筛选都后置到了执行阶段，用返工、延期、烂尾来筛选，成本是立项阶段的几百倍。

基于我参与和复盘过的项目样本（主要集中在中大型企业的信息化、数字化、研发交付类项目，累计 60 余个），立项阶段每多投入 1 人天的严肃论证，平均可以减少后期 8-12 人天的返工或无效投入。这个比例在越大的组织里越夸张，因为协调成本被放大了。

2. 项目负责人真正要交付的三样东西

很多人以为项目负责人在立项阶段交付的是”立项报告”。我的经验是，报告只是载体，真正要交付的是三样东西：

• 一份可以被质疑的假设清单。把”我们相信 X 成立”写成一条条可验证的句子，而不是藏在方案描述里。
• 一套双方都认账的验收口径。注意是”双方认账”，不是”我方写清楚了”。验收口径如果没有业务方或客户方的书面确认，等于没写。
• 一个明确的停止条件。什么情况下这个项目应该被叫停，谁来触发，触发后怎么收尾。这一条 90% 的立项书里没有。

这三样东西有一个共同特征：它们都是”防止项目失败成本扩大”的装置，而不是”推动项目前进”的装置。这正是立项阶段和规划阶段最根本的区别。规划阶段想的是怎么做成，立项阶段想的是怎么不做死。顺序反了，项目大概率会出问题。

3. 一个我在用的判断公式

如果只能留一句话，我会留这个公式：

立项价值 = (业务收益 × 确定性) − (投入成本 × 不可逆程度) − (停止成本 × 触发概率)

这个公式没法精确算，但它的价值在于强迫你把”不可逆程度”和”停止成本”纳进来。很多项目本身收益不错，但不可逆程度极高，比如已经签了对赌合同、已经对外承诺上线时间、已经采购了专用硬件。这类项目在立项时就要被标红，因为一旦走错，后退的路已经被自己堵死了。

二、背景与真实场景：三类立项，动作完全不同

把立项讲清楚，先要承认一个事实：没有一种通用的立项方法。同样是立项，老板一句话驱动的、售前承诺倒逼的、合规替换驱动的，三者的立项动作、文档厚度、决策人、停止条件完全不同。用一套模板套所有场景，是立项失败最常见的原因。

1. 场景一：老板/高层一句话立项

这类项目的典型特征是”目标宏大、边界模糊、时间紧迫”。老板在某个会上说了一句”我们要做数据中台”，然后这件事就被派给了你。你拿到的不是一个需求，而是一个方向。

我踩过的坑是：试图把方向直接翻译成需求，然后开始排期。正确做法是先做一次”方向收敛”，把这句话拆成 3-5 个可以独立评估的子命题，让老板或者业务负责人从中选。这时候你要交付的不是方案，是选择题。

这类项目立项阶段最重要的产出是一份被高层确认的边界声明：这一期不做什么。因为高层立项的项目，最大风险不是方向错，而是边界无限扩张。

2. 场景二：售前承诺或合同倒逼立项

这类项目的立项时间通常被压缩到极限，因为合同已经签了，时间已经承诺了。很多项目负责人这时候会觉得”立项就是个形式，赶紧开工”。我的判断恰恰相反：这类项目最需要立项，因为它最不可逆。

这类项目立项阶段的重点不是论证做不做，而是论证”我们承诺的到底是什么”，以及”哪些承诺我们做不到，需要走变更”。我在一个交付项目里干过这件事：把合同里的 37 条功能承诺逐条拆成”明确可交付/需要澄清/存在技术风险”三类，其中 6 条被标注为高风险，最终在开工前完成了书面澄清。如果这 6 条拖到开发中期才暴露，代价至少是 3 个月延期。

3. 场景三：合规、替换、国产化驱动的立项

这类项目的驱动力来自外部约束或者内部替代需求，最大的特征是”必要性明确、但收益难以量化”。立项书上写不出漂亮的 ROI，容易被质疑。

我的处理方式是换一套语言：不谈收益，谈风险敞口和不可替代性。比如某个国外工具停止服务后，业务流程中断一天的损失是多少、数据迁移窗口有多长、有没有回退方案。把”不做的后果”量化，比硬凑”做了的好处”更有说服力。

现在很多中大型企业做替换立项时，会明确要求候选平台支持私有化部署和数据自主可控。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，是国产替代场景里被反复提到的选项之一。这类平台之所以在这个场景里被优先考虑，不是因为功能多，而是因为它把”迁移成本”这个最大的风险项做成了可估算的工程量，而不是一个未知数。

三、拆解常见误区：这五个坑我全踩过

下面这五条，每一条都是我或者我身边的项目负责人真实踩过的。它们有一个共同点：在立项当时看起来很合理，甚至很”专业”，但事后看都是致命的。

1. 误区一：把立项书当文档任务完成

最典型的表现是”找一份上一年的立项书改一改”。这么做的人心里想的是”反正评审会也没人认真看”，而事实也确实如此，大多数人确实不认真看。但问题在于，你不认真写的那部分，恰恰是你三个月后要拿来跟人对账的那部分。

我观察到一个规律：立项书里写得最敷衍的章节，通常是项目后期争议最大的章节。因为写到那一章时你自己也不确定，于是用模糊语言糊过去了，而模糊语言在后期会变成双方各自解读的依据。

2. 误区二：把 WBS 当计划

WBS 是工作分解，不是计划。计划的核心是依赖关系和关键路径，是”哪件事没做完会导致另一件事无法开始”。很多立项材料里贴了一张巨大的 WBS 树状图，看起来很专业，但它回答不了”如果第三周的需求评审延后两周，整体会延后多久”这个问题。

我的做法是：立项阶段不做完整 WBS，只做关键路径上的 7-12 个里程碑，并且每个里程碑标注”前置依赖”和”最晚开始时间”。剩下的细节放到规划阶段再展开，因为那时候信息更充分。

3. 误区三：把”资源已到位”当作口头承诺

“人我已经跟张总说好了，他那边会派两个人过来。”，这句话在立项会上出现的频率极高，也几乎没有一次真正兑现过。

我的原则是：没有进入对方部门排期表的资源，等于不存在。立项阶段可以接受”资源待定”，但不能接受”资源已承诺但无书面记录”。这两种状态在项目执行时的差别，就是”提前两周协调”和”临时抓人救火”的差别。

4. 误区四：验收标准写在最后一段

验收标准在立项书里的位置，往往反映了团队对它的重视程度。我见过太多立项书，前面 30 页讲方案、讲价值、讲技术架构，最后 200 字草草写一句”按合同要求验收”。这 200 字会在项目末期变成一场持续一个月的扯皮。

正确的做法是把验收标准前置，甚至在立项书的第一页就出现。因为验收标准决定了你要做什么、不做什么、做到什么程度算完成。它不是一个终点条件，而是一个范围约束。

5. 误区五：工具先行

很多团队在立项阶段就开始纠结”用什么工具管理项目”。我的看法是：在立项阶段，工具选择的重要性排在第五位之后。排在前面的是目标、边界、验收口径、资源和停止条件。工具解决的是”信息如何流动”，但如果目标本身是错的，信息流动得再顺畅也没用。

不过有一个例外：当项目涉及跨部门、多团队协作，或者项目数量超过 20 个时，工具的选择会直接影响立项流程本身能不能跑起来。因为立项材料、审批记录、资源占用、项目台账这些东西如果靠线下文档维护，很快会失去一致性。

四、专业判断逻辑：立项四问

如果觉得上面那套公式太抽象，可以退到四个更具体的问题。这四个问题我在每次立项会上都会问，问完基本就能判断这个项目该不该立、该怎么立。

1. 第一问：这件事不做会怎样

这个问题看起来是废话，但它能筛掉大量”看起来该做”的项目。如果答案是”不做也行，只是有点落后”，那这个项目大概率应该降级为探索性任务，而不是正式立项。

我通常会把答案分成四档：不做会导致合规风险或业务中断（必须做）；不做会损失明确的收入或客户（应该做）；不做会被竞争对手拉开差距（可以做，但要控制投入）；不做只是感觉不好（先别做）。

2. 第二问：谁来验收，用什么口径

这一问的关键是”谁来”。不是”哪个部门”，而是具体到人。我见过太多项目，验收方写的是”业务部门”，到了验收时业务部门说”这个不是我提的需求”，于是项目卡住。

正确的做法是：立项书上写明验收人姓名、验收指标、验收时间和验收方式。四项缺一不可。如果验收人无法确定，那说明这个项目在组织内的归属还没理清，此时立项为时过早。

3. 第三问：最坏情况是谁兜底

这一问很少有人主动问，因为它有点”不吉利”。但它是判断项目真实优先级的最好方法。如果一个项目失败了，没有人需要为此负责，那这个项目在组织里的真实优先级很可能比它写在立项书上的低得多。

反过来说，如果一个项目的兜底人是某个 VP，那它的资源获取能力、跨部门协调能力都会显著不同。这直接影响你在立项阶段要不要争取更多的资源承诺。

4. 第四问：什么时候可以停

停止条件是立项四问里最难回答、也最有价值的一问。它的形式通常是：如果 [某个可观测的事实] 在 [某个时间点] 之前没有发生，则项目暂停并重新评估。

举几个我实际用过的停止条件：如果核心业务方在 6 周内未完成流程确认，项目暂停；如果迁移测试的数据一致率连续两轮低于 99.5%，暂停切换；如果第三个月底未达成 30% 的用户激活率，重新评估投入。

停止条件的作用不是真的去停项目，而是给所有人一个诚实的评估节点。没有这个节点，项目就会靠惯性一直跑到资源耗尽。

5. 四问定级：把项目分成 A/B/C 三类

四问答完，我会给项目定级，不同级别走不同的立项流程。这样做的好处是不用所有项目都写 40 页材料，也不用所有项目都走三级评审。

这个分级的价值在于，它把立项从”一刀切流程”变成了”资源分配决策”。C 类项目不该占用 A 类项目的评审带宽，A 类项目也不该用 C 类项目的严谨度来处理。

五、案例与数据观察：一个中大型组织的立项改造

下面这段是我参与过的一个真实场景，出于保密做了脱敏处理，但关键数字和结论保持原样。这个组织约 1800 人，研发与业务团队合计 400 余人，属于典型的中大型企业。

1. 改造前的状态

改造前，这个组织有 3 套立项模板、2 套审批流、1 个线下 Excel 台账。立项书用 Word 写，评审意见用邮件发，评审结论靠会议纪要，资源占用靠各部门自己记。结果是：

• 项目经理平均需要 4.5 天才能确认”这个项目当前处于什么阶段”，因为信息散落在邮件、文档、聊天记录里。
• 同一个项目在不同部门台账里的名称和状态不一致，季度经营会的数据和项目组自报数据平均差异 23%。
• 立项后 30 天内的变更请求，有 61% 是因为立项阶段信息缺失导致的补课，而不是真正的外部变化。

第三个数字是最要命的。它意味着这个组织的立项环节，把本该在立项阶段解决的问题，推迟到了执行阶段才暴露。而执行阶段解决同样问题的成本，至少是立项阶段的 5 倍以上。

后来这个组织把项目与研发管理能力整体迁到了 PingCode 上，选择的原因之一是它支持私有化部署，符合该组织对数据不出内网的要求；另一个原因是团队此前长期使用 Jira，迁移成本和迁移风险是选型时的硬指标。PingCode 支持 Jira 平滑迁移，这一点在实际切换中节省了大量重建字段和重录历史数据的工作量。我在这里提这个细节，不是想说”工具能解决问题”，而是想说：当立项流程本身依赖跨部门的信息一致性时，工具就从一个可选项变成了流程的组成部分。

2. 迁移与流程改造同步推进，数据发生了什么变化

这个组织没有只做工具替换，而是把立项流程一起改了：把立项拆成”提案，论证，决策，冻结”四态，每个状态有明确的完成定义，状态流转在系统里留痕，立项材料作为项目属性挂载，而不是独立文档。

改造后 9 个月，我拿到了几组对比数据，这些数字我印象很深，因为它验证了”立项阶段投入是划算的”这个判断。

这组数据里最反直觉的是”立项书从 42 页降到 9 页，但质量反而提升了”。原因是原来那 42 页里，有 26 页是在重复描述背景和方案，真正承担决策职能的内容不到 5 页。结构化的立项表单逼着项目负责人只写关键信息，反而让评审人愿意认真读。

3. 私有化部署对项目负责人的实际意义

很多人在选型时把私有化部署当成一个合规选项，我觉得它其实是项目负责人的一个风险管理工具。理由有三条：

• 立项数据本身是敏感信息。预算、资源、客户、进度，这些数据外流对组织的伤害是直接的。项目负责人如果用的是无法私有化的平台，等于把一个敏感数据出口留在了自己管理的范围内。
• 流程可定制程度决定了立项流程能不能真正落地。每个组织的立项审批层级不同、字段不同，无法定制的平台最终会被绕过，变成”系统里走一遍、实际另走一遍”。
• 迁移和退出成本。这一点常被忽略。私有化部署意味着数据在自己手里，未来更换平台时谈判地位完全不同。我见过一个组织因为历史数据在平台上无法批量导出，被迫续约三年。

所以我在做工具类立项时，会把”是否支持私有化部署”和”是否存在数据导出壁垒”作为两个必查项。PingCode 支持私有化部署，这一点在 100 人以上组织、尤其是金融、制造、政企类客户的立项评审里，通常是加分项甚至是一票项。而对于正在从 Jira 迁移的团队，它支持的平滑迁移能力也是降低切换风险的关键，迁移不是技术问题，是数据一致性和历史可追溯性的问题。

4. 我观察到的三条数据规律

在这类改造项目里，我反复看到三条规律，几乎每次都被验证：

1. 立项周期与项目成功率之间没有直接关系，但立项周期的”方差”有关系。立项快的项目不一定差，但同一组织内立项周期忽长忽短（3 天到 40 天）的时候，项目成功率明显更低。因为周期方差大说明流程不稳定，没有统一的判断标准。
2. 立项材料长度与质量呈弱负相关。超过 30 页的立项书，评审人的平均阅读完成率不到 40%。而 8-12 页的立项书，完成率能到 85% 以上。
3. 停止条件的填写率与项目超支率呈强负相关。在我能拿到数据的项目里，写明了停止条件的项目，平均超支率是 9%；没写的项目，平均超支率是 27%。这个相关性我没办法完全归因，但我的判断是：能写出停止条件的项目负责人，本身对项目边界的思考就更清晰。

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

前面讲的是判断逻辑，这一节讲具体怎么做。我按最常见的三种处境来分，你可以直接对号入座。

1. 如果你刚接手一个新项目，什么都还没定

这时候你手上最缺的不是方案，是信息。我的建议是按下面这个顺序推进，不要跳步：

1. 先做干系人盘点，不做方案。列出所有能影响这个项目成败的人，标注他们的诉求、影响力和是否支持。这一步通常需要 2-3 天，但它决定了后面所有沟通的路线。
2. 把三条最关键的成功假设写出来，然后找人验证。不是找自己团队验证，找业务方、找客户、找运维验证。验证的方式可以是一次 30 分钟的对话，也可以是一次数据查询，但必须有结论。
3. 争取一次和验收人的直接对话。在立项前，而不是在验收时。对话内容只有一个：你希望项目结束时，看到什么，才认为它成功了。
4. 把停止条件写进立项材料，哪怕没人要求你写。这是成本最低、收益最高的一条。

这四步做完，你会发现立项材料写起来快得多，因为该想的都想过了。

2. 如果你在 100 人以上的组织，立项流程很重

大组织的立项难点不是不会写，是推不动。我的经验是不要试图一次性改掉整个流程，而是从三个小切口入手：

• 先在部门内统一立项材料的字段结构，不求全组织推广。当你的部门立项材料能被上级在两分钟内读懂时，其他部门会自己来问模板。
• 把”停止条件”作为部门内的必填项，但不要求全组织执行。这一项带来的争议最小，效果最明显。
• 争取把立项状态可视化，让所有人都能看到”当前有多少项目在什么阶段”。这是推动流程改造最有效的抓手，因为信息透明本身就是压力。

在工具层面，中大型组织通常需要私有化部署来满足数据合规要求，同时要考虑与已有研发流程的衔接。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，这两点在 100 人以上、尤其是有国产替代需求的场景里，是选型时必须评估的硬指标。但我要强调：工具只能让流程跑起来，流程本身的设计必须由你来做决策。

3. 如果你的组织正在做工具替换或国产替代立项

这类立项有一个特殊性：它天然是 A 类项目，因为不可逆程度高，一旦切换失败会影响业务连续性。我建议在立项阶段就锁定五件事：

1. 迁移范围的边界。是全量迁移还是只迁移活跃项目？历史数据迁移几年？这两个问题决定工作量差 3-10 倍。
2. 数据一致性的验收口径。不要写”数据迁移完整”，要写”抽样 500 条记录，字段一致率 ≥ 99.5%”。可量化的口径才能验收。
3. 回退方案和回退触发条件。并行运行多久？出现什么现象就回退？回退由谁决定？
4. 关键用户的支持承诺。替换类项目最大的阻力来自习惯，必须有第一批愿意用新平台的种子用户。
5. 切换窗口期。避开业务高峰期，这一点在制造、零售、金融行业尤其重要。

七、不同情况下的取舍

前面讲了很多”应该做”，但真实场景里资源永远是有限的。这一节讲清楚该在哪里妥协、哪里不能妥协。

1. 立项深度 vs 立项速度

这两者确实存在冲突，但不是所有情况下都冲突。我的取舍原则是：

• 不可逆程度高的项目，牺牲速度保深度。合同类、替换类、涉及合规的项目属于这一类。这类项目多花一周做论证，可能省下三个月返工。
• 可逆程度高的项目，牺牲深度保速度。探索性项目、内部工具类项目属于这一类。做错了可以改，最大的浪费其实是犹豫的时间。
• 判断不可逆程度的方法很简单：问”如果做错了，能不能在一个月内恢复原状”。能恢复就是可逆，不能就是不可逆。

2. 标准化模板 vs 灵活裁剪

很多组织推行标准化立项模板，最后的结果是所有人都在填表，但没人真的思考。我的取舍是：字段标准化，判断不标准化。

所谓字段标准化，是指立项材料的结构统一：目标、边界、验收、资源、风险、停止条件，这六块必须有，顺序固定。所谓判断不标准化，是指每一块的内容要求可以随项目级别调整，A 类项目要求逐条论证，C 类项目一句话说清就行。

这样做的好处是，评审人能快速定位信息，同时不会因为模板太重而形式化。我见过最失败的立项模板是 17 个必填字段、每个字段不少于 200 字，结果所有人都在凑字数。

3. 自建流程 vs 采购平台

这是一个典型的取舍问题，我的判断标准是三条：

我的整体倾向是：100 人以下、流程简单、没有强合规要求的组织，自建或用轻量工具完全够用；而中大型组织、尤其是需要私有化部署和存量数据迁移的场景，采购成熟平台通常比自建更划算。PingCode 支持私有化部署和 Jira 平滑迁移，在这类场景里属于值得纳入评估范围的选项，注意是”纳入评估范围”，不是”直接选它”，选型永远要结合自己的实际约束。

八、落地清单：可以直接抄走的部分

最后一节我把前面所有内容压缩成可以直接使用的材料。这些东西我用了很多次，改过很多版，你可以按自己的情况调整字段，但结构建议保留。

1. 立项书最小字段集

下面是我现在用的立项书结构（YAML 只是示意格式，实际用文档或系统表单都可以）：

project:
name: "项目名称（含业务方简称，避免同名歧义）"

level: "A | B | C" # 决定评审层级和材料要求

sponsor: "发起人姓名"

owner: "项目负责人姓名"

driver: "high_level | contract | compliance | internal"

goal:

outcome: "项目结束后，谁在什么场景下会有什么不同"

metrics: # 至少一条可量化指标

name: "指标名"

baseline: "当前值"

target: "目标值"

measure: "测量方式与数据来源"

boundary:

in_scope: ["本期做什么"]

out_of_scope: ["本期明确不做什么"] # 这一栏比上面那栏更重要

acceptance:

acceptor: "验收人姓名（必须是具体的人）"

criteria: ["验收口径，逐条可量化"]

timing: "验收时间点"

assumptions: # 每条必须标注验证状态

statement: "关键假设内容"

verified: true | false

verified_by: "验证人"

verified_at: "验证时间"

resources:

internal: ["内部资源，含部门、人数、占用比例"]

confirmed: true | false # 是否已进入对方排期

risks:

risk: "风险描述"

impact: "高 | 中 | 低"

response: "应对措施"

stop_conditions: # 至少一条

condition: "触发停止的可观测事实"

deadline: "评估时间点"

decision_maker: "谁来决定是否停止"

rollback:

needed: true | false

plan: "回退方案（替换类、上线类项目必填）"

这个结构里，我特意把 out_of_scope 和 stop_conditions 放在显眼位置，因为这两块是绝大多数立项书的空白区，也是后期争议的高发区。

2. 立项评审会的 12 个问题

评审会最怕的是变成方案汇报会。我通常会用下面这 12 个问题把节奏拉回来，每个问题都指向一个决策点，而不是一个技术细节：

1. 这件事不做会怎样？请用一句话回答，不要讲背景。
2. 项目的成功标准是什么？一个月后你希望看到哪个数字发生变化？
3. 谁验收？他本人知道这件事吗？
4. 本期明确不做什么？
5. 最关键的三个假设是什么？哪几个已经验证过了？
6. 如果第六周发现方向错了，我们的调整成本是多少？
7. 需要哪些部门配合？这些部门的负责人确认过了吗？
8. 资源是口头承诺还是已经进入对方排期？
9. 什么情况下这个项目应该暂停？谁来判断？
10. 如果上线后出问题，回退需要多长时间？
11. 这个项目最大的单点依赖是什么？（某个人、某个系统、某个供应商）
12. 三句话总结：做什么、不做什么、什么时候可以停。

第十二个问题是我最常用的收尾。如果项目负责人说不清楚这三句话，说明立项还没到可以决策的程度。

3. 立项通过后 30 天要盯的三件事

立项不是终点，立项后 30 天是验证立项质量的关键窗口。我会在这 30 天里盯三件事：

• 假设验证进度。立项时标注为”未验证”的假设，有没有人在推进验证？如果 30 天后还没有进展，说明这些假设实际上被忽略了。
• 资源实际到位情况。承诺的人和实际的差多少？差异出现时有没有及时升级？
• 变更请求的性质。如果前 30 天的变更请求大部分是”补课型”（立项时该写没写的信息），说明立项质量不够；如果是”环境型”（外部条件真的变了），那是正常现象。

这三件事盯住，你会发现项目的中期风险会小很多。因为它们本质上都是在回答一个问题：立项时我们做的那些判断，到现在还成立吗？

我最后想说的是，项目负责人管理方法里，立项是最不被重视、但杠杆率最高的一个环节。它不需要你有多强的技术能力，也不需要你有多高的职级，它需要的是一种”在乐观情绪里保持清醒”的能力。而这恰恰是最稀缺的。

如果你现在手上正好有一个还没立项的项目，我的建议是：今天先做一件事，把三条最关键的成功假设写出来，然后找对应的人验证。不用等模板，不用等评审会，就从这三个问题开始。