去年年底，我接手了一个已经延期两次的跨部门项目。周会上老板问"这个项目现在完成率多少"，我脱口而出"大概65%"，结果他紧接着追问了一句："按什么算的？"我当场卡壳，因为那个65%，是我凭感觉估的。会后我花了三个小时把任务清单重新过了一遍，按任务条数算是71%，按工时加权算只有48%，按合同金额算又是53%。同一件事，三个数字，差了23个百分点。那一刻我才真正意识到：完成率从来不是"算"出来的，而是"设计"出来的。
这篇文章写给和我一样，刚带团队、刚接手项目、需要向上汇报进度，但没人系统教过你"完成率到底该怎么定"的管理者。我会把过去几年踩过的坑、纠正过的口径、以及在不同团队规模下验证过的判断框架，完整拆给你看。读完你至少能做到一件事：下次老板再问完成率，你能说出数字、说出算法、说出这个数字背后代表什么风险。
一、核心结论：完成率的本质是一套"共识机制"，不是一道数学题
先说结论，避免你在细节里迷路。
完成率的价值，90%取决于计算之前的规则设计，10%才取决于计算本身。绝大多数管理者把精力花在"怎么把数字算准"，但真正让完成率失效的，是"完成"这两个字在团队里根本没有统一定义。
我给这个结论配三个可以直接记住的判断：
- 没有验收标准的任务，完成率一定是虚高的，因为执行者会本能地把"我做了"等同于"做完了"。
- 没有基线（Baseline）的完成率，只是一个孤立的数字，它无法回答"这个进度是快了还是慢了"。
- 完成率是过程指标，不是考核指标，一旦直接绑定绩效，你收到的数字会迅速失真。
这三条不是理论，是我在带过三个不同规模团队后，用真实的翻车经验换来的。下面我逐个拆开讲。
二、背景与真实场景：为什么"完成率"这件事在管理层入门阶段最容易出错
先交代一下我的观察范围。我待过20人左右的创业团队，也在300人以上的中大型组织里带过跨部门项目。这两类场景下，"完成率"的用法完全不同，但出错的模式惊人地相似。
1. 小团队：完成率被当成"心理安慰数字"
20人团队里，任务基本靠口头同步，完成率往往是一个人在周会前一晚拍脑袋填进表格的。我最早的一份进度表里，"完成率"那一列是我按感觉填的，哪个任务看起来差不多了就标个80%，明显还没动的标个20%。这张表跑了三个月，最后没人看，因为大家都知道那列数字不准。
小团队的问题不是不会算，而是没有动力把"完成"定义清楚，因为人少、沟通快，大家觉得"反正一问就知道"。
2. 中大型组织：完成率被当成"对齐工具"，但口径常常打架
到了300人以上的组织，问题反过来了。项目涉及研发、测试、市场、供应链多个部门，每个部门都有自己的完成率口径。研发按"功能点关闭数"算，测试按"用例通过率"算，项目经理按"里程碑达成数"算。三个部门在同一个会上报三个不同的完成率，老板听完更懵。
我印象最深的一次，是一个交付项目，研发报"完成率85%"，但项目经理报"整体完成率60%"。老板当场发火，觉得有人在隐瞒。事后复盘发现，两边都没撒谎，研发算的是自己那部分的工作量，项目经理算的是端到端交付。这不是诚信问题，是口径问题。
3. 管理层入门阶段的真实痛点
把这两类场景叠起来看，刚入门的管理者通常卡在这几件事上：
- 不知道怎么定"完成"的标准，只能沿用上一任或凭直觉；
- 不知道怎么设权重，任务大小不一，按条数算明显不公平；
- 不知道怎么定基线，导致完成率没有参照系；
- 不知道怎么在周会、月报、复盘里"用"这个数字；
- 最要命的：不知道怎么避免完成率变成"数字游戏"。
这五个问题，恰好对应我下面要讲的"0→1三阶段"：定标准、算得准、用得上。
三、拆解常见误区：我把这七个坑一个不落地踩过
在讲正确做法之前，先把错误做法摆出来。这一节你如果只记一件事，就记住：大部分完成率的失真，都是管理动作本身造成的，而不是执行者故意造假。
1. 误区一：把"做了"当成"完成"
这是最高频的坑。执行者交了一份文档，但文档没经过验收；开发写完了代码，但没通过测试；市场做完了活动，但复盘没写。在这些状态下，任务在很多人心里已经"完成"了，但在项目管理意义上只能算"进行中"。如果不把"完成"锚定到"交付物+验收标准+责任人确认"这三要素上，完成率必然虚高。
2. 误区二：按任务条数算完成率
10个任务完成6个就是60%？听起来很直观，但它隐含了一个假设：每个任务一样大。现实里，一个"重构核心模块"的任务可能等于十个"改文案"的任务。按条数算，团队会本能地把大任务拆成很多小任务来刷数字，或者先做简单任务冲完成率，把硬骨头留到最后，这就是典型的"前期虚高、后期堆积"。
3. 误区三：完成率越高越好
我见过一个团队，连续三个月完成率都在95%以上，老板很满意。直到项目上线前两周，突然爆出十几个阻塞问题。复盘才发现，团队一直在做容易量化的任务，关键路径上的难题被反复推迟。完成率高，只说明"做的事都做完了"，不说明"该做的事做对了"。完成率必须和进度偏差、关键路径一起看。
4. 误区四：口径混用
同一个项目里，有人按数量、有人按工时、有人按金额，汇报时拼在一起，谁也不知道总数怎么来的。口径混用的直接后果是数字不可比、趋势不可读、预警不可信。
5. 误区五：只算不析
完成率数字出来了，然后呢？很多管理者把完成率当成一个"填表动作"，算完就贴到周报里，从不追问"哪个环节拖累了整体""下阶段瓶颈在哪"。这种完成率，只是负担，不是工具。
6. 误区六：忽略任务依赖
完成率是按任务算的，但任务之间是有依赖的。A完成了、B完成了，但C卡在A和B之间无法启动，这时候算出来的完成率会让人误以为"进度很健康"。忽略依赖关系，等于把项目进度当成了一个无序的任务池。
7. 误区七：把完成率绑到绩效考核上
这是最危险的一条。一旦完成率直接影响个人奖金，你会立刻收到大量"凑数完成"和"虚报进度"。我在一个团队里试过把完成率纳入月度考核，第一个月数字很美，第二个月开始出现大量"形式上完成但质量不达标"的交付，第三个月我主动取消了这个考核项。完成率可以用来暴露问题，但不能用来打分。
四、专业判断逻辑：完成率"0→1"三阶段设计法
讲完误区，进入正题。我用的框架叫"定标准 → 算得准 → 用得上"，三个阶段，缺一不可，顺序也不能颠倒。很多团队一上来就想"换个工具算准数字"，但如果标准没定，换什么工具都是错的。
1. 阶段0：先定义"完成"，再谈完成率
"完成"这个词，必须先落成三件具体的事：
- 交付物：任务结束时，具体交付出什么东西（代码合并、文档链接、验收报告、上线记录）；
- 验收标准：谁、按什么规则、判断这个交付物合格；
- 责任人：谁有权宣布"这个任务完成"。
缺任何一条，"完成"就成了主观词。我的做法是：让团队一起列出所有任务的"完成定义"，写在任务卡里，谁也别口头改。这一步听起来笨，但它能干掉80%的争议。有一次我们给"用户调研报告"定义完成标准是"访谈不少于8位目标用户、输出问题清单、结论经过产品负责人签收"，之后这份报告再也没出现过"做完了但没人认"的情况。
再讲两种主流口径的适用边界：
| 口径类型 | 算法 | 适用场景 | 主要风险 |
|---|---|---|---|
| 数量口径 | 已完成任务数 ÷ 总任务数 | 任务颗粒度均匀、以流程性事务为主（如运维工单、审核任务） | 大任务被拆碎刷数，掩盖关键路径 |
| 权重口径 | Σ已完成任务权重 ÷ Σ总任务权重 | 任务体量差异大、跨职能项目（如产品研发、交付项目） | 权重拍脑袋定，缺乏校准机制 |
| 金额/合同口径 | 已完成部分合同金额 ÷ 总合同金额 | 外包、工程、咨询服务等有明确结算结构的项目 | 前期金额确认滞后，完成率更新迟缓 |
我的一般建议是：项目型工作用权重口径，运营型工作用数量口径，商务/交付类项目叠加金额口径做交叉验证。不要三种混着用一个数字，会乱。
2. 阶段1：算得准，权重、基线、更新频率三件事
口径定了，接下来是三个把数字"钉死"的机制。
（1）权重怎么设。权重不是拍脑袋，至少有三种可解释的设定依据：按工作量（人天估算）、按关键路径（关键路径上的任务权重高）、按合同金额（金额即权重）。我在实际项目里通常用"工作量为主、关键路径加权"的组合，关键路径上的任务在原有工作量权重上乘1.2~1.5。这样做的结果是，完成率对关键路径的变化更敏感，避免了"做了一堆边角任务，关键节点纹丝不动"的假繁荣。
（2）基线怎么定。基线就是"我们原本计划在第X周完成到Y%"。没有基线，完成率只是一个孤数，说不出好坏。基线应该在项目启动时就冻结，中途如需调整必须以书面形式记录变更原因。允许改基线，但每一次改都要留痕，否则基线会变成"随时能改的心理安慰"。
（3）更新频率怎么定。日报、周报、里程碑节点各有适用场景：短周期交付任务用日报或双日报；常规项目用周报；长周期、跨季度项目必须额外设里程碑快照点。我踩过的坑是：一个四个月的交付项目只按周报更新完成率，等发现偏差时已经累积到无法挽回。后来我们在每个月末加了一个"里程碑快照"，把完成率和基线偏差一起存档，偏差趋势立刻变得可见。
3. 阶段2：用得上，管理层真正用完成率做三件事
算准只是起点，完成率的真正价值在于它触发什么管理动作。我判断一个团队完成率是否"用得对"，只看它能否回答三个问题：预警、调配、汇报。
（1）预警。完成率有两种"危险信号"要区分对待：一种是停滞（连续两个周期几乎不动），通常意味着资源卡点或需求模糊；另一种是虚高（数字漂亮但交付物迟迟不落地），往往是执行者在美化数字。两种信号的处理方式完全不同，前者要疏通，后者要核实。
（2）资源调配。完成率拆解到模块后，能直接回答"钱和人该往哪加"。如果一个模块完成率长期低于整体完成率10个百分点以上，且权重高、在关键路径上，那就是优先补资源的对象。这比开会拍脑袋"大家多加点班"有效得多。
（3）向上汇报。对上级汇报时，完成率不能是孤数，而应该是"完成率 + 基线偏差 + 关键路径状态"三件套。这样向上沟通时，你既没有甩锅，也没有背锅，因为数字说清楚了问题在哪、你在做什么、需要什么支持。
4. 工具的角色：让规则落地，而不是替你做规则
很多管理者一上来就找工具，我的顺序恰好相反，先有规则，再用工具固化规则。工具能帮你的，是把"完成定义""权重方案""基线快照""依赖关系"这些规则结构化、可视化、可追溯。
我自己在中大型组织（100人以上、跨部门协作、有私有化部署要求）场景下，用 PingCode 这类项目管理平台做过完整落地。原因是它天然支持工作项类型自定义、字段级权限、私有化部署，也能通过迁移工具从 Jira 迁过来，这对国产替代或数据合规有要求的企业很关键。但我必须强调：工具永远只是规则落地的手段，不是规则本身。我见过团队换了三个工具，完成率依然算不准，因为他们的"完成定义"从来没对齐过。
五、案例与数据观察：一次真实的"完成率重构"全过程
下面讲一个我亲手操作的案例，全程大约两个月，可以作为你复刻的模板。
1. 项目背景
这是一家300人左右的制造+软件混合型企业的数字化交付项目，参与方包括研发、实施、客户成功三个部门，周期原计划16周。我介入时项目已经延期两次，完成率数字在各部门之间差得离谱：研发报71%，实施报58%，客户成功报45%。
我做的第一件事，是把三份"完成率"的明细摊在一张表上，按任务逐条对齐。结果发现三个部门的差异，一半来自口径不同，一半来自对"完成"的理解不同。
2. 第一阶段动作：统一"完成定义"（耗时约1周）
我组织了两次跨部门工作坊，把项目里所有任务分成四类：需求类、开发类、实施类、验收类。每类给一条"完成必须满足的全部条件"。举例：
- 开发类任务完成的三个条件：代码合并到主干、通过约定的自动化测试、相关文档更新完毕；
- 实施类任务完成的三个条件：客户环境部署完毕、客户方对接人确认签字、实施记录归档；
- 验收类任务完成的三个条件：验收清单全项通过、遗留问题有书面处置方案、验收报告归档。
这一步做完，三个部门的完成率首次变得可比。
3. 第二阶段动作：设权重与基线（耗时约1周）
我们按"工作量为主、关键路径加权1.3倍"的方式设定权重，用过去类似项目的数据做校准。基线在项目重新启动时冻结，记录在系统里，后续任何调整都需走变更流程。
这里我把所有任务的"完成定义"和"权重依据"都落进了 PingCode 的工作项类型和自定义字段里，好处是执行者在更新状态时会被字段约束，不能随手勾"完成"。这一步的副作用是初期有人抱怨"太麻烦"，但两周后抱怨消失，因为大家对数字的信任度上来了。
4. 第三阶段动作：按周报+里程碑快照更新（持续8周）
我们建立了双节奏：每周五更新一次完成率，每月末做一次里程碑快照存档。快照里同时记录：完成率、基线偏差、关键路径节点状态、风险项数量。
下面这张图是我们八周里记录的真实完成率与基线偏差对比数据（口径：工作量加权 + 关键路径1.3倍加权）：
5. 结果与复盘
项目最终在第17周完成交付，比原计划多1周，比延期两次后的最新预测提前了3周。真正的收获不是提前3周，而是整个过程中完成率第一次成为团队共同信任的数字，周会上没人再问"这个数字怎么来的"。
复盘下来，投入产出比最划算的三件事是：统一"完成定义"、冻结基线、每月一次里程碑快照。最不划算的一件事是：我们花了两周纠结工具选型，其实规则没定之前，工具再好也白搭。
六、不同情况下的行动建议：按团队规模与项目类型分场景给你操作路径
框架讲完了，但不同团队落地路径不一样。我按四种典型情况给你具体动作。
1. 场景A：20人以下小团队，第一次系统做完成率
别一上来搞复杂。先做三件事：
- 选出你们最痛的三个任务类型，为每类写一条"完成三要素"；
- 用最简数量口径先跑两周，不要用权重，减少理解成本；
- 每周固定一次10分钟对齐会，只看完成率和阻塞项。
三周后你就会发现，即使是最简单的口径，只要"完成定义"清楚，完成率就能立刻可用。
2. 场景B：50-100人团队，跨部门协作开始变多
这个阶段的关键动作是先统一口径，再谈工具。具体三步：
- 找三个部门一起开一次口径对齐会，把各自的完成率算法写在白板上，逐条对比；
- 选一个共同口径作为"对外唯一口径"，部门内部可以保留细分口径，但对外只报一个；
- 建立一份"完成定义词典"，所有任务类型都能在其中找到完成标准。
3. 场景C：100人以上组织，有私有化/合规要求
这个阶段，规则之外还要考虑工具承载能力。任务量级、跨部门视图、权限隔离、数据合规、是否支持私有化部署、能否从现有系统平滑迁移，都会影响落地成本。
我自己在中大型企业场景下，会优先看支持私有化部署、权限模型细、能从主流系统（如 Jira）平滑迁移的平台。PingCode 是我在实际项目中用过并验证过的一类选择，它面向的正是100人以上、跨职能协作复杂、对数据主权有要求的中大型组织。但我要再强调一次：先定规则，再选平台，反过来一定会翻车。
4. 场景D：项目已经延期，需要"救火"
这种情况不要再从头搭体系，就做两件事：
- 把现有关键任务全部重新过一遍"完成定义"，把虚高的任务拉回真实状态；
- 冻结当前基线，按周为单位重新设一个短期目标完成率，只盯关键路径。
救火阶段，完成率不需要完美，只需要让你在两周内知道"问题到底卡在哪"。
七、不同情况下的取舍：哪些能做，哪些必须放弃
管理里最难的往往不是"做什么"，而是"不做什么"。完成率这件事上有几组取舍，我踩过坑，给你参考。
1. 取舍一：精确 vs 可用
追求100%精确的完成率，成本极高且意义有限。我的原则是：完成率精确度达到"能支持决策"的程度即可，不必追求会计级精度。比如，权重用近似估算就够用，不必为每个任务做详细的工时审计。把省下来的时间花在"用完成率做预警和调配"上，价值更高。
2. 取舍二：统一口径 vs 保留细分口径
要不要所有部门口径完全统一？我的建议是：对外统一，对内保留细分。对外汇报，必须有一个公认的口径，否则外部无法解读；但内部执行层面，不同职能保留细分的完成率是必要的，因为它们的工艺不同。关键是明确"哪个口径用于对外、哪个用于内部管理"。
3. 取舍三：完成率纳入考核 vs 不纳入考核
我明确建议不把完成率直接纳入绩效打分。可以用它做过程预警、复盘素材、能力评估的辅助信息，但一旦绑定奖金，数字就会失真。如果一定要用，请配合"质量复核"和"验收签字"双重校验。
4. 取舍四：工具定制 vs 使用标准功能
有些团队一上来就追求高度定制的完成率视图，结果维护成本极高。我的建议是：优先用平台的标准字段和标准视图跑通流程，跑通后再做少量必要定制。这也是我在实际落地 PingCode 时的做法，先用它内置的工作项、迭代、里程碑视图跑完整流程，两三个月后再根据数据反馈调整字段和视图，避免一开始就陷入定制泥潭。
5. 取舍五：追求趋势 vs 追求单点精度
完成率的价值主要在趋势里，不在单点精度里。如果你只能在两者里选一个，永远选趋势。每周更新一次、连续八周的完成率曲线，比某一次精确到小数点的完成率更有管理价值。
八、一张自查清单：你的完成率能回答这五个问题吗？
看完上面的内容，你可以用下面这份清单自查。五个问题，能答上三个以上，说明你的完成率已经进入"能用"的阶段。
| 编号 | 自查问题 | 答不上来意味着什么 |
|---|---|---|
| 1 | 你团队里"完成"的定义是书面化的吗？ | 完成定义缺失，完成率必然虚高 |
| 2 | 你用的是哪种口径？为什么？ | 口径靠惯性，切换场景时会翻车 |
| 3 | 你有冻结的基线吗？改动是否留痕？ | 完成率是孤数，无法判断快慢 |
| 4 | 出现停滞或虚高时，你能指出具体模块吗？ | 完成率停留在总览层，无法驱动管理动作 |
| 5 | 完成率有没有被直接绑定到个人考核？ | 如有绑定，数字可信度将迅速下降 |
如果五个问题里你有三个以上答不上来，不要急着换工具。先把"完成定义"和"基线"这两件事做完，你的完成率至少能立刻提升一个可用级别。
九、从下一个项目开始：给你的最小启动动作
完成率这件事，最怕的就是"知道要做但一直没开始"。所以最后我只给你一个最小启动动作，
在下一次项目启动会前，花30分钟，和团队一起为最重要的三类任务，各写一条"完成三要素"（交付物、验收标准、责任人）。然后在系统里冻结一个基线，选一个口径（推荐权重口径）。跑两周，做一次复盘，看完成率能不能回答前面那张自查表的五个问题。
两周后你会得到两个明确的判断：一是完成率数字是否可信；二是你的团队是否真的准备好了用这个数字做管理。这两个判断，比任何模板都值钱。完成率不是一道算术题，它是你和团队之间关于"什么叫做完了"的一场持续对话。
如果你愿意，可以在评论里说说你们团队现在按什么口径算完成率、遇到过哪种失真场景。我会挑几类典型问题，后续再拆一篇具体的口径校准案例。
常见问题解答（FAQ）
1. 完成率到底该按任务数量算，还是按工作量权重算？
我刚接手一个跨部门项目，周会上老板问完成率多少，我脱口而出60%，结果被追问按什么算的，我一下答不上来。后来发现按任务条数算是60%，按实际工时投入算只有35%，两个数字差了一倍，我到底该报哪个？
两个口径都对，关键看你要回答什么问题。数量口径等于已完成任务数除以总任务数，优点是简单直观、团队一眼能懂，缺点是会把‘改一个文案’和‘重构一个模块’算成同等份量，适合任务颗粒度均匀、周期短的项目，比如活动执行、内容排期。
权重口径是先给每个任务标权重（按预估工时、合同金额或关键路径影响度），再算已完成权重之和除以总权重，适合研发、工程、交付类项目，因为任务体量差异大。实操建议是：对外汇报用权重口径，因为它更接近真实进度；对内站会用数量口径做辅助，因为它能快速暴露‘哪些卡住了’。
但无论用哪个，必须在项目启动时就把口径写进进度表抬头，并且全周期不改，否则前后两周的数字没有可比性。判断依据很简单：如果你报的完成率下降，但团队感觉没退步，大概率是口径混用了。
2. 完成率多少算正常？有没有一个行业通用的及格线？
我们项目现在完成率72%，老板说太低了，但隔壁组58%老板却说还行。我特别困惑，到底多少算正常？是不是有什么我不知道的行业标准？
没有任何通用及格线，完成率必须和基线、时间点绑定才有意义。正确的判断方式是看‘计划完成率’和‘实际完成率’的差值：如果项目进行到一半，计划完成率应该是50%，你实际72%，说明超前，健康；如果计划完成率是80%，你实际72%，说明滞后8个百分点，这才叫危险信号。
所以老板说58%还行，很可能是因为那个项目刚启动三周，58%已经超预期。你可以做一个简单的进度偏差表：计划完成率、实际完成率、偏差值三列，每周更新。偏差在正负5个百分点内属于正常波动，连续两周负偏差超过10个百分点就必须预警。
另外提醒一点，完成率在项目前期天然容易偏高（因为简单任务先做完了），后期容易停滞（难啃的骨头都在后面），所以单看某一个时间点的绝对值意义不大，趋势比数值重要。你要做的不是找及格线，而是和老板对齐基线。
3. 小团队没有专业工具，用Excel怎么做完成率跟踪？
我们团队就七八个人，预算有限，也没人会用复杂的项目管理软件。我一直用Excel手动更新进度，但每次算完成率都要重新拉一遍数据，特别容易出错，有没有简单靠谱的做法？
Excel完全可以做，核心是把‘完成标准’和‘权重’两列先固定下来，后面就只是更新状态。具体做法：建一张表，列分别是任务名称、负责人、权重（按预估天数或难度打1到5分）、计划完成时间、实际状态（未开始填0、进行中填0.5、已完成填1）、加权得分（权重乘以实际状态）。
完成率就等于所有加权得分之和除以权重总和。关键动作有三个：第一，状态只允许填0、0.5、1三个值，不准填‘差不多完成了’这种模糊描述，否则完成率会失真；第二，每周固定时间更新一次，不要每天改，频繁更新会让团队把精力花在填表上而不是干活上；第三，加一列‘上周完成率’，用本周减上周看变化趋势。
这套表七八个人用完全够，十分钟能更新完。什么时候该换工具？当你的任务超过一百条、或者需要多人同时编辑、或者需要看任务之间的依赖关系时，Excel就开始吃力了，那时候再考虑上某项目管理平台或某项目管理工具也不迟。
4. 把完成率直接写进KPI考核，为什么团队反而开始虚报进度？
我们公司去年把项目完成率和绩效奖金挂钩，结果发现大家报上来的完成率都很好看，但项目实际交付还是延期。我作为管理者特别头疼，明明数据在涨，为什么结果没变好？
这是完成率被误用的典型症状。完成率本质是一个过程指标，它衡量的是‘做了多少’，而不是‘做对了多少’和‘能不能交付’。一旦和奖金挂钩，理性人的选择就是先做容易的任务把数字冲上去，把难啃的模块往后拖，甚至把‘做了一半’报成‘已完成’。
有三个可执行的修正办法：第一，完成率只用于内部预警和资源调配，不直接算奖金，奖金和里程碑交付质量、验收通过率挂钩；第二，增加‘完成定义’的硬约束，每个任务必须附交付物链接或验收人签字才算完成，口说完成无效；第三，引入反向指标，比如返工率、延期任务占比，如果完成率涨了但返工率也涨了，说明数字是虚的。
判断依据很直接：健康的项目，完成率上升应该伴随着未完成任务数的下降；如果完成率上升但剩余任务数没怎么变，大概率有人在凑数。你要做的不是取消考核，而是换一个更难被操纵的指标组合。
核心关键词
文章包含AI辅助创作：完成率怎么做？管理层入门指南：进度管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/463619
读者评论
把“完成”定义清楚这一点太真实了。我们团队之前完成率一直虚高，后来要求每个任务必须写清交付物和验收人，数字立刻掉了一截，但反而能看出真实进度了。
按条数算完成率确实坑，我们做研发项目时十个改文案的任务等于一个核心模块重构，按条数永远好看，关键路径却一直不动，后来改成按工时加权才暴露问题。
把完成率绑绩效考核这条我深有体会。之前公司搞月度排名，结果第二个月开始全是形式完成的假交付，数据完全没法信，取消之后才慢慢恢复真实汇报。