单项目选方法，先看需求和技术有多确定，再看合规、外部依赖和交付节点有多硬，然后按“界定不确定性—拆解交付物与约束—匹配方法—设计混合边界—试点验证”五步走完，产出一份写清判断依据、方法组合、角色分工、阶段门和复核时点的方法选择记录。下文给出可直接填写的判断表、选择记录模板、角色责任矩阵和一个软硬件结合项目的完整示例。
要点总览（TL;DR）
- 方法选择从确定性判断开始：需求、技术方案、合规与外部依赖三类维度各写结论和依据，刚性约束决定必须保留的阶段门。
- 按“界定范围与不确定性—拆解交付物与里程碑—匹配候选方法—设计混合边界—试点复核”五步推进，每步都有输入、动作、输出和完成标志。
- 瀑布适合需求稳定、外部节点刚性的部分；迭代适合可分批验证、反馈周期短的部分；混合按阶段、模块或交付批次划分，分界点要对应具体交付物和确认人。
- 方法选择由项目经理牵头，产品、技术、质量与合规角色共同参与，产出方法选择记录、阶段计划、迭代计划和评审记录，变更走提出—评审—批准路径。
- 用一个小交付周期试点，观察分界点交接、评审按时率和变更处理情况，出现连续交接不畅或阶段门反复退回时回到方法匹配步骤调整。
先判断项目确定性：方法选择的起点
方法选择的第一个动作是判断项目确定性，判断结果决定候选方法的范围。凭团队习惯或上一项目沿用的流程选方法，容易在需求频繁变化时被阶段门卡住，或在外部依赖很强时因迭代节奏失控。确定性判断围绕三类维度展开，每类都要求写下结论和依据。
三类判断维度
| 判断维度 | 要问的问题 | 结论倾向 |
|---|---|---|
| 需求确定性 | 验收标准能否在启动时写清？需求变更的频率和来源是否可预期？ | 需求稳定且可前置验收，倾向瀑布；需求可分批澄清、需要用户反馈，倾向迭代 |
| 技术方案确定性 | 关键技术是否已验证？是否存在需要试验才能确定的技术路径？ | 技术路径成熟，倾向瀑布；存在技术探索，倾向迭代或混合 |
| 合规与外部依赖 | 是否有强制评审、认证、第三方交付或固定窗口期？ | 外部节点刚性，相关部分倾向瀑布；内部可自主排期的部分可迭代 |
三类判断不是打分求和，而是识别哪些约束是刚性的。刚性约束决定必须保留的阶段门和评审点，柔性部分才留给迭代节奏。例如产品需通过外部认证，认证送审就是一个不可移动的节点，围绕它安排瀑布式阶段；认证之外的软件功能仍可按迭代推进。
判断结果的记录方式
判断结果用一页表记录，字段包括判断项、结论、依据、影响。判断项按上述三类展开，结论写“确定／部分确定／不确定”，依据写具体事实而非印象，影响写这一结论对方法选择的指向。例如“需求确定性：部分确定；依据：核心流程已确认，报表需求待业务方试用后反馈；影响：核心流程按阶段交付，报表模块按迭代推进”。这张表是后续五步操作的输入，也是方法选择记录的第一部分。
五步完成单项目方法选择
五步操作按顺序推进，每步都有明确输入、动作、输出和完成标志。完成标志是判断这一步能否结束的依据，避免在判断不充分时提前进入方法匹配。
第一步：界定范围与不确定性
输入是项目立项信息和确定性判断表。动作是明确项目边界、主要交付物清单和不确定性最高的三个问题。输出是一页范围说明加不确定性清单。完成标志是项目目标可以用一句话说清，且每个高不确定项都有对应的验证方式或假设。
第二步：拆解交付物与里程碑
输入是范围说明。动作是按交付物或项目阶段做工作分解，标出外部依赖节点和必须评审的决策点，形成里程碑清单。输出是工作分解结构和里程碑清单。完成标志是每个里程碑都有可验收的交付物和责任人，外部节点已标注日期来源。
第三步：匹配候选方法
输入是确定性判断表、里程碑清单和资源约束。动作是对照瀑布、迭代、混合的适用条件，筛出候选方法并写明选择理由。输出是候选方法及理由。完成标志是每个候选方法都能对应到具体的判断项，而不是笼统写“团队熟悉敏捷”。
第四步：设计混合边界
输入是候选方法和里程碑清单。动作是确定按阶段、按模块还是按交付批次划分方法边界，明确每一段的评审方式、验收标准和交接物。输出是方法边界说明。完成标志是每个分界点都写清了“谁在什么时点用什么标准确认这一段完成”。
第五步：试点与复核
输入是方法边界说明。动作是选一个小交付周期试运行，设定观察指标和复核时点。输出是试点结论和调整后的方法选择记录。完成标志是试点周期结束并形成“保留／调整”的明确结论。
方法选择记录的最小字段
五步的产出汇总为一份方法选择记录，最小字段如下：项目目标、主要约束（含合规与外部依赖）、候选方法及选择理由、混合边界与分界依据、阶段门与检查点、角色分工、复核时点与观察指标。这份记录在项目启动评审时确认，后续方法变更以此为基础修订。
瀑布、迭代与混合的边界怎么划
三种方法形态的差别在于对不确定性的处理方式。瀑布把规划和验收前置，适合需求相对明确、计划性较强的项目；迭代把验收分散到多个短周期，适合需求可分批验证的场景；混合则在同一项目内按部分选择形态。判断边界时，先看哪部分约束是刚性的，再看哪部分可以分批获得反馈。
| 方法形态 | 适用条件 | 不适用信号 |
|---|---|---|
| 瀑布 | 需求稳定、验收标准可前置；外部依赖强、有固定评审或认证节点；目标、范围和交付节点较明确且需按计划推进 | 需求在启动时无法写清，或用户反馈只能在交付后获得 |
| 迭代 | 需求可分批澄清和验证；反馈周期短，用户或业务方能在每个周期内给出意见；技术路径需要试验 | 存在不可拆分的强制评审节点，或每轮交付都需要完整验收 |
| 混合 | 项目内同时存在刚性节点和可探索部分；不同模块的确定性差异明显 | 分界点无法对应到具体交付物，导致责任和验收标准模糊 |
混合项目的三种分界方式
按阶段划分：前期需求与方案阶段用瀑布式评审锁定基线，开发阶段按迭代推进，交付前回到瀑布式验收。按模块划分：合规、硬件、外部接口等确定性高的模块走阶段门，软件功能、界面、报表等可试用验证的模块走迭代。按交付批次划分：首批交付满足最小可用范围并按固定节点验收，后续批次按迭代节奏补充。
分界点的判定依据要写进选择记录：分界对应哪个交付物、该交付物的验收标准由谁确认、分界两侧的交接物是什么、分界点的评审在哪个时点进行。分界点写不清，混合方法就会退化成两套流程并行、责任互相推诿。
角色分工与各阶段交付物
方法选择由项目经理牵头，产品、技术、质量与合规角色共同参与判断，避免方法由单一角色决定后在执行阶段被推翻。各角色在选择与执行中的职责如下。
| 角色 | 方法选择中的职责 | 执行中的职责 |
|---|---|---|
| 项目经理 | 组织确定性判断，汇总方法选择记录，主持分界点设计 | 维护阶段门与检查点，跟踪偏差，发起方法变更评审 |
| 产品／需求负责人 | 给出需求确定性结论和验收标准草案 | 确认迭代周期的需求范围，参与阶段评审 |
| 技术负责人 | 判断技术方案确定性和技术验证需求 | 负责技术方案评审，确认迭代内的技术交付物 |
| 质量与合规角色 | 列出强制评审、认证和验收要求 | 执行阶段门检查，出具评审记录 |
交付物与责任人
方法选择记录由项目经理在启动阶段完成，产品和技术负责人提供判断依据，质量与合规角色确认强制节点。阶段计划由项目经理编制，在阶段门评审时确认。迭代计划由产品负责人和团队在每个迭代开始时确定。评审记录由质量与合规角色在每次阶段门后归档。各交付物都标注责任人和完成时点，作为方法执行的检查依据。
方法变更路径
执行中出现需求大幅变化、关键技术验证失败或外部节点调整时，由项目经理提出变更，说明触发原因、影响范围和拟调整的分界方式，经产品、技术负责人评审、项目决策人批准后更新方法选择记录。变更记录保留原判断依据，便于复盘时区分“判断失误”和“条件变化”。
这些记录和阶段门需要在协作工具中承载时，ONES 提供敏捷、瀑布、通用任务协同等多种项目模板，可用项目计划做工作分解、设置任务前后置依赖和里程碑，并通过计划和里程碑基线对比执行偏差。方法选择记录本身可作为项目文档随阶段门归档，使判断依据、评审结论和变更历史留在同一处。
示例：一个软硬件结合项目的混合方法选择
以下为演示情景，用于说明五步方法如何落地，不对应具体企业案例。
项目背景与确定性判断
某团队开发一套带采集终端的现场管理系统，包含硬件终端、后台软件和移动端应用。需求确定性：后台核心流程已确认，移动端报表需求待现场试用后反馈，结论为部分确定。技术方案确定性：终端通信协议已有成熟方案，后台数据模型需在试用中调整，结论为部分确定。合规与外部依赖：终端需通过行业认证，认证送审日期固定，结论为刚性约束。
选择理由与分界方式
认证节点不可移动，终端硬件和认证相关部分按瀑布推进，阶段门设在方案冻结、样机完成和送审三个时点。后台软件和移动端按迭代推进，每两周一个周期，现场试用反馈进入下一周期需求池。分界点定在“终端与后台接口协议冻结”，该交付物由技术负责人确认，冻结后两侧按各自节奏推进，接口变更走变更评审。
阶段门、迭代节奏与复核指标
阶段门包括方案评审、样机验收和认证送审，由质量与合规角色出具评审记录。迭代节奏为两周一次计划会和评审会。复核指标设为：迭代需求按期完成比例、阶段门一次通过率、接口变更次数。项目启动后第四周做首次复核，若接口变更次数超过约定阈值，则重新评估分界点是否设置过晚。
该示例的方法选择记录包含：项目目标、三类确定性判断及依据、混合方法及理由、分界点与交接物、阶段门清单、迭代节奏、角色分工、复核时点与指标。这份记录在启动评审会上确认，后续调整在此基础上修订。
试点验证与完成检查
方法选择是否可行，要用一个小交付周期验证，而不是等到项目中期才发现流程卡住。试点范围选一个完整的小交付单元，周期通常为一个迭代或一个阶段门间隔，观察指标包括：交付物是否按分界点顺利交接、评审是否在计划时点完成、团队在流程上的等待时间、需求变更是否按路径处理。
完成检查清单
- 确定性判断表已填写，每个判断项有结论和具体依据。
- 方法选择记录包含项目目标、约束、候选方法、选择理由、阶段门、复核时点。
- 每个分界点对应具体交付物、验收标准和确认人。
- 角色分工表已确认，各交付物有责任人和完成时点。
- 方法变更路径已写入记录，评审和批准人明确。
- 试点观察指标和复核时点已设定。
通过标准是：试点周期内阶段门或迭代评审按计划完成，分界点交接未出现责任不清，变更按路径处理。出现以下信号时触发方法调整：连续两个周期交付物无法按分界点交接、阶段门反复因同一类问题退回、需求变更频繁绕过变更路径。调整时回到第三步重新匹配方法，并更新选择记录中的判断依据和复核时点。
常见问题
项目启动时需求还没完全定下来，还能用瀑布方法吗？
可以按部分使用。把需求中已经确认、验收标准能写清的部分放进瀑布式阶段，把仍需试用反馈的部分单独划出来按迭代推进，并在方法选择记录里写明分界点和交接物。如果整个项目的验收标准都无法前置，且反馈只能在交付后获得，那么整体按瀑布推进的风险较高，更适合先做一轮探索性迭代，再决定后续形态。
混合项目里瀑布和迭代的分界点定在哪里比较稳妥？
分界点优先落在有明确交付物和确认人的位置，例如接口协议冻结、方案基线确认、首批交付验收。判断标准是：分界两侧的交接物能说清楚，验收标准有人确认，评审时点能排进计划。分界点定得过晚，迭代侧会长期依赖未冻结的输入；定得过早，又可能把本可探索的部分提前锁死。试点周期内可以观察接口变更次数和交接返工情况，据此调整分界位置。
方法选择记录需要多久复核一次？
复核时点跟着项目节奏走，不必固定为统一周期。常见做法是在试点周期结束时做首次复核，之后在每个阶段门或若干迭代后检查一次。触发临时复核的信号包括：需求大幅变化、关键技术验证失败、外部节点调整、连续两个周期交付物无法按分界点交接。复核结论写“保留”或“调整”，调整时更新判断依据和复核时点，原记录保留以便复盘。
团队规模小、角色兼任时，角色分工表还要做吗？
要做，但可以合并角色。小团队里项目经理可能同时承担产品职责，技术负责人也可能兼质量检查，这时在责任矩阵中把同一人对应的职责列在一起，仍然要写清每项交付物由谁确认、在什么时点确认。关键是避免“分界点没人拍板”和“阶段门评审自己评自己”这两种情况。人员增加或职责拆分时，再按矩阵补充分工。
方法选择记录和阶段门在协作工具里怎么承载？
方法选择记录可以作为项目文档随阶段门归档，阶段门和里程碑在项目计划中设置，迭代计划按周期建立。ONES 提供敏捷、瀑布、通用任务协同等多种项目模板，可用项目计划做工作分解、设置任务前后置依赖和里程碑，并通过计划和里程碑基线对比执行偏差。具体模板配置和版本能力以产品实际提供为准，选型前建议用一个小项目试跑确认操作路径。
