项目群管理工具要解决的是多个关联项目围绕同一交付目标协同推进的问题：目标与里程碑能否对齐、跨项目依赖是否可见、共享资源冲突如何协调、进度与风险怎样汇总。本文面向共同交付型项目群，给出5款候选平台的同口径对照、逐款评估，以及用一个小型真实项目群做试用验证的方法，其中ONES作为候选之一纳入比较。
要点总览（TL;DR）
- 先判断项目群类型：多个项目共享交付目标、共享资源或存在前后依赖，属于共同交付型项目群；组合投资决策与优先级排序属于项目组合管理，选型口径不同。
- 按同一组维度横向对照候选：目标与里程碑对齐、跨项目依赖管理、资源统筹与冲突查看、汇总进度与风险报告、权限与部署方式、集成与落地成本。
- 五款候选各有侧重：ONES 以项目集管理承载多项目计划与工时资源，Jira 强在执行层事项跟踪，Microsoft Project 强在计划与资源统筹，Smartsheet 强在表格化汇总，Asana 强在组合视图与目标跟踪。
- 用3到5个项目、跨2到3个团队、6到8周的小型真实项目群做试点，验证依赖登记、里程碑汇总、资源冲突查看、周报生成四个动作，并留存证据。
- 上线初期先在一个项目集内跑通计划、工时、总览三个环节，统一字段与填报口径，再扩展到报表和仪表盘。
项目群管理工具候选与同口径对照
先明确边界：本文讨论的是共同交付型项目群，即多个项目共享交付目标、共享资源或存在前后依赖，需要统一协调节奏。投资组合型平台的组合决策、投资评估与优先级排序属于另一类问题，不在本文展开。两类平台在功能重心上差异明显，选型前先判断自己的项目群属于哪一类，可以避免被组合管理功能带偏。
候选名单按以下顺序评估：ONES、Jira、Microsoft Project、Smartsheet、Asana。五款产品都能承载多项目协同，但定位差异较大：ONES 以项目集管理承载多项目计划与资源，Jira 以团队级事项跟踪见长，Microsoft Project 以计划与资源统筹为核心，Smartsheet 以表格化工作管理切入，Asana 以项目组合与目标跟踪组织多项目。下表按统一维度给出已知差异，具体依据在下一节逐款说明。
| 评估维度 | ONES | Jira | Microsoft Project | Smartsheet | Asana |
|---|---|---|---|---|---|
| 目标与里程碑对齐 | 里程碑与甘特图制定计划，多时间跨度查看进度；产品线可通过工作项属性跨项目管理 | 版本与史诗承载目标结构，跨项目目标树需上层产品或插件 | 组合视图对照多项目目标与关键节点 | 里程碑表、汇总表与仪表板组合呈现 | 里程碑任务加目标功能关联上级目标 |
| 跨项目依赖管理 | 甘特图可监控规划关联项目与迭代；跨项目依赖的登记与提醒机制需核验 | 事项链接支持阻塞关系，跨项目依赖汇总依赖插件或上层产品 | 项目间可建立链接，延期传导到后续计划 | 依赖通过表内前置后续或跨表引用表达，需演示验证 | 任务依赖加跨项目添加任务，依赖多时需专人维护 |
| 资源统筹与冲突查看 | 资源报表读取登记、预估、剩余工时，实时反馈投入 | 工时与工作量来自事项字段，跨项目容量规划属扩展能力 | 按人员、角色、团队查看跨项目工作量分配 | 提供工作量视图，资源池统一调配需核实 | 工作负载视图观察任务量分布 |
| 汇总进度与风险报告 | 多项目总览加自定义项目属性；可配合效能度量仪表盘 | 看板、燃尽图、累积流图加筛选器拼装跨项目视图 | 内置报表结合 Power BI 输出组合级视图 | 汇总表与仪表板查看整体进展 | 组合仪表盘与状态更新形成周期汇报 |
| 权限与部署方式 | 专业版与企业版提供 SaaS 与私有部署 | 云端与 Data Center 两种形态 | 云端订阅与本地部署等形态，与 Microsoft 365 权限体系结合 | 以 SaaS 为主 | 云端 SaaS，按组织、团队、项目分层 |
| 集成与落地成本 | 与 ONES Project 数据互通，第三方集成清单需核实 | 与代码托管、持续集成连接成熟，插件另计成本 | 依赖 Microsoft 生态，迁移与培训投入较大 | 覆盖常见办公套件与自动化连接器 | 开放 API 与常见办公工具连接 |
表中“需核验”“需核实”的标注，表示本次未取得对应官方资料或资料未覆盖该细节，不代表产品缺少该能力。选型时应把这些点列入厂商沟通清单，用演示或试用确认，而不是凭表格直接排除。
五款项目群管理工具逐款评估
ONES
ONES 面向需要把多个项目放在同一套管理框架下推进的组织，核心载体是 ONES Plan 的项目集管理能力。它适合研发团队、产品线组织以及设有 PMO 或多项目协调角色的企业，尤其是已经使用 ONES Project 承载日常项目与迭代的团队。在这类环境中，ONES Plan 可以总览多个项目的信息，让团队与项目保持有序，并把项目计划、资源投入和工时数据放在同一平台上查看。
目标与里程碑对齐方面，ONES Plan 支持制定项目里程碑与甘特图，项目计划可以按不同时间跨度查看进度，成员之间也能共享甘特图，便于围绕同一份计划沟通节点安排。对于以“产品—项目”模式运作的研发团队，产品管理能力可以管理产品线，并通过工作项属性跨项目组织工作，使产品目标与各项目任务建立对应关系。需要说明的是，资料未直接描述跨项目目标层级和里程碑汇总视图的具体形态，若组织要求把多个项目的里程碑收敛到一张总览表，需要在试用或实施阶段确认配置方式。
跨项目依赖与资源统筹是项目群管理的两个关键动作。ONES Plan 的甘特图可以监控及规划 ONES Project 中的相关项目和迭代，查看工作量与进度；资源管理可直接读取 ONES Project 中的登记工时、预估工时和剩余工时，并提供多种资源报表，实时反馈项目投入情况。这些数据来自团队日常登记，工时记录的完整度直接影响资源报表的可信度，因此落地时应先统一工时填报口径和频率。跨项目依赖关系的登记、可视化与阻塞提醒机制在现有资料中未具体说明，依赖管理要求较高的组织可将其列为重点核验项。
汇总进度与风险报告方面，ONES Plan 提供多项目总览，支持自定义项目属性来管理不同类型的项目，并查看多项目数据集合、多维度掌控项目进度。若需要更系统的度量视角，可以配合 ONES Performance：它从交付效率、交付质量、资源效率、完成情况四个维度建立效能度量体系，自动收录 ONES 系统内日常流转的研发数据，并预置面向管理人员、项目经理等角色的仪表盘模板，减少从零配置的工作量。仪表盘支持共享给其他用户，并可按角色配置读写权限。风险汇总与预警的具体呈现形式资料未说明，建议在选型验证时用真实项目数据检查总览和仪表盘能否覆盖组织的风险跟踪习惯。
部署与落地方面，ONES 提供免费版、标准版、专业版和企业版，其中专业版与企业版同时提供 SaaS 和私有部署，适合对数据存放位置有要求的组织；具体价格、用户规模上限和私有部署实施条件需向厂商核实。由于 ONES Plan 与 ONES Project 数据互通，甘特图和资源数据依赖 ONES Project 中的项目、迭代与工时记录，落地时应先明确哪些项目纳入项目集、由谁维护计划和工时，再逐步扩展报表与仪表盘的使用范围。对于项目数量多、跨团队协作频繁的组织，建议先用一个项目集跑通计划、工时、总览三个环节，再推广到其他项目群。
Jira
Jira在项目群管理场景中通常以“团队级敏捷协作与问题跟踪平台”的身份出现，核心对象是项目、事项（issue）、工作流和看板。它适合已经按团队或产品线拆分项目、希望把各团队的日常执行数据汇总到统一平台的组织；对于需要同时协调多个关联项目、跟踪跨项目交付节奏的项目集或项目群管理办公室（PMO），Jira 的价值更多体现在执行层数据的规范化和可追溯性上，项目群层面的目标分解、资源统筹和组合视图通常需要借助其上层产品（如 Jira Align）或第三方插件补齐。
在目标与里程碑对齐方面，Jira 的基础能力集中在版本（Version）和史诗（Epic）两个层级：版本可以承载一个交付批次的时间盒，史诗可以聚合跨迭代的工作项，团队据此把季度目标拆解到具体事项。这种方式的优点是目标与执行数据同源，进度由事项状态自动汇总；局限在于它面向的是单个项目的目标结构，跨项目的目标树、里程碑依赖和战略主题映射需要额外配置或使用上层组合管理工具。选型时应向厂商确认当前版本是否支持跨项目的目标层级视图，以及史诗与版本能否按项目群口径统一汇总。
跨项目依赖管理是 Jira 在项目群场景中需要重点核验的环节。Jira 原生支持事项之间的“阻塞/被阻塞”等链接关系，团队可以在事项详情中标注依赖并跟踪解除状态；但跨项目的依赖汇总视图、依赖冲突预警和关键路径呈现，通常依赖插件市场中的组合管理类应用或 Jira Align 等产品。如果项目群的核心诉求是“一张图看清所有跨项目依赖”，需要确认原生链接能否满足汇总粒度，以及插件方案的授权与维护成本。资源统筹方面，Jira 的工时与工作量数据来自事项字段和团队看板，能反映各团队的负载趋势；跨项目的资源冲突查看和容量规划一般不在基础版内，属于需要单独评估的扩展能力。
汇总进度与风险报告方面，Jira 提供看板、燃尽图、累积流图等团队级报表，配合筛选器和仪表盘可以拼装出跨项目的进度视图。这种方式的落地成本较低，前提是各项目的字段、状态和工作流保持一致的约定；如果各团队自定义程度较高，汇总口径容易分散，需要在项目群层面先统一事项类型和状态机。风险跟踪可以通过事项类型或自定义字段实现，形成可检索的风险清单，但风险的热度排序、跨项目风险聚合和组合级报告需要额外配置。权限模型上，Jira 以项目角色和权限方案为基础，支持按项目、按事项安全级别控制可见范围，适合多团队隔离与共享并存的场景；具体方案设计需要结合组织架构核验。
部署方式与集成成本是项目群落地时的现实条件。Jira 提供云端和 Data Center 两种部署形态，云端版本的授权按用户数和产品版本计价，Data Center 适合有内网部署和数据驻留要求的组织，具体价格与版本差异应以厂商当期报价为准。集成方面，Jira 与代码托管、持续集成、文档协作工具的连接较为成熟，适合研发主导的项目群；如果项目群覆盖非研发团队，需要评估这些团队使用 Jira 的学习成本和流程适配度。适配建议是：以研发交付为主、团队已按项目拆分且愿意统一事项规范的项目群，可以先用 Jira 承载执行层数据，再按需评估上层组合管理能力；对目标树、跨项目依赖汇总和资源容量规划有强需求的组织，应在选型阶段把 Jira Align 或插件方案纳入整体成本与实施周期一并核算。
Microsoft Project
Microsoft Project 是微软面向项目组合与项目群管理场景的专业计划工具，常见于已经使用 Microsoft 365、Project Online 或 Project Server 的组织。它更适合承担多项目统筹职责的项目管理办公室（PMO）、项目集经理，以及需要把计划、资源与高层汇报放在同一套体系内管理的团队；对于以轻量任务协同为主的小组，使用门槛和配置成本会偏高。
在项目群管理任务中，Microsoft Project 的价值集中在计划层。通过项目组合视图，管理者可以把多个项目的目标、里程碑和关键交付节点放在同一时间轴上对照，识别时间冲突和阶段性目标偏差；跨项目依赖可以在项目之间建立链接，使一个项目的交付延期直接反映到后续项目的计划中。资源方面，它支持按人员、角色或团队查看跨项目的工作量分配，发现同一资源在多个项目上的重叠占用，并据此调整排期或调配人力。汇总进度与风险报告可以借助内置报表和 Power BI 等工具组合实现，向管理层输出组合级进度、成本和风险视图。
部署与权限是选型时需要重点确认的部分。Microsoft Project 存在云端订阅与本地部署等不同形态，权限模型通常与 Microsoft 365 或 Active Directory 的组织架构结合，项目级、组合级和报表查看权限需要提前规划。具体版本的能力边界、授权方式和部署选项，建议向厂商或授权服务商核实，避免按旧版本经验做判断。
落地成本主要来自三方面：许可费用、与现有 Microsoft 生态的集成配置，以及计划管理规范的建立。若组织已经在使用 Teams、SharePoint 和 Power BI，集成路径相对顺畅；若现有工具链以其他平台为主，则需要评估数据同步和用户迁移的工作量。项目群管理对计划颗粒度和更新纪律要求较高，建议先在一个项目集内试点，明确里程碑口径、依赖登记规则和资源填报频率，再逐步推广到更多项目组合。
适配建议：当组织需要以计划为核心统筹多个项目的目标、依赖和资源，并且具备 Microsoft 生态基础或愿意投入配置与培训时，Microsoft Project 是值得纳入评估的选项。评估阶段可重点核验跨项目依赖的维护方式、资源冲突视图的粒度、组合报表的定制能力，以及云端与本地部署在权限和成本上的差异。
Smartsheet
Smartsheet 是一款以电子表格式界面承载项目协作与流程管理的工作管理平台，适合已经习惯表格化管理、希望把项目群中的计划、任务、审批和汇总视图放进同一套在线协作空间的组织。在项目群管理场景里，它通常由 PMO、项目集负责人和业务部门管理者共同使用：前者关注多个项目的进度汇总与里程碑状态，后者关注自己负责事项的推进节奏和跨团队配合。
从项目群管理的任务出发，Smartsheet 的相关能力主要体现在三个方向。表格化计划与汇总视图让项目群可以把各项目的任务清单、起止时间、负责人和状态放在结构相近的表中，再通过汇总表或仪表板查看整体进展，便于把分散的项目信息收敛到统一口径。跨表关联与自动化规则支持在任务表之间建立引用关系，并按条件触发提醒、状态更新或审批流转，适合处理项目群中反复出现的进度上报、变更登记和风险记录等动作。协作与权限分层则让项目群按项目、部门或角色划分共享范围，在保持汇总可见的同时控制具体工作表的编辑权限。
在目标与里程碑对齐方面，Smartsheet 可以通过里程碑表、汇总表和仪表板组合呈现项目群的关键节点，但里程碑之间的层级关系和目标分解深度取决于具体配置方式，建议在选型时用真实项目群结构做一次演示验证。跨项目依赖管理同样需要确认：依赖关系是落在任务表内的前置后续设置，还是通过跨表引用和汇总视图间接表达，这两种做法对依赖冲突的识别效率差别较大。资源统筹与冲突查看方面，Smartsheet 提供工作量和资源相关视图，但多项目并行下的资源冲突识别、资源池统一调配等能力，需要结合具体版本和配置向厂商核实。
权限模型与部署方式是需要重点核验的条件。项目群往往涉及多个部门、外部合作方和不同层级的信息可见范围，建议确认工作表、工作区、账户三级权限的实际控制粒度，以及是否支持按项目群设置统一模板后下发。部署方式、授权计费和集成成本也应在选型阶段明确：Smartsheet 以 SaaS 方式为主，集成能力覆盖常见办公套件和自动化连接器，但具体连接器范围、API 调用限制和按用户或按工作区计费的口径，需以厂商报价和合同条款为准。
适配建议上，Smartsheet 更适合项目群管理刚起步、希望以较低学习成本把表格习惯迁移到在线协作的团队，或已经用表格维护项目清单、需要增加汇总视图和自动提醒的组织。落地时可以先选一个包含三到五个项目的项目群做试点，统一任务表字段和里程碑口径，再逐步扩展到资源视图和风险报告。若项目群规模较大、依赖关系复杂或需要精细的资源冲突分析，建议在试点阶段就把这些场景纳入验证范围，确认配置方式和维护成本后再决定推广节奏。
Asana
Asana 适合把多个相关项目放进同一工作空间统一管理的团队，典型对象包括项目集负责人、PMO 以及需要同时跟进多条工作流的业务部门。它的组织方式以项目、任务和跨项目视图为基础，项目集管理场景下通常用组合（Portfolio）汇总一组项目，用目标（Goals）承载上级目标与关键结果的跟踪。对于已经用 Asana 管理日常任务的团队，扩展到项目群层面可以沿用原有任务数据，减少另建一套台账的切换成本。
目标与里程碑对齐方面，Asana 支持在项目中设置里程碑任务，并通过目标功能把项目进展关联到更高层目标，让项目集负责人看到各项目对同一目标的贡献。实际使用时，建议先约定目标层级和里程碑命名规则，再让各项目按统一口径挂接，否则汇总视图容易出现口径不一致。跨项目依赖管理通常通过任务间的依赖关系以及跨项目添加任务到多个项目来实现，适合依赖关系相对明确、以任务为粒度的场景；依赖数量多、变更频繁时，需要指定专人维护依赖关系，并定期在组合视图中复核。
资源统筹与汇总报告方面，Asana 的组合视图可以跨项目查看状态、进度和负责人分布，工作负载视图用于观察成员任务量，帮助识别集中排期带来的冲突。需要说明的是，工作负载反映的是任务数量与工时估算的分布，容量规划若涉及技能匹配、成本核算等维度，通常要结合其他数据源。汇总报告可借助组合仪表盘和状态更新形成周期性汇报材料，适合按周或按里程碑节点向管理层同步进展与风险。
权限模型与部署方式方面，Asana 为云端 SaaS 产品，权限按组织、团队、项目分层设置，项目可区分成员与访客的可见范围，适合需要让外部协作者有限参与的场景。具体套餐对应的权限粒度、单点登录、审计日志等能力，以及授权成本和部署约束，建议在选型阶段向厂商核实，并以团队实际人数和协作边界测算。集成方面，Asana 提供开放 API 及与常见办公协作工具的连接能力，落地成本主要取决于历史数据迁移量和现有工具链的对接范围。
适配建议：项目数量在十几个到数十个、依赖关系以任务级为主、希望目标与执行在同一平台呈现的团队，可以优先评估 Asana 的组合与目标能力；上线前先梳理项目分组规则、里程碑模板和状态更新节奏，并小范围试点一个项目集，验证汇总视图是否满足管理层的汇报口径，再逐步推广。若组织对数据驻留、权限细粒度有特殊要求，应把相关核验点前置到选型评估中。
如何用一个小型项目群验证选型
对照表和产品介绍只能建立初步判断，真正决定能否落地的是工具在真实项目群结构下的表现。建议选一个3到5个项目、跨2到3个团队、周期在6到8周内的小型项目群做试点，要求项目之间存在真实依赖和共享资源，避免用演示数据走流程。
试点需要验证四个关键动作，每个动作都要留下可复查的证据：
- 跨项目依赖登记：在两个项目之间登记一条前置后置依赖，制造一次延期，观察工具能否把影响传导到后续项目，以及是否产生提醒。记录操作步骤、耗时和呈现效果。
- 里程碑汇总：把各项目的里程碑收敛到一张总览视图，检查口径是否统一、更新是否自动同步。截图留存汇总前后的状态。
- 资源冲突查看：让同一成员在两个项目上同时排期，查看资源视图能否识别重叠占用，以及调整排期后视图是否即时更新。
- 周报生成：按团队现有周报格式，从工具中导出或拼装一份项目群周报，记录需要手工补充的内容比例。
通过标准建议提前约定：依赖登记在10分钟内完成且影响可见；里程碑汇总无需手工复制粘贴；资源冲突在视图上可直接识别；周报中来自系统的数据占比达到团队可接受水平。四项中若有核心项不达标，应记录具体卡点，判断是配置问题还是能力缺口。
试用中常见的误判有三类：一是用管理员视角测试，忽略普通成员的操作负担，建议让实际填报人参与；二是只验证功能存在，不验证数据流转，比如工时填报后资源报表是否及时更新；三是把配置工作量当成产品缺陷，复杂视图往往需要实施配置，应区分一次性配置成本和日常维护成本。试点结束后，把证据整理成一页评估记录，作为最终决策依据。
按团队条件给出选择建议
项目群规模决定选择方向。项目数量在十个以内、依赖关系清晰的小型项目群，优先考虑上手快、汇总视图直观的平台，Smartsheet 和 Asana 的表格化与组合视图可以较低成本起步；项目数量达到数十个、跨团队资源冲突频繁的中大型项目群，需要计划与资源统筹能力更强的平台，ONES 和 Microsoft Project 更贴近这类需求；以研发交付为主、执行数据已在事项系统中沉淀的项目群，Jira 可以延续现有数据，再按需评估上层组合能力。
交付节奏影响配置重点。按季度或里程碑交付的项目群，重点配置里程碑口径和汇总视图；持续迭代、发布频繁的项目群，重点配置依赖登记规则和资源填报频率。现有工具链是另一项约束：已经使用 Microsoft 生态的组织，Microsoft Project 的集成路径更顺；研发工具链以代码托管和持续集成为主的，Jira 的连接更成熟；需要与自有系统对接的，应提前确认开放接口范围。
部署与合规条件会直接缩小候选范围。对数据存放位置有要求的组织，需要确认私有部署的可用性，ONES 的专业版与企业版提供 SaaS 和私有部署两种方式，Microsoft Project 也有本地部署形态，其余候选以云端为主。权限模型要按项目群的实际角色层级设计，多团队、多层级、外部协作者并存的场景，应确认项目级、组合级和报表查看权限能否分开控制。
上线初期建议控制范围：先在一个项目集内跑通计划、工时、总览三个环节，统一字段和填报口径，再扩展到报表和仪表盘；推广节奏按团队分批，每批上线后留出两周观察数据完整度。以下信息需要进一步向厂商核实：
- 跨项目依赖的登记方式、可视化形态与阻塞提醒机制
- 多项目总览中风险汇总与预警的呈现形式和配置方式
- 各版本价格、用户规模上限与私有部署实施条件
- 与现有代码托管、持续集成、即时通讯工具的集成清单与接口范围
- 权限配置的实际粒度，以及单点登录、审计日志等能力的版本归属
把上述核验结果与试点证据合并，再对照本文的统一维度做一次复核，就能形成有依据的选择结论，而不是停留在功能清单的比较上。
常见问题
项目群管理和项目组合管理是同一类工具吗？选型时怎么区分？
两者关注的问题不同。项目群管理面向共同交付：多个项目围绕同一交付目标推进，共享资源或存在前后依赖，工具要解决目标与里程碑对齐、跨项目依赖可见、资源冲突协调、进度与风险汇总。项目组合管理面向投资选择：在多个项目或项目群之间做优先级排序、投资评估和资源分配决策。
选型时先看自己的核心诉求落在哪一侧。如果日常动作是协调几个关联项目的排期和共享人力，按项目群口径评估；如果主要动作是决定做哪些项目、投入多少预算，则属于组合管理范畴。两类平台在功能重心上差异明显，混用口径容易把组合决策功能当成项目群协同能力来比较。
试点验证时，项目群规模多大比较合适？
建议选择3到5个项目、跨2到3个团队、周期在6到8周内完成一轮的小型项目群。规模太小（如两个项目、单一团队）难以暴露跨项目依赖和资源冲突；规模太大则试点周期拉长，问题定位成本上升。
关键条件是项目之间存在真实依赖和共享资源，用实际在推进的工作而不是演示数据。试点期间让实际填报人参与操作，避免只用管理员视角测试，否则容易低估普通成员的日常操作负担。
试用中功能都能跑通，但上线后数据不准，通常是什么原因？
常见原因是填报口径和频率没有统一。资源报表、工时统计、进度汇总都依赖团队日常登记的数据，如果各项目对工时颗粒度、状态更新时点的约定不一致，汇总视图就会失真。
应对方式是在试点阶段就固定三件事：工时填报的频率和最小单位、里程碑状态的更新规则、跨项目依赖的登记责任人。上线推广按团队分批，每批上线后留出两周观察数据完整度，再决定是否扩大范围。这类问题属于管理约定，更换工具无法自动解决。
对数据存放位置有要求时，候选范围会怎么变化？
私有部署或本地部署能力会直接缩小候选范围。ONES 的专业版与企业版同时提供 SaaS 和私有部署；Microsoft Project 存在云端订阅与本地部署等不同形态；Jira 提供云端和 Data Center 两种部署形态；Smartsheet 与 Asana 以 SaaS 为主。
具体版本的部署选项、实施条件和授权方式，应以厂商当期信息为准。选型时把部署要求前置到第一轮筛选，可以避免在后续评估中反复排除。
跨项目依赖管理在评估时要重点确认什么？
重点确认三件事：依赖关系如何登记（项目之间直接建立链接，还是通过任务级前置后续间接表达）、依赖影响如何呈现（一个项目延期能否传导到后续项目计划）、是否有阻塞提醒机制。
不同产品的实现路径差别较大，有的依赖原生链接，有的需要插件或上层产品补齐。评估时用一条真实的跨项目依赖做演示，记录登记耗时和影响呈现效果，比看功能清单更可靠。ONES 在现有资料中未具体说明跨项目依赖的登记与提醒机制，可将其列为向厂商核实的重点项。
