里程碑管理、任务排期和阶段评审经常出现在同一张项目计划里，边界却容易混在一起：有人把里程碑当成大任务排进甘特图，有人用评审会代替节点达成判定，也有人把任务延期直接写成里程碑顺延。三者的分工可以这样理解：里程碑管理负责定义关键节点、判定是否达成并处置偏差；任务排期负责把工作拆成任务，安排时间、依赖和责任人；阶段评审负责在节点上组织干系人做出通过、有条件通过或退回的决策。本文围绕这三个管理对象说明划分规则、衔接流程和常见误解，并在衔接环节说明ONES如何承载节点、任务与评审记录。
要点总览（TL;DR）
- 里程碑管理管关键节点与达成证据，任务排期管任务、时间与依赖，阶段评审管评审结论与决策记录，三者共享同一批节点但核心对象不同。
- 边界可按四条规则划分：看管理对象、看时间粒度、看决策权、看产出物；四条规则指向一致时归属即无争议。
- 衔接链路是：从里程碑倒推任务排期，任务完成汇总为达成证据，节点到期触发阶段评审，评审结论驱动节点状态更新，整改项回流排期。
- 常见误解包括把里程碑当大任务排期、用评审会代替达成判定、里程碑日期随意顺延；纠正的关键是分别记录确认动作与评审结论，日期调整走变更。
- ONES 可在项目计划中分解工作、设置任务依赖并用里程碑标记关键节点，支持里程碑基线对比与变更追溯；具体版本与配置以产品文档为准。
里程碑、任务排期、阶段评审各自管什么
三者共享同一批项目节点，但管理的核心对象不同。先把各自管什么说清楚，边界才有讨论基础。
里程碑：管关键节点与达成证据
里程碑是项目中的关键时间点、事件或决策点，用可判定的完成标准来描述，通常对应一项交付物或一次决策。例如“需求基线确认”“开发完成”“生产上线”都可以设为里程碑。里程碑管理的核心对象是节点本身及其达成证据：节点何时到期、达成标准是什么、由谁确认、支撑达成的材料是否齐备。里程碑不承载工时，也不直接分配执行工作。
任务排期：管任务、时间与依赖
任务排期把项目范围拆解为可执行的任务，为每项任务安排起止时间、前后置依赖和责任人。它的核心对象是任务与依赖关系：谁在什么时间做什么、任务之间谁先谁后、资源是否冲突。排期关注的是节点之间的执行安排，产出是排期计划与依赖关系，而不是节点是否达成的结论。
阶段评审：管评审结论与决策记录
阶段评审是在关键节点上组织的决策活动：召集干系人，审阅节点交付物与达成证据，形成通过、有条件通过或退回的明确结论，并记录决策依据与后续整改要求。它的核心对象是评审结论与决策记录。评审本身不修改排期，也不直接改变任务状态，它的产出是结论，结论再驱动节点状态和后续工作。
| 管理类型 | 核心管理对象 | 典型产出物 | 不负责的事 |
|---|---|---|---|
| 里程碑管理 | 关键节点与达成证据 | 里程碑清单、达成标准、确认记录 | 不拆解执行任务，不分配工时 |
| 任务排期 | 任务、时间与依赖 | 排期计划、依赖关系、责任人分工 | 不判定节点是否达成，不给出评审结论 |
| 阶段评审 | 评审结论与决策记录 | 评审材料、评审结论、整改项 | 不替代节点定义，不直接调整排期 |
三者的边界线画在哪里
边界划分可以落到四条可操作的规则上：看管理对象、看时间粒度、看决策权、看产出物。四条规则指向同一结论时，归属就没有争议。
按管理对象划分
节点及其达成证据归里程碑管理；任务、依赖与责任人归任务排期；评审结论与决策记录归阶段评审。遇到一件具体的事，先问它改变的是哪类对象：修改节点达成标准属于里程碑管理；调整某任务的负责人属于排期；形成“有条件通过”的结论属于评审。
按时间粒度划分
里程碑看关键节点，通常以周或月为观察尺度，数量有限且集中在交付物和决策点上；任务排期看周级、日级的执行安排，颗粒度细、调整频繁。粒度差异带来一个实用判断：需要每天跟踪进展的事项放进排期，只需要在节点到期时确认状态的事项留在里程碑层。
按决策权划分
里程碑是否达成，由对该节点负责的确认人依据达成标准判定；阶段评审结论由评审组或指定的决策角色给出。两者可以是同一批人，但动作不同：确认达成是核对证据，评审结论是做出决策。把这两个动作分开记录，后续追溯时才能分清“证据齐了”和“评审通过了”。
按产出物划分
里程碑管理的产出是里程碑清单与达成证据；任务排期的产出是排期计划与依赖关系；阶段评审的产出是评审记录与决策结论。产出物也是验收边界：节点到期时，检查的是证据是否齐备；排期执行中，检查的是任务进度与依赖是否满足；评审结束时，检查的是结论是否明确、整改项是否落实到人。
交叉地带怎么处理
三类管理在节点附近必然交叉，处理原则可以归纳为三条：
- 里程碑日期变化走变更。节点日期调整影响对外承诺和后续计划，应作为变更提出、评估并留痕，而不是在排期里悄悄改掉。
- 任务层面的调整在排期内消化。任务延期、责任人更换、依赖顺序微调，属于排期内部的正常调整，不必每次都上升到里程碑变更。
- 评审结论驱动里程碑状态更新。评审给出通过、有条件通过或退回后，由里程碑管理据此更新节点状态；有条件通过附带的整改项回流到任务排期执行。
三者如何衔接成一条流程
边界清晰之后，三者需要串成一条前后衔接的流程，否则各管一段、互不对齐。一条可用的衔接链路如下。
从里程碑倒推任务排期
先定义关键节点与达成标准，再围绕节点拆解任务、确定依赖与时间安排。节点是排期的锚点：每个里程碑之前应当有支撑其达成的任务集合，任务完成情况构成节点达成的证据来源。ONES在瀑布项目管理场景中支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解计划和工作，并为任务设置前后置依赖，用里程碑标记重要时间点、事件或决策点，节点与任务可以在同一计划体系内对应起来。
任务完成汇总为达成证据
节点到期前，由节点确认人汇总支撑任务的状态与交付物，核对是否满足达成标准。这一步的输入来自排期，输出是里程碑的达成证据。证据不齐时，节点保持待达成状态，缺口回流为排期中的补充任务。
节点到期触发阶段评审
节点达到待评审状态后，组织阶段评审：准备评审材料，召集干系人，形成通过、有条件通过或退回的结论。评审结论决定节点关闭还是重开：通过则关闭节点并进入下一阶段；有条件通过则关闭节点但保留整改项；退回则节点重开，整改项进入排期。
整改项回流与状态流转
评审提出的整改项应作为任务回到排期，明确责任人与完成时间，完成后再次提交确认。节点状态可以按“待达成—待评审—已通过／有条件通过／退回”流转，每次流转都对应明确的动作和记录人。ONES在IPD研发管理场景中描述了阶段决策评审基于评审结果批准基线业务计划、为后续开发与资源投入提供正式依据的做法，可作为评审结论与节点决策衔接的参照；具体评审结论字段与状态流转配置需以产品文档和实际配置为准。
偏差监控与变更留痕
节点日期或达成标准发生变化时，通过基线对比识别计划与执行的偏差，并保留变更记录。ONES支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，通过版本细节追溯变更，这为“里程碑变化走变更”提供了记录载体；基线功能在具体版本与套餐中的可用范围需以实际产品为准。
容易混淆的相邻概念与常见误解
边界混淆往往来自几个具体误解。逐条对照，可以巩固前面的划分规则。
里程碑与任务的区别
里程碑标记重要时间点、事件或决策点，不承载工时，是状态性对象；任务是可分配工时、可跟踪进度的执行单元。一个里程碑背后通常有一组任务，但里程碑本身不应被当作一个大任务来排期和分配工时。
里程碑与阶段评审的区别
里程碑是节点及其状态，阶段评审是发生在节点上的决策活动。节点可以存在而不经过正式评审，评审也可以针对非里程碑事项组织；当二者结合时，评审结论是节点状态更新的依据之一。
三个常见误解
- 误解一：把里程碑当成一个大任务排期。后果是里程碑被拆出工时和责任人，节点判定被进度百分比替代，达成标准反而模糊。纠正方式是里程碑只保留达成标准与确认人，执行工作全部落到任务层。
- 误解二：用评审会代替里程碑达成判定，或反之。评审会给出的是决策结论，达成判定核对的是证据是否满足标准；两者混用会导致“会开过了就算达成”或“证据齐了但没人决策”。纠正方式是分别记录确认动作与评审结论。
- 误解三：里程碑日期随意顺延而不走变更。节点日期承载对外承诺和后续计划，直接顺延会让基线失去意义。纠正方式是将日期调整纳入变更流程并保留记录。
与迭代评审、验收评审的区别
迭代评审通常发生在迭代结束时，关注增量成果的演示与反馈，节奏跟随迭代；验收评审针对交付物是否满足验收标准，结论指向接收或拒收；阶段评审发生在项目关键节点上，结论指向阶段是否放行。三者可以复用同一套评审记录方式，但触发时机、参与角色和结论用途不同，不应互相替代。
一个具体例子：从节点定义到评审结论
以下示例为演示情景，用于说明三层管理的边界如何落地，不代表特定组织的实际流程。
示例背景与里程碑层
某项目设置三个里程碑：需求确认、开发完成、上线。里程碑层为每个节点写明达成标准与确认人：需求确认以需求基线文档评审通过并完成签认为标准，由产品负责人确认；开发完成以全部计划功能开发完毕、代码合并并通过集成测试为标准，由技术负责人确认；上线以生产环境部署完成、上线检查单全部通过为标准，由项目经理确认。
排期层
围绕三个节点拆解任务：需求确认之前安排需求调研、需求文档编写、评审准备等任务；开发完成之前安排模块开发、联调、集成测试等任务，并设置前后置依赖；上线之前安排部署脚本准备、上线演练、发布执行等任务。每项任务有责任人和起止时间，任务进度按周跟踪。
评审层
开发完成节点到期时，技术负责人汇总开发任务完成情况与测试报告作为达成证据，提交阶段评审。评审参与人包括产品负责人、技术负责人、测试负责人和项目经理，评审材料为功能清单、测试报告与遗留问题列表。评审结论为有条件通过：节点关闭，同时提出两项整改项，分别针对遗留缺陷修复和性能测试补充。
边界体现与交接
这个例子里，节点定义与达成标准归里程碑管理，任务拆解与依赖安排归排期，评审组织与结论归阶段评审。交接发生在三处：任务完成情况汇总为节点证据，由确认人核对；节点到期触发评审，由评审组给出结论；评审整改项回流为排期中的新任务，完成后再次提交确认。若开发完成节点需要延期，则作为里程碑变更提出并记录，而不是在排期里直接改掉节点日期。
常见问题
里程碑日期需要调整时，应该走变更还是在排期里直接改？
里程碑日期承载对外承诺和后续计划，调整时应作为变更提出、评估并留痕，而不是在排期里悄悄改掉。任务层面的延期、责任人更换、依赖顺序微调属于排期内部调整，可以在排期内消化；一旦涉及节点日期或达成标准变化，就应进入变更流程，并通过基线对比保留计划与执行的偏差记录。
里程碑达成确认和阶段评审可以由同一批人完成吗？
可以由同一批人参与，但两个动作要分开记录。确认达成是核对证据是否满足达成标准，评审结论是做出通过、有条件通过或退回的决策。分开记录后，后续追溯时才能分清“证据齐了”和“评审通过了”，也便于在退回时定位是证据缺口还是决策未通过。
有条件通过之后，节点算关闭吗？整改项怎么跟踪？
有条件通过通常意味着节点关闭，同时保留整改项。整改项应作为任务回到排期，明确责任人与完成时间，完成后再次提交确认。这样节点状态与执行工作各归其位：节点层记录结论，排期层跟踪整改任务的执行进度。
项目没有正式阶段评审机制时，里程碑管理还能独立运行吗？
可以。里程碑管理的最小构成是节点、达成标准与确认人，节点到期时由确认人核对证据即可判定是否达成。阶段评审是在节点上增加的决策活动，用于需要干系人共同决策的场景。两者结合时，评审结论作为节点状态更新的依据之一；没有评审时，节点状态由确认动作驱动。
ONES 中里程碑、任务和评审记录如何对应到同一套管理里？
ONES 在瀑布项目管理场景中支持用项目计划创建工作分解结构，按目标、交付物或项目阶段分解计划和工作，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点，节点与任务可以在同一计划体系内对应。IPD 场景中描述了阶段决策评审基于评审结果批准基线业务计划的做法。评审结论字段与状态流转的具体配置需以产品文档和实际配置为准。
