产品功能边界说明写起来最容易出现两种偏差：要么只列了一串功能清单，看不出取舍依据；要么通篇是原则口号，落到具体需求时仍然无法判断该不该做。本文给出一份填写完整的边界说明示例，按“做、暂不做、明确不做”三档组织功能范围，每条附判断依据与复核条件，并逐项解释写法。示例中的产品与数据均为演示情景，用于说明格式与判断逻辑，不代表真实客户案例。
要点总览（TL;DR）
- 产品功能边界说明按“做、暂不做、明确不做”三档组织，每条附判断依据与复核条件，才能在评审会上被引用。
- 定位句是整份文档的约束源头，写明服务对象、核心场景和规模或行业限定，后续条目从定位句推导。
- “做”与“暂不做”按需求频次和场景覆盖区分，承认暂不做的功能有价值只是时机未到；“明确不做”要写明承接方，把讨论从“要不要做”转为“交给谁做”。
- 复核条件写成可观察的触发信号，并配上负责跟踪的人，随版本规划周期至少每季度复核一次。
- 示例中的产品与数据均为演示情景，功能条目必须按自身产品重写，本文不涉及单需求价值评分与原型评审。
这份示例要解决什么问题
这份示例的目标很具体：产出一份可以直接套用的功能边界说明。读者拿到它，替换掉产品名称、目标用户和功能条目，就能形成自己产品的第一版边界文档，并在需求评审时作为判断依据使用。
适用读者包括三类角色。产品负责人用它对上对下统一范围口径；产品经理用它判断一个新需求落在哪一档；研发与业务对接人用它理解“为什么这个功能现在不做”，减少反复沟通。三类角色看的是同一份文档，因此文档的措辞要经得起非产品岗位的阅读。
完成标准可以按三条核验：
- 三档边界齐全。“做”“暂不做”“明确不做”都有条目，且每档至少覆盖核心使用场景，避免只写“做”而把另外两档留空。
- 每条有依据。依据来自产品定位、目标用户场景或资源约束中的至少一项，能回答“为什么划在这里”。
- 有复核条件。“暂不做”的条目写明什么信号出现时重新评估，“明确不做”的条目写明归哪个产品线或哪类需求承接。
三条标准同时满足，这份文档才算完成。只满足第一条，它是一份功能清单；只满足前两条，它是一份立场声明；三条齐备，它才具备在评审会上被引用的效力。
完整示例：一款协作工具的功能边界说明
以下是一份填写完整的示例。产品设定为一款面向中小团队的项目协作工具，演示情景，非真实产品。
产品定位与目标用户
定位句：面向 10 至 100 人规模的项目型团队，提供任务拆解、进度跟踪与团队协作的基础能力，帮助团队把计划落到可执行的工作项上。
目标用户：项目经理、团队负责人和一线执行成员。核心场景是项目立项后的任务分配、状态更新与周会同步。定位句同时划定了规模区间和场景重心，后续每一条边界都从这里推导。
三档功能边界
| 档位 | 功能条目 | 判断依据 | 复核条件 |
|---|---|---|---|
| 做 | 任务拆解与层级管理 | 直接支撑“把计划落到工作项”的定位 | — |
| 做 | 看板与列表视图切换 | 覆盖执行成员与负责人的两种查看习惯 | — |
| 做 | 工作项状态流转与评论 | 周会同步场景的最小协作闭环 | — |
| 暂不做 | 跨项目资源负载视图 | 目标用户以单项目或少量并行项目为主，当前需求频次低 | 单账号并行项目数中位数连续两个月超过 5 个，或该需求在季度反馈中进入前五 |
| 暂不做 | 自定义报表引擎 | 现有固定报表覆盖多数同步场景，自定义配置成本高 | 固定报表的导出后二次加工比例超过三成 |
| 明确不做 | 财务结算与发票管理 | 与协作定位无关，属财务系统职责 | 归财务产品线承接，本产品仅保留关联字段 |
| 明确不做 | 面向外部客户的工单门户 | 服务对象是内部团队，对外服务属客服产品线 | 归客服产品线承接，通过接口对接 |
边界外的交接方式
落在“明确不做”的需求，由产品经理在需求登记时标注归属产品线，并转交对应团队评估，原需求不进入本产品排期。“暂不做”的需求进入观察清单，由产品经理按季度汇总触发信号，达到复核条件时提交重新评估。跨边界需求在交接时保留原始场景描述和提出人，避免转交后丢失上下文。
逐项解释：每条边界为什么这样写
定位句是整份文档的约束源头。“面向 10 至 100 人规模的项目型团队”这一句同时排除了两类需求：超出规模区间的企业级管控功能，以及非项目型团队的通用办公需求。后续条目凡与定位句冲突，都可以直接引用定位句作为依据，不必逐条重新论证。
“做”与“暂不做”的区分依据是需求频次与场景覆盖，而非功能难度。任务拆解、视图切换、状态流转三项都直接服务于核心场景，缺一项闭环就不完整，因此列入“做”。资源负载视图和自定义报表引擎有真实价值，但当前目标用户的使用频次不足以支撑优先投入，因此列入“暂不做”。这个区分方式的好处是：它承认“暂不做”的功能是好功能，只是时机不对，避免团队把暂不做误解为否定。
“明确不做”要解决的是与相邻主题混淆的问题。财务结算、对外工单门户这两类需求，如果不写明归属，会在评审时反复被提出，每次都要重新讨论。写明“归财务产品线”“归客服产品线”，等于把讨论从“要不要做”转为“交给谁做”，决策成本明显下降。这里的关键是给出承接方，只写“不做”而不写去向，需求仍会回流。
复核条件要写成可观察的触发信号，避免“等需求多了再说”这类无法执行的表述。示例中的“并行项目数中位数连续两个月超过 5 个”“导出后二次加工比例超过三成”，都是可以从现有数据中统计的信号，谁来看都能得出相同结论。触发信号不必精确到小数点，但要有统计口径和时间窗口。
措辞上要避开两类写法。一类是绝对化表述，如“永不支持”“绝不做”，产品边界会随定位调整而变化，绝对化措辞会让后续修订显得自相矛盾。另一类是模糊承诺，如“后续视情况考虑”“尽快支持”，这类表述既没有触发条件，也没有责任人，等于没有边界。可用的写法是“当前不做，当某信号出现时重新评估”，把不确定性和判断条件同时写清楚。
可迁移规律：换一个产品怎么套用
换成自己的产品时，写法可以复用，内容必须重写。可迁移的判断顺序如下。
第一步，先定定位再划范围。定位句至少包含服务对象、核心场景和规模或行业限定三项，写完后再逐条检查功能条目能否从定位句推导出来。推导不出来的条目，要么补依据，要么移出“做”档。
第二步，按“明确不做—做—暂不做”的顺序判断。先排除与定位冲突、归属其他产品线的功能，范围立刻收窄；再从剩余功能中挑出支撑核心场景闭环的条目列入“做”；最后把有价值但时机未到的条目放入“暂不做”。这个顺序比先列“做”更高效，因为排除法能快速压缩讨论空间。
第三步，为每条边界标注依据来源。依据通常来自三处：用户场景（该功能服务哪个具体场景）、产品定位（是否与定位句一致）、资源约束（当前投入能否支撑）。一条边界引用其中一项即可，引用多项时按重要性排序。
第四步，复核条件与责任人成对出现。每条“暂不做”都要写明触发信号和负责跟踪的人，通常是该产品线的产品经理。没有责任人的复核条件会在几个迭代后失效。
第五步，确定维护节奏。边界说明建议随版本规划周期同步更新，至少每季度复核一次“暂不做”清单，把达到触发条件的条目提交重新评估，把定位已变化的条目移出或改写。边界说明是活文档，长期不更新的版本会失去评审引用价值。
边界说明在团队协作中需要固定的承载位置：文档存放边界说明正文与修订记录，工作项承载“暂不做”观察清单和跨边界需求的转交流转。ONES 的文档与工作项可以承担这类承载，让边界条目、复核责任人和交接状态在同一处可查，减少文档与需求记录脱节的情况。具体使用方式按团队现有流程配置即可。
适用边界：示例不能直接照搬的地方
首先要明确，本文示例中的产品、用户规模、功能条目和触发信号全部为演示情景，用于说明格式与判断逻辑，不是真实客户案例，也不含实测数据或量化成效。读者不应把示例中的具体数字当作行业基准。
功能条目必须按自身产品重写。协作工具的三档划分不能平移到其他品类，例如面向外部客户的服务型产品，“对外门户”可能恰恰是核心功能而非明确不做项。定位句、目标用户和场景重心变化后，每一条边界都要重新推导。
这份示例聚焦产品功能布局，不覆盖单需求的价值评分与优先级排序。一个需求落在“做”档，只说明它属于产品范围，不说明它应该排在本期第一。价值评估、投入产出判断属于另一套方法，需要单独进行。同样，本文也不涉及产品方案表达与原型评审的细节，边界说明回答“做不做”，方案文档回答“怎么做”。
边界说明与需求评审、原型评审是分工关系而非替代关系。需求评审时用边界说明判断需求归属，原型评审时用方案文档检查实现质量，三者各管一段。把边界说明当成评审结论使用，会遗漏对具体方案的质量判断；反过来，用单次评审的结论替代边界文档，则会导致同类需求每次都要重新讨论。
常见问题
“暂不做”的功能被业务方反复追问，怎么回应才不伤协作？
回应时把文档里的三样东西摆出来：这条功能为什么暂不做（依据）、什么信号出现会重新评估（复核条件）、谁在跟踪（责任人）。业务方追问往往是因为只看到“不做”两个字，看不到判断逻辑。把触发信号讲清楚，讨论就从“为什么不做”转到“什么条件下会做”，双方有了共同的观察口径。
如果业务方提出的场景确实不在原依据覆盖范围内，这本身就是有效信号，可以当场记录并纳入下一次季度复核，不必立刻承诺排期。
产品定位调整后，原来的边界说明怎么处理？
定位句变了，从定位句推导出来的条目都要重新检查一遍。做法是先改定位句，再逐条核对：原来列入“做”的功能是否仍支撑新定位，原来“明确不做”的是否因为定位变化需要重新评估归属。修订时保留修订记录，写清哪一条因为什么变化而调整，避免团队按旧版本执行。
定位调整幅度较大时，建议整份重写而不是逐条修补，防止新旧逻辑混在一份文档里。
小团队也需要写这么完整的边界说明吗？
团队规模小、产品线单一时，可以压缩篇幅，但三档结构和依据不能省。小团队的常见做法是把“明确不做”合并成一段说明，只保留与相邻产品线或外部系统交界处的条目；把“暂不做”压缩成一张观察清单，每条一行，写清触发信号和跟踪人。
压缩的是条目数量，保留的是判断逻辑。只要每条边界仍能回答“为什么划在这里”和“什么条件下重评”，文档就具备评审引用价值。
边界说明和需求池里的状态字段是什么关系？
边界说明回答“这个功能属不属于产品范围”，需求池的状态字段记录“这个需求当前处理到哪一步”，两者管的是不同问题。一个需求先按边界说明判断归属：落在“明确不做”的转交对应产品线，落在“暂不做”的进入观察清单，落在“做”的才进入需求池参与后续评估。
把边界判断结果作为需求登记时的必填信息，可以减少同类需求反复讨论归属的情况。具体字段怎么设，按团队现有的需求管理流程配置即可。
复核条件里的数据统计不出来怎么办？
先检查触发信号是否选得过于依赖尚不存在的数据。示例中的“并行项目数中位数”“导出后二次加工比例”都需要现成的统计口径，如果团队暂时没有这类数据，可以换成更容易观察的信号，例如“该需求在季度反馈中进入前五”“连续两个版本有客户提出”。
复核条件的核心是可观察、口径一致，不要求精确。选一个团队现在就能统计或记录下来的信号，比设一个漂亮但取不到数的指标更有用。
