我们如何用瀑布开发管理高风险创新项目

一、核心结论：瀑布不是开发方法，是风险控制框架

我跟很多技术负责人聊过高风险创新项目的管理问题，发现一个反复出现的认知偏差：大多数人把瀑布模型当成一种“落后的开发方法”来批判，而不是把它当成一种“成熟的风险控制框架”来使用。

这句话我在至少十几个项目的复盘会上讲过：当你管理的项目满足以下三个条件中的任意两个，预算超过500万、涉及合规认证、技术路径存在未知变量，你在前期的每一次“加速”，几乎都会在后期转化为成本的指数级增长。

软件工程领域有一个被反复验证的数据：在需求阶段修复一个缺陷的成本是1倍，在设计阶段是5-10倍，在编码阶段是20-50倍，而到了测试或上线后的维护阶段，这个数字会飙升到100-200倍。这个数据最早来自NASA的软件工程实验室，后来被Barry Boehm在《软件工程经济学》中系统化论证，至今仍是我见过的对瀑布模型价值最有力的量化背书。

所以这篇文章的核心结论很简单：在高风险创新项目中，瀑布模型不是一种“开发软件”的方法，而是一种“管理不确定性”的制度化流程。你用它的目的不是更快地写出代码，而是确保在写出代码之前，所有能提前排除的风险都已经被排除。这个结论和大多数人听到“瀑布”两个字时的本能反应完全相反，但我过去十五年在B2B软件、医疗设备软件和金融核心系统领域的一线经验反复告诉我：在正确的场景下，这是最高效的方式。

二、背景：那些“敏捷失败”的高风险项目，到底卡在哪里

1. 两种“高风险”的本质差异

在深入讨论方法论之前，我想先做一个关键区分。我发现很多团队把“高风险”等同于“不知道用户要什么”，但这个定义过于狭窄。我在实际操作中把创新项目的高风险分成四种类型：

• 市场风险：用户需求不明确，产品-市场匹配未经验证。典型场景是C端新产品孵化和探索性SaaS功能。
• 技术风险：核心算法或技术路径是否可行、性能指标是否能达到，都未验证。典型场景是AI模型落地、硬件固件协同、高并发系统重构。
• 合规风险：产品必须通过特定的行业认证或监管审批才能上线。典型场景是医疗器械软件（FDA/CE/NMPA认证）、金融核心系统（等保、PCI-DSS）、汽车功能安全（ISO 26262）。
• 组织风险：项目涉及多个部门、多个供应商或跨地域团队，协调成本和信息衰减本身就是重大风险源。典型场景是企业ERP替换、跨国部署、政府和军工项目。

敏捷方法论对解决市场风险确实有效，短迭代、频繁交付、用户反馈闭环，这些机制天然适合需求探索。但它在解决技术风险、合规风险和组织风险时，效果远没有人们想象的那么理想。原因很直接：这三类风险不能通过“快速试错”来消除，它们必须通过“前置验证”来排除。

举个例子：你没法通过“两周一个迭代慢慢试”来验证一个医疗设备软件是否符合IEC 62304标准。FDA的审核员不会因为你说“我们用了敏捷”就少看一行文档。恰恰相反，如果你拿不出完整的需求追溯矩阵、设计评审记录和测试用例覆盖分析，你的510(k)申请直接会被打回来。在这个场景里，瀑布模型的文档体系不是负担，而是合规准入的硬通货。

2. 我亲眼见过的一个典型失败案例

2021年，我参与复盘了一个金融领域的中台项目。这个项目的目标是替换一家中型银行的对公信贷审批系统，涉及核心风控模型的重构、与央行征信系统的对接，以及超过40个外围系统的接口改造。预算在八位数，团队规模峰值约80人。

项目启动时，技术负责人定调要“全面敏捷”，两周一个sprint，持续交付，拥抱变化。前三个sprint看起来很美好，velocity稳定，燃尽图漂亮。问题从第四个月开始集中爆发：

• 风控模型的准确性在测试环境始终达不到上线标准，而前期为了追求“快速迭代”，建模团队跳过了完整的离线验证阶段；
• 征信接口的加密规范在中途被监管更新，而团队没有做任何前置的技术预研，导致已完成的接口代码需要大范围返工；
• 最关键的是，由于每个sprint都在“响应业务方的需求变更”，功能范围从最初的18个核心模块膨胀到31个，而没有任何一个环节做过端到端的系统级设计评审。

最终的结局是：项目在第11个月被叫停，实际开支超过预算的140%，但核心风控模块的准确率只达到设计指标的72%。复盘会上我没有说敏捷本身有问题，我说的是：这个项目需要的不是迭代速度，而是风险排查的彻底性。它更适合用一个经过强化的瀑布框架来管理，把80%的资源和时间花在需求定义、技术预研和架构评审上，而不是花在反复返工上。

三、误区：人们对瀑布模型的三个严重误解

1. 误解一：瀑布模型不允许任何变更

这是流传最广也最荒谬的误解。严谨的瀑布实践从来不排斥变更，它排斥的是“无纪律的变更”。

我在2009年第一次完整负责一个瀑布项目时，我的mentor教会我第一件事就是设置变更控制委员会。CCB不是一个橡皮图章，而是一个由产品负责人、架构师、质量经理和业务方代表组成的正式决策体。任何变更，无论是新增需求、修改接口还是调整优先级，都必须经过影响分析、成本估算和风险说明三道程序才会被批准或驳回。

这套机制和敏捷的Backlog Refinement在底层逻辑上是相通的：都承认变更是不可避免的，都要求对变更进行排序和取舍。区别在于，瀑布通过“基线化”来控制变更的边界和时机，而不是通过“频繁迭代”来吸收变更。在高风险项目中，前者往往更负责任，因为每一次变更的波及面可能远超你的直觉判断。

一个我反复使用的规则是：在瀑布项目的需求阶段结束后，任何变更都会被赋予一个“波及系数”。如果需求文档中的一个字段定义发生变化，我们不只改这一处，代码仓库、测试用例、接口文档、合规追溯矩阵中的对应项都要同步更新。敏捷团队的直觉反应是“太慢了”，但在合规性和安全性要求极高的场景下，这种“慢”恰恰是保护项目不被碎片化变更拖垮的唯一方式。

2. 误解二：瀑布模型是“做完一步再想下一步”

这个描述听起来像瀑布，但在工程实践上完全不可行。我在2014年接触过一家医疗影像设备公司，他们的软件团队表面上按照“需求-设计-编码-测试”的瀑布流程推进，但实际上每个阶段内部都有大量的并行和前置工作。

具体来说，他们在需求访谈阶段就已经启动技术预研和可行性验证，技术预研不是“开发”，而是通过PoC（概念验证）和仿真来回答最关键的不确定性问题：图像重建算法在目标硬件上能跑通吗？DICOM协议栈的兼容性有死角吗？这些问题的答案会反向影响需求的颗粒度和优先级排序。

所以我说这不叫“做完一步再想下一步”，这叫“阶段门控加并行流”。每个阶段的出口条件是明确且不可逾越的（门控），但在进入当前阶段的同时，为下一个阶段甚至下两个阶段的前置准备工作已经在并行进行。这不是对瀑布模型的“改良”，而是任何严肃的瀑布实践本来就该有的样子。真正让瀑布失效的不是模型本身，而是团队把它执行成了一种“懒惰的流水线”，需求写完就扔给设计，设计画完就扔给开发，中间没有任何反馈回路。

3. 误解三：敏捷和瀑布只能二选一

我大概从2016年开始在多个场合反复讲一个观点：敏捷和瀑布不是光谱的两端，而是两个不同维度。就像你装修房子时，架构设计和水电走线需要用工程蓝图思维（瀑布），但软装和家具布局可以边装边调（敏捷）。没有任何一个正常人在毛坯房里就开始“迭代式装修”，也没有任何一个人在已经入住的房子里还在纠结承重墙的位置。

在高风险创新项目中，最有效的策略往往是在控制框架上使用瀑布的纪律性，在执行单元上使用迭代的灵活性。比如，项目的整体交付节奏、里程碑节点、合规文档体系、风险清单和缓解计划，这些用瀑布来管。而某个具体模块内部的算法调优、UI交互细节、性能优化，这些可以在一个sprint内多次迭代。这种“宏观瀑布、微观迭代”的结构，我后面会用具体案例详细展开。

四、判断逻辑：什么时候该用瀑布来管理高风险创新

1. 我的“三问判断法”

每次有团队来问我“这个项目要不要用瀑布框架”时，我不会直接回答，而是问三个问题。这三个问题的答案组合，基本上就能给出清晰的判断。

第一问：这个项目失败的主要后果是什么？

如果答案是“用户不满意，我们可以下个版本改”，那敏捷是更自然的选择。但如果答案是“系统故障可能导致财务损失超千万”或者“拿不到监管批文整个产品线被砍”，那你就需要瀑布框架提供的可追溯性和阶段控制机制。后果的严重程度直接决定了你能接受多高的“试错成本”。试错成本越高，前置验证的必要性越大，瀑布框架的价值越明显。

第二问：项目启动时，需求的稳定基线有多少？

我强调“稳定基线”而非“需求确定性”，因为两者有本质区别。一个项目在启动时可能不知道所有的用户故事细节，但如果核心业务规则、法规约束、系统边界和关键性能指标已经可以梳理出至少60-70%，那它就有了建立稳定基线的条件。医疗设备、金融核心、汽车功能安全类项目，它们的需求基线稳定性通常能达到80%以上，因为这些需求来自法规标准而非用户偏好。

第三问：团队的能力离散度有多大？

这是很多人忽略但极其重要的变量。如果你的团队由核心骨干、外包团队、跨部门借调人员和第三方供应商混合组成，能力水平差异显著，那么瀑布模型的阶段化文档和明确交付标准是最好的沟通公约数。敏捷的“自组织团队”理念在这种混合能力环境中往往失效，不是理念不好，而是前提不成立。一个经验丰富的架构师和一个刚入职的初级开发之间，根本不存在“自组织”的共同语言，他们之间的信息传递必须以结构化的文档作为媒介，而不是靠每日站会的口头同步。

2. 三条决策边界

基于以上三个问题，我总结出三条可操作的决策边界：

• 合规必瀑：只要项目涉及FDA、CE、NMPA、ISO 26262、IEC 62304、PCI-DSS等强制性认证，“要不要用瀑布”不再是选择题。你需要讨论的是瀑布的“强度”，文档粒度到哪个层级、评审频次多高，而不是要不要。因为审核员的思维模式就是瀑布的追溯思维：需求→设计→实现→测试→证据，少一环都不行。
• 高耦必瀑：如果项目涉及超过5个外部系统对接，或底层架构的变更会波及超过3个独立功能模块，使用瀑布的架构评审和接口冻结机制比敏捷的“迭代式集成”更安全。每个接口的契约一旦确定，其他团队可以并行推进而不必担心某一天突然被通知“接口格式改了”。
• 高风险技术必前置验证：如果项目依赖一项未经验证的技术或算法（例如新的加密方案、自研的推理引擎、非标协议的适配），这个技术不确定性必须在项目早期被隔离和排除。瀑布的“技术预研阶段”做这件事天然比敏捷的“边做边学”更有效率，因为它迫使团队在承诺整个项目范围之前，先集中精力攻克最难的部分。

决策简化表：

五、案例与数据：PingCode帮助一个百人团队在瀑布框架下实现可控创新

1. 案例背景：一个需要“双模管理”的项目困境

本节我以一个与PingCode合作过的真实客户案例（已脱敏）来说明瀑布框架在高风险创新中的落地方式。

这家企业是一家服务政企客户的软件提供商，2023年启动了一个智慧城市级别的数据中台项目。项目的核心挑战在于：底座层（数据接入、清洗、治理、安全管控）是典型的合规和高耦合驱动，涉及等保三级、与20+委办局数据源对接、需通过第三方安全审计；应用层（数据可视化仪表盘、预警规则引擎、报表服务）则需要在探索中快速响应不同委办局的个性化需求。

团队规模约120人，分布在三个城市。项目经理面临的困境非常典型：推纯敏捷，底座层的质量和合规追溯根本满足不了审计要求；推纯瀑布，应用层的交付节奏又跟不上各委办局领导的期望。

2. 解决方案：以PingCode为协同基座的“宏观瀑布+微观敏捷”

这个团队最终采用了一种我称之为“双轨管理”的架构，而PingCode作为协同平台提供了关键的流程承载能力。

轨道一：底座层走强化瀑布

底座层的需求被定义为史诗级别的条目，在PingCode中通过“史诗-特性-用户故事”进行三级管理。关键的是，每一个数据接口的技术规格都被固化为一个独立的用户故事，并且通过自定义字段标注了等保条款的对应关系。这种“需求-合规”的双向追溯，在PingCode中通过关联关系图谱自动生成，审计人员可以直接看到一个接口变更影响了哪些合规条款，反之亦然。

底座层的迭代周期设置为核心模块上线的一个里程碑，而非标准的2周sprint。每个里程碑有严格的准出条件：代码审查完成率100%、安全扫描零高危漏洞、第三方渗透测试报告通过、相关文档（接口规范、数据字典、部署手册）同步更新完毕。这些准出条件在PingCode中被配置为工作流的必填校验项，做不到就不能从“开发中”流转到“已完成”。

轨道二：应用层走轻量迭代

在底座层每个里程碑版本的“稳定窗口期”内，应用层团队采用2-3周的迭代节奏进行功能开发和需求响应。他们的Backlog在PingCode中单独维护，但与底座层的史诗保持关联，当某个应用需求需要对底座层接口提出变更时，会自动触发一个“跨轨道变更请求”，进入底座层的CCB评审流程，而不是直接在sprint内部消化。

3. 实际成效数据

这个项目在16个月内完成了底座层的三个里程碑版本和应用层的11个业务仪表盘交付，我拿到了几个关键数据：

• 第三方安全审计一次通过：由于所有合规要求从需求阶段就已经被标签化和追溯，审计组在文档审查环节的周期从预期的3周压缩到9个工作日。
• 底座层接口变更次数从初期的每周7次下降到稳定期的每月1-2次：不是因为团队“不响应变化”，而是因为前置的技术预研和架构评审把大量潜在变更提前消化了。
• 应用层交付速度没有因底座层的瀑布节奏而拖慢：应用层的平均迭代交付周期从项目初期的3.2周降到后期的2.1周，因为底座层接口的稳定给了应用层团队极大的确定性，他们不需要在每个sprint里处理“接口突然改了”这类意外。

PingCode在这个案例中所扮演的角色值得单独讲一下：它不是单纯的“工具”，而是两种不同管理节奏的翻译层。瀑布轨道的阶段门控、准出校验、变更追溯通过工作流自定义实现；敏捷轨道的Scrum看板、燃尽图、站会管理通过项目模板支持；而两条轨道之间的信息互通，例如一个应用层需求对底座层产生变更影响时，通过关联关系和自动化规则打通，而不是靠项目经理手动在各个系统之间搬运信息。这个“打通”能力，恰恰是大多数中大型企业在混合方法论实践中最大的痛点。

六、行动建议：如何在你的组织里落地“强化瀑布”

1. 第一步：把“风险”从形容词变成名词

我在很多企业的项目管理培训中做过一个实验：让参训者写下他们项目的“三大风险”。超过60%的人写出来的都是诸如“进度延期”、“质量不达标”、“人员流动”这类泛化表述。这些不是风险，这些是风险发生后的后果。

真正的风险管理要求你把风险写成一个“不定式”：什么事件、在什么条件下、以什么概率发生、会导致什么后果。

举个例子，不要写“技术可能做不出来”，而要写“图像识别模型在目标硬件（算力≤2TOPS）上的推理延迟超过100ms的概率约为40%，如发生将导致产品不满足实时性要求，需要降级为后端处理方案或更换更高算力芯片”。

这个颗粒度的风险描述为什么重要？因为它直接决定你在瀑布框架中的阶段门控怎么设、前置验证做什么、验收标准怎么定。如果你的需求文档里只有笼统的“性能要求达到行业先进水平”，那无论你用瀑布还是敏捷，这个风险都不会被管理。

2. 第二步：重构你的阶段门控

瀑布模型的“阶段门控”在大部分团队里形同虚设，评审会开成汇报会，门控条件被简化为“文档已提交”。我在前文提到的金融项目复盘后做了一个改变，这个改变后来在四五个重点项目里被复制：

用“风险清单清零”替代“文档清单齐套”作为阶段准入准出条件。

具体操作是：每个阶段在开始前，必须先定义专属风险清单，这个阶段有哪几条已知的不确定性，必须在这个阶段结束前被排除或被缓解到可接受水平。阶段的准出评审不再是读文档，而是逐条核对风险清单的关闭情况。

• 需求阶段的专属风险：业务规则是否存在歧义？合规条款是否完整覆盖？系统边界是否已与所有利益方书面确认？
• 设计阶段的专属风险：关键技术路径是否有PoC验证？接口契约是否与外部系统团队获得书面确认？架构方案是否通过了正式的同行评审？
• 编码阶段的专属风险：核心算法的单元测试覆盖率是否达标？集成测试是否覆盖了所有高风险数据路径？

这个机制的底层逻辑很简单：你没法“管理”一个你没说清楚的风险。大部分项目失控不是因为风险发生了，而是因为风险在没人注意的地方悄悄发生了，等到发现时已经救不回来了。

3. 第三步：在正确的地方插入敏捷的“探针”

我反复强调这篇文章不是主张“全面回归瀑布”。强化瀑布不是复古，而是升级。升级的一个核心做法是在瀑布的各个阶段中有意识地插入轻量级的敏捷实践，我称之为“探针”：

• 需求阶段插入“低保真原型迭代”：在需求文档定稿前，用Figma或甚至纸面原型做3-5轮用户验证，每轮只花1-2天。这不改变需求的基线化节奏，但大幅提升了需求质量。
• 设计阶段插入“架构刺探”：针对技术不确定性最高的1-2个点，做短平快的技术验证（时间盒控制在1-2周），产出一份“可行/不可行/有条件可行”的判断报告，而不是等到编码阶段才发现架构设计在天上飞。
• 测试阶段插入“持续反馈窗口”：在正式测试阶段的中段设置一个面向业务方的“预发布演示窗口”，收集一轮非正式反馈。这个反馈不进入正式的变更流程（因为会冲击CCB机制），但作为下一里程碑版本的需求输入进行记录和排序。

探针和主流程的关系，类似航天器上的姿态调整发动机，它们的存在保证了主推进器的方向始终正确，但它们不改变主推进器的运行逻辑。

4. 第四步：为你的瀑布项目选择正确的工具基座

一个经常被忽视的问题是：传统的瀑布项目用Excel+Word+邮件来管理，这在10人以下的小团队勉强可行，但一旦团队规模超过30人，且涉及跨部门协同和合规追溯，信息孤岛和版本混乱就会成为一个独立的效率杀手。

我在推荐工具时有一个明确的判断标准：这个工具必须能同时支撑“结构化流程”和“灵活协作”两种模式，且二者之间的数据能自动关联而非手动搬运。PingCode在这个维度的表现，是我愿意在本章单独提及它的原因。它的工作流引擎可以配置出严格的阶段门控（需求→设计→编码→测试→发布，每个节点的必填字段和校验规则），但在同一个项目空间里又可以运行Scrum看板和看板方法，让不同节奏的团队共用一个数据视图。

更重要的是，它的关联关系图谱功能，从史诗到用户故事到任务到代码提交到测试用例的一整条追溯链，解决了瀑布项目中最让人头疼的“需求追溯矩阵维护成本过高”的问题。传统做法是花一个专人每周花一两天手工更新追溯矩阵，而在这个系统里，追溯关系随着任务的流转自动生成。对于有合规要求的项目，这个能力不只是“方便”，而是“刚需”。

七、取舍：在不同场景下你需要承认的代价

1. 用瀑布，你主动放弃的是什么

任何一个方法论选择都伴随着代价，回避代价只谈收益是不诚实的。用强化瀑布管理高风险创新，你需要在以下三个维度上主动接受一些“慢”：

（1）早期交付物的可见速度会变慢

团队在需求和技术预研阶段可能连续4-6周没有任何一行面向用户的功能代码产出。这对于习惯了“两周一个demo”的利益相关方来说，需要一定程度的沟通和心理建设。我在实际操作中的做法是：用风险关闭清单替代功能Demo作为早期阶段的“产出证明”，每周周报里列出的不是“完成了几个用户故事”，而是“排除了几条技术不确定性和几个需求模糊点”。这需要教育和引导你的stakeholder理解：在高风险项目里，排除风险本身就是一种产出。

（2）响应变化的速度会变慢，而这是故意的

当系统架构进入“接口冻结”状态后，一个来自业务方的新增需求无法在2周内被纳入开发，它必须经过影响分析、CCB评审、可能还会推迟到下一个里程碑版本。对于业务方来说，这看起来像是“流程太僵化”。但你必须清醒地意识到：这种“僵化”是有意的，因为随便放行一个变更的代价，可能是整个底座层架构的连锁破坏。你需要向决策层清晰地沟通这个取舍逻辑，把CCB的评审记录作为一种“风险治理的证据”留存，而不是让它演变成“谁在阻碍业务”的政治问题。

（3）团队中偏好“做出来再说”的成员会有挫败感

有一类高绩效的开发人员天生喜欢快速出活、快速看到的成果。在瀑布框架的前期，他们可能会因为大量的文档工作和技术预研迟迟等不来“正式编码”而感到沉闷。这需要你在人员配置上有意识地对冲，在项目团队中保留至少20-30%的成员投入到“探针”性质的快速验证任务中，让他们保持节奏感和成就感，同时为主流程的前置工作创造输入。

2. 用敏捷，你主动放弃的是什么

反过来，如果你在一个高风险创新项目中选择纯敏捷路径，你也在主动做出一些取舍。公平起见，我把这部分也讲清楚：

（1）合规证据链的完整性：敏捷团队倾向于动态文档，但审核员需要的是静态基线。如果你在项目后期才开始补文档，补出来的文档质量不仅低，而且与实际的代码和测试结果之间会存在大量不一致，这种不一致在审计中被发现后，后果比“文档不完整”更严重，因为会被质疑造假。

（2）架构决策的全局一致性：多团队并行迭代时，架构演进的全局一致性很难保持。A团队优化了缓存策略，B团队重构了数据模型，两个改动在各自sprint内都是合理且正确的，但在集成时产生了一个新的边界条件Bug，而这种Bug只有在端到端测试阶段才会暴露，修正成本极高。

（3）风险关闭的仪式感缺失：这是我在敏捷项目中观察到一个微妙但重要的现象。瀑布的阶段门控机制强制团队在某一个时间点坐下来，认真地问自己：“这个阶段的风险，我们真的排除了吗？”敏捷的持续交付节奏里缺乏这样一个自然而然的“停顿点”，结果是某些风险被拖着拖着就忘了，直到它们爆发。

3. 做个诚实的汇总

八、收尾：从“方法论崇拜”到“风险判断”

在项目管理这个领域工作了这么多年，我最深的体会是：绝大多数方法论之争，本质上是对主导权之争的伪装。主张敏捷的人往往更信任一线团队的自组织能力，主张瀑布的人往往更信任流程和制度的约束力。这两类人的底层价值观本来就不同，这也是为什么这个问题吵了二十年也没有共识。

但如果你把争论的焦点从“哪种方法更好”转移到“这个项目的风险特征是什么”，你会发现方法论的选择就变成了一个技术问题，而不是信仰问题。本文的核心意图，就是为你提供这样一套从风险特征推导方法论选择的思维框架，以及当瀑布框架被选中后，如何把它升级为一个有效的风险控制体系，而不是一堆没人看的流程文档。

我的下一步建议是这样的：

1. 拿一个你正在管理的或即将启动的项目，做一次“风险类型诊断”。按照我在第二部分列出的四类风险（市场、技术、合规、组织），给你的项目打分，每类1-5分。如果技术风险+合规风险+组织风险的总分超过10分，认真考虑采用本文描述的强化瀑布框架。
2. 如果你已经在一个高风险项目中陷入“名义敏捷、实际混乱”的局面，不要试图全盘推倒重来。从中斩出一个“底座层”或“核心模块”，单独为它建立瀑布的阶段门控和风险清单机制，让这个模块先稳下来。剩余的探索性功能继续走敏捷。这种渐进的混合过渡比“大爆炸式方法论转型”的成功率高出不止一个数量级。
3. 如果你决定采用瀑布框架，同时把你的工具链审视一遍。问问自己：你的需求管理工具能不能承载“需求-设计-测试-合规”的全链追溯？你的工作流能不能强制执行阶段门控的准出条件？你的团队成员在一个工具里就能看到所有信息，还是需要在四五个工具之间来回搬运？工具不是万能的，但在规模化团队中，一个无法承载结构化流程的工具会把你的方法论执行成本拉高30-50%。

最后说一句我经常讲给团队听的话：没有烂的模型，只有用错了场景的模型。瀑布不死，它只是需要被用得恰到好处，而“高风险创新项目”，正是它最值得被用好的地方。