项目范围如何做好Scope？研发团队流程优化与操作步骤

2023 年下半年，我参与复盘一个 42 人研发团队连续三个迭代的延期问题。翻完 200 多条需求评论、17 次评审纪要和 5 个版本的排期表之后，真正让我意外的不是“又延期了”，而是这个项目从头到尾没有一次范围变更是被“计价”过的。每一次加需求，会议室里讨论的都是“这个重不重要”，从来没有人回答“加这个要拿什么换”。于是所有变更都以“重要”为理由被放行，代价则在三个迭代之后一次性以集体加班和延期三周的形式结算。

这件事让我彻底改变了对 Scope 的看法。范围管理（Scope Management）在大多数团队里被当成一份文档工作，把需求写清楚、把边界画出来、让客户签字。但在真实研发环境里，这些动作的保质期通常不超过两周。真正决定项目成败的，不是你冻结了多少需求，而是当需求必须变化时，你有没有一套能把变化翻译成成本和取舍的机制。

这篇文章会把我这几年在十几个研发团队里踩过的坑、用过的判断框架和实际数据完整讲一遍。它不聊教科书，只聊怎么在人不增加、时间不延长的前提下，让范围这件事真正可控。

一、核心结论：Scope 管理的本质是“变更定价”，而不是“需求冻结”

先说结论：范围失控的根因，九成不是需求写得不清楚，而是变更没有价格。一个团队可以有非常详尽的 PRD、非常规范的评审流程，但只要“加一个需求”不需要付出任何可见代价，范围就一定会膨胀。这不是态度问题，是机制问题。

1. 需求冻结是幻觉，变更定价才是可操作变量

我在 2021 年做过一次统计：把公司内 7 个研发项目从立项到上线的需求条目拉出来，对比初始排期与最终交付。初始范围平均只占最终交付范围的 61%，也就是说近四成的工作量是中途长出来的。而这个比例和项目是否“写了详细需求文档”几乎没有相关性。

反过来，那些最终按期交付的项目，有一个共同点：每一次范围调整都伴随一次显式的资源交换或者显式的风险确认。要么砍掉一个同等人天的需求，要么明确延后某个里程碑，要么补人并且承认有磨合成本。它们并不比别的项目更“不许变”，只是变得更贵了。

所以我的核心判断是：把 Scope 管理的目标从“防止变更”改成“让变更可见、可比、可交换”。这个目标听起来更弱，实际效果强得多，因为它可执行。

2. 有效范围的三层结构：交付边界、验收边界、时间边界

很多团队说的“范围”其实只覆盖了第一层。我带团队梳理 Scope 时，会强制把范围拆成三层，每一层的责任人、载体和失效条件都不一样。

交付边界回答“做什么、不做什么”。它的典型载体是需求清单和功能地图，责任人通常是产品负责人。这一层最容易写，也最容易被推翻。

验收边界回答“做到什么程度算完成”。它的载体应该是可判定的验收标准，而不是“友好”“流畅”“稳定”这类形容词。这一层最容易被跳过，也最容易在验收阶段引发争议。

时间边界回答“在什么时间窗口内、以多大规模的团队完成”。它的载体是排期与人力配置。这一层最容易被当成“项目管理的事”而与范围脱钩，但恰恰是它决定了另外两层的真实弹性。

三层缺一，范围管理就会退化。只有交付边界，需求会不断加码；只有时间边界，团队会用质量换进度；只有验收边界，会出现大量“做完了但没法用”的交付。

3. 一个可以量化的判断公式

我常用一个简化公式做团队自查：

可控范围 = 明确交付物 × 可验证验收标准 × 变更成本可见度

用乘法而不是加法，是故意的。因为这三项里任何一项趋近于零，整体就趋近于零。你可以有非常清晰的交付物清单，但如果验收标准全是形容词、变更没有任何成本反馈，最终结果依然是失控。这个公式的价值在于，它让团队很容易定位自己短板在哪一项，大多数团队的短板是第三项。

4. 判断 Scope 是否管住的最小指标集

不要用“感觉还行”来判断范围管理做得好不好。我建议只盯五个指标，每周更新一次，成本很低但信息量很大。

这五个指标里，我认为最重要的是“未计价变更占比”。它几乎是一个前置信号：只要这个数字长期高于 20%，后面四个指标一定会陆续恶化，只是时间问题。

二、背景与真实场景：一个 40 人团队的 Scope 失控全过程

抽象讨论容易失真，我把上面提到的那个 42 人团队的真实时间线还原一遍。这是一条非常典型的、几乎每个中大型研发组织都走过的路径。团队规模覆盖前端、后端、测试、数据四个职能，迭代周期两周，工具链在项目中途从旧平台迁到了一个国产研发管理平台。

1. 第 1，2 周：评审很认真，但边界是“描述性”的

立项时需求池里有 68 条，评审后保留 43 条，砍掉 25 条，看上去很克制。问题出在保留的这 43 条上：其中只有 9 条写了可判定的验收标准，其余写着“支持批量操作”“交互顺畅”“性能可接受”这类描述。

当时所有人的感受是“范围很清晰”，因为清单是有的。但清单清晰和边界清晰是两回事。没有可判定验收标准的需求，等于把边界定义权推迟到了验收当天，而那一天通常是团队最没有议价能力的一天。

2. 第 3，6 周：口头需求开始渗透

第一个迭代中期，业务方在群里提了 11 条“小优化”，产品负责人评估后口头答应 7 条。这 7 条没有进入需求池，也没有进排期。它们的共同特征是“单条都不大”，单条预估 0.5 到 2 人天。

这正是范围蔓延最危险的形态。大需求会触发流程，小需求只会触发善意。一个 10 人天的需求需要走评审，而十条 1 人天的需求通常靠“顺手做了”消化掉。到第 6 周我们回捞时，这类隐性工作量已经累计到 23 人天，相当于一个迭代 15% 的容量被静默占用。

3. 第 7，10 周：验收标准在验收当天才被讨论

第二个迭代末的验收会上，出现了 6 条需求的争议。典型对话是“这个批量操作支持 500 条，但我们要的是 5000 条”。团队认为需求里没写数量上限，业务方认为“批量”本来就意味着生产级规模。

这类争议的成本极高，因为它发生在代码已经写完、测试已经通过之后。最终的结论往往是“改”，而改动涉及分页、批处理、异步任务三个模块，实际花费 34 人天，是原始预估的三倍。

4. 第 11，14 周：用加班吸收，直到吸收不了

第三个迭代，管理层要求“按期上线”。团队的反应是延长工时，前两周平均每天多工作 1.8 小时。这在短期确实追回了一部分进度，但也带来了两个副作用：一是缺陷密度上升，二是核心成员开始流失。

最终项目延期 3 周上线。复盘时把数据摊开：初始计划 1 400 人天，实际投入 1 826 人天，超出 30.4%。超出部分里，43% 来自中途新增需求，31% 来自边界不清导致的返工，18% 来自加班带来的缺陷修复，只有 8% 来自原始需求的正常低估。

三、常见误区拆解：你以为在管范围，其实在写文档

下面这五个误区，我在不同团队里反复见到。它们的共同点是：做的时候感觉非常正规，出问题时才发现拦不住任何东西。

1. 误区一：把 Scope 当成一次性的需求文档

很多团队在立项时投入大量精力写一份几十页的范围说明书，然后把它归档，之后三个月不再更新。等到发现偏差时，文档已经和现实相差三个版本。

我的判断是：范围文档的价值不在完整，而在版本可比。一份每次变更都更新的三页清单，胜过一次写好的三十页说明书。所以我现在更倾向于把范围拆成“基线 + 变更记录”两部分，基线尽量薄，变更记录尽量实。

2. 误区二：用“变更流程”替代“变更成本”

这是最常见也最隐蔽的误区。团队引入了变更申请单，走三层审批，看起来治理得很严。但审批表里只有“变更内容”“变更原因”“优先级”，没有“需要多少工作量”“占用哪个模块的容量”“影响哪个里程碑”。

结果是审批人只能凭感觉判断“这个重不重要”，而重要的事情永远排在最前面。流程齐全，但决策依据缺失。没有工作量刻度的变更流程，本质是一次投票，不是一次决策。

3. 误区三：验收标准写在测试用例里，不写在范围里

有些团队会说“我们有验收标准啊，测试用例写得很细”。但测试用例是团队内部产物，业务方在立项阶段并不会逐条阅读，也不会对用例签字。等到验收当天拿用例去对齐，业务方第一反应往往是“这不是我要的东西”。

正确的做法是把验收标准前置成范围的一部分，且必须由提出需求的人确认。我的经验是：只要强制要求每条需求填写 2，4 条可判定的验收标准，验收阶段的争议量能下降一半以上，而前置填写的时间成本大约是每条需求 10 分钟。

4. 误区四：把“不做什么”当成政治问题回避

“不做什么”是范围管理里信息量最大的一句话，也是最难写的一句话。很多团队的范围文档只写“做什么”，因为写“不做什么”意味着明确拒绝某些人。

但缺失“不做什么”的后果非常具体：它会让每一次新增需求都变成可以接受的，因为没有参照系去证明“加这个就意味着舍弃那个”。我的做法是把“本期明确不做”单独列一节，并且写清“为什么不做”和“什么时候可能做”。这样拒绝的是时间点，不是人的诉求，阻力会小很多。

5. 误区五：用加班追进度，而不是用范围换时间

当进度落后时，团队面前其实有三个选项：加人、延期、砍范围。大多数团队的实际选择是第四个，加班。加班的问题在于它的收益是非线性的：短期能追回一些进度，但缺陷率和流失率会同步上升，最终把追回的进度又吐出去。

我做过一个粗略统计：在一个持续 13 周的加班周期里，前两周效率提升约 18%，第三到第五周提升缩小到 6%，第六周之后进入负收益区间，因为返工和协作成本开始吃掉全部增益。加班是一种有隐藏利率的借贷，不是一种免费资源。

四、专业判断逻辑：用三把尺子决定“加不加”

误区讲完，说说我实际用的判断逻辑。每当有人提出范围变更，我不会先问“这个重不重要”，而是依次量三把尺子。这三把尺子的顺序不能颠倒，因为它们的成本量级差异很大。

1. 尺子一：交付物能不能被独立验收

第一个问题永远是：“这个需求做完之后，用什么动作可以判断它完成了？”如果答不上来，我不会进入后续讨论，因为它连进入范围基线的资格都没有。

很多需求卡在这一关。不能被独立验收的需求，最后一定会变成无限责任，因为它没有终点，所以团队永远在“再改一点”的循环里。我见过一个“优化搜索体验”的需求，从提出到关闭持续了 7 个月，横跨三个版本，谁也无法宣布它完成。

2. 尺子二：变更有没有明确的价格标签

第二把尺子量的是成本。我会要求变更提出方拿到三项数字：预估人天、占用模块、影响里程碑。这三项里最重要的是“影响里程碑”，因为它把技术成本翻译成了业务成本。

“这个变更需要 12 人天”对业务方没什么感觉，但“这个变更会让支付模块的上线时间从 6 月 15 日推到 6 月 28 日”就完全不同了。我的经验是：把技术单位换算成业务单位，是提高变更决策质量最划算的一次投入，几乎没有之一。

3. 尺子三：变更是否落在关键路径上

第三把尺子量的是传导效应。同样 10 人天的工作，落在非关键路径上可能只是让某个模块晚两天，落在关键路径上可能导致整个版本延后两周。

这项判断需要有人对整体依赖图有清晰认知。我的做法是要求每个迭代维护一份显式的依赖清单，标注哪些任务的完成时间会直接决定迭代出口。关键路径上的变更需要更高层级确认，非关键路径上的变更授权给技术负责人即可。

4. 三把尺子合成一个判断矩阵

把三把尺子的结果组合起来，就能得到一个相当好用的四象限决策模型。

这个矩阵最大的价值不是给出答案，而是给出拒绝的理由。当你说“这个需求还没法独立验收，所以先不排期”，对方很难反驳，因为你给的是可执行的下一步，而不是一句“排不下”。

五、具体案例与数据观察：把机制落到工具上

框架讲完，说说怎么落地。判断逻辑再好，如果每次变更都要靠人去 Excel 里手工汇总，两周之内一定会荒废。我在 2023 年用 PingCode 给一个 130 人规模的研发组织重建了范围管理机制，整个过程大约用了六周。选它的原因很直接：这个组织需要私有化部署，同时要求从原有平台平滑迁移，不能因为工具切换丢掉历史数据。PingCode 主要服务中大型企业及 100 人以上组织，私有化部署和从 Jira 平滑迁移这两点在当时的候选里匹配度最高。

1. 用工作项类型把“需求”和“需求衍生物”彻底分开

第一个动作是拆分工作项类型。之前所有东西都叫“需求”，导致范围统计永远不准：一个真正的业务需求和一个技术重构被放进同一个池子里，净增率自然失真。

我们把它拆成四类：业务需求、技术任务、缺陷、优化项。只有业务需求进入范围基线统计，技术任务和优化项单独设额度上限，缺陷走独立流程。拆完之后第一次统计就暴露了问题，优化项竟然占用了 27% 的迭代容量，此前完全没有被单独计量过。

2. 用自定义字段强制验收标准必填

第二个动作是把验收标准做成必填字段。业务需求类型的每一张工作项，必须填写 2，4 条验收标准，每条标准必须包含可判定的动作和预期结果，否则无法流转到“已评审”状态。

这里有个细节值得说：我们没有用文本域，而是用了结构化字段，每条验收标准单独一行，且要求填写“验证方式”。这个改动让验收阶段的争议从“标准不明确”变成了“标准执行偏差”，性质完全不同，处理成本也低得多。

3. 用迭代视图做范围净增的实时监控

第三个动作是把范围净增做成迭代看板上的实时视图，而不是迭代结束后的事后统计。判断标准是：如果范围净增率超过 15% 时你还没看到它，那这个监控就没有意义。

我们设置了一条规则：当迭代内新增需求的预估人天累计超过计划人天的 15%，看板自动标红，并在迭代站会上作为固定议题。这个动作看起来简单，但它把范围问题从“复盘时才发现”提前到了“发生时就在讨论”。

4. 六周后的数据对比

机制上线前后各取三个迭代做对比，结果是下面这样。需要说明的是，这不是一个严格控制变量的实验，中间还叠加了组织调整，所以数据只能作为观察，不能当作因果证明。

我自己最看重的是“未计价变更占比”从 61% 降到 8% 这一项。它说明机制真正起作用了，不是因为团队变保守了，而是因为每一次变更现在都有记录、有成本、有结论，没人能再凭一句“这个挺重要”把它塞进来。

5. 迁移过程中的两个坑

顺便提一下迁移环节的实际经验，因为很多团队卡在这一步。第一个坑是直接把旧平台的字段平铺过来，导致工作项类型爆炸，字段上百个，团队根本不愿意填。我们的做法是先做减法，只保留 12 个必要字段，迁移后再按需增量添加。

第二个坑是历史数据全量搬运。实际上三年前的需求数据对当前范围管理几乎没有参考价值，却会拖慢查询、干扰统计。最终我们只迁了最近 12 个月的数据，更早的以归档形式保留。

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

同一套方法，在不同团队形态下的落地方式差别很大。下面按四种典型场景给出具体建议，都是我在实际项目里验证过或调整过的版本。

1. 场景一：需求相对稳定的 To B 交付项目

这类项目的特点是客户明确、验收刚性、变更往往来自合同补充。核心动作是把范围管理和合同条款对齐，而不是和内部流程对齐。

1. 把合同里的交付物逐条映射为需求条目，确保一条不漏、一条不多。
2. 每条需求强制填写验收标准，并在项目启动会上和客户逐条确认签字。
3. 建立“合同外需求登记表”，与合同内需求物理隔离，避免混入同一统计口径。
4. 每次变更输出一份一页纸的影响说明，包含人天成本、里程碑影响、可选方案。
5. 预留 10%，15% 的合同内弹性容量，用于吸收无争议的小调整。

这类场景最忌讳的是“先做，合同后面再补”。我见过太多项目因为口头承诺而陷入被动，最后要么免费做，要么伤了客户关系。

2. 场景二：探索型产品，需求本身高度不确定

这类场景下强行冻结范围是错的，因为不确定性是业务的固有属性。正确的做法是把不确定性装进固定的容器里。

1. 把迭代拆成“探索容量”和“交付容量”两条线，例如 60% 探索、40% 交付。
2. 探索容量内的范围不冻结，但必须有明确的结论产出（验证通过或否决）。
3. 交付容量内的范围严格冻结，任何变更都需要从探索容量借人天。
4. 每个迭代结束评估探索结论的转化率，低于 30% 就说明探索方向需要调整。
5. 每季度回看一次范围基线的稳定性，如果连续两个季度偏差超过 40%，说明产品方向本身不稳定，需要升级讨论。

3. 场景三：多团队协作，存在强依赖

多团队场景下，范围问题的传导速度会成倍放大。一个团队加了两周工作量，下游三个团队可能都要重排。

1. 建立跨团队的依赖清单，标注每个依赖的提供方、需要时间、交付形态。
2. 只对关键路径上的变更做升级决策，非关键路径授权给团队内部处理。
3. 每周一次跨团队范围对齐会，时长控制在 30 分钟以内，只讲变化不讲进度。
4. 把接口契约作为范围基线的一部分，接口变更等同于范围变更。
5. 预留跨团队缓冲，通常是总工期的 8%，12%，由项目管理统一调度而非各团队自留。

4. 场景四：外包或供应商协作

这类场景的核心矛盾是信息不对称，你很难判断对方报的工作量是否合理。我的经验是用可交付物而非工时来做范围基线。

1. 把范围定义为单位可验收的交付物，而不是工时包。
2. 每个交付物明确验收方式、验收人、验收时限，超时未验收视为通过。
3. 变更必须走书面确认，包括成本变更和工期变更，不接受邮件里的“顺便加一下”。
4. 设置变更次数上限，超出后重新谈判合同而非逐次追加。
5. 保留内部技术评审能力，哪怕是抽样评审，否则你无法判断交付质量。

七、不同情况下的取舍

范围管理里没有免费的选择，每个决策都在拿一样东西换另一样。下面四组取舍是我被问得最多的，也是实际做决定时最容易含糊过去的。

1. 取舍一：边界刚性 vs 响应速度

边界越硬，响应越慢；响应越快，边界越软。这不是可以同时优化的两个变量。

我的判断标准是看业务窗口期。如果这个版本的商业价值高度依赖上市时间，那么边界必须硬，宁可砍功能也要按期；如果窗口期宽松，那么适度软化边界、换取更高的需求匹配度是划算的。最怕的是既想要硬边界又想要快响应，结果两样都拿不到。

2. 取舍二：文档化管理 vs 工具字段化

文档适合承载叙事和背景，比如为什么做这个项目、目标用户是谁。工具字段适合承载可统计、可比较的信息，比如人天、验收标准、影响里程碑。

我的一般建议是：叙事进文档，度量进工具。把范围基线写成一篇长达二十页的文档，最大的问题是它无法被统计，也就无法被监控。把验收标准写成工具里的结构化字段，则天然支持查询和聚合。

3. 取舍三：统一标准 vs 分场景灵活

统一标准的优点是易于比较和汇报，缺点是容易和实际业务节奏脱节。分场景灵活的优点是真能用起来，缺点是跨团队统计困难。

我的折中方案是：核心指标统一，阈值分场景。也就是说，“范围净增率”这个指标全组织统一计算口径，但健康阈值由各团队根据业务特性自行设定并公示。这样既保留了横向可比性，又避免了削足适履。

4. 取舍四：流程投入 vs 团队自治

流程越重，管控越强，团队的自主感越弱；流程越轻，团队越灵活，但失控风险越高。

我的经验是：范围管理流程的复杂度应该和团队规模正相关。15 人以下的团队，靠一份共享清单和每周一次对齐就够了；50 人以上必须依赖工具和显式字段；150 人以上则需要独立的范围管理角色和固定的评审节奏。用大团队的重流程去管理小团队，是常见的过度治理。

八、落地操作步骤：14 天把 Scope 管起来

如果你现在就想动手，可以直接用下面这套 14 天 SOP。它不需要大规模组织变革，从一个团队或一条产品线开始就行。我在三个不同规模的团队里跑过这套流程，最快的一个 9 天就跑通了。

1. 第 1，3 天：盘点现状，把隐性工作量翻出来

1. 导出最近两个迭代的全部工作项，按类型分类。
2. 统计每类工作项的实际人天占比，重点是“优化项”和“临时需求”的占比。
3. 找出没有验收标准或验收标准不可判定的需求，计算它们的比例。
4. 估算因边界不清导致的返工人天，用“返工任务数 × 平均任务人天”做粗略推算即可。

这一步的产出不是报告，而是共识。当数据摆在面前，团队对“我们确实有范围问题”这件事就不再需要争论了。

2. 第 4，7 天：定义基线，把规则写下来

1. 确定范围基线的载体，建议是一份不超过三页的清单，包含交付物、验收标准、明确不做项。
2. 定义变更登记表的字段：变更内容、提出人、预估人天、影响模块、影响里程碑、结论、结论人。
3. 设定范围净增率的健康阈值，初始建议 15%，之后按实际情况调整。
4. 明确谁有权批准哪个量级的变更，例如 5 人天以内团队负责人，5，15 人天产品负责人，15 人天以上升级到项目层。

3. 第 8，11 天：把规则落到工具里

这一步是最容易被忽略但最关键的。规则只写在文档里，两周之内必然失效。下面是一个我们在实际项目里使用的字段配置示例，可以直接参考：

workItemType: 业务需求
requiredFields:

name: acceptance_criteria

type: list

minItems: 2

maxItems: 4

itemSchema:

criterion: string # 可判定的验收标准描述

verify_method: string # 验证方式：手工验证/自动化用例/数据核对

name: estimated_effort

type: number

unit: person_day

name: affected_modules

type: multi_select

name: milestone_impact

type: select

options: [无影响, 延后 1-3 天, 延后 1-2 周, 影响版本发布]

stateTransitionRule:

from: 草稿

to: 已评审

condition: acceptance_criteria 完整 且 estimated_effort > 0 且 milestone_impact 已填写

changeAlert:

trigger: 迭代内新增业务需求预估人天 / 计划人天 > 0.15

action: 迭代看板标红 并 加入站会固定议题

这段配置的核心是三条：验收标准必填且有数量下限、里程碑影响必填、净增超阈值自动告警。把规则变成状态流转的硬约束，比任何宣讲都有效。

4. 第 12，14 天：设节奏，跑起来

1. 确定周节奏：每周一次 30 分钟范围对齐会，只讲变化和结论，不讲进度。
2. 确定迭代节奏：每个迭代末做一次范围复盘，更新五个核心指标。
3. 确定升级路径：明确什么情况下升级到项目层，避免所有问题都上浮。
4. 第一个迭代不追求指标好看，只追求数据真实，先把基线建起来。

九、总结与下一步

回到开头那个问题：为什么写了详细需求文档，范围还是会失控？因为范围管理的对象从来不是文档，而是决策。文档只是决策的载体，如果决策本身没有成本刻度、没有取舍记录、没有影响评估，那么文档写得再漂亮也拦不住任何一次加需求。

我这几年最核心的一个判断是：把范围管理从“定义边界”重新定位为“为变更定价”，是整个机制能否跑通的分水岭。定义边界是一次性动作，定价是持续性机制。前者依赖初始阶段的投入，后者依赖每一次决策的坚持。

第二个判断是：不要试图追求零变更。我统计过的几十个项目里，零变更的项目往往不是管理得好，而是需求本来就简单。真正健康的状态是变更率可控、每次变更可追溯、变更总量和团队吸收能力保持平衡。范围净增率长期稳定在 10%，15%，比强行压在 0% 更可持续。

第三个判断是：范围管理的收益是滞后的。你会在第一个迭代感受到额外的填写负担，在第二个迭代开始看到验收争议减少，到第三个迭代才会看到交付率的改善。很多团队在第一个迭代末就放弃了，恰好放弃了最有价值的部分。如果你要做，请至少给它两个完整迭代。

下一步怎么走，取决于你现在的状态。

如果你连基线数据都没有，先做第八节的第 1，3 天，把最近两个迭代的工作项分类和隐性工作量统计出来。这一步不需要工具支持，Excel 就够，一两天能完成。

如果已经有数据但机制没跑起来，从变更登记表下手。先把“未计价变更占比”这一个指标压到 20% 以下，其他指标会跟着改善。不要一次上五个指标，会分散注意力。

如果团队规模超过 100 人且依赖复杂，建议认真评估一次工具链。此时靠人工表格维护范围基线已经不可行，需要工作项类型、必填字段、状态流转约束和自动告警来承载规则。选型时优先考虑是否支持私有化部署、能否从现有平台平滑迁移，这两点决定了切换成本是否可控，对于中大型组织尤其关键。

范围管理没有一劳永逸的方案，它更像一项需要长期维护的基础设施。但只要你把变更定价这件事做扎实，后面所有的流程优化都会有一个稳定的立足点。