功能规划图把产品功能按层级、归属和版本节奏组织在一张可读视图里，让团队对功能边界和先后顺序形成同一份参照。设计时先明确图的用途与读者，再搭建“产品线—功能域—功能项—子功能”的层级骨架，为每项功能标注状态、目标版本和依赖关系，然后选择合适的图形形式呈现版本排布，最后约定更新与评审机制。下面按这五步展开，并给出可直接套用的表格与检查清单。
要点总览（TL;DR）
- 先写清图的用途与读者：功能全景、版本排布、归属边界三类用途选定一个主用途，粒度随读者调整。
- 用“产品线—功能域—功能项—子功能”四层搭骨架，功能项按“动词+对象”命名，编号采用“域代码-序号”保证可引用。
- 每个功能项补齐状态、目标版本、依赖、负责人四类字段，状态统一五档口径，未定版本写“未排期”。
- 图形按读者最常问的问题选：泳道看归属与并行，时间轴看版本节奏，矩阵看覆盖与空缺，可组合使用。
- 定稿前按结构、信息、可读、一致、维护五项清单核对，不通过先修数据底稿再调图形。
先定用途：功能规划图要回答哪几个问题
动笔前先写清这张图服务什么问题。功能规划图常见的用途有三类：一是呈现功能全景，让读者看到产品由哪些功能域构成、各域覆盖到什么程度；二是呈现版本排布，说明哪些功能进入哪个版本或时间窗口；三是呈现功能归属与边界，明确某项能力由哪个模块或团队负责。三类用途可以合并在一张图上，但主用途要选定一个，否则图会因承载过多信息而失去可读性。
读者决定粒度。产品负责人看的是功能域划分是否合理、版本节奏是否可行，功能项到“功能域—功能项”两级即可；研发团队需要知道具体做什么，功能项要拆到子功能并标注依赖；业务方关心的是某个场景所需能力何时可用，图应按业务场景或功能域组织，减少技术术语；管理层关注投入与产出节奏，图应突出目标版本和关键里程碑，弱化子功能细节。同一张图面向多类读者时，可以用主图加附表的方式：主图保持两级层级，附表列出子功能与字段。
同时划定图的边界。功能规划图只承载功能布局、归属和版本归属，需求价值评分、优先级排序方法、方案表达与原型评审另行处理。把评分和方案细节塞进图里，会让图变成需求清单，更新成本高且难以维护。建议在图的开头用一句话写明“本图回答什么问题、不回答什么问题”，作为后续评审时的共识依据。
本步骤的产出是一份用途与读者说明，包含三项内容：图要回答的目标问题清单（三到五条）、主要读者及其关注的粒度、明确排除在图外的内容。这份说明不需要很长，但要在评审时与团队确认，避免后续反复调整结构。
搭建功能层级骨架：从产品线到子功能
层级骨架是功能规划图的稳定结构。推荐四层：产品线或模块为第一层，功能域为第二层，功能项为第三层，子功能为第四层。层级不宜过深，超过四层会让图难以在一屏内读完；功能项数量较多时，优先合并子功能，而不是增加层级。单产品团队可以省略产品线层，直接从功能域开始。
功能域划分按用户任务或业务对象组织，比按技术模块划分更利于业务方阅读。例如电商产品可划分为商品管理、交易履约、营销活动、会员权益、数据分析等功能域。跨域功能归入其主要服务的域，并在其他相关域用引用标记提示；公共能力（如账号、权限、消息通知）单独设“公共能力”域，避免在每个域重复出现。划分完成后检查一遍：每个功能项是否只属于一个域，跨域引用是否有明确指向。
功能项命名采用“动词+对象”的结构，如“创建商品”“配置优惠券”，避免使用“优化”“完善”这类无法判断完成状态的词。编号规则建议采用“域代码-序号”的形式，如“GM-03”表示商品管理域第3项功能，子功能编号在父项后追加两位，如“GM-03-01”。编号一旦分配不随意变更，功能下线时保留编号并标注状态，保证历史文档和需求记录可以持续引用。
先用表格或大纲列出骨架，确认无误后再转成图形。表格字段至少包含：功能编号、功能名称、所属域、父级功能、一句话说明。下表是一个填写示例（演示情景，非真实项目）：
| 功能编号 | 功能名称 | 所属域 | 父级功能 | 一句话说明 |
|---|---|---|---|---|
| GM-01 | 商品管理 | 商品域 | — | 维护商品基础信息与上下架 |
| GM-01-01 | 创建商品 | 商品域 | GM-01 | 录入商品名称、类目、价格 |
| GM-01-02 | 批量导入商品 | 商品域 | GM-01 | 通过模板批量创建商品 |
| TR-02 | 订单履约 | 交易域 | — | 订单支付后的发货与签收流程 |
| CM-01 | 账号与权限 | 公共能力 | — | 统一登录、角色与数据权限 |
骨架完成后做一次完整性检查：是否存在没有父级的孤立功能项、是否有功能域为空、编号是否重复。这一步的产出是功能层级清单表，它是后续标注字段和绘制图形的基础。
标注功能状态与版本归属
骨架只说明“有什么”，字段说明“做到哪、什么时候做、依赖谁”。每个功能项至少填写四类信息：状态、目标版本或时间窗口、依赖关系、负责人。
状态取值建议统一为五档：规划中（已识别但未排期）、已排期（进入某个版本计划）、开发中、已上线、暂缓（明确本周期不做）。状态名称要在团队内统一口径，避免“待开发”“未开始”“排队中”混用。状态变更以版本规划会或评审结论为准，个人不得自行修改。
目标版本按团队实际的版本节奏标注，如“V2.3”或“2025 Q2”。尚未确定版本的功能项标注“未排期”，不要用模糊的“近期”代替。依赖关系记录两类：前置功能（本功能上线前必须完成的其他功能项编号）和外部条件（如第三方接口、资质审批）。依赖用功能编号引用，便于在图上连线或检索。
负责人填写到功能域负责人一级即可，子功能不必逐项指定个人，避免图随人员变动频繁失效。字段填写口径建议写成一张简短的填写说明，随图发布。下表为字段表模板：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 状态 | 五档取值之一，以评审结论为准 | 已排期 |
| 目标版本 | 版本号或季度，未定写“未排期” | V2.3 |
| 依赖 | 前置功能编号或外部条件 | 依赖 CM-01 |
| 负责人 | 功能域负责人 | 商品域负责人 |
字段补齐后，功能规划图才具备决策信息：读者能看出哪些功能已进入版本、哪些还在排队、哪些因依赖被卡住。这一步的产出是功能项字段表，与层级清单表合并后即为图的完整数据底稿。
选择图形表达：泳道、时间轴与矩阵
同一份数据可以用不同图形呈现，选择依据是读者最常问的问题。三种常见形式的适用条件如下：
| 形式 | 适合回答的问题 | 局限 |
|---|---|---|
| 泳道图 | 功能由哪个域或团队负责、哪些工作并行 | 版本节奏不直观，功能多时泳道过长 |
| 时间轴/路线图 | 每个版本交付什么、节奏是否合理 | 功能归属和层级关系被弱化 |
| 矩阵图 | 功能域在各版本的覆盖情况、哪里有空白 | 依赖关系难以表达，单元格信息量有限 |
泳道图按功能域或团队分道，横向排列功能项，适合展示归属与并行开发。时间轴按版本或季度分段，把功能项放入对应区段，适合向管理层和业务方说明节奏。矩阵图以功能域为行、版本为列，单元格填写功能项编号或数量，适合快速检查覆盖与空缺，也便于发现某个版本是否过度集中在一个域。
实际使用中常见组合：以时间轴为主图呈现版本排布，用颜色区分功能域；附一张矩阵图检查覆盖；泳道图用于功能域内部的详细排布。工具承载上，表格适合维护字段和数据，白板适合评审时讨论布局，文档适合发布定稿版本。选择哪种工具取决于团队的更新频率和协作习惯，关键是保证同一份数据只有一个维护源，图形从数据生成或同步更新。
角色分工与更新机制
功能规划图失效通常源于无人维护或更新滞后。建议明确三类角色：产品负责人对图的整体结构和版本结论负责，主持版本规划会并确认状态变更；功能域负责人维护本域的功能项、子功能和依赖字段，在变更发生时及时提交更新；研发与业务方作为使用者和评审参与者，在评审会上提出边界和节奏问题，不直接改图。
更新触发点至少包括三类：版本规划会确定新版本范围时，批量更新状态和目标版本；需求变更导致功能增减或依赖变化时，由功能域负责人提交单项更新；季度复盘时检查暂缓项是否重启、已上线项是否需要归档。更新节奏与团队的规划周期一致即可，不必追求实时同步，但要保证图在每次规划决策前是最新的。
评审与留痕方面，每次定稿在图内记录版本号和更新日期，重大调整保留变更说明，说明调整了哪些功能项、原因是什么。图与需求池、路线图的同步约定要写清楚：需求池是需求明细的维护源，功能规划图引用功能编号与需求条目对应；路线图与功能规划图的版本口径保持一致，避免同一版本在两处出现不同范围。
当功能项、版本和评审状态需要在同一处联动维护时，可以把功能项作为工作项管理，版本作为排期字段，评审结论记录在关联文档中，使图的底稿数据与执行记录同源。ONES 在研发管理场景中提供工作项与文档的承载方式，IPD 计划阶段会输出总体技术方案与开发计划并经过技术评审和阶段决策评审（依据官方 IPD 解决方案资料），这类评审结论可以作为功能状态变更的依据；功能规划图本身的字段与视图形式需按团队实际配置确定。
一个完整示例：从骨架到成图
以下为演示情景，用于说明步骤如何落地，不代表真实客户案例。假设一个中型 SaaS 产品计划未来两个版本，团队约十人，读者包括产品、研发和业务负责人。
第一步定用途：图要回答“V2.3 和 V2.4 各交付哪些功能、功能归属哪个域”，主读者是研发和业务方，粒度到功能项，子功能放附表。第二步搭骨架，得到功能域四个：商品域、交易域、会员域、公共能力，功能项共十四项，编号按域代码分配。第三步填字段，例如“批量导入商品”状态为已排期、目标版本 V2.3、依赖 CM-01 账号权限、负责人为商品域负责人；“会员等级体系”状态为规划中、目标版本未排期、无前置依赖。
第四步选图形：主图用时间轴，横轴为 V2.3、V2.4、未排期三段，功能项按域着色放入对应区段；附图用矩阵，行是四个功能域，列是两个版本，单元格填功能项数量，一眼看出 V2.3 集中在交易域、会员域在 V2.4 才有覆盖。第五步约定机制：产品负责人主持双周版本会，功能域负责人在变更后三个工作日内更新字段，图内记录版本号与更新日期。
示例中的取舍及理由：把“批量导入商品”排进 V2.3，因为它是业务方上线前的硬性条件且依赖已就绪；“会员等级体系”留在未排期，因为其价值评估尚未完成，按边界约定不在本图处理；公共能力单独成域而不拆入各域，避免重复计数。这些取舍都写在图的变更说明里，供后续复盘对照。
完成检查：功能规划图是否可用
定稿前按以下清单逐项核对，每项都应有明确答案：
- 结构完整性：每个功能项都有所属域和父级，没有孤立项；功能域划分无重叠，跨域引用有标记；层级不超过四层。
- 信息完整性：每个已排期功能项的状态、目标版本、依赖、负责人四项字段齐全；未排期项至少标注状态和负责人；编号无重复、无随意变更。
- 可读性：请一位未参与设计的团队成员在五分钟内说出产品有几个功能域、下个版本主要交付什么；如果说不清，检查图的层级和标注是否过密。
- 一致性：图上的版本范围与路线图、版本计划一致；功能编号与需求池条目可对应；状态名称与团队统一口径一致。
- 维护性：更新触发点、责任人、评审节奏已写入图内说明；最近一次更新日期在规划周期之内；变更说明可追溯。
五项全部通过即可发布使用。任何一项不通过，优先修正数据底稿再调整图形，避免在图面上反复修饰而底层字段仍然缺失。
常见问题
功能规划图和产品路线图、需求池是什么关系，需要各画一份吗？
三者回答的问题不同，可以分工维护。需求池是需求明细的维护源，记录每条需求的描述、来源和评估信息；功能规划图引用功能编号与需求条目对应，呈现功能层级、归属和版本归属；路线图面向节奏与里程碑，与功能规划图保持版本口径一致。实践中不必各画一份互不相干的图，关键是约定同一份数据只有一个维护源，其余视图从它同步，避免同一版本在两处出现不同范围。
团队规模小、功能项不多，还需要四层结构吗？
不需要照搬四层。层级的作用是让功能项可定位、可引用，功能项数量少时可以从功能域直接开始，省略产品线层；子功能也可以先不展开，等研发需要细化时再补。判断标准是读者能否快速找到某项功能并说清它属于哪里，层级过深反而增加维护成本。随着功能增多再逐层补充，比一开始就搭满四层更实际。
功能状态应该由谁改，评审会上意见不一致怎么办？
状态变更以版本规划会或评审结论为准，个人不自行修改。功能域负责人负责提交本域的字段更新，产品负责人确认版本结论。评审中出现分歧时，先把分歧点记录在图外的变更说明里，明确待定事项和下次确认时间，图上对应功能项保持原状态并标注待定，避免用临时结论覆盖已有排期。分歧涉及功能取舍时，按团队既定的评估流程处理，不在图面上直接裁决。
功能规划图多久更新一次比较合适？
更新节奏与团队的规划周期一致即可，不必追求实时同步。常见做法是版本规划会时批量更新状态和目标版本，需求变更导致功能增减或依赖变化时由功能域负责人提交单项更新，季度复盘时清理暂缓项和已上线项。要保证的是图在每次规划决策前是最新的，而不是每天都变。更新频率写进图内说明，让使用者知道当前版本的有效期。
已上线的功能要不要继续留在图上？
建议保留但做区分。已上线功能是功能全景的一部分，新成员需要看到产品现有能力；同时可以用状态字段或视觉标记与规划中、已排期功能区分开，避免图面被历史功能占满。功能下线时保留编号并标注状态，不删除记录，这样历史文档和需求记录仍可引用。若功能项过多影响可读性，可以把已上线部分收进附表，主图只呈现规划中的部分。
