团队协作平台选型容易在演示环节被功能印象带走，事后才发现权限、集成或数据导出存在缺口。这份清单按需求与范围确认、候选与能力核验、试点与数据验证、合同与上线准备四个阶段组织，每项写明通过标准、证据形式和负责人，并设置阻断项：任一阻断项未通过即暂停进入下一阶段。清单适合IT、业务、采购与安全角色共同使用，ONES可作为承载协作流程与检查记录的候选之一，具体能力需在核验阶段逐项确认。
要点总览（TL;DR）
- 清单按需求与范围确认、候选与能力核验、试点与数据验证、合同与上线准备四个阶段组织，每项写明通过标准、证据形式和负责人。
- 需求阶段先固定协作场景、用户范围、集成边界与预算口径，经业务与IT双方签字后作为后续核验基准。
- 能力核验阶段要求每项有演示记录或书面说明，权限模型、集成方式、安全合规答复缺一不可。
- 试点阶段用真实团队跑完一轮协作闭环，并实测历史数据导入的格式支持与工作量。
- 任一阻断项未通过即暂停进入下一阶段，整体完成条件为四阶段全部通过且阻断项清零。
谁在什么时点使用这份清单
这份清单解决的是责任分工问题：不同角色在不同时点介入，各自提供证据并签字确认，避免选型由单一部门拍板。使用对象包括IT/信息化负责人、业务部门代表、采购、安全与合规人员，必要时加入财务与法务。
各阶段的介入时点与签字责任如下表。签字意味着该阶段证据已收齐、结论可追溯，不替代后续阶段的验证。
| 时点 | 主要使用角色 | 本阶段产出 | 签字确认 | 证据提供方 |
|---|---|---|---|---|
| 立项前 | 业务部门代表、IT负责人 | 协作场景清单、用户范围、预算口径 | 业务负责人与IT负责人共同签字 | 业务部门提供场景与人数，IT提供现有系统清单 |
| 候选筛选后 | IT负责人、安全与合规 | 候选能力核验表 | IT负责人签字，安全项由合规人员会签 | 供应商提供书面说明，IT记录演示表现 |
| 试点前 | 试点团队负责人、IT | 试点方案与验证记录表 | 试点团队负责人签字 | 试点团队提供使用反馈，IT提供导入测试记录 |
| 合同签署前 | 采购、法务、IT、安全 | 合同与上线准备检查表 | 采购与法务主签，IT与安全会签 | 供应商提供合同文本与服务说明，采购核对条款 |
实际操作中，建议指定一名选型协调人维护清单版本，收集各角色的证据并跟踪未通过项。协调人不做技术判断，只保证每项检查有人负责、有记录、有结论。
第一阶段：需求与范围确认检查项
这一阶段在接触任何产品之前完成，目标是把协作场景、用户范围、集成边界和预算口径固定下来，作为后续核验的基准。需求清单一旦签字，后续新增场景应走变更记录，避免候选范围反复扩大。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 协作场景清单 | 逐项列出即时沟通、文档协作、任务与项目管理、会议与日程等场景，并标注优先级与使用部门 | 场景清单文档，含优先级排序 | 业务部门代表 |
| 用户规模与组织范围 | 给出账号数量、部门分布，并明确外部协作方是否纳入及大致人数 | 用户范围说明，附组织架构范围 | 业务部门代表与IT |
| 必须对接的已有系统 | 列出系统名称、对接目的与接口归属边界，明确由哪一方承担对接工作 | 系统对接清单，含责任方标注 | IT负责人 |
| 预算口径 | 许可、实施、运维、培训分项列示，注明年度或一次性口径 | 预算分项表 | 财务或采购 |
| 需求确认签字 | 需求清单经业务与IT双方确认签字，变更流程已约定 | 签字版需求文档 | 业务负责人与IT负责人 |
外部协作方是否纳入，直接影响后续权限模型与账号数量的核验口径。若业务涉及客户、供应商或外包团队参与协作，应在本阶段写明参与方式和数据可见范围要求，而不是留到演示时临时提问。集成边界同样需要提前明确：哪些系统必须打通、由供应商提供接口还是由内部开发对接，决定了后续工作量评估的基础。
第二阶段：候选与能力核验检查项
这一阶段对入围产品逐项核验，用演示记录和书面说明替代印象判断。核验时按第一阶段确认的场景清单逐条走查，避免供应商按通用脚本演示而跳过关键场景。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 核心协作功能 | 按场景清单逐项演示，记录实际表现与限制条件 | 演示记录，含截图或录屏说明 | IT负责人与业务代表 |
| 权限模型 | 能说明组织架构、外部成员、数据可见范围的配置方式，并现场演示一次权限分配 | 权限配置说明与演示记录 | IT负责人 |
| 集成能力 | 对每个必须对接的系统，给出对接方式、所需工作量与责任方 | 集成方案书面说明 | IT负责人 |
| 安全与合规 | 数据存储位置、审计日志、账号体系对接方式有书面答复 | 供应商书面说明或问卷回复 | 安全与合规人员 |
| 核验结论 | 每项检查均有演示记录或书面说明，未通过项已标注 | 候选能力核验表汇总 | 选型协调人汇总，IT负责人签字 |
以ONES为例，其项目产品面向研发团队的需求、任务、缺陷与迭代等场景，提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配；同时提供敏捷、瀑布、通用任务协同等模板。这些信息可作为核验起点，外部协作方的权限细节、数据存储位置与审计日志能力仍需在演示或书面答复中确认。ONES Wiki支持文档关联任务并插入工作项列表，若文档与任务联动是核心场景，可在演示中一并验证。
核验表应记录每项的判断结果：满足、部分满足、不满足。部分满足的项要写清差距和补救方式，作为试点阶段的重点观察对象。
第三阶段：试点与数据验证检查项
试点用真实团队和真实协作数据验证可用性、迁移可行性与日常使用成本。试点团队应覆盖主要使用角色，周期足以跑完一轮完整协作闭环，通常以两到四周为宜，具体时长按业务节奏确定。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 试点团队与周期 | 试点团队覆盖主要角色，周期与验证目标已书面约定 | 试点方案 | 试点团队负责人 |
| 历史数据导入 | 选取代表性文档与任务数据完成导入，记录格式支持情况与实际工作量 | 导入测试记录 | IT负责人 |
| 协作流程跑通 | 完成发起、评审、归档的完整闭环，各环节有实际参与者 | 流程走查记录与工作项状态截图 | 试点团队负责人 |
| 使用反馈收集 | 按约定样本量收集反馈，覆盖不同角色，问题分类记录 | 反馈汇总表 | 选型协调人 |
| 试点结论 | 试点团队完成一轮完整协作闭环并形成书面结论，明确可上线或需整改 | 试点验证记录表与结论签字 | 试点团队负责人与IT负责人 |
试点阶段适合把检查记录本身放进协作平台里跑：在ONES中建立试点工作项，把导入测试、流程走查、反馈问题分别登记为任务，指定负责人和截止时间，评审结论沉淀在关联文档中。这样试点过程与验证证据在同一处留存，后续复核时可直接追溯每个问题的处理状态。
数据导入验证要关注两点：格式支持范围与工作量。若历史数据量大或格式复杂，应在本阶段实测并记录耗时，作为上线排期的输入。反馈收集要避免只听取积极使用者意见，应覆盖日常高频使用和偶尔使用的角色。
第四阶段：合同与上线准备检查项
这一阶段把选型结论落到合同条款和上线动作，防止演示时的能力承诺与合同内容脱节。合同条款应与第二、三阶段的核验结论逐条对照，核验中标注为部分满足的项，要在合同中写明服务方的责任或整改安排。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 服务范围与账号数量 | 合同写明服务范围、账号数量与增购方式，与需求阶段口径一致 | 合同文本对照表 | 采购 |
| 服务级别条款 | 可用性、响应时限、支持渠道有明确条款 | 合同或服务说明附件 | 采购与IT |
| 数据归属与退出机制 | 数据归属明确，导出格式与时限写入合同 | 合同条款 | 法务与IT |
| 培训与推广计划 | 培训对象、方式、时间与推广节奏已排定 | 上线计划文档 | 业务部门代表 |
| 上线时间表 | 上线里程碑、责任人与验收方式经确认 | 上线计划签字版 | IT负责人 |
数据导出格式与时限是退出机制的核心，签约前应确认可导出的数据类型和交付周期，避免上线后才发现迁移受限。培训计划要区分管理员培训与普通用户培训，前者覆盖权限配置和日常运维，后者聚焦协作流程操作。
阻断项与完成条件
阻断项是一票否决或暂停推进的检查项，任一阻断项未通过，选型即停在当前阶段，处理方式为补充验证或更换候选，不以其他项的高分抵消。
| 阻断项 | 判定条件 | 处理方式 | 复核责任人 |
|---|---|---|---|
| 核心协作场景无法满足 | 第一阶段确认的高优先级场景中，存在无法实现且无替代方案的情况 | 暂停推进，要求补充方案或更换候选 | IT负责人与业务代表 |
| 数据无法导出 | 合同或书面说明中无法确认导出格式与时限 | 暂停签约，补充书面承诺后再评估 | 法务与IT |
| 权限模型不满足外部协作要求 | 外部协作方的数据可见范围无法按需隔离 | 补充验证或更换候选 | 安全与合规人员 |
| 安全与合规书面答复缺失 | 数据存储位置、审计日志等关键项无书面答复 | 暂停进入试点或签约 | 安全与合规人员 |
整体完成条件为四个阶段全部通过且阻断项清零。未通过项应登记在清单中，写明原因、补充验证计划、复核责任人与复核时间，复核通过后更新状态。选型协调人在每个阶段结束时汇总清单，确认签字齐全后再启动下一阶段，确保每个结论都有证据支撑、每个未通过项都有明确的后续动作。
常见问题
试点团队应该选多少人、跑多长时间？
试点团队人数没有统一标准，关键是覆盖主要使用角色，例如业务发起人、日常执行成员、审批或评审角色。周期通常以两到四周为宜，具体时长按业务节奏确定，目标是让试点团队跑完一轮完整的协作闭环，包括发起、评审和归档。如果历史数据导入验证耗时较长，可适当延长周期，但应在试点方案中写明验证目标和截止时间。
外部协作方参与协作时，清单里哪几项需要特别核验？
外部协作方纳入后，需求阶段要写明参与方式和数据可见范围要求，用户范围说明中标注大致人数。能力核验阶段重点看权限模型能否按需隔离外部成员的数据可见范围，并现场演示一次权限分配。合同阶段则要确认账号数量口径是否包含外部成员，以及退出机制中外部数据的处理方式。若权限模型无法满足外部协作隔离要求，按阻断项处理，暂停推进并补充验证或更换候选。
供应商演示时表现良好，但书面说明迟迟不提供，怎么办？
能力核验阶段要求每项检查有演示记录或书面说明作为证据，两者缺一不可。若供应商仅做口头承诺或演示而不提供书面说明，该项应标注为未通过，不能以演示印象替代。安全与合规类问题，如数据存储位置、审计日志、账号体系对接方式，若缺少书面答复，按阻断项处理，暂停进入试点或签约。选型协调人应记录未通过项并跟踪补充材料的时限。
历史数据导入验证需要做到什么程度？
试点阶段选取代表性文档与任务数据完成导入，记录格式支持情况和实际工作量即可，不要求全量迁移。重点观察两点：哪些格式可以导入、导入过程耗时多少。若历史数据量大或格式复杂，实测耗时可作为上线排期的输入。导入测试记录由IT负责人保存，作为试点结论的证据之一。全量迁移的执行方法不在本文范围，可在上线准备阶段另行规划。
合同条款与前期核验结论不一致时如何处理？
合同签署前，采购应将合同文本与第二、三阶段的核验结论逐条对照。核验中标注为部分满足的项，要在合同中写明服务方的责任或整改安排；核验中确认为满足但合同未体现的，要求补充条款。数据导出格式与时限必须写入合同，无法确认时按阻断项暂停签约。合同条款与核验结论一致、上线计划经确认，才算通过第四阶段。
