关注人怎么做？实施团队最佳实践：任务管理从0到1

2022 年 3 月，我接手了一个实施中心的任务管理改造。当时这个中心有 47 名实施顾问，同时在 12 个客户现场并行交付，任务管理的主要载体是 12 个微信群加 9 张 Excel 周计划表。我第一次做基线盘点时，拿到的一个数字让我至今记得很清楚：随机抽取 100 个标记为"进行中"的任务，只有 31 个的状态是准确的，其余 69 个要么早已完成没人改状态，要么被客户侧卡住没人吭声。

更难受的是成本。项目经理平均每人每周要花 4.2 小时收集进度、拼周报、核对人力投入，一周 40 小时，超过 10% 的时间花在"问别人在干什么"上，而这个动作本身不产生任何交付价值。

后来 18 个月里，我们把这个中心从"Excel + 微信群"推到平台化管理，任务状态更新延迟从平均 2.8 天压到 0.5 天，71% 的"状态失真"降到 9% 以内。但真正决定成败的，不是我们换了一套什么系统，而是我们花了三个月时间先解决"人"的问题：谁在什么角色上、能承担多少、怎么表达"我卡住了"。这篇文章就是我复盘的完整过程。

一、先把结论摆出来：任务管理从 0 到 1，"关注人"到底在关注什么

我见过太多实施团队把"任务管理"理解成"任务清单管理"，结果做成了给领导看的进度看板，顾问一边填一边骂，数据还不可信。0 到 1 阶段真正要解决的，是人的表达成本和协作摩擦，而不是管控精度。

1. 结论一：0 到 1 的第一目标不是"管得住"，而是"说得清"

任务管理做不起来的团队，问题几乎从来不是"管得不严"，而是"说不清楚"。任务卡在哪里、卡了多久、为什么卡、谁该动，这四件事在 Excel 和微信群里基本靠记忆和追问。

所以从 0 到 1 的第一目标应该是：让一个顾问在 30 秒内把"我现在的状态"准确表达出来，并且这个表达能被项目经理直接用于决策。所有设计都要围绕这个目标，不服务这个目标的字段、流程、审批，一律先砍掉。

2. 结论二：实施团队的任务管理天然是双维度，缺一个都会崩

研发团队的任务管理基本是单维度的：任务挂在需求/迭代下面，人的维度靠迭代容量间接体现。实施团队不一样，它同时存在两个必须并行维护的维度。

• 项目维度：某个客户的上线里程碑、阶段交付物、验收节点，这是对客户承诺的秩序。
• 人的维度：某个顾问同时被 3 个项目占用，本周可用 2.5 天，下周要出差，这才是内部排兵布阵的秩序。

我踩过的最大坑，就是第一版设计只做了项目维度。结果项目 A 的进度看板很漂亮，但顾问小张在三个项目里都显示"进行中"，实际上他已经连续加班两周，第三个项目的任务两周没动过。没有人的维度，项目维度的数据全是幻觉。

3. 结论三：顺序必须是"人 → 规则 → 节奏 → 工具"，反过来一定返工

这是我用真金白银换来的判断。绝大多数团队的做法是：先选一套系统，导入任务，然后要求大家填。三个月后数据失真，开始加考核，六个月后团队开始用微信群绕过系统，系统变成周报素材库。

正确的顺序是把工具放到最后。原因很简单：工具是规则的放大器，规则不清的时候，工具只会把混乱放大得更快、更贵。

4. 结论四：100 人是一条真实的分水岭，不是玄学

我参与过 8 人到 400 人不等的实施组织，可以比较确定地说：100 人以下，任务管理靠规则 + 一个轻量工具就能跑通；超过 100 人，跨部门资源池、多项目组合、权限与数据隔离会变成硬约束，轻量工具会开始反向拖累。

这不是说小团队不需要好工具，而是说小团队的瓶颈在"愿不愿意用"，大团队的瓶颈在"能不能支撑复杂组织"。前者靠人和规则解决，后者必须靠平台能力解决。后面第六节我会按规模分别给出建议。

二、为什么实施团队的任务管理特别难？三个我亲历的场景

讲方法之前，先把痛点说透。实施团队和研发团队、销售团队的差异，决定了它不能照搬任何一套现成模板。

1. 场景一：顾问在客户现场，任务状态天生滞后

研发同学坐在工位上，改完代码顺手更新状态。实施顾问在客户会议室里，被客户拉着开了两个小时会，下午又处理了一个数据迁移异常，晚上回酒店才想起来某个任务其实上午就完成了。

这不是态度问题，是场景问题。我们没有足够多的机会做状态更新，也没有足够低的更新成本，打开电脑、登录系统、找到任务、选状态、写备注，一套下来 90 秒，人在疲惫状态下一定会拖延。

所以我在第二版设计里做了一件事：把状态更新的动作压缩到 15 秒以内，并且允许在移动端完成。不要试图用考核解决场景问题，那是管理上的偷懒。

2. 场景二：项目经理的"周报地狱"

2021 年，我统计过我们中心项目经理的周内时间分布。一个典型项目经理，周一下午到周二上午基本都在做一件事：逐个问进度、填汇总表、把 12 个客户现场的碎片信息拼成一份周报。周三到周五，这份周报的时效性已经衰减了一半。

最讽刺的是，这份周报最大的消费者是项目经理自己，他需要它来安排下周的排兵布阵。如果信息采集方式和消费方式是同一个人，那说明这个流程没有被工具化，只是被仪式化了。

3. 场景三：跨项目抢人，谁的优先级都不算数

实施团队最典型的冲突是：项目 A 的顾问被项目 B 的客户投诉拉走两天，项目 A 的里程碑因此延期，项目经理 A 找中心负责人要人，负责人临时从项目 C 抽一个新人顶上，项目 C 的质量出问题。

这类冲突在 Excel 时代根本无法提前发现，因为"人的可用容量"从来没有被显式记录下来过。所有人都知道小张很忙，但没人知道小张下周到底还剩多少小时、哪个项目占用了他最多的注意力。

4. 场景四：交付节奏和任务节奏不匹配

实施项目的节奏是由客户里程碑驱动的，可能是两周一次阶段验收；但任务的实际执行节奏是天级别的。用里程碑的粒度管天级别的执行，必然导致"前松后紧"，上线前两周团队通宵，其余时间填不满。

解决这个问题的关键，是把里程碑拆成"以人为单位的周承诺"，而不是"以项目为单位的任务清单"。这一点在第四节会展开。

三、五个高频误区：把"关注人"做成了"管住人"

凡是打着"关注人"旗号做任务管理的团队，有一多半最后都做成了监工。我把见过和踩过的坑归成五类。

1. 误区一：先上工具，后定规则

典型表现是老板拍板买一套系统，IT 部门两周完成部署，然后通知下周一全员启用。结果第一周大家都在问"这个字段填什么""这个状态选哪个""我这个任务该挂在哪个项目下"。

工具上线的前提是团队对三件事已经达成共识：任务的最小字段集、状态的流转规则、卡点的上报方式。这三件事没共识就上线，后面一定要推倒重来，而且第二次推行的阻力会大得多，因为大家已经有过一次"填了也没用"的体验。

2. 误区二：把任务管理做成监工系统

我见过一个团队，任务看板做得很精细，每个任务都有预计工时、实际工时、偏差率，每周公示排名。推行两个月后，顾问开始学会一件事：先把工时填得好看，再干活。

数据一旦被用于评价个人，它就会立刻失去真实性。任务管理的数据应该首先服务于"让协作顺畅"，其次才是"评估"。我的做法是：工时数据只对项目经理和本人可见，团队层面只看聚合结果，不做个人排名。

3. 误区三：颗粒度一刀切

另一种极端是把任务切得过细，"给客户发一封确认邮件"也建一个任务。团队很快就疲于应付字段，任务系统变成负担。

我的经验判断是：一个任务的合理粒度是 0.5 天到 5 天。小于 0.5 天的动作，合并成一条；大于 5 天的，拆到有明确交付物为止。超过 5 天的任务几乎一定会拖，因为它缺少"什么时候算做完"的判断标准。

4. 误区四：只看任务，不看负荷

这是实施团队最致命的一个。任务视图上一片绿色，但实际上某个顾问同时背着 3 个项目的 11 个任务，其中 4 个本周到期。他从早到晚在切换，每个任务都推进了一点，但哪个都没验收。

任务管理必须能回答"这个人本周还有多少可用小时"这个问题。如果没有容量视图，你安排的永远是任务，不是人；而实施交付的瓶颈恰恰在人。

5. 误区五：把工时填报当成任务管理

工时填报是成本核算工具，任务管理是协作工具，两者目标不同。用工时填报代替任务管理，会得到一个精致的幻觉：每个人每天填满 8 小时，但项目到底卡在哪没人知道。

我通常的做法是：工时以周为单位回顾，任务状态以天为单位流转。两者共用同一个任务对象，但不互相绑架。

四、专业判断逻辑：任务管理从 0 到 1 的四阶模型

下面这套模型是我在三个不同规模团队里反复调整后沉淀下来的，核心思路是：每一阶只解决一个问题，上一阶不达标绝不进入下一阶。

1. 第 0 阶：先画清"人的边界"，角色、责任、可用容量

这是最容易被跳过的一步，也是最重要的一步。做之前先回答三个问题：

1. 实施顾问在这个团队里有几种角色？（例如：实施顾问、高级顾问、技术顾问、项目经理、测试/培训支持）
2. 每种角色在项目中承担哪些交付物？
3. 每个人每周的可用容量是多少小时？出差、休假、内部事务各占多少？

第三个问题尤其关键。我们的经验值是：实施顾问名义 40 小时/周，实际可用于项目交付的容量按 24-28 小时估，客户现场驻场期间按 30 小时估。这个数字必须写进系统，否则排期永远是拍脑袋。

（1）如何快速建立容量基线

最省事的办法是回看过去 8 周的实际工时分布，取中位数作为基线的起点，而不是让每个人"自己估一个数"。自己估的数普遍虚高 20% 以上，因为没人愿意承认自己产能有限。

（2）容量要区分"常态"和"现场态"

实施顾问在客户现场和在公司办公的可用容量差异极大。现场态被会议、沟通、临时问题打断的概率高得多，可用整块时间可能只有 3-4 小时。建议至少设置两档容量模型。

2. 第 1 阶：统一"任务的语言"，最小字段集

我最终固化的最小字段集只有 7 个。少于 7 个说不清，多于 7 个没人填。

请注意"被阻塞"这个状态。绝大多数团队的任务管理只有"进行中"和"已完成"，所有卡点都被藏在"进行中"里。把"被阻塞"变成一等公民状态，是任务管理从 0 到 1 最关键的一次设计决策。

3. 第 2 阶：建立节奏，日、周、里程碑三层

规则定完之后，如果没有节奏驱动，两周内就会回到原样。节奏的作用是给任务系统一个"强迫被读取"的场景。

• 日节奏（15 分钟站会）：只问两件事，今天做什么、有没有被阻塞。不看任务列表，只看阻塞项。
• 周节奏（30 分钟周计划会）：项目经理基于容量视图，确认每个人下周的承诺任务，总量不超过可用容量的 85%。
• 里程碑节奏（阶段验收前 1 周）：反向核对任务完成度，识别高风险任务并提前介入。

（1）日站会为什么只问两件事

因为问第三件事就会超时。我做过计时统计：问"昨天做了什么 + 今天做什么 + 有没有阻塞"平均每人 4.5 分钟，8 个人就是 36 分钟；只问"今天做什么 + 有没有阻塞"，平均每人 1.8 分钟，8 个人 15 分钟内结束。

（2）周承诺的上限为什么是 85%

剩下的 15% 留给现场突发、客户临时问题和内部事务。按 100% 排满的团队，几乎必然在周三就开始延期，然后整周的计划失去参考价值。

4. 第 3 阶：让数据回流，用历史数据校准估算

前两阶跑顺之后（通常需要 6-10 周），任务系统里已经积累了可用的历史数据。这时候才值得做一件事：用同类任务的历史实际工时反推预计工时。

比如"数据清洗"类任务，我们统计了 6 个月的 137 条记录，发现中位数是 3.5 人天，但团队普遍预估 2 人天。于是我们把这个类别的默认预估值调整为 3.5，排期准确率立刻从 58% 提升到 79%。

数据回流不是为了考核，是为了让下一次估算更准。这个定位必须反复和团队讲清楚，否则数据会重新失真。

五、一个 47 人实施中心的 18 个月：从 Excel 到平台化

前面讲的是判断和模型，这一节讲具体怎么落地。以下数据来自我参与的一个实施中心内部复盘，样本为 1 个实施中心、峰值 47 人、跨 12 个客户现场、18 个月观察期。它是单一样本观察，不是行业统计，但过程细节是可以直接参考的。

1. 起点与基线（第 0 个月）

基线数据我前面已经提过一部分，这里集中列一下：任务状态准确率 31%、状态更新平均延迟 2.8 天、项目经理周报耗时 4.2 小时/周、任务延期率 34%、每月因资源冲突产生的返工约 84 人天。

更值得注意的是延期原因结构：34% 的延期任务中，真正因技术难度导致的只有 11%，其余 23% 是"等待客户反馈""等人""需求变更未闭环""上一环节没交付"。也就是说，三分之二的延期是协作问题，不是能力问题。

2. 转折点：为什么最终选择私有化部署的平台

2023 年第二季度我们做选型。约束条件有三个：客户现场数据不能出内网、要能承载 100 人以上的多项目并行、要能从已有的 Jira 体系平滑迁移过来，我们此前积累了三万多条历史 issue，直接废弃损失太大。

综合评估后，我们选择了 PingCode。选择它的直接原因是三点：

• 支持私有化部署。实施业务的特殊性在于，客户现场的配置数据、业务规则、接口参数往往属于客户敏感资产，内网部署是很多中大型客户的硬性要求。
• 支持从 Jira 平滑迁移。我们 3.2 万条历史 issue、47 个自定义字段、多套工作流需要映射，迁移工具直接决定了这个项目是三周还是三个月。
• 面向 100 人以上组织设计。PingCode 主要服务中大型企业及 100 人以上组织，多项目、多角色、跨部门资源池这些能力是原生的，不需要我们自己搭。

需要诚实说明的是：如果你的实施团队在 20 人以下、只跑 3-4 个客户项目，PingCode 的完整能力对你来说是过剩的，先用一个轻量看板加一套明确规则可能更划算。工具选型要和团队规模匹配，这是我前面说"100 人是分水岭"的实际含义。

3. 关键动作：先固化"人"，再固化"任务"

我们把上线拆成两期，中间隔了三周。这个安排当时被质疑太慢，事后被证明是整个项目最正确的决定。

（1）第一期：只做人

第一期只上线三件事：人员角色、周可用容量、项目成员归属。任务模块暂不开放，所有人只做一件事，每周五前确认下周的可用容量。

三周后，团队第一次有了一张"谁下周有多少可用时间"的视图，冲突立刻显性化：我们发现有 6 个人下周的承诺容量超过 45 小时，另有 4 个人低于 15 小时。这个问题在 Excel 时代存在了很久，但从没有人看见过。

（2）第二期：再上任务

第二期才开放任务模块，并且严格按第一节说的 7 个最小字段。上线第一周我们做了一件反常规的事：不要求补录历史任务，只要求新建任务按规则填。这避免了"为了填而填"的大量无效操作，也让团队第一周就体验到"信息够用"的好处。

（3）第三期：把阻塞变成日常议题

第四周开始，每日站会只看一个视图：被阻塞任务列表。项目经理的职责从"催进度"变成"清阻塞"。这个转变带来的效果超出预期，很多阻塞项其实只需要项目经理打一个电话，之前却因为没人知道而挂了两周。

4. 结果数据（第 12 个月 vs 第 0 个月）

下面是我们在第 12 个月做的完整复盘对比。数据口径统一为"上一个完整自然月"。

5. 迁移与踩坑：从 Jira 迁移的三条经验

迁移这件事，工具能力只占一半，另一半是数据治理。我们最终迁移了 32,147 条 issue，耗时 6 小时完成主体迁移，后续 5 天做校验和补充映射。

（1）自定义字段必须做减法

Jira 上有 47 个自定义字段，我们最后只迁移了 19 个。判断标准很简单：过去 6 个月被实际填写过的字段才迁移，其余全部归档成文本备注。一上来就全量迁移，会让新系统的字段数爆炸，团队抵触情绪直接翻倍。

（2）工作流要合并，不要逐条复刻

原体系有 6 套工作流，我们合并为 2 套：标准交付流和轻量支持流。合并依据是"状态集合是否一致"，而不是"项目是否相同"。

（3）历史数据的价值在统计，不在浏览

迁移完成后，谁也不会去翻两年前的单个 issue。但你需要它们来算历史工时中位数、算某一类任务的真实周期。所以迁移时优先保证时间字段和分类字段的准确性，描述文本可以适当降级。

6. 一个反例：我们做砸的那次"全量铺开"

在第 7 个月，我们试图把这个模式复制到另一个 130 人的实施部门，做法是"一次性全量上线"，没有做人维度的前置准备，直接在两周内把任务模块推给所有人。

结果是：第一个月任务创建量很高（日均 340 条），第三个月回落到 90 条，第五个月基本停用。失败原因现在看很清楚：跳过第 0 阶和第 1 阶，直接跳到工具，团队没有共同语言，工具只能放大混乱。

第二次重做时，我们按同样的四阶模型走了 14 周，效果与第一个中心接近。这个反例让我更确信顺序不可跳过。

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

下面按团队规模给具体建议。规模是最主要的判断变量，因为它决定了瓶颈是在"意愿"还是在"组织复杂度"。

1. 10 人以下的小型实施团队

这个规模不要买复杂平台。建议做法是：用一张共享看板 + 一个固定的每日 10 分钟站会 + 7 个最小字段。

关键动作只有一个：把"被阻塞"状态用起来，并且由负责人（通常是团队 leader）每天负责清阻塞。10 人以下，信息其实都在 leader 脑子里，工具只需要做备忘录，不要试图用它做管理。

2. 10-50 人的实施团队

这个区间开始出现"人不知道别人在干什么"的问题，容量视图的收益最大。

1. 先用两周建立角色和容量基线，不要跳过。
2. 再固化 7 个最小字段，并且做一次全团队宣贯。
3. 第三周开始跑日站会 + 周计划会的双节奏。
4. 第八周开始回看数据，做第一次估算校准。

工具层面，一个轻量的任务管理工具就够用。这个阶段的目标是让规则先跑起来，而不是让工具先跑起来。

3. 50-100 人的实施团队

这个区间开始出现跨部门资源池、多项目组合、区域/行业分组，工具的权限模型和数据隔离能力开始成为硬约束。

建议在选型时重点验证三件事：能否按部门/项目做数据隔离；能否同时呈现项目视图和人的容量视图；能否支持任务模板和项目模板的复用。如果这三点要自己开发来实现，那说明选的工具和你的组织复杂度不匹配。

4. 100 人以上的中大型实施组织

这个规模下，我的建议是直接上一套面向中大型企业的项目管理平台。我们当时的选型结果是 PingCode：它主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，从国产替代的角度看是相当直接的选择。

但工具只解决一半问题。100 人以上的组织，真正的难点是三层结构的一致性：中心层的资源池、部门层的项目组合、项目层的任务执行，这三层用的字段和口径必须统一，否则数据永远对不上。

（1）先定"口径字典"，再配系统

我们在第二个中心推行时，先花了一周时间做了一份 3 页的口径字典：任务状态定义、延期判定规则、容量计算方式、跨项目占用的归属规则。这份字典后来成了所有争议的裁决依据，价值远超预期。

（2）试点不要选最难的，也不要选最简单的

选一个中等复杂度、项目经理配合度高的团队试点。太简单的团队跑出好数据没有说服力，太难的团队失败会直接毁掉整个推行计划。

5. 正在从 Jira 迁移的场景

如果你的团队已有 Jira 体系，迁移决策的核心不是"能不能迁"，而是"迁多少"。我的建议是：

• 只迁近 24 个月、且状态不是"已关闭且无后续引用"的 issue。
• 自定义字段按"近 6 个月是否被填写"筛选，保留率控制在 40% 以内。
• 工作流合并到 2-3 套，不要逐条复刻。
• 迁移前先做一次字段映射表评审，让项目经理签字确认。

PingCode 在 Jira 平滑迁移上的支持，让我们这批 3.2 万条数据的迁移没有出现业务中断，这一点在实施类业务里很重要，实施团队正在客户现场交付，最不能承受的就是内部系统停机。

七、不同情况下的取舍

任何方法都有代价。这一节我把几个必须做的取舍摊开讲，包括我们当时选错又重新调整的部分。

1. 标准化 vs 灵活性

标准化能换来数据可比性，代价是牺牲部分项目特殊性。实施项目的客户差异很大，如果全部标准化，顾问会觉得"系统不了解我的项目"。

我的判断是：状态、字段、节奏必须标准化；任务模板、检查项、文档结构可以按行业或客户类型分套。不要试图标准化一切，也不要因为个别项目特殊就放弃全局口径。

2. 强管控 vs 弱管控

管控越强，短期数据越好看，长期数据越失真。我们第一版做了工时排名公示，一个月内工时填报完整率从 62% 涨到 98%，但三个月后我们用抽样核对发现真实偏差率反而从 12% 涨到了 27%。

调整后我们取消了排名，工时只对本人和项目经理可见，填报完整率回落到 89%，但偏差率降到 9%。89% 的真实数据，价值远高于 98% 的表演数据。

3. 采购 vs 自建

自建的诱惑在于"完全贴合业务"，代价是维护成本和迭代速度。我参与过一次自建，需求到上线平均 6 周，一年后核心开发离职，系统进入维护冻结状态。

我的经验边界是：通用协作能力（任务、迭代、看板、容量、权限）一律采购；行业特有的交付物管理、客户验收流程可以自建并做集成。自建只做别人做不了的那部分。

4. 私有化部署 vs SaaS

私有化部署的代价是运维成本和版本更新滞后，收益是数据可控、可深度集成客户环境。对于服务中大型企业客户的实施团队，私有化往往是硬要求，因为我们自己的系统要跟客户的网络、安全策略共存。

如果客户全部是中小型、且团队没有运维能力，SaaS 更现实。这个取舍的决策依据是客户属性，不是团队偏好。

5. 全量铺开 vs 单点试点

前面已经用反例说明过：全量铺开在 130 人部门失败了。我的建议是先在一个 30-50 人的团队跑满 8 周，产出可验证的数据，再复制。复制时保留 2 周的口径对齐期，不要直接照搬配置。

八、把"关注人"落到动作：一张可以照着做的节奏清单

说了这么多原则，最后给一张可以贴在墙上的节奏清单。这是我们在第二个中心推行时用的版本，跑了 14 周，效果与第一个中心接近。

这张表里我最想强调的是每周五上午那一条。让顾问自己确认下周容量，而不是由项目经理替他填，这个动作本身就是"关注人"。它传递的信号是：你的时间是你自己的，我们只是需要一起把它安排好。

1. 前四周的清单（如果你明天就要开始）

1. 第 1 周：把角色、责任、容量三项写成文档，和团队逐条对齐，暂不动任何工具。
2. 第 2 周：确定 7 个最小字段，找 3 位顾问做一次"填表 30 秒测试"，超过 30 秒就继续砍。
3. 第 3 周：配置工具，只开任务和容量两个模块，其余全部关闭。
4. 第 4 周：开始跑日站会 + 周计划会，只关注阻塞项，不做任何个人统计。

2. 什么时候算跑通了

我给团队的验收标准是三条：随机抽 20 条进行中的任务，状态准确率 ≥ 85%；项目经理周报耗时 ≤ 1 小时；连续四周没有出现"某个人容量超过 110% 却没人发现"的情况。

三条同时满足，才算完成从 0 到 1。在此之前，不要急着加报表、加审批、加考核。

九、写在最后：三个不太一样的判断

第一，任务管理从 0 到 1 的过程，本质是一次组织沟通方式的重构，不是一次 IT 项目。如果你的项目计划里只有"系统上线时间"而没有"规则对齐时间"，它大概率会失败。我们成功的那次，规则对齐花了 5 周，系统配置只花了 4 天。

第二，"关注人"的具体含义是：让每个人用最低成本表达自己的真实状态，并且这个表达不会被用来惩罚他。做不到后半句，前半句就是空话。我们取消工时排名的那一个月，是数据质量提升最快的一个月。

第三，规模决定路径，100 人是真实的分水岭。100 人以下靠规则和节奏就能跑通；100 人以上，你需要一套面向中大型组织的平台能力来支撑三层结构的一致性，同时要考虑私有化部署和从 Jira 平滑迁移这两个现实约束，这也是我们当时选择 PingCode 的原因。

如果你正准备开始，我的建议是：本周不要碰任何工具，先做一件事，把团队的角色、责任、每周可用容量写成一页纸，发给所有人确认。这一页纸的完成度，决定了你后面所有工作的上限。等你把容量视图建立起来，再去选平台、配流程、跑节奏，你会发现整个过程比想象中顺得多。

如果你已经在做这件事但效果不好，先别急着换系统，回头检查三个问题：状态字段里有没有"被阻塞"这一项？每个人的可用容量有没有被显式记录？数据有没有被用来做个人排名？这三个问题的答案，基本能解释你遇到的全部问题。