产品需求决策与路线图系统行业研究报告

基本信息

阅读时间：约 27 分钟

字数：约 14,357 字

摘要：市场担心：需求决策与路线图工具是一门「功能同质化、价格被打穿」的生意。国产工具的每座位年费从 249 元到 599 元不等，开源版本永久免费且不限人数 [6][7][8][18]，客户看起来只需要一个看板加一张表格。2025 年中国研发项目管理工具市场规模只有 41.5 亿元 [3][4]，相比同一年 1,100 万人的软件行业从业人员 [14][15]，人均工具支出不过几百元。

市场担心：需求决策与路线图工具是一门「功能同质化、价格被打穿」的生意。国产工具的每座位年费从 249 元到 599 元不等，开源版本永久免费且不限人数 [6][7][8][18]，客户看起来只需要一个看板加一张表格。2025 年中国研发项目管理工具市场规模只有 41.5 亿元 [3][4]，相比同一年 1,100 万人的软件行业从业人员 [14][15]，人均工具支出不过几百元。

我们认为：这类工具的价值口径被算错了。把它当效率工具，天花板就是每座位几百元；把它当研发资源的分配器，价值锚就应该换成——它每年避免了多少被浪费的研发工时。行业研究普遍发现，软件项目 30%–50% 的工作量用于返工 [11][12]，而需求变更导致的返工成本占总预算的 17%–23% [13]。在一个 1,100 万人、人均年薪 24.9 万元的行业里 [15]，1 个百分点的工时浪费就是几十亿元的账面损失——工具费在这个量级面前，是可以忽略的零头。

1. 需求池不会自动变成产品：以 100 个需求为基数的测算显示，一次评审通过 37 个、返工后二次通过 22 个、立项 59 个、最终交付并保留 50 个 [测算]，一次评审通过率是研发资源分配的第一道分流阀；
2. 研发工时的真实去向与路线图无关：中性情景下只有 59.1% 的工时变成最终交付并保留的功能，需求返工占 24.5%、未立项需求的沉没分析成本占 12.1%、中途废弃占 4.3% [测算]；
3. 同一笔变更在不同阶段被发现的修复成本相差两个数量级：设计阶段 1 倍、编码阶段 6 倍、测试阶段 15 倍、上线后 100 倍 [10][11]，这条曲线才是需求评审环节真正的财务意义。

本篇增量：把「需求评审通过率」当成一个可以被统计、被追踪、被改善的经营指标，并且用它反推路线图上的需求数量与研发实际投入之间的缺口。结论是：工具本身的定价天花板由每座位几百元决定，但它撬动的成本基数由人均年薪 24.9 万元乘以 1,100 万人决定 [15]——这两个数字之间差着四个数量级，因此这个行业的竞争焦点不会是价格，而是谁能证明自己真的改变了工时去向。

同一门生意，市面上至少有三种规模读数，差距接近八倍。最窄的是「研发项目管理工具」口径——覆盖需求管理、迭代规划、缺陷跟踪等项目管理功能，2025 年为 41.5 亿元 [3][4]；中间的是「制造业研发管理数字化工具」口径——把需求管理、产品设计、仿真验证等环节都算进来，2025 年为 44.3 亿元、同比增长 20.1%，预计 2027 年达到 60.7 亿元 [1][2]；最宽的是通用「项目管理工具」口径，2025 年中国市场突破 45 亿美元、折合约 320 亿元、占全球接近 19% [5]。

口径差异不是统计瑕疵，而是供给结构差异的映射。152 亿元的产品生命周期管理软件市场里，本土厂商份额已经超过 45% [3]；而 41.5 亿元的研发项目管理工具市场里，三家厂商就拿走了 79% 的软件研发项目管理份额 [4]。前者的钱主要花在设计与工艺环节，后者的钱花在协作与流程环节——两者的采购决策人、预算科目与替换成本完全不同。

本报告选择 44.3 亿元的制造业研发管理数字化工具口径作为主口径，理由是它同时覆盖软件研发与软硬件一体研发场景，并且有连续两年、明确增速的公开读数 [1][2]。但需要提示：这个口径仍然只统计工具支出本身，不包含企业内部的需求管理人力成本与流程改造咨询费用——而后者往往数倍于工具费。

2025 年研发管理工具市场仍以本地部署为主：本地部署规模约 32.8 亿元、占比约 74%，云服务模式虽然只占约四分之一，但增速高达 35.6%，预计 2027 年占比将提升至 35% 以上 [2]。把这两个数字放在一起，指向一个清晰的替换周期——增量需求几乎全部流向云，本地部署的存量在被缓慢侵蚀。

行业结构上，需求最集中的是三个制造业方向：汽车及零部件约 11.5 亿元、占 25.9%，装备制造约 9.1 亿元、占 20.5%，电子信息约 7.3 亿元、占 16.5%，三者合计超过 60% [2]。这个分布解释了为什么产品形态必须支持软硬件协同研发——智能驾驶系统需要同步开发高算力芯片与算法，版本同步与测试验证的复杂度远高于纯软件项目 [4]。

国产化是结构变化里的另一条主线。制造业研发投入强度已提升至 2.6% [3]，而金融、政务等强监管领域的国产工具渗透率已超 90% [3]。国产替代在强监管行业接近完成，在制造业仍在推进——这解释了为什么本土厂商把汽车、装备、电子三个方向当作主战场，也解释了为什么「对本土研发流程的理解」会被反复写进产品说明。

软件研发项目管理 SaaS 是一个高度集中的市场：飞书项目占 37%、JIRA 占 27%、ONES 占 15%，三家合计 79% [4]；另有调研口径给出飞书项目与 ONES 两家合计占 69% [3]。两个读数的差异来自分母是否包含本地部署与开源版本，但集中度结论一致。

份额在不同细分口径下差异很大。在制造业集成产品开发场景的 SaaS 工具市场，飞书项目以 68.6% 的份额排名第一 [1][2]；在整个软件研发 SaaS 口径下，其份额为 46.8% [1]。两个数字的差额说明一件事：越是流程复杂、越需要与硬件研发对齐的场景，本土产品的适配优势越明显。

产品分层体现在功能梯度上，而不是在基础能力上。以国产工具为例，同一套代码被切成四个版本：开源版提供需求与排期、项目与团队、测试用例与效能统计等核心的研发全生命周期管理、永久免费且不限人数；企业版增加工时管理、甘特图、自定义工作流与统计报表；旗舰版增加评审管理、配置管理、风险评估与量化度量；集成产品开发版则内置需求池管理与产品路标规划流程，并提供阶段评审与决策评审的完整节点 [18]。

这个分层方式透露出这类工具的真实付费点：客户不为「能不能管需求」付钱，而为「能不能管住需求的流入与流出」付钱。需求池、路标规划、评审节点、量化度量——四个高级功能里有三个直接指向需求决策而非任务执行。这也是本报告把研究重点放在评审环节的原因。

这类工具的定价几乎全部采用每座位年费制，价格带非常窄。2026 年官网报价显示：飞书项目 249 元/人/年，Teambition 与云禅道企业版 299 元/人/年，PingCode 399 元/人/年，云禅道旗舰版 499 元/人/年，Jira 约 560 元/人/年，云禅道集成产品开发版 599 元/人/年 [6][7][8]。最高价与最低价之间只差 2.4 倍。

价格带的狭窄意味着竞争不在单价上，而在座位数的获取效率上。以 50 人团队为统一口径测算年度费用：Jira 约 28,000 元、PingCode 约 19,950 元、Teambition 约 14,950 元、飞书项目约 12,450 元 [8]。最高与最低相差 1.25 倍，绝对差价 15,550 元。

把年费与人均薪酬放在一起，价格的重要性就被压缩了。2025 年城镇非私营单位信息传输、软件和信息技术服务业的年平均工资为 248,752 元、为各行业最高 [15]；规模以上企业专业技术人员的年平均工资为 275,504 元 [14]。按 275,504 元折算，一个座位一年的工具费 249 至 599 元，相当于该员工 0.09% 至 0.22% 的人力成本。

免费版把这一点推向极端。5 人以内团队可免费使用云禅道的完整基础功能，部分厂商把免费门槛放到 10 人甚至 25 人 [7][8][18]。对一个 20 人团队而言，工具费在预算表上几乎不可见；真正被消耗的是培训时间——Jira 与 PingCode 都需要 1 至 2 天培训，按工程师日薪 1,000 元估算，20 人的培训成本约 2 万元，已经超过该团队三年的工具订阅费 [8][9]。

还有一个常被忽略的成本项：本地部署的隐性支出。开源版本虽然免费，但需要自行部署与运维，服务器成本约 2,000 元/年，加上按工程师日薪 1,000 元计算的部署与维护工时，三个月至少投入 10 天、折合约 1 万元 [9]。而商业版本地部署的起价更高——同类产品的数据中心版本年费起价约 41,500 元 [9]。免费与付费之间的真实分界线，是运维人力的边际成本。

路线图上写着多少需求，不等于研发实际做了多少事。要回答「研发资源到底投到了哪里」，需要把需求池当作一个漏斗，逐级统计通过率。本报告使用的三级漏斗模型如下：需求池 → 一次评审通过 → 返工后二次通过 → 立项 → 最终交付并保留。

模型的取值来自三条外部锚。第一，项目结果分布：2024 年约 29% 的项目成功交付、52% 受挑战、19% 被取消或放弃，合并后 71% 的项目没有完全实现原定目标 [10]；仅 35% 的项目交付了最初规划的全部功能 [10]。第二，交付环节的时间浪费：65.9% 的团队在设计和开发交付环节浪费了 25% 至 50% 的时间，主要消耗在反复确认需求细节上 [11]。第三，返工的普遍水平：软件项目 30% 至 50% 的工作量用于返工，Forrester 口径为 30%、Voke 口径为 40% [11][12]。

把这三条锚组合，得到本报告的中性取值：需求池中最终交付并保留的比例为 50%、一次评审通过率 37%、二次评审通过率 35%、立项率 59% [测算]。以 100 个需求为基数：一次评审通过 37 个；未通过的 63 个中，有 22 个在补充信息后二次通过；最终立项 59 个；其中约 15% 在上线前被砍，最终交付并保留 50 个 [测算]。

漏斗形状对参数很敏感。二维敏感性测算显示：当一次评审通过率为 25%、二次通过率也为 25% 时，有效转化率只有 37%；当一次通过率升到 45%、二次通过率为 40% 时，有效转化率升至 57%；中性组合（37% 与 35%）对应 50% [测算]。值得注意的是，一次通过率从 25% 提升到 45% 带来的改善（约 13 个百分点）大于二次通过率从 25% 提升到 40% 带来的改善（约 10 个百分点）——把需求写清楚，比把需求改好更值钱。

把需求数量换算成工时，浪费的规模就更具体。以 100 个需求、每个基准 1 单位工时为口径测算：一次通过需求消耗 1.20 单位、返工通过需求消耗 1.80 单位、未立项需求消耗 0.25 单位的需求分析成本、中途废弃需求消耗 0.40 单位 [测算]。四类相加，全年应有 84.65 单位左右的工时被消耗，其中真正变成最终交付功能的只有 50 单位——有效产出率 59.1%，浪费 40.9% [测算]。

浪费的 40.9% 并不是一笔糊涂账，它可以被拆成三项：需求返工 24.5%、未立项需求的沉没分析成本 12.1%、中途废弃 4.3% [测算]。这三项里，返工的体量最大，也因为变更成本的阶段倍率而最贵——下一章会展开这一点。

同一笔变更，在不同的阶段被发现，代价完全不同。外部研究给出的倍率是：在设计阶段发现，成本为基准的 1 倍；在编码阶段发现，6 倍；在测试阶段发现，15 倍；在上线后发现，100 倍 [10]。另一套口径覆盖更多阶段：需求阶段 1 倍、设计阶段 3 至 8 倍、编码阶段 10 倍、测试阶段 15 至 78 倍、生产环境 29 至 100 倍 [11]。

这条曲线解释了为什么在需求评审环节投入是划算的。把上一章的工时结构代入：返工占总工时的 24.5% [测算]，假设这些返工平均发生在编码阶段、倍率为 6 倍，那么每 1 单位的需求侧返工工时，对应约 5 单位的额外开发工时。若能把一半的需求返工提前到评审阶段解决、倍率从 6 倍降到 1.5 倍，仅此一项就能回收约 9 个百分点的工作量 [测算]。

返工率的行业区间给了这个测算一个外部边界。Forrester 口径为 30%、Voke 口径为 40%、行业长期估计的上限为 50% [11][12]，本报告的中性取值 41% 落在区间中段 [测算]。IDC 的另一条口径更贴近需求侧：需求变更导致的返工成本占总预算的 17% 至 23% [13]。

三情景测算给出有效投入率的区间。返工率为 50% 时，有效投入率约 50.0%；返工率为 41% 时约 59.1%；返工率为 30% 时约 70.0% [测算]。这个区间与返工研究的 30% 至 50% 上下限一一对应，因此可以把「有效投入率 50% 至 70%」当作行业分布的合理边界。

需要提醒的是，返工的来源正在变化。有研究追踪了 2444 个工程组织的 100 万次以上代码合并请求，发现每 1 美元的 AI 编码工具支出中，0.44 美元用于缺陷修复、0.27 美元用于重写 AI 生成的代码、0.11 美元用于审查与合并延迟，只有 0.18 美元变成了已交付的产品 [12]。在生成能力大幅提升之后，约束条件从「写得出」转向「说得清」——这反而放大了需求决策环节的价值。

把视角从单个需求抬到整个项目，需求问题的代价同样清楚。2024 年对 5 万个以上项目的统计显示：29% 的项目按时、按预算、按功能成功交付，52% 的项目完成但延期、超预算或缺功能，19% 的项目在交付前被取消或放弃 [10]。项目规模是最强的失败预测因子：预算 100 万美元以下的项目成功率 70%，100 万至 1,000 万美元的降到 23%，1,000 万美元以上的只有 6% [10]。

失败原因里，技术排在最后。需求不清晰占 39%、范围蔓延占 33%、规划不足占 29%、沟通断裂占 25%、技术问题只占 17%、用户参与不足 14%、高层支持不足 13% [10]。另一份研究给出更直接的结论：80% 的失败与需求问题直接相关 [11]。换句话说，这个行业面对的不是一个技术问题，而是一个信息问题。

资源浪费的规模有独立读数。项目管理研究机构估计，12% 的组织资源因项目管理不善而被浪费，相当于软件开发中每 8 元支出就有 1 元没有产生可用产出 [10]。这个数字看起来低于前面测算的 40.9%，但两者口径不同——12% 衡量的是组织层面的资源错配，40.9% 衡量的是已投入工时的返工与沉没比例。引用时需要明确在哪一层说话。

更值得注意的是失败与规模的强相关。预算 1,000 万美元以上的项目成功率只有 6%、受挑战比例 60%、被取消比例 34% [10]；大型项目的成本超支中位数达到 45%、平均比原计划少交付 56% 的价值 [10]。这意味着需求决策工具的价值随客户规模上升而上升——越大的组织，越需要一套机制来阻止范围蔓延。

算清价值口径之后，还需要算清客户基数。2025 年中国软件和信息技术服务业从业人员 1,100 多万人 [14][15]，工信部口径的软件开发者超过 940 万人，专业开发者口径约 404 万人 [14]；软件行业活跃企业超过 75 万家、规模以上企业超过 3.8 万家 [14]。产品岗位方面，国内产品从业者超过百万，2025 年产品经理人才缺口达 85 万 [16][17]。

本报告用一个自下而上的口径测算可服务市场。目标客户设定为研发人员规模达到 50 人以上的企业：以软件和信息技术服务业规模以上企业 3.8 万家为基数 [14]，假设其中约 40% 达到这一规模，得到约 1.52 万家；每家平均研发人员 150 人，工具付费座位渗透率 60%，即 90 个付费座位；按客单价 350 元/人/年（落在云禅道企业版 299 元与 PingCode 399 元之间 [7][8]）测算，每家年付费约 3.15 万元，可服务市场约 4.8 亿元 [测算]。

把这个结果与总量口径对账，会看到一个明显缺口。本报告测算的 4.8 亿元只覆盖软件研发行业，而赛迪口径的 44.3 亿元还包含汽车及零部件、装备制造、电子信息等制造行业的研发管理需求 [1][2]。按 SaaS 部分约 11.5 亿元测算 [测算]，软件行业的自下而上结果只覆盖其中约 41.6%——差额主要来自制造业客户与非软件行业的需求管理投入。

缺口的存在说明渗透率的提升空间在两端。一端是行业广度：汽车、装备、电子三个方向合计占市场的 62.9% [2]，这些客户的研发人员规模大、流程复杂，但工具渗透率仍低；另一端是座位深度：本报告假设付费座位占研发人员的 60%，若这个比例提升到 80%，同等客户基数下的可服务市场就是 6.4 亿元 [测算]。对厂商而言，提高座位渗透率比获取新客户更直接。

预测基数为 2025 年的 44.3 亿元、同比增长 20.1% [1][2]。三个情景的差别来自两个变量的组合：本地部署存量向云迁移的速度，以及制造业客户的采购节奏。

保守情景对应年增 15%，低于 2025 年实际增速 5 个百分点，对应制造业采购放缓、本地部署存量流失慢于预期的情形。中性情景对应年增 20%，与 2025 年 20.1% 的实际增速 [1][2]基本一致，也与公开预测的 2027 年 60.7 亿元、复合增速约 20% [2]相互印证。乐观情景对应年增 35.6%，即整体市场增速向云服务模式的增速收敛 [2]。

结构变化会比总量变化更有意义。2025 年本地部署占比约 74%，预计 2027 年 SaaS 占比提升至 35% 以上 [2]。若这一目标实现，2027 年 SaaS 部分规模约为 21.2 亿元、较 2025 年的 11.5 亿元接近翻倍 [测算]。对以 SaaS 为主要交付形态的厂商而言，可竞争市场的扩张速度远快于总量增速。

还有一个不体现在规模读数里的变量：人工智能能力的集成。行业分析已经指出，智能风险预警、自动化任务分配、基于历史数据的进度预测等功能，正从差异化卖点转变为用户的基础期望 [5]。这意味着工具的能力门槛在被抬高，但定价能力未必同步提升——在每座位年费 249 至 599 元的窄价格带里 [6][7][8]，新增的智能能力更像是维持价格的理由，而不是提价的理由。

1. 结论一：需求评审通过率是研发资源分配的可观测分流阀。以 100 个需求为基数的中性测算显示，一次评审通过 37 个、最终交付并保留 50 个，有效转化率 50% [测算]。路线图上写着多少需求，与研发实际产出之间隔着一层约一倍于需求数量的损耗。
2. 结论二：研发工时的有效产出率约 59%，浪费分布在返工、沉没分析与中途废弃三项 [测算]。其中需求返工占 24.5%，由于变更成本随阶段指数上升，它是三项中最贵的一项 [10][11]。
3. 结论三：这个行业的价值锚与定价锚之间存在四个数量级的差距。每座位年费 249 至 599 元 [6][7][8]，而单个研发人员的年人力成本为 248,752 元 [15]。谁能证明自己真的改变了工时去向，谁就掌握了重新定价的权利。

建议持续跟踪五个观察指标，作为上述判断的验证锚点：

1. 需求池的一次与二次评审通过率（验证漏斗模型，证伪线为一次通过率提升 10 个百分点后单位需求工时下降低于 3%）；
2. 立项需求的上线前废弃率与范围蔓延频次（验证资源浪费结构，证伪线为废弃率降至 5% 以下）；
3. 缺陷与变更的发现阶段分布（验证阶段弹性判断，证伪线为评审拦截率翻倍后测试与上线阶段修复工时未下降）；
4. 付费座位数占研发人员比例（验证可服务市场边界，证伪线为渗透率两年内超过 80%）；
5. 本地部署与云服务的收入结构（验证增速情景，证伪线为 2026 年市场增速落在 15%–35.6% 之外）。

本报告的主要风险有三项。第一是口径风险：同一门生意存在 41.5 亿元、44.3 亿元与约 320 亿元三种读数，本报告选择 44.3 亿元作为主口径，引用时须明确分母。第二是归因风险：项目失败原因统计多为事后归因，「需求不清晰」可能是组织权责不清的表象，因此本报告的漏斗参数带有模型假设成分，已通过二维敏感性给出区间。第三是替代风险：免费版与开源自建持续存在 [7][8][18]，付费渗透率可能长期低于本报告的假设值。

同一组数据，对处在不同位置的人含义不同。下面按三类角色给出可执行的观察动作，均以公开信息与内部可统计口径为限。

1. 产品负责人：把一次评审通过率作为月度指标管理，并区分「信息不足」与「判断分歧」两类驳回原因。前者靠补充材料解决，后者靠决策机制解决。本报告的敏感性测算显示，一次通过率从 25% 提升到 45% 带来的有效转化率改善约 13 个百分点，大于二次通过率从 25% 提升到 40% 的约 10 个百分点 [测算]——第一次就把需求写清楚，回报高于反复修改。
2. 研发负责人：统计缺陷与变更的发现阶段分布，而不是只统计缺陷总数。变更在设计阶段被发现成本为 1 倍、编码阶段 6 倍、测试阶段 15 倍、上线后 100 倍 [10]，阶段分布的改善会直接体现在修复工时上。同时应把「未立项需求的沉没分析成本」纳入统计口径——这部分的量级可达总工时的 12.1% [测算]，但通常不进任何报表。
3. 工具采购与信息化负责人：把座位数与人力成本放在同一张表上比较。50 人团队的四款主流工具年度费用区间为 12,450 至 28,000 元 [8]，而同等规模的研发人力成本在千万元量级。采购决策的关键变量不是单价，而是培训时间与迁移成本——两款主流工具各需 1 至 2 天培训，20 人团队的培训成本已超过三年订阅费 [8][9]。

最后需要强调时间尺度。路线图是季度的，需求池是周度的，而工具替换周期通常是三年以上。在三年时间里，返工率的 10 个百分点变化带来的工时差异，会远超任何一次采购谈判能争取到的折扣。把评估周期拉到与替换周期一致，是这个品类最容易被忽略的决策前提。

本报告共设七条可证伪链，覆盖需求池漏斗、工时去向结构、返工阶段弹性、项目失败归因、工具定价与价值锚的错配、可服务市场边界与规模预测。每条链均给出依据、边界、反面证据、跟踪指标与证伪条件，读者可按证伪条件自行验证判断的有效性。台账如下：

本报告所有关键数据均按四档标注数据来源档次，以区分证据强度与可复核性：

• [T1]一手或官方口径：政府主管部门统计、厂商官网价格公示、上市公司与机构发布的正式报告，可直接复核；
• [T2]机构二手口径：咨询机构、行业研究与专业数据库的整理数据，口径可能存在差异；
• [T3]媒体转引口径：媒体报道或企业对外宣传口径，未经独立审计，仅作参考；
• [缺口]数据缺口：无法获得可靠来源的数据，本报告一律降级为定性讨论或不写。

所有标注「测算」的数字，均为本报告基于外部锚参数推算的结果，推算公式与参数取值在正文中逐项给出。需要特别注意四处口径差异：第一，研发管理相关软件存在 41.5 亿元、44.3 亿元与约 320 亿元三种规模读数，本报告以 44.3 亿元为主口径；第二，需求池漏斗中的一次评审通过率与二次通过率均为模型参数，由项目结果分布与交付环节时间浪费数据反推而来，并非行业统一统计值，本报告已通过二维敏感性给出取值区间；第三，返工率的行业区间为 30% 至 50%，本报告的中性取值 41% 落在该区间中段，另有 12% 的组织资源浪费口径衡量的是资源错配而非工时返工，两者不可替换；第四，可服务市场的自下而上测算仅覆盖软件和信息技术服务业，与包含制造业客户的 44.3 亿元口径不可直接比较。