团队协作平台选型容易在演示环节被功能印象带走，评审时缺少统一判断依据。这份清单按“需求确认—候选评估—试点验证—推广上线”四个阶段组织，每项检查写明通过标准、证据和负责人，并把数据安全、权限模型、集成可行性、总成本列为阻断项：任何一项未通过，暂停进入下一阶段。清单可用表格或工作项承载，ONES 可作为检查项跟踪与评审流转的承载工具之一。
要点总览（TL;DR）
- 清单按需求确认、候选评估、试点验证、推广上线四个阶段组织，每个评审节点对应一组检查项和阶段输出物，逐项判定通过、不通过或待补证。
- 需求确认阶段先固定协作场景、用户范围、现有工具盘点与合规约束，需求清单经业务方签字后才进入候选评估。
- 候选评估用统一口径打分，每个结论都要有产品文档、演示记录或厂商书面答复作为证据，口头承诺不计入通过依据。
- 数据安全与合规、权限模型、关键集成、总成本四类阻断项任一未通过即暂停推进；解除需书面记录并经审批。
- 完成条件是四阶段检查项全部有结论、阻断项全部关闭、各阶段输出物归档，选型结论才可作为采购与上线决策依据。
谁在什么时点使用这份清单
这份清单服务于选型评审，而非产品调研笔记。它把四个阶段的检查项分配到具体评审节点，让每个参与方在对应时点拿出该看的检查表，避免所有问题堆到最终决策会上集中讨论。
使用对象按职责划分：IT/信息化负责人牵头整体节奏，负责技术可行性、账号体系与集成判断；业务部门代表确认协作场景与使用习惯，对功能覆盖和试点体验给出结论；采购人员统一成本口径与合同条款；安全合规人员负责数据存放、审计与权限边界的判定。四类角色在各阶段承担不同检查项，负责人一栏应写到岗位而非部门。
| 评审节点 | 主要参与方 | 本节点应完成的检查 | 阶段输出物 |
|---|---|---|---|
| 立项评审 | IT负责人、业务代表、采购 | 第一阶段全部检查项 | 经业务方确认的需求清单与约束条件 |
| 候选评审 | IT负责人、安全合规、采购 | 第二阶段全部检查项 | 候选评估打分表与证据清单 |
| 试点验收 | 业务代表、IT负责人 | 第三阶段全部检查项 | 试点验收检查表与结论记录 |
| 上线前评审 | IT负责人、业务代表、安全合规 | 第四阶段全部检查项及阻断项复核 | 上线前检查表与回退预案 |
清单的使用方式是逐项判定，每项给出“通过”“不通过”“待补证”三种结论之一。“待补证”必须写明缺什么证据、由谁在什么时间补齐，不能长期挂起；同一检查项在补证后重新判定。阶段推进的条件是该阶段所有检查项都有明确结论，且阻断项全部通过。
第一阶段：需求与范围确认检查项
这一阶段在接触产品之前完成，目的是把协作需求、用户范围和约束条件固定下来，作为后续评估的基准。需求清单一旦确认，候选评估就按它逐条对照，减少因演示内容临时改变评估重点的情况。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 协作场景清单 | 即时沟通、文档协同、任务与项目管理、会议与日程四类场景均列出具体使用部门和典型流程，并标注优先级 | 场景清单文档，业务方签字 | 业务部门代表 |
| 用户范围与组织边界 | 明确内部用户数量级、涉及部门、外部协作方类型（客户、供应商、外包）及移动端使用比例 | 用户范围说明，含外部协作方名单类型 | IT负责人 |
| 现有工具盘点 | 列出现有协作工具、使用部门、合同到期时间，并逐项标注替换、并存或淘汰策略 | 工具盘点表 | IT负责人、采购 |
| 合规与部署约束 | 写明数据存放位置要求、账号体系对接方式、审计与日志保留要求，以及是否允许SaaS部署 | 合规约束说明，安全合规人员确认 | 安全合规人员 |
| 预算与时间约束 | 给出许可、实施、运维、培训的预算上限和上线时间窗口 | 预算批复或立项文件 | 采购、IT负责人 |
这一阶段的完成标志是需求清单经业务方签字确认，且合规约束已由安全合规人员书面确认。若外部协作方的数据访问范围尚未明确，应作为待补证项记录，在候选评估前补齐，因为它直接影响下一阶段的权限模型判断。
第二阶段：候选评估检查项
候选评估用统一口径逐项打分，每个结论都要有可核验的证据来源，包括产品文档、演示记录或厂商书面答复。口头承诺不计入通过依据，演示中看到的功能应记录演示环境、版本和操作路径。
| 评估维度 | 检查项 | 通过标准 | 证据来源 |
|---|---|---|---|
| 功能覆盖 | 四类核心协作场景逐条对照需求清单 | 高优先级场景全部满足；存在缺口的场景有可接受的替代做法并写明 | 产品文档、演示记录 |
| 权限与组织模型 | 能否映射现有组织架构、用户组与项目角色；外部协作方的访问边界如何控制 | 可按部门、角色、项目分别授权，外部人员权限可限制在指定范围 | 厂商书面答复、配置演示 |
| 集成可行性 | 与现有账号体系、消息工具、文档工具、研发工具的连接方式 | 关键集成有明确实现路径，并说明由谁实施、需要何种配合 | 集成文档、厂商书面确认 |
| 安全与合规 | 认证情况、审计日志、数据导出与删除能力、数据存放位置 | 满足第一阶段合规约束；缺失项有书面说明和处理方案 | 合规材料、厂商书面答复 |
| 成本口径 | 许可、实施、运维、培训费用按同一口径折算 | 给出三年期总成本估算，各候选按相同口径可比 | 报价单、成本测算表 |
打分表应保留每个候选在每个维度上的原始证据编号，便于复核时追溯。以 ONES 为例，其项目产品提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，并提供敏捷、瀑布、通用任务协同等模板；这些信息可作为权限模型与功能覆盖维度的评估输入，审计日志、第三方集成细节与具体价格仍需以厂商书面材料核验。
本阶段的通过标准是每个候选在每个维度都有结论和证据编号，且没有维度停留在“待补证”。候选评审结束时形成候选排序，排序依据应能追溯到具体检查项，而非整体印象。
第三阶段：试点验证检查项
试点在小范围真实业务中验证平台可用性，重点回答两个问题：团队是否愿意持续使用，关键协作流程能否在平台上完整走通。试点范围应覆盖第一阶段列出的高优先级场景，并包含至少一个涉及外部协作方的流程。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 试点范围与周期 | 明确试点团队、覆盖场景、持续周期（建议不少于四周），并事先约定不扩展范围 | 试点方案 | IT负责人、业务代表 |
| 活跃使用情况 | 试点团队周活跃使用率达到预设阈值，阈值在试点前确定 | 平台使用数据导出 | IT负责人 |
| 关键流程完成情况 | 选定的关键协作流程在试点期内完整走通，包括任务流转、文档协作与评审环节 | 流程记录、参与人确认 | 业务代表 |
| 问题响应 | 试点中提出的问题均有记录，厂商响应时长在约定范围内，阻断类问题已解决 | 问题清单与响应记录 | IT负责人 |
| 用户体验与培训成本 | 通过问卷或访谈收集反馈，记录新成员上手所需时间与培训投入 | 反馈汇总、培训记录 | 业务代表 |
试点指标阈值需要结合自身业务设定，缺少历史参考时可按试点前基线确定，例如以现有工具的周活跃率为参照。试点结论只有两种：达到预设阈值且无未解决的阻断问题，进入推广阶段；否则记录原因，决定调整方案后延长试点或更换候选。试点期间的问题清单与厂商响应记录应作为验收材料归档，ONES 的工作项与文档关联能力可用于承载这类问题跟踪和结论记录。
第四阶段：推广上线检查项
推广期的风险主要来自组织准备不足，而非平台本身。上线前评审要确认账号、规则、培训和支持四条线都已就位，并准备好回退路径。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 账号与组织数据初始化 | 组织架构、用户组、项目空间按方案建立完成，账号开通率达标 | 初始化核对表 | IT负责人 |
| 使用规则与协作规范 | 发布命名规范、权限申请流程、文档与任务的使用约定 | 已发布的规范文档 | 业务代表 |
| 培训与内部支持 | 培训计划覆盖全部目标用户，内部支持渠道和响应人已确定 | 培训排期、支持渠道说明 | 业务代表、IT负责人 |
| 旧工具数据处理 | 明确归档、导出或并行期的处理方式与时间点 | 数据处理方案 | IT负责人 |
| 观察期指标与回退预案 | 设定上线后观察期长度与观察指标，回退触发条件和操作步骤经确认 | 回退预案，相关方签字 | IT负责人、安全合规人员 |
上线检查项全部通过且回退方案经确认，才可进入正式推广。观察期内按预设指标跟踪使用情况和问题数量，触发回退条件时按预案执行，不临时决策。
阻断项与完成条件
阻断项是不可妥协的条件，与普通检查项的区别在于：普通项可以带条件通过并限期整改，阻断项未通过则暂停推进，不进入下一阶段。四类常见阻断项及其判定方式如下。
| 阻断项 | 判定证据 | 责任人 | 未通过时的处理 |
|---|---|---|---|
| 数据安全与合规不达标 | 合规材料、数据存放位置说明、审计与删除能力的书面答复 | 安全合规人员 | 暂停候选评估结论，要求厂商补充材料或调整部署方案 |
| 权限模型无法满足组织边界 | 权限配置演示记录、外部协作方访问控制说明 | IT负责人 | 记录具体缺口，评估替代控制手段是否可接受 |
| 关键集成无法实现 | 集成文档、厂商书面确认或技术验证记录 | IT负责人 | 确认是否有替代路径；无替代路径则更换候选 |
| 总成本超出预算上限 | 三年期总成本测算与预算批复对比 | 采购 | 调整范围或版本方案后重新测算，仍超限则终止该候选 |
阻断项的解除需要书面记录：写明原判定、补充的证据、解除理由和审批人。解除审批由立项评审时的决策人负责，安全合规类阻断项的解除须经安全合规人员确认。阻断项在试点和上线前评审时各复核一次，防止评估阶段的结论在实施中失效。
整体完成条件是四个阶段的检查项全部有明确结论，阻断项全部关闭或有经审批的解除记录，且每个阶段的输出物已归档。满足这些条件后，选型结论才可作为采购与上线决策的依据。
常见问题
试点周期定多长比较合适，指标阈值没有历史数据怎么办？
试点周期建议不少于四周，覆盖第一阶段列出的高优先级场景，并包含至少一个涉及外部协作方的流程。周期过短容易只验证到登录和基础操作，看不到任务流转、文档协作与评审环节能否完整走通。
指标阈值缺少历史数据时，可以试点前基线作为参照，例如以现有协作工具的周活跃率作为活跃使用率的起点，再结合试点团队规模设定目标。阈值必须在试点开始前确定并写入试点方案，避免试点结束后再调整口径。试点结论只有两种：达到预设阈值且无未解决的阻断问题，进入推广阶段；否则记录原因，决定调整方案后延长试点或更换候选。
候选评估时厂商口头承诺功能可以满足，能否直接判定通过？
不能。候选评估阶段的通过依据限定为可核验的证据来源：产品文档、演示记录或厂商书面答复。演示中看到的功能应记录演示环境、版本和操作路径，口头承诺不计入通过依据。
如果某项能力暂时只有口头说明，应将该检查项判定为“待补证”，写明缺什么材料、由谁在多长时间内补齐，补证后重新判定。打分表保留每个候选在每个维度上的原始证据编号，复核时可追溯到具体材料，候选排序也据此形成，而非整体印象。
阻断项未通过时，是直接淘汰候选还是可以带条件推进？
阻断项与普通检查项的处理方式不同：普通项可以带条件通过并限期整改，阻断项未通过则暂停推进，不进入下一阶段。
四类常见阻断项各有处理路径：数据安全与合规不达标时，暂停候选评估结论，要求厂商补充材料或调整部署方案；权限模型无法满足组织边界时，记录具体缺口并评估替代控制手段是否可接受；关键集成无法实现时，确认是否有替代路径，无替代路径则更换候选；总成本超出预算上限时，调整范围或版本方案后重新测算，仍超限则终止该候选。
阻断项解除需要书面记录，写明原判定、补充证据、解除理由和审批人。安全合规类阻断项的解除须经安全合规人员确认，并在试点和上线前评审时各复核一次。
外部协作方的数据访问范围在需求阶段没定清楚，会影响后续哪些检查？
外部协作方访问范围直接影响候选评估阶段的权限模型判断，也会影响试点阶段涉及外部协作流程的验证。需求阶段若尚未明确，应作为待补证项记录，在候选评估前补齐。
补齐时需要写明外部协作方类型（客户、供应商、外包）、可访问的数据范围以及授权与回收流程。这些信息进入候选评估后，用于判断平台能否按部门、角色、项目分别授权，并把外部人员权限限制在指定范围。若该问题拖到试点阶段才处理，可能导致试点范围需要临时调整，影响试点结论的可比性。
上线后的观察期要跟踪什么，什么情况下触发回退？
观察期长度和观察指标应在上线前评审时确定并写入回退预案，常见跟踪内容包括使用活跃情况、问题数量与处理时长、关键协作流程的完成情况。指标口径与试点阶段保持一致，便于对比。
回退触发条件同样在预案中事先约定，例如关键流程无法走通、问题集中出现且短期无法解决。触发后按预案执行，不临时决策。上线检查项全部通过且回退方案经相关方签字确认，才可进入正式推广；观察期内按预设指标跟踪，达到退出条件后结束观察期。
