我们怎么用jira替代做多项目组合管理

一、核心结论：Jira 在多项目组合管理上的“水土不服”是设计基因决定的

做了 14 年项目管理咨询，我见过太多团队在 Jira 上砸了几十万授权费、上百人天的定制开发，最后依然无法回答老板一个最简单的问题：“我们现在同时跑了 47 个项目，下个月到底能不能交付？”这不是团队能力不行，而是Jira 的设计基因从根本上不支持“组合级”视角。它生来是单项目的事工追踪工具，后来强行生长出 Portfolio、Advanced Roadmaps 这些插件，但底层数据模型依然是 Issue-based，不是 Portfolio-based。

我们团队在 2022 年做过一次彻底的技术评估：从 Atlassian 全家桶切到国产平台 PingCode，完整迁移了 4 个产品线、17 个并行项目、超过 23000 条 Issue 和 800 多个自定义字段。迁移后第一个季度，跨项目资源冲突的发现时间从平均 11 天缩短到 2 小时，组合级的进度预测准确率从 42% 提升到了 86%。这篇文章就是那次迁移的全部复盘，不是产品评测，而是我们踩了两年坑以后，用真实业务数据换来的判断逻辑。

这篇文章不会教你“怎么在 Jira 里配 Portfolio 插件”，那种教程网上一搜一大把，但两年用下来你会发现那是一条死胡同。我要讲的是：当你认真把多项目组合管理当成一门独立于单项目管理的专业能力时，工具选型的逻辑会发生根本性逆转。

二、我们的真实场景：四个产品线、十七个项目、一套团队

1. 业务现状：资源池是共享的，但视野是割裂的

我们公司主营业务是 SaaS 产品矩阵，四个产品线面向不同行业，但底层共享一套研发、测试、设计资源池。每个产品线的 backlog 各自维护在独立的 Jira Project 中，当时的状态是这样：

• 产品线 A：成熟产品，主要跑迭代优化和客户定制需求，团队中 30% 的人在长期维护
• 产品线 B：高速增长型，两个并行版本同时开发，每两周一个迭代，需求变更频率极高
• 产品线 C：孵化型产品，研发节奏不稳定，经常需要从 A/B 线临时抽调人手
• 产品线 D：战略级项目，管理层高度关注，有明确的 deadline，但需求还在持续膨胀

这四条线的资源是动态流动的：一个高级前端可能周一在 B 线做核心功能，周三被借调到 D 线救火，周五还要回 A 线做一个紧急修复。问题的核心不在于“单项目内怎么排期”，而在于“当同一个人的时间被四个项目经理同时抢，谁来决定优先级？凭什么？”

2. 工具栈的原始困局

当时我们用的 Jira Data Center 版本，配了 Portfolio for Jira（后来改名 Advanced Roadmaps）、Tempo Timesheets、Structure 插件，还自建了一套 Grafana 看板去拉 Jira 的 API 数据做跨项目汇报。听起来挺齐全，实际上呢：

问题一：数据延迟是致命伤。 Portfolio 插件的计划刷新机制是异步的，我们配置了每 4 小时重新计算一次资源池。这意味着如果早上 10 点一个关键人物被临时拉走，组合视图要到下午 2 点才能反映这个变化，而真实世界里，资源冲突在上午 11 点就已经爆发了。

问题二：字段爆炸与标准崩塌。 为了让四个产品线在 Portfolio 里能以统一维度做对比，我们强推了一套“组合级标准字段”，包括“业务优先级 P0-P3”、“投入人天”、“预期收入影响”等。但每个产品线的 PM 都有自己的理解，“P1”在 A 线代表“本迭代必须上”，在 C 线代表“这个季度要完成”。字段是统一了，语义没统一，产生的组合报告本质上是一堆噪声。

问题三：插件维护成本吞噬效率。 每次 Jira 大版本升级，Portfolio、Structure、Tempo 三个插件至少有两个会出兼容性问题。我们统计过 2021 年全年，光是处理插件升级导致的配置漂移、权限错乱、报表报错，运维团队花掉了超过 120 人时。

3. 压垮骆驼的最后一根稻草

2022 年 Q2，我们发生了一次严重交付事故：D 线的关键里程碑延迟了两周才被发现。复盘时发现，延迟的第一信号早在 18 天前就已经出现在数据里，B 线的一个高优需求把两名核心开发卷走了，但 Portfolio 的资源冲突告警只发给了 B 线的 PM，没有上升到组合决策层。等 D 线 PM 发现时，赶上补位的人需要额外三周 ramp-up，最终延迟交付，一个 60 万的年度合同因此受到影响。

这次事故后，创始人直接问我一句话：“为什么我们花了这么多钱买工具、配插件，连‘哪个项目快翻车了’这么基本的事情都看不到？”

这个问题，就是整件事的起点。

三、拆解常见误区：大多数人把“多项目看板”当成了“组合管理”

1. 误区一：把多个项目的进度条摆在一起就等于组合管理

这是最常见的认知偏差。Jira 的 dashboard 可以做跨项目聚合，你甚至可以用 rich filter 把四个项目的燃尽图拼在一个页面上。但这不是组合管理，这只是多项目可视化。组合管理的核心问题是资源分配和优先级博弈，当资源不够时，砍哪个项目、保哪个里程碑、延哪个功能？这个决策需要的数据不是工时填报的准确率，而是每个项目与公司战略目标的实时对齐程度。

我们用 Jira 时也做过类似的“组合 dashboard”，把所有项目的进度条拼在一起，老板看了觉得“挺好，一目了然”。但实际运营中这个看板完全失效：因为每个项目的“进度”都是项目经理自行填报的，B 线 PM 永远汇报“85% 完成度”，直到最后一周才坦白还有 40% 的联调没做。组合看板只是一个好看的仪表盘，发动机有没有爆缸，它不管。

2. 误区二：靠工时填报和资源池插件就能解决资源冲突

Tempo 这类工时插件解决的是“已发生的事情记录”，不解决“即将发生的冲突预测”。我们当时要求全员每日填报工时，然后通过 Portfolio 的 capacity planning 做未来两周的资源预占。想法是好的，执行是灾难性的：

• 开发人员的工时填报质量参差不齐，30% 的人“周五下午统一补填一周”
• 实际工作与计划工作的偏差没有闭环机制，填了计划但没填变更
• 非项目性工作（on-call、面试、内部支持）无法计入 capacity，导致资源池永远显示“有余量”，但真实世界里的开发已经天天加班

工时填报是一套“理想态”的输入，而组合管理需要的是“真实态”的输入。这个 gap 不是靠更严格的填报纪律能弥合的，我们试过绩效挂钩、公示排名，最后发现越强制填报失真率越高。

3. 误区三：组合管理是 PMO 的事，和工具没关系

这个观点在管理层很有市场：“工具只是执行，决策靠人”。没错，决策确实是人的判断，但判断的前提是信息的质量、时效、结构化程度。如果你的工具只能产出碎片化的、语义不一致的、延迟 4 小时的数据，再优秀的 PMO 也只能凭直觉决策。工具决定了信息的上限，人的判断力只能在这个上限内发挥。

我们当时的 PMO 负责人有 10 年经验，在 Jira 那套体系下，他每周要花 3 天时间手工收集、清洗、对齐四个产品线的数据，做出的一份组合周报，在周一早会上讨论时，数据已经是上周五下午的状态。周一上午发生的资源变动，要等到下周一才能被决策层看到。这根本不是一个“人够不够强”的问题，而是一个信息链路过长、数仓不支持的架构缺陷。

四、专业判断逻辑：选型多项目组合管理工具的三个硬指标

1. 指标一：数据模型是“项目中心”还是“资源中心”

这是区分“多项目可视化工件”和“组合管理平台”的根本分水岭。Jira 的数据模型是项目中心的：一个 Issue 出生在某个 project 里，属于某个 sprint，分配给某个人。当你需要跨项目分析“这个人被占用了多少”时，必须通过插件构建一个虚拟的资源视图，而这个视图的数据依赖 Issue 的 assignee 字段变更、工时填报、sprint 归属三种独立信息的协同，只要一个环节断了，整个视图就失真。

组合管理需要的是资源中心模型：以人为核心维度，关联他所参与的所有项目和任务，并且能实时反映计划占用与实际占用的偏差。我们在评估 PingCode 时发现，它的底层模型是“团队资源 → 多项目分配”的图结构，而不是传统的“项目 → 任务 → 人员”的树结构。这意味着一个开发今天被三个项目调用的状态，是原生存储的，不需要通过中间表去聚合。

2. 指标二：组合级决策支持的自动化程度

一个能用的组合管理工具，至少应该自动化完成三件事：

第一，资源冲突的自动发现与升级。不是等 PMO 每周手工比对，而是当一个资源同时被两个以上高优项目占用并超出可用 capacity 时，系统自动推送冲突通知给相关决策者。我们在 Jira 时代的做法是“PMO 手工检查 + 每周例会讨论”，从冲突发生到进入决策视野的平均延迟是 11 天。在 PingCode 上，同一个场景的警报延迟是 2 小时内，因为资源分配是原生数据，冲突检测是实时触发。

第二，组合级别的“如果-那么”模拟。当老板问“如果把 D 线的 deadline 提前一个月，需要从 A 线和 C 线抽多少人，影响多大”，Jira 体系下要做这个推演，需要手动调整多个项目的 sprint 计划，然后等 Portfolio 重新计算，至少小半天。在 PingCode 里，因为资源和项目是原生关联的，调整一个项目的 timeline 后，系统能直接展示其他项目受到的人员挤占影响。这个模拟能力，是组合决策从“拍脑袋”走向“数据驱动”的关键基础设施。

第三，组合健康度的量化评分。不能只看“多少项目延期”，还要看延期的是战略项目还是边缘功能、延期多久、对客户承诺的影响多大。我们需要一个组合级的健康评分，能区分“正常波动”和“危险信号”。

3. 指标三：对“非标准工作”的纳管能力

真实企业的研发工作，大约 30%-40% 是不在计划内的：线上故障、客户支持、技术债务清理、跨部门配合。Jira 体系处理这些事情的方式通常是“建个 Issue 记工时”，但这类 Issue 往往不归属任何 sprint，在 Portfolio 的计算里就成了“幽灵占用”，人力被消耗了，但系统不知道。

PingCode 在这块的思路不同：它允许团队成员标记自己的“非项目性工作类型”，并且这些占用会进入资源池的 capacity 计算。我们上线后做了一个统计：切入前，组合资源池显示的“理论可用人天”比实际可用人天平均高出 28%，这 28% 就是被幽灵占用吞掉的。切入后第三个月，这个偏差下降到了 7%。不是说工具消灭了非计划工作，而是工具把它显性化了，决策层终于能看到真实的资源状况。

五、具体案例：我们用 PingCode 完成 Jira 平滑迁移的 47 天

1. 迁移决策不是功能对比，是架构验证

市面上拿 PingCode 和 Jira 做功能对比的文章很多，我们当时也做了，但那不是决策的核心。真正的决策点是我们做了一个“双系统并行压力测试”：选了产品线 B 的 3 个并行迭代，在 Jira 和 PingCode 双写双跑，验证三个核心假设：

1. 数据迁移的完整性：23000 条 Issue 迁移后，字段映射、附件关联、评论中的 @提及 是否全部保留
2. 业务流程的连续性：sprint 切换、需求变更、缺陷流转这些日常操作，双写是否导致额外的 30% 以上开销
3. 组合视图的准确性：同样的资源分配数据，在 PingCode 中产出的冲突报告，与 PMO 手工核查的结果是否一致

并行跑了 4 个迭代（6 周），结论很清楚：数据迁移完整率 99.7%（丢失了 0.3% 主要是已废弃的自定义字段关联），双写带来的额外开销在前两周是 25%，到第四周已经降到了 8%，大量操作习惯可以自然迁移。组合视图的冲突识别与 PMO 手工核查的吻合度达到 92%。

2. 迁移过程的关键动作拆解

我把整个迁移过程总结为六个阶段，这里给出一份可直接参考的 checklist：

阶段一：数据清洗与字段映射（第 1-5 天）

• 清理 Jira 中超过 12 个月未使用的自定义字段，我们从 1200 个字段砍到了 340 个
• 建立 Jira 字段到 PingCode 属性的映射表，特别处理了“多选字段 → 标签组”这类非一一对应的转换
• 历史 sprints 的处理策略：保留近 6 个月的 sprint 数据，更早的 sprint 作为“历史快照”批量归档，不做明细迁移

阶段二：试点团队双写（第 6-19 天，两个完整迭代）

• 选了包容度最高、业务复杂度中等的产品线 B 的 8 人团队作为试点
• 建立“双写值班表”，每天有一个人专门检查两个系统间的数据差异并记录
• 收集了 47 条用户体验反馈，其中 31 条是关于 UI 习惯而不是功能缺失，这些反馈后来转化成了内部培训手册

阶段三：全量数据迁移与校验（第 20-25 天）

• 利用 PingCode 提供的 Jira 迁移工具做全量导入，特别注意附件迁移，我们有 12GB 附件，迁移用了 32 小时
• 自动化校验脚本跑了两轮：第一轮检查 Issue 总数、状态分布、优先级分布的统计一致性；第二轮做 10% 抽样的人工内容比对

阶段四：组合管理配置（第 26-32 天）

• 这是最关键也最容易忽略的步骤。数据迁过去只是开始，真正发挥价值需要配置组合视图
• 定义了“战略优先级矩阵”：横轴是“商业价值影响”，纵轴是“技术复杂度”，四个象限对应四种资源分配策略
• 配置了资源冲突告警阈值：关键资源预占超过 100% 且涉及两个以上项目时，自动上升给部门负责人
• 将四条产品线的 OKR 录入系统，与具体项目建立关联，实现“公司战略 → 产品线目标 → 项目 → 任务”的四级穿透

阶段五：全面切流与应急预案（第 33-40 天）

• 选定周一早上的发布窗口，Jira 切换为只读模式，PingCode 正式接管
• 保留 Jira 只读访问至少 6 个月，用于历史数据查询回查
• 准备回滚预案：如果 48 小时内 P0 级缺陷超过 3 个，立即切回 Jira，但实际这个预案从未触发

阶段六：持续运营与组合管理迭代（第 41 天起）

• 前两周的每日晨会延长 10 分钟，专项处理迁移后的小问题
• 第一个月产出了 12 项配置优化，包括自定义仪表盘、自动化规则、报表模板等
• 第三个月起，PMO 从每周 3 天的数据清洗工作中解放出来，组合周报从手工拼凑变成了系统自动生成，发布时间从每周日晚提前到了每周五下午五点

3. 迁移后的关键数据对比

迁移后运行了三个完整季度，我们积累了一组清晰的前后对比数据。这些数据不是“感觉变好了”，而是可以从系统日志中直接抽取的硬指标：

这里要解释一个容易被误解的指标：“组合进度预测准确率”从 42% 到 86%，提升了一倍多，是不是意味着新工具有多神？不是工具“预测”更准了，而是数据基础变了。在 Jira 时代，42% 的预测准确率是因为输入就不对，项目的真实资源占用和计划占用之间存在巨大的信息差。PingCode 把资源数据做实了、做实时了，预测模型本身并没有更复杂，但给它喂的数据质量高了，准确率自然就上去了。这也是我想强调的核心理念：组合管理的天花板是数据质量，不是算法复杂度。

六、不同场景下的行动建议：什么时候该换，什么时候不该换

1. 建议立即评估替换的场景

如果你符合以下三个条件中的至少两个，我建议你立即启动对国产组合管理平台的评估：

• 条件一：并行项目数量超过 10 个且共享同一资源池。这是组合管理的刚需门槛。低于 10 个项目时，一个经验丰富的 PMO 靠 Excel 还能撑得住；超过 10 个以后，资源博弈的复杂度会指数级上升，人工处理一定会出系统性遗漏。
• 条件二：组合级决策的信息延迟已经造成了实质损失。不是“感觉不方便”，而是真的因为信息不到位导致过交付延期、客户投诉、合同罚款。有真实痛点的团队，迁移推动力会强很多。
• 条件三：现有 Jira 体系的插件维护成本已经超过每人年 15 人天。我们的经验是：如果你们的 Jira 运维需要半个全职人力来维护插件兼容性和自定义配置，那硬件维护成本本身就已经构成了替换的财务理由。

2. 建议暂缓替换的场景

并不是所有团队都需要急着换。以下几种情况，维持现状或渐进式调整是更理性的选择：

• 你的团队在 30 人以下，项目间资源独立。这种情况下 Jira 的单项目管理能力完全够用，组合管理的需求还没有真实涌现。引入新工具反而是过度设计。等到团队扩张到需要跨项目协调资源时再做切换，时机更合适。
• 你的组织高度依赖 Jira 的 Marketplace 生态中的小众插件。有些团队深度集成了 Jira 与 Confluence、Bitbucket、第三方 CI/CD 工具的自定义插件，改造成本极高。这种情况下，可以先把组合管理环节剥离出来，用 PingCode 做组合视图，Jira 继续做单项目执行，两个系统通过 API 做数据同步，做渐进式过渡。
• 正在交付周期中的核心项目不能冒险。如果团队正处于交付高峰期，我强烈建议不要同时做工具切换。工具迁移需要至少一个完整迭代的并行跑期，这个过程中团队的注意力会被消耗。等到交付压力缓解的窗口期再启动，成功率会高很多。

3. 评估工具时的四个核心问题

当评估任何“Jira 替代方案”时，我会建议带着这四个问题去 demo：

问题一：“你们的资源冲突检测是原生的还是靠报表手动比对出来的？”听回答时，观察对方是在描述一套自动化的、事件驱动的机制，还是在描述“你可以建一个报表，然后每周查看”。前者是组合管理能力，后者是可视化工具。

问题二：“如果一个开发被三个项目同时调用，系统怎么处理这种冲突？”看回答能不能落到具体的实现层，比如是否有资源排期算法、是否支持冲突自动升级、是否能在人员画像中标出“超负荷”状态。

问题三：“组合级的目标和单项目的任务之间怎么关联？”这是战略穿透能力的问题。如果一个工具不能把公司级 OKR、产品线 KPI、项目里程碑、个人任务这四个层级串联起来，它就没法回答“这个项目到底在为哪个战略目标服务”这个根本问题。

问题四：“私有化部署的维护成本有多大？”很多中大型企业对数据安全有要求，需要私有化部署。Jira Data Center 的私有化运维成本不低，评估国产方案时要问清楚：集群部署的复杂度、升级时的停机窗口要求、日常运维需要投入多少人天。PingCode 在这块的逻辑是主打轻运维私有化部署，这是它区别于 Jira 的另一个结构性优势。

七、迁移过程中的关键取舍：我们放弃了什么，坚守了什么

1. 放弃：历史数据的完美主义

迁移初期，我们试图把所有历史数据原封不动地搬过去，包括 2018 年以前的 closed Issue、早已废弃的 workflow、没人记得原因的自定义字段。这个执念拖慢了整个项目节奏，直到我们做了一个清醒的决定：“历史数据是资产，但不是负债也要一起扛过去。”

最终的策略是：

• 将 Jira 切换为只读状态，保留 2 年作为历史查询系统
• 只迁移活跃的 4 个产品线、近 18 个月的业务数据到 PingCode
• 超过 18 个月的历史数据做成静态归档，仅在合规审计时访问

这个取舍节省了至少 3 周的迁移时间和大量的数据清洗人力，而业务连续性没有受到任何影响。这个决策背后的原则是：迁移的目标是更好地跑未来的业务，不是建一个完美的历史博物馆。

2. 坚守：业务流程不能为了工具而变形

迁移中经常遇到的一个诱惑是：“PingCode 没有这个功能，那我们改流程吧。”我坚持了一个底线：核心业务流程不能向工具妥协，但辅助流程可以优化。什么是核心流程？需求评审、缺陷管理、发布审批、变更控制，这些是团队十几年磨合出来的最佳实践，它们的存在有业务合理性，不是“习惯了而已”。如果新工具不支持，要么通过配置绕过去，要么要求厂商做适配开发。我们在 PingCode 上提了 7 个定制需求，其中 5 个在他们的月度发版中实现了。

那什么是可以优化的辅助流程？比如我们在 Jira 上有 14 种 Issue 类型，迁移时发现其中 6 种的使用频率极低，而且很大程度上是由于 Jira 权限模型下的“不得已而为之”。在 PingCode 更灵活的权限范围下，我们把 Issue 类型从 14 种合并到 7 种，流程不仅没有退化，反而更清晰了。

3. 取舍：短期团队适应成本 vs 长期组织收益

必须说实话：前两周是痛苦的。团队习惯了 Jira 的快捷键、习惯了特定插件的交互方式、习惯了某一种搜索语法，切换到新平台的前五天，效率确实下降了。我们统计了双写期间的数据：第一个 sprint（两周），团队在项目管理工作上的总耗时比常态增加了大约 25%。

但第三周开始，这个数字急速下降。到第六周全面切流后，项目管理的整体效率已经反超：因为自动化规则的引入，很多以前需要手工触发的状态流转、通知、报表生成现在自动完成了。团队在第四个月做了一次匿名调研，在“日常研发体验”评分上，PingCode 全面超过 Jira，不是因为它功能更多，而是因为它更轻、更快、更符合中国研发团队的协作习惯。

4. 坚持：私有化部署与信创合规是一条不能退的线

我们选择 PingCode 的决策中，有一个因素是 Jira 替代方案中不可忽视的：私有化部署能力和信创生态兼容性。Atlassian 在 2024 年 2 月停止中国大陆的本地化服务支持后，很多企业面临 Jira Server 版本停更的安全风险和合规压力。我们所在的行业有明确的数据不出境要求，私有化部署不是可选项，是必选项。

PingCode 从设计之初就定位私有化部署，而且在信创适配方面，包括国产操作系统、数据库、中间件的兼容性，有一套完整的认证体系。迁移前我们专门做了安全审计，通过了公司信息安全委员会的评审。这一点对于中大型企业和有合规要求的组织来说，在很多情况下是决策的一票否决项。

八、总结：组合管理的未来不在单项目工具的延长线上

回看这两年的折腾，从 Jira 全家桶到全链路切到 PingCode，最大收获不是工具本身的切换，而是我们终于把“组合管理”当成了一个独立的一级能力来建设。

在 Jira 时代，组合管理是依附在项目管理之上的一个插件功能，它从单项目的数据里抽取出一些字段，拼成一个看板，管这叫“组合视图”。这就像把四个独立的 Excel 表用 VLOOKUP 连起来，然后说“我有了一套 ERP”。

真正的组合管理，是一个倒置的逻辑：它应该先定义组织的资源池、战略优先级、决策框架，然后把单项目作为资源分配的实例来管理。顺序不能反过来。从“项目聚合”到“组合治理”，这个认知的翻转，才是所有工具切换的前提。

如果你正在经历类似的痛苦，项目越跑越多，资源越来越不够用，跨项目的协调会议越开越长，但决策质量没有提升，我想给你三个可以直接落地的建议：

1. 先定义你的组合管理最小可行能力清单：在不依赖任何具体工具的情况下，写下你的 PMO 必须能回答的 5 个问题。比如：“当前最关键的三个风险点在哪？”“下个月资源最紧张的角色是什么？”“如果必须砍掉一个项目，砍哪个，为什么？”不要写超过 5 个，先聚焦最基本的信息需求。然后，看你的现有工具能不能实时回答这些问题。如果不能，记住这个 gap，它就是评估新工具的核心标准。
2. 选择在数据模型层面原生支持组合管理的平台：不要选择那种“你可以用插件拼出来”的方案。插件拼凑的组合管理能力，在项目数量超过 15 个以后一定会坍塌，不是功能不够，而是数据模型从根本上不支持。判断标准很简单：看这个工具在没有插件的情况下，能不能直接查看跨项目的资源占用，能不能在资源冲突时自动触发升级流程。
3. 为迁移找到一个真实的业务痛点作为锚点：不要为了“换掉外资工具”或者“追求新技术”去迁移。一定要找到那个让你的老板、你的团队切身体会到痛的场景，一次因为信息延迟造成的交付事故、一次因为资源计算错误引发的客户投诉、一份在高层会上被质疑可信度的组合报告。把迁移项目定义为“解决这个具体痛点”的工程，而不是“换一个工具”。

最后说一个我反复验证过的判断：在 2025 年的今天，国产工具在“组合管理”这个垂直领域的能力，已经不是“追赶”，而是在很多场景下完成了“定义权转移”。它们更理解中国中大型企业的研发组织形态，矩阵式结构、强资源的博弈、OKR 与项目交付的双轨制，这些是 Atlassian 的产品团队未必能深刻感知的使用场景。PingCode 在这个赛道上，不是 Jira 的平替，而是一个从底层模型开始就服务于“组合决策”的新物种。

如果你正在做类似的技术选型，记住一句话：不要问“这个工具能不能替代 Jira”，要问“这个工具能不能解决 Jira 从一开始就没解决的那个问题”。那个问题，才是你在这件事上花的所有时间和预算，真正应该被投向的地方。