项目管理方法选择评估表用于在项目启动前判断该项目更适合瀑布、敏捷还是混合管理方式。一份可用的模板应包含四部分：项目特征清单、权重与评分口径、否决项检查、结论记录字段。填写时先记录项目事实，再按权重计算得分，最后用否决项排除不适用方法，让选择结论有据可查。以下模板适用于单个项目的方法选择评估，组织级流程制度不在本文范围。
要点总览（TL;DR）
- 评估表由四部分组成：项目特征清单、权重与评分口径、否决项检查、结论记录字段，四张表使用同一套字段名称便于交叉核对。
- 七个项目特征按1–5分制打分，分值越高越偏向计划驱动；评分依据栏需写明可核查的文件或记录名称，否则无法复核。
- 权重合计归一化为100%，加权得分用于区分适配程度；判定顺序为先查否决项再看加权分，避免高分方法被排除后结论难以解释。
- 必填字段包括项目名称、评估日期、评估人、特征取值与依据、否决项结论、最终方法与理由、复核时间，缺失必填项时评估不进入审批。
- 模板应保留版本号与变更日志，特征增删、权重复核与否决项变更分别设置触发条件和审批要求，评估记录注明所用版本。
可复制空白评估表模板
以下四张表可直接复制到文档或表格工具中使用。表1记录项目事实，表2把事实换算成分数，表3做一票排除检查，表4固化结论与责任人。四张表使用同一套字段名称，便于交叉核对。
表1：项目特征评分表
| 序号 | 项目特征 | 取值档位 | 评分（1–5） | 评分依据（证据） |
|---|---|---|---|---|
| 1 | 需求稳定性 | |||
| 2 | 交付节奏 | |||
| 3 | 合规与文档要求 | |||
| 4 | 干系人分布 | |||
| 5 | 团队规模与经验 | |||
| 6 | 变更频率 | |||
| 7 | 外部依赖 |
表2：权重与加权得分表
| 项目特征 | 权重（%） | 评分（1–5） | 加权得分（权重×评分） |
|---|---|---|---|
| 需求稳定性 | |||
| 交付节奏 | |||
| 合规与文档要求 | |||
| 干系人分布 | |||
| 团队规模与经验 | |||
| 变更频率 | |||
| 外部依赖 | |||
| 合计 | 100 | — |
表3：否决项检查表
| 否决项类型 | 具体条件描述 | 是否触发（是/否） | 被排除的方法 | 依据与说明 |
|---|---|---|---|---|
| 合规强制 | ||||
| 合同约束 | ||||
| 交付窗口 | ||||
| 资源硬约束 |
表4：结论与记录表
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 评估日期 | |
| 评估人 | |
| 加权总分 | |
| 否决项结论 | |
| 最终选用方法 | |
| 选择理由 | |
| 复核时间 | |
| 备注 |
项目特征字段说明与评分口径
特征字段决定评估表能否被不同评估人填出一致结果。每个特征应给出明确的取值档位和对应分值，评分依据栏填写可核查的证据，例如需求文档版本、合同条款编号、里程碑计划或团队履历。评分统一采用1–5分制，分值越高表示该特征越偏向计划驱动、阶段交付的管理方式；分值越低表示越适合迭代推进。这一方向约定应在模板中写明，避免不同评估人反向理解。
| 项目特征 | 取值档位 | 对应分值 | 评分依据应写什么 |
|---|---|---|---|
| 需求稳定性 | 需求已冻结且变更需审批 / 主体明确、局部待细化 / 需求方向明确但细节持续演进 / 需求处于探索阶段 | 5 / 4 / 2 / 1 | 需求基线文档版本、变更审批记录、需求评审纪要 |
| 交付节奏 | 一次性整体交付 / 少数几个大阶段交付 / 按月或按双周迭代交付 / 持续小批量交付 | 5 / 4 / 2 / 1 | 合同交付条款、里程碑计划、发布日历 |
| 合规与文档要求 | 强监管，需完整阶段文档与审计留痕 / 有内部评审与文档规范 / 文档要求一般 / 文档要求较少 | 5 / 4 / 2 / 1 | 行业监管要求、合同中的文档交付清单、内控规定 |
| 干系人分布 | 多部门或多方参与，需阶段确认 / 主要干系人集中、确认环节较少 / 单一业务方直接对接 | 5 / 3 / 1 | 干系人清单、确认签字流程、跨方协调会议记录 |
| 团队规模与经验 | 大团队、跨专业协作、需明确分工与阶段交接 / 中等团队、经验混合 / 小团队、经验成熟可自组织 | 5 / 3 / 1 | 团队名单、角色分工表、成员项目履历 |
| 变更频率 | 变更少且需正式变更控制 / 变更偶发 / 变更频繁 / 变更持续且需快速响应 | 5 / 3 / 2 / 1 | 历史变更单数量、变更审批周期记录 |
| 外部依赖 | 依赖多个外部供应商且交付节点固定 / 有少量外部依赖 / 基本无外部依赖 | 5 / 3 / 1 | 供应商合同、接口交付计划、依赖方确认函 |
评分依据栏是评估表可追溯的关键。只写“需求较稳定”无法复核，应写“需求基线v2.0已于某日期评审通过，变更需走审批”。当同一特征存在多个证据且结论不一致时，以正式书面文件为准，并在依据栏注明冲突点，交由评估负责人裁定。
权重设置与否决项判定规则
权重回答的是“哪些特征对方法选择影响更大”。分配原则是：与交付方式和治理强度直接相关的特征权重更高，背景性特征权重较低。常见做法是需求稳定性、交付节奏、合规与文档要求各占20%左右，变更频率占15%，干系人分布、团队规模与经验、外部依赖合计约25%。具体数值应结合组织项目类型调整，但所有特征权重合计必须归一化为100%，否则加权得分无法横向比较。
归一化方法：先按重要性给各特征分配相对权重值，再计算每个特征权重占权重总和的比例，换算成百分比并保留整数。调整后若合计不等于100%，将差额计入权重最高的特征，并在变更日志中记录调整原因。
否决项用于一票排除某种方法，与加权分是两道独立关卡。判定顺序建议为：先查否决项，再看加权分。原因是加权分只能说明适配程度高低，无法表达“某方法在本项目不可用”的硬约束。若先算分再否决，容易出现高分方法被排除后结论难以解释的情况。
| 否决项类型 | 典型条件 | 触发后的处理 |
|---|---|---|
| 合规强制 | 行业监管或内控要求必须保留完整阶段评审与文档审计轨迹 | 排除无阶段评审记录的纯迭代方法，或要求以混合方式补齐阶段文档 |
| 合同约束 | 合同约定固定总价、固定范围与验收节点 | 排除范围完全开放、按迭代增量结算的方法 |
| 交付窗口 | 存在不可移动的对外交付日期，且范围已锁定 | 排除以持续探索为主、交付时间不确定的方法 |
| 资源硬约束 | 关键角色无法全职投入，或外部依赖方按固定排期交付 | 排除需要高频同步、角色全程在线的方法 |
否决触发后，在表3记录触发条件、被排除的方法和依据文件编号，并在表4的“否决项结论”中写明“某方法因某条件被排除”。若所有候选方法均被否决，应记录为“需调整项目条件后重新评估”，不强行给出结论。
必填与选填字段划分
评估表字段过多会增加填写负担，字段过少则无法追溯。建议按以下方式划分必填与选填，并在模板中标注。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 项目名称 | 必填 | 与立项名称一致 |
| 评估日期 | 必填 | 记录评估完成日期 |
| 评估人 | 必填 | 填写主要评估人及其角色 |
| 各特征取值与评分 | 必填 | 七个特征均需给出档位和分值 |
| 评分依据 | 必填 | 至少填写可核查的文件或记录名称 |
| 否决项结论 | 必填 | 逐项填写是否触发；未触发也需写明“否” |
| 最终选用方法 | 必填 | 瀑布、敏捷或混合，并写明组合方式 |
| 选择理由 | 必填 | 说明加权分与否决项如何共同支撑结论 |
| 复核时间 | 必填 | 约定下次复核节点 |
| 备注 | 选填 | 补充特殊说明 |
| 参考历史项目 | 选填 | 列出可类比的历史项目及其方法 |
| 附加风险说明 | 选填 | 记录评估中发现的待观察风险 |
缺失必填项时，评估表不应进入审批或作为方法选择依据。处理方式是退回补充：特征取值缺失的，由评估人补充证据后重新打分；否决项结论缺失的，视为评估未完成；最终方法与理由缺失的，结论无效。选填字段缺失不影响评估有效性，但若评估中已识别出重大风险，应转入附加风险说明，避免信息只停留在口头讨论。
填写示例：一个完整评估记录
以下示例为演示情景，用于说明字段如何填写，不对应真实项目。某企业计划建设一套内部业务系统，合同约定固定范围与验收节点，需求在立项阶段已基本冻结，参与方包括业务部门、信息技术部门和一家外部集成商。
| 项目特征 | 取值档位 | 评分 | 评分依据 | 权重 | 加权得分 |
|---|---|---|---|---|---|
| 需求稳定性 | 需求已冻结且变更需审批 | 5 | 需求基线v1.0评审通过，变更走审批单 | 20% | 1.00 |
| 交付节奏 | 少数几个大阶段交付 | 4 | 合同约定三个验收节点 | 20% | 0.80 |
| 合规与文档要求 | 有内部评审与文档规范 | 4 | 内控要求阶段评审记录与交付文档清单 | 20% | 0.80 |
| 干系人分布 | 多部门参与，需阶段确认 | 5 | 业务、信息技术、集成商三方确认流程 | 10% | 0.50 |
| 团队规模与经验 | 中等团队、经验混合 | 3 | 团队12人，含新成员若干 | 10% | 0.30 |
| 变更频率 | 变更偶发 | 3 | 历史同类项目变更单约每月一次 | 15% | 0.45 |
| 外部依赖 | 少量外部依赖 | 3 | 集成商按接口计划交付 | 5% | 0.15 |
| 合计 | — | — | — | 100% | 4.00 |
加权得分计算方式为权重乘以评分后求和，本例合计4.00分（满分5分），整体偏向计划驱动。否决项检查结果：合规强制项未触发，但合同约束项触发——合同约定固定总价与固定范围，排除范围完全开放、按迭代增量结算的方法；交付窗口项未触发；资源硬约束项未触发。
结论记录写法示例：“最终选用瀑布方法，在测试与验收阶段引入迭代式缺陷修复节奏，形成混合执行方式。理由：加权得分4.00，需求稳定性与交付节奏两项高分支撑阶段化推进；合同约束否决项排除了范围开放型迭代方法；为应对集成商接口联调的不确定性，在阶段内部采用短周期跟踪。”复核时间填写为下一阶段启动前，评估人填写项目负责人与项目管理办公室代表。
评估记录形成后，需要落到团队日常使用的工具中才能被持续引用。ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，评估表可作为项目文档与立项工作项关联留档；ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，评估结论确定后可直接选用对应模板建立项目。对于目标、范围和交付节点较明确、需要按计划推进的项目，瀑布式管理通常更具适用性，这与示例中的评估方向一致。
模板的调整与维护方法
评估表需要随项目类型和组织经验更新，否则会出现特征与实际脱节、权重长期不变的问题。维护工作应指定负责人，并按变更类型设置不同的触发条件和审批要求。
新增或删除特征的触发条件包括：连续多个项目在评估中出现同一类未被覆盖的影响因素；某特征在多数项目中取值相同、无法区分方法差异；组织引入新的交付模式或监管要求。新增特征需同时给出取值档位、分值和评分依据要求，并同步调整权重合计。
权重复核建议按固定节奏进行，例如每半年或每完成一批项目后复核一次。复核依据是历史项目的实际执行情况：若某特征高分项目最终仍频繁调整计划，说明该特征权重或评分口径需要修正。复核结论应记录调整前后的数值和原因。
否决项变更涉及方法可用性的硬约束，应经过审批后生效。审批人建议为项目管理办公室负责人或质量负责人，变更记录需写明触发条件、影响范围和生效日期。已按旧版完成的评估不追溯重算，但应在记录中注明所用模板版本。
| 版本号 | 变更日期 | 变更类型 | 变更内容 | 触发原因 | 审批人 | 生效日期 |
|---|---|---|---|---|---|---|
| v1.0 | 初始发布 | 建立七项特征、权重与否决项 | ||||
| v1.1 | 权重调整 | 调整变更频率权重 | ||||
| v1.2 | 否决项变更 | 新增或修改某类否决条件 |
模板文件应保留版本号与变更日志，评估记录中注明所用版本。这样在回顾方法选择是否合理时，可以区分是评估判断问题还是模板口径变化，避免用新标准评价旧结论。
常见问题
评估表填完后，加权得分高就一定选瀑布方法吗？
不一定。加权得分只反映项目特征整体偏向哪种管理方式，最终结论还要经过否决项过滤。如果合同约定固定总价与固定范围，即使得分偏向迭代推进，范围开放型方法也会被排除。反过来，得分不高但否决项均未触发时，可以在候选方法中结合团队经验做取舍，并在选择理由中写明依据。
项目启动时信息不全，特征取值填不出来怎么办？
先区分哪些特征已有书面依据、哪些只能估计。有依据的按档位正常打分；只能估计的特征在评分依据栏注明“暂估”及估计来源，例如初步需求清单或口头确认记录。否决项检查不能暂估，涉及合规、合同、交付窗口和资源硬约束的条件必须取得正式文件后再判定。信息缺口较大的项目，可先给出临时结论并约定复核时间，待需求基线或合同条款明确后重新评估。
多个候选方法得分接近时，如何形成可追溯的结论？
得分接近说明特征本身不足以区分方法，此时应在选择理由中补充说明取舍依据，例如团队对某种方式的熟悉程度、试点经验或交付风险。也可以对权重做敏感性检查：调整某一特征权重后结论是否改变，若改变则说明该特征需要更准确的证据。无论采用哪种方式，调整过程和最终理由都应写入记录表，便于后续回顾。
否决项触发后，是否还能通过调整项目条件重新评估？
可以。否决项排除的是当前条件下某种方法的适用性，条件变化后结论可能不同。例如合同范围重新谈判、交付窗口调整或关键角色到位后，原先触发的否决条件可能不再成立。重新评估时应保留上一版记录，注明条件变化内容和新的判定结果，并更新复核时间。若所有候选方法均被否决，记录为需调整项目条件后重新评估，不强行给出结论。
评估表在团队日常工具中如何留档，方便后续引用？
评估表形成后需要与项目立项记录放在一起，才能被持续引用。ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，评估表可作为项目文档与立项工作项关联留档；ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，评估结论确定后可直接选用对应模板建立项目。这样在项目复盘或方法调整时，可以直接回到评估记录核对当时的事实与判断。
