任务分派多人任务教程：PMO数据分析，避坑指南

上周有一位 PMO 负责人拿着两张报表来找我：同一批 18 个多人协作任务，在项目看板上是 18 条，在人员负载表里却变成了 53 条，人均在制品数量从 3.1 直接跳到 7.4。她第一反应是报表系统出了 bug。我把原始数据拉出来逐条核对后发现，问题不在报表，而是在任务被分派出去的那一刻就已经埋下了，负责人字段里塞了三个名字，工具按"人 × 任务"展开，一条任务在三个人的负载里同时出现。

这就是多人任务分派最典型的坑：你以为你在描述协作，工具以为你在描述三份独立工作量。

一、先给结论：多人任务不是操作技巧，是数据建模决策

关于多人任务分派，我先把结论摆出来，后面再用场景和数据逐个拆解。这些结论来自我过去几年为十几家 100 到 1000 人规模的研发组织做项目管理流程诊断和工具迁移的经验，不是从工具文档里抄的。

1. 三条核心结论

结论一：多人任务的本质是一次数据建模决策，不是"点哪个按钮"的操作问题。你在分派时选择的字段结构，直接决定了半年后 PMO 能不能算出人均负载、能不能做协作网络分析、能不能把人力成本分摊到项目。

结论二：PMO 报表能不能用，取决于你在分派环节有没有同时保住两条线，责任唯一，协作可见。只要这两条线断了一条，报表要么无法追责，要么无法反映真实协作强度，二者必失其一。

结论三：绝大多数团队并不需要"多人负责人"字段。他们真正需要的是"主责人 + 协作人 + 子任务"这三层结构。多人负责人字段是最容易上手、也最容易把数据搞脏的方案，我不建议在 200 人以上的组织里默认开启。

2. 为什么我把结论下得这么绝对

因为任务分派的数据结构一旦定下来，后面所有分析都被它锁死。你可以在报表里做任何复杂的公式，但公式的输入是你当初填的字段。字段错了，报表越精美，误导越大。

我在三家 200 到 500 人的研发组织里做过一次小范围抽样，各抽取 500 条"明显需要多人参与"的任务，对比三种主流建模方式在 PMO 常见四项指标上的表现。这三种方式是：单一负责人加子任务拆分、直接用多人负责人字段、负责人加备注里的协作人姓名。结果差异比我预期的大得多。

这张图想说明一件事：同样一套项目管理平台，仅仅因为多人任务的建模方式不同，PMO 的数据可信度就能差出一倍。很多人把精力花在挑工具上，却忽略了字段设计这一步，结果买了功能最强的平台，报表依然没法看。

二、真实场景：坑是怎么一步步踩进去的

要讲清楚避坑，得先讲清楚坑是怎么形成的。多人任务这个需求，几乎从来不是 PMO 主动提出来的，而是被业务逼出来的。

1. 一个 380 人研发组织的真实起点

我参与过一家约 380 人的研发组织，三条产品线、42 个交付小组、PMO 编制 4 人。他们当时的工具里，任务默认只有一个负责人字段。但现实中至少有三类工作天然是多人协作的：

• 跨模块联调：前端、后端、测试各出一人，必须同时在场才能推进。
• 联合评审与方案设计：架构师、产品、安全三方共同产出，没有单一交付人。
• 故障复盘与应急：值班、运维、业务方同时参与，参与人数随故障等级浮动。

团队最初的解决办法非常朴素：谁能推进就填谁，其他人写在任务描述里。半年后 PMO 做季度人力复盘时发现，报表上显示某位后端工程师当季只承担了 11 个任务，而团队里所有人都知道他几乎全职泡在联调上。问题不是他工作量小，而是他的工作量根本没有进入任务数据。

2. 需求是怎么从"记录"升级成"分析"的

阶段一，团队只想要记录：知道这件事有哪些人在做就行。此时用描述字段写名字完全够用，成本最低。

阶段二，开始要通知：任务状态变了、有评论了，希望相关人都收到提醒。这时备注里的名字已经不起作用，因为工具无法把文本解析成人。

阶段三，开始要度量：PMO 要算人均在制品、要预判未来两周谁超载、要把人力成本摊到项目上。到这一步，备注方案彻底崩盘，团队被迫在工具里找一个"能装多个人"的字段。

真正的坑就在阶段三。绝大多数团队会直接跳到"多人负责人字段"这个最省事的答案，而它恰好是最不适合做分析的一种。

3. 为什么问题总是在半年后才暴露

因为前六个月没人看报表。任务在团队内部流转，靠的是站会口头同步和群消息，数据只是顺带记录的产物。等到 PMO 要做年度人力盘点，或者公司要按项目核算成本，才第一次真正"读"这些数据。

这时候窗口期已经过去了。你要么接受一份偏差巨大的报表，要么花几周时间清洗历史数据，后者往往比重新定义流程还贵。

三、避坑指南：多人任务分派的八个高频误区

下面这八条，是我在实际项目里亲眼见过并处理过的，按出现频率从高到低排列。每一条我都给出错误表现、直接后果和修正方向。

1. 用逗号或顿号把名字拼进负责人字段

这是最原始也最常见的一种。错误表现是负责人字段里出现"张三, 李四, 王五"这样的文本。直接后果有三层：按人过滤时三个人都会命中这条任务；人均任务数被重复计数；工时无法归属到具体人。

修正方向是把它拆成两个字段：主责人（单选、必填）和协作人（多选、可选）。如果工具不支持自定义多选字段，就退而使用子任务或关注者字段，绝不要在文本字段里塞人。

// 反例：用逗号拼多人负责人字段
assignee = "zhang.wei, li.na, wang.qiang"

// 由此产生的连锁问题：

// 1. 按 assignee 过滤时，三个人都会命中这条任务

// 2. 人均任务数被重复计数 3 次，负载虚高 200%

// 3. 工时无法归属到具体人，成本分摊失效

// 4. 状态流转没有唯一责任人可校验，卡住时无人推进

// 5. 通知会同时发给三个人，重要提醒被稀释

2. 只更新主任务状态，子任务状态长期不动

很多团队拆了子任务，但日常同步只在主任务上做。结果是主任务显示"进行中 80%"，点进去看子任务，五个里有四个还挂着"待处理"。

这种数据在报表层面是致命的。任何基于子任务状态聚合的进度计算都会失真，PMO 看到的完成率会比实际低 30% 到 50%，反过来又让管理层误判团队效率。

修正方向很简单：状态更新必须发生在最小执行单元上，也就是子任务。主任务状态由子任务自动汇总，不允许人工直接改。

3. 工时按参与人数均摊

这是我看过的最隐蔽的坑。一个预估 8 小时的任务分给 4 个人，报表里每人记 2 小时。看起来公平，实际上既不是投入也不是成本。

真实情况往往是其中一人投入 6 小时、两人各 1 小时、一人只是旁听。均摊之后，这位主力在数据上变成了"轻负载"，下一次分派时系统还会继续往他身上压任务。

工时数据的价值不在于总量准确，而在于相对分布准确。总量偏差 10% 可以接受，分布完全错位则会让整个负载管理系统失效。

4. 把"知情者"塞进负责人字段

有些团队的习惯是"相关的人都加上"，领导、测试、产品、甚至隔壁组的接口人都挂在负责人字段上。结果是任务状态一变化，十几个人同时收到通知，真正的执行人被淹没在噪音里。

知情和负责是两种完全不同的关系。知情者应该放进关注者字段，他不参与任何负载和工时统计，只接收通知。把知情者算进负责人，等于人为制造了 10 倍的虚假工作量。

5. 没有定义"多人任务什么时候算完成"

五个人参与的任务，四个人标记完成，第五个还在处理细节。这个任务现在算什么状态？如果算完成，剩下的工作就丢了；如果算未完成，前四个人的贡献在报表上体现不出来。

我的建议是给出明确口径：以主责人的确认为准，且所有子任务必须全部关闭。如果确实存在"部分交付"，就应该在拆任务阶段把它拆成两个独立任务，而不是在同一任务内制造模糊地带。

6. 用多人任务击穿看板的在制品限制

看板方法里，每个列都有在制品上限。一张卡片如果挂了五个人，它在五个人的看板上各占一个坑，实际占用了五倍的在制品额度。列上限显示是 8，实际承载的是 40 人份的工作。

这会让团队的流动效率指标彻底失效，你会看到"在制品没超标"，但交付周期越来越长。

7. 报表口径三套并存

任务数、子任务数、工时，这三个口径如果不统一，PMO 的报表和团队看板永远对不上。我见过最夸张的一次，同一个季度的人均任务量，PMO 报表算出来是 14.3，团队自己导出是 26.7，差了将近一倍。

根因是两边的统计粒度不同，一个数父任务，一个数子任务。这件事没有技术难度，纯粹是口径定义问题，但如果不提前约定，每次复盘都要吵一轮。

8. 没有独立的协作关系字段

这是最容易被忽略的一条，也是最有长期价值的一条。如果你的工具里只有负责人和子任务，那么"谁经常和谁一起干活"这个信息就完全没有被记录下来。

一旦你有了独立的协作人字段，PMO 就能做协作网络分析：识别关键协作枢纽、发现跨团队协作瓶颈、评估组织重构对协作密度的影响。这类分析在 500 人以上的组织里价值极高，而它的数据基础，就是在分派环节多填一个字段而已。

四、专业判断逻辑：四个问题决定怎么分派

避坑指南告诉你什么不能做，接下来讲什么该做。我的判断逻辑是四个问题，回答完之后，建模方式基本就唯一确定了。

1. 四个必答问题

（1）这个任务有没有独立可验收的交付物？

如果有，而且这个交付物需要单独验收、单独排期，那它就应该是一个独立任务或子任务，而不是一个多人任务的组成部分。是否"独立可验收"是拆与不拆的第一道分水岭。

（2）参与者是共同交付还是分别交付？

共同交付指的是必须所有人同时在场才能产出，比如联调、联合评审、应急响应。分别交付指的是各自负责一块、最后拼装，比如模块开发。共同交付适合主责加协作，分别交付必须拆子任务。

（3）是否需要计算每个人的投入？

如果 PMO 需要按人力成本分摊到项目，或者需要评估个人产能，那工时必须能落到具体人。这意味着不能用均摊，必须有独立的工时登记入口。

（4）是否有人只是知情？

只要答案是有，就必须把这些人从负责人和协作人字段里拿出来，放进关注者字段。这一步没做，后面的通知和统计都会带噪音。

2. 五种建模方式的选择矩阵

把四个问题的答案组合起来，落到下面五种建模方式上。这张表我在多个客户现场直接用白板画过，团队一看就能对号入座。

看这张表的关键在于最后两列。多人负责人字段的管理开销很低，这也是它受欢迎的原因，但它在责任清晰度和负载统计可靠性上都是最低的。低开销换来的低质量数据，最后一定会在报表环节以更高的成本还回来。

3. 字段层面的三条硬约束

不管选哪种方式，有三条约束我会要求所有客户在工具配置层面强制执行，而不是靠团队自觉。

1. 主责人字段必须唯一且必填，任何任务不允许出现零个或多个主责人。
2. 协作人字段必须是独立的多值字段，默认不参与负载统计，只参与协作网络分析。
3. 子任务必须继承父任务的项目与迭代属性，并且拥有独立的负责人、状态和工时字段。

第三条经常被忽略。很多工具里子任务默认不继承父任务的项目归属，导致子任务在项目维度报表里凭空消失。这个配置项在实施阶段花五分钟设好，能省掉后面半年的数据修复。

4. 一个可以直接落地的任务模型

下面是我推荐的任务数据结构，字段名可以随工具调整，但结构关系不要动。核心思想是：主任务只做容器和汇总，真正的执行、工时、状态都落在子任务上，协作人独立存在。

{
"task_id": "PMO-1024",

"title": "结算模块性能优化",

"project": "billing-platform",

"sprint": "2024-S14",

"owner": "zhang.wei", // 主责人：唯一、必填

"contributors": ["li.na", "wang.qiang"], // 协作人：多值、不参与负载统计

"watchers": ["pmo.team", "qa.lead"], // 关注者：仅通知、不进任何指标

"estimate_hours": 36, // 父任务仅作汇总，不直接登记工时

"status_rule": "auto_from_subtasks", // 状态由子任务汇总，禁止人工直改

"subtasks": [

{ "id": "PMO-1024-1", "owner": "li.na",     "estimate_hours": 12, "status": "doing" },
{ "id": "PMO-1024-2", "owner": "wang.qiang", "estimate_hours": 16, "status": "todo"  },
{ "id": "PMO-1024-3", "owner": "zhang.wei",  "estimate_hours": 8,  "status": "todo"  }
]
}

这个模型的好处是：父任务在负载统计里权重为零，不会重复计数；每个子任务有唯一主责人，工时可以精确归属；协作人字段保留了"这三个人在同一个上下文里协作"这个事实，可以用于协作网络分析。

五、案例与数据观察：某 380 人组织的实际落地过程

前面讲的都是判断逻辑，这一节讲一次完整的落地过程。我会把迁移前后的数据、中间踩的二次坑、以及最终的稳定方案都写出来，方便你对照自己的组织情况。

1. 迁移前的状态

这家组织约 380 人，三条产品线，42 个交付小组，PMO 编制 4 人。他们原来用的是一套海外项目管理平台，多人任务的处理方式是：主责人字段填一个人，其他人用自定义的标签字段记录，只有部分团队会用子任务。

问题出在月度人力报表上。由于协作信息散落在标签和描述里，PMO 每个月要从平台导出 40 多张表，再用 Excel 手工拼接。一份月度人力报表需要 3 个人做 5 个工作日，而且一致性很差，同一份数据，两个人做出来的结果能差 15% 以上。

另外，这家组织有比较明确的数据驻留要求，海外 SaaS 在合规评审上一直过不去。这两件事叠在一起，促成了工具切换。

2. 为什么选择 PingCode

他们在选型阶段评估了几款国产项目管理平台，最终选择了 PingCode。三个决定性因素：

• 支持私有化部署。他们的合规要求是代码、任务数据、附件必须留在自有环境内，这一点直接排除了大部分纯 SaaS 方案。
• 支持 Jira 平滑迁移。他们原有的字段结构、工作流、历史任务量都不小，迁移工具能不能保留历史数据和字段映射关系，是硬性门槛。
• 面向中大型组织的产品定位。PingCode 主要服务中大型企业及 100 人以上组织，在权限模型、多项目层级、跨团队报表这些能力上，和他们的组织结构更匹配。

需要说明的是，工具本身只解决了"能不能做"的问题。"怎么做"这一步，还是靠流程设计。

3. 迁移时做的三件事

第一件，统一任务模型。把所有历史任务规整成"主责人 + 协作人 + 子任务"三层结构。原来的标签字段能映射到协作人的就映射，不能映射的一律清空，宁可丢失部分历史协作信息，也不把脏数据带进新系统。

第二件，配置负载统计口径。在报表层明确规定：负载只统计子任务和明确归属到人的任务，父任务和协作人字段不参与负载计算，但协作人字段参与协作网络分析。这个口径写进了实施文档，并且做成了平台里的固定报表模板，避免各区自行其是。

第三件，设定子任务拆分门槛。一开始我们没有设门槛，结果出问题了，后面会讲。最终定的规则是：预估工时超过 2 小时、且需要独立验收的工作，必须拆成子任务；低于 2 小时的一律不拆。

4. 迁移后的六项数据变化

我把迁移前三个月和迁移后六个月的同期数据做了一个对比。需要提前说明，这些数据来自该组织的内部统计，我做了匿名化处理，同时为了保证可比性，只统计了全程在职、且工作内容没有重大变化的核心岗位共 214 人。

除了这四项持续性指标，还有两个一次性收益值得单独说。

一是月度人力报表的人工投入，从原来的 3 人 × 5 个工作日，降到 1 人 × 0.5 个工作日，节省约 14.5 人天每月。按该组织的人力成本折算，一年下来相当于释放了一个半人的产能。

二是负载预警的提前量，从原来的"事后统计"变成了提前 2 周可识别超载。这意味着排期调整发生在问题暴露之前，而不是在延期之后补救。

5. 落地过程中踩的二次坑

二次坑一：协作人字段被当成第二负责人。上线第一个月，有 37% 的任务出现了"两个人都以为对方在推进"的情况。原因很简单，团队把协作人理解成了共同负责。我们的修正是：在协作人字段的配置里加了说明文字，同时在周会上明确，协作人只表示"参与"，主责人才对交付结果负责。

二次坑二：子任务拆过头。因为没有设拆分门槛，第一个月平均每个父任务下挂了 6.8 个子任务，有些子任务预估只有 30 分钟。结果是团队每天花在更新状态上的时间超过了实际工作时间，管理开销明显上升。

第二个月我们补了 2 小时门槛规则，把平均子任务数压到 2.4 个，同时关闭了一批无意义的子任务。这一条我建议所有团队在拆分规则设计阶段就写进去，不要等到出问题再补。

二次坑三：把培训性质的任务也拆成子任务。有些组长为了"让每个人的工作都被看见"，把内部技术分享、代码走查这类活动也建成了带子任务的任务。这会让负载数据虚高，掩盖真正的交付压力。我们的处理方式是给这类活动单独建一种任务类型，不纳入交付负载统计。

6. 稳定运行一年后的观察

一年之后回看，这套结构最大的价值不是报表变准了，而是组织开始能用数据讨论问题。以前排期冲突靠感觉和资历，现在能拿出未来两周的人均剩余工时，争论的焦点从"谁更忙"变成了"怎么调整优先级"。

另外，协作网络分析也带来了意外收获。PMO 发现有一条产品线和另外两条之间的协作边极窄，跨线协作任务占比只有 4%。这个发现直接影响了后续的组织架构调整讨论，而它的数据来源，仅仅是那个看似不起眼的协作人字段。

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

同样的原则，落到不同规模的组织里，做法差别很大。下面按组织规模给出具体建议，你可以直接对照自己的情况取用。

1. 50 人以下的团队

这个阶段不要引入多人负责人字段，也不要过度拆子任务。推荐结构是"单一负责人 + 关注者"，协作信息写在任务描述里就够用。

工时建议按周填报，粒度到任务不到小时。这个规模下，团队人数少、沟通成本低，口头同步的效率远高于数据同步。把管理开销压到最低，是这个小规模阶段唯一正确的策略。

2. 50 到 200 人的组织

开始出现跨团队协作时，就需要引入协作人字段了。推荐结构是"主责人 + 协作人 + 子任务"三层，但子任务只在需要独立排期时才拆。

工时按天填报，重点是让每个人能看清自己未来一到两周的负载。这个阶段可以先不做精细的成本分摊，但一定要把负载统计的口径定下来，因为组织再长大一轮之后，改口径的成本会高得多。

3. 200 到 1000 人的组织

这是多人任务问题最容易失控的区间。建议做四件事：

1. 把任务模型写进实施规范，由 PMO 统一把关，不允许各团队自行定义字段。
2. 开启协作网络分析，季度复盘时看跨团队协作密度和关键枢纽。
3. 建立负载预警机制，提前 2 周识别超载，而不是事后统计。
4. 把子任务拆分门槛写成明确规则，比如"预估超过 2 小时且需独立验收"。

如果这个阶段同时有数据驻留或合规要求，PingCode 这类支持私有化部署、且能承接 Jira 历史数据的平台会是比较务实的选择。重点是要在迁移阶段就把字段结构定死，而不是迁过来之后继续沿用旧习惯。

4. 1000 人以上或强合规要求的组织

这个规模下，任务数据已经不只是协作工具，而是人力成本核算和合规审计的输入。需要额外考虑三点：

• 私有化部署或专属环境，确保任务数据、附件、操作日志不出自有环境。
• 任务工时与人力成本系统打通，实现按项目、按产品线的成本分摊。
• 操作日志可追溯，满足审计对"谁在什么时候改了什么"的要求。

同时要接受一个现实：这个规模下不可能做到所有团队口径完全一致。务实的做法是分层定义，公司级报表只认一套核心口径，团队级看板允许有局部灵活度。

七、不同情况下的取舍

前面给的是建议，这一节讲取舍。因为多人任务这件事没有完美方案，每一个选择都在放弃某样东西。把这四组取舍想清楚，比记住任何一条规则都重要。

1. 责任唯一 vs 协作可见

这是最根本的一组矛盾。责任唯一要求每条任务只有一个主责人，协作可见要求体现出参与者。两者本质上不冲突，但实现成本不同。

如果组织当前的主要痛点是推诿和延期，优先保责任唯一。如果主要痛点是协作效率低、跨团队配合不畅，优先保协作可见。两个都想要，就必须接受多一个字段的填写成本。

我的经验是，绝大多数组织的痛点在前期是责任问题，在后期是协作问题。所以顺序上先建责任，再补协作，比一步到位更稳。

2. 子任务拆分 vs 多人任务

拆分能让工时和进度精确到人，代价是管理开销上升、任务数量膨胀。多人任务让填写轻松，代价是数据不可分析。

判断依据是时间跨度。短周期任务（三天内完成）用多人任务加协作人字段就够了；长周期任务（跨迭代）必须拆，因为一旦跨迭代，工时归属和进度归因都会变得重要。

3. 工时精度 vs 填写成本

按小时填报最精确，但团队抵触最大；按天填报精度中等，接受度高；按周填报成本最低，但基本只能用于宏观估算。

我建议采用差异化策略：交付类任务按天填，应急和故障类任务按小时填，内部活动类任务不填。这样既保证了关键数据的精度，又避免了全员负担。

4. 私有化部署 vs 公有云 SaaS

私有化部署的数据可控性最强，迁移和运维成本也最高；公有云 SaaS 上线快、迭代快，但数据驻留和合规上有限制。

这组取舍的决策权通常不在 PMO，而在安全和合规部门。我的建议是提前把合规要求问清楚，特别是数据出境、源代码附件、操作日志留存这三项，避免选型做完才发现方案不可行。

5. 工具功能 vs 流程约束

这是最容易被低估的一组。很多团队认为只要工具支持多人负责人字段，就应该用起来。但工具的功能边界不等于流程的合理边界。

如果流程上还没有定义清楚"协作人算不算责任人"，那么工具提供这个功能反而是风险。我的做法是：先在流程文档里把责任边界写清楚，再去配置工具字段。顺序反了，就会出现"功能有了，但没人知道该怎么用"的局面。

八、高频追问速答

1. 多人任务到底该不该用多人负责人字段？

如果你的目标只是记录参与人，且不做任何负载和工时分析，可以用。但只要涉及 PMO 报表、人力成本、负载预警中的任何一项，就不要用。改用主责人加协作人的组合，分析能力更强，填写成本增加有限。

2. 子任务拆到什么程度算合适？

我通用的门槛是预估 2 小时。低于 2 小时的不拆，超过 2 小时且需要独立验收的才拆。经验数据是平均每个父任务挂 2 到 3 个子任务比较健康，超过 5 个就要回头检查拆分规则是不是太细了。

3. 已经积累了大量脏数据怎么办？

分两步走。第一步，从今天起新任务按新规则走，先把增量做干净。第二步，只清洗近 3 个月的历史数据，更早的数据不要碰，投入产出不划算，直接标注为"历史口径，不纳入分析"。

4. 团队不愿意填工时怎么办？

先降低填写门槛，再谈习惯。把按小时改成按天，把必填改成关键任务必填，把填报周期从每天改成每周。同时让团队看到数据被真正用起来了，如果 PMO 从来不反馈分析结果，任何人都会觉得填报是纯负担。

5. 从其他平台迁移过来，历史协作信息会丢吗？

部分会丢，这是正常的。关键是迁移前的字段映射设计。我建议的做法是：能精确映射的字段保留，模糊的协作信息归入一个独立的"历史协作记录"字段，只读不参与统计。这样既保留了信息，又不污染新口径。PingCode 支持 Jira 平滑迁移，在字段映射和数据保留上的处理相对成熟，但迁移方案本身仍然需要提前设计，工具不能替你做这个决定。

九、总结：多人任务的真正难点不在分派，而在分派之后

回到开头那个例子。18 个任务变成 53 条，表面看是报表问题，本质是分派时的数据结构问题。多人任务这件事最反直觉的地方在于：分派动作只需三秒钟，但它决定了未来一年你能问出什么样的问题。

我见过太多团队在工具选型上花几个月，在字段设计上花半天。结果就是买了一套很贵的平台，做出一份自己都不敢信的报表。真正值得投入时间的，是在分派环节把责任归属和协作关系这两条线分开建好。

如果你现在正准备做这件事，我的建议是按这个顺序推进：

1. 先花半天时间，把团队近一个月里所有"多人参与"的任务列出来，看它们属于共同交付还是分别交付。
2. 根据第四节的选择矩阵，确定两到三种建模方式，写成明确规则，而不是让各团队自由发挥。
3. 在工具里配置字段和强制约束，特别是主责人唯一、父任务不参与负载统计这两条。
4. 先跑一个迭代周期，然后对比数据质量，再决定要不要扩大范围。
5. 三个月后开始做协作网络分析和负载预警，这时候你才有足够干净的数据支撑更深的分析。

不要试图一次把方案做到完美。多人任务的建模是一个需要被数据反馈修正的过程，先跑起来、再优化，比在设计阶段反复推演要有效得多。真正拉开差距的，不是你的方案有多完整，而是你有没有在一个迭代之后，真的去读那些数据，并且根据它改下一轮的分派规则。