去年 11 月到今年 3 月，我连续走访了 9 家企业研发组织，规模从 120 人到 1600 人不等，行业覆盖智能硬件、工业软件、SaaS 和系统集成。走访中我问了同一个问题：“你们项目现在处于什么阶段？”九次里有七次，受访者打开的不是项目管理系统，而是一张 Excel 甘特图。剩下两次打开了工具，但项目阶段字段已经三个月没人更新，最后一次修改人还是已经离职的项目经理。这不是工具问题，而是阶段与状态这两个概念，在绝大多数企业里从未被真正定义过。
这篇文章要解决的就是这件事：把“阶段状态管理”从一句口号，拆成一套企业管理者能直接落地、能验收、能追责的方案与清单。
一、核心结论：阶段状态管理是三条不能混淆的线
先把结论摆在前面。我在 9 家企业的诊断里反复验证过一件事：凡是阶段状态管理做得住的团队，都把三条线分得清清楚楚，阶段线管承诺，状态线管流动，门禁线管质量。三者混在一起，流程就会变成一张谁都不信的表。
1. 阶段回答“我们在哪一段”，状态回答“这件事现在怎么样”
阶段（Phase）是计划层的概念，描述项目整体推进到了哪个大块，比如“概念验证”“设计冻结”“小批量试产”。它有明确的起止点、可交付物和责任人，变更需要走评审。
状态（Status）是执行层的概念，描述单个工作项此刻的处境，比如“待处理”“进行中”“阻塞”“待验收”“已关闭”。它的特点是可以高频变化，一天变三次也不算异常。把两者混成一列，就会出现“项目阶段=开发中”这种既不像计划也不像状态的四不像字段。
2. 阶段必须绑定可交付物和准入准出条件
我见过太多企业的阶段定义是这样的：“需求阶段、设计阶段、开发阶段、测试阶段、上线阶段”。这五个词没有任何约束力，因为没人说得出“设计阶段结束”到底要交出什么。
有效的阶段定义长这样：设计冻结 = 结构 3D 图版本锁定 + BOM 首版发布 + 关键器件替代料评审通过 + 硬件与固件接口文档双方签字。这样定义之后，“是否进入下一阶段”就不再是一个主观判断，而是一个可以逐条打勾的核对动作。
3. 状态数量应该少而稳定，阶段数量应该多而可控
这是我一条比较反直觉的经验：状态要少，阶段可以多。状态是每个人每天都要点的东西，每多一个状态，团队的理解成本就翻一倍；而阶段是管理层评审的对象，多几个反而能让风险暴露得更早。
| 维度 | 阶段（Phase） | 状态（Status） |
|---|---|---|
| 所属层级 | 计划层，挂在项目上 | 执行层，挂在任务/缺陷/需求上 |
| 变化频率 | 低，每个阶段通常 2 周到 3 个月 | 高，一天可能变化多次 |
| 变更权限 | 项目经理或阶段门评审组 | 任务负责人本人 |
| 典型数量 | 5～12 个 | 5～9 个 |
| 核心作用 | 承诺、资源投放、风险分级 | 流动效率、瓶颈识别、WIP 控制 |
| 失败信号 | 阶段只能前进不能回退 | 出现“已完成 80%”这类状态 |
这张表我在多家企业的流程工作坊上直接用白板画过。画完之后，八成参与者会意识到自己原来的系统里，阶段和状态根本就是同一列字段，只是名字不同。
二、真实场景：阶段状态为什么会在半年内全面失控
讲一个具体案例。2024 年 3 月，我参与了一家 300 人规模智能硬件公司的研发流程诊断。这家公司做工业级边缘计算设备，硬件、固件、上位机软件三线并行，同时在跑的项目有 14 个。
1. 表面正常，底层已经失真
诊断第一天，项目管理办公室给我看的是这样一组数据：14 个项目中，11 个项目进度显示“正常”，2 个显示“轻微延期”，1 个显示“延期”。整体健康度看起来相当不错。
第二天我让项目经理导出所有任务卡片，统计每张卡片最后一次状态变更距今天数。结果是：全部 3847 张未关闭任务中，有 2136 张卡片超过 14 天没有发生任何状态变更，占比 55.5%。其中 617 张超过 60 天，最早的可以追溯到 2023 年 8 月。
第三天我做了抽样访谈，随机抽了 12 张“进行中”的卡片，逐个问负责人真实情况。12 张里有 5 张其实已经完成但没关，3 张其实卡在等外部供应商但状态还是“进行中”，2 张已经废弃，只有 2 张是真的在推进。
2. 失控的连锁反应
数据失真只是第一层。真正的代价在后面：因为看不到真实的阻塞，管理层在 2024 年 Q1 依然按原计划给三个“正常”项目追加了人力，结果这三个项目实际都卡在同一个供应商的电源模块认证上，追加的人只能空转。
与此同时，另外两个真正需要支援的项目因为没有“叫苦”的渠道，状态里根本没有“阻塞”这个选项，只有“进行中”和“已完成”，被持续忽视，最终演变成客户投诉。
员工侧的反应同样值得注意。我在访谈中听到最多的一句话是：“更新状态没人看，填了也是白填。”当状态字段无法为填写者带来任何反馈或帮助时，它必然在 3 到 6 个月内退化成形式主义。这是我观察到的、几乎不受行业和企业规模影响的规律。
三、常见误区：七个把阶段状态做成废纸的做法
把 9 家企业的诊断记录做交叉比对后，我整理出七个高频误区。它们的共同点是：单独看每个都很合理，组合起来就让整套机制彻底失效。
1. 把里程碑当成阶段
里程碑是时间点上的一个事件，阶段是一段有输入输出的区间。把“Beta 版本发布”当成一个阶段，团队就没办法回答“Beta 发布之前我们应该在做什么”。
正确的做法是：阶段是区间，里程碑是区间的终点标志。一个阶段可以包含多个里程碑，但阶段本身必须有持续时间和责任人。
2. 用百分比表示阶段进度
“设计阶段完成 80%”这句话的信息量接近于零。80% 是怎么算的？是文档写了 8 篇中的 6.4 篇，还是评审过了 5 项中的 4 项？
我的建议是彻底废掉阶段百分比，改用门禁清单通过率。设计阶段 12 项检查条目过了 9 项，就是 9/12，剩下的 3 项是什么、谁负责、什么时候能过，一清二楚。
3. 状态定义过多，超过 12 个
我在一家企业见过 23 个状态的工作流，包括“待产品经理确认”“待技术负责人评估”“待产品和技术双签”等等。结果是所有人都在凭记忆找状态，新人上手要两周。
更隐蔽的代价是维护成本。状态越多，跨状态流转的规则就越多，规则越多就越容易在实际执行中被绕过，最终系统里的数据反而更不可信。
4. 没有“阻塞”和“挂起”状态
这是我最常见也最痛心的一类设计缺陷。很多团队的状态只有“未开始、进行中、已完成”，因为他们觉得“阻塞”是一种异常，不该出现在正常流程里。
但事实恰恰相反。没有阻塞状态，阻塞就会伪装成“进行中”，然后吞噬掉整个项目的缓冲。我建议至少保留“阻塞（有明确外部依赖）”和“挂起（主动暂停，需说明原因）”两个独立状态，并要求填写阻塞对象和预计解除时间。
5. 阶段只挂在项目上，不挂在工作项上
项目有阶段，但任务没有。结果就是：你能知道项目在“设计冻结”阶段，却不知道 300 个任务里有 47 个其实还属于上一个阶段没干完的活。
解决办法是给工作项加一个“所属阶段”字段，并设置校验规则：当项目已经进入下一阶段时，仍停留在上一阶段未完成的工作项必须显式挂账，不能静默遗留。
6. 阶段门评审变成签字仪式
我参加过一场 40 分钟的阶段评审会，12 位参会者，最后 8 分钟在讨论一张 PPT 的配色。评审结论是“通过”，但会后复盘发现，有 3 个关键风险项根本没被提及。
评审失守通常不是因为人不认真，而是因为清单太笼统。把“设计是否完整”换成“接口文档是否覆盖全部 37 个寄存器地址”，评审的注意力自然会被拉到该拉的地方。
7. 阶段回退没有规则
大部分企业的阶段是单向的：一旦从“设计”走到“开发”，就再也回不去。这在现实中完全站不住脚，设计缺陷在开发阶段被发现是常态。
没有回退规则的结果是：团队会用各种变通方式掩盖回退，比如开一个“设计补充”的临时项目、把返工任务挂到下一个阶段。数据看起来干净了，风险却被藏了起来。
四、专业判断逻辑：阶段门、状态机、检查项三层模型
讲完误区，说方法论。我在实际咨询中用的是一套三层模型，从外到内分别是阶段门、状态机、检查项。三层各自解决不同问题，缺一层整套机制就会漏。
1. 第一层：阶段门（Phase Gate）解决“敢不敢放行”
阶段门是设定在阶段边界上的一次强制评审。它的关键设计要素有四个：门禁清单、评审人、放行条件、回退路径。
（1）门禁清单
清单条目必须是可验证的事实，不能是形容词。比如“性能是否达标”不合格，应该是“连续 72 小时压力测试下 P99 延迟不超过 150ms，测试报告已归档”。
（2）评审人
评审人不超过 5 人，且必须包含一位对结果负责的业务方。我见过 15 人评审团，结果是谁都不负责。
（3）放行条件
建议采用“全部必选项通过 + 可选项允许挂账”的规则。必选项通常不超过 8 条，超过 8 条就说明阶段划分过粗。
（4）回退路径
必须明确写出：什么情况下允许回退、回退到哪个阶段、回退后原阶段的产出物如何处理、回退次数是否触发升级机制。我的经验是同一个项目在同一道门回退超过 2 次，就应该上升到项目组合层面重新评估。
2. 第二层：状态机（State Machine）解决“看得见流动”
状态机的核心不是状态列表，而是流转规则。每一条规则都要回答四个问题：谁能触发、触发条件是什么、触发后通知谁、停留超时怎么办。
下面是我在一个 400 人研发组织中实际使用的状态机配置片段，可以直接作为配置参考：
workflow: 研发任务标准流
states:
id: todo
name: 待处理
wip_limit: null
max_dwell_days: 5
id: doing
name: 进行中
wip_limit: 3 # 单人同时在办不超过 3 项
max_dwell_days: 7
id: blocked
name: 阻塞
wip_limit: null
max_dwell_days: 3 # 超过 3 天必须升级
required_fields: [blocker_owner, blocker_reason, expect_release_date]
id: review
name: 待评审
wip_limit: null
max_dwell_days: 2
id: done
name: 已完成
wip_limit: null
max_dwell_days: null
transitions:
from: todo
to: doing
allowed_roles: [assignee]
guard: "estimate_hours is not null"
from: doing
to: blocked
allowed_roles: [assignee, project_manager]
guard: "blocker_owner and expect_release_date"
notify: [project_manager]
from: blocked
to: doing
allowed_roles: [assignee, project_manager]
from: doing
to: review
allowed_roles: [assignee]
guard: "deliverable_url is not null"
from: review
to: done
allowed_roles: [reviewer, project_manager]
from: review
to: doing
allowed_roles: [reviewer]
guard: "reject_reason is not null"
这段配置里我认为最值得抄走的是两个字段：max_dwell_days 和 guard。状态超时告警是把状态管理从“填表”变成“预警系统”的关键一步，没有它，状态数据永远只是事后记录。
3. 第三层：检查项（Checklist）解决“落到具体动作”
检查项是挂在阶段门上的可勾选清单，也是整套体系里最容易被偷工减料的一层。我的建议是每个阶段门的检查项控制在 6 到 15 条之间。
低于 6 条，说明颗粒度太粗，评审会变成走过场；高于 15 条，评审时间会超过 2 小时，团队会开始批量勾选，反而更危险。
五、落地清单：项目级、迭代级、工作项级三张表
方法论讲完，进入可执行部分。我把沉淀多年的落地动作整理成三张清单，分别对应三个管理层级。你在推动时可以直接打印出来逐条核对。
1. 项目级清单：管承诺与资源
- 定义本组织统一的阶段集合（建议 5～9 个），并写入流程文档，明确哪些项目类型可以裁剪。
- 为每个阶段编写可交付物清单，每项可交付物指定唯一责任人。
- 为每道阶段门编写 6～15 条检查项，区分必选项与可选项。
- 明确每道门的评审人名单（不超过 5 人）和评审时限（建议 2 个工作日内给出结论）。
- 定义阶段回退规则，包括允许回退的情形、审批人、回退次数上限和升级路径。
- 在项目管理系统中把阶段做成受控字段，只允许项目经理及以上角色修改，并记录变更历史。
- 建立阶段停留时长基线，超过基线 50% 的项目自动进入预警列表。
2. 迭代级清单：管节奏与缓冲
- 明确迭代是否跨阶段。如果跨阶段，必须标注每个任务所属阶段。
- 计算本迭代内属于“上一阶段遗留任务”的工时占比，我建议控制在 15% 以内。
- 设置迭代级的阻塞任务看板，每日站会只过阻塞项，不过正常项。
- 统计迭代内状态流转次数与平均停留时长，作为流程健康度指标。
- 迭代结束时输出阶段门准备度评估，提前暴露下一道门可能卡住的条目。
3. 工作项级清单：管动作与责任
- 每个工作项必须有所属阶段、负责人、状态三项必填字段。
- 状态为“阻塞”时必须填写阻塞对象、阻塞原因、预计解除日期，三项缺一不可。
- 同一负责人的“进行中”任务数量设置上限，我建议研发角色不超过 3 项，管理角色不超过 5 项。
- 为每个状态设置最长停留时长，超时自动通知负责人和项目经理。
- 工作项进入“待评审”时必须附上可交付物链接，不允许空链接通过。
- 关闭工作项必须由非提交人确认，避免自审自过。
| 清单层级 | 核心目标 | 关键指标 | 责任人 | 复盘周期 |
|---|---|---|---|---|
| 项目级 | 承诺可控、资源可调 | 阶段门一次通过率、阶段停留超期率 | 项目经理 / PMO | 每道门评审后 |
| 迭代级 | 节奏稳定、阻塞透明 | 阻塞任务占比、跨阶段遗留工时占比 | 迭代负责人 / Scrum Master | 每迭代一次 |
| 工作项级 | 动作清晰、责任到人 | 状态超时率、WIP 超限次数 | 任务负责人 | 每周一次 |
六、工具落地与数据观察：以 PingCode 为例
清单再漂亮，落不到工具里就是一张纸。这一节我用一个真实的实施案例来说明工具层该怎么配。案例对象是一家 620 人的工业软件企业，2023 年底开始做研发管理平台的替换与流程重构。
1. 为什么这类组织需要私有化与迁移能力
这家企业的三个约束条件很典型：一是客户中包含多家大型制造集团，要求研发数据不出内网；二是原有系统上积累了 6 年历史数据，约 42 万条工作项，不能丢；三是研发团队长期使用 Jira 的操作习惯，迁移后如果交互差异太大，会引发抵制。
他们最终选择了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，并且支持 Jira 平滑迁移，是国产替代场景下的常见选择之一。这三点正好对应上面三个约束。
迁移过程我参与了一部分。实际耗时分布是：字段映射方案设计 9 人天，历史数据清洗 14 人天，试迁移与差异比对 6 人天，正式迁移与并行验证 4 人天，总计 33 人天。42 万条工作项、17 个自定义字段、9 套工作流全部迁移完成，历史数据校验差异率控制在 0.3% 以内。
2. 平台上线的关键配置动作
迁移只是第一步。真正决定成败的是上线后的配置，我列出这家企业实际做的七件事，供你对照：
- 把项目阶段从原来的文本字段改为受控枚举，共 7 个阶段，禁止自由输入。
- 为每个阶段配置准入准出检查清单，清单条目直接关联到阶段门评审单。
- 重建工作流，把原来的 21 个状态压缩到 8 个，并新增“阻塞”与“挂起”。
- 开启状态停留超时告警，规则为超过设定天数自动推送负责人与其直属上级。
- 配置单人 WIP 上限，超出时系统阻止继续领取新任务。
- 搭建阶段门看板，把每个项目的门禁清单通过率以进度条形式呈现。
- 建立度量报表，固定输出阶段停留时长、阻塞占比、门禁一次通过率三类图表。
3. 上线后 6 个月的数据变化
这家企业是 2024 年 2 月正式上线的，到 8 月我回访了一次。数据变化比我预期更明显，特别是阶段门一次通过率的提升幅度。
4. 一个我认为被低估的收益
这家企业的一位研发总监跟我说了一句话，我印象很深：“以前我最怕的不是项目延期，是我不知道哪个项目会延期。”
阶段状态管理做到位之后，最大的变化不是延期变少了，而是延期变得可预测。阶段停留超期率这个指标，在他们内部被当作“提前 4 到 6 周的预警信号”使用，准确度明显高于原来的进度百分比。
七、行动建议：不同规模组织的落地路径
方法论不能一刀切。我按组织规模和业务形态整理了四条路径，你可以直接对号入座。
1. 50 人以下团队：只做状态，暂缓阶段门
这个规模的团队沟通成本低，靠站会就能对齐。此时上阶段门是过度设计，反而会拖慢节奏。
建议只做两件事：把状态压缩到 5 个并加上“阻塞”，以及设置单人 WIP 上限。这两件事投入不超过 3 人天，收益却很直接。
2. 50 到 200 人团队：状态机 + 轻量阶段划分
这个区间开始出现跨团队协作，需要正式的阶段定义。建议设 5 到 7 个阶段，其中只有 2 到 3 个关键阶段配置正式门禁评审，其余用自检清单即可。
我特别建议在这个阶段引入状态停留时长统计。它是成本最低、见效最快的流程健康度指标。
3. 200 到 1000 人团队：完整三层模型 + 工具支撑
这个规模必须上完整的三层模型，并且需要工具支撑。手工维护的阶段状态数据在这个体量下必然失真。
选型时我建议重点看四项能力：是否支持自定义状态机与流转规则、是否支持阶段字段的受控变更、是否支持超时告警与度量报表、是否支持私有化部署。对于有内网合规要求的中大型企业，私有化部署往往是硬性门槛。
4. 硬件与制造类企业：把阶段门加密
硬件项目的返工成本远高于软件，一个模具开错可能损失数十万元。这类企业我建议把阶段数量增加到 9 到 12 个，门禁清单加厚，但每个阶段的停留时间要相应缩短，避免评审本身成为瓶颈。
八、取舍：四组必须提前想清楚的权衡
任何流程设计都是取舍。以下四组矛盾我在每家企业都会遇到，提前想清楚能省掉大量返工。
1. 标准化与灵活性
标准化降低协作成本，灵活性保留应变空间。我的判断是：阶段必须标准化，状态可以分层。也就是说，全公司统一 7 个阶段、统一的阶段门定义，但允许不同产品线使用不同的状态机，前提是所有状态机都映射到统一的度量口径上。
2. 强制门禁与软门禁
强制门禁意味着不通过就不能进入下一阶段。它的好处是约束力强，坏处是遇到紧急项目时团队会想办法绕开，比如开一个“预研”名义的旁路项目。
软门禁是允许带条件放行，但挂账项必须登记并限期关闭。我的经验是：关键门（如设计冻结、量产放行）必须强制，其余门建议软性。全部强制会导致流程被架空，全部软性则等于没有门。
3. 阶段粒度：粗与细
阶段越粗，评审次数越少，管理成本越低，但风险暴露越晚；阶段越细，预警越早，但评审负担越重。
我通常用一条经验线来判断：如果两个相邻阶段的平均时长都短于 2 周，就该合并。因为评审本身的准备和开会成本会吃掉阶段管理的收益。
4. 自建与采购
自建流程系统的诱惑在于完全贴合业务，代价是维护成本被严重低估。我见过一个团队用两年时间自建了一套流程平台，第三年因为原开发者离职，整个系统进入半废弃状态。
我的建议是：流程逻辑必须自己定义，承载流程的工具尽量采购。前者是核心竞争力，后者是通用能力。对于有数据合规要求的中大型企业，采购时把私有化部署能力和历史数据迁移能力作为硬性评估项。
九、常见问题解答
1. 阶段和迭代的关系应该怎么处理？
两者是不同维度，不是替代关系。迭代是时间盒，阶段是可交付物驱动的区间。一个阶段通常包含多个迭代，一个迭代也可能跨越阶段边界。
实操上，我建议给工作项同时打上“迭代”和“所属阶段”两个标签，并在迭代评审时额外统计“本迭代中属于上一阶段遗留任务的工作量占比”。这个比例超过 15%，就说明阶段门放行过于宽松，需要收紧。
2. 团队抵触更新状态怎么办？
抵触的根源通常不是懒，而是“更新了也没用”。我在一家企业做过对照实验：只在一个部门开启状态超时告警和阻塞升级机制，其余部门保持原样。三个月后，试点部门的状态更新率是 89%，对照组是 51%。
差别就在于试点部门的成员发现，把任务标成“阻塞”之后，第二天真的有人来帮忙协调了。状态字段必须能带来实际反馈，否则任何强制手段都撑不过一个季度。
3. 阶段门评审要开多久才合理？
我的经验值是 60 到 90 分钟。低于 45 分钟，说明评审在走过场；超过 2 小时，说明清单颗粒度太细或者参会人过多。评审前的材料预读是压缩时长的关键，我建议要求参会人提前 1 个工作日完成清单预勾选。
4. 小团队真的不需要阶段门吗？
准确地说，小团队不需要正式的评审会议，但仍然需要阶段划分和清单。区别只是形式：大团队开会评审，小团队用自检清单加一次 15 分钟的同步会。
完全不划分阶段的团队，通常在项目后期会遇到同一个问题：没人说得清“我们到底做完了哪些、还差哪些”，而这个问题的代价往往在交付前两周集中爆发。
5. 从旧系统迁移时，历史状态怎么处理？
不要试图 1:1 映射。我在 42 万条数据的迁移项目中用的方法是：先把旧状态按语义聚类，通常 20 多个旧状态会收敛成 6 到 8 类，然后对每一类指定一个目标状态。
无法归类的历史状态统一折叠为“已归档”，并在数据字典中保留映射记录，方便日后追溯。保留映射关系比追求完美映射更重要，因为它让历史数据仍然可查、可解释。
十、结语：阶段状态管理的真正价值是让风险提前可见
回到开头那个问题。9 家企业里，真正把阶段状态管理做好的只有两家，而这两家有一个共同特征：它们的项目延期并没有明显比别人少，但延期的提前量比别人多了四到六周。
这就是我认为阶段状态管理真正的价值所在，不是让项目不延期，而是让延期变成一个可以被提前讨论、提前干预、提前告知客户的事件。做不到这一点，再漂亮的仪表盘也只是装饰。
如果你准备动手，我的建议是按这个顺序推进，不要跳步：
- 本周内做一次数据体检，统计当前系统中状态超过 14 天未变更的工作项占比。这个数字通常会让你吃惊。
- 两周内完成阶段与状态的字段拆分，把混在一起的列拆成两列，阶段设成受控字段。
- 一个月内把状态压缩到 5 到 9 个，并补上“阻塞”与“挂起”。
- 一个季度内为三道关键阶段门编写检查清单，先跑起来再优化，不要追求第一版就完美。
- 半年后复盘阶段停留超期率和门禁一次通过率两个指标，用数据决定是加密还是放松阶段划分。
最后补一句我的个人判断：阶段状态管理的失败，几乎从来不是工具能力不足，而是管理层不愿意承受门禁带来的短期延期压力。工具可以采购，清单可以照抄，唯独这个取舍必须由管理者自己做出。想清楚这一点，剩下的都是执行细节。
常见问题解答（FAQ）
文章包含AI辅助创作：阶段状态管理方法大全：企业管理者项目阶段落地方案落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/332080
读者评论
作为一线研发，状态更新最大的阻力不是数量，而是填了没人处理。我们把“阻塞”单独列出来后，真正起效的是规定阻塞超过两天必须有人回应，否则周会直接过。门禁清单细化到寄存器地址听着好，但小团队维护成本很高，容易变成文档工作。我的疑问是，阶段回退有了规则后，绩效和排期是否也允许回退，不然大家还是不敢点。
从PMO角度看，阶段数量多能暴露风险，但跨硬件、软件、供应链时，统一阶段反而会打架。我们试过把阶段挂到工作项，结果校验太严，项目经理天天处理挂账，最后开始批量改阶段。更认同阶段门评审人不超过5个，但现实中评审人常由职级决定，不是由责任决定。若没有资源调配权，门禁清单再细也挡不住一句先发货。
用过几个项目管理平台后，最深的感受是状态设计别追求完整，追求可执行。我们把状态从十几个砍到6个，另用阻塞原因字段记录等谁等什么，月更新率明显回升。但标签也会泛滥，需要定期清理。阶段门通过率比百分比好，可管理层仍要一个整体进度数字，我们目前只能用通过率加权，感觉还是有点主观，想听听更实操的折中办法。