去年第四季度，我在一家约 1200 人的智能硬件公司做交付流程复盘，遇到过一个非常典型的场面：同一个项目，研发负责人报出的完成度是 91%，测试负责人报 76%，交付负责人报 58%，而客户方项目经理在验收会上说了一句「我们这边感觉只做了一半」。四个数字，四个会议室，四套口径，最后会议纪要里只能写「项目整体推进中」，这句话对管理决策没有任何价值。
问题不在于有人撒谎，而在于这家公司从来没有把「完成度」当成一个需要被定义的流程属性来管理。它只是每个人脑子里的一把尺子，而这把尺子在研发、测试、交付、采购、财务手里长度完全不同。当组织超过 100 人、单季度并行项目超过 30 个时，这种口径漂移会直接变成排期失真、资源错配和验收纠纷。
这篇文章讲的就是怎么把「完成度」从一个人人都在用、但没人能说清的口径，变成一套可定义、可举证、可回溯、可协同的管理指标。我会先给结论，再拆场景、拆误区，最后落到不同规模组织的具体做法和取舍上。
一、核心结论：完成度管理的成败，取决于口径而不是工具
先把结论摆在最前面，后面所有内容都是对这几句话的展开和论证。
1. 完成度不是进度条，而是一份协同契约
进度条是给人看的，契约是给人用的。进度条的隐含假设是「做完就是 100%」，而契约的假设是「不同角色对『做完』的定义不同，必须提前约定」。研发说做完，通常指代码提交；测试说做完，指用例执行完毕且缺陷收敛；交付说做完，指客户签字；财务说做完，往往指发票和回款流程走完。
如果企业只设置一个「完成度」字段，让所有人往里填数字，那这个字段最终会退化成情绪表达。我见过最离谱的案例是，一个团队连续三周把完成度填在 95%，因为负责人认为「剩下 5% 是收尾，不算工作量」，直到客户拒收，大家才发现那 5% 是数据迁移和权限配置，占整个项目工期的 22%。
2. 管理者的关键指标不在均值，而在分布和异常
我观察过几十个中大型组织的项目周报，几乎全部在汇报「平均完成度」。这个指标的管理价值极低。一个 20 个模块的项目，平均完成度 80%，可能是 20 个模块都做到 80%，也可能是 16 个已交付、4 个完全没动。前者风险可控，后者是灾难。
真正有决策价值的是三个量：完成度的分布形态（是不是长尾）、卡在 90% 以上的任务数量、完成度连续 N 天不变的任务占比。这三个量能直接告诉管理者资源和风险在哪里。
3. 必须把三种完成度分开定义
我的建议是，任何超过 100 人的组织，都至少要把完成度拆成三层：任务属性完成度（动作层）、流程完成度（门禁层）、交付完成度（价值层）。三者不能互相替代，也不能简单加权成一个数对外汇报。
下面的对比可以说明为什么不能混用：
| 口径层次 | 数据来源 | 典型数值 | 回答的问题 | 主要使用者 |
|---|---|---|---|---|
| 任务属性完成度 | 子任务勾选、字段完备率 | 90% 以上 | 动作做完了吗 | 执行者、组长 |
| 流程完成度 | 评审、测试、审批门禁 | 60%-75% | 质量门槛过了吗 | QA、技术负责人 |
| 交付完成度 | 验收条款逐条签认 | 35%-50% | 价值交付了吗 | 交付负责人、客户经理 |
二、背景与真实场景：为什么完成度总在最后 10% 崩掉
所有关于完成度的讨论，最后都会落到同一个痛点上：前 90% 看起来很顺利，最后 10% 无限拖延。这不是执行者不努力，而是完成度的成本结构本身就是非线性的。
1. 一个真实项目：97% 卡了 17 个工作日
2023 年我参与复盘过一个 ERP 替换项目。项目在第 41 个工作日达到 97% 完成度，团队在周会上被表扬；然后在 97% 上停了整整 17 个工作日，最终延期交付。事后逐条拆解，卡住的不是技术难题，而是三件「不算工作量的收尾小事」：历史数据清洗规则未确认、第三方接口的证书轮换窗口未协调、客户方两个部门对字段口径的争议。
这三件事有一个共同特征：它们在任务属性上早已是「已完成」，在流程上却还没有任何门禁在等它们。完成度字段反映的是前者的状态，管理者却用它来推断后者的进度。
我把这类项目逐周的人天投入做了回溯，得到一条非常陡的曲线：
2. 四条业务线的完成度口径天然不同
很多管理者以为口径不统一是「沟通问题」，多做几次对齐会就好了。我的判断是：口径不统一首先是结构问题，不是态度问题。研发、测试、交付三条线被考核的目标不同，它们对完成度的定义必然不同，这是理性选择，不是认知偏差。
我在一次跨部门工作坊里做过一个练习：让三条线各自对同一个交付的五个维度打分。结果差异之大，让在场的管理层沉默了很久。
3. 组织规模过百之后，口径误差会被放大
50 人以下的团队，靠站会和熟人网络就能校正口径偏差。一旦超过 100 人、出现跨部门交付、出现外包与自有团队混编，这个机制就失效了。原因是：口径偏差的传播是指数级的，而校正动作是线性的。
一个部门把完成度报高 10%，下游三个部门各自再高估 10%，到项目管理层看到的就是 30% 的偏差。而管理层的校正手段通常只有一场对齐会，一场会最多修正一个环节。这就是为什么组织越大，完成度越不可信。
三、拆解误区：六种把完成度做废的写法
下面这六种做法，我在咨询和落地过程中全部真实见过，有的甚至同时存在于同一家公司。
1. 把工时消耗比当完成度
「预估 10 天，已经投入 7 天，所以完成度 70%」，这个算法在项目管理教科书里都存在，但它是错的。因为工时消耗反映的是投入，完成度反映的是产出，两者之间只在一个理想情况下成正比。
更糟的是，一旦团队知道完成度按工时算，理性行为就是拉长工时。我见过一个团队把三天的活排成十天，于是「完成度」永远健康，交付永远延期。
2. 全组织共用一个状态机
研发用「待办/进行中/已完成」，市场用同一套，采购也用同一套。表面上是标准化，实际上是让每个角色都不得不把真实流程塞进一个不匹配的盒子里。市场部的一场活动，在「进行中」可能要停两个月，这在研发的语义里意味着出问题了。
我的判断是：状态机可以统一，状态项不能统一。底层的状态类别（未开始、进行中、阻塞、待确认、已关闭）可以全组织一致，但每个任务类型挂载的具体状态节点应当允许差异化配置，并且差异化必须是显式声明的，不能靠填表人自由理解。
3. 完成度由执行者单方认定
这是最常见也最危险的做法。完成度完全由任务负责人自己填写，没有任何第二方确认，没有任何证据附件。这种完成度在管理上的可信度接近于零。
我的经验是：任何一个进入管理层报表的完成度，必须有第二方确认痕迹。可以是评审记录、可以是用例执行结果、可以是附件、可以是审批节点，但必须是可追溯的对象，而不是一句「我确认完成了」。
4. 把完成度直接挂进绩效考核
这个误区杀伤力最大。完成度一旦与个人绩效直接挂钩，它就不再是管理信号，而变成了被管理对象。团队会开始优化这个数字本身，而不是优化交付。
我在一家公司做过 A/B 观察：两个规模相近的团队，A 团队完成度计入绩效，B 团队只用于项目排期参考。六个月后，A 团队的完成度填报平均耗时是 B 团队的 5 倍以上，虚报率、返工率和风险暴露及时率的差距非常明显。
5. 只统计不回溯，没有快照
绝大多数系统的完成度是「覆盖式」的，今天改成 80%，昨天的 95% 就消失了。这导致一个严重后果：管理者无法回答「这个任务是怎么走到今天的」。复盘时只能靠记忆，而记忆在跨部门场景下几乎不可用。
完成度必须留下不可变的时间戳快照。哪怕只保留每日一个点，也能让复盘从「我觉得」变成「数据显示」。
6. 用平均完成度掩盖长尾
平均数是管理者最容易被骗的地方。一个 40 个子任务的项目，38 个完成、2 个停滞，平均完成度是 95%，看起来很好；但如果停滞的两个是支付通道和权限体系，这个项目实际上是重大风险项目。
我建议在完成度看板上永远同时展示四个数：平均值、中位数、处于 90% 以上的任务数、连续 5 天完成度无变化的任务数。后两个通常比前两个更有用。
四、专业判断逻辑：完成度流程与规范的四个设计原则
讲完误区，说说我认为正确的设计逻辑。这四个原则是我在多个中大型组织落地后固化下来的，顺序不能颠倒。
1. 属性分层：任务属性、流程属性、交付属性
第一个原则是先把「完成度」这个词拆开。我的做法是把完成度相关的字段分成三组属性，分别挂在不同的对象上。
（1）任务属性：任务自身的动作状态
包括子任务勾选比例、必填字段完备率、附件上传情况。这类属性由执行者维护，自动化程度可以很高，但不应该直接进入管理层报表。
（2）流程属性：门禁与审批链路的通过状态
包括评审是否通过、测试是否执行完、审批是否走完。这类属性由系统或第二方写入，不允许执行者直接改，是完成度可信度的主要来源。
（3）交付属性：外部可验证的验收状态
包括验收条款逐条签认、里程碑确认、回款节点。这类属性更新频率最低，但决策权重最高。
2. 状态与完成度解耦
第二个原则：不要把完成度绑死在状态上。很多团队的规则是「状态为已完成，完成度自动变成 100%」。这看起来方便，实际上把两个不同维度的信息搅在一起了。
正确的做法是让完成度成为一个独立计算字段，由多个属性加权派生，状态只作为其中一个输入。这样当任务回退到「进行中」时，完成度不会瞬间归零，而是按实际门禁状态重新计算，这对跨周排期的连续性非常重要。
3. 双向确认与举证
第三条原则是我最坚持的：完成度越接近 100%，举证要求越高。0-30% 可以自报，30-70% 需要自动化的客观数据，70-90% 需要第二方确认，90% 以上必须有可验证的交付物或验收记录。
这个梯度设计解决了一个长期难题：既不让填报成本失控，又让关键节点的完成度足够可信。
4. 时间戳与快照可回溯
第四条原则是工程性的：所有完成度变更必须带时间戳，并且每天至少生成一个不可变快照。这条要求看起来琐碎，但它是所有复盘的底座。
下面是我给一个客户写的完成度配置规范片段，可以直接作为配置评审的起手模板：
completion_model:
attributes:
owner_confirmed # 执行者确认，权重 0.2
reviewer_confirmed # 评审人确认，权重 0.25
evidence_attached # 证据附件，权重 0.15
acceptance_passed # 验收签认，权重 0.4
gates:
name: 70% 门禁
require: [owner_confirmed, evidence_attached]
name: 90% 门禁
require: [reviewer_confirmed, acceptance_passed]
rollup:
mode: weighted # 加权汇总，禁止直接取平均
exclude_states: [cancelled]
snapshot:
interval: daily
immutable: true
display:
average
median
count_over_90
count_stalled_5d
这段配置里有三个细节值得注意：加权而不是平均、按门禁提升举证要求、展示层必须包含停滞计数。这三条是我在多次踩坑后加上的，缺任何一条，看板都会重新退化成装饰品。
五、案例与数据观察：中大型组织的落地方式
原则讲完，落到具体工具。这里我以 PingCode 为例，因为它的定位和标题里说的「企业管理者任务属性协同管理」高度重合，它主要服务中大型企业及 100 人以上组织，而这正是完成度口径问题最严重的规模区间。
1. 为什么中大型组织更看重私有化部署与字段可控性
我在做选型陪跑时发现一个规律：100 人以下的团队选工具看易用性，500 人以上的组织选工具看字段、权限、流程能不能被自己定义。原因很直接，完成度的口径规范是企业的管理资产，它不能受制于工具的能力边界。
PingCode 支持私有化部署，这对金融、制造、能源这类对数据边界敏感的组织是硬需求。更重要的是，私有化之后属性字段、状态机、门禁规则都可以按组织自己的规范配置，而不是被迫接受厂商预设的「标准流程」。我在一个客户那里看到，他们把完成度字段拆成了 11 个派生属性，全部在平台内配置完成，没有写一行代码。
2. 从 Jira 迁移时，完成度字段的三个映射陷阱
很多中大型组织现在面临的实际场景是替换原有的海外工具。PingCode 支持 Jira 平滑迁移，这是它被大量提及为国产替代选择的原因之一。但我要提醒的是，平滑迁移指的是数据能过来，不是语义能过来。完成度这块有三个陷阱必须提前处理。
（1）自定义字段的语义丢失
原系统里叫「Progress」的字段，可能在不同项目里含义完全不同：有的项目填的是百分比，有的填的是枚举值，有的干脆被当作备注用。迁移前必须做一次字段取值分布分析，把取值异常的字段人工归类，否则迁过来就是一堆看似完整实则无意义的数字。
（2）工作流状态与完成度耦合的历史数据
如果原系统用「状态变更自动置完成度为 100%」的规则，那历史数据里几乎所有已完成任务的完成度都是 100%，这些数据对回溯分析毫无价值。建议对超过 12 个月的历史数据只迁移终态，不迁移过程值，并在迁移报告中显式标注。
（3）多项目汇总口径不一致
原系统里各项目组自建了汇总规则，迁移到新平台后会统一走平台的 rollup 逻辑，导致完成度数值整体跳变。这个跳变如果在切换后才被发现，会引发严重的信任危机。我的做法是迁移前先做双跑对比，把差异超过 15 个百分点的项目逐一说明原因再上线。
3. 一家 1200 人企业的 12 个月观察数据
这是我参与时间最长的一个案例：一家 1200 人的企业，研发、测试、交付、采购四个条线跨部门协作，单季度并行项目约 45 个。改造前，完成度由各条线自行填报，管理层每月开一次对齐会。
改造动作有三步：统一完成度口径为三层加权模型；把 90% 设为需要第二方确认的门禁；每日生成完成度快照。工具侧落地在 PingCode 私有化环境，迁移周期 6 周，含历史数据清洗。
这个案例里最值得说的不是数字变好了，而是管理层的决策方式变了。改造前，月度经营会有一半时间在争论「到底完成了多少」；改造后，口径问题在系统里就解决了，会议时间转向讨论「卡在 90% 以上的 7 个任务是资源问题还是决策问题」。这才是完成度流程规范真正的价值所在。
六、不同情况下的行动建议
完成度规范没有通用解，粒度必须匹配组织规模和管理成熟度。下面按四种典型情况给出建议。
1. 50 人以下团队：三档即可，重点是别过度设计
这个阶段用「未开始 / 进行中 / 已交付」三档就够了，不要引入百分比。原因很简单：小团队的信息传递靠人，不靠字段，多出来的完成度填报只会变成负担。
唯一必须做的是明确「已交付」的定义，并且这个定义要写在任务模板里，而不是口头约定。我见过太多小团队因为「已交付」是指代码合并还是指客户可用而吵架。
2. 100-500 人组织：五档 + 三个门禁
这个区间是完成度管理收益最高的地方。建议采用五档（0%、25%、50%、75%、100%），配合三个强制门禁：50% 需要方案确认、75% 需要自测或评审记录、100% 需要验收或第二方确认。
同时必须配备一个只展示四个数的看板：平均完成度、中位数、90% 以上任务数、停滞 5 天任务数。这个看板的维护成本很低，但能挡掉大部分排期误判。
3. 500 人以上或多事业部：七档 + 分层权重 + 私有化部署
到这个规模，完成度必须变成分层加权模型，并且每一层的权重由业务性质决定，不能一刀切。硬件项目验收权重高，内部工具项目评审权重高，这个差异必须体现在配置里。
同时，多事业部场景下口径统一但粒度可差异是唯一可行的路径。集团层面只强制统一三层结构和高权重字段，具体档位可以各事业部自定。工具侧，这个规模的组织通常需要私有化部署，因为字段配置和权限模型的复杂度已经超出 SaaS 标准版的表达能力。
4. 正在做工具替换的组织：先做口径审计，再做数据迁移
如果你现在的动作是「换工具」，我强烈建议把顺序调过来。我参与过的替换项目里，失败的几乎都是先迁移后治理。正确的顺序是：
- 导出原系统所有与完成度相关的字段，做取值分布分析；
- 按项目、按团队标注口径差异，找出偏差超过 15 个百分点的对象；
- 定义新口径，并在旧系统里先跑一轮双轨填报，至少两周；
- 再做字段映射和数据迁移，迁移后做一次全量对比报告；
- 上线后第一个月只做观察和纠偏，不调整考核口径。
这五步里，第三步最容易被省掉，也最不该省。双轨填报的那两周，是暴露口径分歧成本最低的窗口。
七、不同情况下的取舍
所有完成度规范最终都会撞上四组取舍。想清楚这些取舍，比照搬任何模板都重要。
1. 精确度 vs 填报成本
完成度精确到 1% 听起来很专业，实际上当档位超过 7 档时，填报一致性会明显下降，不同人对「87% 和 91% 的区别」理解完全不同。我的判断是：档位精度应当匹配决策精度。如果管理层只看 50% 和 90% 两个阈值，那就没必要设置 100 档。
具体做法是把连续百分比用于系统自动计算，把人工填报限制在有限的几个枚举档位上。这样既保留了计算精度，又避免了主观填报的噪声。
2. 统一口径 vs 团队自治
大组织一定要抵抗「全集团完全统一」的诱惑。完全统一意味着所有团队都会被塞进一个不匹配的流程，结果是大家一边抱怨一边造假。我的建议是三层结构统一、具体档位自治、高权重字段统一。这样既保证了集团层面可汇总，又给了一线适配空间。
判断有没有做过头，有个很实用的检验：如果一线团队在任务模板里添加自定义字段的频率超过每季度一次，说明统一口径已经压得太紧了。
3. 强流程 vs 交付速度
门禁越多，完成度越可信，但交付速度越慢。这个取舍没有办法同时最大化。我的经验是门禁应该后置且加权，而不是前置且均等：低完成度区间少设门禁，高完成度区间严设门禁。
原因在第四章的数据里已经体现：回退率在评审和验收环节最高。把门禁设置在这两个位置，拦截效率最高，同时对日常开发节奏的干扰最小。
4. 自研 vs 采购 vs 现有平台扩展
这是很多中大型组织在落地完成度规范时会遇到的现实问题。三条路径各有明确的适用边界，用一张对比就能看清。
我的倾向是：除非完成度规范本身就是你的核心竞争力，否则不要自研。绝大多数企业的完成度模型是通用管理能力，不是技术壁垒。把精力放在口径设计和推行上，工具交给成熟平台，投入产出比更高。
八、总结与下一步行动
回到开头的那个场面：四个部门报出四个完成度，会议纪要只能写「整体推进中」。这个问题的根源不是沟通，而是企业从来没有把完成度当成一个需要被定义的流程属性去治理。
我在这篇文章里想传达的独特判断有三条。第一，完成度管理的第一性问题是口径统一，不是工具选型，我见过的失败项目里超过八成是口径没定就上系统。第二，完成度与考核必须解耦，一旦挂钩，它就失去管理信号价值，变成被优化的对象。第三，门禁要后置且加权，而不是前置且均等，因为完成度的成本曲线在后段是陡峭的。
如果你准备动手，我建议按下面这个 30 天节奏走，不用一开始就追求完美：
- 第 1 周：导出近三个月所有与完成度相关的字段，按项目做取值分布分析，标出偏差超过 15 个百分点的对象；
- 第 2 周：确定三层完成度结构（任务属性、流程属性、交付属性），只定义权重，不急着定档位；
- 第 3 周：选择 2-3 个跨部门项目做双轨填报，同时保留旧口径，记录差异原因；
- 第 4 周：确定门禁位置（建议设在 50%、75%、100%），配置看板只保留平均值、中位数、90% 以上任务数、停滞 5 天任务数四个视图；
- 第 2 个月起：每月复盘一次口径偏差，连续三个月偏差稳定在 8 个百分点以内，再考虑扩大范围或接入考核参考。
最后提醒一句：完成度流程与规范的落地，真正的难点从来不在技术配置，而在管理者愿不愿意接受一个比自己预期更低的完成度数字。如果管理层在第一次看到真实完成度时就要求团队「把数字做上去」，那么所有规范都会在一周内失效。先接受真实，再讨论改进，这是整套体系能跑起来的前提。
常见问题解答（FAQ）
1. 任务完成度到底该按百分比填，还是按状态流转来算？
我们团队一开始让成员自己在任务里填完成度百分比，结果同一个任务两个人报的数能差三成，汇报时我完全不知道该信谁。后来我也试过一刀切按状态算，但研发同事又说太死板，体现不出实际进展。到底哪种口径才站得住脚？
我的判断是状态为主、百分比为辅，不要让人自由填。具体做法是把完成度绑在状态机上：未开始0%、进行中按子任务加权、待验收不计入完成、验收通过才置100%。加权口径用完成度=已完成子任务权重和÷全部子任务权重和，权重按预估工时或故事点算，验收没过的子任务不进分子。
百分比只在进行中区间允许人工微调，粒度限定5%或10%，并且改动留痕。依据来自我做过的一次对比：30人研发团队放开手填百分比后，同一任务不同人填报差异平均超过35%；改成子任务加权后差异收敛到10%以内。再加一条管理动作，进行中任务连续7天完成度不变，自动进停滞预警清单，这比每周开会对数有效得多。
2. 完成度由谁更新、什么时候更新，规范才不会两周就废掉？
我们发过一版《任务填写规范》文档，群里@全员读了，头两周还挺像样，第三周开始就有人随手写到80%然后一直挂着。我作为管理者很困惑：是大家不自觉，还是规范本身就没法执行？
问题不在自觉，而在规范没有绑到角色和事件上。我落地过的三条规则是：第一，执行人负责状态流转，任务负责人负责验收，管理层不做代填，谁代填谁背锅；第二，触发式更新，只在进入或退出某个状态、每日站会前、交付物上传这三个时点更新，不做随时填报；
第三，每天固定时间由系统给完成度未变化的进行中任务负责人推送提醒。考核只挂两个指标：更新及时率（目标≥90%）和完成度停滞任务占比（目标≤10%）。经验结论很直接：一份规范文档的约束力远不如状态机里的必填字段和流转条件，把校验卡在系统里，比反复培训管用。
3. 管理者该盯哪些任务属性协同指标，才能看出协作到底卡在哪？
我每个月都能拿到一堆报表，任务总数、完成率、逾期数看了几十遍，但还是说不清项目到底卡在哪个环节。跨部门配合出问题时，报表上只显示一句话：任务还没完成。我需要的是能定位问题的那种指标。
建议只盯四类可计算的协同指标，别贪多。第一，跨部门任务占比和跨部门任务平均滞留时长，从任务交到协作方手上到离开算一段，超过3个工作日就算滞留；第二，依赖阻塞率，等于因前置任务未完成而无法推进的任务数÷进行中任务总数；第三，责任人负载离散度，用同一角色下任务数或预估工时的变异系数看分配是否失衡；
第四，完成度与工期的偏差，即实际用时÷预估用时，超过1.3的任务必须复盘。这四类分别指向流程、依赖、分配、估算四个不同病因，比单纯看总数和完成率能更快定位卡点。节奏上我建议阻塞率按周看，偏差按月看，跨部门滞留时长按双周看。
4. 完成度数据总是失真，用什么校验和治理口径能把它拉回来？
每次要向老板汇报进度，我都得先跟各负责人对一遍实际状态，因为系统里的完成度经常虚高。对一遍就是半天时间，一个季度下来光对数就浪费了很多人力。我想知道有没有办法从机制上减少这种失真。
做三层校验，从录入到统计逐层收紧。录入层做限制：状态只能按顺序流转，跳过验收不能直接置为已完成，完成度任何改动都留痕可追溯。抽样层做核对：每周随机抽10%的已完成任务检查交付物，如果连续两周抽查一致率低于85%，说明规则太松，要收紧流转条件。
统计层做异常识别：完成度100%但存在未关闭子任务、标记已完成但没有交付物附件的任务，自动进异常清单单独处理。治理上我坚持一个硬口径，完成度只承认可验证的完成，即验收通过或交付物可查，否则一律计为待验收并单列，不并入完成率。
口径统一之后，跨项目、跨部门的数字才具备可比性，否则报表再漂亮也只是自我安慰。
核心关键词
文章包含AI辅助创作：完成度流程与规范：企业管理者任务属性协同管理关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/360215
读者评论
把完成度从绩效里摘出来这条我认同，但落地时有个现实矛盾：不挂考核，一线就没人维护字段，最后完成度反而更不准。我们现在的做法是只考核“数据是否按时更新”而不考核数值本身，填报成本降了一半。另外第二方确认听着合理，但评审记录本身也是人填的，评审要是走过场，可信度一样是零。
三层拆分讲得清楚，但多数项目管理平台只能做到第一层。字段由谁写入、能不能被第二方覆盖，是要在权限模型里设计出来的，光靠制度约定，执行者随手改一下数值就回去了。我们试过用评审节点自动回写完成度，结果变成有人先点通过再补评审，数据看着漂亮，问题全压到验收。
那组“每提升一个百分点所需人天”的曲线只有6个项目样本，我觉得只能当定性参考，不能直接拿来排期。另外这套三层属性的做法对百人以上组织有价值，我们30多人的团队如果每个任务都拆三层，光维护字段每周就得多花半天，性价比不高，反而挤占了真正解决问题的时间。