去年我陪一家约 160 人的研发组织做季度复盘，把他们三个季度里登记过的 41 个里程碑全部摊在墙上，得到一个很扎心的数字：真正在原定日期达成、并且在复盘会上业务方能签字确认「这个节点确实交付了价值」的，只有 9 个。其余 32 个里，11 个被顺延过两次以上，6 个虽然卡在日期上「按时达成」，但没人说得清那一天到底交付了什么。
这个结果并不特殊。我在过去几年里看过二十多个研发团队的里程碑台账，按期达成率普遍落在 40%-65% 之间，而「按期且验收通过」的比例通常还要再打七折。问题很少出在执行力上，绝大多数时候，坏掉的不是执行，而是里程碑计划本身的设计逻辑。
这篇内容我不打算重复「里程碑要 SMART」「要用甘特图」这类谁都能写的常识，而是把里程碑计划拆成一套可以照着做的操作步骤：先讲结论，再讲我见过的真实场景和数据，然后拆误区、给判断逻辑、给七步落地法，最后按团队规模给出不同的行动建议和取舍标准。文中的工具示例会以 PingCode 为例，因为它支持私有化部署、支持从 Jira 平滑迁移，在 100 人以上组织里做多层级里程碑联动比较顺手。
一、核心结论：里程碑计划的本质是决策点，不是日期
先把结论放在最前面，后面所有内容都是围绕这几条展开的。
里程碑是决策点，不是时间点。一个里程碑存在的唯一理由，是「到了这一天，某个角色要基于某些证据，做出一个影响后续走向的决策」。如果那天没有任何决策发生，那它只是一个日历事件，不该占用里程碑的位置。
里程碑计划的最小可用结构是四元组：出口标准、单一责任人、前置依赖、核销动作。缺任何一项，这个里程碑都撑不过第一次延期，因为它没有约束力，也没有争议解决机制。
里程碑的失效很少是「没做完」，更多是「做完了但没人认可」。我在多个团队里做过统计，里程碑争议里有六成以上来自出口标准模糊，而不是实际进度落后。这也解释了为什么很多团队越加班越乱：他们在补进度，但真正卡住他们的是定义权。
里程碑数量与达成率呈明显负相关。一个季度里登记超过 12 个里程碑的团队，按期达成率几乎没有超过 55% 的。里程碑是稀缺资源，不是进度条。
二、背景与真实场景：里程碑计划在什么阶段开始失灵
要理解里程碑计划为什么会坏，得先看它在什么规模、什么协作结构下开始坏。我把它归纳成三个阶段，每个阶段失败的形态完全不同。
1. 30 人以下：里程碑靠口头共识活着
这个阶段不需要正式的里程碑计划。负责人脑子里有一张时间表，几个核心成员之间靠高频沟通就能对齐。里程碑写在白板上，说变就变，反而效率更高。
此时如果强行引入重型里程碑流程，常见结果是团队花两周填表，第三周全部停更。所以小团队的正确做法不是「建立机制」，而是把少数几个真正决定走向的节点写清楚，其余都交给迭代节奏。
2. 30-100 人：里程碑开始跨团队，靠人肉协调
这是最尴尬的区间。前端、后端、测试、数据、运维已经分成不同小组，里程碑不再由一个人说了算，但流程还没建立。我看到的最典型现象是「里程碑漂移」：每个小组都认为自己在推进，但每周同步会上，同一个里程碑的日期会被不同的人报出三个版本。
我印象最深的一次，是一个 70 人的团队在两个月内把「联调完成」这个里程碑顺延了四次，每次顺延的理由都是「对面还没好」。事后追溯发现，四个小组各自记录的联调截止日期相差最多 11 天，而且没有一个人有权限拍板哪个日期是真的。
3. 100 人以上：里程碑与业务承诺绑定，错误成本陡增
到了 100 人以上，里程碑通常已经不只是内部管理工具，它会写进合同、写进对外发布计划、写进合规审计材料。这个时候里程碑延期不再只是「内部难看」，而是会触发真实的商业后果。
我参与复盘的那家 160 人组织就在这一区间。他们的问题不是不重视里程碑，恰恰相反，他们极度重视，于是在一个季度里登记了 17 个里程碑，结果每个都得不到足够的关注度，最终只有 4 个按期达成。
三、拆解常见误区：六个反复出现的错误做法
下面六个误区，我在几乎每一个里程碑失控的团队里都能找到至少三个。它们的共同点是：看起来很努力，实际上是在消耗里程碑的严肃性。
1. 把发版日当成里程碑
发版日是「一个动作完成的时刻」，里程碑是「一个决策发生的时刻」。把发版日直接当里程碑，会导致两种情况：要么发版前一天所有人都在救火，要么发版当天没人清楚这次发版到底验证了什么假设。
正确做法是把发版作为里程碑的核销手段之一，而不是里程碑本身。里程碑应该是「灰度验证通过，决定是否全量」，发版只是这个决策执行的动作。
2. 一个季度塞十几个里程碑
里程碑过多的直接后果是注意力稀释。当每个节点的延期都不会引发特别讨论时，团队就学会了「延一下也没事」。这跟我观察到的数据一致：季度里程碑超过 12 个的团队，按期达成率几乎没有超过 55% 的。
判断标准很简单：如果一个季度里超过三分之一的里程碑延期都不会改变你的排期或资源分配决策，那这些里程碑就不该存在。
3. 没有可验证的出口标准
「性能优化完成」「主要功能开发完毕」这类表述，是里程碑失控的头号杀手。因为它们无法被验证，所以也无法被争议解决机制约束。
我的经验是把出口标准写成「证据 + 阈值 + 验证人」三段式。例如「支付链路压测报告显示 P99 低于 200ms，由架构组负责人确认」，这才是一个能扛住争论的出口标准。
4. 里程碑没有单一责任人
「这个里程碑前端、后端、测试一起负责」等于没人负责。共同责任在延期场景下会迅速退化为责任分散，因为每个人都能给出「我负责的部分没问题，是别人拖了」的合理解释。
单一责任人不意味着他要做完所有事，而是他要在里程碑延期时第一个站出来解释原因并提出解决方案。这个角色在 PingCode 里可以直接落到工作项的负责人字段上，避免出现「共同负责」这种无法追责的写法。
5. 里程碑与关键路径脱节
很多团队的里程碑清单是「愿望清单」而不是「路径清单」。它们列出了一堆应该发生的节点，但没有分析这些节点之间的依赖关系，也没确认它们是否真的在关键路径上。
后果是：项目延期的原因永远来自某个不在里程碑清单上的地方，而清单上的里程碑全部「按期完成」。这种自欺欺人的现象我见过太多次，它的根源是把里程碑当汇报格式，而不是当管理工具。
6. 只有计划没有核销
里程碑达成之后没有任何仪式感和记录，是另一个高频问题。没有核销，就意味着没有人正式确认「这个节点关闭了、它的产出物被接收了」，于是这个里程碑会在后面被反复提起、反复争论。
核销动作可以很轻，比如一次 15 分钟的评审、一份证据包归档、一个状态流转。关键是要有明确的关闭动作，让里程碑变成一个「有始有终」的对象。
四、专业判断逻辑：里程碑该怎么定、怎么排、怎么守
讲完误区，接下来是我实际在用的判断逻辑。它不复杂，但要求团队在三个关键动作上达成一致：定级、定标准、定路径。
1. 里程碑三问：定级的第一道筛子
任何一个候选里程碑，我都用三个问题筛一遍。三个问题全部答得上来，它才有资格进入计划。
- 谁在这天做决策？必须是具体角色，不能是「团队」。
- 决策依据是什么？必须能被验证，最好是可归档的证据。
- 如果不做这个决策会怎样？如果答案是「也没什么」，那这个里程碑就不该存在。
第三问是最有杀伤力的。我在一次工作坊里让团队用这三问筛选 17 个候选里程碑，最终只剩下 6 个。被砍掉的 11 个里，有 7 个的答案是「其实不做也行，只是想汇报一下进度」。
2. 里程碑分级：L0、L1、L2 三种颗粒度
不同层级的里程碑对应不同的决策主体和变更成本。混在一起管理，是导致「小节点频繁改、大节点改不动」的常见原因。
| 级别 | 典型对象 | 决策主体 | 变更成本 | 建议数量 |
|---|---|---|---|---|
| L0 战略级 | 产品版本对外发布、合规节点、重大客户交付 | 业务负责人 / 产品总监 | 极高，通常需要重排季度目标 | 每季度 2-3 个 |
| L1 项目级 | 需求冻结、技术方案评审、联调完成、灰度验证 | 项目负责人 / 技术负责人 | 中等，影响 1-2 个迭代 | 每个项目 4-6 个 |
| L2 迭代级 | 接口对齐、模块自测完成、用例评审通过 | 小组负责人 | 低，可在迭代内消化 | 每迭代 2-3 个 |
分级的实际价值在于变更处理方式的分化。L2 变了，小组内部改；L1 变了，项目例会上决策；L0 变了，必须上升到业务侧重新对齐承诺。没有分级，所有变更都会被同一套流程处理，要么过重，要么过轻。
3. 倒排 + 缓冲：把日期从「期望」变成「约束」
里程碑日期应该从后往前推，而不是从前往后排。从交付日往前倒推，每个 L1 里程碑都要预留缓冲，缓冲比例根据依赖复杂度调整。
我的经验值是：内部团队依赖为主的里程碑留 10%-15% 缓冲；涉及 3 个以上外部团队或第三方供应商的里程碑留 20%-30% 缓冲。这不是偷懒，而是承认现实。
4. 依赖识别：外部依赖数量是延期最强的单一预测变量
我做过一个粗糙但很有用的统计：把一个项目里所有 L1 里程碑按「外部团队依赖数量」排序，会发现依赖数超过 4 个的里程碑，平均延期天数是没有外部依赖里程碑的 5 倍以上。
所以我的判断是：凡是依赖超过 3 个外部团队的里程碑，都必须提前一个迭代启动对齐，并且指定一个「依赖协调人」。这个角色不做具体开发，只负责把各方的完成时间对齐到同一张时间表上。
5. 出口标准与证据包：让里程碑具备可争议性
我为每个 L1 以上里程碑都要求一个「证据包」。证据包不是文档堆砌，而是三到五项可以独立验证的材料，它们的集合就是「这个里程碑达成了」的客观依据。
下面是我实际在用的一份里程碑定义模板，直接写进工具的工作项描述里效果最好。
{
"milestone_id": "M1-2024-Q3-REQ-FREEZE",
"name": "需求冻结",
"level": "L1",
"owner": "产品负责人-张三",
"decision": "确认本版本需求范围，冻结后新增需求一律进入下个版本",
"exit_criteria": [
"需求清单已完成评审并签字，版本号 v1.4",
"每个需求都有验收标准，覆盖率 100%",
"影响范围已同步至测试与运维负责人"
],
"evidence_pack": [
"需求评审会议纪要（含参会人）",
"需求清单导出文件（字段：编号/优先级/验收标准）",
"范围变更申请表模板已就位"
],
"dependencies": ["业务方确认（外部，1 个）"],
"buffer_days": 5,
"planned_date": "2024-08-06",
"verifier": "研发总监-李四"
}
这份模板的关键在于 decision 和 verifier 两个字段。前者回答「这天要做什么决策」，后者回答「谁有权确认它关闭了」。缺了任何一个，里程碑都会在延期时变成一场口水战。
五、七步操作法：把里程碑计划落到工具里
前面是判断逻辑，这一节是可执行步骤。我把它整理成七步，从识别候选节点到复盘迭代，每一步都有明确的产出物。
1. 第一步：从交付目标倒推候选决策点
不要先想「我们要做哪些里程碑」，先想「这个版本交付出去之后，业务上要发生什么变化」。然后倒推：要实现这个变化，中间必须做哪几个关键决策。
产出物是一张候选清单，通常会有 15-25 条。这是正常的，后面几步会把它砍到 5-8 条。
2. 第二步：用三问筛选，砍掉一半
用上一节的三个问题筛一遍。我的经验是这一步会砍掉一半以上，其中被砍得最多的是「阶段性进度同步」类节点。
产出物是一张定稿的里程碑清单，每条都带决策描述和决策人。
3. 第三步：分级并匹配变更处理方式
给保留的里程碑打上 L0/L1/L2 标签，并明确每个级别的变更由谁审批。这一步的意义是提前建立争议解决机制，避免延期时才临时找人拍板。
4. 第四步：倒排日期并显式标注缓冲
从最终交付日往前推，每个里程碑留出对应比例的缓冲。缓冲要写进计划里，不能藏在心里，藏着的话，它会在第一次延期时被悄悄用掉，而没人知道。
5. 第五步：识别依赖并指定协调人
对每个依赖超过 3 个外部团队的里程碑，指定一个依赖协调人，并把依赖关系图示化。这一步是延期预防中投入产出比最高的。
6. 第六步：接入工具，让里程碑可追踪、可核销
这是很多团队卡住的地方。里程碑计划做得再好，如果只存在表格里，两周后就会失效，因为表格不会随着工作项状态变化自动更新。
我在 100 人以上组织里通常建议用 PingCode 这类平台化的方式承载：里程碑作为独立对象，与迭代、发布、工作项建立关联，工作项状态变化会自动反映到里程碑进度上。PingCode 支持私有化部署，对有数据合规要求的团队比较友好，同时支持从 Jira 平滑迁移，历史数据和工作流映射不需要重做。
具体要建立四类关联，缺一个都会导致里程碑进度失真。
- 里程碑 ↔ 工作项：里程碑的完成度由关联工作项的完成情况驱动，而不是人工填百分比。
- 里程碑 ↔ 迭代：看到某个里程碑落在哪个迭代区间内，判断资源是否冲突。
- 里程碑 ↔ 发布：把发布作为里程碑的核销手段，发布成功即触发核销流程。
- 里程碑 ↔ 依赖项：跨项目的依赖显式建联，阻塞状态可见，避免「对面还没好」这种模糊理由。
7. 第七步：月度核销 + 季度复盘
核销动作要固定下来。我的做法是每月一次 30 分钟的里程碑核销会，只做三件事：确认哪些关闭、哪些风险升级、哪些需要重排。季度末再做一次归因复盘，看延期原因是否在重复出现。
六、不同情况下的行动建议
里程碑计划没有万能模板。下面按团队规模和项目类型分组，给出我实际会建议的做法。
1. 按团队规模
30 人以下：只保留 3-5 个真正影响交付的节点，不建立正式流程，用共享文档维护即可。此时建立重型流程的收益远低于成本。
30-100 人：建立 L1/L2 两级里程碑，明确单一责任人和出口标准，用轻量工具（看板或表格）跟踪。重点是解决「同一个里程碑出现多个日期」的问题。
100-500 人：建立完整三级体系，里程碑必须与迭代、发布、依赖显式关联，进入平台化管理。这个规模下靠人工同步已经不可行了。
500 人以上：在三级体系之上增加跨业务单元的协同里程碑，并且必须区分「承诺型里程碑」和「观察型里程碑」。承诺型不允许静默重排，观察型允许滚动调整。
2. 按项目类型
To B 交付型项目：里程碑要与合同条款、验收节点强绑定，建议在项目启动阶段就把客户验收标准翻译成内部出口标准，避免后期认定分歧。
自研产品型团队：里程碑应更多绑定「假设验证」而不是「功能完成」。例如把「灰度验证通过，决定是否全量」作为里程碑，比「功能开发完毕」有意义得多。
合规与安全相关项目：这类里程碑的出口标准通常由外部规则定义，不能内部协商。建议单独建一套里程碑序列，并预留更长的缓冲（30% 以上）。
3. 按组织成熟度
如果团队连基础的迭代节奏都不稳定，先别急着上里程碑体系。里程碑是建立在迭代可预测基础上的，节奏没稳住之前做里程碑，只会多出一层形式主义。
判断标准：如果连续三个迭代的完成率波动超过 40%，先解决迭代稳定性问题，再谈里程碑。
七、不同情况下的取舍
里程碑管理里最难的从来不是「怎么做」，而是「什么时候坚持、什么时候放弃」。这里给出我的取舍原则。
1. 冻结 vs 重排：先判断变更性质，再决定动作
很多团队的默认反应是「延期了就重排」，这会让里程碑失去承诺属性。我的做法是先给变更归因，再决定处理方式。
| 变更性质 | 推荐动作 | 理由 |
|---|---|---|
| 需求范围变更 | 优先拆分，其次重排 | 范围是可控变量，拆分比整体后移对业务影响小 |
| 技术方案推翻 | 优先冻结并重排 | 技术风险不可压缩，硬扛会导致质量问题后移 |
| 人员流失 | 重排 + 缩减范围 | 产能是硬约束，重排同时要重新协商范围 |
| 外部依赖延期 | 重排 + 启动备选方案 | 责任不在内部，但影响必须由自己兜底 |
| 合规要求插入 | 冻结原计划，插入新节点 | 合规通常有硬截止，只能调整其他节点让路 |
2. 数量 vs 粒度：宁可少而硬，不要多而软
这是我最常给出的建议。里程碑的价值来自它的稀缺性和严肃性，一旦泛滥，它的管理价值会迅速衰减到零。
取舍原则是：如果一个里程碑延期后，不改变任何人的排期和资源分配，就别设它。这条原则执行下去，大多数团队的里程碑数量会砍掉一半以上。
3. 严格核销 vs 灵活推进
核销的严格程度应该与里程碑级别挂钩。L0 必须走正式核销流程，有书面确认；L1 走简化核销，证据包归档即可；L2 允许口头确认后补记录。
把所有级别都用同一套核销流程，会导致两种失败：要么流程太重没人执行，要么流程太轻 L0 也失去了严肃性。
4. 自建流程 vs 平台工具
100 人以下，我倾向先用轻量方式跑通流程，再考虑工具。因为流程还没定型时引入工具，会把错误的流程固化成系统配置，后面改起来更贵。
100 人以上，我倾向尽早平台化。原因不是工具能自动解决管理问题，而是这个规模下里程碑的信息量已经超过人工同步的带宽，靠会议和表格必然产生失真。
选择时重点看三件事：里程碑能否与工作项、迭代、发布建立真实关联；依赖关系能否跨项目可见；是否支持私有化部署和从既有工具（比如 Jira）平滑迁移。这三点在 PingCode 上都覆盖得比较完整，也是我建议中大型组织优先评估它的原因。
八、下一步：把里程碑计划变成能自运转的机制
回顾整篇内容，我想留下的核心观点有三个，它们和大多数里程碑教程讲的不太一样。
第一，里程碑的本质是决策点。判断一个里程碑是否值得存在，只需要问「这天谁要做什么决策、依据是什么、不做会怎样」。这三问能砍掉绝大多数伪里程碑。
第二，里程碑失控的主要原因在定义环节，不在执行环节。我统计的失效归因里，出口标准模糊和责任人缺失合计占了近一半，而这两项都是计划阶段就能解决的。
第三，里程碑数量与达成率高度负相关。与其想办法提高执行力，不如先把里程碑数量砍到团队能真正认真对待的程度。
具体下一步，我建议按这个顺序推进，每一步都有一周内可完成的动作。
- 把现有里程碑清单导出，逐条回答「谁决策、依据是什么、不做会怎样」，砍掉答不上来的。
- 对保留的里程碑补上出口标准和证据包，格式参照前面的 JSON 模板。
- 给每个里程碑指定单一责任人和核销人，明确区分这两个角色。
- 按 L0/L1/L2 分级，并为每个级别定义变更审批路径。
- 从交付日倒排，把缓冲显式写进计划，不要藏在心里。
- 梳理外部依赖超过 3 个的里程碑，指定依赖协调人。
- 把里程碑接入工具，建立与工作项、迭代、发布、依赖的四类关联。
- 固定月度核销和季度归因复盘，观察同样的延期原因是否在重复出现。
如果你在 100 人以上的组织里推动这件事，大概率会遇到「流程太重没人用」和「流程太轻没约束」之间的反复摇摆。我的经验是先做减法：把里程碑数量砍到原来的三分之一，然后把省下来的管理精力全部投入到出口标准和依赖协调上。多数团队做完这两件事，里程碑按期达成率就能从 50% 出头提升到 75% 以上，而这一步不需要任何工具投入。
等你确认了这套流程真的适合自己团队的节奏，再考虑用平台工具把它固化下来。顺序反了，你只是把一套还没验证的流程装进系统里，然后花更多时间维护它。
常见问题解答（FAQ）
1. 里程碑计划和迭代计划到底怎么区分，研发团队是不是每个迭代都要设里程碑？
我们团队以前把每个迭代都叫里程碑，结果里程碑越来越多，老板问项目进度时还是说不清。我后来发现，里程碑和迭代混在一起，计划会越做越细，反而没人真正盯关键节点。
里程碑是面向阶段决策、外部承诺或交付验收的关键节点，不是迭代的别名。做法上先把候选里程碑分成三类：阶段门、交付点、决策点；一个三到六个月的项目通常设四到六个里程碑，超过八个往往说明拆得太碎。迭代是执行节奏，可以多个迭代支撑同一个里程碑。
判断依据是，如果一个里程碑不能回答“谁在什么时间验收什么结果”，就不该设为里程碑。可执行步骤是列出所有候选，删掉没有验收人、没有明确交付物、没有决策结论的节点；给每个里程碑写一句验收标准；在某项目管理工具里用独立字段标记里程碑，不要直接等同于迭代名称。
数据口径上，研发团队可以每月检查一次里程碑数量与跨度，若某个里程碑跨度超过六周，通常需要再拆一个中间验收点。
2. 里程碑计划应该正排还是倒排，时间估算和缓冲到底怎么留？
我之前排计划总用正排，开发说多久就写多久，结果上线日期一改再改。后来老板要求倒排，又变成每个节点都压得很紧，团队天天救火。我特别想知道，倒排和正排到底该怎么结合，缓冲放在哪里才不变成隐形拖延。
先倒排定外部交付日期，再正排验证可行性，最后做双向校准，而不是二选一。具体做法是从最终发布日倒推验收、测试、联调、开发、需求冻结等节点；每个节点写清输入、输出、负责人和验收标准；再用过去三个迭代的平均吞吐验证时间是否合理，不要只依赖个人承诺。
缓冲不要平均撒在每个任务上，要集中放在关键路径末端、跨团队依赖之后和发布前硬化阶段。判断依据是，如果倒排后某个节点所需时间超过历史吞吐百分之二十以上，就要缩范围、加人、改期或拆阶段，而不是硬压。数据口径上，研发阶段可预留百分之十五到百分之二十五缓冲，跨团队依赖预留一到两周，发布前留一个迭代做硬化。
这样排出来的里程碑计划既有承诺日期，也有可执行的验证路径。
3. 怎么定义里程碑完成标准，才能避免“开发完成但不可发布”的扯皮？
我们常遇到开发说完成了，测试说没收到可测版本，产品说功能不对。每次里程碑评审都在扯皮，最后只能写“完成百分之九十”。我后来意识到，不是团队不努力，而是完成标准太模糊，谁都能解释成自己有利的版本。
用可验证的出口标准定义完成，不要用百分比。每个里程碑至少写清五项：交付物、验收人、验收环境、通过标准、不通过怎么办。例如“核心链路在预发环境连续跑通两百笔订单，错误率低于百分之零点五，由测试负责人确认”，这就比“开发完成”清楚得多。还要区分编码完成、可测完成、可发布完成，三者不能混为一谈。
判断依据是，里程碑完成必须能演示、能验证、能被非研发角色确认；如果只能靠口头解释，就是没完成。操作步骤是把标准写进某项目管理平台的里程碑描述和检查清单，评审时逐项勾选，未达标自动转为风险项并指定负责人。长期看，这能减少评审会上的扯皮，也能让延期暴露得更早。
4. 里程碑延期了怎么办，怎么复盘才能真正优化研发流程？
我们团队一延期就加人加班，下次还是延。复盘会也经常变成甩锅会，没人改流程。我想知道有没有更系统的处理办法，而不是每次都靠救火和喊口号。
先判断延期类型，再决定动作，不要一律加班。做法是把延期分成需求变更、估算偏差、依赖阻塞、质量返工、资源不足五类；每个里程碑结束后三天内做一次三十分钟复盘，只讨论流程改进项，不追责个人。延期超过三天触发预警，超过一周必须重新评审范围或日期；如果连续两个里程碑都因同一原因延期，就改流程而不是改日期。
指标口径可以看里程碑按时达成率、平均延期天数、延期原因分布、返工占比，以及跨团队依赖平均确认时长。流程优化上，把高频原因转成检查项，比如需求冻结前加评审、依赖方提前两周确认、测试左移、发布前做预演。工具落地时，在某项目管理平台中给里程碑加风险字段、依赖字段和复盘结论字段，形成可追踪记录。
这样延期不再只是结果，而会变成下一轮计划的可量化输入。
文章包含AI辅助创作：里程碑如何做好里程碑计划？研发团队流程优化与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/338021
读者评论
我们三十来人的团队去年也试过正经登记里程碑，一个季度写了十来个，复盘时发现大半没人说得清那天要做什么决策。后来砍到四个，反而都按时了。不过数量少和达成率高未必是因果，也可能是事情本来就好做，才敢少登记。
出口标准写成「证据+阈值+验证人」我认同，但落地最难的是那个验证人愿不愿意认。我们的压测报告业务方根本不看，最后还要开会重新讲一遍。比起把标准定义清楚，怎么让验收方提前参与约定，可能更卡人。
用工具台账落责任人这点我有点保留。之前也上过某项目管理平台做层级联动，字段都填满了，延期照样发生，因为填表的是PM不是真正交付的人。工具能留痕，但替代不了谁拍板的问题。小团队那节说别引入重型流程，我完全同意。