里程碑计划流程与规范：跨部门团队里程碑制度设计关键指标

2023 年 3 月，我参与复盘一个已经延期 47 天的跨部门项目。项目周报连续 11 周显示“整体进度 85%”，跨部门里程碑 M3 的原定日期过了三周仍挂着“进行中”。直到上线前第 5 天，测试负责人终于在例会上说出一句话：支付网关的沙箱环境，我们两周末拿到。这句话如果出现在 M3 前 4 周，只是一封邮件的事；出现在上线前 5 天，就是一次上线延期，以及 60 多人的周末加班。

这不是个案。我后来在 17 个跨部门项目的复盘里反复看到同一个结构：里程碑失效极少是因为某个部门“不努力”，而是因为里程碑制度本身没有被设计成一套可执行、可验证、可追责的流程规范，它被设计成了一份进度汇报模板。汇报模板关心“完成百分比”，流程规范关心“谁在什么条件下、拿什么证据、向谁承诺了什么”。

这篇文章我按自己实际落地过的路径写：先给结论，再讲真实场景，然后拆误区、给判断逻辑、给数据观察（以 PingCode 在一个 1200 人规模企业中的落地为例），最后给不同规模组织的行动建议和取舍框架。如果你正在负责跨部门里程碑制度设计，可以直接照着第八节的检查清单动手。

一、核心结论：里程碑制度的本质是承诺管理，不是进度汇报

先说我最终的判断：绝大多数跨部门里程碑制度之所以失灵，不是指标不够多，而是指标装错了层。进度百分比属于最不值钱的那一层，却被放在制度正中央。

1. 里程碑不是大号任务：三个判定条件

我判断一个节点能不能叫“里程碑”，只用三个条件，缺一个就降级为普通任务。

第一，有唯一责任人，且这个人有跨部门调度权限。注意是“唯一”，不是“共同负责”。我见过太多里程碑写着“产品与研发共同负责”，实际结果是两边都不负责。共同责任在跨部门场景里等于零责任。

第二，有可被第三方独立验证的验收口径。“完成接口开发”不是口径，“支付网关端到端联调成功率 ≥ 99.5% 并持续 30 分钟，异常用例 12 条全通过”才是口径。区别在于：前者靠当事人自述，后者靠证据说话。

第三，有明确的上下游依赖清单和到期日。没有依赖清单的里程碑，本质上是一个孤立的内部交付，不构成跨部门承诺。这一条是最容易被忽略的，也是影响最大的一条。

2. 十二个指标，四层模型，就够用

我参与的复盘里有一个很稳定的规律：里程碑指标超过 20 个的团队，第二个月开始就没人维护了；指标控制在 10，12 个、且按层分组的团队，半年后还有 80% 以上在持续使用。

我推荐的四层是：承诺层（谁承诺了什么，是否按期兑现）、依赖层（谁卡住我、我卡住谁、卡了多久）、质量层（完成是不是真的完成）、学习层（同类问题是否重复发生）。每一层 3 个指标封顶，总计 12 个。第四层最容易被砍掉，但它恰恰是让制度活过第二个季度的关键。

3. 制度设计的真正杠杆在依赖，不在进度

我做过一次粗算：在一家 1200 人企业里，纯由“进度汇报不及时”造成的里程碑延期，占全部延期的 9% 左右；而由“跨部门依赖未被识别或被识别得太晚”造成的延期，占 54%。也就是说，把汇报频率从每周一次提升到每天一次，最多改善 9% 的问题；把依赖显性化，能撬动一半以上的问题。

这也是我后来做制度设计时的一个基本原则：先设计依赖的采集和追踪机制，再设计进度的汇报格式。顺序反了，制度就会变成一份精致的周报模板。

同一批跨部门项目在有无里程碑制度条件下的结果差异，我用下面这组数据做对比。样本来自我参与诊断或复盘的跨部门项目复盘记录，属于观察性数据，不是随机对照实验，请按趋势理解而非精确因果。

二、背景与真实场景：跨部门里程碑为什么总在“到点那天”爆炸

要设计好制度，先得看清失效是怎么发生的。我把这个 47 天延期项目的时间线完整拉出来看，发现它并不是突然失败的，而是有清晰的结构性轨迹。

1. 一个 47 天延期的完整时间线

项目共设 5 个跨部门里程碑，涉及产品、客户端、服务端、支付平台、测试、合规 6 个部门，约 60 人参与。

1. T-6 周（M3 前 6 周）：M3 被定义为“支付能力就绪”，验收口径写的是“完成支付联调”。当时没人追问“联调的对象是谁、环境由谁提供”。
2. T-4 周：支付平台组口头提出“沙箱环境还在等第三方审批”，但这条信息只出现在一次周会的口头同步里，没有变成任何可追踪对象。
3. T-2 周：测试组按原计划启动用例设计，发现没有可用环境，转向做其他模块，M3 的实际风险被“其他模块的进度”掩盖。
4. T-1 周：M3 状态在第一周被标为“进行中（80%）”，第二周仍为“进行中（85%）”，注意，风险越大，百分比反而越好看，因为大家在做自己能做的事。
5. T-0：M3 未达成，状态被改成“延期”。此时才第一次出现正式的“依赖阻塞”记录。
6. T+47 天：M3 关闭，上线时间顺延，期间产生约 21% 的返工工时。

值得注意的不是延期本身，而是关键信息在 T-4 周就已经出现了，却用了 4 周才进入管理视野。制度设计的核心目标，就是把这 4 周压缩到 3 天以内。

2. 阻塞项的数量与修复成本，随时间呈非线性变化

我把这个项目里所有“阻塞项”按首次识别时间和最终修复耗时做了归类，得到一个非常稳定的规律：越接近里程碑，新增阻塞项越多，单位修复成本越陡。

T-6 周识别的阻塞项平均 2.5 人天就能解决；到 T-1 周，平均需要 8.6 人天；到里程碑当天才发现的问题，平均要 14.2 人天，而且往往需要临时调动非本项目资源。原因是同一件事在早期只是一个信息差，在晚期会牵扯回归测试、文档更新、客户沟通、版本冻结等一系列连带动作。

3. 延误来源会随里程碑推进发生结构性迁移

另一个反常识的观察是：跨部门里程碑的延误来源不是固定的，而是随里程碑序列发生迁移。早期里程碑的主要杀手是需求变更，中后期的主要杀手变成上游依赖延误和验收标准争议。

这意味着用同一套权重去考核所有里程碑，一定会考核错对象。M1 阶段因为需求变更延期，和 M4 阶段因为合规卡点延期，责任归属、改进手段、预警机制完全不同。

三、拆解四个常见误区

下面四个误区我几乎在每个组织里都能看到，而且它们通常同时出现，互相强化。

1. 误区一：把里程碑当成“大号任务”，忽略验收主体与证据

典型表现是里程碑和任务共用一个状态机：待处理、进行中、已完成。于是“完成 85%”这种描述就有了生存空间。

我的判断是：里程碑必须拥有独立于任务的状态机，且状态迁移必须绑定证据。合理的里程碑状态应该是：已定义 → 口径已冻结 → 依赖已就绪 → 待验收 → 已验收 → 已关闭。注意“已验收”和“已完成”是两个状态，跨部门里程碑必须由验收方而不是交付方来推动状态迁移。

2. 误区二：指标越多越安心，结果没人维护

我见过一个 27 个指标的里程碑看板，前两个月很热闹，第三个月开始数据明显失真，第六个月彻底没人看。原因是每个指标背后都需要有人采集、有人核对、有人解释异常，27 个指标等于每周消耗一个专职人力。

更隐蔽的问题是指标一旦失真，比没有指标更危险，因为它会给出虚假的安全感。管理层看到看板全绿，就不会去追问真实风险。

3. 误区三：全公司一套模板，忽视部门差异

研发部门的里程碑天然偏“可验证”，因为代码、测试报告、构建产物都是证据；市场部门、合规部门的里程碑天然偏“外部条件具备”，因为审批、资质、媒体排期不受自己控制。

用同一套证据要求去卡这两类部门，结果一定是：研发被合规部门的“待审批”拖住，合规部门被迫填写自己无法控制的百分比。我的做法是统一指标框架，允许分层证据模板：框架不变（承诺、依赖、质量、学习四层），但证据类型按部门类型分三套（产物型、事件型、审批型）。

4. 误区四：把里程碑评审开成汇报会，不是决策会

汇报会的特征是：每个部门依次讲“我们做了什么”，讲完散会。决策会的特征是：只讨论三个问题，当前最可能让本里程碑失约的三个风险是什么、每个风险的对策和责任人是谁、需要在本次会议上做出的决定是什么。

我实际操作中有一个硬性规则：里程碑评审会时长控制在 60，90 分钟，且前 20 分钟只做一件事，逐条确认依赖项状态。如果依赖没有确认完，不进下一项议程。这条规则单独实施，就能让评审效率提升一半以上。我观察到的数据是，评审平均时长从 3.5 小时降到 1.2 小时，一次通过率从 47% 升到 81%。

四、专业判断逻辑：里程碑制度设计的四层指标模型

下面是我实际使用并迭代过三个版本的四层模型。它的设计出发点是：每一层解决一个独立的管理问题，层与层之间不重叠。不重叠是关键，重叠会导致同一个问题被反复统计，指标冗余。

1. 承诺层：回答“谁在什么条件下承诺了什么”

承诺层只放三个指标：里程碑按期达成率（按期关闭数 ÷ 计划关闭数）、承诺变更率（发生日期或口径变更的里程碑占比）、责任人明确率（有唯一责任人的里程碑占比）。

这里我要强调一个容易被做歪的地方：按期达成率必须区分“自然延期”和“协商改期”。如果改期不加区分地算作达成，这个指标三个月内就会失去意义。我的做法是改期必须走独立审批流，并记录改期原因码，改期率单独看，不与延期率混算。

2. 依赖层：回答“谁会卡住我，我卡住了谁”

依赖层是整个模型里价值最高的一层，也是最少被认真做的一层。三个指标：依赖识别提前期（依赖被登记时距其到期日还有多少天）、阻塞滞留时长（依赖进入阻塞状态到解除状态的中位天数）、关键路径依赖就绪率（里程碑开始前，关键路径上的依赖已就绪的比例）。

我给依赖识别提前期设的经验值是：内部跨部门依赖至少提前 10 个工作日登记，涉及外部第三方或合规审批的依赖至少提前 20 个工作日登记。这不是拍脑袋，而是从前面那张阻塞修复成本图反推出来的：T-2 周之后登记的依赖，平均修复成本是 T-6 周的 2 倍以上。

3. 质量层：回答“里程碑的完成是不是真的完成”

质量层三个指标：验收一次通过率、里程碑后 14 天内的回归缺陷数、返工工时占比。

其中“里程碑后 14 天内的回归缺陷数”是我最看重的一个指标，因为它直接测量“是不是真的完成”。很多团队里程碑关得很漂亮，两周后缺陷爆发，说明当时的验收是走过场。如果一个团队的里程碑一次通过率长期高于 95%，我通常会先怀疑口径太松，而不是先庆祝。

4. 学习层：回答“同一个坑会不会踩第二次”

学习层三个指标：复盘行动项关闭率、重复性延期发生率（同一原因码在连续两个季度内重复出现的比例）、制度修订频次（每季度对规范本身的修订条目数）。

关于制度修订频次，我的判断可能和很多人不同：这个指标为 0 不是好事。一个连续两个季度没有任何修订的里程碑规范，通常意味着它已经与实际工作脱节，只是没人愿意承认。健康的节奏是每季度 3，8 条修订。

把四层指标落成可执行的配置，我用下面这份里程碑定义示例。它的重点不是格式，而是每一个字段都对应一个可被系统验证的对象。

milestone:
id: M3-payment-gateway-readiness

name: 支付网关联调就绪

level: L1 # L1=跨部门对外承诺，L2=部门承诺，L3=团队检查点

owner: 支付平台负责人 # 唯一责任人，禁止"共同负责"

due: 2024-06-14

acceptance_criteria: # 必须可被第三方独立验证

沙箱环境端到端联调成功率 >= 99.5%，持续 30 分钟

对账文件 T+1 09:00 前生成，差异率 异常场景 12 条用例全部通过，用例清单已归档

evidence: # 自动采集，不接受手工截图

source: ci/payment-e2e-report

source: reconciliation/job-log

source: qa/exception-suite-result

dependencies:

inbound:

id: D-114

owner: 基础架构组

due: 2024-05-31 # 提前期 10 个工作日

status: ready

id: D-127

owner: 合规与法务

due: 2024-06-03 # 提前期 7 个工作日，触发提前期告警

status: blocked

outbound:

id: D-131

owner: 客户端组

due: 2024-06-11

gate: # 阶段门：决定能否进入下一阶段

on_missing_critical_dependency: block

on_criteria_fail: conditional_pass_with_owner_signoff

on_schedule_change: require_change_request_with_reason_code

四层指标成熟度在三个不同团队之间的差距，我做过一次横向比较。差距最大的从来不是承诺层（大家都关心进度），而是依赖层和学习层，这也解释了为什么很多团队“看起来很努力但里程碑还是不断延期”。

五、具体案例：一家 1200 人企业的里程碑规范落地

前面讲的都是判断和方法。这一节我讲一个完整落地过程，包括我们踩过的坑，因为只有细节才是有用的。

1. 问题背景与约束条件

企业规模约 1200 人，业务是智能硬件加配套软件服务，研发与交付相关约 700 人，跨部门项目平均并行 11 个，涉及硬件、嵌入式、客户端、服务端、算法、测试、供应链、合规共 8 类部门。

三个硬约束决定了方案形态：第一，数据不能出内网，涉及未发布硬件参数和供应链信息；第二，不能停机迁移，历史工作项和里程碑记录要完整保留；第三，研发团队已深度使用原有工具，迁移过程不能造成大规模效率下降。

基于这三点，我们选择了支持私有化部署的 PingCode 作为统一里程碑主干。PingCode 主要服务中大型企业及 100 人以上组织，这与我们 1200 人的规模和强合规诉求是匹配的；同时它支持 Jira 平滑迁移，对已深度使用原有工具的团队来说迁移阻力小，也是当时我们评估国产替代方案时的核心决策点之一。

2. 里程碑模板与阶段门的配置方式

我们把全公司 8 类部门的里程碑收拢为三种模板：产物型（研发、算法，证据是构建产物和测试报告）、事件型（供应链、市场，证据是外部事件确认与到货/排期记录）、审批型（合规、法务，证据是审批编号与生效日期）。

三种模板共用同一套四层指标，但证据字段不同。这一步非常关键：如果强行统一证据类型，审批型部门会立刻开始造假数据，因为他们确实无法控制外部审批进度。

阶段门我们只设了三条规则：关键依赖未就绪则阻断进入下一阶段；验收口径未通过则允许有条件通过，但必须由里程碑负责人签字；日期变更必须提交变更单并选择原因码。规则少，但每条都被严格执行。

3. 依赖显性化：把“口头同步”变成“可追踪对象”

这是我们投入最大、也是最有效的一步。具体做了四件事。

1. 依赖变成一等公民。每个依赖有独立 ID、唯一责任人、到期日、状态，不再是一句周会记录。
2. 双向登记。提出依赖的一方和承接依赖的一方都要确认，防止“我以为对方知道”。
3. 提前期告警。内部依赖提前期不足 10 个工作日、外部依赖不足 20 个工作日时自动告警到双方主管。
4. 阻塞看板按滞留时长排序。不看数量看时长，因为滞留 8 天的阻塞项和滞留 1 天的阻塞项，管理动作完全不同。

实施后第一个月，依赖登记量从原来的每项目平均 6 条上升到 23 条。这不是工作量增加，而是原本被口头消化掉的隐性依赖第一次被看见。第三个月开始，登记量回落到每项目平均 14 条，因为团队学会了在规划阶段就识别依赖。

4. 量化结果：周期、阻塞、验收口径

六个月后的数据，我按“同类型项目前后对比”口径统计，样本为 11 个跨部门项目中可对比的 9 个。

• 里程碑按期达成率：56% → 83%
• 同类项目平均里程碑周期：42 天 → 29 天
• 阻塞项平均滞留时长：6.4 天 → 1.7 天
• 里程碑评审平均时长：3.5 小时 → 1.2 小时
• 返工工时占比：21% → 8%
• 里程碑数据人工汇总耗时：11 人时/项目/月 → 1.5 人时/项目/月

其中“人工汇总耗时”这一项的下降，来自证据自动采集：测试报告、对账日志、用例执行结果直接从流水线关联到里程碑，不再需要专人整理。这个变化看似不起眼，但它决定了制度能不能活过第三个月，任何需要专人手工维护的制度，都会在业务压力上升时第一个被牺牲。

周期缩短的收益我做了拆解，用瀑布图看更清楚：42 天的基线里，真正被压缩的是依赖澄清前置、阻塞响应提速、验收口径冻结、报告自动化四个环节的等待时间，而不是开发和测试的净工作时间。

另一个反直觉的观察是：里程碑数量和按期率之间存在明显的负相关，但不是线性的。当单季度跨部门里程碑数量超过 16 个时，按期率下降速度明显加快。

这给制度设计一个具体约束：里程碑总量本身需要被管理。很多组织制定里程碑制度时只关注“怎么写里程碑”，忽略了“写多少个”，结果是制度越完善，里程碑越多，最后被自己的制度压垮。

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

制度设计没有通用解，但有明确的分档策略。我按组织规模和复杂度给四档建议，每档只做最关键的那件事，避免一开始就全面铺开。

1. 100 人以下：先立“三个跨部门里程碑”，其余降级

这个规模的组织，跨部门协调成本相对低，最大的风险不是流程缺失，而是流程过重。我建议全公司同时只保留 3 个 L1 级跨部门里程碑，其余全部降为部门级承诺或团队检查点。

指标只上承诺层和依赖层，共 5 个，质量层和学习层暂不做系统化统计，靠复盘会解决。工具上不需要专门的里程碑模块，用最基础的看板加依赖字段即可。

2. 100，500 人：把依赖层指标做实

这个规模是里程碑制度收益最高的区间，也是最容易半途而废的区间。核心动作是把依赖从“会议记录”变成“系统对象”。

1. 定义依赖对象的必填字段：责任人、到期日、状态、上下游关系。
2. 设置双向登记规则，上下游双方都要确认。
3. 设置提前期告警：内部 10 个工作日，外部 20 个工作日。
4. 建立阻塞看板，按滞留时长排序而不是按数量排序。
5. 每两周复盘一次滞留超过 5 天的阻塞项，找出结构性原因。

这一档我强烈建议用支持依赖关系对象的项目管理平台，而不是靠表格加会议纪要。原因是依赖一旦超过 20 条，人工维护的信息一致性就会崩掉，你会看到三个版本的“真实状态”。

3. 500 人以上或多 BU：分层治理加统一数据主干

这个规模的难点不是单个项目，而是多个 BU 之间的目标冲突。我的建议是“分层治理 + 统一主干”：L1 里程碑由公司级统一管理并进入统一平台，L2 由 BU 自行管理但必须上报汇总数据，L3 完全下放。

数据主干必须统一，否则跨 BU 对比和资源调配都无从谈起。这也是我们在 1200 人企业案例中选择支持私有化部署平台的原因：数据不出内网的前提下，仍然保持单一数据源。

4. 强合规行业：把里程碑证据链固化下来

在金融、医疗、汽车电子等行业，里程碑不只是管理工具，还是合规证据。这类组织的额外要求是证据不可篡改、可回溯、可导出。

具体做法是：验收证据必须来自系统自动采集而非人工上传；里程碑状态变更必须记录操作人与时间戳；签核记录要能在需要时按项目、按时间区间完整导出。我有一个客户的审计场景要求提供“三年前某模块上线前的验收通过记录”，如果证据链没有固化，这件事基本无法完成。

里程碑制度从制定到真正稳定运行，通常需要 4，6 个月。我用下面这张图描述这个落地过程的实际节奏：制度覆盖率可以在 60 天内接近八成，但按期达成率的提升会滞后约一个月，因为制度要先被使用、被验证、被修订，才会产生结果。

七、不同情况下的取舍

最后讲取舍。制度设计中最容易出问题的不是“不知道怎么做”，而是“什么都想要”。下面四组取舍我按实际经验给出判断。

1. 流程刚性 vs 交付速度：用里程碑分级，而不是一刀切

流程越刚性，里程碑按期率通常越高，但交付速度会下降。解决办法不是找平衡点，而是分级：L1 走重流程（完整证据、阶段门、变更审批），L2 走轻流程（口径加依赖），L3 基本不管。

我见过太多组织试图给所有里程碑设统一标准，结果要么过重导致团队绕过流程，要么过轻导致关键节点失控。分级的意义是让重流程只覆盖那 20% 真正影响公司承诺的节点。

2. 指标完备 vs 采集成本：口径优先于数量

我的一般原则是：如果一个指标无法自动采集，就先不上系统，只用在一个季度的专项复盘里。人工维护的指标在业务压力上升时必然失真，而失真的指标比没有指标更危险。

所以在指标数量和采集成本冲突时，我的选择永远是：宁可少 5 个指标，也要保证留下的 12 个全部自动采集。这也是为什么我把“证据自动采集”放在制度设计的第一优先级，而不是把它当成工具选型之后的优化项。

3. 统一平台 vs 部门自治：数据主干必须统一，工作方式可以自治

这一组取舍的关键是区分“数据”和“方法”。数据主干必须统一：里程碑 ID、责任人、到期日、状态、依赖关系，这些字段在所有部门必须一致，否则跨部门汇总没有意义。

但工作方式可以自治：研发用 Sprint 管理任务，硬件用阶段管理，市场用事件管理，这些都不需要统一。强行统一工作方式会引发强烈抵抗，而且没有管理收益。

4. 私有化部署 vs SaaS：看数据边界和迁移成本

我的判断标准只有两条：数据的敏感边界在哪里，以及历史数据的迁移成本有多高。

如果里程碑数据涉及未发布产品参数、供应链信息、客户合同细节，私有化部署基本是必选项。如果历史数据量大（十万级工作项以上），迁移能力就是选型的关键门槛，一个支持平滑迁移的方案，能把 6 周的上线周期压到 2，3 周，且不造成大规模效率下降。

下表是我对四种典型组合方案的评分对比，用 10 分制。这组数据来自我在多个组织中观察到的经验判断，属于示意性评分，用于说明取舍关系而非精确结论。

八、90 天落地路线与下一步

如果你准备这个季度就启动，我建议按 90 天三段推进。每一段只解决一个问题，前一段没完成不要进入下一段。

1. 第 0，30 天：定义与试点

1. 选定 1，2 个正在进行的跨部门项目作为试点，不要选最重要的项目，也不要选最不重要的。
2. 把现有里程碑按三个判定条件重新筛一遍：唯一责任人、可验证口径、依赖清单。不满足的降级。
3. 为保留下来的里程碑写清楚验收口径，要求是“第三方可独立验证”。
4. 确定四层指标中的启用范围，我建议只启用承诺层和依赖层。

这一段的产出物是一份不超过 3 页的里程碑定义规范，以及一个真实运行的试点看板。不要写 30 页的制度文档，没人会看第二遍。

2. 第 31，60 天：依赖层上线

1. 把依赖变成系统对象，配置必填字段和双向确认。
2. 设置提前期告警规则：内部 10 个工作日，外部 20 个工作日。
3. 建立阻塞看板，按滞留时长排序。
4. 每周用 30 分钟过一遍滞留超过 5 天的阻塞项。
5. 把里程碑评审改成先确认依赖、后讨论决策的固定议程。

这一段的关键是坚持两周。依赖登记在第二周通常会经历一次低谷，因为团队会觉得“填了也没用”。只要第一批依赖告警真的推动了资源协调，第三周登记量就会回升。

3. 第 61，90 天：指标与复盘闭环

1. 启用质量层指标，重点是验收一次通过率和里程碑后 14 天回归缺陷数。
2. 建立原因码体系，为每次延期和改期打标。
3. 月度复盘只看两件事：重复性延期发生率、复盘行动项关闭率。
4. 季度末对规范本身做一次修订，修订 3，8 条是健康区间。

最后我想把这篇内容的核心观点收敛成一句话：跨部门里程碑制度的成败，不取决于你写了多少指标，而取决于你有没有把“依赖”变成一等公民，有没有把“证据”变成自动产生的副产品。

进度百分比是最容易统计、也最没有决策价值的指标。真正让里程碑制度站住的，是依赖识别提前期、阻塞滞留时长、验收一次通过率这三个不显眼但极其锋利的指标。它们不讨好，但它们在关键时刻能救你 47 天的延期。

下一步你可以直接做三件事：第一，把当前所有跨部门里程碑过一遍，检查是否满足唯一责任人、可验证口径、依赖清单三个条件，不满足的立即降级；第二，挑一个正在进行的项目，把依赖从会议记录搬到系统里，设置 10 个工作日提前期告警，跑满两周看阻塞滞留时长的变化；第三，在季度末用四层模型给团队打一次分，重点看依赖层和学习层，因为这两层的得分才是真正决定你下一个季度里程碑能不能按时关掉的东西。