2023年秋天，我参与了一家年营收约40亿元的装备制造集团的PMO诊断项目。他们的项目管理平台里，里程碑按时达成率连续四个季度稳定在91%，94%之间，看上去非常健康。但在年度经营分析会上，董事长只问了三个问题：为什么三个已标注“已完成”的量产节点，客户那边还在催样件？为什么研发说完成了、工艺说没收到、采购说没启动？为什么每月里程碑评审会要开4个小时，最后只确认了“下周再确认”？
这三个问题，直接把这个集团PMO的里程碑制度打回了原形。会后我拿到系统导出数据一看，被标记为“已完成”的37个里程碑里，有11个缺少任何交付物链接，有6个的完成时间晚于计划时间但状态仍是绿色。
这就是我想在这篇文章里讲清楚的事情：里程碑落地的难点从来不在“设几个节点”，而在“节点状态由谁定义、凭什么判定、判定结果如何被信任”。这也是PMO开展里程碑制度设计时最容易忽略的一层，制度设计不是流程图，而是状态契约。接下来我会用我过去三年参与的14个PMO咨询项目中的脱敏数据，拆解节点状态从“自报”走向“可审计”的完整设计路径。
一、核心结论：里程碑制度设计的三条硬判断
在展开背景和案例之前，我先把结论放在前面。这三条判断来自我对14个项目的复盘，其中7个项目在制度重构后12个月内里程碑争议事件下降超过60%，另外7个只改了工具、没改制度的项目，争议事件基本没变。
1. 节点状态的本质是“定义权分配”，不是“进度展示”
很多PMO把里程碑状态理解为项目进度的一个可视化标签：绿了就是好，红了就是差，黄了就是有风险。这个理解在10人项目里勉强能用，在100人以上、跨3个以上部门的组织里一定会失效。原因很简单：当“完成”的定义权落在执行人自己手里，状态就不再是事实，而是立场。
我见过最典型的例子是一家汽车零部件企业。研发项目经理在系统里把“样件交付”标记为已完成，依据是“设计文件已发布”。但工艺部门的判断标准是“样件实物通过三坐标检测”，采购部门的判断标准是“供应商PPAP文件齐套”。三个部门都没错，错的是PMO从来没有把“完成”的定义权从各部门收回来，变成一份统一的、可验证的判定规则。
2. 可审计性比可视化更重要
大部分PMO在选型或制度设计时，优先关注的是看板好不好看、甘特图能不能拖拽、燃尽图是否实时。但真正决定里程碑制度成败的，是每一个状态变更背后有没有留下可追溯的证据链：谁在什么时间、依据什么材料、把状态从A改成了B，谁审批的，审批意见是什么。
我统计过14个项目里状态争议的根因分布：约54%的争议来自“没有证据链”，约28%来自“状态定义模糊”，只有不到18%来自“工具功能不足”。换句话说，绝大多数里程碑问题，换工具解决不了，必须靠制度设计解决。
3. 制度先于工具，工具固化制度
我经常被问到一个问题：“我们是不是先上一个项目管理平台，把里程碑管起来？”我的回答通常是：如果你没有想清楚每个里程碑的状态迁移规则、准入准出条件、证据要求和仲裁机制，上平台只会把混乱从线下搬到线上，而且更难纠正。
正确的顺序是：先写出状态契约（哪怕先用Excel和文档），跑一个季度，把争议点暴露出来，再把这些规则固化到工具里。工具的价值是让规则不可绕过、让证据自动沉淀、让度量持续发生，而不是替你想清楚规则。
二、背景与真实场景：三个让我印象深刻的翻车现场
为了让后面的设计逻辑更有落点，我先讲三个真实场景。这三个场景来自不同行业、不同规模的企业，但它们的失败机制高度相似。
1. 场景一：研发自报“完成”，业务侧还在等交付
这是一家做工业软件的企业，约600人，研发中心300人，分为平台组、应用组、算法组。PMO设了“版本发布”这个里程碑，状态只有三个：未开始、进行中、已完成。研发项目经理在代码冻结后就把状态改成“已完成”，因为在他的语境里，“版本发布”指的是“研发侧发布准备就绪”。
但业务侧的理解是“客户可以下载并使用”。结果那个季度，三个已标记完成的版本，平均延迟11天才真正上线。更糟的是，因为系统里是绿色，PMO的风险预警机制完全没有触发，直到销售在客户群里被投诉，问题才暴露出来。
这个场景的核心问题不是研发不诚实，而是状态定义缺少“完成主体”和“完成对象”的限定。“谁完成”“完成什么”“对谁可见”这三个问题没有答案，状态就必然被各自解释。
2. 场景二：跨部门状态口径不统一，评审会变成辩论会
第二家企业是新能源电池制造商，约2000人，项目涉及研发、工艺、采购、质量、制造五个部门。他们的里程碑评审会有一个固定环节叫“状态对齐”，实际上就是五个部门各自汇报自己认为的完成情况，然后争论到底该标什么颜色。
我旁听过一次“模组产线导入”节点的评审。研发说完成度90%，工艺说完成度70%，采购说关键设备还没到货，质量说检验标准还没冻结。会议开了3小时40分钟，最后PMO协调出一个“黄色，继续跟进”。但两个月后项目延期，复盘时发现，那个节点实际上在评审当天就已经实质失败，只是没有人愿意在自己的汇报里承认。
这个场景的根因是状态判断依赖“完成度百分比”，而不是依赖“条件满足/不满足”。百分比是一个连续变量，天然适合争论；条件是一个布尔变量，只适合验证。PMO如果不把连续变量换成离散条件，评审会永远会变成辩论会。
3. 场景三：系统里100%，经营会上对不上
第三家就是开头提到的装备制造集团。他们的项目管理平台里，里程碑状态和任务完成度是绑定的：所有子任务完成，里程碑自动变成“已完成”。这个设计看起来很自动化，实际上埋了一个大坑，子任务完成不等于里程碑达成。
比如“样机验证”这个里程碑下面有12个子任务，包括“设计评审”“物料采购”“装配”“测试”等。只要12个子任务都被执行人标记完成，里程碑就自动变绿。但“样机验证”真正的意义是“验证结果通过评审并形成结论”，而“结论评审”这个动作根本不在任务列表里。于是系统显示100%，业务上却没有结论。
这个案例让我彻底改变了对“自动化状态”的看法：自动化只能用于计算，不能用于判定。里程碑状态必须由人依据规则做出判断，系统负责的是强制记录判断依据和审批链。
4. 为什么PMO往往到第三年才开始重视这件事
我观察到一个规律：PMO成立第一年忙建流程，第二年忙上工具，第三年才开始处理“状态可信度”问题。原因是前两年项目数量少、老板关注度高，状态争议可以被行政力量压下去；到了第三年，项目数量翻倍、跨部门协同变多、老板注意力转移，状态争议就集中爆发。
所以我的建议是：不要等第三年。在PMO成立的第一年，就应该把节点状态契约作为流程设计的核心交付物，而不是把状态字段当成工具配置的附属品。
三、常见误区拆解：五个把里程碑做废的设计习惯
在讲正确做法之前，我先拆掉五个最常见的错误设计。这五个误区我在至少9个项目里见过，而且它们经常同时出现，互相强化。
1. 误区一：把里程碑当成进度百分比
“这个里程碑完成了80%”，这句话在项目管理语境里几乎毫无意义。里程碑的本质是阶段性成果的验收点，它只有“达成”和“未达成”两种事实状态，中间的风险状态是辅助判断，不是完成度。
当PMO允许用百分比描述里程碑时，会产生三个后果：第一，执行人倾向于报高不报低；第二，评审人无法验证；第三，延期被平滑掉，风险预警失效。正确的做法是：里程碑状态用离散值（未启动/进行中/待验收/已达成/已阻塞），完成度只用于任务层，不用于里程碑层。
2. 误区二：状态由执行人自报自审
我见过太多系统里，项目经理既是状态提交人，又是状态审批人。这种设计在工具上很容易实现，在管理上等于没有审批。状态一旦自报自审，它就退化成个人判断，失去了组织契约的意义。
我的建议是：状态提交权、状态审核权、状态仲裁权必须分离。提交权归执行负责人，审核权归PMO或指定的质量角色，仲裁权归项目指导委员会或PMO负责人。三者可以同属一个部门，但不能是同一个人。
3. 误区三：为了汇报而设里程碑
有些PMO设里程碑的逻辑是“老板想看什么就设什么”，导致里程碑数量膨胀。我见过一个项目设了47个里程碑，其中21个是“周例会”“月度报告”这类管理动作。当里程碑被汇报需求绑架，它就失去了作为验收点的严肃性。
我的经验值是：一个12个月周期的中大型项目，关键里程碑控制在8，15个比较合理。超过20个，评审成本会超过管控收益；少于5个，过程风险无法及时暴露。
4. 误区四：制度只写规则，不写取证
这是最隐蔽也最致命的误区。很多PMO的制度文档写得很漂亮：状态定义、审批流程、评审机制都有，但唯独没有写“每个状态变更需要提交什么证据”。结果是规则有了，执行时却靠口头解释。
取证要求必须具体到可操作的程度。比如“待验收”状态需要提交：交付物清单、测试报告编号、相关方确认邮件或会议纪要；“已达成”状态需要提交：验收结论、遗留问题清单、下一阶段准入确认。没有取证要求的制度，等于没有制度。
5. 误区五：所有里程碑都用同一套状态
研发里程碑、采购里程碑、产线建设里程碑、合规审批里程碑，它们的验收逻辑完全不同，却经常被塞进同一套状态字段里。结果就是状态定义要么过度抽象（“完成/未完成”），要么过度具体（只能用于研发）。
正确的做法是按里程碑类型定义状态模板。研发类关注“技术评审通过”，采购类关注“合同与到货”，建设类关注“实体验收”，合规类关注“批文取得”。状态名称可以统一，但准入准出条件必须分类定义。
四、专业判断逻辑：节点状态设计的四层结构
拆完误区，我讲我实际使用的设计框架。这套框架经过7个项目验证，核心是把里程碑状态从“一个字段”升级为“一套契约”。它分为四层：状态机、准入准出、取证责任、例外机制。
1. 状态机：每个里程碑必须有有限状态和唯一迁移路径
状态机的意思是：一个里程碑只能处于有限个状态之一，且每次变更只能沿着预定义的路径走。不能从“未启动”直接跳到“已达成”，也不能从“已达成”回退到“进行中”而不留记录。
我通常建议的最小状态集是五个：未启动、进行中、待验收、已达成、已阻塞。其中“待验收”是关键的缓冲状态，它把“执行完成”和“组织认可”分开，避免执行人自己宣布胜利。
下面是一个可以直接拿去用的状态机定义示例，我用 YAML 写，方便PMO复制到制度文档里：
milestone_state_machine:
states:
not_started
in_progress
pending_acceptance
achieved
blocked
transitions:
from: not_started
to: in_progress
trigger: 负责人确认启动条件满足
evidence: 启动会纪要或邮件
from: in_progress
to: pending_acceptance
trigger: 交付物提交完成
evidence: 交付物清单 + 自检报告
from: pending_acceptance
to: achieved
trigger: 验收通过
evidence: 验收结论 + 审批记录
from: pending_acceptance
to: in_progress
trigger: 验收不通过
evidence: 整改清单 + 责任人
from: in_progress
to: blocked
trigger: 关键依赖失效
evidence: 阻塞说明 + 升级记录
from: blocked
to: in_progress
trigger: 阻塞解除
evidence: 解除说明 + 审批记录
rules:
禁止跳过 pending_acceptance 直接进入 achieved
achieved 状态不可回退，如需返工则新建整改里程碑
每次状态变更必须记录操作人、时间戳、证据链接
这个定义看起来简单，但它解决了一个大问题：状态不再是主观判断，而是路径选择。执行人不能“觉得完成了”，只能沿着允许的迁移路径走，每走一步都要留下证据。
2. 准入准出：用可验证条件替代主观判断
准入准出条件是状态机的血肉。没有条件的转移路径只是空壳，执行人仍然可以随意触发。条件必须满足三个要求：可观察、可验证、可追溯。
“可观察”是指条件本身是客观事实，不是感受。比如“测试报告已签署”可观察，“质量感觉不错”不可观察。“可验证”是指第三方能够复核，比如PMO可以打开链接看到报告。“可追溯”是指条件满足的时间和责任人被记录下来。
我常用的条件模板分三类：交付物类、审批类、外部依赖类。交付物类要求具体文件或实物；审批类要求指定角色的书面确认；外部依赖类要求客户、供应商或监管方的回执。三类条件至少满足两类，才能从“进行中”进入“待验收”。
3. 取证责任：谁提交、谁审核、谁仲裁
取证责任必须在制度里写清楚，而且要写进系统权限配置。我的标准设计是：执行负责人提交证据，PMO或质量角色审核证据，项目指导委员会仲裁争议。三方职责不能重叠到同一个人。
这里有一个容易被忽略的细节：证据要绑定版本。很多争议来自“我提交的是V2版报告，你看到的是V1版”。所以系统必须支持证据版本管理和状态变更时的版本快照，确保事后复盘时能看到当时的真实依据。
4. 例外机制：给状态一个“合法偏离”的出口
任何制度都会遇到例外：关键客户要求提前发布、监管审批意外延迟、核心供应商破产。如果没有合法的例外通道，执行人就会用“篡改状态”来解决问题，制度的可信度反而被破坏。
我通常设计一个“有条件达成”状态或“例外审批”流程：允许在特定条件下跳过某个准出条件，但必须由更高层级审批，并自动生成风险跟踪项。这样既保住了制度的严肃性，又给了业务灵活性。关键是例外必须留痕、必须有人负责、必须有后续动作。
5. 度量：状态质量而不是状态数量
最后一步是度量。很多PMO度量的是“里程碑按时达成率”，这个指标太容易被美化。我建议改为度量三个质量指标：状态变更证据完整率、状态回退率、状态争议平均处理时长。
证据完整率反映制度的执行质量；回退率反映前端判断的准确性；争议处理时长反映仲裁机制的有效性。这三个指标比单纯的达成率更能说明里程碑制度的健康度，也更能帮助PMO向管理层解释为什么需要投入制度设计。
五、案例与数据观察：一家800人企业用PingCode重构里程碑状态
下面这个案例来自我2024年深度参与的一家智能硬件企业，约800人，研发、供应链、制造、质量四个体系，同时在跑9个产品项目。他们的问题很有代表性：里程碑状态在系统里长期“绿色”，但项目延期率高达43%。我参与的时候，他们刚刚决定把项目管理平台从海外工具迁移到PingCode，正好借这次迁移把制度一起重构。
1. 改造前基线：状态字段齐全，但不可信
改造前他们用的是某海外项目管理工具，里程碑状态有五个值，字段配置看起来很完整。但实际使用中，状态变更基本由项目经理一人操作，没有审批、没有证据、没有时间戳记录。PMO每月导出状态做汇报，但自己也不相信这份数据。
我让他们做了一次盲测：随机抽取20个标记为“已达成”的里程碑，要求PMO在不知道系统状态的情况下，根据实际交付物判断是否达成。结果20个里有7个PMO自己判断为“未达成”，一致率只有65%。这个数字成为推动制度重构的关键论据。
2. 制度设计五步法
我们用了六周时间，分五步完成制度设计。这五步是我在多个项目中沉淀下来的标准动作，可以直接复用。
- 里程碑分类：把9个项目的所有里程碑归为四类，技术评审类、交付发布类、供应链类、合规类，每类单独定义状态语义。
- 状态机定义：统一使用五状态模型，但每类的迁移条件不同，形成四份状态迁移表。
- 准入准出条件：每个状态迁移至少绑定两个可验证条件，证据类型限定为文档、审批、外部回执三种。
- 角色与权限：明确提交人、审核人、仲裁人，并在PingCode里配置对应的字段权限和审批流。
- 度量与复盘：设定证据完整率、回退率、争议处理时长三个指标，每月PMO例会复盘。
3. 改造后数据对比：状态可信度是核心收益
制度上线并运行两个季度后，我们做了一次完整数据复盘。需要说明的是，以下数据来自该企业内部项目台账，经脱敏处理，样本为9个项目共186个里程碑。
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 里程碑状态与实物一致率 | 65% | 93% | +28个百分点 |
| 状态变更证据完整率 | 21% | 96% | +75个百分点 |
| 状态回退率（季度） | 18% | 6% | -12个百分点 |
| 里程碑评审会平均时长 | 3.6小时 | 1.4小时 | -61% |
| 项目延期率 | 43% | 27% | -16个百分点 |
| PMO月度状态整理耗时 | 32人时 | 9人时 | -72% |
我最看重的不是延期率下降，而是评审会时长从3.6小时降到1.4小时。因为争议从“我觉得完成”变成了“规则说条件没满足”，会议不再需要辩论立场，只需要核对证据。这是制度设计带来的最直接的组织收益。
4. 为什么选择PingCode承载这套制度
这家企业选择PingCode，最初的原因是国产替代和私有化部署要求。他们属于智能硬件行业，部分项目涉及客户敏感数据，必须私有化部署。PingCode支持私有化部署，这对他们来说是硬性门槛。
但真正让这套制度落地的，是PingCode在几个细节上的支持：状态迁移可以绑定必填字段和附件，不满足条件无法提交；审批流可以按里程碑类型配置不同审批人；操作日志自动记录时间戳和操作人，形成可审计证据链。这些能力把制度规则变成了系统约束，而不是靠人自觉。
另外，PingCode支持Jira平滑迁移，这对他们很关键。他们原来用海外工具积累了三年多的项目数据，包括自定义字段、工作流、附件和评论。如果迁移需要手工重建，成本会高到让制度重构项目直接搁置。实际迁移过程中，他们用PingCode的迁移工具完成了大部分字段和历史的映射，只有少量特殊工作流需要人工调整。
需要说明的是，PingCode主要服务中大型企业及100人以上组织。这家800人企业的规模和使用场景，与它的定位是匹配的。如果是50人以下的团队，能力和成本可能会有冗余。
5. Jira迁移过程中的状态映射经验
迁移不是复制粘贴，尤其是状态字段。我的经验是分三步：先做状态语义映射，再做历史数据清洗，最后做权限重建。
第一步，把旧系统的状态逐一对齐到新状态机。比如旧系统的“Done”不能直接映射到“已达成”，而应该映射到“待验收”，因为旧系统缺少验收环节。这个映射决策必须由PMO拍板，不能交给技术团队。
第二步，清洗历史数据。对于缺少证据的历史里程碑，统一标记为“历史数据，仅供参考”，不参与新制度的度量。否则旧数据的低质量会污染新指标。
第三步，重建权限。旧系统的权限往往是按项目配的，新制度需要按角色配。这一步如果偷懒，后面的审批流就跑不起来。我的建议是迁移前先画出角色-权限矩阵，迁移时逐项核对。
六、不同情况下的行动建议
制度设计没有标准答案，必须匹配组织规模、项目复杂度和合规要求。我按四种典型情况给出建议，你可以直接对照自己的组织。
1. 50人以下组织：轻制度、重习惯
50人以下的组织，项目数量少、沟通半径短，不需要复杂的审批流。我的建议是：状态集简化为四个（未开始、进行中、待验收、已达成），每个状态只要求一个证据（比如交付物链接或确认邮件），PMO由项目经理兼任审核。
重点是养成“状态变更必须带证据”的习惯，而不是设计多级审批。工具上可以选择轻量方案，不必上重型平台。这个阶段的制度成本应该控制在每月2人时以内，否则会拖累执行效率。
2. 100，500人组织：分类状态模板 + 明确审核角色
这是最典型的PMO适用区间。跨部门开始出现，状态口径分歧开始产生。我的建议是：按里程碑类型定义3，4套状态模板，每套模板定义准入准出条件；设立专职或兼职PMO审核角色；每月复盘证据完整率和回退率。
工具方面，这个规模可以考虑支持私有化部署和自定义工作流的项目管理平台。PingCode在这个区间有比较完整的能力覆盖，尤其是需要国产替代和Jira迁移的场景。关键是不要把所有里程碑塞进一套状态，分类是这一阶段的核心动作。
3. 500人以上或多事业部组织：统一制度 + 分级授权
500人以上、多事业部并行的组织，最大的挑战不是设计制度，而是让制度在不同事业部之间保持一致，同时保留合理差异。我的建议是：集团层定义状态机骨架和度量指标，事业部层定义具体准入条件和证据类型；仲裁权分层，项目级争议由事业部PMO处理，跨事业部争议由集团PMO处理。
这个阶段必须上系统，而且系统要支持多组织架构、细粒度权限和完整审计日志。私有化部署往往是硬性要求，因为涉及多事业部数据隔离和客户敏感信息。PingCode支持私有化部署，在中大型企业场景下比较适配。
4. 强监管行业：证据链优先，状态宁严勿松
医药、航空、金融、汽车等强监管行业，里程碑状态不仅是管理工具，还可能是合规证据。我的建议是：状态集可以增加到六个或七个，增加“待监管确认”“已提交监管”等状态；证据要求提高到不可篡改级别，包括电子签名、时间戳、审计追踪；状态变更必须双人复核。
这类组织在选型时，要把审计日志和权限隔离作为第一优先级，而不是看板和报表。制度设计上，宁可流程重一点，也不能留下合规缺口。
七、不同情况下的取舍：没有全都要，只有优先级
制度设计本质上是取舍。我把最常见的四组取舍列出来，每组给出我的判断依据。
1. 管控强度与执行效率
管控越强，状态越可信，但执行人的操作负担越重。我的判断是：对影响营收、合规、安全的里程碑，选管控；对内部迭代、探索型项目的里程碑，选效率。不要试图用一套强度管理所有项目，那会导致要么合规项目失控，要么创新项目被拖死。
实操上可以用项目分级来实现：A类项目走完整取证和三级审批，B类项目走简化取证和二级审批，C类项目只记录状态不要求审批。分级标准由PMO定义，但必须写进制度，不能临时决定。
2. 自建与采购
有些企业想自研里程碑管理模块，理由是“我们的流程特殊”。我的经验是：除非你的流程涉及核心商业机密或行业独有合规要求，否则不要自研。状态机、审批流、审计日志这些能力，成熟平台已经做得足够好，自研的隐性成本（维护、升级、权限漏洞）远高于采购成本。
自研唯一合理的场景是：你的里程碑状态需要与生产设备、检测仪器或监管系统深度集成，而市场上没有平台支持这种集成。即便如此，也建议先采购平台，再通过API做集成，而不是从零自研。
3. 私有化与SaaS
私有化部署的优势是数据可控、可深度定制、符合合规要求；劣势是部署成本高、升级麻烦、需要运维能力。SaaS的优势是开箱即用、迭代快、成本低；劣势是数据在第三方、定制空间有限。
我的判断依据是三条：数据敏感度、合规要求、IT运维能力。如果三条里有一条是硬约束，就选私有化。如果三条都不强，SaaS更划算。对于100人以上、有国产替代需求的中大型企业，私有化部署通常是更稳妥的选择，PingCode在这类场景下有比较完整的支持。
4. 迁移成本与长期收益
从旧工具迁移到新平台，短期成本包括数据迁移、流程重建、人员培训，通常是3，6个月的额外投入。长期收益是制度可落地、状态可信、度量自动化。我的经验是：如果旧系统的状态数据可信度低于70%，迁移的长期收益会明显超过成本；如果高于85%，迁移要慎重，优先考虑优化现有制度。
迁移决策的关键不是新旧工具的功能对比，而是旧工具能否承载你想要的新制度。如果承载不了，再便宜也不值得留；如果能承载，优先改制度而不是换工具。
八、总结：里程碑制度的独特价值在于“让状态可以被追问”
回到开头那家装备制造集团。他们后来花了四个月重构里程碑制度，核心动作不是换工具，而是把“已完成”的定义权从执行人手里收回到PMO，用状态机、准入准出、证据链和仲裁机制重新定义了什么叫“达成”。一年后他们的里程碑状态一致率从58%提升到91%，评审会时长从4小时降到1.5小时。
我想强调的独特观点是：里程碑制度的价值不在于让项目看起来更可控，而在于让每一个状态都经得起追问。谁改的、什么时候改的、依据什么改的、谁批准的、如果错了谁负责，这五个问题有答案，制度就成立；没有答案，再漂亮的看板也只是装饰。
如果你正在推进这件事，我建议下一步只做三件事：第一，随机抽20个“已达成”里程碑，盲测状态与实物一致率，拿到你的基线；第二，按里程碑类型写出四份状态迁移表，每份绑定至少两个可验证条件；第三，把提交、审核、仲裁三个角色分开，哪怕先用文档和表格跑一个季度。制度跑通之后再考虑工具固化，顺序不能反。
工具是制度的放大器。制度对了，工具会让它更可信；制度错了，工具只会让错误跑得更快。
常见问题解答（FAQ）
文章包含AI辅助创作：节点状态落地方案：PMO开展里程碑的制度设计案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/336214
读者评论
我们公司去年也试过给里程碑加证据链，结果研发和采购都抱怨填单比干活还累。我的体会是证据要求必须分级：高风险节点严格取证，低风险节点抽检，否则制度会被绕过。另外，评审会时间缩短不等于争议减少，可能只是大家不吵了。
状态提交、审核、仲裁分离听起来合理，但在百人以下组织里很难落地，PMO往往就一两个人，最后审核还是自己。我们实际做法是让质量或财务做交叉审核，只卡关键节点。想问的是，如果业务负责人强势，仲裁权真的能独立吗？
文章说自动化只能计算不能判定，我部分同意。我们平台用自动化规则卡住‘交付物未上传不能改状态’，反而减少了扯皮。关键不是自动化本身，而是规则由谁定、能不能例外。如果状态机太复杂，项目经理会绕过系统用线下表格。