需求排期迭代规划教程：管理层效率提升，避坑指南

需求排期最容易制造一种“看起来很忙”的假象：需求池排得满满当当，迭代计划按时发布，管理层却仍然说不清为什么重要项目延期、团队为什么总在救火、下个季度到底能承诺多少。问题往往不在排期表不够精细，而在团队把需求优先级、交付能力和管理承诺混成了一件事。本文给出一套可落地的需求排期迭代规划方法，并用明确标注的情景模拟案例说明：怎样减少计划反复、识别隐藏容量、让管理层的决策建立在证据而不是催促上。

一、先讲核心结论：排期不是把需求塞进日历

1. 需求排期的目标是管理承诺，不是填满迭代

我做需求规划时，首先会把“排期”拆成三个问题：哪些需求值得做，团队在当前约束下能做多少，以及管理层愿意为哪些取舍承担责任。若只回答第一个问题，需求池会越来越长；只回答第二个问题，计划会变成工程团队的估算表；三者都没有对齐，所谓迭代承诺就只是日期和愿望的组合。

一份有管理价值的计划，至少要能解释四件事：目标是什么、为什么现在做、预计投入多少、如果出现变化要牺牲什么。它不必预测每一项工作的精确完成日期，但必须明确哪些是承诺、哪些是候选、哪些是假设。一旦管理层把“候选”当成“承诺”，计划就会在执行中不断被追加。

我更看重计划是否可调整，而不是计划是否看起来完整。稳定的规划不是从不改动，而是变化有入口、有影响评估、有决策人。一个迭代临时加入需求并非必然错误；没有记录被挤出的工作、风险和责任，才是治理失效。

2. 管理层效率提升，首先来自减少决策往返

管理层的时间通常不是被一张排期表占用，而是被反复确认同一件事消耗：需求为什么排在前面、哪个团队负责、延期会影响谁、临时插单由谁批准。若每次会议都从头解释背景，说明规划信息没有形成可复用的决策材料。

我建议把管理层需要参与的事项限制在三类：目标与优先级冲突、跨团队资源冲突、超出授权范围的范围变更。需求描述、依赖确认、开发拆分等日常问题，应由明确的责任人在线处理。管理层不需要逐项审阅所有需求，但需要看见关键取舍和风险。

3. 计划要分层，不能用一个日期回答所有问题

需求规划至少分为三个时间尺度：季度或月度目标层、未来数个迭代的滚动计划层、当前迭代的执行承诺层。越远的计划越应表达方向和容量区间，越近的计划才适合落实到具体工作项与负责人。把三层都写成“某日必须完成”，只会制造过度确定性的错觉。

这三层必须使用不同的语言。目标层说“要改善什么”，滚动层说“优先考虑什么”，执行层才说“本周期承诺什么”。管理层据此能区分方向变化、候选调整和正式承诺变化，避免把每次讨论都变成延期问责。

二、背景与真实场景：为什么排期越细，反而越容易失控

1. 需求从不同入口进入，优先级天然会打架

在中大型组织里，需求可能来自客户反馈、销售承诺、运营数据、合规要求、技术改造和管理层战略。每个入口都有自己的评价标准：销售关心签约与续费，运营关心流程效率，研发关心系统风险，管理层关心战略窗口。若这些输入没有统一的决策框架，排期会议就会变成声音大小的竞争。

最常见的局面是：业务方说“客户很急”，产品方说“这是核心体验”，技术团队说“旧系统已经撑不住”，管理者问“能不能都做”。每一方说的可能都是真的，但事实成立不代表当前容量能够同时容纳。规划的职责不是替所有人证明自己正确，而是让相互冲突的价值、成本和风险可比较。

2. 任务切得越细，不代表估算越准确

我见过一种排期表，工作项细到半天，表格看起来非常专业，实际却把未知因素全部藏进了单点估算。需求验收口径没定、外部接口没有确认、测试环境不稳定，团队仍给出精确工时。结果不是估算更准，而是误差被推迟到执行中才暴露。

拆分的价值是暴露依赖和验收边界，不是制造精确感。若一项工作仍包含多个未知，先拆出验证任务、技术预研或业务确认节点，通常比把开发工时写成“3.5天”更有用。对不确定性高的需求，计划应明确“何时获得证据”，而不是假装已经知道最终工期。

3. 计划偏差常常是系统性问题，不是个人不努力

当团队连续多个迭代完不成计划，不要急着把原因归结为估算能力差或执行力不足。先检查是否长期把支持工作、线上问题、代码审查、跨团队沟通和休假从容量中剔除；再看需求是否频繁变更，依赖团队是否按时交付，验收是否在迭代末才开始。

有一个简单的辨别方法：如果延期总发生在相似环节，例如需求澄清、外部依赖或测试排队，那么优先修复流程约束；如果偏差集中在少数高不确定需求，则应改进拆分和验证；如果计划外工作持续挤占迭代，则要建立支持容量和插单机制。不同根因需要不同动作，不能一律要求“再努力一点”。

4. 对百人以上组织，协调成本也是排期输入

团队规模变大后，排期不只是产品与研发之间的事，还涉及架构、安全、数据、采购、发布、客户成功等角色。某个功能开发只占几个人天，却可能需要多团队评审、环境准备和灰度验证。若计划只计算编码时间，就会低估端到端交付周期。

对中大型企业和 100 人以上组织，我会特别关注“等待时间”和“协调次数”。如果需求在多个团队间移交，交付日历可能远长于实际工作量；如果每次跨团队评审都没有明确输入和决策人，会议数量增加也不会自然提高效率。此时，统一需求状态、依赖关系和变更记录，比单纯催促负责人更有效。企业可以用 PingCode 等项目管理平台承载需求、迭代与跨团队协作，但工具本身不能替代优先级规则和决策授权。

三、常见误区：表格越漂亮，不等于计划越可靠

1. 误区一：需求价值就是“谁喊得急”

紧急程度是时间约束，不等于业务价值。客户承诺、监管截止日期、线上事故可以构成硬约束；某位负责人希望“本月看到效果”，则未必是硬约束。若团队把所有需求都标成高优先级，优先级就失去区分作用。

我会要求提出方说明：错过当前窗口会造成什么可验证的损失？影响对象是谁？是否存在临时替代方案？截止日期来自外部事实还是内部期望？这些问题不是为了拖延，而是把“急”转成可以审议的约束。真实的硬截止要在计划中标识，普通偏好则进入价值排序。

2. 误区二：容量等于团队人数乘工作日

十个人工作两周不等于二十人周的净交付容量。有人休假，有人轮值，有人承担技术支持，有人需要配合招聘、面试或重大事故复盘。即使全员在岗，也有评审、同步、测试和发布等必要工作。直接用名义工作时间排满任务，实际上是在提前消费缓冲。

更可靠的做法是从历史完成量反推容量，再根据当前人员变化和工作类型进行修正。历史数据也不是承诺：若过去的迭代经常被临时插单打断，完成量反映的是混乱状态，而不是理想状态。因此还要同时看范围变更、返工、未完成工作和支持工时。

3. 误区三：所有需求都能按同一把尺子估算

成熟功能、小幅体验优化、新技术探索和合规改造，具有不同的不确定性。把它们都换算成故事点或人天后直接排序，容易掩盖风险。一个估算为五人天的成熟功能，和一个估算为五人天但接口方案未定的需求，计划风险并不相同。

我倾向于把“工作量”和“置信度”分开记录。工作量表示投入规模，置信度表示当前估算有多少证据支撑。低置信度事项要么先做验证，要么预留更大缓冲，要么只进入远期候选，不应与已经澄清的需求获得同等承诺等级。

4. 误区四：迭代开始后不允许变化才叫纪律

真实业务会出现新信息，严格禁止变化有时会让团队错过事故响应或法规要求。真正需要控制的是变化成本：新增需求有没有说明影响，是否由有权限的人批准，是否明确被推迟的原任务，是否更新相关团队的预期。

没有记录的变更，最终会变成团队“怎么没按计划交付”；有记录的变更，才能区分计划失效与决策调整。迭代中允许变更，但不允许假装变更没有代价。

5. 误区五：完成率越高，团队规划越好

完成率很高可能来自计划保守、需求被拆得过小，也可能来自团队在周期末加班赶工。完成率很低也可能是目标变更、外部依赖失效，而不是团队能力不足。单独看一个比率，容易诱导团队通过降低承诺或隐藏工作来“改善数字”。

至少要把完成率与计划变更率、未完成原因、缺陷返工、周期外支持工作一起看。管理层若只奖励高完成率，团队会倾向于少承诺；若只处罚延期，团队会隐藏风险。指标设计要让诚实暴露问题比粉饰数据更安全。

四、专业判断逻辑：用一套可解释的规则决定先做什么

1. 先设准入条件，再做价值排序

不是所有想法都应该直接进入排期评审。先做准入检查，可以把信息不完整的请求挡在承诺流程之外。最低限度需要知道问题对象、期望结果、验收方式、提出依据和关键依赖。缺少其中一项，不一定要拒绝，但应标记为待澄清或验证，而不是假装它已经可以交付。

• 问题对象：受影响的是哪类用户、哪个内部流程或哪项系统能力。
• 目标结果：希望改变什么可观察行为或业务指标。
• 验收条件：什么情况算完成，谁有权确认。
• 依据来源：客户反馈、业务数据、合规文件、事故记录或战略假设。
• 依赖约束：是否需要其他团队、供应方、数据或环境配合。

准入的目的不是增加审批，而是减少团队拿到需求后才发现“业务目标没定、验收人没找、接口方不知道”的反复。若需求来自重大事故或硬性法规，可以允许快速通道，但仍应补齐责任人和影响评估。

2. 用价值、紧迫度、风险和成本共同判断

我不建议把复杂决策压缩成一个看似客观的总分，再由小数点决定资源分配。评分的作用是暴露分歧，不是消除判断。团队可以使用简单的相对评分，将价值、紧迫度、风险降低和投入规模分别评为低、中、高，然后讨论分歧最大的项目。

排序时，我会先处理硬约束，再在同一约束组内比较价值与成本，最后检查组合是否失衡。例如，一个迭代若全是新功能，却没有安排必要的稳定性工作，短期看起来产出很多，后续风险可能集中爆发。优先级排序不是需求名单的排序，更是资源组合的设计。

3. 把“硬约束”与“可协商目标”分开

硬约束包括法规生效日、已确认的客户交付条款、重大安全修复窗口等，通常不能随意移动。可协商目标则可能是营销活动希望配合的日期、业务方期望的体验优化时间。两者都可以重要，但不能用同一语气表达。

对硬约束，我会进一步核实最小可行范围：必须交付的功能是什么，是否可分阶段，是否有人工替代流程。对可协商目标，则评估延期成本、机会成本和替代方案。这样做常能把“要么全部按期，要么失败”的二选一，改成“核心合规部分按期，体验增强部分进入下一轮”的可执行方案。

4. 使用置信区间，而不是给未知事项一个精确日期

对未来数月的计划，给出范围往往比单一日期更诚实。例如，成熟需求可以预估两到三周，依赖未确认的工作则应给出更宽区间，并列出收窄区间所需的证据。管理层需要知道不确定性来自哪里，才能决定是投入验证、接受风险还是改变目标。

对当前迭代，团队可以做较明确的工作承诺；对后续迭代，使用容量区间和候选顺序；对更远期，保留方向和关键假设。随着信息增加，再逐步提高确定性。计划的精度应该随证据增加，而不是随汇报日期临近。

5. 为计划变更建立显式决策路径

迭代中要有明确的变更规则。一般缺陷修复和小范围调整可以由产品负责人或迭代负责人在授权范围内处理；影响跨团队承诺、发布日期或关键目标的变更，则需要更高层级确认。决策路径应提前公布，而不是出事后再临时找人签字。

• 提出变更时，说明触发原因、影响用户、截止约束和不处理的后果。
• 执行团队估算新增工作，并识别需要移出的工作。
• 产品与技术负责人核对依赖、风险和验收条件。
• 按授权级别批准或拒绝，并记录决策人和理由。
• 同步更新计划、风险清单和相关团队的预期。

五、具体案例与数据观察：把“多做一点”改成可讨论的取舍

1. 案例背景：一个多团队产品组的排期失真

以下是匿名化情景模拟，用于展示分析方法，不代表真实客户案例或行业统计。假设一个由产品、研发、测试和运营协作的产品组，覆盖约 120 人规模的组织。团队每两周规划一次迭代，需求来源包括客户交付、运营优化和平台稳定性改造。

连续四个周期，计划完成比例分别为 68%、73%、61% 和 70%。管理层最初提出“估算要更准，执行要更快”。复盘后发现，平均每个周期有约 18% 的原计划范围在开始后变更；支持与缺陷处理平均占团队净容量约 14%；跨团队依赖平均有 2 项未在计划评审前确认。

这些数据是案例设定，不是通用基准。它们的价值在于展示诊断顺序：先确认容量是否被低估，再确认变化是否有治理，接着判断依赖是否提前暴露。若直接惩罚低完成比例，团队可能会降低计划量，却不会解决插单和等待问题。

2. 复盘后如何重排：三类工作分别处理

团队没有要求所有人加班，而是把需求分为硬约束工作、常规价值工作和验证型工作。硬约束工作先核实最小交付范围；常规价值工作按价值与投入排序；验证型工作拆成短周期实验，避免未经验证的完整方案占据大量容量。

同时，团队把支持工作从“计划外杂事”改为容量预算。历史记录显示，每两周支持与缺陷处理占用波动较大，因此在计划时先预留一段容量；若实际支持低于预留，团队再从候选列表中补入工作，而不是一开始就把全部时间排满。

3. 变化后的观察：不仅看完成率，也看计划稳定性

在这组情景模拟中，团队用六个周期观察调整效果。完成比例从约 68% 的水平提升到约 82%，迭代中途的范围变更从约 18% 降到约 9%，支持工作仍约占净容量的 13% 至 15%。这组数字不是任何真实组织的成果承诺，只说明把支持容量和变更决策显式化后，团队更容易区分“计划不现实”和“执行不稳定”。

更重要的变化不是完成率本身，而是管理者能在规划会上看到三种不同问题：哪些需求因价值排序落选，哪些需求因不确定性需要先验证，哪些工作因为外部依赖尚未具备条件。决策不再只剩“能不能加”，而可以讨论“加了以后换掉什么”。

复盘时，我会同时关注：范围变更率、计划外工作占比、依赖按期满足比例、返工率、未完成原因构成和交付后目标指标。若完成比例上升但返工率也明显上升，可能只是以质量换速度；若计划稳定但目标指标没有变化，说明需求选得不对或价值假设未成立。

4. 怎样理解这些数字，避免把模拟当成承诺

模拟数据不能证明某个流程在所有团队中都能得到相同结果。团队技术栈、产品成熟度、交付方式、客户承诺和支持压力都不同。正确的用法是把这些指标作为试点观察框架：在调整前记录基线，连续跟踪数个迭代，再判断变化是否与机制调整相关。

还要防止把指标变成团队的奖惩工具。完成比例低时，应先查计划输入和变化原因；完成比例高时，应检查是否有未登记工作、质量下降或需求被拆小。如果指标一旦影响绩效，团队可能会优化数字而不是优化交付。

六、落地教程：从需求池到迭代承诺的七个步骤

1. 建立统一需求入口，保留来源而不保留特权

把不同来源的需求收敛到统一入口，但保留来源、提出人、目标用户和业务背景。统一入口不是让所有事情走同一套慢流程，而是让需求可以被比较、追踪和复盘。紧急事故可以走快速通道，但事后也要补录原因和影响。

2. 先澄清问题，再讨论解决方案

提出方往往直接要求一个功能，但排期讨论需要先知道问题是什么。例如，“增加一个筛选项”只是方案描述；真正的问题可能是运营人员每周花数小时定位异常记录。只要问题和结果讲清楚，团队就有机会比较多种解决办法，而不是把最先提出的方案自动当成唯一答案。

3. 写出验收条件和成功信号

验收条件描述工作完成的边界，成功信号描述上线后是否产生价值，两者不能混为一谈。功能可以按规格完成，却未必改善目标指标。对于探索性需求，成功信号也可以是验证了某个假设或排除了某种方案，但要事先说清证据标准。

4. 标记依赖、风险和置信度

在计划会上，不要只问“估几天”，还要问“估算依赖哪些假设”“哪些团队必须在何时提供输入”“不确定性怎样降低”。如果依赖未确认，可以将工作拆成确认任务；如果技术路径尚未验证，可以先安排短时预研。这样做可能让短期计划看起来少了一项功能，却能减少后续整项推翻。

5. 按净容量安排承诺，候选工作另列

先扣除休假、轮值、固定协作和预计支持工作，再看团队可用于新需求的净容量。当前迭代的正式承诺不应与候选清单混在一起。候选项可以有优先顺序，但必须标明“容量允许时进入”，以免相关方把它误读成保证交付。

6. 计划评审只讨论需要决策的差异

如果会议上每个需求都从头介绍，讨论会很快耗尽。提前发送需求摘要、估算区间、依赖和风险，会议集中处理冲突：价值判断不一致、容量超限、目标冲突、跨团队依赖或风险接受。管理层参与的是决策，不是逐条录入需求信息。

7. 迭代结束后对比计划与事实

复盘不要只记“完成”或“未完成”。逐项记录变化原因、阻塞时间、返工和验收等待，再把发现用于下一个周期的容量与风险调整。复盘的目的不是证明谁错了，而是让下一轮计划少依赖猜测。

1. 汇总计划内完成、未完成和中途新增的工作。
2. 将未完成原因归类为估算偏差、需求变更、依赖等待、质量返工或突发支持。
3. 比较原定容量和实际容量，识别长期被忽略的工作。
4. 更新依赖清单、估算区间和风险缓冲依据。
5. 选择一项最影响交付的机制问题，在下一周期验证改进。

七、不同情况下的行动建议与取舍

1. 小团队：优先做轻量规则，别先搭复杂治理

小团队通常不需要多层委员会或复杂评分模型。用一个共享需求池、一个明确的优先级负责人、一套准入条件和简单的容量记录就可以起步。每次规划只需确认目标、净容量、依赖和候选顺序，避免为了“规范”而花大量时间维护流程。

小团队最值得先解决的通常是插单和需求澄清。如果同一位负责人既提需求又决定优先级，建议至少让工程负责人参与容量判断，并把被替换的任务写下来。流程可以轻，但责任边界不能模糊。

2. 中大型组织：先治理跨团队依赖，再追求更细估算

中大型组织的主要风险往往不是某个团队不会估算，而是多个团队各自做了局部计划，却没有共同的依赖时间表。一个服务团队延迟两天，可能让产品、数据、测试和发布同时等待。此类组织应建立跨团队依赖负责人、共享里程碑和升级路径。

如果使用项目管理平台，应优先确保需求状态、责任人、依赖、版本和变更记录一致。工具选型时，我会检查团队是否能按自身流程配置字段与视图、管理层能否看到组合层面的风险、历史数据能否支持复盘，以及权限与审计是否符合企业要求。功能数量多不是唯一标准，数据能否形成可执行决策更重要。

3. 需求高度不确定：先买证据，不要一次押注完整交付

若目标用户、技术路线或业务收益尚未验证，最合理的下一步可能是用户访谈、原型测试、数据分析或技术验证，而不是直接排入完整开发。验证任务应有时间盒、决策问题和停止条件，否则预研容易无限延长。

这类选择的代价是短期功能产出变少，但收益是降低大规模返工的概率。管理层应明确接受“本周期产出证据而非完整功能”，并约定验证结果将如何影响后续投入。

4. 法规、事故或客户硬期限：先定最小范围和风险升级线

硬期限下，团队不应只靠加人或加班应对。先划出不可缺少的交付范围，确认验收人、外部审核和上线流程，再识别哪些增强项可以后移。若关键依赖没有按期就绪，要有明确的升级时间点和替代方案，而不是等到发布日期临近才宣布风险。

这类项目可以减少常规评审环节，但不能省略影响记录、责任人和风险沟通。越是紧急，越需要让决策过程可见，否则临时方案可能在上线后变成长期技术负担。

5. 稳定性工作总被新功能挤掉：把风险变成可见目标

技术债务和稳定性工作常因收益不够直观而被挤出计划。改善办法不是把所有技术工作都标为紧急，而是说明风险对象、发生概率、影响范围和不处理的成本。例如维护窗口将关闭、故障恢复时间持续增加、关键依赖停止支持，都比笼统的“需要重构”更有决策价值。

当业务增长需要稳定性投入时，可以设置明确的容量边界或阶段性目标，并每个周期回顾风险变化。这样做会减少短期功能数量，但能避免维护成本持续增长，最终使未来交付速度更可预测。

6. 管理层要求提高承诺量：先核对约束，不先压缩估算

如果管理层希望同一周期多做 30%，先逐项检查可选择的杠杆：缩小范围、减少并行工作、清除依赖、延后低价值事项、增加匹配技能的人员，或接受更高风险。直接要求团队把每项估算压低 30%，不会消除工作，只会把风险推迟到执行和质量阶段。

增加人员也不是即时扩容按钮。新成员需要熟悉系统、流程和业务背景，已有成员还要承担培训与评审。若交付窗口很近，应优先考虑缩小范围和降低并行度，而非假设新加入的人可以立刻带来等比例产能。

八、管理层看什么：用少量指标形成可行动的视图

1. 看目标与结果，不只看工作项状态

工作项状态回答“做到了哪里”，目标指标回答“做了是否有用”。管理层视图应同时呈现关键目标、当前趋势、计划范围、风险和需要决策的事项。若只有一列绿色进度条，领导看不到目标是否偏离，也不知道该采取什么行动。

2. 看变化而不是单点数字

完成比例、计划变更率、交付周期和返工率最好用一段时间的趋势观察。单个迭代容易受到假期、事故或大型发布影响。趋势能帮助判断问题是偶发还是结构性，也能识别某项改进是否持续有效。

3. 看风险是否有人负责、有时间点、有处理方案

风险清单若只有“存在风险”，对决策帮助有限。每条高优先级风险都应有负责人、触发条件、最晚决策时间和应对方案。管理层不需要看所有细枝末节，但要知道哪些风险已超出团队授权范围。

4. 让指标服务诊断，而非排名团队

不同团队的产品成熟度、支持负担和工作类型并不一致，简单横向排名很容易误导。一个维护型团队可能完成需求数量较少，却避免了重大故障；一个新产品团队的计划偏差较大，可能是验证探索的正常结果。比较之前先确认口径、团队任务和质量要求一致。

九、最终取舍：规划不是消灭变化，而是让变化有代价、有依据

1. 计划细度与灵活性之间必须取舍

越远期的计划越需要弹性，越近期的承诺越需要清晰。管理层若要求远期日期精确到天，就要接受频繁重排；若希望计划稳定，就需要把远期表达为范围、目标和关键依赖。没有一种做法能同时获得远期精准和完全不变。

2. 交付速度与质量之间不能靠隐瞒风险平衡

缩小范围、清除依赖、改进测试和减少无效并行，往往比单纯压缩开发时间更可持续。若必须接受质量风险，应明确风险负责人、影响范围和回退方案。把风险藏起来并不会使项目更快，只会让风险在代价最高的时候暴露。

3. 统一规则与团队自主之间要设置边界

组织需要统一的是需求信息口径、承诺定义、变更记录和关键指标，不必强求所有团队使用完全相同的估算方法。不同团队可以保留适合自身工作的执行方式，只要能够说明容量、风险、依赖和交付结果，并遵守共同的跨团队承诺规则。

4. 工具效率与流程负担之间要保持比例

项目管理工具能减少信息散落、重复汇报和状态追问，但字段越多、审批越长，不代表治理越成熟。先确定哪些信息会改变决策，再配置相应流程。若每个需求都要填写大量不参与讨论的字段，团队会把工具当作额外文书工作，数据也会逐渐失真。

5. 下一步从一个迭代开始验证

如果当前排期主要靠经验、临时沟通和个人记忆，不必一次性重建全部流程。选择一个产品组或一个迭代周期，记录净容量、支持工作、范围变更、依赖等待和未完成原因。用这些事实建立基线，再调整一项机制，观察变化后是否真正改善。

1. 选定一个试点团队，明确本次规划的目标和范围。
2. 收集最近 6 至 10 个迭代的可用记录；若数据不完整，先标明缺口，不补造数字。
3. 统一“承诺、候选、待澄清”的定义，避免不同角色使用不同口径。
4. 为本次迭代显式预留支持和风险容量，并列出候选工作。
5. 在复盘中核对范围变更、阻塞、返工和业务结果，决定下一轮只改哪一项。

需求排期真正提升管理效率的地方，不是让每个团队更快填完计划，而是让组织更早看见冲突、更清楚地承担取舍。下一步可以从最近一个延期迭代开始，问三个问题：计划外工作占了多少容量？哪些依赖在承诺前没有确认？每一次新增需求替换了什么？把答案记录下来，下一轮排期就能从“谁更急”转向“什么最值得、什么能交付、什么风险由谁接受”。