人力资源计划可用工时教程：产品经理最佳实践，避坑指南

人力资源计划可用工时教程：产品经理最佳实践，避坑指南

在人力资源计划中，最容易被误用的数字不是“团队有多少人”，而是“这个月有多少可用工时”。我曾经见过一个产品团队按 12 名成员、每人每月 160 小时计算，排出了 1920 小时的开发容量，结果迭代连续延期；复盘后发现，其中 240 小时被法定假期和年假抵消，约 190 小时用于会议、招聘和支持，另外还有一名核心成员实际只能投入 50% 时间。真正可交付的容量不到账面值的 65%。

这正是《人力资源计划可用工时教程：产品经理最佳实践，避坑指南》要解决的问题：可用工时不是考勤工时，也不是合同工时，更不是把员工人数乘以 8 小时之后得到的漂亮数字。它是经过假期、固定会议、支持工作、技能匹配、并行项目和风险缓冲层层折算后，团队在特定周期内能够稳定用于某类工作的时间。

一、先讲核心结论：可用工时必须从“人头”转化为“可交付容量”

1. 可用工时的正确公式

产品经理做资源规划时，建议把可用工时拆成五层，而不是直接采用“工作日 × 8 小时”的简单算法。

理论工时
= 计划工作日 × 每日标准工作小时

可用工时

= 理论工时

法定节假日与请假

固定会议与行政事务

生产支持、客服支持与线上故障处理

培训、招聘、绩效沟通等组织性工作

有效交付容量

= 可用工时

× 技能匹配系数

× 角色投入系数

× 风险缓冲系数

这几个系数不能随意拍脑袋。技能匹配系数用于反映人员是否真正具备完成任务所需的能力；角色投入系数用于处理产品经理、架构师、技术负责人等“既要交付又要承担管理职责”的岗位；风险缓冲系数则用于吸收需求变更、技术不确定性和跨团队等待。

例如，一名后端工程师理论上每月有 176 小时，扣除 16 小时会议、8 小时培训、16 小时线上支持和 24 小时年假后，剩余 112 小时。如果该工程师只有 80% 时间投入当前产品，且项目处于新技术验证阶段，需要预留 15% 风险缓冲，那么真正可以承诺的交付容量约为 76 小时，而不是 176 小时。

2. 产品经理最应该盯住“可承诺工时”

资源计划至少要区分三种口径：理论工时、计划工时和可承诺工时。理论工时用于核算劳动时间，计划工时用于安排任务，可承诺工时用于向业务承诺发布日期。三者混用，几乎必然导致计划失真。

如果一个团队只能给出“我们有 2000 小时”，却不能说明其中多少小时可以用于当前产品、多少小时必须留给支持工作，那么这不是资源计划，而只是工时总账。

3. 规划周期决定数据精度

月度计划适合做资源盘点，迭代计划适合做任务承诺，季度计划适合做招聘和外包判断。周期越长，数据越容易受到人员变动、优先级调整和假期变化影响，因此季度层面不宜使用过于精细的小时数字。

我的建议是：季度规划使用“人月”和区间，月度规划使用“人日”或“小时”，迭代规划使用任务级工作量。比如季度规划写“前端 4.5 至 5.2 人月”，比写“前端 832 小时”更诚实；到了两周迭代，再把容量换算为 320 至 360 小时，才有实际管理价值。

二、背景和真实场景：为什么产品团队总是高估容量

1. 产品经理面对的是多线程组织，而不是单一项目

在 100 人以上的中大型组织中，一个研发成员通常并不只服务一个需求池。他可能同时参与主产品迭代、客户定制、线上缺陷、技术债治理和部门公共事务。产品经理如果只看项目管理平台中“分配给当前项目”的任务，就会把未登记的隐性工作误认为闲置容量。

我在一次资源复盘中，把某产品团队一周的工时按实际用途重新归类，发现排期系统中的任务只覆盖了 68% 的时间。剩余时间主要流向四类工作：客户问题定位、跨团队接口沟通、生产环境告警和临时管理事项。原先团队被判断为“执行效率低”，重新核算后，真正的问题是资源计划没有覆盖完整工作流。

这类差异并不代表员工在“偷懒”。相反，很多支持工作对业务是必要的，只是它们没有进入产品经理的容量模型。看不见的工作不会消失，只会在上线日期附近集中爆发。

2. “每人每天八小时”不等于八小时交付

标准工作时间是法律和组织管理上的基准，不是项目执行效率的承诺。根据我国现行工时管理框架，标准工时通常以每日不超过 8 小时、平均每周不超过 40 小时作为基本口径，但实际项目还要扣除休息、会议、沟通、环境切换和非项目职责。

产品经理不应把“不能计入开发的时间”理解为浪费。需求澄清、技术方案评审、风险同步、代码评审和发布演练，虽然不一定直接产出功能，却决定了交付质量。更合理的做法是把这些活动分成“必要交付活动”和“可压缩管理活动”，而不是粗暴地全部扣除或全部忽略。

3. 中大型组织更容易出现资源重复承诺

在小团队里，资源冲突通常可以通过面对面沟通解决；在中大型组织里，同一名专家可能被三个产品线、一个平台团队和一个重点客户同时列为“已确认资源”。每个项目单独看都合理，合并后却可能达到 180% 甚至 220% 的投入承诺。

使用 PingCode 这类项目管理平台时，我建议建立组织级资源视图，而不是只让每个项目负责人维护自己的计划。资源视图至少要能看到人员、角色、项目、投入比例、周期和状态，并把“计划投入”和“实际记录”分开。对于 100 人以上的组织，项目之间的资源争抢通常不是个人排期能力问题，而是缺少统一的容量治理机制。

三、常见误区：这些做法看起来精确，实际上最危险

1. 误区一：用员工人数直接乘以工作日

这是最常见的错误。一个 10 人团队在 20 个工作日的月份里，理论上有 1600 小时，但如果其中两人要参与平台治理，一人长期承担客户支持，一人休假 5 天，团队用于版本交付的可承诺容量可能只有 900 至 1100 小时。

人数乘工时只适合做粗略预算，不能直接用于排期。尤其是核心岗位，一名架构师或测试负责人缺席，影响的可能不是 8 小时，而是整个交付链条的等待时间。

2. 误区二：把所有人的容量设置成相同百分比

很多团队会统一设置“每个人 80% 可用”。这比 100% 计划好一些，但仍然过于粗糙。初级工程师、技术负责人、产品经理、测试负责人和运维人员的非项目时间结构并不相同。

例如，产品经理可能只有 55% 时间用于需求交付，因为还要承担用户访谈、路线图、数据分析和跨部门沟通；测试负责人可能有 70% 时间用于版本测试，另外 20% 用于质量体系，10% 用于自动化建设；而专职开发人员在稳定迭代期可能达到 75% 至 85%。使用统一比例，会掩盖岗位差异。

3. 误区三：把请假当作唯一的不可用时间

请假是最容易被记录的变量，但通常不是最大变量。对于产品团队，会议、支持、需求变更和等待依赖往往比年假更影响交付。某次迭代中，假期只造成 6% 容量减少，但跨团队依赖导致 18% 的开发时间无法连续使用。

连续性比总小时数更重要。一个工程师如果每天只有两个小时可用于某项复杂开发，即使月底累计有 40 小时，也未必能完成一项需要连续上下文的任务。因此，资源计划除了计算小时，还应观察时间是否被切碎。

4. 误区四：用加班填补计划缺口

加班能在短期内增加投入，但不能稳定增加有效产出。长时间加班会提高缺陷率、返工率和人员流失风险，最终使名义工时增加、有效工时下降。

我更关注“加班后新增的有效交付量”，而不是加班小时本身。如果本周增加了 40 小时加班，却只多完成 12 小时等价产出，同时缺陷和返工增加，那么这不是产能提升，而是把下个周期的成本提前透支。

5. 误区五：把估算偏差归因于员工执行不力

任务估算偏差可能来自需求不完整、验收标准模糊、技术方案未验证或外部依赖未确认。若产品经理只统计“预计 8 小时、实际 16 小时”，却不记录偏差原因，就无法判断是估算能力问题，还是计划输入质量问题。

建议在任务复盘时至少增加一个偏差分类：需求澄清、技术不确定、外部等待、环境问题、质量返工、人员切换或原估算偏低。连续记录四到六个迭代后，团队通常能看出真正的容量损耗来源。

四、专业判断逻辑：从工时数字推导资源决策

1. 先确定“工作池”，再计算人员容量

计算可用工时之前，先把团队在计划周期内承担的工作池列完整。至少包括版本需求、缺陷修复、技术债、客户定制、线上支持、架构治理、招聘培训和跨团队协作。

如果工作池不完整，容量计算越精确，结论反而越危险。因为你是在用精确的数字覆盖不完整的事实。

• 版本交付池：当前周期需要完成并验收的功能。
• 质量维护池：缺陷修复、回归测试、自动化和稳定性建设。
• 业务支持池：客户问题、售前验证、线上故障和数据修复。
• 组织建设池：招聘、培训、技术分享和流程建设。
• 不可预见池：突发需求、依赖延期和紧急风险处理。

2. 再识别资源的“有效边界”

资源边界不只是人员名单，还包括角色、技能、权限、工作时段和上下游依赖。一个人被分配到项目，不代表他具备立即交付的能力；一个团队拥有某类技能，也不代表该技能在需要的时间点可用。

建议在资源台账中至少记录以下字段：

3. 将“人力不足”拆成三种不同问题

当需求工作量超过可用容量时，不要马上得出“需要招聘”的结论。人力不足至少有三种类型：总量不足、技能不足和时间窗口不足。

总量不足意味着所有人员的有效容量加总后仍然低于需求量，例如需要 1200 小时，团队只能提供 900 小时。此时可以考虑缩减范围、延长周期、招聘或外包。

技能不足意味着总工时可能够，但关键技能无法匹配。例如团队有 400 小时开发容量，却只有 40 小时数据安全经验，而需求需要 100 小时安全改造。继续增加普通开发资源，不一定能解决问题。

时间窗口不足意味着资源总量够，但无法在关键节点前连续投入。例如测试人员在发布前一周被其他项目占用，即使季度总容量足够，也不能支撑当前发布日期。

4. 最后才做方案取舍

资源计划不是为了证明某个版本一定能做，而是为了让取舍透明。产品经理应把取舍方案分为范围、时间、资源和质量四类，并明确哪一项可以变化，哪一项不能变化。

五、具体案例和数据观察：一个 100 人以上组织如何建立可用工时模型

1. 案例背景：四条产品线争用同一支研发团队

下面以一个使用 PingCode 进行项目协同的中大型企业情景为例。该组织约有 260 名员工，其中产品、研发、测试和运维人员约 150 人；四条产品线共用平台研发、数据分析和安全工程资源。案例数据为项目复盘中的情景模拟，用于展示方法，不代表该平台或任何企业的公开经营数据。

计划周期为一个月，共有 30 名研发相关人员参与某条产品线，其中 18 名为全职投入，12 名为跨项目共享。团队先按每人 160 小时计算，得到 4800 小时理论工时。

如果按照 4800 小时排需求，团队会得到一个看似充足的版本范围；如果按照 2180 小时承诺，产品范围需要缩减一半以上。两者之间的差距不是效率低下造成的，而是计划口径不同造成的。

2. 任务层面的工作量与人员层面的容量必须统一口径

很多团队在人员侧使用小时，在任务侧使用故事点，最后通过一个固定换算比例强行合并。这个做法只有在团队稳定、任务类型相似且历史数据足够时才可靠。

如果团队使用故事点，建议先用过去六至八个迭代建立团队级吞吐基线，再把人员容量变化映射到吞吐变化。比如过去六个迭代平均完成 42 个故事点，但下个迭代有 20% 成员休假、关键测试资源减少 25%，就不能简单承诺 42 个故事点。

如果必须将故事点换成小时，应至少区分需求类型：

• 常规业务功能：历史平均每故事点 5.5 至 7 小时。
• 跨系统接口功能：历史平均每故事点 8 至 12 小时。
• 数据迁移和权限改造：历史平均每故事点 10 至 16 小时。
• 探索性技术任务：不建议直接按故事点估算，应先设置时间盒。

这些区间只是示意基准，不能跨团队直接套用。真正有价值的是建立本团队自己的历史分布，并关注中位数、四分位数和异常任务，而不是只看平均数。

3. 用历史数据校准，而不是追求一次算准

可用工时模型不可能第一次就准确。建议每个迭代结束后比较三个数：计划可用工时、计划任务工时和实际完成工时。如果计划容量为 800 小时，任务估算为 760 小时，最终完成只有 610 小时，就要进一步拆解剩余 150 小时去了哪里。

我通常会采用“滚动四周期校准法”：第一周期建立基线，第二周期修正非项目时间，第三周期校准技能系数，第四周期确定风险缓冲。四个周期后，团队通常能把容量预测误差从 30%左右降低到 10%至15%的可管理范围。

六、在项目管理平台中落地：从字段设计到管理动作

1. 先设计最小可用的数据结构

不要一开始就配置几十个字段。资源规划的第一版只需要保证“谁、在什么时间、为哪个工作池、投入多少、实际用了多少”能够被记录和查询。

在 PingCode 这类项目管理平台中，可以把项目计划、迭代、任务、工时和成员投入建立关联，再通过项目组合视图查看共享人员的多项目负载。这里的重点不是“有没有工时字段”，而是计划工时和实际工时是否使用同一套时间范围、人员身份和工作分类。

2. 规划视图和执行视图要分开

规划视图回答“未来需要多少资源”，执行视图回答“现在实际发生了什么”。如果把两者混在一起，项目经理会为了让计划看起来合理而修改实际数据，产品经理也无法判断偏差来源。

建议使用以下两层视图：

• 资源规划视图：按月份、迭代和人员查看计划投入。
• 执行分析视图：按任务类型、项目和偏差原因查看实际投入。
• 管理预警视图：显示超负荷人员、资源冲突、容量不足和关键技能缺口。
• 复盘视图：显示计划与实际差异、延期原因和缓冲消耗速度。

3. 设置三个关键预警阈值

阈值不宜过多，否则管理者会被大量提醒淹没。对大多数产品团队，我建议先设置三个阈值。

第一是负载阈值。当某人未来两周计划投入超过可承诺容量的 100% 时，标记为超载；达到 85%至100%时，标记为高风险。第二是共享冲突阈值。当同一人员在两个项目的同一工作日被安排超过 100%时，立即提示冲突。第三是缓冲消耗阈值。当迭代前半段已经消耗超过 60%的风险缓冲时，应触发范围或时间复核。

这些阈值不是绩效标准。把 100% 负载理解为“人员必须满负荷工作”，会使整个系统变成加班驱动。阈值的作用是提醒管理者重新做选择，而不是要求员工填满所有时间。

4. 用权限设计保护数据质量

资源计划涉及人员安排、休假和投入记录，不能让所有人随意修改。建议将权限分成三层：成员维护个人不可用时间和实际工时，项目负责人维护任务和计划投入，资源管理员维护组织级容量规则和共享资源分配。

同时要保留变更记录。一个月后发现计划反复延期时，管理者需要知道是原计划不合理，还是中途发生了资源调整。如果没有历史版本，只能凭记忆争论。

七、不同情况下的行动建议：不要用同一种方法处理所有团队

1. 新组建团队：先用区间，不要追求精细

新团队缺少历史数据，成员熟练度和协作方式都不稳定。此时建议使用较大的缓冲区，例如将理论工时的 50%至65%作为首期可承诺容量，再通过两到三个迭代逐步提高。

新团队的重点不是把每个人排满，而是识别三类事实：任务平均需要多久、哪些环节最常等待、哪些岗位是瓶颈。只要能稳定记录这些信息，后续容量模型就会越来越可靠。

2. 稳定迭代团队：用历史吞吐校准小时容量

稳定团队可以同时观察小时和产出。小时用于资源分配，吞吐用于判断交付能力。若连续六个迭代都显示投入工时增加，但完成故事点没有增加，应优先检查需求拆分、返工和依赖，而不是继续增加人力。

这类团队适合建立“承诺容量区间”，例如下个迭代预计完成 35至42 个故事点，而不是承诺固定完成 42 个。区间能够反映不确定性，也便于业务方理解范围取舍。

3. 共享资源团队：先解决优先级，再解决排期

共享资源的最大问题不是算不出工时，而是多个项目都声称自己优先。资源管理员应建立项目优先级规则，例如按客户承诺、商业窗口、合规要求和技术依赖进行排序。

当同一名专家被两个项目同时需要时，不应让他自己决定加班解决，而应由项目组合负责人明确其中一个项目延后、缩减范围或引入替代资源。资源冲突必须在组织层面解决。

4. 频繁处理线上问题的团队：单独建立支持容量

如果团队每周都会被线上问题打断，就不应把支持时间藏在风险缓冲里。建议直接设置固定支持容量，例如每周保留一名工程师轮值 16 小时，或者把团队总容量的 10%至20%作为支持池。

支持池的价值在于让版本计划更诚实。即使本周没有故障，这部分时间也可以用于自动化、监控和技术债；一旦问题发生，团队不必临时从版本任务中硬挤资源。

5. 高不确定性项目：采用时间盒，不承诺完整范围

新技术验证、复杂数据迁移和大型架构改造很难准确估算。此时不适合直接给出完整功能的确定工时，可以先给出两周或四周时间盒，明确要验证的假设、输出物和继续投入的判断条件。

时间盒结束后再决定继续、缩减、替代或停止。这样可以把“估算不准”的风险转化为“阶段性决策”，避免项目一开始就背负一个无法验证的长期承诺。

八、不同情况下的取舍：可用工时不是越高越好

1. 高利用率和高可靠性之间的取舍

把可承诺容量从 70%提高到 90%，短期看似能承接更多需求，但系统抗风险能力会明显下降。任何一个请假、故障或外部依赖延期，都可能直接冲击发布日期。

如果产品处于稳定维护期，团队可以把可承诺容量设在较高区间；如果处于重大版本、技术迁移或组织变化期，宁愿保留更大的缓冲，也不要用高利用率制造虚假的确定性。

2. 借调专家和培养内部人员之间的取舍

借调专家可以迅速解决技能缺口，但会增加沟通成本和知识孤岛；培养内部人员短期效率较低，却能提高长期可持续性。对于一次性、强专业、时间紧的任务，借调或外部支持更合理；对于持续存在的核心能力，应该逐步培养内部梯队。

产品经理可以将这项取舍量化：如果外部专家能在两周内减少 80 小时返工，但每周增加 10 小时沟通成本，且任务只持续一个月，借调可能划算；如果同类需求每季度都会出现，持续借调的总成本往往高于培养内部能力。

3. 外包和内部交付之间的取舍

外包并不等于“增加可用工时”。外部团队需要需求说明、接口对接、代码评审、验收和质量管理，这些工作会占用内部人员时间。估算外包收益时，必须扣除内部管理成本。

外包更适合边界清晰、验收标准明确、技术栈成熟的任务；核心业务规则、长期架构和高频变更需求更适合内部掌握。否则，表面上减少了开发工时，实际上把工时转移到了沟通、返工和维护。

4. 压缩范围和延长周期之间的取舍

当容量不足时，压缩范围通常比压缩质量更健康。可以优先保留能够验证核心价值的最小闭环，把装饰性功能、低频场景和复杂定制延后。

但也不能把所有延期都解释为“先做最小版本”。如果业务窗口、合同承诺或合规要求明确，延长周期可能造成更高损失。产品经理需要把延期成本、范围缩减成本和增配资源成本放在同一张决策表中，而不是只比较工时。

九、避坑指南：建立可用工时计划时必须检查的十二个问题

1. 数据口径检查

• 计划周期是否统一到同一组开始和结束日期？
• 理论工时是否与实际工作制度一致？
• 请假、节假日和培训是否被重复扣除？
• 计划工时与实际工时是否使用同一计量单位？

2. 资源边界检查

• 共享人员是否同时出现在多个项目计划中？
• 关键岗位是否有明确替补，而不是只有一个名字？
• 人员投入比例是否与真实职责一致？
• 技能标签是否经过项目负责人确认，而不是只看岗位名称？

3. 交付风险检查

• 线上支持是否有独立容量，而不是隐含在缓冲里？
• 外部依赖是否有等待时间和责任人？
• 风险缓冲是否按项目不确定性调整？
• 是否设置了超载预警和资源冲突处理人？

4. 复盘有效性检查

• 是否记录计划与实际的差异？
• 是否记录差异的原因，而不是只记录结果？
• 是否连续观察至少四个周期？
• 是否根据历史数据调整缓冲系数和投入比例？

如果以上问题中有一半无法回答，当前团队还不适合进行精细化的个人工时考核。此时最应该做的是补齐工作分类和资源记录，而不是增加更多复杂报表。

十、FAQ：产品经理关于可用工时的常见问题

1. 可用工时是否应该用于个人绩效考核？

不建议直接用于个人绩效考核。可用工时是计划工具，包含团队协作、等待依赖和组织性工作，不能准确代表个人价值。若强行把“填满工时”作为考核目标，员工会倾向于拆分任务、延长记录时间，甚至隐藏真实效率。

更合理的做法是使用交付质量、目标完成度、缺陷率、风险处理和协作反馈等多维指标。工时数据可以用于识别系统性问题，但不应单独评价个人。

2. 产品经理需要精确到小时吗？

不需要所有层级都精确到小时。季度规划采用人月或区间，月度计划采用人日或小时，迭代计划才适合细化到任务级小时。精度应该与决策需要匹配，精确但不能支持决策的数据没有价值。

3. 如何处理无法提前预测的突发需求？

先定义突发需求的边界，再设置固定容量。比如把团队 10% 的容量作为紧急池，只有生产事故、合规问题或高优先级客户事件才能使用。每次使用后记录原因和耗时，连续几个月后再判断紧急池比例是否合理。

4. 任务估算总是偏低，应该增加多少缓冲？

不要直接统一增加 20%或30%。先分析偏差原因。如果主要是外部等待，应优化依赖；如果主要是需求变更，应改善评审；如果主要是技术探索，应使用时间盒。只有无法消除的不确定性，才适合通过风险缓冲吸收。

5. 使用项目管理平台后，是否可以自动得到准确容量？

平台可以帮助统一数据、关联任务、记录工时和展示冲突，但不能替团队判断哪些工作必须做、哪些技能真正匹配、哪些风险需要保留。自动化解决的是可见性和计算问题，管理判断仍然需要产品负责人、项目负责人和资源管理者共同完成。

6. 团队没有工时填报习惯，应该从哪里开始？

不要一开始要求记录所有工作。先选择一个关键项目、一个月度周期和三到五类工作类型，记录版本任务、缺陷、支持、会议和培训。只要成员能看见记录结果会用于改善排期，而不是监控个人，数据质量通常会逐步提高。

十一、下一步怎么做：用四周建立第一版可用工时模型

1. 第一周：定义口径和工作池

明确理论工时、可用工时、可承诺工时的定义，列出团队承担的全部工作类型。此时不要急着设置复杂公式，先让产品、研发、测试和运维对“哪些时间属于交付”达成一致。

2. 第二周：收集实际时间和资源冲突

记录每个人的请假、会议、支持、跨项目投入和版本任务。重点不是要求记录得非常精确，而是发现计划中没有被看见的工作。同步检查同一成员是否被多个项目重复分配。

3. 第三周：建立容量区间和风险缓冲

根据前两周数据计算团队级有效容量，设置保守、中性和激进三种方案。保守方案用于高风险版本，中性方案用于常规迭代，激进方案只能用于明确知道风险并有回滚机制的场景。

4. 第四周：用一个真实版本验证

选择一个即将开始的版本，把需求工作量与可承诺容量进行对比。不要为了让版本通过而调整数据；如果容量不足，就让范围、时间、资源和质量取舍公开发生。版本结束后，复盘预测误差并更新模型。

对于使用 PingCode 等项目管理平台的团队，可以把人员、项目、任务、迭代和工时记录放在同一套管理链路中，再通过资源视图和报表进行滚动校准。平台选型的重点不是页面是否复杂，而是能否支持组织级资源透明、计划与实际对比、跨项目冲突识别以及历史数据沉淀。

十二、总结：真正成熟的人力资源计划，不是把时间排满

可用工时管理的核心，不是算出一个看起来精确的数字，而是让团队知道哪些时间已经被承诺、哪些时间必须保留、哪些技能真正稀缺，以及当容量不足时谁来做取舍。

我最看重的判断标准只有三个：第一，计划是否覆盖了真实发生的工作；第二，容量是否经过技能、角色和风险折算；第三，计划偏差是否能够回溯到具体原因。如果这三个问题都能回答，哪怕早期数据存在误差，资源计划也在变得可靠。

产品经理最危险的行为，是用理论工时承诺结果；最成熟的行为，是用可承诺工时管理不确定性。下一步可以从一个真实迭代开始：列出团队全部工作池，扣除已知不可用时间，识别共享资源冲突，设置风险缓冲，再用四个周期的实际数据修正模型。不要先追求完美系统，先建立一套能够被团队持续使用、持续复盘、持续改进的容量机制。