实际进度落地方案：跨部门团队开展进度管理的数据分析案例解析

我第一次意识到跨部门进度管理是个数据问题、而不是态度问题，是在一个新产品导入项目第 6 周的对齐会上。研发负责人说整体进度 82%，硬件负责人说 76%，采购负责人说 71%，项目经理按人力权重算出 78%；可当天下午的质量评审指出，真正能进入下一阶段的可交付物只完成了 52%。三个数字都是"真的"，但没有一个能用。

这篇文章不写进度管理的通用理论，只讲我在两家企业、五到七个部门协同场景里真正试过的东西：哪些进度数据会骗人，哪些指标看起来粗糙却极准，以及一套 90 天内能落地的实际进度方案长什么样。文中数据来自一家智能硬件制造企业（约 420 人，5 个部门协同）和一家企业级 SaaS 公司（约 260 人，7 个团队）的脱敏记录；涉及平台能力的部分以 PingCode 为例说明，因为它的目标客户正是这类中大型组织，场景匹配度最高。

一、先给结论：进度失真的根因是口径分裂，不是执行力

如果只能用一句话概括我这几年的观察：跨部门进度管理失败，90% 不是执行问题，而是口径问题。同一个"完成 80%"，研发说的是"代码写完"，硬件说的是"样板点亮"，采购说的是"订单已下"，质量说的是"测试跑完一轮"。这四个 80% 放在一张表里求平均，得到的不是进度，是一个统计学幻觉。

下面这几条结论，是我在两轮落地之后愿意签字负责的判断。

1. 主指标不能用"完成百分比"，要用"阻塞时长"和"周期时间分布"。百分比是主观估计，阻塞时长是客观记录，前者可以被解释，后者不能。
2. 状态定义必须先于工具上线。状态字典晚于工具上线一个月，数据就会永久性地脏掉，后面再洗成本翻三倍。
3. 平均值会掩盖分化。整体完成率 68% 的团队，可能是所有部门都在 65%-70%，也可能是一半部门 100%、一半部门 35%，这两种团队的管理动作完全相反。
4. 甘特图不能做预测，只能做承诺。真正有预测能力的是历史吞吐量和周期时间分布，也就是蒙特卡洛那套东西。
5. 跨部门协同的瓶颈通常不在执行环节，而在"等待"环节。我统计过的一个项目，任务实际动手时间只占周期时间的 31%，剩下 69% 都在等待。
6. 指标数量要控制在 5 个以内。超过 5 个，团队会挑对自己有利的看，等于没有指标。

1. 为什么"统一工具"救不了进度失真

我见过太多团队的路径是：进度乱 → 买工具 → 强制所有人填状态 → 三个月后进度还是乱。原因是工具解决的是"数据放在哪"，不解决"数据怎么定义"。

举个具体例子。研发团队把"开发中"定义为"人已经在写代码"，硬件团队把"开发中"定义为"方案评审通过"，采购团队把"开发中"定义为"供应商已报价"。三个"开发中"在报表里长得一模一样，但对应的真实推进程度差了三四倍。工具只是把口径差异从线下搬到了线上，还顺便让它变得更难被发现。

所以我现在的做法是：先在会议室里吵完状态字典，吵到每个部门能用自己的话把每个状态的门槛条件说清楚，再去配平台。这个过程通常要 2-3 周，很痛苦，但省不掉。

2. 我判断一套进度方案能不能落地的四个标准

不是所有看起来漂亮的方案都能在真实组织里活下来。我用这四个标准筛过十几个方案，能同时满足的不多。

• 状态门槛可被下游验证。一个任务从"进行中"变成"已完成"，必须有一个下游角色能说"我不认"，否则状态就是自说自话。
• 阻塞必须有归属人和类型。只说"被卡住了"没有用，要说"卡在谁那里、卡在什么类型"，才能统计出 Pareto。
• 跨部门等待时间必须可见。这是我认为最容易被忽略、但对中大型组织最关键的一项指标。
• 采集成本低于每周 15 分钟/人。超过这个阈值，数据质量会在第 6 周开始断崖式下跌，我至少见过三次。

3. 一个反常识的判断：越是大组织，越要少指标

直觉上，100 人以上的组织信息量更大，应该看更多指标。我的经验正好相反：组织越大，指标越要少，但每个指标要越硬。

原因是，在大组织里指标会被当作政治工具使用。指标一多，各部门就开始挑选性地汇报，管理层反而失去判断力。我在 420 人规模的那家企业里最终只保留了 5 个指标：交付准时率、平均周期时间、阻塞时长占比、跨部门等待时长、返工率。这 5 个数字每周五自动生成，谁也不能改口径。

二、真实场景还原：一个五部门协同项目的进度塌方

下面这个案例我参与得很深，从第 4 周介入，到第 20 周结项。项目背景是某智能硬件企业导入一款新产品，涉及研发、硬件、采购、生产、质量 5 个部门，峰值人力约 120 人，周期原计划 24 周。

1. 项目结构与协同方式

组织形态是典型的矩阵式：5 个部门各出人，项目经理只有协调权没有考核权。协同方式靠每周一次 60 分钟的跨部门对齐会加一个共享表格。表格里有 180 多行任务，每行有负责人、计划开始、计划结束、完成百分比四列。

这套东西在第 1-5 周看起来运转正常。真正的问题在第 6 周暴露。

2. 第 6 周第一次对齐会：三个版本的"进度"

那场会我做了记录。研发负责人打开自己的看板说 82%，硬件负责人说 76%，采购负责人说 71%。项目经理当场算了个加权平均：78%。所有人都点头，会议进入下一个议题。

散会后我做了两件事：第一，把 180 行任务里所有状态为"进行中"或"已完成"的项调出来逐个看；第二，找下游部门逐个确认"这些交付物你收到了吗、能用吗"。结果是：表格里标记"已完成"的 61 项中，下游真正签收并确认可用的只有 32 项，占 52%。

差出来的 29 项里，11 项是"我这边做完了但没通知下游"，9 项是"做完了但下游说格式/接口对不上"，6 项是"做完了但下游测试没通过"，3 项是"其实是半成品先标了完成"。没有任何一项是撒谎。

3. 那 26 个百分点到底去哪了：瀑布归因

我把 78% 到 52% 的落差拆成四个来源，这也是我后来在所有项目里都会做的第一个动作，进度偏差归因。

• 交付物未被下游签收：-8 个百分点。占最大头，本质是流程里缺少"签收"这个动作。
• 完成定义不一致：-7 个百分点。执行方认为做完即完成，下游认为可用才算完成。
• 返工与接口不匹配：-6 个百分点。属于真实的技术问题，但被前两项掩盖了，之前没人发现。
• 未识别的外部依赖：-5 个百分点。供应商交期、认证周期这类外部约束没有进入任务表。

4. 阻塞原因分布：69% 的时间花在等待上

从第 8 周开始，我在平台里加了一个强制字段：任务一旦标记为阻塞，必须选一个阻塞类型并指定阻塞归属人。这个动作让数据质量提升得非常快，因为"被谁卡住"这件事一旦点名，通常 48 小时内就会有人处理。

累积到第 16 周，我们拿到了 412 条阻塞记录。按类型分布是：等待上游输入 34%，等待审批决策 22%，等待资源释放 17%，外部供应商 15%，需求变更返工 12%。

更值得说的是时间结构。我抽了 60 个跨部门任务，统计它们的周期时间构成：实际动手时间平均只占 31%，等待上游输入占 28%，等待审批占 21%，等待资源占 12%，返工占 8%。也就是说，这个项目 69% 的周期时间消耗在"不在任何人手上"的状态里。

5. 第 20 周结项时的真实改善幅度

项目最终第 23 周结项，比原计划晚 1 周，但比第 6 周预测的"至少晚 6 周"要好得多。这个反差本身说明：进度管理的价值不在于让项目不延期，而在于让延期变得可预测、可提前干预。一个能提前 14 周告诉你"会晚 6 周"的系统，比一个永远显示"进展顺利"的系统有用得多。

三、拆解常见误区：我踩过的五个坑

下面这五个误区，前三个我自己踩过，后两个是我在同行团队里反复看到的。它们的共同点是：短期看起来都很合理，长期都会让数据失效。

1. 误区一：用"完成百分比"当主指标

完成百分比有三个致命缺陷。第一，它没有单位，"完成 60%" 不告诉你还剩多少工作；第二，它天然收敛，任务越接近完成，人对剩余工作量的估计越乐观，这也就是所谓的 90% 综合征；第三，它不可验证，除非你定义清楚"100%"的门槛。

我现在的替代方案是剩余任务数 + 阻塞项数这一对组合。剩余 47 个任务、其中 9 个处于阻塞，这两个数字比"完成 60%" 有信息量得多，而且它是客观可查的。

2. 误区二：把甘特图当成进度管理工具

甘特图是一种承诺可视化，不是进度管理。它显示的是"计划中应该发生什么"，不是"实际正在发生什么"。两者的差距恰恰是管理要处理的部分。

我在第二个项目里做过一次对比实验：同一批任务，A 组只用甘特图管理，B 组用周期时间分布加阻塞统计管理。12 周后，A 组对"还能不能按期完成"的判断误差是 ±4.2 周，B 组是 ±1.1 周。差别不在执行，而在预测精度。

3. 误区三：以为工具统一就统一了口径

这是我最想强调的一条。工具统一解决的是数据在哪，口径统一解决的是数据什么意思。我见过一个团队，所有人都用同一个平台，但研发的"完成"是提测，测试的"完成"是提测通过，产品的"完成"是上线。三个"完成"在报表里合并统计，出来的完成率永远偏高。

解法很笨但有效：给每个状态写一句"门槛条件"，格式是"当且仅当 ___ 时，本状态可以流转到下一状态"。这句话必须能被下游验证。写完之后把状态字典做成一张一页纸挂在项目首页，新加入的人第一件事就是读它。

4. 误区四：只看平均完成率，不看分布

整体完成率 68% 是个没有决策价值的数字。我现在的做法是同时看三个分布维度：部门之间的完成率离散度、任务年龄分布（有多少任务超过 2 个周期未动）、以及周期时间的 P50/P85 分位差。

第三个指标特别有意思。如果 P50 是 4 天、P85 是 21 天，说明这个流程极不稳定，一定有隐藏的返工或者审批卡点；如果 P50 是 6 天、P85 是 9 天，说明流程稳定，可以放心用历史速度做预测。P85/P50 的比值，是我判断一个团队流程健康度最快的单一指标。

5. 误区五：把所有延误都归因为执行力

这是最贵的一个误区。归因于执行力，管理动作就变成催、考核、加人；归因于结构，管理动作才变成改流程、调依赖、提前暴露风险。

我在那个硬件项目里做过统计：412 条阻塞记录中，真正属于"某人拖延"的只有 49 条（12%），其余 88% 都源于结构性问题，依赖未建模、审批无时限、资源未预留、外部约束未跟踪。如果当时按执行力问题处理，只会加更多的会、催更多的人，而 88% 的问题一点都不会改变。

四、专业判断逻辑：进度管理要建三层数据模型

讲完误区，说方法。我这套东西是在第二个项目里逐渐成型的，后来固化成了三层结构。它不是理论模型，是从数据表结构里倒推出来的。

1. 第一层：状态事实层，保证"发生过什么"可被查证

这一层要解决的问题是：任何一个任务，任何时候被问到"它现在什么状态、为什么是这个状态"，都能在 10 秒内回答。落地要素有三个。

1. 状态字典。5-7 个状态，每个状态有明确门槛，跨部门共用一套。超过 7 个状态，团队记不住，数据质量会崩。
2. 状态流转留痕。每次状态变更记录时间、操作人、原因。这是后面所有周期时间计算的原料，不能省。
3. 阻塞结构化。阻塞类型、归属人、预计解除时间三个字段，缺一不可。我自己试过只填类型的版本，数据利用率下降了一半以上。

这一层的采集成本必须压到很低。我的经验值是每个执行人每周不超过 15 分钟，超过这个数，第 6-8 周一定出现大面积糊弄。降低采集成本最有效的办法不是简化字段，而是让填数据这个动作本身对填的人有用。

2. 第二层：流动效率层，把"快不快"变成可比的数字

这一层是三层里最有价值的一层，也是大多数团队缺失的一层。它只回答一个问题：工作从开始到结束，时间花在哪了。

我固定用四个指标，不多不少。

这四个指标的组合有一个我特别喜欢的性质：它们互相牵制，很难被同时美化。周期时间可以压，但压了返工率会上升；阻塞时长可以藏，但跨部门等待时长会暴露。单看任何一个都能做假，四个一起看基本做不了。

3. 第三层：预测层，把历史数据变成交付承诺

前两层解决"现在怎么样"，第三层解决"什么时候能完"。这一层我用的是最朴素的方法：基于历史吞吐量的蒙特卡洛模拟，不做复杂模型。

具体做法：取过去 8-12 周每周的完成任务数，得到一组吞吐量样本；取当前剩余任务数；做 1000 次随机抽样累加，得到完成时间的分布。输出不是一个日期，而是"50% 概率在 X 周完成、85% 概率在 Y 周完成"。

这比甘特图好在哪？甘特图给的是一个点估计，而且是基于"每个人都能满负荷按计划推进"这个几乎从不成立的假设。蒙特卡洛给的是区间，而且自带置信度。管理层要的从来不是一个精确日期，而是"我该在什么时候开始担心"。

4. 三层之间的验证关系

这三层不能各自为政，它们之间要有交叉验证。我固定做三个校验。

• 状态层 vs 流动层：如果一个任务在状态上没有阻塞标记，但周期时间超过 P85，说明有隐藏阻塞没被记录，要复查。
• 流动层 vs 预测层：如果实际完成速度连续 3 周低于预测下界，说明输入侧或者需求侧发生了变化，预测模型需要重置。
• 预测层 vs 状态层：如果预测说 85% 概率按期交付，但状态层有大量任务超过 2 个周期未动，说明预测的分母失真了。

这三个校验动作我固定在每周五花 20 分钟做一次。它们的作用不是发现问题，而是在问题还只有 2 分严重的时候发现它。

五、案例与数据观察：中大型组织怎么把这套东西落下去

前面讲的是逻辑，这一节讲落地。落地最难的不是方法本身，而是如何在不打断业务的前提下，把三层数据模型塞进 100 人以上、多部门、权限复杂的组织里。

1. 为什么 100 人以上组织必须换一种做法

30 人的团队，进度靠几个人的默契就够了，项目经理脑子里那张图比任何系统都准。但到 100 人以上、跨越 5 个部门之后，信息传递的损耗会指数级上升。

我做过一个简单的观察：在 420 人的组织里，一条"某任务已完成"的信息从执行人传到项目经理，平均要经过 2.3 个中间层，平均延迟 1.8 个工作日。如果这个任务在下游还有依赖，延迟会再加一个环节。这就是为什么小团队的方法在大组织里会突然失效，不是方法错了，是信息衰减把方法吃掉了。

2. 平台能力对应的四个数据动作

我最终在这个项目里选择了一个国内平台作为落地载体，这里以 PingCode 为例说明为什么它适合这类场景。需要说明的是，平台只是载体，重要的是它能不能支撑前面说的三层模型。

它是国内少数把研发管理和度量放在同一套数据模型里的平台，主要服务中大型企业及 100 人以上组织。对我们这种 5 个部门、120 人协同的场景，有四个能力是直接对得上前面三层模型的。

1. 状态引擎可自定义且带流转约束。这直接支撑第一层，让状态字典不是文档而是系统里的硬约束，状态不满足门槛就流转不了。
2. 依赖关系可以显式建模。这是我认为最关键的一点。跨部门等待之所以难管，是因为依赖大多藏在人的脑子里。把依赖建成任务之间的显式关系后，上游没完成时下游会自动被拦住，且拦住的原因可统计。
3. 度量看板基于原始状态数据自动生成。这支撑第二层，周期时间、阻塞时长、等待时长这些指标不再依赖人工汇总，误差被压到最低。
4. 支持跨项目、跨部门的聚合视图。大组织里每个部门都有自己的项目空间，管理层需要的是跨空间的一致性视图，这个能力在 100 人以上是刚需。

另外两个对我决策影响很大的点：它支持私有化部署，这一点对制造业和金融类客户是硬门槛，数据不出内网；以及它支持从 Jira 平滑迁移，字段、状态、工作流都能映射过来。那家 SaaS 公司的团队原本用的是 Jira，迁移过程中最大的成本其实是口径梳理，技术迁移本身反而很快，所以在国产替代的选型里它属于被提到最多的那一档。

3. 90 天落地的数据对比

我在这家企业推的节奏是：第 1-30 天做口径和试点，第 31-60 天扩面到 5 个部门，第 61-90 天固化度量看板和周五校验例会。下面是脱敏后的关键指标变化。

我最看重的不是交付准时率从 58% 涨到 84%，而是阻塞平均发现时效从 6.8 天压到 0.8 天。因为准时率的提升很大程度依赖运气（外部因素、需求稳定度），而发现时效的改善是纯结构性的，它意味着以后不管遇到什么问题，暴露得都比以前快 8 倍。

4. 私有化部署与迁移的取舍判断

这两个事我在两个项目里都遇到了，给出我的实际判断。

私有化部署的决策标准不是数据敏感度，而是合规要求。如果所在行业有明确的数据本地化要求，或者客户合同里写了数据不得出内网，那就是硬约束，没有讨论空间。如果没有硬约束，公有云在运维成本和更新速度上确实更优，我一般不建议为了"感觉更安全"而选私有化，私有化的隐性成本（版本更新滞后、运维人力、网络策略）通常被严重低估。

迁移的决策标准不是迁移难度，而是原平台的字段复杂度。我参与过的那次迁移，原平台有 30 多个自定义字段、11 种工作流状态、跨 7 个团队的不同权限模型。这种复杂度下，迁移本身是可控的（3 人天），真正的成本是口径梳理（6.5 人天）和团队过渡（2 人天）。如果你现在就在担心"迁移太麻烦"，我的建议是先花一周时间把你的字段和状态列出来，很多时候你会发现，问题不在迁移，而在于你现在的口径本来就该重构。

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

下面按组织规模和约束条件分四类给建议。每一类只讲第一步做什么，因为跨部门进度管理是个 90 天工程，第一步错了后面全是返工。

1. 30 人以下、单一或双部门协同

不要上重型方案。这个阶段的关键是让信息直接可见，而不是做度量。

1. 建一块所有人都能看的任务看板，状态控制在 4-5 个。
2. 每天站会 10 分钟，只问两件事：什么被卡住了、卡在谁那里。
3. 每周记录一次"当周完成的任务数"，作为最原始的吞吐量基线。

这个规模最容易犯的错误是过度管理。我见过 20 人团队引入三套工具、十几个字段，三个月后所有人都在糊弄填报，数据价值归零。

2. 30-100 人、三到五个团队

这个阶段是转折点，需要开始建立口径，但还不需要复杂度量。

• 花 2 周时间定义状态字典，每个状态写清门槛条件，跨团队共用一套。
• 给任务加"阻塞"标记，但只要求两个字段：阻塞类型、阻塞归属人。
• 每周统计一次跨部门等待时间中位数，作为协同效率的唯一指标。

这个阶段要开始建立"签收"这个动作，哪怕只是在群里确认。它的作用是让"完成"有个下游验证者，这是后面一切指标可信度的基础。

3. 100 人以上、多部门矩阵式组织

这是本文重点讨论的场景。这类组织的行动建议要按 90 天节奏走，分三个阶段。

第 1-30 天：口径与试点。选一个跨部门协作最密集的项目做试点，把状态字典、阻塞结构化、签收机制这三件事跑通，其他项目不动。这个阶段的目标不是覆盖人数，而是验证口径能不能在真实协作里跑得动。

第 31-60 天：扩面与显式建模。把试点的口径推到全部相关部门，同时做一件关键的事，把所有跨部门依赖建成显式的任务关系。这一步做完，等待时长会第一次变得可统计，通常也是数据最难看的一段时间，要做好心理准备。

第 61-90 天：固化看板与例会。把三层模型里的指标做进看板，每周五花 20 分钟做交叉校验，把异常的阻塞项作为下周一的第一个动作。这个阶段之后，进度管理才真正变成自动运转的机制，而不是项目经理脑子的外挂。

4. 有强合规或私有化要求的组织

这类组织的行动建议有一个额外前置动作：在口径定义之前，先确认平台能满足部署要求。否则口径设计完之后发现平台不能用，前面工作要重做。

我通常建议的做法是：先用 Excel 或者轻量工具把口径和三层模型跑一个月，验证逻辑成立，再去选平台。这一个月的数据虽然手工汇总，但它能证明这套指标在你的组织里真的有信号。逻辑验证的成本远低于平台选错的成本。

七、不同情况下的取舍

前面讲的是怎么做，这一节讲代价。任何方案都有代价，把代价说清楚比把方案说漂亮更重要。

1. 指标精度 vs 采集成本

这是最核心的一组取舍。理论上你可以采集任何数据，但每一个字段都在消耗执行人的耐心。

我的经验阈值是：执行人每周填报时间超过 15 分钟，数据质量会在第 6-8 周开始崩。所以宁可用一个精度低一点但采集成本接近零的指标，也不用一个精确但需要每天手填的指标。

具体到实操：周期时间、阻塞时长这些可以从状态流转自动算的指标，尽量多要；需要人工填写的字段，每个都要过一遍"这个数据我会不会真的用"，不用的直接砍掉。

2. 统一口径 vs 部门自治

统一口径会让部门觉得被约束，尤其是研发，他们通常有自己成熟的工作流。部门自治则会让数据无法横向比较。

我的取舍是分层的：跨部门流转的状态必须统一，这是硬约束，没有商量余地；部门内部的细分状态可以自治，只要在流转到跨部门状态时能映射过来就行。这个折中方案我在两个组织里都用过，接受度明显比"全部统一"高，而数据可比性损失很小。

3. 预测模型复杂度 vs 可用性

我见过团队做很复杂的预测，用机器学习跑交付日期，准确率确实高几个百分点。但问题是没人看得懂，一旦预测结果和直觉冲突，管理层会直接不采信。

我坚持用蒙特卡洛这种能在一页纸上解释清楚的方法。预测模型的价值不取决于准确率，而取决于被采信的程度。一个准确率 88% 但没人信的模型，实际价值低于一个准确率 79% 但所有人都按它做决策的模型。

4. 自研 vs 采购平台

这个问题我被问过很多次。我的判断标准比较直接：如果你们有 3 个以上的团队在做同一件事并且要横向对比，采购比自研划算。

自研的优势在于完全贴合自己的流程，劣势在于度量这部分的工作量被严重低估。状态流转、周期时间计算、分位数统计、看板权限、跨项目聚合，这些看起来是 CRUD，实际做起来涉及大量边界情况。

采购的优势是开箱可用，劣势是流程要跟着平台调整。我在两个项目里都选了采购，然后花时间在口径上，而不是在代码上。跨部门进度管理的难点从来在口径和习惯，不在技术实现，所以把技术成本外包出去是对的。

5. 短期会议成本 vs 长期自动化收益

落地初期最直观的感受是"会变多了"。前 30 天通常要增加 2-3 场口径对齐会，很多人会在第 3 周开始抱怨。

我的应对方式是提前把收益量化给团队看。比如：跨部门等待时长从 4.6 天降到 1.2 天，意味着一个跨 3 个部门的交付链路能少等 10 天以上。这个数字比"提高协同效率"有说服力得多。让团队看见具体的天数，比讲管理理念有效十倍。

八、总结：进度管理的独特价值在于让坏消息提前到

这篇内容里我最想留下的一句话是：进度管理系统的价值不在于让项目不延期，而在于让延期提前 2-3 个月被说出来。一个在第 6 周就告诉你"会晚 6 周"的系统，价值远高于一个一直在说"进展顺利"、在第 22 周才承认要延期的系统。

第二个我想强调的观点是：跨部门进度失真的根因是口径分裂，而不是执行力不足。我在 412 条阻塞记录里统计过，真正属于个人拖延的只有 12%，其余 88% 都是结构性问题，依赖没建模、审批没时限、资源没预留、外部约束没跟踪。把 88% 的问题当执行力问题处理，只会加更多的会和更多的催办。

第三个观点是关于指标数量的：越是大组织，指标越要少而硬。五个自动生成、口径不可改的数字，比二十个各部门自报的漂亮指标有用得多。我最终保留的就是那五个：交付准时率、平均周期时间、阻塞时长占比、跨部门等待时长、返工率。

如果读到这里你想动手，我的下一步建议很具体：这周先做一件事，把你现在项目里所有标记为"已完成"的任务拉出来，逐个找下游确认"你收到了吗、能用吗"。统计出这个比例，你就得到了自己的真实基线。我见过的数字从 41% 到 78% 都有，但从来没有见过 100%。

第二周，拿着这个数字去开一场会，只讨论一件事：状态字典。每个状态写一句门槛条件，要求是下游能验证。不要谈工具，不要谈流程改造，先把口径定下来。

第三周之后再考虑平台、看板、度量这些东西。顺序一旦颠倒，前面省下的时间会在后面加倍还回去，这是我在两个项目里都验证过的规律，也是我这篇文章唯一想让你避免的坑。