Jira 至今保留 Version，ONES、TAPD 与飞书项目却把版本做成可配置工作项。菜单可以消失，范围与节奏的管理责任不能消失：一批不确定需求怎样变成团队愿担、组织可调、可核验的交付承诺，才是研发交付的核心。

最近重新看 Jira、ONES、TAPD 和飞书项目的交付规划能力时，我遇到一个很有意思的差异。

Jira 到今天仍然保留 Version。工作项通过 Fix versions 进入某个计划版本，空间里还有 Releases 页面。可再看 ONES 和 TAPD，产品更强调的是“发布”“发布计划”“规划”和“路线图”；飞书项目则更进一步，公开模板里的版本、迭代甚至里程碑，本身就可以是一类可配置工作项。

如果只看入口，很容易得到一个结论：版本管理正在消失。

但把这些产品真正保存的数据放在一起，结论正好相反。消失的往往只是一个固定菜单，或者一类写死的专用实体。团队仍然要回答：候选需求有哪些，这次准备交付什么，何时交付，能力够不够，范围变化后谁来决定，最后又真正交付了什么。

这些问题不但没有消失，团队越大，反而越不能依靠一个版本号和一次口头承诺解决。

版本入口可以消失，范围与节奏的管理责任不能消失。

这一篇不再从“迭代、版本和发布分别是什么”开始。那样写很容易把 Jira 的产品名词倒推成所有平台都必须照搬的对象模型。我更想从前面的管理问题出发，看看一批充满不确定性的需求，究竟怎样一步步变成团队愿意承担、组织允许调整、最后还能核验的交付承诺。

01 为什么 Jira 还有 Version，有的产品却不再强调它

先把四款产品的事实摆在桌面上。

Jira 对 Version 的定义很直接：一组作为单次更新共同发布的功能和修复。它可以跨越多个 Sprint，工作项通过 Fix versions 关系进入版本；开启 Releases 后，空间会增加对应入口，集中查看计划日期、范围进度，以及已连接研发工具提供的提交、合并请求、构建和部署信息。换句话说，Jira 的 Version 既是稳定的范围标识，也是查询、计划和发布信息的连接点。

ONES 的公开帮助材料里，“发布”组件从产品更新和运营节奏出发建立粗略发布列表，再把需求、缺陷规划进某次发布；路线图可以按史诗、发布或通用工作项组织时间计划，规划、基线、资源和项目集能力则分别处理更大范围的计划问题。它没有把所有责任都压在一个 Version 入口里。

TAPD 的公开帮助文档把发布计划定义为迭代之上的中长期产品规划。发布计划有目标、起止时间、需求范围和进度，并可进入发布评审。新版发布计划又增加了计划锁定、自定义视图、甘特图和统计度量。这里的“版本”更多是发布计划产生的可交付结果，产品经理日常操作的主对象则是发布计划。

飞书项目公开的软件研发模板，把需求、缺陷、版本和迭代都配置为工作项；游戏研发模板还会增加里程碑和变更。它证明的不是“飞书项目所有空间都内置这套模型”，而是另一条产品路线：平台先提供中性的工作项、关系、流程和视图，企业再按业务需要把版本、迭代、里程碑建模出来。

四款产品没有谁彻底取消了交付计划。它们真正不同的是：相近的管理责任，究竟落成一个字段、一组关系、一类可配置工作项、一个专用计划对象，还是一个带视图和治理能力的组件。

这也是判断“为什么版本不见了”时最容易踩的坑。菜单名称只能说明产品怎么呈现，不能说明底层是否还在管理范围、日期和变更。

02 研发交付管理，管理的是承诺形成，不是版本号

从第一性原理看，项目管理平台在交付这一层至少要回答六个问题。

PMBOK 第八版把治理、范围、进度、资源和风险列为关键绩效域，同时强调价值交付、适应性和问责。把它放到研发软件里，不是要求平台照搬一套过程组，而是在提醒产品经理：范围、时间、能力和风险从来不是四张互不相干的报表，它们共同决定一个承诺是否成立；而治理解决的是，承诺变化以后谁有权作出选择。

研发场景比传统计划更麻烦的地方，是信息会不断变化。刚进入需求池的一条想法，和已经排进下周发布窗口的需求，虽然都叫“需求”，承诺强度完全不同。

我会把这个过程分成五层：

1. 候选范围：值得继续评估，但尚未决定做；
2. 目标范围：与某个产品目标相关，组织愿意投入进一步分析；
3. 预测范围：按照当前信息，预计可以进入某个时间窗口；
4. 已承诺范围：责任团队已经确认，并有明确变更规则；
5. 实际交付范围：有证据证明成果进入了指定环境或用户范围。

这五层不是五张必须创建的表，也不是一条强制审批链。它们描述的是承诺逐步变硬的过程。小团队可能只用 Backlog、一个发布标签和一场计划会完成前四层；大团队则可能分别用路线图、里程碑、发布计划、迭代和基线保存决策。模型可以轻，语义不能混。

还有一条边界必须在这里讲清：前四层主要是项目管理平台能够拥有的计划事实；最后一层不能靠工作项状态自行宣布。代码进了哪个构建、制品是否部署成功、灰度覆盖了哪些用户，需要第十三篇里的工程证据链来证明。

03 范围与节奏不是两条对象链，而是两个必须同时回答的问题

为了分析交付计划，可以把它拆成范围、节奏和横向约束三部分。

1. 范围回答“做什么”：哪些工作还在候选池，哪些围绕目标被选中，哪些进入某次交付承诺，哪些后来被移出。
2. 节奏回答“什么时候重新作出判断”：路线图看多远，里程碑在哪个关键点检查结果，团队按迭代还是持续流动执行，下一次可用的发布窗口在哪里。
3. 横向约束回答“这个承诺是否可信”：团队有多少可用能力，关键依赖能否按时解除，风险是否超过可接受范围，变化发生后是否重新决策。

三者是分析视角，不是数据库层级。一个发布计划本身就会同时包含目标范围和时间预期；一个里程碑也可能既是时间锚点，又要求在该时点形成明确交付物。产品设计最怕把分析框架直接做成层级树，强迫用户依次创建“路线图—里程碑—发布计划—迭代”才能开始工作。

有的团队没有里程碑，有的团队没有独立版本，有的团队甚至不用迭代。只要它能够清楚回答范围、节奏和约束，模型依然成立。

反过来也一样。一个平台即便把上述菜单全部做齐，如果路线图只是手工画时间条、发布计划只是一个名字、迭代只统计关闭率，变化又没有历史，它仍然没有建立可信的交付模型。

04 从需求池到发布计划，不是一条必须走完的流水线

为了让这些概念不再悬空，可以用一个抽象化场景说明。它不是客户案例，只是把常见决策放进同一个模型。

假设团队准备升级一项支付能力。需求池里同时存在支付方式扩展、失败重试、对账优化、运营配置和若干线上缺陷。路线图表达的是“本季度先降低支付失败，再扩展支付方式”这一方向和顺序；合规评审日期形成一个不能忽略的里程碑；发布计划则从候选工作里选择一组范围，给出目标窗口、负责人和风险。

执行时，前端与业务服务团队使用两周迭代；基础设施团队按持续流动处理变更。它们可以进入同一个发布计划，却不需要被强行塞进同一个 Sprint。前者以迭代目标、团队容量和工作清单形成短期预测，后者以在制品限制、服务能力和预计完成时间形成执行承诺。

这个例子里，各种计划构件只负责一个主要问题。

这里还要主动消除“版本”这个词的歧义。产品版本、代码标签、构建版本、制品版本和客户端商店版本，可能共享 V1.6 这个名字，却不是同一个对象。本文说的版本，主要指用于组织计划交付范围的产品版本标识；代码、构建和制品版本属于工程系统事实，只有建立明确映射后才能关联，不能靠名称相同自动视为一件事。

为什么已经有迭代，还需要发布计划？因为两者的责任主体和时间尺度不同。迭代回答一支团队这两周准备实现什么目标；发布计划可能跨多个迭代、多支团队和多个技术栈，回答某次对外或对内交付准备包含什么。Jira 官方资料也明确说明，一个 Version 可以跨多个 Sprint。把较长的交付范围硬塞进一个“大迭代”，只会让团队容量和责任边界失真。

05 一份计划是否可信，要看范围、日期、能力和依赖如何冲突

很多项目管理软件擅长展示计划，不擅长迫使团队处理计划冲突。只要结束日期还没到、完成率还在上升，页面就可以一直是绿色的。

可真实的交付计划一定会遇到四类约束。

第一类是能力。能力不是简单的人数，也不必统一成一个精确公式。它表示特定团队在特定期间内可用于交付的实际能力，可以参考历史吞吐、可用工时、故事点或服务能力。不同团队的估算口径不能直接相加；“前端 30 点 + 服务端 50 点 = 项目容量 80 点”看似量化，实际没有可比较的单位。

第二类是依赖。第五篇已经讲过依赖关系怎样建模，这里只关心它怎样改变交付判断：某个关键前置延期以后，原范围是否仍能按原窗口交付？如果不能，系统应暴露受影响范围，而不是只在甘特图上把后续条形自动向右推。

第三类是风险。风险不是一句“存在延期风险”，而是尚未发生、却可能改变范围、日期或质量判断的不确定性。它至少要有影响对象、发生可能性、应对动作、责任人和触发条件。风险真正发生以后，应转成问题、缺陷、变更或阻塞事实，不继续躺在风险列表里。

第四类是发布就绪。测试结论、未关闭缺陷、合规审批、运维窗口和回滚准备会影响发布决策，但项目管理平台不应重新录入流水线和部署数据。它应该引用证据、保存判断和责任，而不是成为第二个工程事实源。

当四者冲突时，真正的产品动作只有几类：减少范围、调整日期、改变实现方案、重新安排能力，或者在明确责任下接受风险。系统可以计算影响、给出预警，甚至建议方案，但不能偷偷改掉范围和日期，再生成一个新的绿色进度。

这也是容量功能需要克制的地方。平台一开始做到团队级容量和关键资源冲突，往往已经足够；只有个人排期真实影响跨项目承诺时，才值得进入人员级资源管理。过早追踪每个人每天的可用小时，会把不确定的研发工作包装成虚假精确，还增加一层持续维护成本。

06 基线不是冻结变化，而是保存“我们当时怎样承诺”

敏捷不反对变化，但变化必须可见。

当前范围只能回答“现在准备交付什么”。如果一个发布计划从 20 条需求变成 27 条，系统只保存当前关系，就无法区分正常拆分、紧急插入、优先级调整和范围失控。管理者最后看到的只是新的完成率，团队当初为什么承诺、后来为什么改变，已经被覆盖。

更稳妥的模型至少有三层：

1. 当前范围，服务日常执行和查询；
2. 决策基线，保存某个承诺时点的范围快照；
3. 变更事件，记录加入、移除、延期的原因、影响、发起人和决策结果。

但基线不是所有团队一上来都必须配置的重治理能力。小团队先保存工作进入和移出计划的成员关系历史，已经能回答大部分问题；当外部承诺、合规审查、跨团队依赖或反复插单让“当时承诺过什么”变得重要，再增加正式基线、多快照和变更审批。

ONES 的基线能力很能说明这层语义：基线保存某个时点工作项的版本及其关系，供后续查看和对比。TAPD 新版发布计划的计划锁定，也是在用产品能力保护已经形成的计划判断。二者实现不同，却都在解决同一个问题：变化可以发生，但不能假装原承诺从未存在。

这与第十篇的“配置版本”完全不同。这里冻结的是一次交付计划中的业务范围；配置版本冻结的是类型、字段、流程等平台元模型。两者都叫版本或快照，事实所有者和变更后果却不相同。

07 四款产品的差异，来自对计划复杂度的不同判断

如果按统一维度再看四款产品，差异就不再是“谁有哪个菜单”。

这张表不是产品能力排行榜。它更像四种产品判断。

• Jira 选择保留稳定 Version，是因为 Fix versions 已经成为工作项查询、版本报告、发布计划和生态集成的共同键。把它取消，迁移成本和语义损失都很大。
• ONES 和 TAPD 更愿意把“制定发布范围、追踪进度、形成评审和保存基线”作为显性的计划活动，因此用户看到的主入口更接近发布或发布计划，而不是一个孤立版本号。
• 飞书项目把版本和迭代放回中性的工作项模型，让游戏、软件、运营等团队可以拥有不同层级和流程。它换来了灵活性，也把一部分产品责任交给实施者：如果每个空间都重新定义版本，跨空间统计和长期治理就会变难。

因此，专用对象不一定比可配置工作项先进，可配置也不天然优于内置。真正的取舍是语义稳定、配置自由、治理成本和使用负担之间如何平衡。

08 什么时候用字段，什么时候升级为专用计划对象

从零设计时，没必要一上来复制所有成熟产品。可以按四级方案逐步升级。

第一层是字段或标签。团队只需要给工作标记“目标发布：九月”，不需要独立负责人、状态和历史，用一个字段最便宜。

第二层是保存查询或计划视图。团队需要重复查看同一范围、按日期和负责人聚合，但范围本身还不需要独立生命周期，可以用筛选器、路线图或计划视图承载。

第三层是可配置工作项。当计划需要名称、负责人、时间、范围关系和简单流程，又要适配不同业务，可以把发布、版本或里程碑建成工作项。它能复用字段、关系、权限和工作流，代价是容易把计划对象与普通执行工作混在一起。

第四层是专用计划对象。当发布计划需要独立范围操作、基线、容量计算、跨团队聚合、情景推演、评审和专用报表时，继续把它伪装成普通工作项会越来越别扭，才值得建设专用模型。

判断是否升级，不看企业人数，而看事实是否已经独立：

• 是否有独立负责人和生命周期；
• 是否要管理一对多范围关系；
• 范围变化是否必须追溯；
• 多团队是否需要统一观察、分别承诺；
• 是否反复出现延期、插单和范围失控；
• 是否需要明确的变更和发布决策记录。

这些条件只出现一两个时，不妨继续用轻方案。因为每多一个对象，就多一套创建、权限、搜索、通知、自动化、报表和归档成本。模型越重不代表管理越成熟；没有人会用的独立对象，只是把口头负担变成了填表负担。

09 项目管理平台应该记录到哪里停止

交付计划最终会遇到一个边界问题：平台怎样证明已经交付？

项目管理平台适合保存目标范围、计划窗口、责任团队、容量判断、关键依赖、风险、范围基线、变更决策和发布评审结论。它回答“我们准备交付什么、为什么这样承诺、变化后怎样处理”。

代码仓库、测试系统、流水线、制品库、部署平台和监控系统，分别拥有实现、验证、构建、部署和用户生效的事实。它们回答“代码是否进入构建、测试是否通过、哪个制品到了哪个环境、哪些用户真正受到影响”。

两边需要连接，但不能互相冒充。发布评审通过不等于部署成功；发布计划完成不等于制品包含了全部变更；工作项全部关闭，也不能推出用户已经获得价值。

第八篇应该停在发布决策。第九篇会继续解释这些计划事实放在长期空间里以后，路线图、甘特图和各种视图怎样组织；第十一篇会回答谁有权确认范围和批准变更；第十三篇再把需求、代码、测试、制品、流水线和发布连成真正的交付证据链。

10 一个中型研发团队，怎样同时推进多个产品、版本和迭代

前面讲了很多对象和边界，放进一支真实研发团队会是什么样？下面用一个抽象案例把它们串起来。案例中的名称和数量只是为了说明模型，不对应某家公司的实际项目。

假设一个中型研发组织长期维护三款产品：用户端、商家平台和交易服务。客户端、商家端、服务端和测试分别由不同团队负责。九月需要推进两项交付：一项是跨产品的“会员权益升级”，另一项是线上高优缺陷修复。前者涉及用户端 V8.2、商家平台 V5.6 和交易服务 R24.09；后者使用各产品当前稳定版本的补丁号，发布日期也更紧。

这时，最容易犯的错误是强行画一棵父子树：产品下面放版本，版本下面放发布计划，发布计划下面再放迭代和工作项。它很整齐，却不符合团队真正的工作方式。

一个产品版本往往跨越多个迭代才能完成；同一个团队迭代也可能同时处理功能版本、线上缺陷和技术债。交易服务中的一条规则接口，还可能同时阻塞用户端和商家平台两个版本。里程碑只是“何时必须形成某个结果”的检查点，基线只是“当时承诺了哪些范围”的快照，它们都不适合成为工作项的父级容器。

更稳妥的做法，是在平台里建立两套互相连接的管理坐标，再用工作项连接、用里程碑和基线治理。

两套坐标回答不同问题；连接机制让两边读到同一条工作，治理记录则保存承诺和变化。这才是多产品并行研发更接近真实工作的结构。

这个案例保留产品版本，是因为三款产品需要独立发布、回滚和统计。如果某条产品线没有稳定的版本身份，工作项完全可以直接关联发布计划；版本不是必须经过的中间层。同样，案例启用正式基线，是因为跨产品承诺和共享依赖让“当时承诺了什么”值得被保存。更轻的团队只记录范围成员的加入、移出历史也可以。

实际操作可以这样展开。

发布负责人先创建“会员权益升级”发布计划，关联三个目标产品版本，并设置范围确认、联调完成和发布评审三个里程碑。范围评审通过后，发布负责人触发生成一份决策基线。基线不会锁死后续调整，但会保存此时三个版本分别承诺了哪些工作项。

接下来，各产品负责人维护自己的版本范围，各团队负责人再把工作项拉入迭代。客户端的 C18、C19，商家端的 M12、M13，服务端的 B35、B36 可以在不同日期开始，也不必使用相同编号。工作项同时参与两类关系：它面向哪个产品版本，以及当前由哪个团队、在哪个迭代执行。版本因此可以跨迭代推进，迭代也可以承载不同版本甚至不同发布计划的工作，而不需要反复移动父节点。

真正考验平台的，是共享依赖发生变化的时候。假设“权益规则接口”原本安排在服务端 B35，却因为线上缺陷修复被挤到 B36。系统不应该只把这条工作项标红，至少要让发布负责人沿依赖关系看到：用户端 V8.2 的权益展示、商家平台 V5.6 的权益配置都受到影响，联调里程碑已经存在延期风险。更成熟的实现，才会自动聚合这些影响并预警。

团队最终可以选择保留发布日期，把商家端的批量配置能力移到下一个版本。这个动作至少应留下四条事实：哪项工作被移出、影响哪个产品版本、为什么调整、由谁确认。原基线仍然保留，当前范围和受影响迭代随决策更新。平台没有替团队做决定，但它把决定需要看到的影响范围摆到了同一张桌面上。

于是，同一份数据可以生成四种视图：发布负责人看跨产品范围、里程碑和基线差异；产品负责人看自己版本包含什么；团队负责人看迭代容量、阻塞和依赖；研发成员只需要知道当前工作项做什么、被谁阻塞、完成后影响哪个交付结果。

这也是并行管理最重要的产品判断：不是给每个管理名词都建立一层目录，而是让同一条工作在业务承诺和团队执行两个坐标中都能被准确定位。 当产品、版本和迭代继续增加时，系统增加的是关系实例和视图，不是继续加深一棵越来越难维护的树。

回到开头的问题：为什么有的产品还保留 Version，有的却看不见了？

因为 Version 从来不是唯一答案。它可以是稳定的范围标识，可以被发布计划吸收，可以被做成可配置工作项，也可以只剩一个轻量字段。真正不能被删掉的，是候选范围怎样形成承诺、承诺怎样受到时间和能力约束、变化怎样留下历史、最终事实由谁证明。

如果读完只记住五句话，就记住这些：

1. 需求池保存候选工作，不代表已经承诺。
2. 路线图和里程碑表达方向与关键约束，不等于详细任务计划。
3. 发布计划把目标范围、时间预期和跨团队约束放在一起，但不证明已经部署。
4. 迭代只是团队执行节奏的一种，持续流动团队也可以进入同一交付计划。
5. 版本入口可以消失，范围、节奏、变更和证据责任不能消失。

真正成熟的项目管理软件，不是拥有最多的计划名词，而是每当有人问“这次到底承诺了什么、为什么延期、现在改了什么、最后交付了什么”，系统都知道该去读哪一条事实，也知道哪一条事实不归自己拥有。

下一篇，我们会把视角从交付计划移到它所在的长期容器：为什么一个叫作 Project 的入口，最后越来越像一个不会随一次交付结束而关闭的 Space；列表、看板、甘特图和路线图，又为什么只是同一对象网络面向不同决策任务的投影。