2023 年我接手一个 320 人研发组织的效能治理项目时，第一眼看到的月度报表上写着"任务按期完成率 91%"。同一周的产研例会上，三个业务线负责人都在抱怨交付积压。我没有急着质疑报表，而是花了十一天，把散落在需求池、缺陷跟踪、运维工单、会议纪要、企业 IM、邮件和两套历史遗留系统里的任务记录全部拉出来，按"同一份可交付成果"做了一次人工比对。结果是：报表里 91% 的完成率所覆盖的记录中，约 37% 与另一条记录指向同一件实际工作。
这不是工具的问题，也不是一线造假。这是任务管理从 0 到 1 建设过程中一个几乎必然出现、却很少被单独拿出来讨论的环节，任务合并。它介于"记录任务"和"分析任务"之间，做不好，后面所有的工时统计、吞吐量分析、交付预测、资源负载判断都会系统性失真。
这篇文章我想把任务合并这件事讲透：为什么它必须先做、常见的做法错在哪、判断标准怎么定、不同规模的组织该怎么落地。文章里的数据来自我参与过的四个组织样本（120 人到 1400 人），以及 2024 年我对 26 名研发管理者的访谈记录，其中部分数字为了脱敏做了区间化处理，我会在涉及处标注口径。
一、核心结论：任务合并的三条铁律
先给结论，后面所有内容都是围绕这三条展开的论证和操作细节。
1. 粒度统一必须先于合并动作
大多数团队一上来就问"怎么把重复任务合掉"，这个问法本身就错了。合并的前提是你能判断两条记录是不是同一件事，而判断同一件事的前提是你们对"一个任务"的粒度有共识。
我见过一个团队，需求侧把"用户登录模块重构"当成一个任务，开发侧拆成了 7 个任务，测试侧拆成 3 个用例集对应的 3 个任务。这种情况下谈合并毫无意义，因为它们本来就不是同一个粒度层级。正确顺序是：先定义粒度标准，再定义合并规则，最后才是执行合并。
2. 合并必须保留溯源链路，而不是删除记录
我坚持一个原则：合并的结果应该是"多条记录收敛为一条主干 + 若干条带标记的来源记录"，而不是"删掉多余的"。原因很实际，半年后审计、复盘、绩效申诉、客户追溯时，你需要回答"这条需求最早的提出时间是什么""谁在什么时间点改过验收标准"。
物理删除带来的信息损失是不可逆的。我在一个金融行业客户那里见过因为删除了原始工单记录，导致一次合规审计多花了 3 周时间做人工还原，直接成本超过 40 人天。
3. 合并是常态机制，不是一次性运动
最典型的失败模式是"治理突击月"：集中两周，全员停下手上活清理重复任务，清理完发个公告，然后三个月后重复率回到原来的 80%。因为任务重复的根源是"多入口创建 + 多角色转译"，这两个条件不消失，重复就会持续产生。
真正有效的做法是把合并能力嵌进日常流程：新建时自动查重提示、每周固定 30 分钟由模块负责人做一次同源检查、每月做一次跨系统对账。我后面会给出具体的节奏设计。
二、任务重复从哪里来：四类真实来源场景
不理解重复的来源，就无法设计合并规则。我把观察到的重复来源归为四类，这四类的处理方式完全不同。
1. 多入口创建导致的同源重复
这是最常见的一类。同一件事可能从需求池进来一条、从客户反馈系统进来一条、从运维工单转过来一条、从销售在 IM 里@产品经理转手建一条。
在一个 480 人规模的样本里，我统计过某个季度新增的 11400 条任务记录，其中明确来自两个及以上入口的占 31%。更麻烦的是这些记录的标题往往不一样：需求池那条叫"支持批量导入订单"，客户反馈那条叫"客户 A 反馈导入太慢"，运维工单那条叫"订单模块性能优化"。
2. 跨角色转译导致的语义漂移
产品经理写的是业务价值，开发写的是技术动作，测试写的是验证场景。这三条记录在语义上指向同一件事，但字面几乎不重合。这类重复最难用规则识别，也最容易在自动合并时被误判。
我做过一个对照实验：用标题相似度阈值 0.7 去匹配一个 800 条记录的样本，召回了 41% 的真实同源记录，但同时产生了 17% 的误合并，把"订单导出优化"和"订单导入优化"合到了一起，这两个改动方向几乎相反。
3. 会议与口头指令的落地缺口
评审会、站会、专项会上确定的事情，如果没有当场落到系统里，通常会由两到三个人分别"记一下"，然后各建一条。这类重复在时间上高度集中，往往出现在会议后 24 小时内。
我统计过一个 12 人小组，一次为期 90 分钟的需求评审会后，产生了 9 条任务记录，实际对应的独立工作只有 4 件，重复率超过 55%。
4. 工具迁移与历史遗留的断层
从一套系统迁到另一套系统时，如果迁移策略是"全量导入"，历史数据里的重复会被完整带过来。我在一个从海外工具迁移到国内平台的案例中看到，迁移后的任务总量比迁移前实际有效工作量高出 2.4 倍。迁移不是复制粘贴，迁移本身就是一次最好的合并窗口。
三、六种看起来正确、实际会反噬的做法
下面六种做法我在不同团队都见过，它们都有合理的外表，但都在某个环节上出了结构性错误。
1. 用标题相似度做自动合并
这是最容易想到、也最容易出事的方法。标题相似度可以处理"同一个入口重复提交"这类场景，但对跨角色转译基本无效，同时会产生可观的误合并。
更稳妥的分工是：自动规则只负责"提示候选"，人工负责"确认执行"。系统给出"这 3 条可能是同一件事"的提示，准确率只要到 70%，就能把人工发现重复的效率提升数倍，同时不会造成误伤。
2. 合并即删除原记录
我前面已经说过溯源问题，这里补充一个更隐蔽的代价：删除会破坏历史统计数据的时间连续性。你三个月后想分析"需求从提出到交付的平均周期"，如果原始提出记录被删了，起始时间点就永久丢失了。
正确做法是"标记而非删除"：原记录保留，状态改为"已合并"，并通过关联字段指向主干任务。这样统计时按主干去重，追溯时能回到源头。
3. 搞一次性大扫除
治理突击的问题是它把成本集中到某个时间点，同时制造了巨大的心理抵抗。一线会觉得"又来折腾我们"，而且集中清理时判断质量普遍偏低，因为时间压力下人会倾向于快速点过。
我的做法是把合并成本摊薄：新建时查重（成本几乎为零）、每周模块级巡检（每次 30 分钟）、每月跨系统对账（每次 2 到 3 小时）。总量不变，但每次的决策质量高得多。
4. 只合并任务，不合并口径
这是一个非常典型的隐形坑。你把重复任务合掉了，但"完成"的定义在不同团队还是不一样：有的团队"代码合并"就算完成，有的要"测试通过"，有的要"上线验证"。合并后报表数字好看了，但可比性没有提升。
任务合并和口径统一必须同期进行。我的经验是，合并规则里至少要包含状态映射表：源系统的哪些状态对应主干任务的"进行中"，哪些对应"已完成"。
5. 让一线自证"我这条不重复"
把所有判断责任推给创建者，会导致两种结果：要么一线为了免责把明显重复的也保留，要么为了省事把不该合的也合了。判断重复需要跨模块视野，而一线通常只有局部视野。
合理的分工是：系统提供候选、模块负责人做判断、PMO 做规则维护和抽样复核。三层各司其职。
6. 把"合并率"做成考核指标
这是我见过代价最大的一个错误。一旦合并率进考核，就会有人为了数字去合并本来不该合并的记录，或者把子任务强行挂到父任务上来"减少"任务数。
我在一个团队见过这种情况：为了达成季度"任务条目精简 30%"的目标，某个小组把 12 个独立的优化项打包成一个"性能优化专项"任务。结果三个月后没人说得清这个专项里到底做了哪些事，复盘完全失效。
应该考核的是数据可信度相关的指标，比如报表抽查一致率、跨系统对账差异率，而不是合并动作本身的数量。
四、专业判断逻辑：什么该合、什么不该合
这一节是我认为整篇文章最有价值的部分。合并的难点不在操作，在判断。
1. 三个核心判据
当两条记录同时满足以下三条时，可以合并；只满足一条或两条时，应当保留为关联关系而不是合并。
（1）同一可交付成果
问一个具体问题：这活干完之后，交付的是什么？如果两条记录交付的是同一个可验收的东西，判据一成立。如果一条交付的是代码模块，另一条交付的是运维手册，即使它们由同一次改动产生，也不应该合并。
（2）同一验收标准
验收标准是判断同源性的关键。我见过太多"看起来一样、验收标准完全不同"的案例。比如两条都叫"优化搜索"，一条的验收是"响应时间从 800ms 降到 300ms"，另一条的验收是"支持按标签组合筛选"。这两个是不同工作。
（3）同一责任人与同一时间窗口
如果两条记录的责任人不同，合并会直接破坏责任归属，导致后续谁都不认领。如果时间窗口相差超过一个迭代周期，通常说明这不是同一次工作，而是两次独立的需求。
三条判据都通过，执行合并；只通过判据一，建立关联关系；一条都不通过，不做任何操作。
2. 三种合并层级及各自代价
合并不是一个动作，而是三个可选层级，选错层级带来的代价差异极大。
| 合并层级 | 操作方式 | 溯源完整性 | 一线操作成本 | 报表一致性 | 适用场景 |
|---|---|---|---|---|---|
| 物理合并 | 多条记录合并为一条，原始记录删除或归档 | 低（需额外归档机制） | 低 | 高 | 明确误提交、测试数据、重复提交 |
| 逻辑合并 | 保留全部记录，通过父子或关联关系建立主干 | 高 | 中（需维护关联字段） | 中（依赖报表聚合逻辑） | 跨角色转译、跨系统来源 |
| 视图合并 | 底层数据不动，在分析层按规则聚合展示 | 最高 | 低（对一线无感） | 高（但仅限特定报表） | 管理层看板、跨部门汇报 |
我的推荐组合是：底层用逻辑合并保溯源，展示层用视图合并保一致，物理合并只用于处理明确的垃圾数据。很多团队一上来就选物理合并，后来想追溯历史时才发现无从下手。
3. 决策路径
把上面的判据串起来，形成一条可执行的判断路径。我在团队里推行的版本是这样的：
- 系统自动扫描近 30 天内标题或关键词相似度超过阈值的记录，生成候选组
- 候选组交由模块负责人做第一轮人工判断，按三条判据逐条打勾
- 三条全过的进入合并队列，由 PMO 做第二轮抽样复核（抽样比例 30%）
- 复核通过的执行合并，同时生成来源映射记录
- 只过判据一的，建立关联关系，不合并
- 每月做一次合并结果的回溯检查，重点看有没有误合并导致的返工
这套流程在 320 人组织里跑通后，单个模块的周巡检时间稳定在 25 到 35 分钟，没有成为额外负担。
五、以 PingCode 为例：任务合并的落地实现
前面讲的是方法论，这一节讲具体怎么用工具承载。我以 PingCode 为例，原因很直接：PingCode 主要服务中大型企业及 100 人以上组织，这类组织的任务重复问题最复杂，也最需要结构化的合并能力。
1. 工作项类型与粒度定义
落地第一步不是配合并规则，而是把工作项类型理清楚。在 PingCode 里，需求、任务、缺陷、测试用例是不同类型的工作项，这个区分本身就是防止重复的第一道防线。
我的做法是要求团队在建单时就明确"这是需求还是任务"。需求描述业务价值，任务描述可执行动作，缺陷描述偏差。这个看似简单的约束，能消掉我前面说的"跨角色转译重复"里相当一部分。
（1）自定义字段承载合并元数据
我在实践中会加几个自定义字段：来源系统、来源单号、主干工作项、合并批次。前两个用于追溯，第三个用于建立主干关系，第四个用于批量回溯。这四个字段加起来，就让逻辑合并变得可执行、可审计。
（2）粒度标准的落地方式
粒度标准不能只写在文档里。我会把它做成一个必填的字段"预计交付物"，要求用一句话描述完成后交付什么。这句话写得出来，粒度基本就是合适的；写不出来，说明任务太虚或者太大。
2. 关联关系与溯源链路
PingCode 支持工作项之间的关联关系配置，这是逻辑合并的技术基础。我的配置习惯是：主干任务与来源记录之间建立"由…分解"或"关联"关系，而不是把来源记录挂成子任务。
区别在于：子任务会被计入工作量统计，而关联关系不会。如果来源记录本身不是独立工作量，把它挂成子任务会造成工时重复计算，等于把你刚合掉的重复又从另一个口径漏了回来。
3. 自动化规则降低人工负担
人工巡检的可持续性依赖自动化兜底。我通常配三类自动化规则：
- 新建查重提示：新建工作项时，如果标题关键词与近 30 天内的记录高度重合，自动提示"可能存在同源记录，请先确认"，并列出候选
- 跨系统字段同步：来源系统、来源单号自动从集成接口带入，避免人工填写遗漏
- 超期未关联提醒：状态为"进行中"但 14 天未建立任何关联关系的工作项，自动提醒负责人确认是否需要建立主干关系
这三条规则的成本很低，但覆盖了我前面统计的四类重复来源中的三类。
4. Jira 平滑迁移：把迁移当成一次合并窗口
很多中大型组织在国产化替代过程中会面临从 Jira 迁移的问题。PingCode 支持 Jira 平滑迁移，这是它的一个明确优势。但我要强调一个判断：迁移不是数据搬运，而是一次不可多得的历史数据治理机会。
我的建议是分三步走：第一步，全量迁移但打上迁移批次标记；第二步，对迁移数据做一次专项查重，把历史重复归并；第三步，把归并结果与新建数据做口径对齐。如果直接全量导入就完事，你会发现迁移后第一个月的报表数字会明显"变好"，不是因为效率提升了，是因为历史重复把分母撑大了。
5. 私有化部署带来的数据治理空间
PingCode 支持私有化部署，这对数据敏感型组织很关键。我在做任务治理时经常需要把任务数据与其他系统（工时系统、绩效系统、客户系统）做交叉对账，如果数据出不了内网，这件事的可行性会大打折扣。私有化部署让跨系统的数据对账和口径校验可以在合规前提下完成。
另外，私有化环境下的数据保留策略更可控。前面说合并要保溯源，如果数据保留周期受外部限制，溯源链路就断了。这一点在选型时容易被忽略，但在真实治理中很重要。
六、不同情况下的行动建议
同样的方法论，在不同规模、不同成熟度的组织里，落地路径差别很大。我按四个区间给出建议。
1. 50 人以下团队
这个规模下不要搞复杂机制。我的建议只有三条：
- 收敛入口，最多保留两个任务创建入口，其他渠道统一走其中一个
- 每周站会后花 10 分钟做一次快速对账，由团队负责人执行
- 不建主干关系，直接口头确认后合并，因为人少，上下文丢失风险低
这个规模的核心矛盾是产出效率，不是数据精度。过度治理的伤害大于收益。
2. 50 到 200 人组织
这个区间是任务重复开始明显影响报表的阶段，需要引入结构化机制，但仍要保持轻量。
| 动作 | 频率 | 负责人 | 单次耗时 |
|---|---|---|---|
| 新建查重提示规则维护 | 每季度一次 | PMO | 2 小时 |
| 模块级任务巡检 | 每周一次 | 模块负责人 | 20-30 分钟 |
| 跨系统数据对账 | 每月一次 | PMO | 2-3 小时 |
| 合并规则有效性复核 | 每季度一次 | PMO + 模块负责人 | 4 小时 |
这个阶段最重要的产出是一份团队内部认可的粒度标准文档，它决定了后面所有自动化规则的准确率。
3. 200 到 1000 人组织
到这个规模，靠人工巡检已经不可持续，必须转向"规则前置 + 抽样复核"。我建议的做法是：
（1）建立专门的数据治理角色
不需要专职，但需要明确一个 owner。这个人负责维护合并规则、监控数据质量指标、组织季度复核。在我参与的一个 320 人组织里，这个角色由 PMO 中的一个人承担 30% 的工作量，效果很好。
（2）把治理指标纳入管理例会
不是纳入考核，而是纳入例会看板。我建议跟踪三个指标：报表抽查一致率、跨系统对账差异率、一线治理耗时。前两个上升说明有效，第三个下降说明可持续。
（3）工具层面做能力绑定
这个规模下工具选型变得重要。需要工具支持自定义工作项类型、关联关系配置、自动化规则、以及跨系统集成能力。这也是为什么在这个区间我会推荐评估像 PingCode 这类面向中大型企业的平台，它的工作项模型和集成能力能承载前面说的逻辑合并和视图合并。
4. 1000 人以上或多事业部组织
这个规模下的核心问题不再是"怎么合并"，而是"谁来定义合并标准"。各事业部对任务粒度的理解天然不同，强行统一会遭遇巨大阻力。
我的建议是联邦式治理：集团层面定义最小公约数（比如工作项类型体系和状态映射），事业部层面定义具体的合并规则和粒度标准，集团只做数据汇聚层的视图合并。
这样既保证了管理层看板的一致性，又不破坏各事业部的既有习惯。代价是集团层的分析深度会受限，只能做趋势和总量分析，无法做细粒度的横向对比。
七、取舍：合并带来的收益与必须接受的代价
任何治理动作都有代价，回避代价的讨论是不负责任的。这一节我想说清楚四组权衡。
1. 合并程度 vs 上下文完整性
合并得越彻底，单条记录承载的上下文越多，但也越容易被"打包"成一个黑箱。我见过一个团队把 20 多个改动合并成一个"版本优化"任务，三个月后复盘时没人说得清这 20 多个改动分别是什么。
我的经验阈值是：单条主干任务合并的来源记录不宜超过 8 条，超过就说明粒度定义出了问题，应该往上拆一层而不是继续合并。
2. 治理速度 vs 一线体验
快刀斩乱麻式的治理能在两个月内把数字做漂亮，但一线体验差，反弹概率高。渐进式治理体验好，但管理层需要忍受三到六个月的"数据不好看"期。
如果管理层有硬性的报表需求时间点，我建议的做法是：先用视图合并快速交付一个可信的看板，同时用逻辑合并慢慢治理底层数据。这样管理层看到的是真实数字，一线不会感到被突击。
3. 中心化治理 vs 联邦式治理
中心化治理规则统一、报表一致，但适应性差，容易在事业部层面遭遇抵触。联邦式治理适应性强，但集团层难以做细粒度横向对比。
判断标准是：如果管理层分析主要用来看趋势和资源调配，选联邦式；如果要用来做跨部门横向排名和绩效核算，选中心化。这两者对数据一致性的要求差一个数量级。
4. 短期报表好看 vs 长期数据资产
这是最根本的一组取舍。物理合并能让报表最快变好看，但会持续损耗数据资产。逻辑合并和视图合并前期慢，但数据资产是累积的。
我的判断很明确：如果你的组织打算在三年后还能用这些数据做交付预测、效能分析、AI 辅助排期，就必须选后者。因为所有高级分析都依赖历史数据的完整性，而历史数据一旦被删，没有任何技术手段能补回来。
八、总结与下一步行动
回到文章开头那个 91% 完成率的报表。治理七个月后，这个数字变成了 79%，看起来是"变差了"，但管理层第一次可以用它做决策，因为剩下的每一条记录都对应一件真实的工作。
我想强调的独特观点是：任务合并的价值不在让报表变好看，而在让报表变得可用。短期内它会让数字变差，因为它挤掉了水分；长期它让所有基于任务数据的分析，交付预测、资源调配、效能评估，第一次有了可信的基础。
如果你现在准备开始做这件事，我建议按下面这个顺序推进：
- 第一周：拉出过去一个季度的全部任务记录，按我前面说的四类来源做一次人工分类，搞清楚你的重复主要来自哪里
- 第二到三周：定义团队级的任务粒度标准，写成一页纸，重点写清"一个任务交付什么"
- 第四周：配置工具层的三个自定义字段（来源系统、来源单号、主干工作项），建立最小可用的溯源链路
- 第二个月：启动每周模块级巡检，同时上线新建查重提示，把重复拦在入口处
- 第三个月起：建立三个监控指标（报表抽查一致率、跨系统对账差异率、一线治理耗时），按季度做规则有效性复核
最后给一个判断：如果你现在还在纠结要不要做任务合并，可以先做一个五分钟的测试，随机抽 20 条任务记录，问三个不同角色的同事"这条记录对应的工作，在系统里还有没有别的记录指的是同一件事"。如果有超过 3 条答不上来或者答"有"，那你的任务数据已经不适合直接用于管理层分析了。这件事越早做，代价越小；等到需要用数据做关键决策的时候才发现数据不可信，代价会高出一个数量级。
常见问题解答（FAQ）
1. 任务合并到底该在什么阶段做，需求评审前还是开发排期后？
我们团队二十来人，之前任务都是谁想到就建一条，结果评审一过，同一个功能被拆成七八条散落在几个迭代里，管理层想看进度根本拼不出全貌。我一直在纠结，到底是评审前就把颗粒度定好，还是等排期时再合并？
建议放在需求评审通过、进入排期之前做一次集中合并，而不是评审前。评审前需求本身还在变，提前合并大概率白做；评审后需求边界稳定了，这时合并才能对齐交付物。判断依据是看三条：同一交付目标、同一验收人、同一上线时间窗。三条都满足的散任务就合成一条父任务，子项作为检查项保留，不要直接删。
合并后父任务的工作量按子项之和填，避免管理层看到的工时被摊薄。我们团队实测，二十人规模一次迭代能把任务条数压下三到四成，周报里‘进行中’的条目从五十多条降到三十条以内，管理层一眼就能看出卡在哪。
2. 任务合并之后原始记录被删掉了，后面要追溯谁改过什么怎么办？
上次我把五条重复任务合成一条，结果两周后老板问某个改动是谁提的，我翻遍记录只剩一条合并后的描述，当事人和原时间点全没了。我现在特别怕合并等于销毁证据，可又不能不合并。
合并的原则是‘关不删、并留链’，绝对不要物理删除原始任务。做法是把源任务状态改为已关闭或已合并，在描述里写清‘已合并至 XXX’，并在父任务的日志里逐条贴出源任务编号、原始负责人和创建时间。这样管理层看的是合并后的干净视图，追溯时又能顺着编号找回全部上下文。
判断标准很简单：合并操作后，任意一条原始任务的编号仍然可搜索、可点开、可看到它指向谁。如果你们用的某项目管理工具支持任务关联或父子层级，优先用关联而不是删除，数据口径上父任务工时取子项之和，但保留子项独立工时字段，方便事后核对是否存在重复计工。
3. 多个小任务合并成一条大任务后，进度百分比到底怎么算才不会被质疑？
我们合并后出现过一次尴尬：父任务显示完成百分之八十，但底下五个子项其实只完了两个，管理层当场质疑数据注水。我后来想是不是干脆按子项数量平均算，可子项工作量差很多，平均也不对。
进度不要用子项个数平均，也不要用负责人拍脑袋填，用工作量加权。具体口径是：父任务进度等于已完成子项的预估工时之和除以全部子项预估工时之和，预估工时在合并时就固定下来，中途变更要走变更记录。这样五个子项里完成两个、但这两个占了六成工时，显示百分之六十就是合理的，经得起追问。
前提是子项必须有工时预估，如果你们团队还没养成估工时的习惯，可以先退一步用子项权重，比如核心子项权重三、次要子项权重一，但要在父任务描述里写明权重规则，保证前后口径一致。管理层质疑的从来不是数字大小，而是算法是否透明、是否每次都一样。
4. 从零搭建任务管理，任务合并和数据分析的看板应该先做哪个？
我们刚开始规范任务管理，领导既想要干净的合并后任务列表，又想要能看趋势的数据看板，资源只够先推一个。我担心先做看板，底层任务一团乱，图表全是噪音；先做合并，又怕领导觉得看不到成果。
先做合并规范，再做看板，顺序反了会返工。原因是看板的所有指标都建立在任务口径统一之上，如果同一件事还散在多条任务里，你的完成率、周期、积压量全是重复计数的假数据，看板越漂亮越误导。可执行的路径是：第一步定义合并规则和字段规范，至少统一任务标题格式、负责人唯一、工时预估、状态取值四项；
第二步跑两个迭代，把历史任务清洗合并一遍，形成干净底表；第三步才上看板，先只做三张图，任务总量趋势、按状态的积压分布、按负责人的负载，跑稳一个月再扩展。判断是否该进入第二步的标志是，随机抽十条任务，有八条能明确归属到唯一交付目标。达不到就继续清洗，别急着做图。
规模上，二十到五十人团队按这个节奏通常四到六周能跑顺，人越多清洗阶段要留的时间越长。
核心关键词
文章包含AI辅助创作：任务合并怎么做？管理层数据分析：任务管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/349892
读者评论
每周30分钟模块级巡检这条我持保留意见。320人的组织或许可行，我们80人的团队模块负责人本身就是一线主力，固定抽30分钟做同源检查，执行两个月就流于形式了。后来改成新建时必须填“可交付成果”字段，填不出来不让建，源头堵住了不少。但跨角色转译那类还是没辙，开发写的和产品写的依旧对不上。
合并率不能进考核这点很认同，但报表抽查一致率同样能被对付。我们试过抽查，结果模块负责人提前把可疑记录自行处理掉了，抽查时自然一致。真正靠得住的可能是保留“已合并”标记的完整链路，让审计方从原始记录反查，而不是让被考核方自证。另外文中37%这个比例，在需求变更频繁的业务线里我估计还要更高。
迁移那部分我有一点不同看法。理论上迁移动刀是最好的合并窗口，但实际推进时阻力往往不在技术侧，而在业务方，并购过来的团队不愿让自己的历史数据被合并归类，觉得那是工作量的证据。我们那次最后只做了“物理导入加逻辑打标”，分析层去重，没敢真合。所以迁移窗口成立的前提，可能是治理权已经足够集中。