项目组合平台试用评分表以“验证场景—试用结果—问题记录—结论建议”为主线设计：先按组合视图、立项排序、资源容量、预算跟踪、关口评审和决策留痕等场景设定评分项与权重，再为每项写明验证方法、判定标准和证据，试用中逐项记录实际结果与问题，最后按加权得分和阻断项给出采用、补测或放弃的结论。适用范围是投资组合决策类平台，ONES Plan 的组合视图与资源报表可作为试用对象之一。
要点总览（TL;DR）
- 评分表按“验证场景—试用结果—问题记录—结论建议”四组字段组织，用场景编号把评分、问题和结论串在同一张表里。
- 评分项从组合全景视图、立项排序、资源容量、预算跟踪、关口评审、决策留痕六个决策动作推导，权重按业务关键度分配，阻断项单独标注。
- 试用按准备、执行、取证、打分、汇总五步推进，每个评分项的得分都要对应到截图、导出文件或操作记录。
- 结论先看阻断项，再看关键场景得分，最后参考加权总分，输出采用、补测后复评、暂缓或放弃四类判断。
- 交付前逐项核对场景覆盖、判定标准、证据支撑、问题跟进和结论一致性，评分表、问题清单与证据一并提交评审。
评分表先定结构：一张表要装下哪些字段
评分表的结构决定了试用过程能否留下可复核的记录。建议把字段分成四组：表头信息、评分主体、过程记录和结论。四组字段放在同一张工作表里，用场景编号串联，避免评分、问题和结论分散在多个文件中。
| 字段组 | 字段 | 填写要求 |
|---|---|---|
| 表头信息 | 平台名称、试用版本、试用周期、试用人员与角色、试用环境 | 试用环境需注明 SaaS 或私有部署、数据是否为样例数据 |
| 评分主体 | 场景编号、验证场景、评分项、权重、验证方法、判定标准、得分、证据链接 | 每个评分项对应一条判定标准，证据链接指向截图、导出文件或操作记录 |
| 过程记录 | 试用结果、问题描述、问题等级、影响范围、责任方、跟进状态 | 问题等级建议分为阻断、重要、一般三档；跟进状态用待确认、已确认、已解决、遗留四类 |
| 结论 | 加权总分、阻断项、结论建议、后续动作 | 结论建议与得分、阻断项同时出现，后续动作写明责任人和时间 |
表头信息中的试用版本和试用环境需要固定下来，因为同一平台在不同部署方式下的权限、数据导入和报表表现可能不同。评分主体字段是表格的核心，场景编号建议采用“S01、S02”这类短编号，便于在问题清单和结论中引用。过程记录字段与评分主体分行并列，一个评分项可以对应多条问题记录，用编号关联即可。
按投资组合决策场景设置评分项与权重
评分项从组合决策的实际动作推导，而不是从产品功能菜单照搬。项目组合平台要回答的问题是：组合里有哪些项目、该优先做哪个、资源够不够、钱花到哪里、关口能不能过、决策过程能否追溯。围绕这六个动作展开，评分项才能对应试用者真正要验证的内容。
| 验证场景 | 可观察的评分项 | 验证方法 | 判定标准示例 | 建议权重 |
|---|---|---|---|---|
| 组合全景视图 | 多项目汇总展示、筛选与分组、状态标识 | 导入 10–20 个样例项目，按业务线、状态、负责人筛选 | 能在一次操作内得到所需组合视图，字段口径与业务定义一致 | 20% |
| 立项与优先级排序 | 立项信息字段、评分或排序模型、排序结果可调整 | 用季度立项清单走一遍排序，记录调整过程 | 排序依据可配置，结果可导出并附理由 | 20% |
| 资源与容量平衡 | 资源负载视图、冲突识别、工时数据来源 | 导入角色与工时样例，查看超负荷区间 | 能定位到具体角色和时段，数据口径可解释 | 15% |
| 预算与投入跟踪 | 预算录入、实际投入对比、偏差提示 | 录入预算与若干期实际数据，核对偏差计算 | 预算与实际可对比，偏差口径与财务定义一致 | 15% |
| 阶段关口评审 | 关口设置、评审记录、通过条件 | 为一个样例项目设置两个关口并完成一次评审 | 评审结论可记录，关口状态随结论变化 | 15% |
| 报表与决策留痕 | 报表导出、历史记录、权限可见范围 | 导出组合报表，回查一次历史决策记录 | 报表数据与视图一致，历史记录可追溯到人和时间 | 15% |
权重按业务关键度分配，上表比例可按组织实际调整。组合全景视图和立项排序通常决定平台能否支撑组合决策，权重可以更高；预算、关口等场景如果由其他系统承担，权重相应下调。阻断项单独标注，例如“无法导入现有项目清单”“组合视图数据口径与财务口径冲突”，这类问题出现时不参与加权平均，直接进入结论判断。
评分刻度建议统一为 1–5 分，并写明每档含义：5 分表示按判定标准完整达成且有证据；4 分表示达成但存在不影响结论的小问题；3 分表示部分达成，需要变通操作；2 分表示仅能演示，无法在样例数据上完成；1 分表示未实现或结果不可用。刻度含义写在表头说明中，所有评分人使用同一套解释。
试用执行步骤：从准备到打分
试用执行按准备、操作、取证、打分、汇总五步推进，每一步都有明确的输入和完成标志，避免试用结束时只剩印象分。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 准备 | 组合决策场景清单、样例项目与工时数据、角色分工表 | 确定试用周期与环境，准备 10–20 个覆盖不同状态的项目样例，编写每个场景的操作脚本 | 样例数据集、场景脚本、分工表 | 脚本经组合管理者确认，样例数据可导入 |
| 执行 | 场景脚本、评分表 | 按脚本逐场景操作，边操作边在评分表记录实际结果 | 逐场景的试用结果记录 | 每个评分项至少有一条结果记录 |
| 取证 | 操作过程 | 截图关键界面、导出报表、记录操作路径和参数 | 证据文件与链接 | 每个评分项的得分都能对应到证据 |
| 打分 | 判定标准、证据 | 评分人独立打分，再开合议会对差异项讨论定分 | 各评分项最终得分 | 差异超过 1 分的评分项已完成合议并记录理由 |
| 汇总 | 得分、问题清单 | 计算加权总分，按等级整理问题，标注阻断项 | 加权得分表、问题清单、结论草稿 | 结论评审会前材料齐备 |
执行阶段容易出现的偏差是只验证顺利路径。建议每个关键场景准备一条异常路径脚本，例如导入字段缺失的项目清单、给同一角色分配超额任务、在关口评审中驳回一次，观察平台如何处理异常和记录原因。这些结果往往比正常路径更能说明平台是否适合长期使用。
角色分工与各自交付物
评分表由多人共同完成，单人打分容易把个人操作习惯当成平台能力。角色分工按“定义场景、执行验证、专业判断、环境保障、记录归档”划分。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 组合管理者 | 定义验证场景与权重，主持结论评审 | 场景与权重清单、结论建议 |
| 项目经理/项目集经理 | 按脚本执行组合视图、立项排序、关口评审场景并记录结果 | 场景执行记录、评分初稿 |
| 财务或资源管理角色 | 验证预算跟踪、资源容量与工时口径 | 预算与容量场景的验证结论、口径差异说明 |
| IT 或平台管理员 | 准备试用环境，验证权限、数据导入与集成条件 | 环境说明、导入与权限验证记录 |
| 记录人 | 维护问题清单、归档证据、跟踪问题状态 | 问题清单、证据归档目录 |
组合管理者不直接给所有评分项打分，其职责是保证场景覆盖和权重合理，并在合议时对分歧作出判断。财务或资源角色对预算与容量场景的判定标准有最终解释权，避免用项目管理口径替代财务口径。记录人需要在每次试用结束后更新问题状态，确保结论评审时看到的是最新记录。
填写示例：一个组合优先级场景怎么打分
以下示例演示季度立项评审中的优先级排序场景如何落到评分表的一行。示例中的平台表现和得分为演示情景，用于说明填写结构。
| 字段 | 填写内容 |
|---|---|
| 场景编号 | S02 立项与优先级排序 |
| 评分项 | 排序依据可配置，排序结果可导出并附理由 |
| 权重 | 20% |
| 验证方法 | 导入 12 个季度立项申请，按战略契合度、投入规模、风险三项设置排序依据，调整其中两个项目的评分后重新排序，导出排序结果 |
| 判定标准 | 排序依据可由业务人员配置；调整评分后排序结果同步变化；导出结果包含排序理由和评分明细 |
| 实际结果 | 排序依据可配置，调整评分后结果同步更新；导出文件包含评分明细，排序理由需在项目描述中手工填写，未自动带入导出表 |
| 得分 | 4 分（达成主要判定标准，理由字段需手工补充） |
| 证据链接 | 排序配置截图、调整前后对比截图、导出文件 |
| 问题记录 | 问题等级：一般；影响范围：立项评审材料整理；责任方：平台管理员确认是否有字段配置方案；跟进状态：待确认 |
这一行的结论是：该场景得分 4 分，未触发阻断项，场景判断为“可用，需在评审流程中补充理由字段的填写规范”。其他场景按同样结构填写：先写验证方法和判定标准，再写实际结果和得分，最后把发现的问题按等级记录并指定跟进方。得分与问题记录同时存在，结论评审时才能区分“能力缺失”和“配置或流程可弥补的差异”。
在组合视图和资源投入这类场景中，ONES Plan 提供多项目总览、可自定义项目属性，以及资源报表和工时数据，可作为试用时对照评分项观察的对象；具体视图层级、筛选口径和报表字段仍需在试用环境中逐项核验并记录证据。
结论建议怎么写：从得分到采用判断
结论建议由加权总分、关键场景得分和阻断项三部分共同决定，单看总分容易掩盖关键场景的短板。建议先看阻断项，再看关键场景，最后参考加权总分。
- 阻断项规则：出现任一阻断项，结论直接记为“不通过”或“补测后复评”，不因总分高而改为采用。阻断项需写明具体表现、影响和复测条件。
- 关键场景规则：组合全景视图和立项排序作为关键场景，任一场景得分低于 3 分，结论至少为“补测后复评”。
- 总分参考：加权总分达到 4 分及以上且无阻断项，可给出“采用”；3–4 分之间结合关键场景判断“采用并附改进条件”或“补测”；低于 3 分一般记为“暂缓”或“放弃”。
结论类型建议固定为四类：采用、补测后复评、暂缓、放弃。采用类结论附实施条件和待办事项；补测类结论附补测清单、复评时间和责任人；暂缓类结论写明触发重新评估的条件；放弃类结论记录主要原因，便于后续选型参考。商务条件、版本差异和部署方式确认属于后续动作，与能力结论分开写，避免把未确认的商务信息混入评分结论。
完成检查：评分表交付前的核对项
评分表提交结论评审前，由记录人和组合管理者共同核对以下条目，每条都要能给出“是”或具体缺口。
- 场景覆盖是否对应组合决策的六个关键动作，缺失的场景是否说明了原因。
- 每个评分项是否都有验证方法和判定标准，判定标准是否可观察、可复核。
- 每个得分是否都有证据支撑，证据链接是否可打开。
- 问题是否记录了等级、影响范围、责任方和跟进状态，阻断项是否单独标出。
- 结论是否与加权得分、关键场景得分和阻断项一致，是否存在总分高但关键场景不达标却判采用的情况。
- 评分人是否覆盖组合管理、项目执行、财务或资源、平台管理四类角色，合议记录是否留存。
- 表头信息是否完整，试用版本和试用环境是否写明，样例数据与真实数据的边界是否清楚。
核对完成后，评分表、问题清单和证据归档一并提交结论评审。评审输出采用、补测、暂缓或放弃的明确结论，并指定后续动作的责任人和时间，试用工作才算闭环。
常见问题
试用周期短、场景多，评分表要不要一次覆盖全部场景？
可以分批。建议把组合全景视图和立项排序作为第一批必测场景，这两项直接决定平台能否支撑组合决策；资源容量、预算跟踪、关口评审和决策留痕放在第二批。分批时在表头写明本轮覆盖的场景编号和未覆盖原因，结论建议里注明“本轮未覆盖场景需补测”，避免把部分场景的得分当成整体结论。
多个评分人给出的分数差异很大，怎么处理？
先检查差异来源：是判定标准理解不同，还是操作路径不同导致看到的结果不一样。对差异超过 1 分的评分项，由评分人各自出示证据，在合议会上对照判定标准逐条讨论，定分后把理由写进问题记录。若差异来自判定标准本身表述模糊，应回头修订判定标准并重新打分，而不是简单取平均。
试用中发现的问题，哪些应该算阻断项？
阻断项指直接影响组合决策能否成立的问题，例如现有项目清单无法导入、组合视图的数据口径与财务口径冲突、关键场景无法在样例数据上完成操作。一般问题如导出文件缺少某个字段、界面操作步骤偏多，记录等级和跟进状态即可，不进入阻断判断。阻断项出现时结论直接记为不通过或补测后复评，并写明复测条件。
评分表里的证据需要保留到什么程度？
每个评分项的得分至少对应一份可打开的证据：关键界面截图、导出文件或带参数的操作记录。截图要能看出操作对象和结果，导出文件保留原始格式，操作记录写明路径和输入数据。证据按场景编号归档，结论评审后与评分表一并留存，便于后续复评时对照。
试用结论给出“采用”后，还需要确认哪些事项？
能力结论与商务、实施条件分开处理。采用类结论附实施条件和待办事项，包括版本与部署方式确认、权限与数据导入方案、与现有系统的集成条件、上线时间与责任人。这些事项未确认前，评分结论只代表能力层面通过，不代表采购与实施已经就绪。
