产品线规划图用一张按时间轴排布的结构化视图，呈现多条产品线在若干时间窗内的阶段状态与关键里程碑。设计前先统一规划周期、产品线划分口径和状态字典，再按盘点、定目标、排节奏、评审四步填图，并明确角色与更新机制。下文给出可直接套用的步骤、字段清单、示例和验收检查表。
要点总览（TL;DR）
- 先统一三项口径再动笔：时间粒度（季度或双月）、产品线划分主口径（客户群、技术平台或业务单元）、状态字典（规划、开发、上市、成长、维护、退市）。
- 填图按四步推进：盘点现状形成现状行，设定规划期末目标状态，把路径拆到各时间窗并标注里程碑与依赖，最后组织产品、研发、销售与管理层评审。
- 每个产品格至少记录产品名称与编号、所属产品线、时间窗、状态、关键里程碑、负责人、依赖说明；图面横向为时间轴、纵向为产品线，并配图例、版本号与更新日期。
- 编制、评审、维护职责落到人：产品负责人维护本产品行，产品线负责人汇总排节奏，编制人维护主版本与变更记录，管理层确认优先级取舍。
- 交付前用口径一致性、字段完整性、评审与更新机制三组清单验收，状态无依据、里程碑无责任人、依赖冲突未处理、评审结论缺失均属阻断项。
规划图先定口径：时间轴、产品线与状态字典
规划图之所以容易画乱，多数问题出在动笔之前：不同人理解的时间粒度不一致，产品线边界各说各话，状态名称混用。先把三项口径写成一份定义表，后续填图才有共同语言。
规划周期与时间粒度
时间粒度取决于规划用途和业务变化速度。年度经营规划可用季度为格；产品迭代较快、需要与研发节奏对齐的团队，用月或双月更合适。粒度一旦确定，整张图统一使用，不在局部细化到周，否则图面会失去横向可比性。规划周期建议覆盖未来4到8个时间窗，太短看不出演进节奏，太长则后段信息可靠性下降，可标注为“方向性规划”。
产品线与产品族的划分依据
常见划分依据有三类：按客户群或市场（如面向中小企业、面向大型企业），按技术平台或产品形态（如硬件、软件、服务），按业务单元归属。选择一种主口径并写清楚，避免同一张图里混用多种划分方式。产品线之下可再分产品族，层级建议控制在两层，超过两层时图面难以阅读，可拆成多张图分别呈现。
状态阶段字典
状态字典是规划图的语义基础。每个状态需要给出名称、定义、判定标准和进入下一状态的典型条件。以下是一份可直接修改使用的参考字典：
| 状态 | 定义 | 判定标准（示例） |
|---|---|---|
| 规划 | 已列入产品线规划，尚未启动开发 | 有立项意向与目标客户描述 |
| 开发 | 进入研发实施阶段 | 需求已评审，研发资源已分配 |
| 上市 | 面向市场发布 | 发布评审通过，销售资料就绪 |
| 成长 | 上市后持续获取客户与收入增长 | 有明确的增长目标与运营动作 |
| 维护 | 以存量客户服务与缺陷修复为主 | 新增投入低于维护投入 |
| 退市 | 停止销售并安排客户迁移 | 有退市公告与迁移方案 |
状态数量不宜过多，6个左右足以覆盖大多数产品线；状态名称在全组织内保持唯一，避免“孵化”“预研”“立项”等近义词并存造成误读。
四步画出规划图：盘点、定目标、排节奏、评审
口径确定后，填图本身是一个有先后依赖的过程。四步依次推进，每步都有明确输入和输出，前一步的输出即后一步的输入。
第一步：盘点现状
输入是现有产品清单、各产品的销售与客户数据、在研项目状态。动作是逐条确认每个产品当前所处状态、所处时间窗、负责人，并标注数据来源日期。输出是一张“现状行”，即所有产品在第一个时间窗的起始状态。完成标志是每个产品都有唯一状态且无遗漏，状态判定有依据可查。
第二步：设定目标状态
输入是业务目标（收入结构、客户覆盖、市场进入计划）和现状行。动作是为每条产品线确定规划期末希望达到的状态组合，例如某产品线在期末形成“一款成长产品加一款规划中新品”的结构。输出是目标状态列。完成标志是目标状态与业务目标能逐条对应，且每条产品线的目标都有负责人确认。
第三步：排布节奏与依赖
输入是现状行与目标状态列。动作是把每个产品从当前状态到目标状态的路径拆到各时间窗，标注关键里程碑（如立项评审、版本发布、退市公告），并识别依赖关系：共享研发资源的产品不宜同期进入开发，平台型产品的能力就绪时间会约束上层产品上市。输出是完整填满的规划图。完成标志是每个状态变化都有对应时间窗，依赖冲突已标注并给出处理方式。
第四步：评审确认
参与方通常包括产品线负责人、产品负责人、研发负责人、销售或市场代表，涉及资源投入时管理层参与。评审关注三件事：目标与业务策略是否一致，资源与依赖是否可行，状态判定是否符合字典。通过标准可设为：无未处理的依赖冲突、关键里程碑均有责任人、管理层对资源投入无异议。输出是评审通过的规划图版本及会议结论记录。
规划图必备字段与图面结构
图面结构决定可读性，字段决定可用性。两者一起定义，才能让规划图既看得懂又查得清。
每个产品格需要记录的字段
| 字段 | 说明 | 是否必填 |
|---|---|---|
| 产品名称与编号 | 唯一标识，与产品台账一致 | 必填 |
| 所属产品线/产品族 | 按既定划分口径填写 | 必填 |
| 时间窗 | 如2025 Q1，与时间粒度一致 | 必填 |
| 状态 | 取自状态字典 | 必填 |
| 关键里程碑 | 该时间窗内的评审、发布、退市节点 | 状态变化时必填 |
| 负责人 | 产品负责人姓名 | 必填 |
| 依赖说明 | 资源、平台或外部条件约束 | 有依赖时填写 |
| 备注/假设 | 数据口径、待确认事项 | 选填 |
图面布局
横向为时间轴，从左到右按时间窗排列，表头标注时间窗名称；纵向为产品线，同一产品线内的产品相邻排列，产品线之间用分隔线或底色区分。每个产品占一行，行内按时间窗填状态色块，色块内写状态简称，里程碑用标记符号标注在对应时间窗。图例放在图的下方或右侧，说明状态颜色与标记含义。
版本与变更标注
规划图需要标注版本号和更新日期，放在图面固定位置。每次变更记录变更内容、变更人、变更原因，可采用简表附在规划图之后。对尚未确认的规划，用虚线边框或浅色填充区分“已确认”与“方向性”内容，避免读者把假设当成承诺。
角色分工与交付物：谁画、谁审、谁维护
规划图能否长期使用，取决于职责是否落到人。编制、评审、维护三个环节分别对应不同角色。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 提供所负责产品的现状、目标与里程碑，维护本产品行 | 产品状态说明、里程碑清单 |
| 产品线负责人 | 汇总本产品线数据，排布节奏，处理线内依赖，组织线内评审 | 产品线规划图分册、依赖处理记录 |
| 规划图编制人（可由产品线负责人或产品运营兼任） | 统一口径，合并各产品线内容，维护版本与变更记录 | 规划图主版本、变更记录 |
| 研发负责人 | 确认资源可行性与技术依赖 | 资源与依赖评审意见 |
| 管理层 | 评审目标与投入，确认优先级取舍 | 评审结论与决策记录 |
更新频率建议与规划周期匹配：季度规划按月复核，半年规划按季度复核；出现重大市场变化或资源调整时触发临时更新。维护责任归编制人，各产品行的准确性由对应产品负责人负责。规划图的状态与里程碑如果只停留在文档里，复核时容易出现信息滞后，可以在协作工具中承载：ONES Plan 面向以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，同时支持制定项目里程碑与甘特图、多时间跨度查看进度，便于把规划图中的时间窗与里程碑对应到实际项目数据上做复核。
示例：一条产品线的规划图如何填
以下为演示情景，用于说明字段填写与取舍逻辑，不代表真实客户案例。假设某产品线包含三款产品：A（成熟主力）、B（成长期）、C（规划中新品），规划周期为四个季度。
| 产品 | Q1 | Q2 | Q3 | Q4 |
|---|---|---|---|---|
| A | 成长 | 成长 | 维护（里程碑：版本冻结） | 维护 |
| B | 开发 | 上市（里程碑：发布评审） | 成长 | 成长 |
| C | 规划 | 规划（里程碑：立项评审） | 开发 | 开发 |
逐项解释：A在Q3转入维护，是因为其客户增长趋缓、维护投入已超过新增投入，符合状态字典的判定标准；B在Q2上市，里程碑标注发布评审，负责人为B的产品负责人；C在Q2完成立项评审后才进入开发，避免与B的发布期争夺同一研发资源。这里的取舍逻辑是：同一时间窗内只安排一个产品进入重投入阶段，把资源冲突前置到排节奏环节解决，而不是留到执行中协调。
完成检查：规划图交付前的验收清单
交付前逐项核对以下清单，全部通过方可作为正式版本发布。
口径一致性
- 全图使用同一时间粒度，时间窗命名统一。
- 产品线划分只采用一种主口径，层级不超过两层。
- 所有状态均取自状态字典，无自造状态名。
字段完整性
- 每个产品行均有负责人，状态变化处均有里程碑。
- 依赖关系已标注，且有对应处理说明。
- 图例、版本号、更新日期齐全。
评审与更新机制
- 评审参与方覆盖产品、研发、销售或市场，涉及投入时有管理层结论。
- 更新频率与责任人已写明，变更记录可追溯。
- 未确认内容已用视觉方式区分。
阻断项与完成条件
存在以下任一情况时不予发布：状态判定无依据、关键里程碑无责任人、依赖冲突未处理、评审结论缺失。全部阻断项清零，且上述检查项无未通过项，即视为规划图达到可用状态，可进入正式发布与后续复核。
常见问题
规划周期应该覆盖多长时间，后段时间窗信息不可靠怎么办？
建议覆盖未来4到8个时间窗：太短看不出产品集合的演进节奏，太长则后段信息可靠性下降。对靠后的时间窗，可以保留状态与里程碑，但用虚线边框或浅色填充标注为“方向性规划”，与已确认内容区分开。复核时优先更新最近两个时间窗，后段随业务目标明确再逐步转实。
产品线层级超过两层时，规划图怎么处理？
图面层级建议控制在两层（产品线—产品族），超过两层会明显影响可读性。可行做法是拆成多张图：一张产品线级总览图只呈现各产品线的整体状态分布，另按产品线分别出分册图，呈现产品族与具体产品。总览图与分册图使用同一套状态字典和时间粒度，避免口径分裂。
规划图评审时最常见的分歧是什么，如何减少反复？
分歧通常集中在两处：一是资源是否够用，二是同一时间窗内多个产品争抢同一批研发资源。减少反复的关键在第三步排节奏时就把依赖冲突显式标注，并给出处理方式，而不是留到评审会上临时协调。评审前把现状行、目标状态列和依赖说明提前发给参与方，会上只讨论未决项，通过标准可设为无未处理依赖冲突、关键里程碑均有责任人、管理层对资源投入无异议。
规划图做好后，多久更新一次，谁来负责？
更新频率与规划周期匹配：季度规划按月复核，半年规划按季度复核；出现重大市场变化或资源调整时触发临时更新。维护责任归编制人，负责合并各产品线内容、维护版本与变更记录；各产品行的准确性由对应产品负责人负责。状态与里程碑如果只停留在文档里，复核时容易信息滞后，可以在协作工具中承载。ONES Plan 面向以“产品-项目”模式工作的研发团队，支持管理产品线并通过工作项属性跨项目管理，同时支持制定项目里程碑与甘特图、多时间跨度查看进度，便于把规划图中的时间窗与里程碑对应到实际项目数据上复核。
示例里的状态色块和里程碑标记，必须按固定样式画吗？
样式可以自定，但需要满足三个条件：状态颜色与图例一一对应且全图统一；里程碑标记在对应时间窗内可定位到具体产品行；已确认内容与方向性内容在视觉上可区分。样式一旦确定就写入图面规范，后续版本沿用，避免每次更新都重新解释图例。
