去年第四季度，我参与复盘了一个跨部门的年度大促项目。立项会上六个里程碑日期一次性拍定，白纸黑字写进排期表，所有部门负责人都说“没问题”。结果是：第一个里程碑延期4天，第二个延期6天，等到“素材终稿交付”这个节点时，已经比原计划晚了11天，最终上线只推迟了3天，代价是设计团队连加一周班，测试把三轮回归压成一轮，上线后两天出了两个线上问题。这件事让我重新审视一个问题：跨部门项目的节点日期，到底是怎么定出来的？
大多数人以为是“算出来的”，其实真正决定成败的是“谈出来 + 推出来的”。这篇指南，我想把里程碑从0到1拆开讲清楚，包括我踩过的坑、验证过的方法，以及在中大型组织里能真正跑通的落地方式。
一、先给结论：节点日期的本质是约束，不是预测
如果只用一句话概括我这些年做跨部门里程碑的经验，那就是：节点日期不是“我们什么时候能做完”，而是“我们最晚什么时候必须交，才不会把下游拖死”。这是两种完全不同的思维，前者是预测，后者是约束。预测一定会偏，约束可以被管理。
很多团队做不好节点日期，根本原因就是把两个问题混在一起讨论：技术可行性问题和业务必要性问题是两张桌子上的事，必须分开谈，最后再合并。把它们混在一起的会议，通常开三小时也没结论。
1. 五条核心结论，先摆在这里
第一，节点日期要“反向定约束，正向验可行”。先由业务方给出最晚可接受日期，再由交付方评估可行性；不可行就谈范围，而不是直接改日期。
第二，每个里程碑必须有唯一责任人。责任落到“人”，不落到“部门”。一个里程碑挂三个部门，等于没人负责。
第三，缓冲要集中管理，不要分散到每个部门。每个部门各自加20%缓冲，叠加起来会虚胖；集中在项目层加一次，反而更准。
第四，日期要分两轨：承诺日期和内部目标日期。对外承诺一个，对内追踪一个更紧的，两者之间就是你的安全垫。
第五，里程碑数量要控制。一个交付周期里，2到5个里程碑是健康区间，超过7个就变成了“周报节点”，不再有决策价值。
2. 一个反常识判断：改日期不一定是失败
很多项目经理把“里程碑日期被改”当成项目失控的信号，我不同意。真正危险的不是改日期，而是日期明明已经不可能实现，却没人敢提出来。我见过最糟的项目，不是延期最多的那个，而是所有里程碑在系统里都是“绿色”，直到交付前一天集体变成红色。
所以我在团队里立了一条规矩：里程碑日期可以改，但必须走正式变更，并说明三个信息，为什么改、影响哪些下游、用什么换回来。没有这三条的改期申请，一律驳回。
二、背景与真实场景：跨部门节点为什么天然容易失控
理解节点日期为什么难做，要先理解跨部门项目的三个结构性特征。它们不是管理不善造成的，而是组织形态自带的。
1. 三个结构性难题
难题一：共同上级太远。跨部门项目里，产品、研发、设计、法务、供应链各自的直属上级不同，项目经理通常只有协调权没有考核权。这意味着节点日期本质是一个“协商结果”，而不是“命令结果”。
难题二：依赖链是串行的，但估算是并行的。各部门在自己会议室里估工期时，默认上游会准时交付；可一旦某个上游晚两天，下游所有节点整体后移，而插入缓冲的人几乎没有。
难题三：信息不对称带来的乐观偏差。负责执行的团队知道所有风险，负责汇报的层级倾向于报一个“好看的数”。每上一层，日期就被美化一次，到项目委员会桌上时，已经离真实情况很远了。
我做过一个粗略统计：在一个涉及7个部门的项目里，从一线执行者到项目决策层，同一里程碑的完成时间预期平均相差9到14天。这个差值不是撒谎，而是每一层都在做“礼貌性乐观”。
2. 一个典型场景的时间账
以我参与的一个消费品新品上市项目为例，从立项到渠道上架，名义周期是16周。把时间账拆开看，会发现大量消耗并不在“干活”上，而在等待、评审、返工和排队上。
3. 延期原因的真实分布
我把过去三年参与复盘的跨部门项目延期原因做了归类。结论有点反直觉：纯技术难题导致的延期占比并不高，最大头是“依赖没对齐”和“验收标准模糊”。
三、拆解常见误区：六个让节点日期失效的做法
下面这六条，几乎每一条我都在真实项目里见过，有的还是我自己早期犯过的错。它们单独出现时影响有限，叠加出现时足以让一套排期表彻底失去参考价值。
1. 误区一：把节点日期当成“计划完成日”
这是最普遍的误区。团队说“研发大概6周能完成”，于是在计划里写上“第6周末完成研发”。可“大概”是50%分位数的意思，也就是有一半概率做不完。用中位数当承诺日期，项目本身就注定有一半概率延期。
我的做法是：中位数用于内部目标，75%到85%分位数用于对外承诺。这两个数之间的差距，就是你必须显式管理的风险区间。
2. 误区二：各部门分别承诺，项目组做加法
每个部门都报一个“我能做到”的日期，项目组在Excel里纵向相加，得到总周期。这个算法忽略了两件事：依赖关系导致的等待时间，以及各部门的乐观偏差会叠加而非抵消。
正确做法是先排依赖顺序，再逐段校准，最后统一加缓冲。加法的结果通常比真实需求短20%到35%。
3. 误区三：一刀切使用倒推法
“交付日是3月15日，倒推研发6周、设计2周、测试2周”，这种算法看起来很专业，但它默认每个环节的工期是固定的，而实际工期受范围、人力、并行度影响巨大。倒推法的正确用法是倒推出约束条件，再正向验证是否可行，而不是直接把它当计划。
4. 误区四：日期只写“哪天”，不写“验收什么”
“3月8日完成设计定稿”，这句话在跨部门语境里几乎没有约束力。什么是定稿？谁签字算数？修改几轮算超范围？我见过设计交付后被业务方推翻两次、延期9天的案例，双方都觉得自己没错。
我的模板里，每个里程碑必须同时写清三件事：日期、交付物清单、验收人和验收标准。缺任何一项，这个里程碑就不算定义完成。
5. 误区五：认为改期等于失败
把改期污名化，直接后果是团队隐瞒风险。我在一个项目里推行“绿色、黄色、红色”三色节点机制后，黄色（有风险但可控）的申报数量翻了3倍，而最终延期天数下降了近40%。让风险可见，才是控制风险的前提。
6. 误区六：缓冲加在部门内部，而不是项目层
每个部门各自留10%缓冲，看起来安全，实际上这些缓冲互相不共享：A部门提前完成了，缓冲不会转移给延期的B部门。结果是项目整体缓冲虚高，局部却毫无弹性。
我推荐缓冲集中在项目层，由项目经理统一分配。部门只报“真实工作量 + 已知风险”，不加隐藏缓冲。
四、专业判断逻辑：里程碑日期的四层推算法
这套方法我在不同规模的组织里试过，最后沉淀成“四层推算法”。核心思想是：把不同类型的判断拆到不同层去做，每层只回答一个问题，最后再合并。这样做的最大好处是避免在同一个会议上既谈业务必要性又谈技术可行性。
1. 第一层：约束层，确定不可动摇的日期
约束层只回答一个问题：哪些日期是外部给定的、不可协商的？典型来源包括监管申报窗口、渠道档期、展会时间、合同交付条款、财务结账日。
这一层的输出是一张“硬约束清单”。注意，硬约束通常很少，一个项目里一般不超过3个。如果列出来有10个，说明你把“希望”当成了“约束”。
2. 第二层：依赖层，画出关键路径
依赖层回答：为了满足硬约束，必须按什么顺序完成哪些事？这一步的产物是依赖图和关键路径。关键路径上的任何一个环节延期，都会直接推动最终日期。
我在实践中要求团队做两件事：一是把依赖写成“A完成 → B才能开始”的明确句式；二是标注依赖类型是“硬依赖”（必须串行）还是“软依赖”（可并行但需协调）。很多所谓的“必须等”，其实是软依赖。
3. 第三层：容量层，用可用人天，而不是意愿估工期
容量层回答：在给定时间窗内，团队实际能投入多少人天？这一步是跨部门项目最容易糊弄的地方。正确的做法是拿排期表减去休假、其他项目占用、会议与支持时间，剩下的才是可用容量。
我常用的估算是：一个工程师每周有效投入按3.5人天计算，而不是5人天。中大型组织里，会议、评审、临时支持通常吃掉20%到30%的时间。按5天算出来的工期，几乎必然延期。
4. 第四层：风险层，用缓冲吸收不确定性
风险层回答：这套计划在多大程度上会偏？需要多少缓冲？我的经验规则是按项目不确定性分级加缓冲：
- 需求明确、团队稳定、有历史数据：加10%到15%缓冲
- 需求基本明确、跨3个以上部门：加20%到25%缓冲
- 需求探索型、涉及外部供应商或监管：加30%到40%缓冲
缓冲要挂在项目层，不挂在部门层。使用时由项目经理决定投放位置，比如优先补到关键路径末端。
5. 合并计算：一段可复用的伪代码
把四层合并，逻辑大致如下。这段代码不是让你照抄去写工具，而是帮助你把判断过程显式化。
输入：硬约束日期集合 C、任务依赖图 G、各角色可用人天 A、不确定性等级 L
输出：里程碑日期表 M、项目级缓冲 B
对每个硬约束 c in C：
从 c 反向遍历 G，标记出所有关键路径任务集合 P_c
对 P_c 中每个任务 t：
估算工作量 E_t（取历史数据的 50% 分位）
计算工期 D_t = E_t / (该角色可用人天 A_role / 时间窗天数)
按依赖顺序累加 D_t，得到无缓冲完成时间 T_base
按不确定性等级 L 计算缓冲：
B = T_base * buffer_ratio(L) // 10% / 20% / 30%
检查 T_base + B 是否早于硬约束 c
若早于：可行，写入 M，缓冲挂在项目层
若晚于：触发范围协商，而不是直接改日期
为每个里程碑补充：交付物清单、验收人、验收标准
6. 缓冲比例与按期交付概率的关系
缓冲不是越多越好。加太多，团队会自然膨胀填满时间（帕金森定律）；加太少，风险暴露。我观察到的拐点在20%到25%之间：这个区间内按期交付概率提升最快，超过30%之后边际收益明显下降。
五、案例与数据观察：一套里程碑体系在300人研发组织的落地
2023年，我深度参与了一家制造企业研发中心的里程碑体系改造。该中心约300人，横跨产品、硬件、软件、测试、合规五个部门，同时并行20多个项目。改造前的状态很典型：里程碑日期靠邮件确认，变更靠口头通知，每月项目例会花三小时对数。
1. 改造前的四个具体问题
问题一：里程碑定义不统一。同样叫“设计冻结”，硬件部门指图纸归档，软件部门指接口文档评审通过，业务部门指样品可演示。三个部门对同一个节点的理解完全不同。
问题二：日期变更无痕迹。一个里程碑改了三次，只有当事人记得，季度复盘时无法还原决策过程。
问题三：依赖关系不可见。20多个项目共享测试资源，但没人能说清测试排期冲突会在哪一周爆发。
问题四：跨部门数据靠人工汇总。每个月项目经理要花近两天时间收集、核对、整理进度数据。
2. 用PingCode落地里程碑管理
这家企业最终选择用PingCode来承载这套体系。选择原因有三个，都和跨部门里程碑管理直接相关。
第一，PingCode主要服务中大型企业及100人以上组织，产品设计天然考虑了多项目并行、跨部门依赖和容量规划这些场景，不需要靠大量定制去补。第二，它支持私有化部署，对制造业这类对数据边界敏感的企业是硬性条件。第三，它支持Jira平滑迁移，该企业原有的Jira数据可以较完整地保留历史记录，避免了“换工具等于丢掉三年项目档案”的尴尬，这也是它作为国产替代方案被选中的关键原因之一。
落地时我们没有一上来就全面铺开，而是选了3个跨部门项目做试点，重点做四件事：
- 统一里程碑模板：每个节点强制填写交付物清单、验收人、验收标准三项
- 建立依赖登记：所有跨部门依赖必须在系统中显式登记，不允许只写在邮件里
- 设置双轨日期：承诺日期对业务方可见，内部目标日期由项目组追踪
- 项目级缓冲池：缓冲不分配到部门，由项目经理按关键路径动态投放
3. 试点三个月的数据变化
试点覆盖3个项目、合计21个里程碑。三个月后的对比数据如下。
同期还有一个数据值得注意：项目经理每月的进度汇总耗时，从平均1.8天降到0.4天。这部分节省出来的时间，被重新投入到依赖协调和风险处理上，形成了正向循环。
4. 一个值得单独说的发现：部门信心差异
试点期间我让五个部门负责人对同一个里程碑日期打分（1到10分，10分代表“非常有信心”）。结果差异之大超出预期。这个发现直接改变了我对“日期是否达成共识”的判断方式，口头同意不等于真正共识。
六、不同情况下的行动建议
同样的方法，在不同规模、不同成熟度的团队里用法完全不同。照搬流程往往比不做还糟。下面按团队规模给出我的具体建议。
1. 50人以下团队：够用就好，别上重流程
这个规模的团队通常沟通成本低，一个群就能对齐。我的建议是只做两件事：每个里程碑写清交付物和验收人；每周用15分钟过一遍依赖变化。不要建复杂的容量模型，投入产出比不划算。
工具层面，轻量看板足够，不需要引入重型项目管理平台。过早引入重流程，反而会消耗掉小团队最大的优势，反应速度。
2. 100到300人团队：这是最需要体系化的区间
这个规模是典型的“尴尬区间”：靠喊话已经对齐不了，但流程还没固化。我的建议是建立三套最小机制。
- 里程碑模板标准化：统一交付物、验收人、验收标准三个字段，先解决“同一个词不同理解”的问题
- 依赖登记制度：所有跨部门依赖必须显式登记，每周更新一次状态
- 项目级缓冲池：取消部门内部隐藏缓冲，改由项目经理统一管理
这个规模也正好是PingCode这类平台发挥价值的起点。它服务中大型企业及100人以上组织，容量规划、跨项目依赖、多角色权限这些能力，恰好对应上面三套机制落地时最费人的部分。如果企业原本使用Jira，迁移过来能保留历史数据，切换成本会低很多。
3. 300人以上组织：机制之上要有度量
到这个规模，靠人工管理已经不可能了。我的建议是在前面三套机制之上，再补两件事：建立里程碑准时的历史基线，用于校准估算偏差；建立跨项目资源冲突的预警，因为大组织里最大的延期诱因往往不是单个项目出问题，而是多个项目抢同一批人。
私有化部署在这个规模通常会成为硬要求，一方面是数据边界，另一方面是要和内部账号体系、报表体系打通。选型时这一点要提前确认，不要等到实施阶段才发现不满足。
七、不同情况下的取舍
做节点日期管理，最难的不是方法本身，而是在几组矛盾中做选择。下面四组取舍，我在不同项目里做过不同选择，没有标准答案，但有判断依据。
1. 准确性与速度的取舍
想要更准的日期，就要花更多时间做前期对齐。四层推算法比部门自报相加多花大约15到18人天，但能把准时率从50%区间拉到80%区间。
我的判断依据是项目不可逆程度：如果延期代价是错过渠道档期、监管窗口、合同违约，那前期多花的每一人天都值得；如果只是内部迭代，快速启动、边做边调更划算。
2. 里程碑数量与决策价值的取舍
里程碑设得多，看起来管控更细，实际会稀释注意力。超过7个之后，团队会把它们当成普通任务节点，而不是决策点。
我的取舍原则是：只在“需要跨部门共同决策”或“需要正式验收”的位置设里程碑。单纯的进度节点，用任务状态跟踪就够了，不必升级成里程碑。
3. 缓冲集中与责任清晰的取舍
缓冲集中在项目层，弹性最好，但会带来一个副作用：部门容易觉得“反正有项目池兜底”，从而放松自我管理。
我的应对办法是双指标考核：既看最终里程碑是否准时，也看各部门自身承诺的完成情况。缓冲只用于吸收不可预见风险，不用于弥补可预见的拖延。
4. 工具化与流程化的取舍
很多团队希望通过换工具解决里程碑管理问题，结果发现工具上线后数据依然没人维护。我的判断很明确：流程不清楚的时候，工具只会把混乱数字化。
正确的顺序是先把里程碑定义、责任人、变更规则这三件事谈清楚，再用工具固化。工具的价值在于让规则可执行、可追溯，而不是替代规则本身。
八、下一步：从哪个里程碑开始动手
聊到这里，我想回到最开始那个问题。跨部门项目的节点日期之所以难，不是因为它需要多高深的技术，而是因为它同时牵扯业务必要性、技术可行性、组织权力和人性偏差。把这四件事放在一次会议里解决，注定失败；把它们拆开、分层、逐个击破，就会变得可控。
我的独特判断是：节点日期管理的核心指标不是“准时率”，而是“风险可见度”。一个准时率90%但没人敢报风险的团队，比一个准时率70%但风险透明的团队危险得多。前者的问题只是还没爆发，后者的每个问题都在被处理。
如果你打算明天就开始动手，我建议按这个顺序走：
- 挑一个正在进行的跨部门项目，不要新建试点项目，就用真实的、有压力的那个
- 把现有里程碑重写一遍，每个补上交付物清单、验收人、验收标准三项，缺一项就标红
- 画一次依赖图，只标硬依赖，看看关键路径上到底有哪几个环节
- 算出有效人天，用3.5天每周而不是5天，重新估一次工期
- 把缓冲从部门收回到项目层，按20%到25%设置一次，观察一个迭代
- 建立三色风险申报机制，明确黄色申报不追责，这是让数据变真的关键一步
这六步做完，大约需要两到三周。你会得到一套比现在准确得多的节点日期，更重要的是，你会第一次真正看清项目里有哪些风险在被隐藏。至于工具，等你把规则跑顺了再选，那时你会更清楚自己需要什么，如果组织规模在100人以上、需要私有化部署、并且希望从现有平台平滑迁移，PingCode这类面向中大型企业的平台值得列入备选；如果只是几十人的小团队，先用好现有的看板工具就够了。
最后送你一句我在项目复盘里反复验证过的话：里程碑日期不是用来预测未来的，是用来暴露分歧的。分歧暴露得越早，交付就越接近你说的那一天。
常见问题解答（FAQ）
1. 跨部门项目的节点日期，到底该由项目经理定，还是让各部门自己报？
我第一次带跨部门项目的时候，直接按老板给的 deadline 倒推，把节点日期排好了发到群里，结果研发说排期早满了，市场说物料根本来不及。当时我挺委屈的，我是为了推进度才定的日期，怎么反而成了众矢之的。后来我一直在想，这个日期到底该谁说了算？
我的做法是：项目经理定约束，执行方定承诺，双方当场确认。具体分三步。第一，项目经理先输出硬约束，也就是上线窗口、外部发布日、合规截止日这类不可谈判的日期，把它当锚点。第二，让每个承接方给两个日期，最早可开始时间和最晚必须交付时间，而不是让他们报一个笼统的完成时间，因为人报完成时间一定会留安全垫。
第三，把两头日期对撞，差值就是冲突，冲突必须当场暴露给双方的共同上级，不要靠项目经理私下磨。判断依据是：节点日期的所有权属于执行方，约束的所有权属于项目经理。如果一个节点没有任何人愿意以承诺口径确认，那它就不是节点，只是一个愿望。
数据口径上建议区分三类日期：承诺日、计划日、实际日，每周只对比承诺日和实际日的偏差，偏差超过 3 个工作日就重新评估后续节点。坚持三个月，你会看出哪些部门的承诺系统性偏乐观，下次给他们排节点时自动加 10%~15% 缓冲。
2. 第一次做跨部门里程碑，节点日期怎么估才不至于全凭感觉拍脑袋？
我们团队以前排节点就是开会拍，谁嗓门大听谁的，老板说一句这个太久了，日期就往前提一周。结果项目跑了三个月，第一个节点就晚了半个月。我想知道有没有一套哪怕是土办法，也能让第一次定的日期靠谱一点，至少别差得离谱。
靠谱做法是三步：先算工作量，再算可用产能，最后加依赖缓冲。第一步做拆解，把节点拆到单个交付物，每个交付物不要超过 3 天工作量，拆不出来的说明还没想清楚。第二步算真实产能，不要用人数乘 8 小时，跨部门协作场景我一般按 0.6~0.7 的可用系数算，因为会议、审批、等回复会吃掉三到四成时间。
第三步加依赖缓冲，每个跨部门交接点单独放 1~2 天，而不是在总工期末尾放一个大缓冲，末尾大缓冲在现实中几乎一定会被前面吃光。判断依据是：跨部门项目的延期八成发生在交接处，不是发生在干活本身。没有历史数据怎么办？
用三点估算，让执行人分别给乐观、最可能、悲观三个值，按（乐观+4×最可能+悲观）/6 算期望值，这个公式真正的价值不是算得准，而是逼对方说出悲观值，悲观值往往最接近现实。最后把所有节点期望值加总，如果超过老板给的 deadline，就把差值摆到桌面上让业务方做取舍，而不是自己硬扛下来。
3. 节点日期定了，但怎么才能在到期前一两周就知道哪个节点要黄？
我最怕的场景就是周一问进度，大家回快了快了，周五突然说还要一周。等发现的时候，后面的节点已经连环塌了。有没有什么办法，不用天天盯人，也能提前一两周看出来哪个节点要出问题？
关键是别看完成百分比，要看可验证的产出。完成百分比是主观的，83% 和 85% 没有区别，但接口文档已提交评审这种说法是可以验证的。我的具体做法有三条。
第一，每个节点到期前一周设一个证据检查点，要求提交一份第三方能验证的东西，比如评审通过的文档、能跑通的 demo、已入库的测试用例，拿不出证据的节点直接默认红灯。第二，每周只记录一个指标：剩余工作量（人天），不记录完成率。
如果连续两周剩余工作量没有下降，哪怕进度报的是 80%，也说明卡住了，这个信号通常能提前 10~14 天出现。第三，红黄绿三档要带触发条件而不是靠感觉：绿灯等于证据已提交且无未关闭阻塞，黄灯等于存在未关闭的外部依赖，红灯等于剩余工作量连续两周未下降或关键人休假超过 3 天。
在项目管理平台里把这三档做成状态字段，周会只看红灯和黄灯，绿灯不讨论，会议时间能压缩一半以上。要接受一个事实：跨部门节点百分百准时是不可能的，目标不是零延期，而是让延期被提前两周发现，后面的节点还有机会重排。
4. 一个项目放多少个里程碑合适？里程碑和节点日期是同一回事吗？
我们项目的排期表上密密麻麻几十个时间点，每个都叫里程碑，开会的时候根本没人看得过来。也有人说里程碑应该少而重。我一直没搞清楚这两个词的区别，也不知道到底放几个才算合理。
两者不是一回事。节点日期是某件事必须在哪天之前完成的管理约定，数量可以很多；里程碑是项目到达了一个不可逆状态的标志，数量应该很少，它的作用是让项目外的人，比如老板、兄弟部门、客户，一眼知道项目走到哪了。
我的判断标准是，一个里程碑必须同时满足三条：有明确的验收物、产生对外可见的变化、通过之后不需要回退重做。按这个标准筛，一个 3~6 个月的项目留 4~7 个里程碑就够了，典型形态是需求冻结、方案评审通过、首个可演示版本、功能封版、上线、复盘关闭。
多出来的那些时间点应该叫节点日期或者检查点，挂到里程碑下面做二级结构，不要在同一个层级里混着展示。颗粒度上还有个实用规则：任何两个里程碑之间的距离不要超过 3 周，超过 3 周中间一定有值得单独看的节点，否则项目会出现长时间看起来没进展的焦虑期。
落地时在项目管理平台里把里程碑设成单独层级，用版本或阶段承载，节点日期挂在里程碑下面作为子任务或检查项，这样汇报时只看里程碑，执行时只看自己负责的节点日期，两种视角各有各的用途，不会互相干扰。
核心关键词
文章包含AI辅助创作：节点日期怎么做？跨部门团队入门指南：里程碑从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/342543
读者评论
四层推算法里的容量层，用3.5人天而不是5人天来估算，这个数字我认。但落到实际排期时，很多团队根本没有可靠的历史投入数据，最后还是会退回到拍脑袋。我们试过记录两个季度的真实占用，发现会议和临时支持吃掉的时间比想象的多不少，可惜这种记录很难坚持。想问问作者，容量数据缺失的阶段，有没有更轻的过渡办法？
把改期当成正常变更而不是失败，这点我完全同意。我们团队之前就是里程碑全绿到交付前一天集体变红，后来强制要求黄色风险必须提前申报，一开始大家怕被追责，报得很保守，过了两三个迭代才慢慢真实起来。不过我觉得三色机制能不能跑通，关键还是看上级怎么对待第一个报黄的人，报了就挨批的团队，这套东西活不过一个月。
文章里延期原因分布说纯技术难度只占8%，协作类占了大头，这个结论方向我信，但12个项目47个里程碑的样本量偏小，而且是复盘归因，人往往倾向于把延期归结为沟通和依赖问题，而回避自己技术评估不准。另外四层推算法前期对齐时间更长，跨部门协调权弱的项目经理可能推不动，最后还是会回到部门自报相加的老路。