功能规划图把产品功能按模块、层级、版本和取舍状态摆在同一张图上，让团队看清“做什么、什么时候做、为什么先做这些”。本文用一个假设的移动端记账产品作为示例，给出一张完整填好的功能规划图，并逐项解释字段填法与取舍依据，帮助读者把这套结构迁移到自己的产品规划中。
要点总览（TL;DR）
- 功能规划图用“功能域—功能项—版本归属—取舍状态—依赖关系”五列，把功能布局和取舍结论放在同一张表上。
- 功能域按用户任务划分，示例中的记录、统计、周期账目、多人协作、数据安全都来自用户使用场景，功能之间的依赖关系更容易浮现。
- 取舍状态分本期做、后续做、暂缓、不做四类，暂缓项写清卡点，不做项写明排除理由，便于后续引用。
- 换产品套用时先列核心任务步骤，功能域控制在五到八个，近期写到功能项，远期可写到功能域级别，随规划节奏更新。
- 这张图负责布局与取舍表达，单需求价值评分归需求优先级评估，交互方案与原型表达归产品方案与原型评审。
示例目标：这张功能规划图要回答什么
本文示例为假设情景，不对应任何真实客户或实际项目，其中的产品、版本节奏与取舍结论仅用于演示填写方法。示例产品设定为一款面向个人用户的移动端记账工具，团队规模约十人，按季度规划版本，当前处于第二季度规划期。这个背景只用于让示例自洽，读者套用时替换为自己的产品与节奏即可。
这张图要回答三个问题：产品功能可以归入哪些功能域；每个功能项落在哪个版本；哪些功能本期做、哪些排到后续、哪些暂缓或明确不做。读者看完图，应当能说出近期版本的功能范围，以及被推迟的功能分别卡在什么条件上。
示例范围限定在功能布局层面。单个需求的价值评分、优先级打分模型属于需求优先级评估环节，功能的具体交互方案与原型表达属于产品方案与原型评审环节，这两部分不在本文展开。功能规划图回答的是“布局与取舍”，不替代这两类工作。
完整示例：一张功能规划图的填写结果
示例采用“功能域—功能项—版本归属—取舍状态—依赖关系”五列结构，按功能域分组呈现。取舍状态分为四类：本期做、后续做、暂缓、不做。版本归属用季度标识，暂缓与不做的功能项不绑定版本。
| 功能域 | 功能项 | 版本归属 | 取舍状态 | 依赖关系 |
|---|---|---|---|---|
| 记录一笔账 | 手动记账（收入/支出） | Q1 已上线 | 本期做（已完成） | 无 |
| 记录一笔账 | 自定义分类与图标 | Q2 | 本期做 | 依赖手动记账的分类字段 |
| 记录一笔账 | 语音记账 | — | 暂缓 | 依赖语音识别服务选型，待定 |
| 看清钱花在哪 | 月度分类统计 | Q2 | 本期做 | 依赖自定义分类 |
| 看清钱花在哪 | 预算设置与超支提醒 | Q3 | 后续做 | 依赖月度分类统计 |
| 看清钱花在哪 | 多维度交叉报表 | — | 暂缓 | 依赖预算功能上线后的数据积累 |
| 管好周期账目 | 周期性账单自动生成 | Q3 | 后续做 | 依赖手动记账 |
| 管好周期账目 | 账单导入（银行/支付平台） | — | 暂缓 | 依赖第三方接口对接，待定 |
| 多人一起记 | 家庭共享账本 | Q4 | 后续做 | 依赖账号体系与权限设计 |
| 多人一起记 | 账本内评论与提醒 | — | 不做 | 与产品定位不符，明确排除 |
| 数据安全 | 本地备份与导出 | Q2 | 本期做 | 无 |
| 数据安全 | 端到端加密同步 | — | 暂缓 | 依赖同步架构改造，待定 |
从图中可以直接读出近期布局：Q2 集中完成“记录一笔账”和“看清钱花在哪”两个功能域的基础能力，同时补齐数据导出；Q3 在统计能力之上叠加预算与周期账单；Q4 才进入多人协作场景。暂缓项集中在依赖外部服务或架构改造的功能上，不做项则与产品定位冲突。跨模块衔接通过依赖列体现，例如预算功能依赖统计功能，统计功能又依赖分类能力，形成一条清晰的先后链。
逐项解释：每个字段为什么这样填
功能域按用户任务划分，示例中的“记录一笔账”“看清钱花在哪”“管好周期账目”“多人一起记”“数据安全”都是用户在使用产品时会说的话。按组织架构划分会得到“客户端组”“服务端组”“数据组”这类分组，读者无法从中判断功能之间的使用关系，也难以发现某个任务链上缺了哪一环。按任务划分后，功能域之间的依赖自然浮现，比如统计依赖记录，预算依赖统计。
版本归属与依赖关系需要一起填。示例中“预算设置与超支提醒”放在 Q3，理由是它依赖 Q2 的月度分类统计；如果统计延后，预算也应顺延，而不是硬塞进 Q2 造成半成品。依赖列写的是功能项之间的先后条件，跨功能域的衔接也写在这里，例如“家庭共享账本”依赖账号体系与权限设计，这条依赖横跨基础能力与协作场景，单看功能域分组容易遗漏。
取舍状态与规划节奏对应。本期做对应已排入当前季度版本的功能；后续做对应已有明确季度但尚未启动的功能；暂缓对应方向认可但条件不成熟的功能，通常卡在外部依赖、架构改造或数据积累上；不做则是经过讨论后明确排除的功能，写进图里是为了避免反复讨论。示例中“账本内评论与提醒”标为不做，原因是它与“个人及家庭记账”的定位不符，把它留在图上比删掉更有价值，团队后续再遇到类似提议时可以直接引用这个结论。
有些信息适合留空或标注待定。“语音记账”的依赖写“语音识别服务选型，待定”，版本归属留空，表示当前无法判断落地时间。把不确定的信息如实标出，比用猜测填满更能保护规划的可信度。待定项应在下次规划评审时重新检查，确认条件是否具备。
这张图落地后需要在协作工具中承载功能项与版本状态，让规划结论和后续执行使用同一份数据。ONES 可作为此类承载工具之一，把功能项作为工作项管理、关联版本与状态，具体能力以官方资料为准。选择承载方式时，重点看功能项能否按功能域组织、版本状态能否随进展更新、依赖关系能否被记录和查看。
可迁移规律：换一个产品怎么套用
换产品套用时，先列出目标用户完成核心任务要经过的步骤，每一步对应一个候选功能域，再检查是否有跨任务的基础能力（如账号、权限、数据导出）需要单独成域。功能域数量控制在五到八个，过多说明划分过细，过少则难以体现布局差异。
分层呈现近期与后续功能，可以用季度、版本号或“现在—下一步—以后”三档。关键是同一张图上能看出时间顺序，读者不需要翻多份文档才能拼出完整布局。近期功能写到具体功能项，远期功能可以写到功能域级别，随规划推进再细化。
取舍状态与依赖标注遵循几条通用规则：
- 每个功能项必须有且只有一个取舍状态，避免“待定”泛滥；确实无法判断的，标注待定并写明缺什么条件。
- 暂缓项要写清卡点，是外部依赖、技术条件还是数据积累，卡点决定它何时能被重新评估。
- 不做项写明排除理由，理由与产品定位或资源约束挂钩，便于后续引用。
- 依赖关系只标真实存在的先后条件，不把“相关”写成“依赖”，否则整张图会变成一团线。
这张图随规划推进更新，而不是一次画完就归档。每个版本结束后，把已完成项的状态更新，检查暂缓项的卡点是否解除，把新出现的功能项补进对应功能域。更新频率与规划节奏一致即可，季度规划的产品按季度更新，双周迭代的产品可以按月汇总更新。
适用边界：什么时候这张图不够用
功能规划图解决布局与取舍的表达，不解决单个功能该不该优先做。当两个功能都排进本期、资源只够做一个时，需要进入需求优先级评估，用价值、成本、风险等维度打分，这部分方法与功能规划图分工明确：图负责摆位置，评估负责定顺序。
功能的具体交互方案、页面结构和原型表达应放到产品方案与原型评审环节。规划图上写“预算设置与超支提醒”，只说明这个功能在 Q3 做，不说明预算怎么设、提醒怎么触发。把这些细节塞进规划图会让图变得臃肿，也会让评审失去焦点。
团队规模与产品复杂度会影响这张图的用法。十人左右的单产品团队用一张表即可；多产品线组织可能需要按产品线分层，每层一张图，再用一张总图呈现产品线之间的关系。功能项超过几十条时，建议按功能域拆分子表，主图只保留功能域级别的布局。
本文示例中的版本归属与取舍结论均为演示设定，不构成对任何真实项目的承诺。读者套用时，应结合自己的用户研究、资源情况和外部依赖重新判断，示例的价值在于结构与方法，不在具体结论。
常见问题
功能规划图里的“暂缓”和“不做”有什么区别，实际填写时怎么判断？
暂缓表示方向认可但当前条件不成熟，通常卡在外部依赖、技术架构改造或数据积累上，条件具备后可以重新评估。不做表示经过讨论后明确排除，理由一般与产品定位或资源约束相关。填写时，暂缓项要写清卡点，例如“依赖第三方接口对接，待定”；不做项要写明排除理由，例如“与产品定位不符”。把两者分开记录，团队后续再遇到类似提议时可以直接引用已有结论，减少重复讨论。
功能规划图应该多久更新一次，更新时重点检查什么？
更新频率与规划节奏保持一致即可，季度规划的产品按季度更新，双周迭代的产品可以按月汇总更新。每次更新重点检查三件事：已完成功能项的状态是否同步；暂缓项的卡点是否解除、能否转入后续版本；新出现的功能项是否补进对应功能域。版本归属和依赖关系也要随调整同步修改，避免图上信息与执行状态脱节。
功能项很多时，一张功能规划图放不下怎么办？
功能项超过几十条时，建议按功能域拆分子表，主图只保留功能域级别的布局和关键依赖，子表记录具体功能项、版本与状态。多产品线组织可以按产品线分层，每层一张图，再用一张总图呈现产品线之间的关系。拆分的目的是让读者先看清整体布局，再按需下钻到细节，避免一张图承载过多信息而失去可读性。
功能规划图和需求优先级评估是什么关系，会不会重复？
两者分工不同。功能规划图负责摆位置，说明功能属于哪个功能域、落在哪个版本、取舍状态如何；需求优先级评估负责定顺序，在资源有限、多个功能竞争同一版本时，用价值、成本、风险等维度判断先做哪个。实际工作中可以先有规划图确定布局，再对本期候选功能做优先级评估，评估结论回填到规划图的取舍状态列，两份信息保持衔接而不互相替代。
规划图落地到协作工具时，需要关注哪些承载条件？
重点看三点：功能项能否按功能域组织，便于与规划图结构对应；版本状态能否随进展更新，让规划结论和执行使用同一份数据；依赖关系能否被记录和查看，避免跨模块衔接只停留在文档里。ONES 可作为此类承载工具之一，把功能项作为工作项管理、关联版本与状态，具体能力以官方资料为准。
