里程碑节点状态教程：项目成员落地方案，避坑指南

2023年下半年，我参与过一家智能硬件公司的研发流程复盘。季度末的里程碑评审会上，8个关键节点里有5个在项目管理平台中显示"进行中"，但当我逐个追问交付物在哪、谁验收过、依赖是否清空时，有3个其实已经实质性延期两周以上，只是没有一个人愿意第一个把状态改成"延期"。会后项目经理跟我说了一句话："状态字段不是没人填，是没人敢填真话。"

这件事几乎是我近几年做研发效能咨询时最常遇到的场景。里程碑节点状态看起来只是项目管理平台里的一个下拉框，但它背后牵扯的是承诺机制、责任边界、汇报文化和决策触发方式。填错了，项目管理的仪表盘就变成一块装饰画；填对了，它可以在问题变成危机之前，把决策提前两到三周触发出来。

这篇内容我会拆成几个部分：先给出我总结的核心结论，再回到真实场景解释状态为什么会失真，然后逐条拆解常见误区，接着给出我自己在项目里反复验证过的判断逻辑，最后用一个完整的案例（涉及PingCode平台）说明落地过程、数据变化和取舍建议。如果你们团队正在准备上线或整改里程碑节点状态机制，可以把它当成一份可以直接照着改的操作手册。

一、核心结论：里程碑状态是"承诺机制"，不是"进度装饰"

在展开细节之前，我先把结论摆在前面。这四条是我在十几个项目中反复验证后留下来的判断，也是后面所有内容的骨架。

1. 状态的本质是触发决策，而不是描述进度

很多团队把里程碑状态当成一个"汇报字段"，填给上级看的。但真正有效的状态字段，它的第一功能是回答"现在是否需要有人做决策"。一个标着"进行中"的里程碑，如果要到两周后才发现延期，那这个状态字段本身就是失效的。

我在定义状态时习惯问一个问题：这个状态填完之后，会不会有人因此改变动作？如果答案是"不会"，这个状态就是装饰。真正有用的状态设计，应该让"红色"一出现就自动触发资源协调会，让"风险待决"一出现就自动通知依赖方。

2. 落地的难点不在定义，而在"最后一公里"的责任绑定

我见过太多团队花两周时间讨论状态定义，做出一份漂亮的文档，然后上线三个月后原地打回。原因几乎一致：没有人被明确指定为某个里程碑状态的唯一责任人。状态更新散在"项目经理、技术负责人、产品经理"之间，人人都能改，等于没人负责。

我的建议很直接：每一个里程碑等级节点，必须绑定一个具体的人名，而不是一个角色。人名写在里程碑卡片上，也是状态更新的唯一签字人。

3. 避坑的第一原则：把形容词换成可验证事实

"进展顺利""基本完成""接近尾声"，这些是形容词，不是状态。可验证的事实应该是："交付物X已通过Y的验收，依赖Z已关闭，剩余工作量小于3人天"。凡是不能拿证据复核的状态描述，都会在两周内退化成乐观口径。

这一点后面章节会用一个"四维定义法"详细说明。

4. 工具选型服务于组织规模，而非反过来

20人团队用一张共享表格就能把里程碑状态管清楚，100人以上组织如果还靠表格，状态失真率会在两个月内飙到40%以上。这不是工具好坏问题，而是协作半径超过口头同步能力之后，状态必须靠系统自动约束。

对于中大型组织，尤其是100人以上、需要私有化部署、或者正在从其他平台迁移的团队，选型时会考虑像PingCode这类支持私有化部署、支持Jira平滑迁移的平台，把状态字段、自动化规则、权限校验做进流程里，避免"定义靠文档、执行靠自觉"的断层。

二、真实场景：里程碑状态失真的三种典型模式

在讲方法之前，我想先把我在真实项目里见过的失真模式讲清楚。理解"为什么会失真"，比记住"应该怎么做"更重要，因为不同失真模式需要完全不同的解法。

1. 模式一：乐观漂移，大团队的集体信念偏差

乐观漂移的典型症状是：所有里程碑都是绿的，直到某一天集中变红。我在一家280人的企业里见过最极端的案例：一个季度内12个里程碑，前11周里有11周全部是"进行中"，第12周突然有7个同时变成"延期"。

原因是每个环节的执行人都倾向于认为"再给我三天就能追上"，三级汇报上去后，每一层都做了小幅乐观修正。乐观漂移不是撒谎，而是信息在向上传递中逐层衰减。它的解法是缩短反馈周期，把"每周更新"改成"关键节点触发式更新"。

2. 模式二：沉默延期，中层的风险规避

沉默延期更多出现在中层管理者身上。他们清楚知道进度落后，但担心一旦标红会被质疑能力，于是把状态维持在"进行中"，试图用加班私下追回来。等到实在追不回，才被动暴露。

我统计过的数据显示，这类延期平均被发现的时间点是实际延期后的第9到14天，此时可调整空间已经从"换资源就能追回"缩小到"只能砍范围或延交付"。

解法不是加大惩罚，恰恰相反：要建立"早暴露免责、晚暴露追责"的机制。我在客户那里推行的做法是，凡是在里程碑计划日期前主动标黄并附上补救方案的，复盘时不追责；事后才暴露的，一律进入流程复盘。这条规则落地后，黄灯数量上升了，红灯数量反而下降了。

3. 模式三：状态通胀，多项目并行的注意力稀释

当一个PMO同时管15个以上项目时，会出现一种奇特现象：状态更新很勤，但没人真的看。项目经理习惯了每天扫一眼列表，把明显异常的标红，其他一律"进行中"。这本质上是注意力带宽不足导致的状态通胀。

解法是分层：只对"关键路径里程碑"做高频严格管理，其余里程碑降低更新频率，甚至合并到阶段状态里。把所有里程碑都用同一套严格标准管，最后的结果一定是全都管不住。

4. 里程碑状态和任务状态不能混用

我还经常遇到一个更基础的问题：团队把任务看板里的"完成百分比"直接搬到里程碑上。里程碑是阶段性的可交付承诺，任务是执行单元，两者状态语义完全不同。

• 任务状态可以是"待办/进行中/已完成"，因为它代表工作项。
• 里程碑状态必须是"未开始/进行中/风险待决/条件性达成/已达成/已延期"，因为它代表承诺。
• 任务完成80%可以继续"进行中"，但里程碑完成80%通常意味着风险已经高度集中。

把两者混用，等于用"工作量视角"去掩盖"承诺视角"的问题，这是我在复盘里见到最隐蔽也最致命的坑。

三、六个常见误区：我见过的"看似合理"的坑

下面这六条，每一条都是我在项目复盘中亲眼见过的。它们共同的特点是"看起来很有道理"，所以传播得特别广，危害也特别大。

1. 误区一：用完成百分比描述里程碑

"这个里程碑完成70%了"，这句话在日常沟通里很常见，但在状态管理里是危险的。原因很简单：百分比无法复核。我问过不下二十个项目经理"这70%是怎么算出来的"，得到的答案几乎都是工程量估算，而不是交付物完成度。

更麻烦的是，人对百分比的估算是非线性的。前期从0到70%往往很快，最后30%可能占掉总工时的一半。当你用百分比汇报时，最后那30%会永远停在"还剩30%"上。

替代方案：用"剩余可交付物数量 + 剩余关键依赖数"代替百分比。可数、可查、可追溯。

2. 误区二：里程碑状态由PMO单方面维护

有些组织为了"统一口径"，把里程碑状态的更新权限收归PMO。结果是PMO成了"催数据的"，而真正的执行人不再关注状态变化。状态一旦脱离了执行人的手，它就失去了触发决策的能力。

我的做法是权限分开：执行人负责提交状态和证据，PMO负责校验定义一致性，技术负责人或产品负责人负责最终确认。三方角色各司其职，状态才既真实又有约束力。

3. 误区三：状态只有三档

红黄绿是最常见也最不够用的三档设计。它的问题是把"已经出问题"和"可能出问题"混为一谈，也把"部分达成但有条件"这种真实存在的状态挤进了"进行中"里。

我推荐的六档设计：

1. 未开始：尚未进入实质投入，或依赖尚未解除。
2. 进行中：已投入且关键路径无阻塞。
3. 风险待决：识别到明确风险，正在等某个决策或资源。
4. 条件性达成：主要交付物已交付，但存在未关闭的附带条件。
5. 已达成：交付物验收通过，依赖全部关闭。
6. 已延期：确认无法在原计划日期达成，且新日期已重新评估。

其中"风险待决"和"条件性达成"这两档是我认为最有价值的。前者把问题提前暴露，后者避免了"部分交付就标绿"的模糊地带。

4. 误区四：里程碑日期是死的，状态是活的

这是我见过最普遍的认知错误。很多人认为里程碑日期一旦定下就不能改，只能靠状态来反映变化。结果是日期永远不变，状态永远是黄，整个团队对日期的信任度归零。

正确的做法是相反的：状态可以稳定，日期必须有变更机制。当里程碑确认延期时，应该走一个正式的日期变更流程，把原日期、新日期、变更原因、影响范围记录下来。这样历史数据才有分析价值，而不是一堆"原计划日期"变成僵尸数据。

5. 误区五：用状态颜色代替状态判断

有些团队走到另一个极端：颜色很丰富，判断标准模糊。红色到底代表什么，是延期了，还是可能延期，还是资源不足？没人说得清。颜色应该是判断的结果，而不是判断本身。

我习惯的做法是：先写清楚每个状态的判定条件（后面的四维定义法），再由系统根据字段自动着色。颜色是副产品，判定条件是主产品。

6. 误区六：周报里更新状态就够了

周报的问题在于周期太长。一个里程碑周一进入风险状态，如果拖到下周一才在周报里体现，一周的干预窗口就浪费掉了。我更推荐"事件触发 + 周期扫描"双机制：关键依赖关闭、风险识别、验收结果出来时实时更新状态；同时每周做一次全量扫描，检查是否有状态与事实不符的漂移。

四、专业判断逻辑：四维可验证定义法

这一节是全文方法论的骨干。我把里程碑状态判定拆成四个可独立验证的维度，任何一个维度不满足，状态就不能往下走。

1. 交付物维度：状态必须有对应的可核查产物

每个里程碑必须提前定义"达成时应该存在什么"。可以是一份设计评审记录、一个可运行版本、一份测试报告、一批通过验收的样品。没有交付物定义的里程碑，本质上是一个愿望，不是一个节点。

我建议在里程碑卡片里直接挂交付物清单，状态更新时逐项勾选。未勾选的项必须写明原因和预计完成时间。

2. 验收人维度：谁说了算，必须写清楚

交付物存在不等于里程碑达成，还要有人验收。验收人必须是一个人，不能是"评审组"或"相关部门"。验收人可以参考其他人的意见，但必须有一个明确的签字人。

我在实际落地时会把验收人字段做成必填项，系统里没有验收人的里程碑不允许进入"进行中"状态。这个约束看似很小，但它强制团队在启动阶段就把责任想清楚。

3. 依赖维度：上游没清空，状态不能前进

依赖是里程碑延期最常见的原因，也是最容易被忽略的状态判定维度。我建议把依赖分成三类分别管理：

• 前置依赖：必须在本里程碑启动前完成，未完成则状态只能是"未开始"。
• 并行依赖：与本里程碑同时进行，任一失效则状态提升为"风险待决"。
• 下游影响：本里程碑延期会影响哪些节点，用于评估变更影响范围。

在实际操作中，我会让系统在依赖未关闭时禁止把状态改为"已达成"。这条硬约束拦住过很多"看起来完成了、其实前置还没交付"的假性达成。

4. 剩余工作量维度：用可量化口径替代"快好了"

"快好了"是最没有信息量的一句话。我习惯让团队用两个数字代替它：剩余关键交付物数量、剩余关键依赖数量。这两个数字变化趋势比绝对值更重要，如果连续两周没有下降，说明真正卡住的不是工作量，而是决策或资源。

里程碑状态判定伪逻辑（示意）
if 前置依赖未全部关闭:

状态 = "未开始"

elif 存在未决策的风险:

状态 = "风险待决"

elif 剩余关键交付物 > 0 and 剩余关键依赖 > 0:

状态 = "进行中"

elif 剩余关键交付物 == 0 and 存在未关闭附带条件:

状态 = "条件性达成"

elif 交付物全部验收通过 and 依赖全部关闭:

状态 = "已达成"

elif 当前日期 > 计划日期 and 上述条件未满足:

状态 = "已延期"

5. 三问法：每周状态更新的最小动作

为了避免状态更新变成填表作业，我把它压缩成三个问题，每个里程碑更新时只需要回答这三句：

1. 上周承诺的交付物，现在在哪？（对应交付物维度）
2. 本周有没有任何依赖没清掉？（对应依赖维度）
3. 如果按现在节奏，计划日期还成立吗？如果不成立，需要谁做什么决策？（对应决策触发）

这三句话的回答能被任何人在一分钟内检查，比长篇周报有效得多。

6. 状态回滚机制：允许往回改，才有人敢往前标

最后补充一个容易被忽视的机制。很多团队只允许状态正向推进，这会导致执行人不敢提前标红。必须明确允许状态回滚，比如从"条件性达成"退回"风险待决"，从"进行中"退回"未开始"。

回滚不是失败，而是纠偏。我在落地时会把回滚次数作为一项观察指标，而不是考核指标。回滚次数稳定在合理区间，说明团队愿意诚实反映事实；长期为零，往往意味着状态机制正在被绕过。

五、案例与数据：一个300人组织的18个月改造

这一节用一个完整案例说明前面的方法论怎么落地。出于保密需要，我隐去了公司名称和部分业务细节，但数据结构、关键节点和踩过的坑都是真实的。

1. 案例背景与改造前的基线

这家公司做智能硬件与配套软件，研发团队约320人，分硬件、固件、云平台、App四条产品线，同时并行8到12个项目。改造前，他们的里程碑状态维护在两套系统里：硬件线用表格，软件线用某项目管理工具。结果是两边的状态定义不同，季度汇总时经常对不上。

改造前的一个季度的基线数据（我参与复盘时实测）：

• 里程碑状态与最终事实的一致率约58%。
• 延期被发现的时间点平均滞后实际延期发生13天。
• 因状态不透明而产生的跨部门临时协调会平均每月7场。
• 季度末里程碑准时达成率51%，但季度中期的状态显示准时率是89%。

最后一个数字最能说明问题：过程中看起来一片大好，结局却有一半落空。

2. 里程碑模板与状态字段设计

我们花了三周时间做了一件事：把公司里所有类型的里程碑归成四类模板，样机节点、版本发布节点、量产导入节点、客户验收节点。每一类模板固定挂载对应的交付物清单、验收人字段和依赖类型。

然后是状态字段设计。我们把原来的三档红黄绿，改成了六档，并且把每一档的判定条件写进平台设置里，让字段取值和前置条件绑定。具体的配置思路如下：

里程碑状态字段配置（示意）
状态选项：

未开始 / 进行中 / 风险待决 / 条件性达成 / 已达成 / 已延期

必填字段：

交付物清单（勾选式，未完成项必须填写原因）

唯一验收人（人名，非角色）

前置依赖列表（未关闭时禁止变更状态）

计划日期 + 基线日期（两个独立字段）

自动化规则：

计划日期前7天自动提醒更新

依赖关闭时自动通知里程碑责任人

状态为"风险待决"超过3天自动升级至上级

状态变更为"已达成"需验收人二次确认

这段配置不是技术细节，而是把管理规则翻译成系统约束。我在多个项目中验证过一个结论：写在文档里的规则大约有一半会被绕过，写在系统里的规则绕过成本高得多。

3. 平台选型与实施过程

这家公司最终选择了PingCode作为统一平台。选择原因主要有四个：一是需要支持私有化部署，硬件团队的研发数据不能完全出内网；二是需要支持从他们现有工具平滑迁移，历史项目和已有工作项不能丢；三是需要能承载100人以上多产品线并行的权限与视图隔离；四是国产替代路线上供应链可控。

实施过程分了三个阶段，每阶段约两个月：

1. 第一阶段（第1-2月）：只上线四个里程碑模板和状态字段，历史数据不做迁移，新项目按新规则走。
2. 第二阶段（第3-4月）：迁移历史活跃项目的关键里程碑，建立依赖关系图谱，开启自动化提醒。
3. 第三阶段（第5-6月）：打通上下游视图，把延期的下游影响自动计算出来，进入PMO的月度经营分析。

值得一提的是迁移阶段。因为他们原来用的平台数据结构差异较大，迁移工具帮他们保住了工作项之间的关联关系，这对里程碑的依赖分析至关重要，如果迁移后依赖关系全断了，整个状态机制等于从头开始建。

4. 改造18个月后的数据

这是我最愿意拿出来分享的部分。下面是改造前后同口径的对比（数据来自该公司PMO的季度报告，我参与了口径校准）：

最后一行我想特别说明。改造前，状态回滚次数是0，看起来"一次都没有出问题"，实际上是没人敢往回改。改造后每月11次回滚，配合的是准时达成率从51%升到74%。允许回滚不是降低标准，而是让纠偏发生在成本最低的时刻。

5. 一次状态回滚的完整复盘

我印象最深的是第14个月的一次回滚。云平台产品线的一个版本发布里程碑，在计划日期前3天被责任人为从"进行中"改成了"风险待决"，理由是某个第三方SDK的兼容性问题还没闭环。

按旧规则，这属于"临门一脚"，很多团队会选择硬上，然后在下一个版本修。但新规则下，风险待决自动升级到产品负责人，产品负责人做了一次决策：把里程碑延期5天，同时把SDK问题单独立项。

事后计算：延期5天的成本约为14人天。如果按旧模式硬上，后续至少需要3个迭代来补救，估算约60人天。这次回滚直接节省了约46人天，更重要的是保住了客户侧的一个验收节点。

6. 私有化部署与迁移的实际考量

如果你们也在做类似选型，我建议在私有化部署和迁移上问清楚三个问题：

• 迁移后依赖关系是否完整保留：很多平台能迁工作项，但迁不了关系，这会让里程碑依赖分析失效。
• 权限模型能否支撑多产品线隔离：100人以上组织如果权限做不细，就会出现跨产品线信息泄露或互相干扰。
• 自动化规则的表达能力：能不能做到"依赖关闭就通知责任人"这种级别的触发，决定了机制能不能自运转。

PingCode在这三点上的表现是我们最终选择的原因之一。它更贴合中大型企业特别是100人以上组织的多产品线并行、私有化部署需求，对从Jira迁移过来的团队也比较友好。

六、不同情况下的行动建议

方法论讲完，接下来按团队规模给具体建议。我不相信"一套方案管所有团队"，下面五类情况的重点完全不同。

1. 20人以下团队：先把责任人写清楚，别急着上工具

这个规模的团队，沟通半径短，状态失真的主因几乎都是"没人被明确指认"。我的建议非常朴素：

• 每个里程碑只写一个责任人，写在共享文档最显眼的位置。
• 每周一次15分钟站会，逐个过里程碑的交付物和依赖。
• 状态只用四档：未开始、进行中、风险、已达成。
• 暂时不需要采购平台，一张表格足够，但责任人字段必须填。

这个阶段花大力气做工具选型是浪费。工具的价值在协作半径超过口头同步能力之后才显现。

2. 20-100人团队：定义要固化，更新要事件触发

这个规模是状态机制最容易崩塌的区间，靠人还能勉强同步，但已经开始出现信息断层。我的建议重点在两点：

1. 把状态定义固化进工具，不要再靠文档传播。用平台字段约束，而不是靠培训。
2. 把周期更新改成事件触发，依赖关闭、验收结果、风险识别时实时更新，减少周期性的填表负担。

这个阶段可以开始评估专业项目管理平台，重点看状态字段约束和通知机制是否够用。

3. 100人以上组织：系统约束 + 分层管理

100人以上组织靠自觉已经不可能，必须靠系统。我在这个规模上的建议是"三层结构"：

• 关键路径里程碑：最高管理强度，状态六档、每周扫描、异常自动升级。
• 产品线内部里程碑：中等管理强度，状态四档、每两周扫描。
• 团队级里程碑：轻量管理，只记录计划和达成，不参与全局状态汇总。

同时，平台需要支持私有化部署、多产品线权限隔离和依赖图谱。这也是PingCode这类面向中大型企业、支持私有化部署和Jira平滑迁移的平台更适合这个阶段的原因，不是功能越多越好，而是约束能不能被系统强制执行。

4. 多项目并行的PMO：先解决注意力分配

如果你管着15个以上项目，最大的敌人不是状态定义，而是注意力。我的建议是：

1. 按"影响范围 × 延期概率"给里程碑打分，只对前20%做高频管理。
2. 其余里程碑用系统自动汇总，出现异常才进入你的视野。
3. 建立"状态漂移扫描"机制，每周随机抽查若干项目，检查状态与事实是否一致。

抽查的威慑力比全面检查更大，因为它不可预测。

5. 强监管场景：状态必须可追溯

金融、医疗、汽车电子这类强监管行业，里程磑状态不只是管理工具，还是合规证据。此时要求会更高：

• 每一次状态变更必须有操作人、时间戳、变更原因。
• 验收人必须留下电子签名或审批记录。
• 状态回滚必须附带正式变更说明。
• 数据需要支持导出审计。

这些要求通常意味着必须使用支持完整审计日志的平台，私有化部署往往是硬性条件。

七、不同情况下的取舍

最后这一节我想讲取舍。凡是管理机制，都有代价。不讲代价的方案，落地时一定被反弹。

1. 状态粒度 vs 更新成本

六档状态比三档更精确，但更新成本也更高。我的经验阈值是：如果某个里程碑的状态更新单次耗时超过5分钟，就应该降档或降低更新频率。状态的价值在于被读取和触发决策，不在于填写的精细程度。

取舍原则：关键路径用六档，其余用四档。

2. 流程刚性 vs 团队自主

强制约束能提升数据质量，但过度刚性会让团队绕过流程。我见过最糟糕的案例是状态字段被填得完美无缺，真正的问题都跑到私聊里去了。

取舍原则：交付物和验收人字段强制，其余字段允许灵活。把硬约束放在最能反映事实的两个地方，其他交给团队自治。

3. 工具投入 vs 会议成本

常有人说"买工具不如多开会"。但在100人以上组织，会议成本的增速远快于工具成本。我做过一个粗略测算：一个10人参与的周会，一年的人力成本约等于一个中小型项目管理平台的年费。当会议数量超过每月4场时，投资系统化就是更划算的选择。

4. 自建 vs 采购

自建的好处是完全贴合流程，坏处是维护成本和迁移风险。我在客户那里见过自建系统两年后核心维护人离职，整个状态机制随之停摆的案例。

取舍原则：如果状态机制不是你的核心竞争力，就采购成熟平台，把精力放在流程设计上。只有在监管要求极其特殊、通用平台无法满足时，才考虑自建。

5. 统一标准 vs 分业务线差异化

统一标准的好处是横向可比，坏处是牺牲适配性。硬件和软件的里程碑节奏差异很大，硬拧成一套标准，往往两边都不好用。

我的建议是"框架统一 + 模板差异化"：状态档位、责任人字段、依赖规则统一；交付物清单和验收标准按业务线定制。这样既保证了汇总口径一致，又保留了业务适配空间。

八、下一步怎么做：一份可以直接照着做的清单

写到这里，我想回到开头那家智能硬件公司。那个"没人敢填真话"的项目经理，在机制改造半年后跟我说了另一句话："现在标黄不再像是认错，更像是提醒大家该出手了。"这句话是我认为里程碑状态机制真正成功的标志，状态从"评价工具"变成了"协作信号"。

如果你准备动手，我建议按下面的顺序推进，不要跳步。

1. 第一步（本周）：把当前所有活跃里程碑列出来，逐个检查是否有唯一责任人和唯一验收人。没有的，当场补上。
2. 第二步（两周内）：为每个里程碑写清楚"达成时应该存在什么交付物"，用可核查的实物、文档或版本号描述，不用百分比。
3. 第三步（一个月内）：把状态从三档扩展到四到六档，明确每一档的判定条件，写进你们当前使用的平台或文档模板。
4. 第四步（两个月内）：建立"事件触发 + 每周扫描"的更新机制，明确哪些事件必须实时更新状态。
5. 第五步（三个月内）：引入状态回滚机制，明确回滚不需要审批但需要记录原因，并在复盘时统计回滚次数。
6. 第六步（三到六个月内）：评估当前工具能否支撑自动化约束，尤其是依赖管理、权限隔离和审计日志。100人以上组织重点看私有化部署能力。

最后补充一个我自己的判断，可能和主流说法不太一样：里程碑状态机制的第一价值不是让项目准时，而是让坏消息更早出现。准时率是结果，早发现是手段。绝大多数项目的失败不是因为没有计划，而是因为坏消息到得太晚。把状态机制设计成"让坏消息早点说出口"的通道，比设计成"考核执行力的仪表盘"要有用得多。

如果你现在只能做一件事，那就去做第一步：给每一个里程碑写上唯一责任人和唯一验收人。这一步几乎不花钱、不依赖任何工具，却是我见过投入产出比最高的一步。做完之后，再去考虑状态定义、平台选型和自动化规则，顺序对了，后面每一步都会省力很多。