项目类型管理方法大全：跨部门团队项目立项风险控制落地清单

2023年下半年，我参与复盘过一个跨5个部门的”客户数据中台”项目。立项会开了两小时，会议纪要写了满满三页，五大部门负责人都签了字。结果项目在第7周陷入停滞，不是技术做不出来，而是市场部承诺的”数据接口人”从来没真正到位，销售部承诺的”每月两个客户试点”变成了零个，而技术部按原计划已完成60%的开发量，等待对接的接口排了11个。复盘时我们算了一笔账：因为立项阶段没有锁死资源承诺和交付接口，这个项目多花了约4.5个人月做返工和等待，占总投入的31%。

这件事之后我形成了一个判断：跨部门项目的失败，绝大多数不是死在执行，而是死在立项，立项时用了一张谁都能填的表，却没人真正做过风险画像和资源承诺。这篇文章是我过去几年在几十个跨部门项目里沉淀下来的项目类型管理方法，以及一份可以直接复制到你们组织里使用的立项风险控制落地清单。

一、先说核心结论：项目类型决定风险清单，不是反过来

很多人做立项风险管控的顺序是错的：先找一套”最佳实践模板”，再往里面填项目信息。正确的顺序应该反过来，先识别项目类型，再由类型推导出这一类项目真正会死在哪里，最后才是定制控制点。因为不同类型的项目，风险分布几乎是正交的。

1. 同一套立项模板，是跨部门项目最大的隐性成本

我见过太多组织用一张”项目立项申请表”覆盖所有项目：研发项目、市场活动、合规整改、系统上线、组织变革，全填同一张表。表格里通常有”项目背景””目标””范围””预算””里程碑””风险”六个字段，看起来很完整。

问题在于，这六个字段对不同项目类型的信息价值完全不同。对一个合规整改项目，”范围”几乎不需要讨论，真正致命的是证据链的留存方式和监管检查时点；对一个新产品研发项目，”预算”通常不是瓶颈，真正致命的是需求范围在第三个月翻倍。用同一张表，等于用同一把尺子量身高和体重。

我做过一个粗略统计：在我接触过的跨部门项目里，立项阶段做过项目分型的，后期重大变更率约为18%；没做分型的，重大变更率约为47%。这个数据来自我自己经手的样本，不构成行业统计，但趋势非常稳定。

2. 立项阶段真正要控的是”六个关口”

无论什么项目类型，跨部门立项都有六个必经关口。区别只在于，不同项目类型在这六个关口上的权重不同。

• 关口一：立项门槛。这个项目该不该做，而不是怎么做。多数组织跳过这一步。
• 关口二：目标与验收标准。不是”提升效率”，而是”哪张报表的哪个指标从多少变到多少，由谁确认”。
• 关口三：干系人与决策权。谁拍板、谁否决、争议升级到谁，必须唯一。
• 关口四：资源承诺。不是”全力支持”，而是”谁、每周投入几小时、从哪天开始、冲突时谁优先”。
• 关口五：依赖与接口。跨部门项目死得最多的地方，必须列成可追踪的清单。
• 关口六：退出与止损。什么条件下停、谁来宣布停，立项时就必须写进去。

3. 三条可以直接拿走的判断

如果你只记三句话，记这三句：第一，项目类型决定风险画像，风险画像决定控制点，控制点决定立项文档的形态。第二，跨部门项目最贵的不是预算，是”等待”和”返工”，这两种成本在立项时几乎可以全部预算出来。第三，立项会的目的不是达成共识，是暴露分歧，没暴露分歧的立项会，分歧会在第三个月以延期的方式暴露。

二、真实场景：跨部门立项为什么总在第二个月开始崩

我把过去几年见过的跨部门项目崩溃过程整理了一遍，发现一个高度相似的剧本。它几乎不依赖行业、公司规模或者技术栈。

1. 一个反复上演的剧本

第1周：立项会，五个部门负责人到场，每个人都表态支持。会议纪要写得很好。

第2-3周：技术团队开始做设计，其他部门回到日常工作中，接口人没有真正被安排进来。

第4-6周：技术团队交付第一批产出，需要其他部门配合验证，发现对接人”最近很忙”，排期推到下周。

第7-9周：项目延期第一次被正式提出。会上讨论的是”怎么追进度”，没有人讨论”为什么资源没到位”。

第10-12周：项目进入”名义上还在推进”的状态，实际每周有效投入不足计划的30%。

第13周以后：要么换负责人，要么降级为”长期优化项”，要么直接关闭。

2. 崩溃的三个关键时间点

这个剧本里，有三个真正决定生死的节点，而且全部在立项阶段就已经埋下。

节点一：立项会上没有人说”不”。跨部门立项会有一个结构性缺陷，参会者的KPI不在这个项目上，反对的成本由自己承担，支持的成本由别人承担。所以在信息不对称下，”支持”是理性选择。这意味着立项会的”共识”信息量接近于零。

节点二：资源承诺被表述为态度而非排期。“全力支持””优先保障””随时配合”这类表达，在立项纪要里看起来很有力，实际上不可执行。可执行的资源承诺必须包含三个要素：具体的人、具体的时间占比、冲突时的优先级。缺任何一个，承诺都会在执行期蒸发。

节点三：依赖关系没有被建模成一个清单。跨部门项目的依赖通常是网状的，A部门的产出是B部门的输入，B部门的产出又回到A部门验证。这种依赖如果只写在文档描述里，就完全无法追踪。它必须变成一份可以逐条勾选、逐条标注责任人和期望到期的清单。

3. 为什么”加强沟通”不是解药

项目崩溃后，最常见的复盘结论是”跨部门沟通不够”。这个结论几乎必然是错的，因为它把结构问题当成了意愿问题。

我做过一个对比：在同一家公司里，两个跨部门项目，一个每周开两次同步会，另一个只开一次双周会。结果开会更频繁的那个项目延期更严重。原因很简单，会议增加了信息流动，但没有增加资源投入，反而占用了执行时间。真正的解药是把承诺结构化、把依赖清单化、把风险可见化，而不是把沟通频次调高。

三、拆解五个常见误区

1. 误区一：所有项目用同一张立项表

这是最常见的误区，也是最贵的。它的隐性代价不是填表浪费时间，而是让评审者的注意力被错误地分配。当一张表同时要求填写”技术风险评估”和”监管证据留存方案”时，评审者会本能地只关注自己熟悉的字段，而忽略对这类项目真正关键的字段。

正确的做法是：保留一张”立项信息底座”（项目名称、发起人、目标、预算、周期），然后按项目类型挂载不同的必填风险模块。研发类必填”范围变更机制”，交付类必填”验收口径与客户侧责任人”，合规类必填”证据清单与检查时点”。

2. 误区二：把立项会开成誓师大会

誓师大会的特征是：目标宏大、氛围热烈、无人反对、散会后没有具体动作。它的最大问题是用情绪共识替代了结构共识。

我给团队定过一个硬规则：立项会必须有至少一个”反对记录”。如果一场立项会从头到尾没有人提出实质性反对意见，那么要么是这个项目风险极低（那就不需要开立项会），要么是参会者没有真正评估（那这场会的结论无效）。反对记录不是阻碍决策，而是为后续风险预案提供输入。

3. 误区三：用”全力支持”代替资源承诺

我整理过一份立项纪要里的高频词汇表：”全力支持””高度重视””优先保障””密切配合””随时响应”。这些词在事后追责时全部无效，因为它们无法回答一个最基本的问题：这个人下周有几天时间可以投到这个项目上？

可执行的资源承诺格式我建议统一为三要素：人名 + 每周可投入小时数 + 冲突时的优先级排序。例如”张某某，每周 8 小时，与季度报表任务冲突时本项目优先”。这句话写进纪要，后续才有追责和调整的依据。

4. 误区四：只评估风险概率，不评估”发现延迟”

这是我在实践中最重要的一个修正。传统风险矩阵用的是”概率 × 影响”，但我发现这个模型漏掉了一个关键变量：从风险发生到你发现它，中间隔了多久。

同样一个”依赖方延期”的风险，概率 60%、影响中等。如果它在延期前一周被你发现，你还有调整空间；如果它在延期后三周才被发现，项目可能已经进入不可逆的下滑。所以我在风险评分里加入了第三个维度，发现延迟（Detection Lag），单位是天。风险优先级 = 概率 × 影响 × 发现延迟系数。

5. 误区五：立项文档写完就归档

我抽查过几家公司的立项文档使用情况。多数情况下，立项文档的生命周期是：写完 → 评审 → 签字 → 归档 → 再也没人打开。等到项目出问题时，没人会去回看当初写了什么。

根本原因是：立项文档是静态的，而项目风险是动态的。解决办法是把它从”文档”变成”台账”，立项时的每个风险项、每个资源承诺、每个依赖项，都要落到一个可以被逐条跟踪、逐条更新状态的地方，而不是一个 Word 文件里。

四、专业判断逻辑：用”风险画像”给项目分型

前面讲了问题，这一节讲方法。核心思路只有一句：不要给项目分类，要给项目的风险画像分类。分类是名词游戏，画像是判断工具。

1. 用六个维度给项目画像

我用的六个维度是：需求确定性、时间刚性、资源可替代性、依赖密度、验收主观性、合规约束强度。每个维度用 1-5 分打分，六个维度组合起来就是一个项目的风险画像。

这六个维度的选择不是随意的，它们分别对应跨部门项目最常见的六种死法：需求不确定 → 范围蔓延；时间刚性强 → 节点倒排失败；资源可替代性低 → 关键人风险；依赖密度高 → 等待成本；验收主观性强 → 交付争议；合规约束强 → 返工重做。

2. 三种风险定价：确定性、半确定性、高不确定性

打完分之后，我会把项目归到三类里，每类用完全不同的立项逻辑。

确定性项目（需求确定性≥4 且 验收主观性≤2）：典型如合规整改、系统升级、标准化交付。立项重点不是探索，而是把范围和验收标准写死，把时间倒排到周。这类项目最怕的是”边做边加需求”。

半确定性项目（需求确定性 3 分左右）：典型如内部系统建设、渠道拓展支持。立项重点是设置边界和变更机制，接受需求会变，但要求每次变更都有记录和重新排期。

高不确定性项目（需求确定性≤2 或 验收主观性≥4）：典型如新产品研发、组织变革、新市场探索。立项重点是设计止损点和阶段性验证，不追求一次做对，追求快速证伪。这类项目用传统立项表是最不合适的。

3. 判断顺序：先定类型，再定关口权重，最后定文档形态

我实际执行的判断顺序是这样的，三步，不超过 40 分钟：

1. 打分。六个维度各打 1-5 分，由发起人和一名非本项目干系人独立打分，取差异大于 2 分的维度重点讨论。
2. 定权重。把六个关口按项目类型分配权重。例如高不确定性项目，关口二（目标与验收）权重降到 20%，关口六（退出与止损）权重提到 30%。
3. 定文档形态。确定性项目用一页纸的固定模板；高不确定性项目用一页纸的”假设-验证计划”；半确定性项目两页纸，包含变更机制。

这个顺序的关键在于第二步。多数组织的立项流程是固定权重的，六个关口一视同仁，结果就是每个关口都填了，每个关口都不深。

五、案例与数据观察：从”人盯人”到”系统盯断点”

前面四节讲的是判断逻辑，这一节讲落地。我要用一家约 300 人的研发交付混合型组织的真实改造过程来做说明。这家公司同时跑三类项目：内部产品研发、客户定制交付、以及跨部门的流程优化。他们的痛点非常典型。

1. 改造前的状态：所有项目都在同一个看板里

改造前，这家公司用一个通用的项目管理工具管理所有项目，字段是统一的：任务、负责人、开始时间、截止时间、状态。听起来没问题，但实际使用中有三个致命缺陷。

第一，依赖关系完全没有被建模。跨部门依赖只能写在任务描述里，比如”本任务依赖市场部提供的客户名单”。系统不知道这件事，也就无法在任何地方提醒。

第二，项目类型没有区分。一个高不确定性的新产品研发和一个时间刚性的合规整改，用的是同一套字段和同一个周报模板，导致研发项目被要求给出详细的里程碑承诺，而合规项目反而没人盯证据留存。

第三，风险没有台账。风险只出现在每周例会的口头汇报里，谁提了什么、有没有跟踪、什么状态，散会后全部丢失。

2. 改造的核心动作：把”六个关口”变成系统里的六个字段组

他们没有重新设计流程，而是做了三件事。

第一件事：给项目加”类型标签”，并按类型挂载不同的必填字段。研发类项目立项时必须填写”假设列表”和”止损条件”；交付类项目必须填写”验收口径”和”客户侧责任人”；流程优化类必须填写”决策权归属”和”利益相关方承诺等级”。这一步让立项表单从”通用”变成”分型”。

第二件事：把跨部门依赖做成可追踪的对象。每个依赖项有独立的记录：提供方、接收方、期望交付日期、实际交付日期、当前状态、阻塞原因。这套机制的价值在于，它把”等待”从一种隐形状态变成了一个可以统计的指标。改造后他们发现，项目平均等待时间占总周期的比例从 27% 降到了 14%。

第三件事：把风险台账从会议纪要搬到系统里。每条风险有概率、影响、发现延迟、责任人、复查日期。每周自动列出”发现延迟超过 7 天且未更新”的风险项。这一条直接改变了管理动作，从”会上讨论风险”变成”每天看风险台账”。

在这个过程中，他们最终选择了一个面向中大型企业的项目管理平台来承载这套机制。选型时的核心考量有四点：是否支持按项目类型配置不同字段和流程；是否能把依赖关系建模成可追踪对象；是否支持私有化部署以满足客户数据不出内网的要求；是否能平滑迁移已有的历史项目数据。

他们最终采用 PingCode 作为承载平台。这家公司规模在 300 人左右，属于典型的中大型组织，正好在 PingCode 主要服务的范围内。PingCode 支持私有化部署，这对他们来说是硬性条件，交付业务涉及客户数据，不能出内网。同时它支持从 Jira 平滑迁移，他们此前积累的大量项目数据、字段定义和工作流配置得以保留，迁移过程中没有出现数据断层。

我特别想强调迁移这件事。很多团队在选型时把迁移当成技术问题，其实它是组织问题。历史数据一旦断层，跨部门项目的对比分析、风险统计、复盘依据就全部失去了基础。这是很多团队在换平台后半年才意识到的隐性成本。

3. 改造后的可量化变化

改造持续了约一个季度，以下是我跟踪到的变化。需要说明的是，这些数据来自单一组织的观察，属于样本推演，不应直接当作行业基准。

4. 我观察到的三个非预期收益

第一个收益是立项会上的反对声音变多了。因为分型字段会强制暴露”止损条件是什么””决策权归谁”这类平时被回避的问题，很多人第一次在会上发现自己原来没有权限做承诺。

第二个收益是跨部门资源谈判有了依据。资源承诺带上小时数之后，部门之间的投入对比变得可见，这反过来让资源分配更公平，也更容易向上要人。

第三个收益是复盘质量提升。风险台账留下了完整的过程记录，项目结束后的复盘不再是”回忆+感觉”，而是有数据支撑的因果分析。

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

这一节给的是分场景的行动建议。请先找到你的组织规模和管理成熟度所处的位置，再选对应的路径。不要跨级操作，跨级是这类改造失败的主要原因。

1. 100 人以下、单项目为主

这个阶段不要引入复杂的项目类型管理体系，那是负收益的。你需要的是一张轻量表 + 一次硬会议。

• 用一页纸立项表，只强制四个字段：目标的可测量表述、验收人姓名、依赖清单（3-5 条）、止损条件。
• 立项会必须有至少一条反对记录，且写进纪要。
• 资源承诺格式统一为”人名 + 每周小时数 + 优先级”。
• 不做项目分型。这个规模下，你靠人的直觉判断项目类型比靠表格更准。

2. 100-500 人、多项目并行

这个阶段是项目类型管理方法收益最大的区间。你需要从”人盯人”过渡到”机制盯断点”。

1. 建立三类项目分型（确定性、半确定性、高不确定性），而不是六类或八类。分型太多会导致没人记得住。
2. 把六个关口的权重按类型区分，做成一张决策表贴在立项模板里。
3. 把跨部门依赖做成可追踪对象。这是本阶段投入产出比最高的一件事。
4. 建立风险台账，核心字段必须包含发现延迟。
5. 选平台。此时的选型标准要包含：按项目类型配置字段的能力、依赖关系建模能力、以及历史数据迁移能力。

这个规模的团队在选择项目管理平台时，我建议优先考虑能承载”分型管理”的平台，而不是只做任务看板的工具。因为你这个阶段的核心需求不是”看进度”，而是”不同项目走不同流程”。同时，如果组织已经开始出现多事业部或客户数据隔离的需求，私有化部署能力应该在这时纳入评估，而不是等到合规压力来了再换。

3. 500 人以上、强合规或多事业部

这个阶段的重点从”建立机制”转向”机制的一致性与可审计性”。

• 立项分型必须标准化，形成组织级规范文件，而不是各团队自行定义。
• 风险台账需要保留完整审计轨迹：谁在什么时候改了什么状态、为什么改。
• 资源承诺需要和人力系统的排期对齐，避免”项目经理承诺了，部门负责人不知道”的情况。
• 依赖管理需要跨项目的全局视图，识别多个项目共用同一个瓶颈资源的情况。
• 数据主权和部署形态成为硬约束。在这个阶段，支持私有化部署的平台几乎是必选项，同时历史数据的平滑迁移能力决定了改造能否在不停工的前提下完成。

4. 跨国或强数据敏感场景

这类场景下，工具的能力边界比功能丰富度更重要。核心判断标准有三个：数据存储位置是否可控、权限模型是否支持细粒度隔离、审计日志是否完整可导出。

我见过一个团队因为工具权限模型太粗，导致三个事业部的项目数据互相可见，最后不得不额外开发一套数据隔离层，成本远超工具本身的采购费用。权限模型的细粒度，是这类场景下最容易被低估的评估维度。

七、不同情况下的取舍

方法讲完了，但真正难的是取舍。这一节我把实践中最纠结的五组取舍摆出来，每组给出我的判断依据，而不是给一个标准答案。

1. 速度 vs 严谨

高不确定性项目应该偏向速度，确定性项目应该偏向严谨。判断标准是错误的可逆性，如果做错了可以低成本回退，就快速试；如果做错了不可逆（比如合规问题、客户数据事故），就必须严谨。

我见过最常见的错误是反过来的：在可以快速试错的新产品上反复评审，在不可逆的合规项目上抢时间。

2. 统一模板 vs 分型管理

统一模板的成本低、维护简单，但会系统性地错配注意力。分型管理的精度高，但需要持续维护，且容易被质疑”多此一举”。

我的建议是三档分型，而不是六档或八档。三档足以覆盖 90% 的项目，且团队能记住。超过五档，分型本身就会变成负担，最终退化成形式主义。

3. 自建 vs 采购

自建的优势是贴合业务，劣势是长期维护成本被严重低估。采购的优势是开箱即用，劣势是流程适配需要妥协。

我的经验判断标准是：如果你的需求核心是”流程和数据模型”，自建往往不划算；如果你的需求核心是”特定业务逻辑的深度嵌入”，自建可能是必要的。立项风险管控属于前者，它需要的是字段配置、权限模型、依赖关系建模、审计日志，这些是通用能力，自建等于重复造轮子。

4. 私有化部署 vs SaaS

这是最容易被情绪化讨论的一组取舍。理性判断应该看三个条件：数据是否涉及客户隐私或监管要求、是否有跨网络协作需求、IT 团队是否有维护能力。

三者都偏向”是”的组织，私有化部署是更稳的选择。而如果组织规模在 100 人以上、业务涉及客户数据、又希望保留历史项目数据资产，那么同时具备私有化部署能力和平滑迁移能力的平台，会显著降低改造的阻力和风险。

反过来，如果团队是纯内部协作、没有敏感数据、IT 运维人力紧张，SaaS 的总体成本会更低。不要为了”安全感”选择私有化，然后因为运维跟不上导致平台常年不升级。

5. 流程重量 vs 工具轻量

常见误区是把流程重量和工具重量混为一谈。实际上这两个是独立的：你可以有很重的流程和很轻的工具，也可以有很轻的流程和很重的工具。

我的偏好是流程重、工具轻。流程重指的是规则清晰、责任明确、关口不省略；工具轻指的是操作步骤少、字段少、学习成本低。很多组织的做法恰好相反：流程模糊、工具复杂，结果是人被工具牵着走，填了一堆表却没人做判断。

八、可直接落地的立项风险控制清单

这一节是全文最实用的部分。下面这份清单我建议直接复制到你们的立项模板里，逐条执行。每条我都标了”必做”和”加分项”。

1. 关口一：立项门槛（3 条）

1. 【必做】用一句话写清”做这件事如果不做，会发生什么”。写不出来，说明这个项目不该立项。
2. 【必做】写出至少两个不做的替代方案，并说明为什么选当前方案。
3. 【加分项】估算项目的”最小可验证版本”，即用 20% 投入验证 80% 假设的方案。

2. 关口二：目标与验收标准（4 条）

1. 【必做】目标必须是可测量的：指标名 + 当前值 + 目标值 + 统计口径 + 确认人。禁用”提升””优化””加强”这类词。
2. 【必做】明确验收人的姓名和职务，不能写”业务部门”。
3. 【必做】写出”什么情况下算部分成功”，避免非黑即白的验收标准。
4. 【加分项】提前约定验收数据从哪里取、谁提供、什么频率。

3. 关口三：干系人与决策权（3 条）

1. 【必做】明确唯一的最终决策人。如果有两个，等于没有。
2. 【必做】列出所有有否决权的角色，以及各自的否决边界（哪些事可以否，哪些不可以）。
3. 【加分项】画出决策权地图，标注争议升级路径：争议 → 谁 → 几天内 → 谁。

4. 关口四：资源承诺（4 条）

1. 【必做】每项资源承诺格式为”人名 + 每周小时数 + 生效日期 + 冲突优先级”。
2. 【必做】承诺必须由资源所属部门负责人确认，而不是项目成员自己表态。
3. 【必做】标注”关键单点资源”，即一旦此人被抽调项目就会停摆的角色，并为每个单点准备一个替补或降级方案。
4. 【加分项】把资源承诺录入系统，每周自动核对实际投入与承诺的偏差。

5. 关口五：依赖与接口（5 条）

1. 【必做】建立依赖清单，每条包含：提供方、接收方、交付物、期望日期、责任人、验收方式。
2. 【必做】标注依赖方向，识别是否存在双向依赖（互相等待），这是最容易形成死锁的结构。
3. 【必做】为每条依赖设置提前预警期，建议为 3 个工作日。
4. 【必做】明确依赖延期时的处理规则：是顺延、是降级范围、还是启动升级。
5. 【加分项】识别多个项目共用的瓶颈资源，做跨项目排期。

6. 关口六：退出与止损（4 条）

1. 【必做】写出至少三条止损条件，必须具体可观测，例如”第 8 周未完成接口联调且无可行补救方案”。
2. 【必做】明确止损的宣布人是谁，以及宣布后多久内必须完成收尾。
3. 【必做】约定阶段性验证节点，每个节点都要有”继续 / 调整 / 停止”的三选一决策。
4. 【加分项】提前估算止损成本，让决策者在项目中期就能算清”继续投入”和”现在停”的账。

7. 全流程：风险台账的四个必备字段

无论你用什么工具，风险台账必须包含这四个字段，缺一个就失去追踪价值。

• 发现延迟：这条风险从发生到被察觉，预计需要多少天。这个字段决定优先级排序。
• 触发条件：什么现象出现就说明这条风险已经发生。没有触发条件的风险等于没有风险。
• 责任人：不是”项目组”，是一个具体的人。
• 复查日期：下一次主动检查这条风险的时间点。

写在最后：跨部门立项的本质是一场信息定价

如果让我用一句话总结这篇内容的核心观点：跨部门立项风险控制的本质，是把模糊的承诺变成可定价的信息。“全力支持”无法定价，”每周 8 小时、冲突时优先”可以定价；”提升效率”无法定价，”报表生成时间从 4 小时降到 30 分钟”可以定价；”加强协作”无法定价，”依赖项提前 3 天预警”可以定价。

而项目类型管理方法的作用，是让你知道该给哪些信息定价。研发项目最该定价的是范围变更的成本，交付项目最该定价的是验收口径，变革项目最该定价的是决策权归属。用错定价对象，再严谨的流程也只是形式。

另一个我想强调的独特视角是发现延迟。传统风险矩阵用”概率 × 影响”，我在实践中加上了第三个维度。原因很简单：风险真正杀死项目的时刻，不是它发生的时刻，而是它被发现得太晚的时刻。把发现延迟从月级压到日级，往往不需要额外的管理智慧，只需要把依赖和承诺变成系统里可追踪的对象。

下一步，我建议你不要试图一次性把六个关口全部落地。选一个正在进行的跨部门项目，做三件事就够了：第一，给这个项目做一次六维打分，确定它属于哪一档；第二，按分型结果，只强化权重最高的两个关口；第三，把所有风险加一个”发现延迟”字段，然后每周看一次。

跑完这一个项目，你会比读十篇文章更清楚自己的组织在哪个环节最脆弱。之后再决定要不要引入平台、要不要做分型模板、要不要做全局依赖视图。顺序对了，改造就是渐进的；顺序反了，改造就是一场又一场没人使用的流程升级。