这份项目管理软件选型清单按“需求立项—候选筛选—试用验证—商务与落地”四个阶段展开，每项检查都给出通过标准、所需证据和负责人。使用时先逐项确认阻断项，全部通过后再评估加分项；任一阻断项未通过，就停在当前阶段处理，不进入下一阶段。清单适合项目负责人、IT、采购、财务和业务代表共同使用，在立项前、试用结束和合同签署前三个时点分别核对。
要点总览（TL;DR）
- 先固定需求分级和预算口径，再接触供应商：必须满足项写成可验证条件，许可、实施、培训、运维分项列预算。
- 候选控制在3–5家，按需求分级逐条核对并记录依据来源，避免凭演示印象打分。
- 试用选1–2个真实项目、真实角色参与，用操作记录和观察数据代替主观感受。
- 阻断项一票否决：核心需求缺失、数据无法导出、权限模型不满足、合规不达标、预算超限，任一未通过不进入下一阶段。
- 合同写明验收标准、数据归属与导出、续费涨价规则，上线准备落实到责任人和时间表。
谁在什么时点使用这份清单
选型检查流于形式，常见原因是角色分工不清：需求由业务提，技术由IT看，价格由采购谈，最后没人对“能不能用、值不值得买”整体负责。清单需要先固定参与角色和决策权限，再谈检查内容。
建议设置一个选型小组，由项目负责人担任组长，对整体进度和结论负责；IT/信息化负责部署方式、集成、权限与数据安全核验；采购负责供应商资质、报价口径与合同条款；财务负责预算与付费方式；业务部门代表负责需求确认和试用验证。角色可以兼任，但每项检查要落到具体人名。
| 使用时点 | 主要参与角色 | 本时点要完成的动作 | 决策权限 |
|---|---|---|---|
| 立项前 | 项目负责人、业务代表、IT、财务 | 梳理现状与需求分级，确认预算口径，形成签字版需求清单 | 项目负责人确认需求范围；财务确认预算上限 |
| 试用结束 | 项目负责人、业务代表、IT | 汇总试用记录，逐项判定验证结果，形成候选排序 | 项目负责人对试用结论签字；IT对部署与集成项有一票否决权 |
| 合同签署前 | 采购、财务、IT、项目负责人 | 核对报价、合同条款、上线准备与验收标准 | 采购与财务对商务条款有一票否决权；项目负责人对验收标准有一票否决权 |
阻断项的一票否决权按领域划分：核心业务需求缺失由业务代表否决，数据无法导出、权限模型不满足、合规不达标由IT否决，预算超限由财务否决。否决意见要写明依据和证据，避免口头否决后无法追溯。
第一阶段：需求与立项检查项
这一阶段的目标是在接触供应商之前，把需求、范围和预算口径固定下来。需求清单越具体，后续候选筛选和试用验证越容易判断，也越不容易被演示效果带偏。
先梳理现状：目前在用哪些工具、各自承担什么用途；要管理的项目类型有哪些，例如研发迭代、交付实施、市场活动；团队规模区间是多少人、是否包含外部协作方；现有工具中哪些数据需要延续。现状梳理的产物是一页纸的现状说明，作为需求讨论的输入。
需求按三档分级：必须满足、希望满足、可放弃。“必须满足”写成可验证的条件，例如“支持按项目角色控制任务可见范围”“支持导出全部任务与工时数据”，避免写成“权限灵活”“报表强大”这类无法判断的表述。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 现状梳理 | 在用工具、项目类型、团队规模区间、外部协作方全部列明 | 现状说明文档，业务方确认 | 项目负责人 |
| 需求分级 | 每条需求标注必须满足/希望满足/可放弃，必须满足项写成可验证条件 | 需求清单，业务代表签字 | 业务代表 |
| 预算口径 | 许可、实施、培训、运维四类费用分别列项，给出预算上限 | 预算表，财务确认 | 财务 |
| 人力投入 | 明确内部实施、培训、日常管理的责任人及投入时间 | 人力安排表 | 项目负责人 |
预算要按许可、实施、培训、运维分别列项，避免只比较软件订阅价而忽略实施和培训投入。需求清单经业务方签字确认后，才进入候选筛选阶段；后续新增需求要记录变更原因，不能随时插入。
第二阶段：候选筛选检查项
候选筛选的任务是用统一口径缩小范围，而不是收集越多越好。建议候选控制在3–5家，来源包括同行推荐、行业报告和公开招标信息，每家的入围理由要记录在案。
功能核对按需求分级逐条进行：必须满足项逐条打勾并注明依据来源，例如产品文档、演示确认或供应商书面答复；希望满足项按权重评分。只凭演示印象打分的做法要避免，演示中展示的功能要对应到具体需求条目。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 候选数量与来源 | 候选3–5家，每家记录入围理由与信息来源 | 候选名单及来源记录 | 项目负责人 |
| 功能覆盖核对 | 必须满足项逐条有结论，希望满足项完成评分 | 需求对照表，注明依据来源 | 业务代表、IT |
| 部署方式确认 | 明确SaaS或私有部署，与IT基础设施和安全要求匹配 | 供应商书面说明 | IT |
| 集成能力确认 | 与现有账号体系、代码仓库、消息通知等系统的集成方式有明确结论 | 集成说明或接口文档 | IT |
| 数据导出与迁移 | 确认可导出的数据范围、格式和迁移支持方式 | 供应商书面答复或试用验证记录 | IT |
| 供应商资质与案例 | 营业执照、服务团队、同规模案例可核验 | 资质文件、案例联系人 | 采购 |
数据导出与迁移路径是容易被忽略的检查项，需要在筛选阶段就要求供应商书面说明可导出的数据范围和格式，而不是等到签约前才问。淘汰记录同样要保留：每家候选被淘汰的原因对应到具体检查项，便于复盘和向内部说明。
第三阶段：试用与验证检查项
试用要变成可复现的验证。做法是选1–2个真实项目，让真实角色参与，按预设脚本完成操作并记录结果，而不是观看供应商演示。
试用范围建议覆盖一个进行中的项目和一个小型新项目，参与角色包括项目经理、执行成员和只读查看的外部协作方。验证项至少包括：任务与进度跟踪是否支持工时统计和进度视图；权限与可见性是否满足按角色控制；报表口径是否与内部管理口径一致；移动端能否完成日常查看和更新。
| 验证项 | 通过标准 | 记录方式 | 负责人 |
|---|---|---|---|
| 任务与进度跟踪 | 真实项目的任务拆分、负责人分配、进度更新可完整走通 | 操作记录与截图 | 项目经理 |
| 权限与可见性 | 按角色配置后，外部协作方只能看到授权范围内容 | 权限配置记录与验证结果 | IT |
| 报表口径 | 导出的进度、工时报表与内部统计口径一致或差异可解释 | 报表样本与口径对照说明 | 业务代表 |
| 移动端使用 | 常用操作在移动端可完成，关键页面加载正常 | 移动端操作记录 | 执行成员 |
| 性能与稳定性 | 试用期内记录响应时间、异常次数，达到约定阈值 | 观察记录表 | IT |
性能与稳定性用观察记录代替主观感受：记录试用期内关键操作的响应时间、出现异常的日期和现象、是否影响正常使用。试用结论按规则判定：必须满足项全部通过且阻断项无未通过项，判为通过；存在未通过项但可补测的，安排补测；补测仍不通过的，淘汰该候选。
在需求收集和试用验证环节，可以用ONES Project承载需求池、任务分配和试用问题记录：需求可自定义状态与属性并规划至迭代，任务工时统计和看板、燃尽图用于跟踪进度，多层级权限可按组织架构、用户组和项目角色分配，便于在真实项目中验证权限与可见性。具体能力以官方资料和实际试用为准。
第四阶段：商务、合同与上线准备检查项
签约前的检查重点是价格口径、合同条款和上线准备三件事。报价要按用户数、模块、实施与培训费用分别核对，确认计费周期和用户数计算方式，避免签约后因人数增长产生预期外费用。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 报价口径 | 用户数、模块、实施、培训费用分项列明，计费周期与用户数计算方式书面确认 | 报价单与书面说明 | 采购、财务 |
| 服务级别 | 响应时间、故障处理流程、服务时间写入合同 | 合同条款 | 采购、IT |
| 数据归属与导出 | 数据归属明确，退出时可导出全部数据，格式与期限写入合同 | 合同条款 | IT、采购 |
| 续费与涨价规则 | 续费价格调整方式、提前通知期限有明确约定 | 合同条款 | 财务 |
| 上线准备 | 账号与组织架构导入、权限初始化、培训安排有责任人和时间表 | 上线计划表 | 项目负责人、IT |
| 验收标准 | 验收条件、验收方式和验收期限写入合同 | 合同条款 | 项目负责人 |
验收标准要写成可判断的条件，例如“约定范围内的用户完成登录并完成一次任务流转”“权限配置经IT核验符合要求”，并写明验收期限和未通过时的处理方式。上线准备包括账号与组织架构导入、权限初始化、培训安排，每项指定责任人和完成时间。
阻断项清单与整体完成条件
阻断项是不能妥协的条件，任何一项未通过，都不进入下一阶段。把阻断项单独列出，可以避免在总分评估中被其他加分项掩盖。
| 阻断项 | 判定证据 | 否决方 |
|---|---|---|
| 核心需求缺失 | 必须满足项中存在未通过条目，且有书面核对记录 | 业务代表 |
| 数据无法导出 | 供应商无法书面确认导出范围与格式，或试用中导出失败 | IT |
| 权限模型不满足 | 试用中按角色配置后仍无法满足可见性要求 | IT |
| 合规要求不达标 | 资质或合规材料经核验不符合内部要求 | IT |
| 预算超限 | 分项报价合计超出财务确认的预算上限 | 财务 |
整体完成条件是：阻断项全部通过，且加分项达到事先约定的分值。加分项可包括报表丰富度、移动端体验、集成便利性等，权重在立项阶段确定，避免试用后再调整评分标准。
未通过时的处理路径有三条：属于信息不足或操作问题的，安排补测并记录补测结果；属于产品能力不满足的，换候选重新进入筛选或试用；属于预算或时机问题的，暂缓采购并保留需求清单，待条件变化后重启。每条路径都要留下书面记录，作为下一轮选型的输入。
常见问题
需求清单签字后，业务方又提出新需求，清单怎么处理？
新增需求按变更处理，不直接插入原清单。由提出方写明需求内容、属于哪一档分级、对预算和试用范围的影响，交项目负责人和业务代表确认。若属于必须满足项，需要重新评估候选是否满足，必要时回到候选筛选阶段；若属于希望满足项，记录为加分项并在评分标准中体现。变更记录保留在案，作为后续复盘和向供应商沟通的依据。
试用阶段发现某个必须满足项不通过，但供应商承诺后续版本会支持，能否继续推进？
承诺不能替代验证。该项仍按未通过处理，是否继续推进取决于两点：一是该需求是否属于阻断项，属于阻断项则当前不进入下一阶段；二是能否拿到书面承诺，写明功能范围、交付时间和未按期交付的处理方式。即使拿到书面承诺，也建议在合同中约定验收条件，把该功能纳入验收范围，验收通过后再完成付款或扩大使用范围。
候选只有一家能满足必须满足项，还需要走完整清单吗？
需要。单一候选时，清单的作用从比较转为核验：逐条确认必须满足项的依据来源，重点检查数据导出、权限模型、合规资质和商务条款这些容易在演示中被忽略的部分。同时记录候选数量受限的原因，例如市场供给有限或需求特殊。单一候选的谈判空间较小，更要在合同条款和验收标准上把关。
清单里的阻断项和加分项权重，应该在什么时候确定？
在立项阶段确定，写入需求清单并经业务方和财务确认。试用结束后再调整评分标准，会让结论失去可比性。加分项可包括报表丰富度、移动端体验、集成便利性等，权重按业务优先级分配；阻断项不参与加权，单独判定。若立项后业务方向发生重大变化，应重新走需求确认流程，而不是在评分表上临时改权重。
ONES Project 在这份清单里可以承担哪些环节？
在需求收集和试用验证环节，可以用 ONES Project 承载需求池、任务分配和试用问题记录：需求支持自定义状态与属性并规划至迭代，任务工时统计与看板、燃尽图用于跟踪进度，多层级权限可按组织架构、用户组和项目角色分配，便于在真实项目中验证权限与可见性。部署方式、价格、数据导出与合规认证等事项，仍需按清单要求向供应商书面确认，具体能力以官方资料和实际试用为准。
