制定产品功能规划，核心是把“要做哪些功能、先做哪些、本期做到哪”变成一份可评审、可执行的布局方案。本文按目标与约束、功能架构、共性差异判断、优先排序、范围取舍、角色分工、示例和完成检查八步展开，聚焦功能层面的布局与取舍；单需求价值评分和方案表达另行处理。涉及规划记录与评审协作时，可借助ONES的工作项与文档能力承载。
要点总览（TL;DR）
- 功能规划从一份规划任务书开始：写清目标、资源与时间约束、技术合规限制，并明确只做功能布局，单需求价值评分和方案表达另行处理。
- 功能架构按用户任务或业务对象分层，模块对应独立能力域，功能项保持统一颗粒度，架构图与功能清单配套产出、逐项对应。
- 功能组合按复用范围和支撑作用区分共性与差异：多场景复用、被其他功能依赖的做共性；服务特定客户群或场景的做差异，可用可选模块、插件或版本分层承载。
- 功能排序使用业务价值、依赖关系、实现成本、风险四个维度，在同一张表内统一分档；依赖关系先处理，再比较无冲突功能。
- 范围取舍划出本期、下期、暂缓三档，每条未入选功能记录理由、影响和复审时点；评审通过、责任到人、变更可控即达到可执行状态。
功能规划先定什么：目标、约束与规划边界
功能规划启动前，先把“为什么规划、受什么限制、规划到哪为止”写清楚。这一步的产出是一份规划任务书或一页纸范围说明，它决定后续架构拆分和排序是否有共同基准。缺少这份输入，讨论很容易滑向具体需求的细节争论。
规划目标要落到可判断的表述上。确认方式通常包括：与业务负责人对齐本期的业务背景，例如进入新客户群、补齐某条业务链路的断点、支撑一次版本发布；把背景转成规划要回答的问题，例如“本期功能布局能否覆盖目标客户的核心任务”。目标写成一句话即可，但要能用来判断后续取舍是否偏离。
约束条件需要逐项列出并注明来源：
- 资源约束：可投入的产品、设计、研发人力规模与时间窗口。
- 时间约束：版本节点、对外承诺日期、依赖的外部里程碑。
- 技术约束：现有架构的边界、必须复用的组件、已知的技术债。
- 合规约束：行业准入、数据与安全要求、合同约定的交付项。
规划边界同样要写明。功能规划回答的是功能布局与范围问题，单条需求的价值评分、优先级打分属于需求管理环节，产品方案表达与原型评审属于方案设计环节，两者不在本文规划动作内。把边界写进任务书，可以避免评审会上把功能布局讨论变成单个需求的辩论。
规划任务书建议包含：规划目标一句话、业务背景两到三条、约束清单、边界说明、参与角色与各自输入、评审时点。完成标志是任务书经产品负责人确认，参与角色已知晓自己的输入责任。
搭建功能架构：分层、分模块与功能清单
功能架构的作用是把产品能力拆成可讨论、可分配的结构。常用做法是按用户任务或业务对象分层：先划出用户要完成的主要任务链，再把每条任务链拆成支撑它的功能模块，最后在模块下落到具体功能项。按业务对象分层适合数据和管理对象清晰的产品，例如围绕客户、订单、合同组织能力。
模块划分要控制粒度。模块过粗，排序时无法区分轻重；模块过细，规划表会膨胀成需求列表。一个实用的判断是：模块应能对应一个相对独立的能力域，功能项应是用户可感知的一项操作或一组紧密关联的操作。功能项颗粒度在全表内保持一致，避免同一层里既有“消息通知”又有“重构权限体系”这类跨度极大的条目。
功能清单建议至少包含以下字段，便于后续排序和范围划定：
| 字段 | 填写要求 |
|---|---|
| 功能项 | 用户可感知的能力名称，动词加对象 |
| 所属模块 | 对应功能架构图中的模块 |
| 目标用户 | 主要使用角色或客户群 |
| 当前状态 | 已有、改造、新建、待评估 |
| 依赖功能 | 必须先具备的前置能力 |
| 备注 | 约束、风险或待确认事项 |
功能架构图与功能清单是配套产物：图负责表达层次和模块关系，清单负责逐项可查。完成标志是架构图上的每个模块都能在清单中找到对应功能项，清单中不存在无归属的功能项。在ONES中，功能项可以作为工作项按模块组织，架构说明与清单以文档形式与工作项关联，便于评审时对照查看。
功能组合与共性差异：哪些做共性、哪些做差异
功能组合要回答的是：哪些能力做成所有客户共用的基础，哪些能力按客户群或场景做成可选或特化。判断依据不是功能大小，而是复用范围和定位作用。
共性功能的识别标准主要有两条：一是多场景复用，同一能力在多个客户群、多条业务链路中被反复需要；二是基础支撑，其他功能依赖它才能成立，例如账号与权限、组织架构、消息通知、基础数据模型。共性功能通常应优先进入规划，因为缺失会阻塞一片功能。
差异化功能的判断依据包括：目标客户的特定作业方式、竞争定位上需要突出的能力、场景特化带来的流程差异。差异化功能不等于定制开发，可以先判断能否通过配置、可选模块或扩展点实现，再决定是否进入本期范围。
常见的组合方式有三种：基础加可选，即共性能力默认提供，差异能力作为可选模块；平台加插件，即核心平台稳定，场景能力以插件形式扩展；分层版本，即按客户群划分能力包。选择哪种方式取决于差异的稳定程度和维护成本，差异越分散、变化越频繁，越适合可选或插件方式。
产出是一张标注了共性与差异的功能组合表，在功能清单基础上增加“组合属性”和“判断依据”两列。完成标志是每个差异功能都能说明服务哪类客户或场景，每个共性功能能说明被哪些模块复用。
功能优先顺序：用统一口径排出规划次序
功能排序与单需求价值评分是两件事。单需求评分回答“这条需求值不值得做”，功能排序回答“在功能布局中，哪些能力应先具备、哪些可以后置”。前者面向需求池，后者面向架构落地顺序，口径不同，不能直接套用同一张评分表。
功能层面的排序建议使用四个维度，并对每个维度给出统一的分档标准：
- 业务价值：该功能支撑的目标客户群规模、对核心任务链的完整度贡献。
- 依赖关系：是否为其他功能的前置条件，被依赖越多越靠前。
- 实现成本：研发工作量、技术不确定性、对现有架构的改动幅度。
- 风险：合规风险、技术风险、交付延期风险。
操作方法可选分层打分或矩阵对比。分层打分是先按依赖关系排出硬性先后，再在无依赖冲突的功能之间按价值、成本、风险打分排序；矩阵对比是把功能两两放在价值与成本构成的四象限中，高价值低成本优先，高价值高成本需要拆分或分期。两种方法都要求在同一张表内使用同一套分档，避免不同模块各用各的标准。
依赖与前置条件要单独处理。存在前置关系的功能，排序时先满足前置，再比较后续功能；如果前置功能成本过高，应考虑是否调整本期范围，而不是把后置功能强行提前。产出是功能优先级排序表，包含功能项、所属模块、四个维度的分档、依赖说明和排序结果。完成标志是任意两项功能的先后都能用表中口径解释。
规划范围取舍：本期做什么、不做什么
范围取舍是把排序结果与约束条件对齐，划出本期、下期、暂缓三档。本期范围应满足：覆盖规划目标中的核心任务链，依赖关系闭合，资源与时间可承载。下期范围是已判断有价值但受约束限制的功能；暂缓范围是当前依据不足或与目标偏离的功能。
取舍记录要写清三件事：为什么选或为什么不选、影响是什么、什么时候复审。理由引用排序表中的维度分档，影响说明对目标客户或依赖功能造成的缺口，复审时点绑定版本节点或触发条件，例如客户签约、技术方案变化。
变更控制需要提前约定触发条件与审批方式。常见触发条件包括：关键客户需求变化、技术方案评估结果与预期不符、资源发生增减。范围调整应回到取舍记录中更新，由产品负责人提出、相关角色确认、评审角色审批，避免范围在口头沟通中悄然扩大。
产出是范围取舍记录与版本规划表。版本规划表按本期、下期列出功能项与责任模块，取舍记录逐条对应理由与复审时点。完成标志是本期范围内不存在未决的依赖缺口，每条未入选功能都有记录和复审安排。
角色分工与交付物：谁负责哪一步
功能规划需要多角色共同输入，但牵头和汇总责任要明确到人。下表给出常见分工，团队规模较小时可由一人兼多个角色，职责本身不变。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 产品负责人 | 牵头规划、组织评审、汇总输出、维护取舍记录 | 规划任务书、功能清单、优先级排序表、范围取舍记录 |
| 架构/技术负责人 | 评估架构可行性与实现成本，确认模块划分与技术约束 | 功能架构图、技术约束清单、成本评估意见 |
| 业务/销售代表 | 提供目标客户场景、客户需求与竞争信息 | 场景说明、客户需求输入、共性差异判断依据 |
| 研发负责人 | 确认实现依赖与排期可行性 | 依赖说明、排期确认意见 |
| 评审角色 | 按评审时点对规划范围与优先级做决策确认 | 评审结论与决策记录 |
评审时点建议设在两个位置：功能架构与清单完成后评审一次，确认结构和颗粒度；范围取舍完成后评审一次，确认本期范围与资源匹配。评审结论要落到记录中，明确通过、有条件通过或退回修改，并指定后续动作的责任人。
示例：一次功能规划从输入到评审的完整过程
以下为演示情景，用于说明各步骤如何衔接，不代表真实项目数据。
背景与目标：某协作类产品计划在下一版本服务一批中型客户，目标是补齐任务协作链路中的计划与跟踪能力。约束为两名产品、六名研发、一个季度窗口，需满足客户合同中的数据留存要求。规划边界限定为功能布局，具体需求评分不在本次范围。
架构拆分与清单片段：按用户任务分为“计划”“执行”“跟踪”三个模块。“计划”下含任务分解、里程碑设置；“执行”下含任务状态流转、评论与附件；“跟踪”下含进度视图、逾期提醒。清单中标注当前状态：任务分解为改造，里程碑设置为新建，进度视图为已有需增强。
共性与差异判断：任务状态流转、评论与附件被多个模块复用，标为共性；里程碑设置主要服务有阶段交付要求的客户，标为差异，采用可选模块方式；数据留存相关能力受合同约束，标为共性并列入本期。
排序与取舍结果：按依赖关系，任务分解先于进度视图；按价值与成本对比，里程碑设置价值高但成本中等，列入本期；逾期提醒依赖通知能力，成本较低，列入本期；高级报表价值高但成本高，列入下期。暂缓项为与目标客户场景关联较弱的自定义字段扩展。
评审结论与后续动作：评审确认本期范围，要求研发负责人在两周内确认里程碑设置的排期，产品负责人更新取舍记录并设定下期复审时点为版本发布后。评审记录与功能清单、排序表一并归档，作为后续变更的基准。
完成检查：功能规划是否可交付
规划进入评审前，用以下清单逐项核对。每项都应有明确答案，存在未决项时标注责任人和解决时点。
- 功能架构图覆盖规划目标涉及的全部任务链，模块划分粒度一致。
- 功能清单字段完整，每个功能项有归属模块、目标用户和当前状态。
- 共性功能能说明复用范围，差异功能能说明目标客户或场景依据。
- 优先级排序表使用统一分档口径，依赖关系已标注并处理。
- 本期、下期、暂缓三档划分清楚，每条未入选功能有理由和复审时点。
- 范围变更的触发条件与审批方式已写入记录。
- 各角色交付物齐全，评审结论与后续动作责任到人。
全部核对通过，且评审结论已记录，功能规划即达到可执行状态。后续按版本节点复审取舍记录，范围调整回到同一份记录中更新，保持规划与实际执行一致。
常见问题
功能规划和需求优先级排序是什么关系，会不会重复做两遍？
两者回答的问题不同。功能规划回答的是功能布局：哪些能力先具备、哪些后置、本期做到哪一档；需求优先级排序回答的是需求池里哪条需求先做。功能规划的输出是功能架构、功能清单、功能优先级排序表和范围取舍记录，需求排序发生在功能项确定之后，针对具体需求逐条评估。
实际操作中，功能规划先给出功能层面的次序和范围，需求进入本期功能项后再做单条评分。如果团队把两者混在一张表里，常见结果是排序口径打架：功能层面看重依赖和布局完整度，需求层面看重单条价值，混排会让前置功能被单条高价值需求挤掉。建议在规划任务书中写明边界，两套表分开维护、相互引用。
共性和差异功能判断出现分歧时，怎么收敛？
分歧通常来自判断依据不统一。可以回到两条标准逐项核对：该功能是否在多个客户群或多条业务链路中被反复需要；是否有其他功能依赖它才能成立。两条都成立，倾向共性；只服务特定客户群或特定作业方式，倾向差异。
仍有争议时，把问题转成成本问题：做成共性需要多少维护投入，做成可选或插件需要多少配置和扩展成本。差异越分散、变化越频繁，越适合可选或插件方式。分歧无法当场收敛的，标注为待评估并指定责任人和确认时点，不阻塞其他功能项进入排序。
本期范围已经评审通过，中途客户提出关键需求，怎么处理？
先判断是否触发预先约定的变更条件，例如关键客户签约、合同交付项变化、技术方案评估结果与预期不符。触发后回到范围取舍记录中更新，由产品负责人提出调整方案，说明新增功能挤占哪些原定功能、对依赖链和目标客户的影响，再由相关角色确认、评审角色审批。
没有触发条件的临时需求，进入下期或暂缓档并记录理由，不直接插入本期。范围调整后同步更新版本规划表和功能优先级排序表，保持三份记录一致，避免口头变更造成执行偏差。
团队规模较小，角色分工可以简化到什么程度？
角色可以合并，职责不能消失。小团队中产品负责人常同时承担业务输入汇总和规划牵头，架构评估可由技术负责人兼做，评审角色可由团队负责人担任。需要保留的是三项动作：架构可行性与成本有人评估、客户场景有人提供输入、范围与优先级有人做最终确认。
简化时容易漏掉的是取舍记录和复审时点。建议至少保留一份范围取舍记录，写明每条未入选功能的理由和复审安排，并在版本节点回看。这样即使人员变动，规划依据仍然可查。
功能清单做到多细才够用，会不会越做越像需求列表？
判断标准是颗粒度一致和可排序。功能项应是用户可感知的一项操作或一组紧密关联的操作，同一层里不出现跨度极大的条目。如果清单里开始出现界面细节、字段级改动或单个交互优化，说明已经下沉到需求层，应回到功能项层面归并。
清单规模以能支撑排序和范围划定为限。模块数量多、功能项过细时，可以先按模块做粗排，再对本期候选模块展开功能项。清单字段保持功能项、所属模块、目标用户、当前状态、依赖功能、备注六项即可，字段过多会增加维护负担。
