需求优先级落地方案：企业管理者开展需求管理的制度设计案例解析

需求优先级失灵，通常不是团队不会打分，而是打分结果没有真正改变资源分配：高分需求仍要排队，临时指令照样插队，业务部门则继续用“紧急”争取开发时间。企业管理者设计需求管理制度，重点不应是再造一张评分表，而应把需求从提出、判断、承诺、交付到复盘连成闭环，并明确谁有权决定、依据什么决定、改变决定要付出什么代价。

一、先讲核心结论：优先级不是分数，而是资源承诺规则

1. 先把“排队顺序”与“准入门槛”分开

我在梳理需求制度时，通常先问一个问题：这套优先级机制究竟要解决什么？如果它要解决的是“哪些需求可以进入计划”，那就需要准入条件；如果它要解决的是“有限资源先做什么”，那才是排序规则。把两者混成一个总分，容易让一项价值很高但还没准备好的需求挤进开发计划。

举例来说，某需求预估能带来显著收入，但目标客户、验收口径和数据来源都不清楚。它可能值得继续研究，却未必已经具备排期条件。制度应允许团队把它标记为“高价值、待验证”，而不是因为高分就直接承诺交付。优先级决定先后，准备度决定能否承诺；两者不应由同一个分数替代。

2. 把需求决策写成可执行的管理规则

一套能落地的制度，至少需要回答五件事：谁能提交需求、谁负责补充证据、谁参与评估、谁有最终裁决权、需求进入计划后怎样处理变更。若只规定“按业务价值排序”，却没有规定冲突时谁拍板，团队仍会回到临时协调和职位权力。

• 入口规则：明确必填信息、需求类型和受理范围，避免未经澄清的想法直接进入排期池。
• 评估规则：统一价值、时效、成本、风险和战略匹配度的定义，避免同一指标被不同部门随意解释。
• 决策规则：明确评审角色、决策周期、例外审批人和记录方式。
• 执行规则：说明计划容量、插队条件、变更成本以及被挤出需求如何重新安排。
• 复盘规则：检查预估是否准确、结果是否实现，以及规则是否产生了预期行为。

我建议把制度目标写成“在固定周期内，优先投入有限产能到价值更高、证据更充分且风险可控的事项”，而不是“让所有需求都尽快完成”。前者承认资源有限，也允许管理者作出取舍；后者会把制度变成无法兑现的承诺。

3. 用决策记录让优先级可以被解释

优先级不是永久标签。客户结构变化、法规要求变化、技术风险暴露，都可能改变原来的排序。因此，评审记录不应只保留一个等级，还要保留决策日期、主要依据、关键假设、反对意见和下次复查时间。这样做不是为了增加文书，而是让团队能回答“当时为什么这样排”。

如果管理者只看到“最高优先级”，却看不到该标签的依据，优先级就无法用于复盘。需求延期后，团队也无法区分是估算错误、外部条件变化，还是管理层中途调整了方向。

二、背景和真实场景：需求池为何会变成“谁催得急谁先做”

1. 组织变大后，需求数量和协作成本一起增长

在小团队里，需求常由同一位负责人拍板，信息可以靠口头补齐。组织扩大到多个业务线、产品团队、技术团队和区域团队之后，需求来源开始分散：销售有客户承诺，运营有流程问题，合规有时限要求，技术团队有平台治理事项。每一项看起来都有理由，冲突却不可避免。

当需求数量超过团队可处理能力，问题不是“大家不够努力”，而是组织没有显式表达放弃什么。需求池越积越长，团队仍不断接受新承诺，管理者看到的是“每项都很重要”，一线看到的却是切换频繁、计划反复、完成率下降。

2. 典型症状是计划不断被打断，而不是需求没有分级

我通常从几个现象判断机制是否失效：一个迭代中途插入多项任务；不同部门对同一需求的优先级描述相互矛盾；已经排期的工作没有明确的替换对象；需求延期后只调整日期，不调整范围；评审会议结束后，参会者仍不清楚谁负责下一步。

这类组织经常已经有“高、中、低”标签，甚至有复杂的打分表，但标签没有关联容量、决策权和变更成本。于是，团队花时间打分，实际却按催办频率排序。真正的制度缺口不是缺少等级，而是等级没有后果。

3. 企业案例：同一团队同时面对增长、客户和治理诉求

以下案例是为说明制度设计而构造的情景模拟，不对应某家企业的真实经营数据。某企业有三个产品团队，共同服务企业客户。月初需求池中有客户定制、关键流程优化、数据治理和平台稳定性事项。销售希望先完成两个大客户功能，运营希望降低人工处理，技术团队则发现一项旧接口存在持续性故障风险。

如果只按“预计收入”排序，定制需求可能长期占据前列；如果只按“影响用户数”排序，平台风险可能被忽略；如果由各部门负责人各自打分，指标口径又不一致。制度设计需要把业务收益、影响范围、时效、成本、风险和组织目标放到同一决策框架中，同时保留不同类型事项之间的必要边界。

4. 多部门协作需要统一“需求语言”

业务部门说“客户必须要”，产品部门需要知道客户是谁、是否签约、影响哪些使用场景；技术部门需要知道依赖关系、实现风险和维护成本；管理层需要理解收益、损失或合规后果。制度并非要求所有人使用同一套专业术语，而是要求同一需求能被不同角色依据同一组事实讨论。

需求描述若停留在“增加一个按钮”，技术人员很难判断它解决的业务问题；若只写“提升客户满意度”，决策者又难以比较不同需求。有效的需求语言，应从用户问题出发，说明目标对象、触发场景、现状证据、预期变化和验收方法。

三、常见误区：为什么看起来公平的打分，最后仍然失效

1. 误区一：把分数当成决策本身

评分表能帮助减少凭感觉排序，却不能替代管理判断。若一项需求的收益评分为五分，另一项为四分，分差并不自动意味着前者值得立刻启动。评分受证据质量、评估者经验和量表定义影响，精确到小数点的总分，不代表决策就有同等精度。

我更倾向于把评分视为“讨论的压缩工具”，而非自动裁决器。对分值接近的需求，评审应回到差异最大的假设：价值测算是否可靠、受影响用户是否重叠、实现成本是否低估、时限是否真实。评分可以给出排序信号，不能替组织承担取舍责任。

2. 误区二：所有需求都用同一把尺子比较

增长需求、合规需求、稳定性需求和体验优化需求的收益结构不同。增长需求可能有转化或收入数据，合规需求可能体现为避免处罚或满足审计要求，稳定性需求的价值则经常表现为减少故障概率和恢复成本。要求它们都用短期收入打分，会系统性压低风险治理和基础能力建设的优先级。

处理方法不是为每种类型建立一套完全独立的制度，而是先设置类型门槛，再在相同类型内比较。法定时限、重大安全风险和持续性稳定问题，可以进入特定的强制评审通道；满足强制条件后，再决定范围、排期和资源比例。这样既保留横向比较，也避免把不能交换的责任误当成普通需求竞争。

3. 误区三：用“紧急”代替可验证的时效

“客户很急”“领导关注”“下周必须上线”都不是充分的时效依据。管理者应进一步追问：截止日期由什么事件决定？错过期限的损失是什么？是否存在临时替代方案？如果只是内部期望，能否通过缩小范围满足？

真正的时效应能解释时间与损失之间的关系。例如，外部政策在某日生效、合同约定某日验收、关键客户在明确决策窗口内评估方案，都比“尽快”更容易核验。若截止日期无法说明来源，评审可先将它作为待确认信息，而不是自动提升优先级。

4. 误区四：估算只看开发工时，不看机会成本

一项需求看起来只需两周开发，不代表真实成本只有两周。还可能包括需求澄清、测试、数据迁移、客户沟通、上线支持、后续维护和被打断工作的恢复成本。尤其是跨团队依赖，等待和协调时间可能比实际编码时间更长。

优先级决策应询问“投入这项工作，哪些已有工作要延后”，而不只是“这项工作多大”。没有替换对象的插单，本质上是在隐藏机会成本。只有把被挤出的工作写出来，管理层才看得到真实取舍。

5. 误区五：评审会变成信息补课会

如果评审会上才第一次讨论用户是谁、收益如何测量、技术风险有哪些，会议就会被背景介绍占满，最终只能凭印象拍板。评审会之前应完成最基本的材料检查，让会议集中在冲突、假设和取舍上。

这并不意味着每项需求都要准备厚重文档。小型需求可以用简短模板，大型或高风险事项需要更充分的证据。关键是让提交成本与潜在影响相称，不要用统一的长表单消耗低价值需求的澄清时间。

四、专业判断逻辑：把价值、紧迫性、成本和风险拆开评估

1. 价值判断先回答“改变什么”，而非“听起来多重要”

我建议把需求价值拆成可解释的结果维度：收入或转化改善、用户流程耗时下降、客户留存或服务质量提升、运营成本减少、风险暴露降低、战略能力建设。并不是每项需求都需要覆盖所有维度，但提交者应说明主要价值来自哪里，以及用什么信号判断结果发生。

例如，“改进搜索体验”不是可直接比较的价值描述；“目标客户查找某类记录的中位耗时预计从三分钟降至一分钟，并减少客服求助”则包含对象、现状和结果方向。若基线数据暂时不存在，制度应允许先安排验证工作，而不是把未经验证的预期收益当作既定事实。

2. 时效性要看错过窗口的后果

时效不是越紧越高，而是延迟产生的边际损失有多大。若需求晚一个周期只会推迟有限收益，时效评分不应夸大；若延迟会导致合同违约、政策不符合或重要客户决策窗口关闭，则应说明具体损失和时间边界。

评审时可以把时效证据分成“外部确定期限”“业务窗口”“内部期望”三类。外部确定期限通常需要文书或政策依据；业务窗口需要说明客户决策、市场活动或运营周期；内部期望则应与其他因素共同判断。这样的分类能减少将普通催办伪装成硬期限的情况。

3. 成本与不确定性要分开记录

需求成本估计回答“投入可能有多大”，不确定性回答“我们对这个估计有多大把握”。一个估计为十人天的需求，如果上下浮动很大，可能比估计为十二人天但路径清晰的需求更难纳入短周期计划。

对于高不确定性事项，可以先做技术验证、用户访谈或数据分析，再进入正式排期。验证本身也需要明确时间上限、成功条件和停止条件。否则，“先研究一下”容易成为没有期限的隐性项目。

4. 建议采用分层评分，而不是单一总分排名

在制度刚启动时，我建议使用少量维度，每项采用清晰的低、中、高等级，并要求评估者给出证据。可用下表作为起点。表中阈值属于制度设计示例，企业应根据业务模式和历史数据校准，不能直接当作普遍行业标准。

5. 决策时先设硬约束，再做同类比较

管理者可以采用“硬约束筛选，同类排序，容量决策”的顺序。第一步确认是否触及法定、合同、安全或重大稳定性要求；第二步在同类需求中比较价值、成本与时效；第三步根据本周期容量决定做多少，并明确不做什么。

这比把所有需求丢进公式求一个全局名次更稳健。公式可以帮助筛选和暴露差异，但最终仍要由有授权的角色作出取舍。尤其当不同需求分别代表收入机会和风险控制时，单一总分可能掩盖企业的风险偏好。

五、制度设计案例：从评分结果走到资源承诺

1. 案例边界：把场景模拟说清楚

下面继续使用一个情景模拟案例，演示制度如何从规则转化为操作。假设一家企业有三支产品团队，服务超过百人的内部协作网络，并同时管理客户需求、运营优化和平台治理事项。团队过去按月收集需求、按双周安排工作，但插入任务没有统一审批机制。

企业不需要先购买复杂系统才能开始治理。可以先用统一表单、共享需求池和评审记录跑通规则，再根据需求量、跨团队依赖、权限管理和审计要求决定是否引入专门平台。若已有工具难以支撑流程和权限，工具升级应服务于制度，不应反过来让流程迁就工具字段。

2. 建立需求入口：让提交者先说明问题和结果

入口表单应尽量短，但必须能筛出不可评估的信息。我的建议是先要求提交者写清楚：谁遇到什么问题、发生在什么场景、当前影响是什么、预期改变是什么、怎样验证改变。若需求来自客户，还应说明客户类型、承诺状态和是否存在可替代方案。

对于纯技术治理需求，也不应强迫填写虚构的收入预期，而要说明当前风险、影响范围、故障或维护证据、可能的损失和缓解选项。入口设计的原则是“不同类型允许不同证据，但所有事项都要讲清为什么值得占用容量”。

3. 设置三类决策通道，避免所有事项挤在一场会议里

• 常规需求：由产品、业务和技术代表按固定周期评估，适用于一般功能优化和流程改进。
• 强制时限需求：由责任部门提供政策、合同或安全依据，管理者确认范围与资源调整，不以普通商业价值分数决定是否履责。
• 紧急运行事项：针对生产故障、重大服务中断或严重安全风险，按应急机制处理，事后补齐决策记录并复盘。

分通道不是给需求贴“特殊”标签的捷径。通道必须有进入条件、授权人和复盘要求。若每个部门都能自行声明“紧急”，例外通道就会吞掉常规规则。

4. 评审会议只处理决策，不替代需求澄清

在评审前一天锁定材料，需求负责人对缺项做标记。会上先检查硬约束，再讨论价值、时效和成本差异，最后决定进入计划、继续验证、暂缓或拒绝。每项决定都应记录负责人和下一步日期，而不是只留下“后续跟进”。

有分歧时，主持人不必强求所有人达成一致。可以记录支持与反对的关键理由，由有授权的决策人裁决。制度的目标不是消除分歧，而是使分歧透明、可追溯，并把责任放在正确层级。

5. 采用容量预留，而不是把每个人排满

在计划周期中，团队通常还要处理缺陷、客户支持、平台维护和估算偏差。若计划容量按百分之百填满，任何波动都会变成延期或加班。企业可以先观察过去若干周期的实际工作构成，再设定计划工作与非计划工作的容量边界。

例如，某团队复盘发现，过去六个周期平均约有五分之一工作量用于临时修复和支持，管理者就不应把全部人力承诺给新功能。这里的比例应来自本团队的历史记录，而不是照抄其他组织。团队规模、产品成熟度和服务等级不同，合理预留也会不同。

6. 插单必须同时说明替换对象和复原方式

如果计划中途确需插入高优先级工作，审批人应明确三件事：新事项为什么现在做、哪项既有工作被延后或缩小、受影响方何时收到通知。若无法明确被替换工作，说明组织尚未看见插单的全部成本。

被挤出的需求应回到需求池重新评估，而不是保留原日期等待团队自行补偿。否则，团队会同时背负新旧承诺，最终由加班和质量风险承担管理决策的代价。

7. 用工具支撑可追溯性，但不把工具当制度

对于跨部门、多团队、需要权限隔离或审计留痕的组织，需求管理平台可以帮助统一入口、状态、评审记录、优先级变更和关联工作项。选择工具时，我会先验证它是否支持团队实际流程、权限边界、数据导出、部署要求、历史迁移和管理报表，而不是先比较功能清单的长度。

以 PingCode 为例，它面向中大型企业及百人以上组织提供需求和研发协同场景；据其产品资料，支持私有化部署，并提供从 Jira 平滑迁移的能力。对正在评估国产项目管理平台的企业，这些是值得进入验证清单的条件，但“支持迁移”不等于所有数据、字段、权限和工作流都能无损自动转换。上线前应做样本迁移、差异核对和回滚演练，并结合合同、技术文档及实际测试确认适用范围。

我不会把任何产品描述直接写进制度作为前提。制度应独立定义需求状态、决策角色、例外规则和指标；工具负责让规则容易执行和追踪。若工具无法完整承载流程，可以先保留必要的人工评审，不要为了界面方便删掉关键控制点。

六、指标与复盘：检查制度有没有改善决策

1. 不要只用交付数量衡量优先级制度

按期交付率能反映计划稳定性，却不能说明团队是否做对了事；完成需求数容易受拆分方式影响；需求池变短也可能只是把未评估事项删除。管理者应同时观察流程、计划、结果和公平性，避免单一指标诱导团队优化表面数字。

我建议先设一组小而有解释力的指标：需求评估周期、承诺后范围变更率、计划内工作占比、需求结果达成率、插单替换记录完整率，以及因信息不足退回的比例。指标用于发现制度问题，不应立即与个人绩效绑定，否则提交者会美化收益、团队会回避高风险事项。

2. 把预测准确性和实际结果分开看

预测准确性关注估算、日期和风险判断是否可靠；实际结果关注需求是否解决问题。两者可能背离：团队按期交付了一个用户并不使用的功能，说明预测可能准确，价值判断却失败；需求创造了明显收益但延期数周，则结果不错，执行预测仍需改善。

每个需求在评审时应确定一个最小可验证结果。若目标是降低处理时间，就测量处理时间；若目标是提升关键流程完成率，就定义分母、分子和观察周期。没有基线时，先做基线测量，避免上线后才临时挑选有利数据。

3. 以固定周期做规则复盘，而不是频繁改分数

建议每季度或每几个计划周期检查一次规则。复盘重点不是“某需求当时分数打得对不对”，而是看哪些假设经常失准：高价值需求是否低估了维护成本，所谓紧急是否大多没有外部期限，跨团队事项是否持续因依赖而延期，例外通道是否被滥用。

如果某类需求常在交付后达不到预期，可能不是团队执行差，也可能是入口证据质量不足；如果某类工作长期排不上，可能是制度指标偏向短期收益。复盘应允许修正指标定义、流程门槛和容量配置，而不是只增加审批层级。

七、不同情况下的行动建议：按组织成熟度逐步推进

1. 需求很多，但基本信息经常缺失

先不要上复杂评分。用最小提交模板补齐问题、对象、证据、预期结果、负责人和验收方法，再由产品或业务运营人员做初筛。设置短周期的补充时限，过期未补充的事项回到待澄清状态，避免长期占据评审注意力。

这一阶段的核心指标是信息完整率和从提交到可评估的时间。若完整率低，优先修复入口培训和模板设计；不要通过增加更多评分字段解决信息质量问题。

2. 需求信息完整，但部门之间争抢资源

此时重点是明确决策权和比较口径。建立跨部门评审组，成员提供证据和专业判断，最终裁决人对容量取舍负责。讨论中必须显式写出被延后的事项，并定期把未入选需求重新检查，避免形成永久性的部门资源不平衡。

如果争议主要来自不同业务线的收益难以比较，可以先对齐战略目标和结果指标，再讨论各自的证据。不要要求一个部门把所有收益都换算为收入，尤其是风险、合规和服务质量等不能简单货币化的事项。

3. 计划总被紧急事项打断

先区分真正的突发事项和计划内维护。如果大多数插单都来自可预见工作，问题在容量规划或入口机制，而不是团队执行力。记录插单原因、来源、影响范围和替换对象，连续几个周期后再调整预留容量及应急通道门槛。

如果生产故障确实频繁，应先改善稳定性与运行机制，而不是不断压缩功能团队的计划容量。管理者需要判断根因属于产品质量、基础设施、监控响应还是外部依赖，再决定是增加保障投入还是改变服务承诺。

4. 企业有严格权限、部署或迁移要求

先把安全、数据驻留、审计、身份认证、权限隔离、备份恢复、接口集成和供应商支持写成验收条件，再做平台验证。对于私有化部署需求，应实际核对升级方式、运维责任、资源配置、灾备方案和版本差异；对于从既有系统迁移的需求，应抽取真实数据样本测试字段映射、附件、历史记录、权限和关联关系。

采购决策不应只依赖演示环境。建议由业务、研发、信息安全和运维共同完成小范围试点，预先定义通过标准与失败时的回退方案。迁移成功的标准不仅是数据导入，还包括用户能否继续工作、历史决策是否可追溯、报表是否可信。

5. 团队人数不多，流程负担已经偏重

小团队可以采用轻量制度：一页需求说明、每周一次短评审、明确负责人和容量上限。不要复制大型企业的多层审批，也不要为了追求“规范”让低风险改动等待数周。制度的复杂度应与决策风险相称。

但轻量不等于口头承诺。即使团队只有十几人，也应保留需求来源、优先级变化、承诺日期和验收结果。记录可以很简洁，只要关键决策能在人员变化后被理解。

八、不同情况下的取舍：制度设计没有万能分数

1. 速度与严谨之间，按风险分层

低成本、可逆、影响范围小的需求，可以简化评估，快速进入短周期计划；涉及核心数据、安全、广泛用户或高迁移成本的需求，应增加验证和审批。统一要求所有事项同等严谨，会拖慢小改动；统一追求快速，又会把高风险决策变成试错。

区分流程的关键不是“重要与不重要”，而是错误决策的影响、可逆性和发现时间。可快速回滚的实验可以容忍更轻的前置评估；难以恢复的数据变更则需要更强的前置控制。

2. 短期收益与长期能力之间，设置组合而非永久配额

平台治理、架构演进和自动化能力常常没有立刻可见的收入，但持续忽略会提高后续交付成本。管理者可以通过周期性检查组合结构，确认增长、客户价值、风险治理和基础能力都有合理投入，而不是为每类事项永久设死比例。

投入比例应随阶段变化。产品早期可能更强调市场验证，规模扩大后可靠性、权限和数据治理的重要性上升。管理层要说明当前选择的原因和复查日期，避免暂时的资源偏向变成长期惯性。

3. 客户定制与通用能力之间，比较总拥有成本

客户定制可能帮助赢得合同，也可能带来分支维护、升级困难和长期支持负担。评审时除了合同收益，还要估算复用可能性、交付时限、后续维护、与产品方向的冲突和退出方式。若收益集中于单一客户、维护成本由多个团队承担，决策不能只由销售单方面作出。

企业可以探索配置化、扩展点或分阶段交付，先满足关键场景，再评估是否纳入通用产品。但要避免把“未来可复用”当成未经验证的收益。复用价值应由明确的客户群、相似场景或后续路线图支持。

4. 公平比较与专业裁量之间，保留可审计的例外

制度越强调统一评分，越需要承认评分无法覆盖所有情境。管理者可以保留有限的裁量权，但每次例外都应记录理由、授权人、影响和复查日期。例外不是制度的失败；没有记录、无法复盘的例外才会削弱制度公信力。

如果例外反复出现，应检查规则是否设计错误。比如，某类经常性法规事项仍每次走临时通道，说明应将其纳入常规规划；某团队持续以客户承诺插单，说明承诺流程需要前置治理，而不只是提高插单审批门槛。

九、下一步怎么做：先跑通一个周期，再扩展制度

1. 用一周完成制度最小版本

1. 整理历史需求：抽取最近几个周期的需求、插单、延期和撤回记录，区分可预见事项与真正突发事项。
2. 定义需求类型：至少区分常规业务需求、强制时限事项、运行保障事项和探索验证事项。
3. 写出入口字段：规定问题、对象、证据、预期结果、负责人和验收方式，不为每种需求强行要求相同收益数据。
4. 确定评审角色：明确谁准备材料、谁评估成本、谁裁决资源冲突、谁负责结果复盘。
5. 公开容量规则：说明团队如何预留支持和修复工作，以及插单时必须替换什么。

2. 用一个计划周期验证流程，而不是急着追求完美

第一轮执行时，管理者应观察规则是否让决策更清楚，而不是只看表单是否填写完整。记录需求从提交到可评估花了多久，会议中哪些信息反复缺失，插单是否留下替换记录，团队是否知道被延期工作的下一步安排。

周期结束后，选取几项已交付需求核对预期结果；再选取几项未入选需求，检查其是否因为低价值、证据不足、容量限制或高风险而被暂缓。不同原因需要不同后续动作，不能一概标注“未通过”。

3. 成熟后再决定是否自动化和扩大工具使用

当需求量增加、跨团队协作变复杂、审计追踪要求提高时，才更有必要把流程状态、权限、关联工作和报表系统化。平台评估应围绕真实工作流做试点：从提交、评估、决策到变更和复盘完整走一遍，检查是否减少重复录入、是否保留决策依据、是否能按角色控制信息访问。

如果涉及从现有系统迁移，应把迁移当作独立项目管理，设置数据范围、映射方案、校验规则、用户培训和回退计划。工具切换本身不会自动改善优先级，只有当新流程让关键决策更透明、执行成本更低、反馈更及时，迁移才有管理价值。

4. 最终判断：制度的价值在于让“不做什么”也能被管理

需求优先级落地的关键，不是找到一个所有人都认可的完美算法，而是让组织能够基于共同证据作出有限资源下的选择，并承担选择带来的影响。高分需求如果证据不足，可以先验证；低收入事项如果承担明确风险，可以进入强制评审；紧急事项如果挤占既有计划，必须说明被推迟的工作。

我认为，成熟的需求管理制度有一个容易被忽视的标志：团队不仅知道现在做什么，也知道哪些事情暂时不做、为什么不做、何时重新判断。下一步可以从最近一个周期的需求池开始，选出二十至三十项需求，按“价值、时效、成本、风险、准备度”重新复盘，再用一个周期试运行入口、评审和插单规则。先让取舍可见，再追求自动化和规模化，制度才会真正改变资源流向。