项目组合平台试用记录模板应覆盖五组字段：试用基本信息、验证场景与用例、试用结果、问题记录、评分与结论建议。模板以表格为主，适合在初筛和深入验证两个阶段记录同一候选产品的表现，让不同评估人填出的记录可以横向比较，并据此形成是否进入下一轮的结论。
要点总览（TL;DR）
- 模板按五组字段组织：试用基本信息、验证场景与用例、试用结果、问题记录、评分与结论建议，记录区与评分区可直接复制使用。
- 必填字段保证记录能支撑决策：基本信息、场景与预期结果、是否通过、实际表现、证据位置、问题描述与严重程度、评分与适配结论；初筛阶段可收窄评分维度。
- 评分采用统一维度与权重，评估人先独立打分再汇总分歧，权重在试用启动前确定、过程中不调整。
- 填写示例展示从场景到结论的闭环：场景定义预期结果，结果区给出判定与证据，问题区记录偏差，评分区折算分数并落到后续动作。
- 多轮试用后按反馈增删字段、复核评分锚点、统一模板版本，并将空白模板、填写记录与证据材料打包归档复用。
可复制空白试用记录表
下表分为记录区与评分区两部分，可直接复制到文档或表格工具中使用。记录区按一次试用填写一份，评分区由各评估人分别填写后汇总。表格中的“【必填】”“【选填】”标注与第三节的必填对照表一致。
记录区：试用基本信息
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 试用单位【必填】 | 填写组织或部门全称 | |
| 评估负责人【必填】 | 填写姓名与角色 | |
| 试用周期【必填】 | 起止日期，精确到日 | |
| 试用版本【必填】 | 产品版本、套餐或部署方式 | |
| 参与角色【必填】 | 列出参与试用的角色及人数 | |
| 试用环境与数据【选填】 | 说明使用演示数据还是脱敏真实数据 | |
| 厂商支持方式【选填】 | 如培训、答疑、实施协助 |
记录区：验证场景与用例
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 用例编号【必填】 | 如 UC-01，便于结果与问题引用 | |
| 场景名称【必填】 | 一句话描述要验证的组合管理动作 | |
| 对应组合管理动作【必填】 | 如组合总览、优先级排序、资源分配、进度跟踪、评审汇报 | |
| 前置数据【必填】 | 需要的项目数量、人员、工时或预算数据 | |
| 操作步骤【必填】 | 按顺序写出关键操作 | |
| 预期结果【必填】 | 可观察、可判断的完成标志 | |
| 执行人【选填】 | 实际执行该用例的人 |
记录区：试用结果
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 用例编号【必填】 | 与场景区编号对应 | |
| 是否通过【必填】 | 通过 / 部分通过 / 未通过 | |
| 实际表现【必填】 | 记录实际看到的结果，与预期结果逐条对照 | |
| 证据位置【必填】 | 截图编号、录屏时间点或文档链接位置 | |
| 耗时与操作步数【选填】 | 用于比较不同产品的操作效率 |
记录区：问题记录
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 问题编号【必填】 | 如 ISS-01，与用例编号关联 | |
| 问题描述【必填】 | 写清现象、出现位置和复现条件 | |
| 影响范围【必填】 | 影响的角色、场景或数据范围 | |
| 严重程度【必填】 | 阻断 / 严重 / 一般 / 建议 | |
| 临时处理【选填】 | 试用中采用的替代操作 | |
| 待厂商确认事项【选填】 | 需要厂商答复的能力边界或配置问题 |
评分区：评分与结论建议
| 评分维度 | 权重 | 评分（1–5） | 评分依据 |
|---|---|---|---|
| 组合总览与数据汇总 | |||
| 计划与进度管控 | |||
| 资源与工时管理 | |||
| 评审与汇报支持 | |||
| 易用性与学习成本 | |||
| 与现有工具集成 | |||
| 加权总分 | 合计 100% | ||
| 适配结论【必填】 | 推荐进入下一轮 / 有条件推荐 / 不推荐 | ||
| 后续动作【必填】 | 如补充验证、向厂商确认、安排演示、结束评估 | ||
各字段的含义与填写口径
字段说明的目标是让不同评估人对同一字段作出一致判断。填写口径写得越具体，汇总时越不需要反复追问。下表按五组字段逐一说明。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 试用单位 | 记录这次试用由谁发起和负责 | 写到部门层级，跨部门试用列出牵头部门 |
| 评估负责人 | 对记录完整性和结论负责的人 | 只填一人，避免多人署名导致责任分散 |
| 试用周期 | 试用实际发生的时间范围 | 填实际使用起止日期，与厂商开通的试用期区分开 |
| 试用版本 | 被评估的具体产品形态 | 注明版本号、套餐名称或部署方式，不同版本结论不可混用 |
| 参与角色 | 试用覆盖的岗位 | 列出角色名称和人数，便于判断结论的代表性 |
| 场景名称 | 一条用例要验证的业务动作 | 用“谁在什么情况下完成什么”的句式，避免写成功能名 |
| 对应组合管理动作 | 该场景在组合管理流程中的位置 | 从组合总览、优先级排序、资源分配、进度跟踪、评审汇报中选择或补充 |
| 前置数据 | 执行用例所需的数据准备 | 写明项目数量、人员规模、工时或预算口径，数据不足时注明 |
| 操作步骤 | 复现该场景的关键操作序列 | 按顺序编号，写到他人可照做的程度 |
| 预期结果 | 判断用例是否通过的标准 | 写成可观察的结果，如“在组合视图中一次看到全部项目的进度状态” |
| 是否通过 | 用例的总体判定 | 三档判定：全部达到预期为通过，主要结果达到但有缺口为部分通过，关键结果未达到为未通过 |
| 实际表现 | 试用中真实看到的结果 | 与预期结果逐条对照写，避免只写“基本满足”这类无法核对的描述 |
| 证据位置 | 支撑判定的材料所在位置 | 统一编号规则，如截图按“用例编号-序号”命名 |
| 问题描述 | 试用中发现的缺陷或能力缺口 | 写现象、位置、复现条件三要素，不写主观评价 |
| 影响范围 | 问题波及的角色和场景 | 说明是否影响其他用例的判定 |
| 严重程度 | 问题的处理优先级 | 阻断指该场景无法完成，严重指关键结果缺失，一般为可用但有明显不便，建议为体验改进项 |
| 评分 | 对维度表现的整体判断 | 1–5 分制，5 分为完全满足并有超出预期的表现，3 分为基本满足，1 分为无法满足；评分须附一句依据 |
| 权重 | 维度在总分中的占比 | 由评估负责人在试用前确定，全部维度权重合计 100%，试用开始后不再调整 |
评分口径需要在试用开始前向所有评估人说明。一个常见做法是先由各评估人独立打分，再集中讨论分歧超过两分的维度，讨论后各自修订分数，最后取加权平均。这样既保留个人判断，又避免一人主导全部结论。
哪些字段必填、哪些可以选填
必填字段的作用是保证记录可以支撑决策。缺少任一必填字段，这条记录只能作为过程笔记，不能作为选型结论的依据。选填字段按试用深度取舍，初筛阶段可以留空，深入验证阶段建议补齐。
| 字段 | 初筛阶段 | 深入验证阶段 | 必填理由或选填情形 |
|---|---|---|---|
| 试用单位、评估负责人、试用周期、试用版本、参与角色 | 必填 | 必填 | 缺少这些信息，记录无法定位到具体产品和具体时间，后续无法复核 |
| 试用环境与数据 | 选填 | 建议填写 | 使用演示数据时结论的参考价值有限，需在结论中说明 |
| 厂商支持方式 | 选填 | 选填 | 涉及后续采购与服务安排时填写 |
| 用例编号、场景名称、对应组合管理动作、前置数据、操作步骤、预期结果 | 必填 | 必填 | 没有场景和预期结果，试用结果无法判定，也无法与其他产品对比 |
| 执行人 | 选填 | 建议填写 | 多人分工试用时填写，便于回溯操作过程 |
| 是否通过、实际表现、证据位置 | 必填 | 必填 | 结论需要可核对的依据，证据位置缺失时判定容易被质疑 |
| 耗时与操作步数 | 选填 | 建议填写 | 需要比较操作效率时填写，否则可省略 |
| 问题编号、问题描述、影响范围、严重程度 | 必填 | 必填 | 问题记录是判断产品成熟度和实施风险的主要材料 |
| 临时处理、待厂商确认事项 | 选填 | 建议填写 | 存在未确认的能力边界时填写，作为下一轮沟通清单 |
| 评分、权重、加权总分、适配结论、后续动作 | 必填 | 必填 | 没有统一评分和明确结论，试用记录无法进入决策流程 |
初筛阶段的必填范围可以收窄到基本信息、场景与预期结果、是否通过、问题描述和适配结论，评分维度可只保留三到四项。进入深入验证后，补齐证据位置、耗时、待厂商确认事项和完整评分维度。调整必填范围时应在模板版本中注明，避免同一批记录口径不一致。
一份完整填写示例
以下示例为演示情景，用于说明字段之间如何配合，不代表任何具体产品的实际表现。示例中的组织为虚构的中型软件团队，正在评估项目组合平台对季度项目盘点和资源调配的支撑能力。
示例试用背景
| 字段 | 填写内容 |
|---|---|
| 试用单位 | 某软件公司研发管理部 |
| 评估负责人 | 张明，研发管理部项目经理 |
| 试用周期 | 2025-03-03 至 2025-03-21 |
| 试用版本 | 厂商提供的试用环境，具体版本与套餐以开通通知为准 |
| 参与角色 | 项目经理 2 人、部门负责人 1 人、资源管理员 1 人 |
| 试用环境与数据 | 导入 12 个脱敏项目及近三个月工时数据 |
示例验证场景与结果
| 用例编号 | 场景名称 | 组合管理动作 | 预期结果 | 是否通过 | 实际表现 | 证据位置 |
|---|---|---|---|---|---|---|
| UC-01 | 部门负责人查看本季度全部项目的进度与风险状态 | 组合总览 | 在一个视图中看到全部项目的进度、负责人和风险标记，无需逐个项目打开 | 通过 | 组合视图可自定义显示字段，12 个项目状态一屏可见，风险标记可筛选 | 截图 UC-01-01 |
| UC-02 | 资源管理员按角色查看未来两个月的人力投入 | 资源分配 | 按角色汇总投入工时，识别超负荷人员 | 部分通过 | 可按项目汇总工时，按角色维度的汇总需要额外配置，配置后数据可用 | 截图 UC-02-01、录屏 UC-02-02 |
| UC-03 | 项目经理调整一个项目的里程碑并同步给组合视图 | 进度跟踪 | 里程碑调整后组合视图中的进度状态同步更新 | 通过 | 调整后组合视图状态即时更新，历史版本可查 | 截图 UC-03-01 |
示例问题记录
| 问题编号 | 问题描述 | 影响范围 | 严重程度 | 临时处理 | 待厂商确认事项 |
|---|---|---|---|---|---|
| ISS-01 | 按角色汇总资源投入时，默认视图只显示项目维度，需手动增加角色字段 | 资源管理员，UC-02 | 一般 | 配置自定义视图后继续验证 | 是否有预设的角色资源视图，配置能否保存为团队共享模板 |
| ISS-02 | 导入历史工时数据时，部分日期格式未被识别，需手工修正 | 数据准备阶段，影响 12 个项目中的 3 个 | 严重 | 按模板重新整理后导入成功 | 导入模板对日期格式的支持范围，是否有校验提示 |
示例评分与结论建议
| 评分维度 | 权重 | 评分 | 评分依据 |
|---|---|---|---|
| 组合总览与数据汇总 | 25% | 5 | UC-01 一次通过，视图字段可自定义 |
| 计划与进度管控 | 20% | 4 | UC-03 通过，里程碑与组合视图联动正常 |
| 资源与工时管理 | 25% | 3 | UC-02 部分通过，角色维度需额外配置 |
| 评审与汇报支持 | 10% | 4 | 组合视图可直接用于季度评审，导出格式待确认 |
| 易用性与学习成本 | 10% | 4 | 参与角色在半天内完成主要操作 |
| 与现有工具集成 | 10% | 3 | 工时数据导入存在格式问题，见 ISS-02 |
| 加权总分 | 100% | 3.9 | 按权重计算 |
| 适配结论 | 有条件推荐：组合总览与进度管控满足需求，资源维度与数据导入需厂商确认后再定 | ||
| 后续动作 | 就 ISS-01、ISS-02 向厂商提交确认清单，安排一次资源管理专题演示，两周内复核 | ||
这份示例展示了记录闭环：场景定义预期结果，结果区给出判定和证据，问题区记录偏差，评分区把偏差折算为分数并落到结论和后续动作。示例中的每个字段都能在第二节的字段说明中找到对应口径。
试用后的模板调整与维护方法
模板在多轮试用后需要修订，否则字段会越来越长，评分口径也会随评估人变化而漂移。维护的重点是保持字段精简、评分可比、记录可追溯。
根据试用反馈增删字段的原则
- 同一字段连续两轮试用都无人填写，且不影响结论判定，考虑删除或并入其他字段。
- 多个评估人反复在“实际表现”中补充同类信息，说明该信息应独立成字段。
- 新增字段时同步更新字段说明和必填对照表，并在模板版本号中体现。
- 字段总数控制在单页可填写的范围，超出时按初筛和深入验证拆成两个版本。
评分标准与权重的维护
权重在每轮评估启动前确定，评估过程中保持不变。若业务重点发生变化，例如从进度管控转向资源优化，应在新一轮评估开始时调整权重并记录调整原因，不回溯修改已完成记录的分数。评分锚点建议每年复核一次，把“5 分”“3 分”的描述与近期实际试用表现对照，避免标准逐渐宽松。
多候选人记录汇总与版本管理
多个候选产品的记录应使用同一模板版本、同一组用例和同一套权重，汇总时按维度并列比较，并单独列出各产品的问题清单。模板本身建议纳入文档协作工具管理，保留每次修订的版本记录。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录所有页面版本、支持查看与回滚，适合承载这类需要长期维护的评估模板；权限配置可以区分评估人和查阅人。若试用重点在组合层面的多项目总览与资源投入，ONES Plan 支持自定义项目属性、查看多项目数据集合，并提供资源报表与工时数据，可作为验证场景中“组合总览”“资源分配”类用例的对照对象，具体功能范围以试用环境实际配置为准。
归档与复用方式
- 每轮评估结束后，将空白模板、填写记录、评分汇总和结论备忘打包归档，命名包含评估轮次和日期。
- 归档时保留证据材料的编号索引，截图和录屏按用例编号存放，便于日后复核。
- 下一轮评估直接复用上一轮的模板版本和用例库，只替换候选产品和试用周期。
- 把反复出现的待厂商确认事项整理成问题清单，作为新候选产品试用时的必查项。
常见问题
试用记录模板和试用评分表需要分开做吗？
可以合在一份模板里，也可以拆成两份。合在一起的好处是场景、结果、问题和评分在同一份记录中前后对应，评估人填完用例就能直接打分；拆开则适合参与人数较多、评分需要匿名汇总的情况。无论哪种方式，评分维度、权重和用例编号必须共用同一套口径，否则汇总时无法对齐。
初筛阶段时间有限，最少保留哪些字段？
初筛可以只保留能支撑“是否进入下一轮”判断的字段：试用单位、评估负责人、试用周期、试用版本、参与角色，每条用例的场景名称、预期结果、是否通过，问题描述与严重程度，以及适配结论和后续动作。评分维度可压缩到三到四项。证据位置、耗时、待厂商确认事项等字段留到深入验证阶段补齐，但初筛记录中应注明省略了哪些字段，避免后续误读。
多个评估人对同一维度打分差距很大，怎么处理？
先看分歧是否来自对评分锚点的理解不同。可以让分歧超过两分的评估人各自说明打分依据，对照“5 分完全满足、3 分基本满足、1 分无法满足”的描述重新校准，再各自修订分数后取加权平均。若分歧来自实际使用深度不同，应在记录中注明各自执行的用例范围，汇总时按用例覆盖情况区分权重，而不是简单平均。
试用中发现的问题，什么时候需要写进待厂商确认事项？
当问题涉及能力边界、配置方式或版本差异，试用团队无法自行判断时，写入待厂商确认事项，例如某个视图能否保存为团队共享模板、导入模板支持哪些日期格式。属于操作不熟练或配置错误的问题，先在临时处理中记录解决办法，确认是产品限制后再转为待确认事项。每轮试用结束后把待确认事项整理成清单，作为下一轮沟通和新候选产品的必查项。
模板需要长期维护时，用什么方式管理版本比较稳妥？
把模板本身当作受控文档管理，每次修订记录版本号、修订日期和变更内容，并同步更新字段说明与必填对照表。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，并记录所有页面版本、支持查看与回滚，权限配置可以区分评估人和查阅人，适合承载需要多轮复用的评估模板。归档时把空白模板、填写记录、评分汇总和证据索引放在同一目录下，命名包含评估轮次和日期。
