立项审批最佳实践：项目经理项目立项协同管理，常见问题

去年我参与梳理一家 1400 人规模软件企业研发中心的立项数据，他们统计了 87 个立项单：从提交到最终批准平均耗时 23 个工作日，而项目经理真正花在价值测算、资源谈判、风险识别上的时间不到 4 天，剩下 19 天都在等会签、补材料、约评审会。更麻烦的是，这 87 个项目里有 31 个在开工 60 天内发生了重大范围变更，因为审批环节几乎没有人追问过一句：验收标准到底是什么、谁签字承诺了人手。

这件事让我意识到，立项审批最容易被当成一道”合规闸门”，但它真正的价值其实是一次跨部门承诺的签订仪式。签完字之后，钱、人、时间、验收口径是否真的对齐，才决定这个项目后面是顺水推舟还是三步一坎。

下面这套内容，是我在 200 人到 3000 人规模不等的十几个研发组织里反复验证、也反复踩坑之后沉淀下来的判断。它有结论、有误区、有数据观察，也有一份可以直接拿去改流程的清单。

一、核心结论：立项审批的产出不是”批准”，而是”可执行的承诺集合”

先把结论放前面。绝大多数组织优化立项审批时，第一反应是”砍节点、缩流程、提效率”。这个方向只对了一半。审批快不等于立项好，如果快出来的结果是开工后疯狂返工，那省下的时间只是在后面加倍还回去。

1. 立项审批真正该考核的指标是”开工后 30 天的重大变更率”

我通常会建议客户在两个指标里选一个作为立项流程的北极星：一是立项审批周期，二是开工后 30 天的重大变更率。前者管速度，后者管质量。只盯前者，流程会退化成盖章机器。

为什么是 30 天？因为一个项目在开工第一个月内出现的重大变更，八成以上不是因为外部环境变了，而是因为立项阶段该问的问题没问。范围边界模糊、验收标准缺失、关键资源只是”口头支持”，这三类问题都会在开工后第 15 到 30 天集中爆发。

2. 审批链条越长，责任反而越稀释

这是我最想纠正的一个反常识判断。签字的人越多，愿意为结果负责的人越少。七个人会签的方案，出了问题时每个人的心理活动都是”我当时只是跟着签的”。

我见过的一个极端案例：某企业一个 400 万元的平台建设项目，走完了 11 个审批节点，包括 3 位副总。结果项目延期 5 个月，复盘时没有一个人认为自己是决策者。这就是典型的”责任分散型审批”。

3. 真正需要被审批的是五个要素，不是一份 40 页的文档

很多组织的立项材料写得极其厚重，可行性分析、市场调研、技术方案、风险矩阵一应俱全，但偏偏没有一页写清楚”这个项目做完，用什么客观标准证明它成功了”。

我的判断是：立项审批需要被确认的核心要素只有五个，价值假设、验收标准、资源承诺、止损线、责任人。其余内容都是支撑材料，支撑材料可以后置、可以按需补充，不必成为审批阻塞点。

4. 流程工具治不了决策缺失，但能把决策过程暴露出来

我从不认为换一个项目管理平台就能解决立项审批的所有问题。决策质量差、责任人不明确、资源承诺是假的，这些是管理问题，工具治不了。

但工具能做一件很关键的事：把”谁在什么时候、基于什么信息、做了什么判断”完整记录下来。当立项数据、审批记录、后续交付数据贯通之后，哪些审批环节是真正创造价值的、哪些只是形式主义，数据会自己说话。

二、背景与真实场景：立项审批到底卡在哪里

脱离场景谈流程设计，最后都会变成纸上谈兵。我把常见的立项来源归成三类，每一类的审批逻辑都不一样，这也是”一套流程走天下”必然失效的根源。

1. 场景一：战略派单型立项

老板或战略会已经定了方向，项目立项本质上是把战略意图翻译成可执行的计划。这类立项的审批重点不是”要不要做”，而是”用什么代价做、做到什么程度算完成”。

我见过太多这类项目在审批环节走形式，因为没人敢质疑战略。结果是资源被无限占用，边界不断扩张，最后变成一个人人都知道要延期、却没人敢叫停的项目。

2. 场景二：需求驱动型立项

业务部门提出需求，研发评估后立项。这类项目数量最多，也最容易失控，因为它的立项申请往往来自一个没有成本概念的岗位。

这类立项的审批重点在于价值量化与机会成本比较：这件事如果做，挤掉的是哪个项目的资源？如果不做，业务的实际损失是多少？没有这个比较，立项审批就只是在批准”我想做”，而不是”值得做”。

3. 场景三：技术预研型立项

方向不确定，需要小步验证。这类立项最忌讳用大项目的审批标准去卡，因为它本来就说不清楚最终交付物。

我的建议是给这类项目设置分阶段决策门：第一阶段只批人和时间盒（比如 3 人 6 周），阶段结束做一次轻量评审，验证通过才批第二阶段预算。这样既不阻塞探索，也不会让不确定性无限放大。

4. 一个典型的 23 天，到底花在哪里

我把那家 1400 人企业的立项单拆开分析过，23 个工作日大致是这样分布的：材料补正 5.5 天，跨部门会签排队 8 天，等评审会排期 4 天，正式评审会 0.5 天，法务与财务专项审核 3 天，最后归档与走系统 2 天。

真正在做判断的时间不到 1 天。也就是说，95% 的立项审批时间消耗在协调和等待上，而不是在决策上。这就是优化空间最集中的地方。

三、常见误区拆解：八个我反复见到的坑

下面这八个误区，我在不同规模、不同行业的组织里都见过，有的甚至同时存在三四个。它们单独看都不致命，叠加起来就会让立项审批彻底失效。

1. 误区一：把立项审批当成风险控制，实际做成了责任转移

很多立项流程的设计初衷是”多一道签字多一层保险”。但真实效果恰恰相反：审批节点越多，每个节点的审查深度越浅。因为大家都默认后面还有人看，自己只需要”表示同意”。

正确的做法是把审查责任收敛到少数几个真正具备判断能力的人手上，而不是摊薄到所有相关部门。

2. 误区二：所有项目共用一套审批流

一个 20 万元的小工具改造，和一个 800 万元的平台重建，走同样的 9 个节点，这本身就是资源浪费。分级授权不是特权，是效率设计。

我的经验值是按金额、跨部门数量、战略权重三个维度分档，通常 A 档全流程评审、B 档部门级评审加备案、C 档负责人审批即可。具体阈值各组织不同，但必须分级。

3. 误区三：审批要素写在制度里，没写进表单

这是最隐蔽的一个坑。制度文件里写得清清楚楚要评估 ROI、要明确验收标准，但实际提交的立项单上只有一个”项目描述”文本框。

结果就是：制度要求什么，取决于项目经理的自觉性。自觉性是不可靠的。要素必须变成表单上的必填字段，不填就走不下去。

4. 误区四：预算审批和资源审批分家

财务批了预算，不等于人手到账。我见过太多立项书上的”财务预算已批准”，到执行阶段发现根本没有对应的人力编制。

我的判断是：没有资源承诺的立项批准，本质上是一张空头支票。资源承诺必须具体到人、到工时、到占用周期，并且由资源归属方负责人明确签字。

5. 误区五：变更不回流，立项基线形同虚设

立项时定的范围和预算，执行三个月后变了三倍，但立项文档从来没更新过。这样一来，立项时的所有分析和承诺都失去了对照意义。

我建议设置一条硬规则：当范围、预算、关键里程碑中任意一项的变化超过约定阈值时，必须触发立项变更审批，并更新立项基线。没有这条规则，立项审批就是一次性的表演。

6. 误区六：百人以下组织抄大厂流程，百人以上组织靠聊天工具走流程

这是两种截然相反的错配。50 人的团队抄一套 9 节点的评审流程，结果是流程被架空、大家私底下口头沟通，系统里全是补录。

而已经超过 200 人的组织还在用聊天记录和邮件确认立项，导致审批历史无法追溯、责任人无法定位、数据无法沉淀。规模决定形式，这一点没有例外。

7. 误区七：审批通过率 100%，说明决策门已经失效

如果一个组织连续两年立项审批通过率都是 100%，这不是流程高效，而是决策门已经退化成形式。真正有效的决策机制一定会有明确的否决或退回案例。

健康区间大致是：直接通过 60% 到 75%，附条件通过 15% 到 25%，退回或否决 5% 到 15%。这个比例是我从多个组织统计中归纳的参考基准，不是绝对标准，但它能帮管理者快速判断决策门是否还活着。

8. 误区八：立项通过之后就没人管了

审批通过的那一刻，往往是从业者关注度最高、组织资源投入最密集的时候。但项目真正的成败，取决于后续几个月的执行。

如果立项数据和项目执行数据是两套系统、两张表，那立项阶段的分析结论就无法在过程中被验证和修正。立项与交付的割裂，是立项审批最大的长期浪费。

四、专业判断逻辑：我是怎么设计一条立项审批链的

前面讲了问题和误区，这一节讲方法。我不打算给你一套通用流程模板，而是给出判断逻辑，你可以据此推导出适合自己组织的方案。

1. 先定决策分层，再定流程节点

我把立项决策拆成三层，每层的提问和参与者都不同。混在一起讨论，是评审会开不完的根本原因。

第一层是价值决策：这件事值不值得做，由业务负责人和战略角色判断。第二层是可行性决策：技术上能不能做、合规上有没有障碍，由技术和法务角色判断。第三层是执行决策：怎么做、分几期、谁来做、什么节奏，由项目负责人和交付团队判断。

三层清楚之后，你会发现很多争议其实属于不同层级，本来就不该在同一场会上吵。

2. 按金额、跨部门范围、战略权重做三档授权

分级授权的核心不是省钱，而是把评审资源集中在真正重要的项目上。一个 15 人的部门内部工具改造，让全公司评审委员会花两小时讨论，这件事本身就不经济。

3. 审批要素清单：五个必须有，三个可以有

五个必须有：价值假设（怎么验证）、验收标准（客观可测）、资源承诺（人到工时）、止损线（什么情况下停）、责任人（单一拍板人）。

三个可以有：市场竞争分析、详细技术方案、完整风险矩阵。这三项在复杂项目中价值很高，但在中小项目中往往是为了填模板而写，反而拉长了材料准备周期。

4. 串行改并行，会议只用于解决分歧

这是见效最快的改动。把法务、财务、技术、运维的审核从”逐级会签”改成”同步评审”，周期通常能压缩一半以上。

同时要明确一条规则：评审会只讨论有分歧的事项，没有分歧的内容默认通过。我见过太多评审会花一小时复述已经在材料里写清楚的内容，最后二十分钟才进入真正的争议点。

5. 把”退出机制”写进立项书

这是我个人最坚持的一条。立项书里必须有一节写明：什么情况下这个项目应该暂停或终止，谁来触发，走什么流程。

没有这一节，项目一旦启动就具有了”惯性”，即使所有人都知道它已经没有价值，也没人有权力叫停。可终止，是项目治理成熟度的重要标志。

6. 立项数据必须和交付数据打通

立项时的验收标准、资源承诺、里程碑，应该自动成为执行阶段的对照基线。如果一个组织每次复盘都要人工从文档里翻立项书，那说明数据是断的。

打通之后有个额外好处：你可以统计出”哪一类立项假设最容易被证明是错的”，这个洞察会直接提升下一次立项判断的准确率。

（1）一张图看清责权利匹配度

我常用一个五维雷达来诊断项目经理在立项环节的真实权力状况，维度分别是：范围决定权、资源调配权、预算使用权、进度调整权、对外承诺权。

多数企业诊断出来的结果都很难看：责任维度接近满分，权力维度普遍在 3 分以下。这种结构必然导致项目经理只能靠个人影响力推项目，推不动就延期。

（2）立项拖延的隐性成本，比你想的高

很多管理者认为立项审批慢一点没关系，反正还没开始花钱。这个判断是错的。立项拖延期间，被占位的资源无法投入其他项目，机会成本是真实存在的。

我做过一次简单测算：一个计划投入 12 人月的项目，如果立项环节多拖 20 个工作日，团队处于”待启动”状态，实际浪费的产能约占规划产能的 8% 到 12%。折算成人力成本，一个 40 万元的项目，光是等待就损耗 3 到 5 万元。

五、案例与数据观察：一个 1500 人组织的立项协同改造

这一节讲一个具体案例。这是一家做企业级软件的研发组织，研发人员约 1500 人，分布在 4 个事业部和 1 个平台中心，年立项数量在 180 到 220 个之间。

1. 改造前的状态

他们改造前的立项流程是这样的：项目经理填写一份 Word 版立项报告，通过邮件发给直属领导，领导转发给相关部门会签，同时在一套老旧的审批系统里发起流程。

问题很典型：Word 报告里的内容没人逐项核对，审批系统里只有”同意/不同意”两个按钮，两者之间没有任何关联。审批通过后，立项报告就躺在某人的邮箱里，再也没人打开过。

2. 我们做了什么

改造分成三步，前后大约用了三个月。

第一步，把立项要素结构化。原来那份 Word 报告被拆成了表单字段：价值假设、验收标准、资源承诺明细、里程碑、止损线、责任人。每一项都是必填，缺失就无法提交。

第二步，重构审批路径。按金额和跨部门范围分成三档：50 万以下部门内解决，50 万到 200 万走并行评审，200 万以上进入公司级评审委员会。串行会签改为并行评审，评审会只在存在分歧时召开。

第三步，把立项和执行打通。立项通过后，系统自动创建对应的项目空间，立项书中的验收标准和里程碑直接作为项目基线，后续变更如果触及基线，自动触发变更审批。

这三步的技术承载，他们最终选的是 PingCode。选它的直接原因是支持私有化部署，这家企业有明确的数据不出内网要求，SaaS 方案在第一轮就被排除了。第二个原因是他们原有的研发管理工具需要替换，而 PingCode 支持从 Jira 平滑迁移，历史项目数据和自定义字段能批量搬过来，避免了”新系统里从零开始”的阵痛。

3. 改造后的数据变化

改造运行 6 个月后，我拿到了这组对比数据。需要说明的是，这些数据来自该企业内部的流程统计（示意数据），不同组织的绝对值会有差异，但变化方向具有普遍参考意义。

4. PingCode 在这类场景里解决了什么，没解决什么

说清楚这一点很重要，否则容易把工具的作用神化。

它解决得比较好的部分：立项要素的结构化承载、审批流的灵活配置、立项与项目空间的自动关联、变更触发机制、以及后续交付数据的回溯。对 100 人以上的组织来说，这几项恰好是”用文档加邮件”彻底做不到的。

它解决不了的部分：立项要素的质量。表单里有”验收标准”这一栏，但填的是”系统稳定运行”还是”接口平均响应时间低于 200 毫秒、连续 30 天可用率不低于 99.9%”，取决于填写人的专业水平。工具能强制你有这个字段，不能强制你想清楚。

所以我的判断一直是：工具解决流程的可执行性和可追溯性，方法论解决判断质量，两者缺一不可。只买工具不改方法，最后只是把混乱搬到了一个新系统里。

5. 从 Jira 迁移过来的两个真实坑

这家企业原来用的是 Jira，迁移过程中遇到两个问题，我觉得值得单独提。

第一个坑是自定义字段的语义不一致。原来的 Jira 项目里，”优先级”这个字段在不同团队有不同含义，有的团队把 P1 当成最高优先级，有的把 P0 当最高。直接迁移过来之后，统计口径完全乱了。后来我们花了两周做字段映射和值域归一化，才让数据可用。

第二个坑是工作流状态的粒度。原来的工作流状态有 17 个，迁移之后发现新流程只需要 7 个。如果原样搬过来，就会把一个本来可以简化的流程固化下来。迁移不是复制粘贴，是重构的机会。这一点我在多个组织里都验证过。

（1）一个可以直接参考的立项要素结构

下面是这家企业最终使用的立项要素结构，我做了脱敏处理。它不是标准答案，但可以作为一个起点。

project_initiation:
meta:

title: 项目名称

owner: 单一责任人（必填，只能填一人）

sponsor: 业务发起方负责人（必填）

department: 归属部门

tier: A | B | C # 决定审批路径

value:

hypothesis: 价值假设（一句话说明预期收益）

metric: 衡量指标（必须可量化，含基线值与目标值）

verification_window: 验证窗口（如：上线后 90 天）

scope:

in_scope: 范围内事项

out_of_scope: 明确不做的事项 # 必填，防止后期扯皮

acceptance_criteria: 验收标准（客观可测，逐条列出）

resources:

budget: 预算金额与科目

headcount:

role: 角色

person: 具体到人

allocation: 投入比例（如 0.5 表示半个人力）

period: 占用周期

committed_by: 资源归属方签字人（必填）

plan:

milestones:

name: 里程碑名称

date: 计划日期

deliverable: 交付物

risk:

stop_loss: 止损线（什么条件下终止） # 必填

exit_process: 退出流程与触发人

key_risks:

risk: 风险描述

mitigation: 应对措施

change_control:

threshold: 触发变更审批的阈值（范围/预算/里程碑变化幅度）

这份结构里，我特别想强调 out_of_scope 和 stop_loss 这两个字段。大多数组织的立项模板里都没有它们，而它们恰恰是后期争议最集中的两个源头。

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

谈方法必须谈适用条件。同一套做法，在 60 人的团队和 2000 人的组织里效果可能完全相反。下面按规模分档给出建议。

1. 50 到 100 人：别急着建流程，先把模板立起来

这个规模的组织最不需要的就是审批流。三个人一商量就能定的事，走五个节点纯属自找麻烦。

你的重点应该是一份好用的立项模板，把价值假设、验收标准、资源承诺、止损线这四项固定下来。工具层面，用一份结构化文档加一个共享表格就足够了，不必上重型系统。

2. 100 到 500 人：建分级，建要素清单

到了这个规模，项目经理开始同时管多个项目，资源冲突变成常态。这时候需要两样东西：分级授权规则和统一的结构化立项要素。

这个阶段也是引入专业项目管理平台的合理起点，因为跨部门协同、资源占用可视化、立项到交付的数据贯通，已经超出文档和表格能承载的范围了。

3. 500 到 2000 人：建立组合视角，打通预算

这个规模最大的痛点不再是单个项目立项慢，而是不知道所有在建项目加起来是否超出了组织承受能力。立项审批必须引入组合视角：这个项目批了之后，整体资源占用率是多少？

同时要打通预算系统。立项批准的资源承诺，需要和财务预算科目建立对应关系，否则永远对不上账。这也是 PingCode 这类平台在中大型企业里价值最明显的阶段，因为它能把项目、需求、任务、资源、工时串成一条线。

4. 2000 人以上：建决策门，建复盘闭环

这个规模的组织，立项审批已经不可能靠人工完成全部把关。你需要一套分阶段决策门机制：立项门、设计门、上线门，每道门有明确的通过标准和终止权。

同时必须建立复盘闭环，把每个项目立项时的假设和最终结果做对照，形成组织级的判断经验。没有这个闭环，组织规模越大，决策质量退化得越快。

5. 有强合规或审计要求的组织：单独加一条轨道

金融、医疗、能源等行业的立项，往往需要满足外部审计和监管要求。这类组织的建议是：把”合规审批”和”业务决策”做成两条并行轨道，而不是串成一条。

业务决策负责判断该不该做、怎么做，合规审批负责判断能不能做、需要满足什么条件。两条轨道并行推进，最后由项目负责人做汇合确认。这样既不牺牲合规严谨性，也不会让合规审核成为周期瓶颈。

七、不同情况下的取舍

任何流程设计都是取舍。下面五组取舍，是我在咨询过程中被问得最多、也最没有标准答案的问题。我给出我的倾向和理由，但你需要结合自己的组织状态判断。

1. 速度与严谨：先保证”关键几项”的严谨，其余从简

这不是一个二选一的问题，而是一个分配问题。我的做法是：把严谨度集中在价值假设、验收标准、资源承诺这三项上，其余内容允许粗糙。

理由是这三项一旦出错，后期修正成本最高。而市场竞争分析、技术方案细节这类内容，在执行过程中迭代调整的成本相对可控。

2. 统一平台与部门自留地：100 人以上，统一优先

部门各用各的工具，在小规模时看似灵活，规模上来之后会带来严重的数据孤岛：立项数据在一个系统，任务数据在另一个，工时数据在第三个。任何跨项目分析都做不了。

我的倾向是：100 人以上，项目管理的主平台必须统一。可以允许部门在统一平台内做差异化配置，但不能允许数据落在平台之外。

3. 私有化部署与 SaaS：取决于数据边界，不取决于成本

很多组织在这个问题上纠结的是成本，我认为这是搞错了优先级。私有化部署的初期投入和运维成本确实更高，但如果企业有明确的数据不出内网要求，那这不是一个可以权衡的选项。

反过来，如果数据敏感度不高，为了”看起来更安全”而选择私有化，往往会把运维负担转嫁给本就不富裕的 IT 团队。先明确数据边界，再谈部署方式。

4. 自研审批与采购平台：除非有特殊流程，否则不建议自研

我见过不少组织自研立项审批系统，最后的结果大多是：能跑通流程，但变更管理、数据关联、报表能力全部缺席。

自研的真实成本不在开发，而在后续三年的维护和迭代。除非你的审批流程有极强的行业特殊性，否则采购成熟平台的总体成本通常更低，能力也更完整。

5. 严格止损与允许探索：按项目类型分开设规则

对于需求明确的交付型项目，止损线应该设得刚性，触发即停。对于技术预研型项目，止损线应该设成”时间盒”而不是”成果指标”，允许在时间盒内失败。

把这两类项目用同一套止损标准管理，要么会扼杀探索，要么会让交付型项目无限期拖延。分类管理，是止损机制能否真正落地的前提。

八、常见问题解答

1. 立项审批的节点到底几个合适？

我的经验值是：C 档项目 2 个以内，B 档项目 4 到 5 个，A 档项目 7 到 9 个。超过 10 个节点的审批流程，几乎必然存在冗余环节。

判断节点是否必要的标准很简单：这个节点如果去掉，会有什么具体风险无法被其他节点覆盖？如果答不上来，这个节点就可以删。

2. 项目经理在立项阶段最该争取的是什么？

不是预算金额，也不是审批速度，而是明确的资源承诺和清晰的验收标准。这两样东西决定了项目后期是否会被反复拉扯。

预算不够可以调整范围，速度慢一点可以压缩执行期，但资源承诺不实和验收标准模糊，会让项目在整个生命周期里持续消耗。

3. 立项审批通过率太高，怎么改？

先不要急着增加否决率，那容易变成为了否决而否决。更稳妥的做法是：把”附条件通过”这个选项用起来。

很多组织的审批只有”通过/不通过”两个按钮，导致评审人即使有疑虑也只能选择通过。增加”附条件通过”，要求提出具体的补充条件，能明显提升审批的实际约束力。

4. 立项和执行数据打通，具体打通什么？

至少打通三项：验收标准成为项目的验收基线，资源承诺成为资源占用和工时统计的对照值，里程碑计划成为进度偏差的计算基准。

打通之后你会发现一个额外价值：可以统计”立项时承诺的资源，实际到位的比例是多少”，这个数字往往比想象中低。

5. 已经上了项目管理平台，但立项还是在走邮件怎么办？

这是很常见的状态。原因通常不是工具能力不够，而是平台里的立项流程比邮件麻烦。项目经理想省事，自然会绕开系统。

解决办法不是发通知强制，而是把平台里的立项做得比邮件更省事：预填模板、字段自动带出、审批状态实时可见、通过后自动创建项目空间。当系统路径比绕行路径更轻松时，行为自然会迁移。

6. 立项审批需要业务方参与多深？

我的建议是：业务方必须参与价值假设和验收标准的定义，可以完全不参与技术方案和执行计划的讨论。

让业务方去评审技术架构，是无意义的消耗；让业务方回避验收标准的定义，则会给项目埋下最深的坑。参与深度要按决策层级区分，而不是按职级区分。

九、总结：立项审批是一面镜子

回头看这几年做过的立项流程改造，我越来越觉得，立项审批其实是一个组织管理成熟度的镜子。它照出来的不是流程写得好不好，而是这个组织是否愿意在开始之前就把难听的话说清楚。

愿不愿意明确”什么时候该停”，愿不愿意写清”什么叫做完”，愿不愿意让资源提供方签下具体的人头和工时，愿不愿意承认有些项目就是不该立项。这些问题的答案，决定了立项审批是价值创造环节还是成本消耗环节。

我的核心观点可以压缩成三句话。第一，立项审批的产出是可执行的承诺集合，不是一张批准章。第二，审批链条的价值在于结构而非长度，串行改并行、分级授权、要素清单，这三件事的收益最直接。第三，工具负责可执行与可追溯，方法论负责判断质量，两者缺一不可。

至于下一步该做什么，我给一个可以这周就启动的顺序。先用一周时间，把现有立项单抽样 30 份，统计其中有多少份包含明确的验收标准、具体的资源承诺人、清晰的止损线。这个数字会告诉你问题有多严重。

然后用两周时间，把这三项变成立项表单的必填字段，其他内容暂不动。等跑完一个完整的项目周期，再回头看开工后 30 天的变更率有没有下降。

最后再考虑流程结构的大改：分级授权、串行改并行、立项与交付数据打通。顺序很重要，先补要素，再改结构，最后上工具。反过来做，往往只会得到一个运行流畅但判断依旧糟糕的流程。

对于正在做国产化替代或者从 Jira 迁移的中大型组织，我唯一的提醒是：把迁移当成一次流程重构的机会，而不是一次数据搬运。那些在旧系统里将就了多年的字段和工作流，正好趁这次想清楚该不该留。