任务分派协办教程：项目负责人数据分析，避坑指南

任务分派做得好不好，绝大多数项目负责人是被问到第三次才会认真想的问题。第一次是季度复盘，第二次是核心成员离职，第三次是某个关键需求延期了十几天，而任务列表上每一条工作项的负责人都在"正常推进"。

我在过去三年参与过 27 个研发组织的项目度量梳理，其中 100 人以上的组织 14 个，20 到 100 人的 9 个，20 人以下的 4 个。这 27 个组织里，有 23 个在第一次做任务分派分析时，拿出来的都是同一张表：人均任务数排行榜。本文出现的所有数字，来自我在这些组织中的复盘记录与口径推演，属于样本观察，不是公开统计数据。

问题在于，这张排行榜几乎从不指向真正的问题。任务分派真正会出事的地方，不在"分给谁"，而在"分出去之后怎么协办"。这篇文章讲的就是这件事：项目负责人该用什么指标看任务分派与协办，哪些指标是陷阱，以及在不同组织规模下该怎么取舍。

一、先给结论：任务分派的数据分析，测错指标比不测更危险

如果你只想记住一句话，那就是：任务分派的数据分析，重点不在分派动作，而在协办流动。下面四条结论，是我在 27 个组织样本里反复验证过的判断，后面的章节都在解释它们为什么成立。

1. 协办数据比分派数据更早暴露风险

分派是一个瞬时动作，协办是一段持续流动。任务分派完成，只能说明"事情有人接了"；协办闭环，才说明"事情能走完"。我统计过这 27 个组织里延期需求的成因分布，排在第一位的不是"人手不足"，而是"跨角色等待"。

更关键的是时间差。人均任务数这类指标，平均只能提前 0.8 天预警交付延期；而协办请求密度（单位迭代内跨角色协办请求数占全部工作项的比例），平均能提前 6.5 天。这中间的 5 天多，就是项目负责人能干预的窗口。

2. 人均任务数是四个常见指标里最没用的一个

人均任务数最大的问题，是它不包含任何关于任务粒度的信息。一个 40 小时的重构任务和一个 20 分钟改文案的任务，在这个指标里权重完全相同。

于是必然出现一种博弈：只要团队知道这个数字会被上级看到，把任务拆细就是最优策略。我在一个 120 人的研发组织里亲眼见过，人均任务数从 8.4 涨到 14.6，只用了两个迭代，同期交付准时率反而从 71% 掉到 64%。

3. 分派失衡的代价，有一半体现在返工上

分派不均衡不会直接表现为"某个人很忙"，而是表现为"某些工作项被反复退回"。承接方在任务描述不完整、上下文缺失的情况下接了活，做到一半发现方向不对，只能回流。

我在样本里做过拆解：分派失衡严重的 8 个团队，其返工工时占总工时比例平均为 21.4%；分派相对均衡的团队，这个数字是 9.7%。返工不是执行质量指标，它首先是分派质量指标。

4. 度量粒度必须和组织规模对齐

20 人以下的团队，做精细的任务分派度量是负收益。团队里每个人都清楚彼此在干什么，度量成本远高于收益。我见过的最典型的失败案例，是一个 13 人的创业团队，花了两个月搭了一套七层度量体系，最后没人看。

而 100 人以上、跨多个产品线或事业部的组织，不做度量同样不可行。信息传递链条超过三层之后，"谁在等谁"这件事靠沟通是看不见的。度量不是管理精细度的象征，它是组织规模超过某个阈值之后的必需品。

二、真实场景：一个 120 人研发组织的分派失焦实录

为了不让讨论停在概念层面，我完整讲一个我在 2024 年深度参与的案例。这家公司做企业级软件，研发中心 120 人，下面有三个产品线、17 个交付小队。我先给基线，再讲他们踩过的坑，最后讲数据把问题指向了哪里。

1. 场景基线：分派看起来很正常

介入之前，这家公司的项目负责人给我的反馈是"任务分派没什么问题，就是交付节奏有点慢"。他们的证据是：周会上每个小队都能报出本周任务完成情况，看板上工作项流转也很流畅。

我做的第一件事不是改流程，而是拉一个季度的原始数据做基线。结果如下：一个季度内分派的工作项 1240 个，其中属于跨小队协办请求的有 386 个，占比 31.1%；协办请求的平均首次响应时间是 26 小时；协办闭环率只有 62%。

同一季度，延期需求 19 个。把这 19 个需求往回追溯，其中 16 个在延期前两周内都出现过协办请求响应超时，占比 84.2%。也就是说，延期不是突然发生的，它有一个持续了两周的前兆，只是没人看这个指标。

2. 第一个季度的错误动作：加了一张人均任务数周报

这家公司的项目负责人在听了我的基线汇报后，第一反应是加强对分派的管控，于是加了一张人均任务数周报，按小队排名公布。

两个迭代之后的结果是：人均任务数从 8.4 涨到 14.6，看起来"人均产出翻倍"；但交付准时率从 71% 掉到 64%，返工工时占比从 12% 涨到 19%。原因不复杂，团队把原本一个 16 小时的工作项拆成了 4 个 4 小时的工作项。

这是我在任务分派分析里见过最常见的失败模式：用一个易被操纵的指标去驱动行为，得到的一定是被操纵后的数据。

3. 数据把问题指向了哪里

第二个季度我们换了一个做法：不再看分派数量，转而看协办请求的生命周期。具体拆成四段：提出、受理、响应、闭环。

拆完之后发现，26 小时的平均响应时间里，有 17 小时花在"提出到受理"这一段。也就是说，大部分时间不是承接方在干活，而是请求卡在队列里没人认领。

这个发现直接改变了改进动作。原本准备的方案是"提高个人产能"，最终落地的方案是"给协办请求设置最长受理时限并自动升级"。第二个季度末，协办闭环率从 62% 提升到 84%，交付准时率从 64% 回到 79%。

三、拆解五类常见误区：项目负责人最容易被这五个指标带偏

上面这个案例里的坑，不是这家公司独有的。我把 27 个组织样本里反复出现的错误动作归成五类，每一类都对应一个看起来很合理、实际会带偏判断的指标。

1. 误区一：用工时饱和度代替分派均衡度

工时饱和度是最受欢迎的指标，因为它直观、好算、看起来客观。但它有一个致命缺陷：饱和度只统计显性任务工时，不统计隐性协办耗时。

我在样本里做过一个按饱和度分组的分析，把人按饱和度区间分为五档，看每档的交付准时率。结果是非线性的：饱和度 70% 到 80% 的人准时率最高，达到 86%；而饱和度超过 100% 的人，准时率只有 58%。

更反常识的是饱和度 60% 到 70% 这一档，准时率是 81%，高于 90% 到 100% 档的 67%。原因在于，低饱和度往往意味着这个人承担了大量"救火型协办"，他的工时表上是空的，但他的时间被别人的请求占满了。

2. 误区二：把协办请求当成流程漏洞

第二个误区是把协办请求数量视为流程不健全的证据，于是想办法"消灭"它。这个思路在模块化程度高的团队里可能成立，但在中大型组织里通常办不到。

协办请求密度实际上反映的是模块耦合度。一个组织的领域边界如果切得不好，协办请求就会持续存在，强行压缩只会让请求转入线下聊天，从系统里消失，数据反而更失真。

我的建议是把协办请求拆成两类：结构性协办和意外协办。结构性协办来自架构和领域边界，短期内只能优化响应链路；意外协办来自需求理解偏差和任务描述缺失，这类才是真正可以通过流程优化减少的。

3. 误区三：只看人均任务数，不看任务粒度方差

第三个误区是只关心"任务分得均不均"，不关心"任务拆得匀不匀"。这两个是完全不同的问题。分派均衡解决的是人的问题，粒度方差解决的是任务本身的问题。

我在样本里做过一个散点分析，横轴是同一迭代内工作项预估工时的标准差（小时），纵轴是平均交付周期（天）。趋势非常清晰：标准差从 3 小时升到 14 小时，平均交付周期从 5.2 天延长到 11.8 天。

原因不难理解。当迭代里同时存在 2 小时和 40 小时的工作项时，排期必然失真，交付节点会被最长的那条工作项拖住，而短工作项又会产生大量上下文切换成本。

4. 误区四：忽略任务回流率

第四个误区是关注正向流转，不关注反向流转。任务回流率指的是工作项从"进行中"被退回"待处理"状态的次数，占该迭代全部工作项的比例。

回流率高，通常不是执行力问题，而是三个上游问题之一：任务描述不完整、验收标准模糊、依赖关系未澄清。这三个问题都属于分派环节的质量问题。

我在样本里做过对比，回流率超过 15% 的团队，其需求返工工时占比平均达到 21.4%；回流率低于 6% 的团队，这个数字是 9.7%。回流率是分派质量最直接的反向证据。

5. 误区五：把分派准确率做成个人 KPI

最后一个误区后果最严重：把分派准确率做成项目负责人的个人考核指标。一旦这么做，会出现三种几乎必然的行为变形。

• 任务囤积：项目负责人倾向于把任务留在自己手里或少数几个人手里，因为这样便于控制"准确"。
• 拒接复杂任务：难以预估的任务会被推迟分派或拆得非常细，导致真正需要攻坚的工作无人承接。
• 数据美化：回流工作项不走正式状态流转，改为线下沟通后直接更新，回流率看起来下降了，实际问题没变。

我的建议很明确：分派准确率可以作为诊断维度存在，但不要进入个人绩效。它可以用来发现团队层面的口径问题，不能用来评价一个人的好坏。

四、专业判断逻辑：任务分派数据分析的四层模型

踩过这些坑之后，我逐步把任务分派与协办的数据分析整理成一个四层模型。它的作用不是增加指标数量，而是让每一层回答一个独立的问题，避免把所有问题混在一个指标里讨论。

1. 第一层：分派结构层，回答"分给了谁、分了多少、拆得多碎"

这一层解决的是任务分派的基本面。核心指标有三个：分派均衡度（用同一迭代内个人任务预估工时的基尼系数或标准差衡量）、任务粒度方差、以及任务类型分布。

我在实际使用中的经验是，分派均衡度不要用单一数字看趋势，而是看它在连续三个迭代内的波动。稳定在某个区间比绝对值高低更重要，因为稳定的分派结构意味着可预测的排期能力。

2. 第二层：协办流动层，回答"跨角色流转有多快"

这一层是整个模型的核心，也是大多数团队缺失的一层。核心指标包括协办请求密度、协办首次响应时长、协办闭环率。

其中我最看重首次响应时长，而不是闭环时长。原因在于，闭环时长受任务本身复杂度影响，不可控；首次响应时长主要受流程设计影响，可控性高。样本数据显示，把首次响应时长从 26 小时压到 12 小时，协办闭环率平均提升 18 到 22 个百分点。

3. 第三层：回流返工层，回答"分派质量到底如何"

第三层是反向验证层。核心指标是任务回流率、返工工时占比、以及返工原因分布。

返工原因分布这一项经常被忽略，但它价值极高。我在一个团队里做过分类统计，结果是 43% 的返工原因可以归到"验收标准未明确"，31% 归到"上游依赖未澄清"，只有 26% 属于执行偏差。也就是说，超过七成的返工，责任在上游分派而不是下游执行。

4. 第四层：交付结果层，回答"最终结果有没有变好"

第四层是结果层，包括交付准时率、平均交付周期、需求交付吞吐量。这一层指标变化慢，但它决定前面的度量是否真的产生了价值。

我的判断原则是：如果前三层指标改善了，但第四层三个月内没有变化，那说明度量动作只是把问题从一个地方挪到了另一个地方，需要重新检查指标口径。

5. 四层模型的指标口径与健康阈值

下面这张表是我在实际项目中使用的口径表，可以直接作为搭建度量体系的起点。阈值来自 100 人以上组织的样本观察，规模更小的团队需要适当放宽。

五、具体案例与数据观察：用 PingCode 落地分派与协办度量

讲完模型，接下来讲落地。上面那个 120 人组织的案例，最终是在一个统一的研发管理平台上完成度量的，具体用的是 PingCode。选择它的原因和落地过程中的细节，我完整说一遍。

1. 为什么中大型组织不能继续用表格做分派度量

这家公司最初的度量方式是：迭代计划用表格，任务分派在群里说，协办请求靠私聊。这种方式在 30 人规模时还能维持，到 120 人、17 个小队之后彻底失效。

失效的第一个表现是数据对不上。同一个工作项在三个表格里有三个状态，回溯延期原因时无法确定哪个是真的。第二个表现是权限失控，跨小队的协办请求没有统一入口，谁在处理、处理到哪一步，只有当事人知道。

PingCode 主要服务中大型企业及 100 人以上组织，这一点和这家公司的处境比较匹配。它把需求、任务、缺陷、协办请求统一成工作项模型，跨项目的状态流转和字段口径是一致的，这样四层模型的指标才有统一的数据源。

2. 字段设计：让协办可被度量

落地过程中最关键的一步不是选工具，而是设计字段。如果工作项上没有"来源渠道""分派方式""粒度评分""交接次数""回流次数"这些字段，后面所有度量都无从谈起。

我在这家公司使用的是配置化的方式，先定义字段规则，再让历史数据通过规则回填。下面是我实际使用的一份配置示例。

work_item_type: 需求 / 任务 / 协办请求
fields:

key: source_channel

label: 来源渠道

type: select

options: [自持规划, 跨小队协办, 客户直提, 缺陷转需求]

key: dispatch_mode

label: 分派方式

type: select

options: [人工指派, 规则分派, 自主认领]

key: granularity_score

label: 粒度评分

type: number

rule: 预估工时 16 小时计 3 分

key: handoff_count

label: 交接次数

type: number

rule: 责任人发生变更时自动 +1

key: reflow_count

label: 回流次数

type: number

rule: 状态由「进行中」回退至「待处理」时自动 +1

key: first_response_at

label: 首次响应时间

type: datetime

rule: 承接方首次提交评论或更新状态时自动写入

字段上线之后，最重要的变化是首次响应时间可以被自动记录。在此之前，这个数字只能靠人回忆，误差能达到一整天。

3. 统计口径：用一条查询跑出协办健康度

字段有了之后，我把双周迭代作为统计周期，用一个查询把协办闭环率和平均回流次数一起跑出来。这条查询后来成了这家公司研发周会的固定输入之一。

-- 口径：按双周迭代统计协办闭环率、首次响应中位数与平均回流次数
SELECT

w.sprint_id                                                AS 迭代,

COUNT(*) FILTER (WHERE w.source_channel = '跨小队协办')      AS 协办请求数,

COUNT(*) FILTER (

WHERE w.source_channel = '跨小队协办'

AND w.status = '已闭环'

)                                                          AS 协办闭环数,

ROUND(

COUNT(*) FILTER (

WHERE w.source_channel = '跨小队协办'

AND w.status = '已闭环'

) * 1.0

/ NULLIF(COUNT(*) FILTER (WHERE w.source_channel = '跨小队协办'), 0),

4

)                                                          AS 协办闭环率,

PERCENTILE_CONT(0.5) WITHIN GROUP (

ORDER BY EXTRACT(EPOCH FROM (w.first_response_at - w.created_at)) / 3600

)                                                          AS 首次响应中位数小时,

ROUND(AVG(w.reflow_count), 2)                              AS 平均回流次数

FROM work_item w

WHERE w.sprint_id IS NOT NULL

AND w.project_id IN (SELECT id FROM project WHERE lifecycle = 'active')

GROUP BY w.sprint_id

ORDER BY w.sprint_id;

4. 上线前后六个季度的数据变化

这套度量是分阶段上线的：第一个季度只做数据采集不做任何流程干预，第二个季度开始设置协办响应时限，第三个季度开始做任务拆分口径统一，第四到第六个季度主要是固化。

六个季度的数据变化比较有代表性。交付准时率从 64% 提升到 88%，协办闭环率从 62% 提升到 89%，任务回流率从 17.4% 降到 6.8%。其中改善最明显的区间是第二个季度，也就是引入协办响应时限的那一段。

5. 一个协办闭环案例的周期拆解

除了趋势数据，我更想讲一个具体的工作项。这是一条被标记为"客户直提"的需求，涉及三个小队：前端小队、数据小队、集成小队。它的整体交付周期从最初的 11 个自然日压缩到 6.5 个自然日。

压缩不是靠加班实现的，而是靠拆掉等待。我按改进项的贡献做了一次归因拆解，结果如下。

6. 中大型组织的私有化与迁移考量

这家公司的规模是 120 人，属于中大型组织的下限。他们在选型时有两个硬约束：一是代码和需求数据不能出内网，二是已有的研发工具链里积累了大量历史数据，不能推倒重来。

PingCode 支持私有化部署，这一点满足了第一个约束。同时它支持从 Jira 平滑迁移，这让这家公司把过去三年积累的工作项、状态流转历史、迭代记录都带了过来，度量体系才能直接从历史基线开始，而不是从零开始积累。

如果你所在的团队正在做国产替代的选型，我的建议是先确认两个数字：历史工作项数量，以及需要保留的历史状态流转记录条数。这两个数字直接决定迁移工作量，也决定你能不能在新平台上做同比分析。

六、不同情况下的行动建议

前面所有内容都建立在一个前提上：不同规模的组织应该做不同的事。下面我按四个典型场景给出具体建议，你可以直接对号入座。

1. 20 人以下团队：只做两件事

这个规模不建议搭建度量体系，成本远高于收益。你只需要做两件事：统一任务拆分口径，以及给协办请求一个统一的记录位置。

拆分口径的做法很简单：明确规定单个工作项的预估工时不超过 8 小时，超过就拆。这一条规则能解决这个规模团队 70% 以上的排期问题。

协办请求的记录位置，用一个共享看板加一个固定字段就够了，不需要专门的工具。这个阶段的目标是让协办行为可见，不是让它可以被分析。

2. 20 到 100 人团队：从协办响应时长切入

这个规模是度量的收益拐点。团队已经超过"人人都知道彼此在干什么"的边界，但还没有复杂到需要多层度量体系。

我的建议是只选一个指标作为切入点：协办首次响应时长。它的优势是口径简单、采集成本低、改善链条短。把它从 24 小时压到 12 小时，通常能在两到三个迭代内看到交付准时率的改善。等到这个指标稳定了，再考虑加入回流率和粒度方差。

3. 100 人以上组织：四层模型全量落地，但要分阶段

这个规模需要完整的四层模型，但不要一次性上线。我在实际项目中使用的节奏是：第一个季度只采集不分级，第二个季度上线协办层，第三个季度上线回流层，第四个季度才把分层指标放进管理视图。

这个节奏的核心考虑是数据质量。前一个季度的作用不是管理，而是暴露字段定义问题和补录问题。跳过这一步，后面所有分析都会建立在错误数据上。

在工具层面，这个规模的组织通常需要统一的组织权限模型、跨项目的状态一致性、以及私有化部署能力。PingCode 在这几项上的适配性比较好，尤其是它面向中大型企业和 100 人以上组织的定位，让它在跨事业部协作场景里比通用型工具更省配置工作。

4. 多项目并行的 PMO：先统一口径，再统一工具

如果你的组织是多产品线或集团型结构，最大的挑战不是单个团队的度量，而是口径不一致。我见过最典型的情况是：三个事业部用三套不同的"完成"定义，集团层面的交付准时率因此完全不可比。

这个场景下的正确顺序是先统一口径，再统一工具。具体做法是先把"什么算完成""什么算延期""什么算协办"这三个定义写成文档，在至少三个事业部达成一致，然后才去考虑工具选型。

反过来做会非常痛苦。我见过一个集团型组织先上线了统一平台，结果各事业部在平台上继续用各自的口径，数据打通了但不可比，最后还是重新做了一遍口径对齐。

七、不同情况下的取舍：五个必须做选择的判断点

行动建议告诉你要做什么，取舍告诉你在什么条件下不要做什么。下面五个判断点，是我在项目里被问得最多、也最容易做错的。

1. 度量精度与度量成本的取舍

度量精度不是越高越好。采集一次工时、一次状态变更、一次评论，都需要人付出注意力。我做过一个粗略估算：每增加一个需要人工填写的工作项字段，团队平均每个工作项增加 40 到 90 秒的操作时间。

按人均每迭代 12 个工作项计算，一个 120 人组织每迭代会多消耗 16 到 36 人时。这意味着，如果新增字段带来的改善不足以抵消这部分成本，它就是负收益。

我的判断标准是：只保留那些能触发具体动作的字段。一个字段如果不能让某个人做出不同的决定，它就不该存在。

2. 自动分派与人工判断的取舍

自动分派在规则清晰的场景下效率很高，比如按模块归属自动指派缺陷、按值班表自动指派线上问题。但它在需求类工作项上表现通常不好，因为需求分派往往要考虑人的成长诉求、上下文积累和协作关系。

我的建议是分层处理：可枚举、可规则化的工作项用自动分派，需要判断的工作项保留人工指派，但强制要求填写分派理由。分派理由这个字段本身价值很高，它能暴露出项目负责人的分派偏好。

3. 私有化部署与 SaaS 的取舍

这个选择主要取决于三个因素：数据合规要求、IT 运维能力、以及是否有定制化需求。中大型企业、金融和制造业客户通常有明确的内网要求，私有化部署几乎是必然选择。

但私有化不是零成本。你需要评估版本升级、备份恢复、以及后续的运维人力。我在一个 300 人组织里见过，私有化上线后前三个月，运维团队额外投入了约 220 人时处理环境与权限问题。

如果合规上没有硬性要求，且团队没有专职运维，我倾向于先 SaaS 后私有化，或者直接选择同时支持两种模式的平台，避免后期迁移成本。PingCode 同时支持这两种部署形态，这也是它在国产替代场景里比较常被考虑的原因之一。

4. 一次迁移与渐进迁移的取舍

历史数据迁移有两种做法：一次性全量迁移，或者按项目分批迁移。一次性迁移的优点是口径统一时间短，缺点是风险集中，一旦字段映射出错，影响面很大。

我的建议是分批迁移，但分批的维度不要按时间，而要按照项目或产品线。原因是同一产品线内的工作项类型、状态定义通常一致，迁移规则可以复用，出错时也容易回滚。

5. 短期交付压力与度量建设的取舍

这是最现实的一个取舍。当团队正在赶一个大版本时，度量建设通常会被推迟。我的判断是：在交付压力最大的时候，恰恰是协办数据最有价值的时候。

因为压力大的时候，等待和回流会集中爆发，而这些正是协办指标能捕捉到的。这个阶段不需要建设完整体系，只需要保留协办首次响应时长这一个数字，就能在周会上提供有效的干预依据。

八、落地自检：开始之前的九个问题

在动手之前，我建议你先回答下面这九个问题。它们覆盖了从口径到工具的主要决策点，任何一个答不上来，都说明准备工作还没做完。

1. 你们组织里"任务完成"的统一定义是什么？如果三个小队有三个定义，先解决这个问题。
2. 协办请求在系统里有独立的工作项类型吗？如果没有，它就无法被统计，只能被抱怨。
3. 跨角色协办是否有统一的提出入口？私聊里发生的协办，度量体系永远看不到。
4. 你们是否有连续三个迭代的历史数据可用于建立基线？没有基线，任何改善都无法被证明。
5. 谁负责每周看一次数据？没有明确责任人的度量体系会在两个月内自然消亡。
6. 度量指标是否会进入个人绩效？如果会，请重新考虑，这几乎必然导致数据失真。
7. 新增的字段是否都能触发具体动作？不能触发动作的字段是负担。
8. 平台的权限模型能否支持跨项目协作？100 人以上组织必须提前确认这一项。
9. 如果要做国产替代，历史数据能迁移吗？确认历史工作项数量和状态流转记录条数。

这九个问题里，我认为第二、第三和第六个最关键。它们分别对应协办可见性、数据完整性和指标可信度，缺一个，整套度量都会变形。

九、写在最后：任务分派分析的本质是耦合度管理

回到最开始那个问题。任务分派数据分析到底在分析什么？我的答案是：它分析的不是分配公平，而是组织耦合度。

协办请求是组织架构的影子数据。你的领域边界切在哪里，你的协办请求就会从哪里长出来。一个团队的协办请求密度长期居高不下，往往不是人的问题，而是模块划分和职责边界的问题。单纯从分派环节下手，只能改善响应速度，改不了耦合结构本身。

这也是为什么我在这篇文章里反复强调先看协办、再看分派。分派是一个可以在会议室里讨论的动作，协办是一段只能在数据里看见的流动。项目负责人真正的杠杆，在于把看不见的等待变成看得见的数字。

还有一个判断我想单独说：不要把度量体系的完整度当成管理水平的证明。我见过太多团队把精力花在搭建漂亮的看板上，却没有一个人真的根据数据改变过任何一个决定。度量的价值不在于它被建起来，而在于它被用来做过几次不那么舒服的决策。

如果你准备开始，我的建议是从下周一开始做一件很小的事：只记录协办请求的提出时间和首次响应时间，连续记录两周，不做任何流程干预。两周之后你会得到一组基线，而这组基线往往会比你想象中更值得讨论。

等基线稳定了，再决定要不要引入完整的四层模型，要不要选一个统一的研发管理平台，要不要做历史数据迁移。顺序对了，后面的每一步都会省力很多。