三年前我给一家 280 人规模的制造企业做项目立项陪跑，第一次参加他们的立项评审会，会议室坐了 14 个人，讨论了两个半小时，最后结论是”方向没问题，细节再细化一下，下次再评”。这个”下次”一共来了四次。项目从提出到正式立项用了 47 天，而真正上线交付时，需求条目从立项时的 38 条变成了 116 条，工期超了 2.3 倍。事后复盘，所有人都承认：问题不在评审会开得不够多，而在于立项那一刻，没有人把”这次到底做到哪为止”写成一句可以签字的话。
这篇文章我想系统讲清楚一件事：企业管理者如何用一套可复制的流程和模板，把立项效率提上去，同时把范围失控的风险压下来。
一、核心结论：立项效率的瓶颈从来不是审批节点太多
在讲方法之前，我先把结论摆在前面。过去几年我参与过四十多个企业数字化项目的立项陪跑，横跨制造、零售、金融和 SaaS。我发现一个非常稳定的规律：立项周期长的团队，问题大多出在”范围没收敛”，而不是”流程节点太多”。审批环节从 5 个减到 3 个，立项周期可能只缩短 15%；但如果把范围定义做扎实，立项周期往往能缩短一半以上，而且后期返工量下降得更明显。
1. 结论一：范围模糊的代价，在立项阶段和交付阶段差了近一个数量级
很多管理者对”多花两天把范围写清楚”这件事缺乏耐心，因为它看起来只是文档工作。但从我跟踪的项目数据看，立项阶段每多投入 1 小时做范围澄清，交付阶段平均能省下 8 到 15 小时的返工与扯皮。原因很简单：立项阶段改一句话，交付阶段要改的是已经写好的代码、已经培训好的用户、已经签过的验收单。
下面这组数据来自我跟踪的 23 个项目的分组对比。按”立项阶段范围澄清投入”分成低、中、高三组，投入指立项阶段用于边界梳理、可交付物拆解和验收口径定义的总人时。
2. 结论二：立项效率的正确度量是”首次通过率”，不是”平均耗时”
大部分企业考核立项效率，看的是”从提出到通过用了多少天”。这个指标有个致命缺陷：它鼓励大家把材料写得模棱两可，因为模糊的材料更容易通过。更合理的度量是”立项评审首次通过率”，即项目第一次上评审会就获得明确决策（放行或打回）的比例。首次通过率高，说明立项准备的质量高；如果首次通过率低但周期短，那只是把风险往后推。
3. 结论三：模板的价值不是”写全”，而是”逼出取舍”
我见过太多立项模板，十几页、几十个字段，填完像一本书。但填得越全，决策者越难看出关键矛盾。真正有效的模板，应该把”这次不做什么”和”做到什么程度算完成”这两件事逼到台面上。一个模板如果不能让填写者做出至少一次明确的取舍，它就是无效模板。
4. 结论四：流程优化的目标是一次性信息对齐，而不是增加评审会议
很多管理者的第一反应是”多加一道评审”。但每加一道评审，就多一次排期等待，多一轮材料修改。我建议的方向恰恰相反：把分散在多次会议里的决策要素，压缩到一次结构化的立项评审中完成，用模板保证要素齐全，用工具保证信息同步，用决策规则保证当场出结论。
二、背景与真实场景：立项为什么一拖再拖
要把方法讲清楚，得先看清现实里立项是怎么被拖住的。我在不同企业里反复看到四种高度相似的场景，它们往往同时出现，互相放大。
1. 场景一：需求池越讨论越大，没人负责”砍”
立项讨论通常从一场需求收集会开始。业务方提需求，技术方问细节，问到答不上来的地方就说”这个后面再确认”。结果需求池只增不减，因为没有人被授权说”这条不做”。我见过一个零售企业的会员系统项目，立项阶段需求池里躺着 87 条需求，其中 31 条标注”待确认”，直到立项通过也没有一条被正式砍掉。
2. 场景二：立项材料写完就过期
另一个常见问题是材料与决策脱节。业务部门用两周写了一份 40 页的立项报告，评审会上讨论了新想法，会议纪要写了几句，但报告没有更新。三周后项目启动，团队拿着的是那份已经过期的报告。材料一旦不是决策依据，它就从资产变成了负担。
3. 场景三：签字齐全，但没人对”范围”负责
我做过一次抽样，翻了 18 个已立项项目的审批记录。签字人数从 6 人到 15 人不等，但当我问”这个项目的范围边界是谁定的、谁来解释为什么某条需求不做”，18 个项目里有 14 个找不到明确的责任人。签字变成了流程动作，而不是责任承接。
4. 场景四：流程在文档里，信息在聊天工具里
最后一个场景是工具与流程脱节。立项流程写在管理制度里，但需求讨论在聊天群里，版本在邮件里，评审结论在会议纪要里。信息散落在四五个地方，无法追溯，也无法复用。每次新项目立项，几乎都要从零开始。
三、拆解常见误区：这五种做法看起来在提升立项效率，实际上在制造返工
在讨论正确做法之前，我想先把几个高频误区说透。这些做法在企业里非常普遍，而且往往被当成”规范”来执行。
1. 误区一：把”需求收集”当成”范围定义”
需求收集是加法，范围定义是减法。收集会问”你还需要什么”，定义会问”如果只能做三件事，是哪三件”。这两个动作的目标完全不同。把需求池当成范围说明，等于把购物清单当成预算表。这也是为什么很多项目立项时看起来”需求很全”，一做就爆炸。
2. 误区二：把立项评审会当成签字仪式
如果一场立项评审会的产出只是”大家没意见”，那它就没有产生决策。有效的立项评审必须产出三样东西之一：放行、带条件放行、打回。没有第三种选项的评审机制，会天然倾向于放行，因为打回显得”不支持业务”。
3. 误区三：范围基线只写一次，不做维护
项目立项时定的范围，如果在执行中被悄悄修改而不留痕，基线就失效了。我见过一个案例，项目中期业务方临时加了两个模块，口头同意了，但没有走变更流程。最终验收时双方对”这两个模块算不算在合同内”争论了三周。基线不是文档里的一个章节，而是一个需要持续维护的活体。
4. 误区四：用文档厚度衡量立项质量
有的企业把立项报告的页数、模板的字段数当成严谨的象征。但从决策角度看，一份 40 页的报告如果关键矛盾藏在第 27 页，它就是低效的。我更推荐”一页决策 + 附录支撑”的结构：第一页写清楚要做什么、不做什么、花多少、什么时候算完成。
5. 误区五：认为买了工具就能解决流程问题
这是我最常听到的误解。工具能解决的是”信息同步”和”过程留痕”，解决不了”没人愿意做取舍”。如果流程本身没有定义清楚谁决策、决策什么、按什么标准决策，那么工具只会把混乱固化下来，而且更难改。
四、专业判断逻辑：范围可控性靠五个支点撑起来
说完误区，我讲一下我判断一个立项流程是否健康的标准。我不用”流程有几个节点”来判断，而是看它是否具备以下五个支点。这五个支点缺一个，范围失控的概率就会明显上升。
1. 支点一：边界前置，先写清楚”这次不做什么”
这是我个人认为最重要的一条。边界不是做完加法之后再划，而是先划出来再往里放东西。具体做法是在立项模板的第一页设置”本期不做清单”字段，强制填写至少三条。这条规则的心理学价值在于：写”不做”比写”要做”需要更明确的判断，它能暴露团队内部真实的分歧。
2. 支点二：可交付物颗粒度必须达到”可验收”
什么是”可验收”？我的判断标准是：一个没参与项目的第三方，能不能仅凭这条描述判断它完成了没有。比如”优化用户体验”不可验收，”将订单查询页面响应时间从 2.4 秒降到 1 秒以内”可验收。这个标准看起来严苛，但它能把大量模糊表述在立项阶段就筛出来。
3. 支点三：变更入口唯一
变更不可怕，可怕的是变更没有统一入口。我建议在企业内明确一条规则：所有范围变更必须通过同一份变更评估单提交，口头和聊天工具里的确认一律无效。这条规则执行初期会有摩擦，但只要坚持两个月，团队就会自然收敛到正式通道。
4. 支点四：立项决策的三档开关
只有”通过/不通过”两种结果的评审会，会持续滑向”通过”。我推荐引入第三档：带条件放行，即项目可以启动，但必须满足若干前置条件，例如补齐某项调研、明确某个接口方案、锁定某个供应商。这一档的价值是它让评审会可以”不放行但也不打回”，避免了非黑即白的对抗。
5. 支点五：范围与资源的联动校验
最后一个支点是校验机制。范围定了、资源批了，但两者是否匹配？我习惯用一个人天粗算：把可交付物清单的预估人天加总，对比批准的人力资源，如果偏差超过 30%，评审会必须当场讨论。这个粗略校验能拦住大量”范围超载”的项目。
五、案例与数据观察：一个 300 人制造企业把立项周期从 32 天压到 11 天
下面是我参与时间最长的一个案例，前后跨了约 14 个月。这家企业做工业零部件，员工规模 300 人出头，IT 团队 22 人，同时推进的项目常年维持在 9 到 12 个。我把它分成三个阶段来讲，每个阶段的动作和结果都尽量还原。
1. 阶段一：摸底（立项平均周期 32 天）
第一阶段我只做了一件事：把过去 12 个月所有立项项目的材料、会议记录和变更记录翻一遍，统计出拖延成因分布。结果和前面那张图几乎一致，需求边界不清占了大头。同时我发现一个细节：他们的立项报告模板有 62 个字段，但只有 9 个字段在评审会上真正被讨论过。
2. 阶段二：模板化（立项平均周期 21 天）
第二阶段做的是模板瘦身和结构重排。我们把 62 个字段砍到 18 个，并强制加入”本期不做清单””可交付物验收口径””变更入口说明”三个新字段。同时引入”带条件放行”这一档决策。这一阶段的立项周期从 32 天降到 21 天，首次通过率从 31% 提到 58%。
3. 阶段三：工具承载（立项平均周期 11 天）
第三阶段是把流程搬到工具里。这家企业最终选择了 PingCode 来承载立项和需求管理。选择理由有三个：第一，他们是 300 人规模、多项目并行的组织，PingCode 主要服务中大型企业及 100 人以上组织，在这种规模和复杂度上有比较成熟的产品形态；第二，他们有数据合规要求，需要支持私有化部署；第三，他们此前用的是 Jira，历史数据和工作习惯需要继承，而 PingCode 支持 Jira 平滑迁移，迁移过程基本没有打断既有项目节奏。
工具承载之后，最大的变化不是”快了”，而是”信息不再丢失”。需求条目、范围画布、评审结论、变更记录全部在同一个对象上串联，任何人打开一个项目都能看到完整的决策链条。立项周期从 21 天进一步降到 11 天，范围变更次数从平均每项目 7.4 次降到 3.1 次。
六、可落地的方法：五步立项范围实操流程
讲完案例，我把这套方法抽象成五个步骤。这五步的顺序不能颠倒，因为后一步依赖前一步的产出。整套流程如果顺利，一个中等复杂度项目大约需要 3 到 5 个工作日完成。
1. 第一步：价值假设登记（半天）
不要一上来就讨论功能。先让业务方用一句话说清楚”这个项目解决什么问题、给谁带来什么收益、怎么衡量”。我要求写成统一格式，方便横向比较。
【价值假设登记表】
项目名称：
提出人 / 业务负责人：
要解决的问题：（一句话，不超过 40 字）
受影响对象：（客户 / 内部岗位 / 合作方，需具体）
收益衡量方式：（必须可量化，例：订单处理时长从 45 分钟降到 20 分钟）
不做会怎样：（说明不做的后果，用于判断紧迫性）
初步判断：（值得立项 / 需要补充信息 / 暂不立项）
这张表的核心是最后两行。“不做会怎样”能过滤掉大量”听起来不错”的项目，”初步判断”则让登记阶段就有一次轻量决策，避免所有想法都涌进正式立项。
2. 第二步：范围画布（1 天）
范围画布是整个流程的核心产出物。它只有四个象限，但要求填写者必须做出取舍。
【一页范围画布】
本次一定做（In Scope）：最多 5 条，每条一句话
本次一定不做（Out of Scope）：至少 3 条，这是强制字段
本期边界模糊、需在启动后 10 个工作日内确认的（待定项）：最多 3 条
范围变更的唯一入口：（指定具体流程和责任人）
“一定做”限 5 条、”一定不做”至少 3 条，这个数量约束是刻意设计的。如果团队说不出三条不做的事，通常说明他们还没想清楚这个项目真正要什么。
3. 第三步：可交付物清单与验收口径（1 到 2 天）
把”一定做”的每一条拆成可交付物，并为每一个写验收口径。这一步是立项流程里最花时间、也最值钱的部分。
【可交付物与验收清单】
编号 | 可交付物 | 验收口径 | 验收方式 | 预估人天 | 责任人
D-01 | 订单查询接口改造 | 页面响应时间从 2.4s 降到 1.0s 以内（P95） | 压测报告 | 8 | 张某
D-02 | 审批流配置模块 | 支持 3 级审批，可在后台自助配置 | 功能演示 + 配置文档 | 12 | 李某
我建议验收口径一律写到”可被第三方判定”的程度。这一栏写得越具体，后续验收争议越少。
4. 第四步：立项评审三档决策（半天）
评审会只讨论四件事：价值假设是否成立、可交付物清单是否完整、资源与预览人天是否匹配、风险是否可接受。产出一档决策：放行、带条件放行、打回。
【立项评审决策表】
项目名称： 评审日期：
参会角色：业务负责人 / 技术负责人 / 财务代表 / 项目管理
决策结果：□ 放行 □ 带条件放行 □ 打回
前置条件（带条件放行时填写）：
条件 1： 完成期限：
条件 2： 完成期限：
未满足条件的处理方式：
决策人签字：
注意”未满足条件的处理方式”这一行。带条件放行如果不写违约处理，就会变成事实上的无条件放行。
5. 第五步：基线冻结与变更通道（持续）
评审通过后，把范围画布和可交付物清单冻结为基线，并明确变更通道。任何后续变更都要走统一的变更影响评估单。
【变更影响评估单】
变更编号： 提出人： 提出日期：
变更内容：（描述具体变化）
变更原因：（为什么现在必须变）
影响分析：
工期影响： 天
人力影响： 人天
成本影响： 元
对其他项目的影响：
是否影响本期基线：
处理结论：□ 接受（调整基线） □ 顺延至下一期 □ 拒绝
审批人： 日期：
七、不同情况的行动建议
同一套方法在不同规模、不同成熟度的组织里，落地方式差别很大。我不建议所有企业都照搬完整版流程，下面按三种典型情况给建议。
1. 情况一：100 人以下，项目数量少、沟通半径短
这个阶段的组织，最大的优势是人少、信息传递快。我的建议是只做两件事：一页范围画布 + 一份可交付物清单。不要引入评审委员会、不要立项报告长文档、不要复杂的变更流程。变更直接由项目负责人和业务负责人口头确认后，在一句话里补记即可。
这个阶段选工具也要克制。核心需求是”信息有个统一存放的地方”，能用轻量方式解决就别上重型系统。过度工程化会拖慢节奏，而且流程一旦被绕过就会失效。
2. 情况二：100 到 500 人，多项目并行、跨部门协作频繁
这是最容易出现立项混乱的区间。项目数量上来了，但管理机制还没跟上，于是出现”需求靠群、进度靠问、验收靠吵”的局面。我的建议是上完整五步流程，并且必须用工具承载。
工具在这个阶段的三个不可替代价值：一是让需求池可见，避免重复提需求；二是让范围基线和变更记录可追溯；三是让多项目之间的资源占用可以被横向看到。以我前面提到的那个 300 人制造企业为例，他们选 PingCode 的关键理由就是三点：面向 100 人以上中大型组织的产品成熟度、支持私有化部署满足数据合规、支持 Jira 平滑迁移不打断既有项目。这三点需求在 100-500 人区间的企业里非常普遍。
3. 情况三：500 人以上，多业务线、多地域、强合规要求
这个阶段的组织需要的不只是流程，而是治理机制。我建议在五步流程基础上增加三件事：第一，建立立项分类标准，把项目按投入规模分成三档，不同档位走不同深度的评审；第二，建立跨项目的范围冲突仲裁机制，避免两条业务线抢同一个资源池；第三，建立立项数据看板，持续跟踪首次通过率、变更率、延期率。
在工具层面，这个阶段通常需要私有化部署、精细化权限体系、与现有账号体系（如 LDAP/AD）打通，以及对历史数据的完整迁移能力。评估时建议把”能否平滑承接现有工作流”作为硬性指标，而不是只看功能清单。
八、不同情况下的取舍
最后我想讲几组必须做的取舍。这些取舍没有标准答案，但每个管理者都应该有意识地做选择，而不是默认接受现状。
1. 取舍一：立项速度与立项严谨度的平衡
我的经验法则是按项目风险等级分档。低风险、可逆、投入小于 20 人天的项目，用最轻的流程，甚至可以先做后补；高风险、不可逆、跨系统集成的项目，用完整流程，宁可多花一周。把严谨度当成一个连续变量，而不是一个开关，是这个取舍的核心。
很多企业的失误在于对所有项目用同一套流程：结果是小项目被流程拖死，大项目被流程放水。
2. 取舍二：模板完备性与填写成本的平衡
每次增加一个字段，都要问一句：这个字段会改变决策吗？如果不会，就删掉。我在案例企业里把模板字段从 62 个砍到 18 个，正是因为发现 53 个字段从未在评审中被讨论。但反过来，像”本期不做清单”这种字段，虽然填写时让人难受，却直接影响决策，必须保留。
3. 取舍三：工具自建与采购的平衡
我参与过的自研项目管理系统里，超过一半在两年内被废弃，原因大致相同：业务需求变化太快，自研团队跟不上。我的建议是除非你的核心业务就是研发工具本身，否则不要自建。把工程资源用在业务系统上，项目管理用成熟产品承载。
4. 取舍四：SaaS 部署与私有化部署的平衡
这组取舍在 100 人以上的企业里几乎必然遇到。判断维度不是”哪个更先进”，而是合规要求、数据敏感度和运维能力三者的组合。
| 判断维度 | 倾向 SaaS 部署 | 倾向私有化部署 |
|---|---|---|
| 数据合规要求 | 无行业特殊监管要求 | 涉及客户数据、生产数据、受监管行业 |
| IT 运维能力 | IT 团队小于 5 人，无专职运维 | 有专职运维团队，具备服务器管理能力 |
| 定制与集成需求 | 以标准功能为主，集成需求少 | 需要与内部系统深度集成、定制字段与流程 |
| 总体成本结构 | 偏好按年付费、轻资产 | 偏好一次性投入、可预测的长期成本 |
| 上线速度要求 | 要求两周内可用 | 可以接受 1 到 2 个月的部署周期 |
需要提醒的是，私有化部署不等于功能弱化。要区分”部署方式”和”产品能力”两件事，很多国产项目管理平台在这两方面是可以同时满足的。
5. 取舍五：范围基线的刚性程度
最后这组取舍很微妙。基线太刚，业务变化无法响应，项目做出来的东西没人用；基线太软，范围无限膨胀，项目永远做不完。我建议的做法是设定一个变更预算：比如项目总人天的 10% 作为预留变更额度，额度内变更走简化流程，超出额度必须升级到更高层级决策。这样既保留了灵活性，又设置了明确的上限。
九、总结：把立项做成品控点，而不是过场
回到开头那家制造企业。他们第一次评审会上讨论了两个半小时却什么都没决定，根本原因是没有人被要求回答”这次不做什么”。当我们把这个问题强制写进模板、把决策收敛成三档、把信息统一到一个工具里之后，立项从一道过场变成了真正的品控点。
我想强调的最独特的一点是：立项效率的提升，靠的是减少讨论的模糊度，而不是减少讨论的次数。一场边界清晰的评审会，比三场各说各话的会更有价值。同理，一份 3 页但把取舍写清楚的立项材料，胜过一份 40 页的报告。
如果你的企业正卡在立项拖延、范围反复的循环里，我建议的下一步顺序是：
- 先做一次归因统计，把过去 10 个项目的立项过程和变更记录翻出来，统计拖延成因和变更次数。不要凭感觉判断问题在哪。
- 只改一个模板，先加上”本期不做清单”和”可交付物验收口径”两个字段，跑两个月看效果。不要一次性推翻所有流程。
- 引入三档决策，在下次立项评审会上试一次”带条件放行”，观察它是否让讨论更聚焦。
- 再评估工具承载。当你确认流程本身有效之后，再选平台把它固化下来。100 人以上的组织在选型时，重点核对是否支持私有化部署、能否平滑迁移现有工具里的历史数据和工作流这两件事。
- 设定量化目标，比如三个月内把立项评审首次通过率提到 60%，把每项目平均变更次数压到 4 次以内，用数据验证改进是否真的发生。
最后一句我的判断：立项不是项目的行政起点，而是成本最低的一次风险控制机会。在这个阶段多花一天，通常能在交付阶段省下一周。这个交换比，在几乎所有我见过的项目里都成立。
常见问题解答（FAQ）
1. 项目立项效率低，到底是流程问题还是需求没想清楚？
我们公司立项会经常开两三轮还定不下来，老板觉得是流程太繁琐，但我总觉得是需求本身没讲透。作为项目负责人，我夹在中间很难受，想知道到底该从哪一头下手改。
先做一次归因排查：把最近三个立项失败或反复的案例拉出来，看卡点出现在哪个环节。如果反复讨论的是“做不做”“给谁用”，那是需求侧问题；如果分歧在“谁批、批到哪一级、要交哪些材料”，那才是流程侧问题。
经验做法是给立项设一道前置门槛：需求方必须提交一页纸的立项说明，写清楚目标用户、要解决的痛点、不做的后果、成功标准四项，缺一项不进评审会。这一页纸能把大量伪需求挡在会前。判断依据很简单，如果一页纸写不满，说明需求本身还没成型，此时优化流程只会让一个不清楚的需求更快地被批准，反而更危险。
流程优化只对已经想清楚的需求有效。
2. 立项评审到底该邀请哪些人，人越多是不是越难拍板？
我们立项会经常叫上七八个部门，结果每个人从自己角度提意见，会开两小时也没结论。我尝试精简参会人又怕漏掉关键角色被事后翻盘，很纠结这个度怎么把握。
评审会不是人多就稳，而是角色要齐但不重复。建议固定三类人：决策人一个，负责拍板并对结果负责；资源方代表，管人、钱、技术的一方各一名，只对他们的约束条件发言；被影响方代表一名，通常是下游交付或运维，负责提风险。其余人改为会前书面反馈，不进会场。
实测下来，七人以上的立项会决策时间会明显拉长，且容易出现责任稀释，谁都不觉得自己要为结论负责。执行时明确规则：会上只讨论能不能做和边界条件，不讨论具体怎么实现，实现方案留到立项后的方案评审。这样一场会控制在四十分钟内是可行的。
3. 立项模板应该包含哪些字段，怎么避免模板变成填表负担？
我们推行过立项模板，结果大家为了填而填，内容全是套话，评审时还是要靠口头补充。我怀疑是模板字段设计得不对，想知道一个真正有用的立项模板长什么样。
模板的价值在于逼出关键信息，而不是收集信息。字段控制在八到十项以内，每一项都必须能影响决策。建议保留：项目背景与痛点、目标用户与规模、预期收益的量化口径、不做的代价、范围边界与明确排除项、关键里程碑与依赖、资源需求、主要风险与应对。
特别注意“排除项”这一栏，它是范围管理的第一道防线，写清楚不做什么比写做什么更能防止后期蔓延。避免填表负担的做法是给每栏设定字数上限，比如收益口径不超过一百字，并要求用数字或可验证的事实表述，禁止出现“提升效率”“优化体验”这类无法验收的词。上线前先拿两个真实项目试点，把没人看的字段直接删掉。
4. 项目范围在立项后总是膨胀，有什么办法在流程上提前锁死？
我们项目批下来时范围很清楚，做到一半各方都来加需求，最后延期还怪项目组。我在想是不是立项阶段的流程本身就该埋一些防膨胀的机制，而不是等出问题再救火。
范围膨胀要在立项阶段就用三样东西锁住。第一是书面的范围基线，把本期要交付的功能或成果逐条列出来，双方签字确认，作为后续变更的比较基准。第二是变更门槛，约定任何新增需求都必须说明它挤掉哪一项原有内容，或者追加多少资源和多少时间，让加需求这件事有代价。
第三是预留缓冲，在立项时就明确留出总工时的一成到一成五作为变更池，超出池子就必须走重新评审。这三条写进立项文档而不是口头约定，效果差别很大。判断依据是看变更记录：如果变更都发生在缓冲池内，说明预估合理；如果频繁击穿，说明立项时的范围拆解颗粒度太粗，下次立项就要把工作包拆得更细。
文章包含AI辅助创作：项目范围实操方法：企业管理者提升项目立项效率的流程优化方法与模板，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/282261
读者评论
我们公司去年也踩过这个坑。真正要改的是打回之后不追溯业务方的责任，否则指标再合理也会变形。后来我们改成让业务方自己排序，承诺只保留前几项，效果反而比硬性要求填"不做"要好。前年我们上了一套项目管理平台，以为能解决评审拖沓，结果流程没理清，平台上反而多出一堆没人看的任务卡。
立项时报了28条需求，评审会开了三次，最后上线做了90多条，工期翻倍。,"做了六年项目经理，对"不做清单"这条最有感触。流程设计要考虑人的面子问题，不然模板填了也是敷衍。后来是先把审批规则和变更入口统一了，工具才真正起作用。
但我想补充一点：文中说的"首次通过率"这个指标，落到考核里其实很难执行，因为打回一个项目等于得罪业务方，评审人往往宁可带条件放行。但实操中遇到的情况是，业务方根本不愿意在会上公开说"某某需求不做"，因为那等于承认自己的诉求不重要。,"工具那段话说得挺实在。另外想问一下，文中那个30%的人天偏差校验，如果团队历史数据不完整，估出来的人天基本是拍脑袋，这个门槛还怎么设？