项目管理系统选型容易陷入“演示看着都行、上线后处处别扭”的困境。这份清单把选型拆成需求立项、候选初筛、场景演示、技术与安全评审、商务与合同、试点验收六个阶段，每项检查都给出通过标准、所需证据和负责人，并单列阻断项规则。它适合由业务、IT、采购、法务与安全共同组成的选型小组使用，帮助团队在投入下一阶段资源前拿到可核验的结论。
要点总览（TL;DR）
- 选型清单按需求立项、候选初筛、场景演示、技术与安全评审、商务与合同、试点验收六个阶段推进，每个阶段设评审节点，结论分为通过、有条件通过、退回补充。
- 需求立项阶段把必须项与加分项分开：必须项不满足即淘汰，加分项按权重计分，权重与评分口径由选型小组签字确认。
- 演示与试点都要预先约定验收点，用真实业务场景判断通过与否，记录截图、操作路径和异常表现，核心场景不满足记为阻断项。
- 技术与安全评审在签约前确认身份认证对接、权限分级、集成联调、数据导出与安全材料，安全材料以厂商正式文件为准并核对签约主体。
- 阻断项未关闭不进入下一阶段，完成选型需同时满足需求表签字、核心场景验收点满足、技术安全阻断项关闭、合同条款覆盖价格与服务四类条件。
谁在什么时点使用这份清单
清单在选型启动会上第一次使用：确定小组成员、明确各阶段主责人，并约定评审节奏。之后每个阶段结束设一个评审节点，节点输出结论为“通过”“有条件通过”或“退回补充”，只有通过或有条件通过且条件已关闭，才进入下一阶段。
角色分工建议按决策权而非部门名称划分。业务负责人对需求必须项和场景验收点负责；IT/信息化对集成方式、账号体系和部署环境负责；采购对报价口径和商务条款负责；法务对合同条款与数据处置约定负责；安全对权限模型、合规材料和责任边界负责。同一人可兼任多个角色，但每个检查项必须有唯一确认人。
| 评审节点 | 时点 | 主责人 | 参与人 | 进入下一阶段的条件 |
|---|---|---|---|---|
| 需求立项评审 | 接触产品前 | 业务负责人 | IT、采购、安全 | 必须项、加分项与权重签字确认 |
| 候选初筛评审 | 收集候选后1周内 | IT/信息化 | 业务负责人、采购 | 候选名单收敛到可演示数量，淘汰理由留档 |
| 场景演示评审 | 每场演示后当日 | 业务负责人 | 关键角色用户代表 | 核心场景验收点全部有判定结论 |
| 技术与安全评审 | 演示通过后 | IT/信息化与安全 | 法务、采购 | 技术阻断项关闭，安全材料齐备 |
| 商务与合同评审 | 签约前 | 采购 | 法务、业务、IT | 价格口径与服务条款逐条对应 |
| 试点验收评审 | 试点周期结束 | 业务负责人 | IT、采购、试点用户 | 验收指标达标，问题清单关闭 |
记录方式统一为三种状态：通过、不通过、待补证据。待补证据项必须写明补证责任人和截止时间，超过时限未补齐按不通过处理。评审结论、证据附件和异议意见一并归档，便于后续复盘和合同争议时追溯。
需求立项阶段：先把必须项和权重定下来
这一阶段的目标是把“我们想要一个好用的系统”转成可以逐条判断的需求表。做法是先按使用角色收集场景，再从场景中提炼检查项，最后区分必须项与加分项。
必须项指不满足即淘汰的条件，例如支持某种部署方式、必须与现有账号体系打通、必须满足数据不出境要求。加分项指影响体验或效率但可妥协的条件，例如报表自定义程度、移动端支持范围。区分方法很直接：问一句“如果这条不满足，我们是否愿意放弃这家厂商”，答案为是则归入必须项。必须项数量宜控制在十条左右，过多会让候选全部出局，过少则失去筛选作用。
需求收集按角色展开：项目负责人关心计划编制、进度跟踪与资源视图；执行成员关心任务分配、工时与文档协作；管理层关心跨项目汇总与风险预警；IT关心账号、权限与集成；采购关心计费方式。每个角色至少访谈两人，把访谈原话转成检查项，例如“希望周报自动汇总”转为“系统能按项目自动生成进度汇总并导出”。
权重与评分口径在立项阶段一次定清：加分项总分设为100分，按业务影响分配权重，评分采用统一刻度（如1至5分），并约定评分人。需求文档由业务负责人起草，IT、采购、安全会签，最终由选型小组组长签字确认。签字后的需求表作为后续演示和试点的唯一验收依据，中途变更需走书面变更记录。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 必须项清单 | 每条必须项可判断满足与否，数量在合理区间 | 需求表必须项页，含判定说明 | 业务负责人 |
| 角色场景覆盖 | 核心角色均有访谈记录并转为检查项 | 访谈纪要、场景—检查项对照表 | 业务负责人 |
| 加分项权重 | 权重合计100分，评分刻度与评分人已约定 | 权重表与评分说明 | 选型小组组长 |
| 需求文档确认 | 业务、IT、采购、安全会签，组长签字 | 签字版需求文档与变更记录模板 | 选型小组组长 |
需求收集和会签过程会产生大量访谈记录、评审意见和变更请求，这些材料需要集中存放并跟踪状态。ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把需求条目、评审意见和待补证据作为工作项管理，让每条需求的确认人和状态可查。
候选初筛阶段：用公开信息排除明显不符
初筛的目的不是选出最优产品，而是用低成本信息把明显不符合必须项的候选排除，把演示资源留给真正有机会的厂商。候选来源包括同行推荐、行业报告、公开评测和厂商主动接洽，数量建议控制在五到八家，过多会稀释评审精力。
初筛只看三类信息：部署方式是否覆盖必须项要求（SaaS、私有部署或两者兼有）；账号体系能否与现有身份认证方式对接；集成方向是否覆盖必须打通的系统类别，如代码仓库、持续集成工具、办公协作平台。这三类信息通常可从官网、产品文档和厂商书面答复中获得，不需要安排演示。
证据留存要求：每条初筛结论必须附来源，官网页面注明访问日期，厂商答复保留邮件或书面文件。口头答复不作为通过依据，只能标记为待补证据。淘汰理由按“不满足哪条必须项”记录，避免写成“感觉不合适”这类无法复核的表述。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 候选数量 | 收敛到五至八家，来源可追溯 | 候选来源登记表 | IT/信息化 |
| 部署方式 | 覆盖需求表规定的部署方式 | 官网页面截图或厂商书面答复 | IT/信息化 |
| 账号体系 | 支持与现有身份认证方式对接或有明确对接方案 | 产品文档、对接说明 | IT/信息化 |
| 集成方向 | 覆盖必须打通的系统类别 | 集成文档或厂商答复 | IT/信息化 |
| 淘汰理由 | 每条淘汰对应具体必须项，可复核 | 初筛表淘汰原因栏 | IT/信息化 |
场景演示阶段：用真实业务走一遍
演示阶段最容易失控的环节是厂商按标准脚本展示功能，评审方却无法判断这些功能能否支撑自己的业务。解决办法是提前把演示变成有验收点的场景验证。
场景选择覆盖核心角色与关键流程，通常三到五个场景足够：一个从需求提出到排期立项的流程，一个迭代或阶段计划编制与进度跟踪的流程，一个跨角色协作与审批流程，一个报表汇总与导出场景，以及一个权限差异场景（如外部协作人员只能看到部分内容）。每个场景写明参与角色、输入数据和期望结果。
演示脚本与验收点在演示前至少三个工作日发给厂商，要求按脚本准备真实数据环境而非预制演示库。演示中记录三类信息：关键界面截图、操作路径（从哪个入口经过几步到达结果）、异常表现（报错、卡顿、需要绕行的操作）。记录人由业务侧指定，不由厂商代劳。
判定规则事先约定：每个验收点给出“满足”“部分满足”“不满足”三档，部分满足需注明差距；核心场景出现不满足即记为演示阻断项，需厂商给出解决方案和验证时间，未关闭不进入技术与安全评审。演示评分只用于加分项排序，不替代必须项判断。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 场景覆盖 | 覆盖核心角色与关键流程，三至五个场景 | 场景清单与角色对照 | 业务负责人 |
| 脚本与验收点 | 演示前送达厂商，验收点可判断 | 发送记录、验收点清单 | 业务负责人 |
| 过程记录 | 截图、操作路径、异常表现齐全 | 演示记录文档 | 指定记录人 |
| 判定结论 | 每个验收点有明确判定，阻断项登记 | 场景演示评分表 | 业务负责人 |
技术与安全评审：集成、权限、数据归属逐项确认
演示通过只说明业务场景能跑通，系统能否在真实IT环境中稳定运行、是否符合安全要求，需要单独评审。这一阶段的结论直接影响合同能否签署，检查项应由IT和安全人员主导，业务方配合确认影响范围。
身份认证与权限模型重点确认：是否支持与现有统一身份认证对接，账号开通与回收是否可自动化；权限能否按组织、角色、项目分级设置，外部协作人员的可见范围是否可限制；权限变更是否有审计记录。集成方式确认接口类型（开放API、Webhook、预置连接器）、调用频率限制、失败重试机制，并要求在测试环境完成一次真实对接验证，而非只看文档。
数据归属与迁移路径确认：数据所有权在合同中如何表述；导出能力覆盖哪些对象（任务、附件、评论、操作日志），导出格式是否通用；从现有系统迁入数据的路径与工作量。安全合规材料以厂商提供的正式文件为准，包括安全白皮书、渗透测试报告、相关认证证书，并核对证书主体与签约主体是否一致。责任边界写明安全事件的通知时限、处置分工和赔偿约定。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 身份认证对接 | 测试环境完成一次真实对接 | 对接测试记录 | IT/信息化 |
| 权限模型 | 分级授权可配置，外部人员范围可限 | 权限配置截图与说明 | IT/信息化 |
| 集成验证 | 关键系统完成接口联调 | 联调记录、接口文档 | IT/信息化 |
| 数据导出 | 核心对象可完整导出，格式通用 | 导出样例文件 | IT/信息化 |
| 安全材料 | 正式文件齐备，主体与签约方一致 | 证书、报告原件或盖章件 | 安全 |
| 责任边界 | 事件通知时限与处置分工写入条款 | 合同安全条款草案 | 安全与法务 |
权限与数据归属的确认往往需要对照具体配置逐项核对。ONES Project 的多层级权限可按组织架构、用户组、项目角色灵活分配，便于在评审中直接演示不同角色的可见范围；ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，若选型范围包含测试管理，可在评审中一并验证测试流程闭环与用例导入导出能力。
商务与合同阶段：把价格口径和服务条款写清楚
产品合适不等于合同可签。商务阶段的任务是把报价拆到可核对的口径，把服务承诺写成可追责的条款。报价口径至少拆成四项：用户数（按注册用户、活跃用户还是并发用户计费）、模块（基础模块与增值模块分别计价）、存储（容量上限与超量计费方式）、实施服务（人天单价、范围与交付物）。同一厂商不同报价单口径不一致时，以书面确认的版本为准。
服务水平条款写明支持渠道、响应时限分级（如严重故障与一般咨询分别约定）、服务时间窗口和升级路径。验收标准与付款节点一一对应：例如合同签订付首款、试点验收通过付第二笔、全面上线后付尾款，每个节点附可判断的验收条件。数据导出与合同终止后的处理单独约定：终止后数据保留期限、导出协助义务、删除确认方式。
| 条款项 | 要求 | 合同对应位置 | 确认人 |
|---|---|---|---|
| 用户数与计费方式 | 明确计费口径与调整机制 | 价格附件 | 采购 |
| 模块与存储 | 分项计价，超量规则写明 | 价格附件 | 采购 |
| 实施服务 | 范围、人天、交付物明确 | 服务条款 | 采购与业务 |
| 服务水平 | 响应时限分级，升级路径清晰 | 服务级别附件 | 采购 |
| 验收与付款 | 节点与验收条件一一对应 | 付款条款 | 业务与采购 |
| 终止后数据处理 | 保留期限、导出协助、删除确认 | 数据条款 | 法务 |
试点验收：用可观察结果决定是否全面上线
试点是在真实业务中验证系统，与演示阶段的区别在于使用真实数据、真实用户和真实工作节奏。试点范围选一个完整业务单元或一条完整业务线，周期建议四到八周，覆盖项目负责人、执行成员和管理层三类角色，参与人数以能形成真实协作量为准。
验收指标在试点启动前设定，并明确取数方式。常用指标包括：核心流程在系统内完成的比例、任务按时更新率、周报或进度汇总的生成方式是否从手工转为系统输出、用户反馈中阻断级问题的数量。每个指标给出目标值、数据来源和统计周期，避免试点结束后再补口径。
试点期间建立问题清单，按阻断、重要、一般三级分类。阻断级问题指导致核心流程无法在系统内完成的问题，关闭标准是复现路径验证通过并由提出人确认；重要问题约定关闭时限；一般问题可转入上线后迭代。试点结束召开验收评审会，对照指标给出三种结论之一：全面上线、延期继续试点、终止合作。延期需写明补充验证的具体事项和时限。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 试点范围与周期 | 范围、周期、角色书面确定 | 试点方案 | 业务负责人 |
| 验收指标 | 指标、目标值、取数方式事先约定 | 指标定义表 | 业务负责人 |
| 问题关闭 | 阻断级问题全部关闭并复验 | 问题清单与复验记录 | IT/信息化 |
| 验收结论 | 三选一结论有指标数据支撑 | 试点验收表 | 选型小组组长 |
阻断项清单与完成条件
阻断项是触发后必须停下处理、不得进入下一阶段的检查项。识别标准有两条：该检查项对应需求表中的必须项；或该问题会导致核心业务流程无法完成、数据无法安全处置、合同存在重大口径缺失。普通体验问题和可绕行的功能差距不列为阻断项，转入加分项记录或上线后迭代清单。
| 阻断项 | 所属阶段 | 关闭条件 | 确认人 |
|---|---|---|---|
| 必须项未逐条确认 | 需求立项 | 必须项清单签字，权重与评分口径确认 | 选型小组组长 |
| 候选不满足必须项仍进入演示 | 候选初筛 | 补充书面依据或移出候选名单 | IT/信息化 |
| 核心场景验收点不满足 | 场景演示 | 厂商给出方案并在约定时间内复验通过 | 业务负责人 |
| 身份认证或关键集成无法验证 | 技术与安全 | 测试环境联调通过并留存记录 | IT/信息化 |
| 安全合规材料缺失或主体不符 | 技术与安全 | 补齐正式文件，主体与签约方一致 | 安全 |
| 价格口径或退出条款缺失 | 商务与合同 | 条款写入合同并经法务确认 | 采购与法务 |
| 试点阻断级问题未关闭 | 试点验收 | 问题复验通过，提出人确认关闭 | 业务负责人 |
阻断项未关闭时的处理规则统一为：暂停当前阶段，登记阻断项并指定关闭责任人与时限；时限内无法关闭的，由选型小组组长决定是延期、调整需求还是终止该候选。任何阻断项不得以“上线后再解决”的方式带过，除非经组长书面批准并列入合同附件。
完成选型的条件可以归纳为四条同时成立：需求表已签字且未发生未记录的变更；入选产品在演示与试点中核心场景验收点全部满足；技术与安全阻断项全部关闭且材料齐备；合同条款覆盖价格口径、服务水平、验收付款与终止后数据处理。四条齐备后，选型小组出具选型结论报告，连同各阶段检查表、证据附件和阻断项登记表一并归档，作为上线后复盘和合同履约的依据。
常见问题
必须项定得太多导致候选全部出局，怎么调整？
先回到需求立项阶段的判断方法：逐条问“如果这条不满足，我们是否愿意放弃这家厂商”，答案为否的条目移入加分项。必须项通常控制在十条左右，聚焦部署方式、账号体系、必须打通的系统类别和数据合规要求这类硬条件。调整必须项属于需求变更，需要走书面变更记录并由选型小组组长确认，避免在初筛或演示阶段临时放宽标准。
厂商在演示中用自己的演示环境，不按我们的脚本准备，怎么处理？
演示脚本和验收点应在演示前至少三个工作日书面送达厂商，并明确要求使用按脚本准备的真实数据环境。若厂商仍按标准脚本展示，评审方可以只对已覆盖的验收点作判定，未覆盖的验收点记为“待补证据”，由厂商另行安排补充演示。核心场景验收点没有判定结论的，不进入技术与安全评审。
试点期间业务部门提出新增需求，是否要重新走选型流程？
区分两种情况。若新增需求属于原需求表已覆盖的场景细节，可在试点问题清单中记录，按重要或一般问题处理；若新增需求触及必须项，例如要求新的部署方式或新的系统集成，则属于需求变更，需要评估是否影响已通过的评审结论，必要时退回需求立项阶段补充确认。变更都应留下书面记录，作为选型结论报告的附件。
安全合规材料由厂商提供，评审时重点核对什么？
重点核对三点：材料是否为正式文件而非宣传页摘录；证书或报告的主体与合同签约主体是否一致；材料的覆盖范围是否包含本次选型涉及的部署方式和业务模块。材料缺失或主体不符属于技术与安全阶段的阻断项，关闭条件是补齐正式文件并经安全确认。具体认证要求以企业自身合规要求为准，清单不预设统一标准。
选型过程中的评审记录和问题跟踪放在哪里比较合适？
关键是让每条需求、评审意见和待补证据都有唯一确认人和可查状态。可以用协作平台承载：ONES Project 提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把需求条目、评审意见和阻断项作为工作项跟踪。若选型范围包含测试管理，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，可在评审中一并验证测试流程闭环。
