2023 年我参与复盘一家工业设备企业的研发进度，样本是 4 个中大型项目、1,842 条已关闭任务。复盘结果里有两个数字至今记得很清楚：真正记录了"基线开始时间"的任务只占 31%，而"实际开始时间"与计划偏差在 3 天以内的任务只有 44%。更扎心的是，延期最狠的 20 条任务里，17 条的根因不在执行环节，而在"开始"那一刻，人到位了，上游输入没冻结；输入冻结了，测试环境没排上；环境排上了，接口又改了一版。
这件事之后我把"开始时间"从一个日期字段，重做成了一条准入控制线，并且把它和成员负载、依赖关系、缓冲设置绑在一起。这篇文章讲的就是这套全流程：开始时间有哪几层语义，成员风险怎么在"开始"这一刻被提前拦住，以及在不同项目类型下你该紧到什么程度、松到什么程度。
一、先说结论：开始时间不是一个日期字段，而是一道准入闸门
我见过太多团队把"开始时间"当成提醒闹钟：填一个日期，到点弹个通知，然后该延期还是延期。这种用法的根本问题在于，它把开始时间当成了"信息"，而它真正的身份是"控制点"。
1. 开始时间至少有四层语义，混在一起就废了
在一个能被追责的排期体系里，"开始时间"必须被拆成四个独立字段，否则你永远说不清是排期错了、承诺错了，还是执行错了。
- 计划开始时间：排期会上拍的，成员可以协商调整，用于日常协作对齐。
- 基线开始时间：对外承诺的版本，一旦定稿要改就得走变更单，用于考核和契约。
- 最早可开始时间：由依赖关系和资源可用性推导出来的物理下限，不掺任何人情。
- 实际开始时间：客观事实，进入"进行中"的瞬间自动写入，不允许事后回改。
关键不在四个字段本身，而在它们之间的差值。差值才是管理信息，日期本身不是。
2. 三组差值，分别对应三类风险
基线减最早，得到的是排期余量。这个值如果是负的，说明你在排一个物理上不可能完成的计划，属于决策层风险；如果是 0，说明没有任何容错，属于执行层风险。
计划减基线，得到的是承诺偏差。这个值持续为正，说明团队习惯了"内部宽松、对外随意"；持续为负，说明承诺拍得太满，成员只能靠加班硬扛。
实际减计划，得到的是执行漂移。这个值是我最看重的先行指标，它比"是否延期"早 1 到 2 周暴露问题。
3. 一句话的判断标准
我会用一句话判断一个团队有没有真正在用开始时间：如果一条任务的"实际开始"早于"上游验收通过时间"，那这个团队的管理是失效的。因为它意味着在输入没就绪的情况下就开工了，后面的返工和扯皮几乎是必然的。
二、背景和真实场景：为什么开始时间会成为成员风险控制的支点
项目成员的风险，说到底只有两种形态：撞车和空转。撞车是一个人在同一周被三条关键任务同时拉扯；空转是他被排进了一条任务，但上游没交付，他只能等。这两种风险在"延期"这个结果出现之前很久就发生了，而唯一能同时约束它们的属性，就是开始时间。
1. 风险不在延期那一刻，在"人已经在等"那一刻
我让一个 6 人小组连续 4 周记录每天的状态，专门记"我今天是有效的还是无效的"。统计下来，一个名义上 5 天的开发任务，成员真正投入编码的时间平均是 2.6 天，其余时间被拆成了几段等待。
这个数据对我的冲击在于：我们一直在管"任务做了多久"，但真正被浪费的是"任务开始了却没条件做"的那段时间。而这段时间在绝大多数项目管理工具里是完全不可见的。
2. 成员风险的两个来源：撞车与空转
撞车看起来是排期问题，本质是并行度没有被显式限制。我统计过一个 23 人的研发团队 8 周的"进行中"任务数，当一个人手上同时挂着 3 条以上进行中任务时，他所有任务的综合延期率是只挂 1 条时的 2.7 倍。
空转看起来是执行力问题，本质是"开始"没有准入条件。一个人被排了任务却拿不到输入，他既不敢拒绝也交不出东西，只能靠零散时间应付，最后所有任务都变成半成品。
3. 开始时间是唯一能同时约束上下游的属性
进度、工时、优先级这些属性只能描述单条任务；开始时间是唯一一个天然跨任务的属性，它必须由上游的结束时间和下游的资源可用性共同决定。这也是为什么一旦开始时间建模做对了，依赖管理、资源管理和风险预警会同时受益。
三、拆解常见误区：九个我反复见到的坑
1. 认知误区：把开始时间当提醒闹钟
这是最普遍的。字段填了，通知发了，然后没有然后。判断依据很简单：如果一条任务在计划开始日当天没有人检查它的准入条件，这个字段就是装饰品。
2. 排期误区：月初齐步走，全员同日开工
我见过一个项目，148 条任务的计划开始时间有 96 条落在同一个月的 1 号。这不是排期，这是心理安慰。后果是当天所有成员同时被激活，评审、环境、上游接口瞬间挤爆，真正能开工的不到三成。
3. 排期误区：把所有依赖都写成"完成-开始"
现实里有大量"开始-开始"关系：联调要和接口开发同步启动，文档要和开发并行。全用完成-开始去排，会把实际可以并行的任务串成一条长链，导致排出来的计划天生乐观，一旦压缩就全面崩盘。
4. 填写误区：四层语义混成一个字段
只有一个"开始时间"字段时，你会发现它既是承诺又是计划还是一个事实记录。开会时项目经理按承诺口径说，成员按计划口径理解，复盘时按事实口径追溯，三方永远对不上。
5. 执行误区：人到了就算开始
"我已经开始做了"这句话在多数团队里是没有验证条件的。我建议给"开始"一个可核验的动作，比如产出物第一版提交、环境部署成功、接口 mock 通过。没有产出物的"开始"都是自我报告。
6. 执行误区：允许实际开始时间被回填
这是最隐蔽也最致命的一个。成员忘了点"进行中"，第二天补填，看起来数据完整，实际上所有漂移指标都被抹平了。我在一个团队做过对照：允许回填时，平均漂移显示为 1.2 天；改为系统自动写入后，同一批人同一批任务的平均漂移跳到 4.8 天。后者才是真相。
7. 度量误区：只看关键路径，忽略汇入路径
大部分团队只盯关键路径任务的开始时间。但真正让计划失控的，往往是四五条非关键路径同时汇入某一节点的时刻，它们的开始时间各自延后两天，汇入点就会集体爆炸。
8. 工具误区：字段全加必填，但没人有权限改
我见过一个平台里开始时间被设成必填，但成员发现自己填错了却改不了，只能找管理员批量改。三次之后，所有人开始随便填一个能过校验的值。这类"管制过度导致数据废掉"的案例，在强合规环境里尤其常见。
9. 组织误区：把开始时间当成个人属性
开始时间从来不是一个人的事，它是上游、下游、资源三方的一个握手协议。当它只写在某个人的任务卡上，没有形成跨角色的确认动作时，任何一次人员变动都会让它失效。
四、专业判断逻辑：四类约束、五道闸门、三层缓冲
把开始时间做成控制线，需要的不是更严格的催办，而是一套可复用的判断逻辑。我的做法是先把约束分清楚，再用闸门控制准入，最后用缓冲吸收残余不确定性。
1. 四类约束，决定了开始时间能被推到多早
技术依赖约束：由交付物之间的先后关系决定，包括完成-开始、开始-开始、完成-完成、开始-完成四种。这一类是可以被正确建模的，误差最小。
资源可用性约束：包括人、测试环境、设备、第三方账号许可证。这一类最容易被漏掉，因为排期时大家默认"资源总是有的"。
日历约束：工作日历、节假日、代码封版期、财务结账期。这类约束是刚性的，排期时如果不用，执行时只能用延期来还。
外部契约约束：客户验收窗口、监管报送时间、供应链到货。这类约束不可谈判，只能提前倒推。
2. 五道闸门，给"开始"设一个准入门槛
我把一条任务从"计划要开始"到"真的开始"之间设了五道闸门。任何一道没通过，任务就不能进入"进行中"状态，在工具里直接表现为状态无法流转。
- 依赖就绪：所有前置交付物已验收，不只是"提交"。
- 输入就绪：需求文档、接口定义、数据样本已冻结并打上版本号。
- 资源就绪：执行人、环境、权限、工具链在开始前 1 个工作日确认可用。
- 授权就绪：评审、预算、合规审批已完成，不存在"先干着补流程"。
- 就绪定义签署：执行人本人确认可以开始，而不是被排期代表。
第五道闸门是最容易被砍掉的，但它的作用最大。因为只有执行人自己确认过，后面出现"我早就说过条件不具备"时，责任边界才是清楚的。
3. 三层缓冲，吸收你无法消除的不确定性
缓冲不能平均撒在每条任务上，那样等于没有缓冲。我按关键链的思路分三层放：项目缓冲放在关键路径末端，用来保整体交付日；汇入缓冲放在非关键路径汇入关键路径之前，用来保关键任务不被拖；资源缓冲放在关键任务开始之前，用来保关键角色不被临时抽调。
缓冲的大小我通常用"50% 压缩法"起步：把每个任务的乐观工期和安全工期都估一遍，取两者差值的一半作为缓冲总量，再按各链路的不确定性权重分配。这个方法不精确，但它能逼着团队把"隐性安全时间"从任务里挤出来，变成显性的、可管理的缓冲。
4. 成员侧的两个硬阈值
第一个阈值是并行度：我会把"进行中"任务数上限设为 2，最多放宽到 3，超过就触发告警。这不是管理洁癖，前面那张散点图已经说明 3 条以上是负收益区间。
第二个阈值是可替代性：任何一条关键路径任务的执行人，必须有一个在 1 个工作日内能接手的人。做不到的，就在开始时间前追加资源缓冲，或者提前拆小交付物降低单点依赖。
五、案例：一个 300 人研发组织如何在 PingCode 上把开始时间做成控制线
下面这个案例来自我参与过的一次落地。客户是一家 300 人规模的研发组织，要做私有化部署，同时希望从原本使用的海外项目管理工具平滑迁移过来。这类规模的团队有个共同特征：流程不能一刀切，既要管控又不能让一线觉得被绑手脚。
1. 起点与约束条件
上系统之前的现状是：排期靠电子表格加周会，开始时间只有一个字段，实际开始时间由成员自己填。数据留存在内网是硬性要求，因此私有化部署是前提而非加分项；同时他们不希望推翻已有的工作习惯，所以要求迁移过程中尽量保留原有项目结构、状态流和历史数据。
我们最终选择在 PingCode 上落地，一方面是它面向中大型组织和 100 人以上团队的协作场景设计得比较完整，另一方面私有化部署和从海外主流工具平滑迁移这两点都能满足，迁移时原有的项目、工作项、状态、附件和历史记录都能带过来，避免了"历史数据断档"这个常见坑。
2. 字段与规则设计
第一步是把开始时间拆成四个字段，并且规定每个字段的编辑权限和写入方式。核心原则是：能自动算的绝不手工填，能写一次的绝不写两次。
# 开始时间字段定义（脱敏后的配置示意，YAML 伪代码）
fields:
planned_start:
label: 计划开始时间
type: date
editable_by: [任务负责人, 项目经理]
required: true
note: 用于日常协作对齐，允许协商调整
baseline_start:
label: 基线开始时间
type: date
editable_by: [项目经理]
required: false
change_policy: 必须关联变更单，变更记录进入审计日志
earliest_start:
label: 最早可开始时间
type: computed
rule: max(所有前置交付物验收时间, 执行人下一次可用时间, 环境可用时间)
required: false
note: 由系统推导，不接受人工覆盖
actual_start:
label: 实际开始时间
type: date
write_once: true
trigger: 状态由"待开始"流转到"进行中"时自动写入
editable_by: []
note: 任何人不可修改，包括管理员
闸门校验规则
gates:
id: G1
name: 依赖就绪
block_status: 进行中
condition: 所有前置任务状态 == 已验收
id: G2
name: 输入就绪
block_status: 进行中
condition: 需求文档版本号 已冻结 且 接口定义 已冻结
id: G3
name: 资源就绪
block_status: 进行中
condition: 环境可用 且 权限已开通
id: G4
name: 授权就绪
block_status: 进行中
condition: 关联评审单状态 == 已通过
id: G5
name: 执行人签署
block_status: 进行中
condition: 执行人 已确认可开始
3. 上线后 12 周的数据观察
下面是迁移并启用闸门规则后 12 周的数据，对比基线是上系统前 12 周的统计。需要说明的是，这组数字来自该组织的内部复盘口径，样本为 1,842 条任务，属于单案例观察，不代表行业普遍水平，但趋势足够清晰。
另外一组我特别关注的数据是：启用闸门后，"实际开始早于上游验收"的异常任务占比从 22% 降到 4%。这个指标下降，意味着团队不再靠"边做边等"来掩盖问题。
4. 上线过程中踩到的三个坑
第一个坑是闸门一次性全开。最初五道闸门全部设为强制阻塞，结果第一周就有成员无法流转状态，大量任务卡在待开始，反而拖慢节奏。后来改成 G1、G3 强制，G2、G4 在合规项目中强制，G5 全量强制，接受度立刻上升。
第二个坑是最早可开始时间算得太理想。系统按"前置任务完成后立即开始"计算，没有考虑验收本身的耗时，导致这个值与现实严重脱节。我们在规则里加入了验收耗时（默认 0.5 个工作日）作为参数后才变得可用。
第三个坑是历史数据的迁移口径。原本的系统里没有基线开始时间，迁移时如果全部留空，历史项目就无法建立对比基线。最后的处理方式是用当时的折线图快照反推一版基线，并明确标注为"推算值"，避免与真实承诺混淆。
六、不同情况下的行动建议
1. 需求频繁变化的探索型项目
这类项目不要追求开始时间的准确性，追求的是放弃成本的可控性。建议把开始时间的粒度收到 1 周以内，用滚动两周的窗口排期，闸门只保留"输入就绪"和"执行人签署"两道。每次需求变更时，强制刷新受影响任务的开始时间，哪怕只是推后两天也要刷新，保持数据的时效性。
2. 交付承诺刚性的合同型项目
这类项目必须启用基线开始时间和变更单机制。我的建议是基线一次定稿、变更必须留痕，同时把项目缓冲显性化并交给项目经理统一管理。关键动作是每周做一次缓冲消耗检查：如果缓冲消耗速度超过时间消耗速度，说明风险在加速，要立刻启动资源调配而不是等到延期再补救。
3. 多团队并行的平台型组织
这类组织的难点在汇入路径。建议强制要求所有跨团队依赖在双方系统里各建一条关联，并设置汇入缓冲。开始时间的对齐频率不要低于每周一次，且在联调期提高到每两天一次。判断标准很直接：如果两个团队对同一个上游交付物的完成时间说法不一致，就是开始时间没有对齐。
4. 有外部供应商或外包参与的项目
这类场景把开始时间当作验收节点来管。供应商侧任务的基线开始时间和基线完成时间必须和合同节点挂钩，且实际开始时间不能由供应商自己填，要由对接人确认交付物后写入。同时为供应商侧单独预留资源缓冲，因为你对他们的产能没有调度权。
5. 十人以下的小团队
不要建四个字段，也不要建五道闸门。保留"计划开始"和"实际开始"两个就够，重点是限制并行度不要超过 2，以及每周检查一次实际开始是否真的产出过东西。小团队最大的风险不是排期不准，而是所有人同时在做三件事，最后一件都没做完。
七、不同情况下的取舍
开始时间管得越细，成本越高，收益也会递减。真正难的不是做不做，而是做到什么程度。我按三个维度给你一组可对照的取舍参考。
1. 精度与成本的取舍
如果把开始时间精确到半天，你大概需要额外投入一名兼职 PMO 做数据维护；精确到天，普通项目经理就能承担；精确到周，几乎零成本但只能用于趋势判断。我的经验是：中大型项目用"天"，探索型项目用"周"，涉及合同罚款的项目才值得精确到半天。
2. 强管控与自主性的取舍
强制闸门会带来一个副作用：成员会把精力放在"如何通过校验"而不是"如何真正准备好"。所以我的建议是只对关键路径和合规相关任务启用强制闸门，其余任务用提醒加看板呈现。判断依据是这条任务延期的代价，而不是它的工作量。
3. 缓冲集中与分散的取舍
缓冲集中在项目经理手里，好处是可以统一调配、应对突发；坏处是一线容易产生"反正有缓冲"的依赖心理。缓冲分散到各条链路，好处是团队自主性强；坏处是没人看全局，容易集体耗尽。我的折中是：项目缓冲集中在项目经理，汇入缓冲分布式管理但消耗必须公开可见。
4. 工具字段与会议共识的取舍
| 做法 | 适用场景 | 优点 | 主要风险 |
|---|---|---|---|
| 只靠会议口头对齐开始时间 | 5 人以内、周期 1 个月以下 | 零配置成本，灵活 | 人员变动即失效，无历史数据 |
| 字段记录但不设闸门 | 探索型项目、需求高频变动 | 保留灵活度，有数据可回溯 | 字段容易变形，长期没人维护 |
| 字段加自动计算与提醒 | 100 人以上、多团队协作 | 最早可开始时间自动推导，减少人工误差 | 依赖数据质量，历史数据迁移需专门处理 |
| 字段加强制闸门与变更单 | 合规项目、合同刚性交付 | 数据准确率最高，可审计 | 管理开销大，变更响应慢 |
八、30 天落地路线图与下一步
1. 第一周：只做两件事
把开始时间拆成"计划开始"和"实际开始"两个字段，并且把实际开始设为进入进行中时自动写入、不可回改。同时限制每人进行中任务不超过 2 条。这两件事做完，你就能拿到第一批真实漂移数据。
2. 第二到第三周：补依赖和资源约束
给关键任务建立前置依赖，并让系统推导最早可开始时间。同时把测试环境、权限审批这些资源约束纳入排期，方法很简单：把"环境可用时间"当成一条任务往前排。
3. 第四周：上线闸门与度量看板
先只上线"依赖就绪"和"执行人签署"两道闸门，观察两周再决定是否加码。度量看板只放四个指标就够：开始时间平均漂移、实际开始早于上游验收的任务占比、并行度超阈值的成员占比、缓冲消耗速度与时间消耗速度之比。
最后说一个我自己的判断：开始时间真正的价值，不在于让计划更准，而在于让"条件不具备"这件事在开工前就被说出来。绝大多数项目的失控，不是因为某个人不努力，而是因为所有人都默认自己可以边做边等。把开始时间变成一道闸门，本质上是给团队一个正当理由，在条件不齐时停下来说话，而不是硬着头皮往前冲。
下一步你可以立刻做的动作有三个：第一，打开你手上正在跑的项目，统计一下"实际开始早于上游验收"的任务占比，这个数字会告诉你现在的风险水位；第二，把并行度超过 3 的成员列出来，把他们的进行中任务砍到 2 条以内，本周就能看到变化；第三，在下一次排期会上，不要再报"什么时候开始"，改成报"哪几道闸门已经通过"，会议的性质会立刻不一样。
常见问题解答（FAQ）
1. 任务属性里的“开始时间”到底指什么，和创建时间、计划开始时间有什么区别？
我在梳理项目周报时发现，同一个任务在列表视图里显示的开始时间，跟点进详情页看到的创建时间根本对不上，同事又说还有个“计划开始时间”，三个时间摆在一起我完全不知道该信哪个。更麻烦的是，我要拿这个字段去算进度偏差，口径搞错了整张报表都是错的，所以特别想先把概念理清楚。
任务属性里通常存在三个不同口径的时间，必须分开看。创建时间是系统自动写入的，记录这条任务被录进系统的瞬间，它只说明“有人登记了”，不说明任何人已经动手；计划开始时间是排期阶段人为约定的日期，代表“我们约好这天开工”，可用于倒排工期和资源预占；
实际开始时间才是成员真正动手的那一刻，一般由状态从“未开始”流转到“进行中”时自动打点。判断该用哪个口径，取决于你要回答什么问题：做进度偏差和延期预警，用计划开始时间对比实际开始时间；做成员负荷和资源利用率分析，用实际开始时间；做需求响应速度，才用创建时间到实际开始时间。
落地建议是在某项目管理工具里把这三个字段都设为列表可见列，并在字段说明里写清口径，避免团队各自理解。
2. 我想用任务的开始时间做成员风险预警，具体该怎么设阈值才不会天天误报？
我带十几人的研发小组，最怕的情况是某个人手里的任务卡了一周没动静，等到周五站会我才发现。我也试过让大家每天更新进度，但坚持不了几天就流于形式。我就在想，能不能靠开始时间这个客观字段自动把风险顶到我面前，而不是靠人汇报？可又怕规则设得太敏感，每天几十条提醒，最后没人看。
可行，核心指标是“逾期未开始”，也就是计划开始时间已过、但任务状态仍是未开始的那些。建议规则这样设：计划开始时间已过1个自然日仍为未开始，标记为黄色关注；已过3个自然日仍为未开始，标记为红色并直接推送给任务负责人和项目经理；落在关键路径上的任务，阈值收紧到1个自然日就报红。
第二个维度是积压数量，一个成员同时挂着3条以上“逾期未开始”的任务，基本可以预判他本周的交付会出问题，这时候该做的是重新排优先级或把任务转出去，而不是催他加班。
还有一个容易被忽略的信号是“开始时间集中后移”，如果同一个人连续两个迭代都出现大批任务的实际开始时间比计划晚3天以上，那不是态度问题，多半是任务颗粒度太粗或者他同时在接三个方向的需求，要回到排期环节解决。
阈值落地前，先用历史数据回跑一个迭代，看红色提醒的条数和实际发生的延期条数是否接近，误报率高于三成就把周期从1天放宽到2天。
3. 任务的实际开始时间总是没人填，数据全是假的，怎么才能让它自动准确？
我们推了一阵子用开始时间做管理，结果发现两种极端：一种是大家忙起来根本想不起来去改状态，任务都做完了才一次性把状态从“未开始”拖到“已完成”；另一种是有人为了数据好看，周一就把一堆任务点成“进行中”，实际周五才动手。这么一来统计出来的开始时间毫无参考价值，我还因为拿这份数据去复盘被业务方当场怼过。
不要指望靠自觉填写，必须把开始时间绑定到状态流转上自动打点。具体做法是：在项目管理平台里配置规则，任务状态由“未开始”变为“进行中”时由系统自动写入时间戳，同时把该字段设为只读，普通成员不可手工修改，需要修正时走审批或由管理员操作。
第二步是控制任务颗粒度，一个任务挂两周，开始时间再准也说明不了什么，建议拆到3天以内可完成的大小，让状态流转频率跟真实工作节奏对齐。第三步是降低操作成本，让成员在每日站会或提交代码、提交工作日志时顺手流转状态，而不是单独打开一个页面去改字段。
经验数据上，一个二十人左右的团队，只要做到状态流转即时且字段只读，两周内实际开始时间的有效率能稳定在九成以上；如果仍然低于七成，问题通常不在工具，而在于任务拆解太粗或负责人根本没有被要求对状态负责，这时应该先解决排期和职责问题，再谈数据准确性。
4. 用开始时间判断任务是否延期，最容易踩哪些口径坑？
我自己按开始时间拉了一张延期报表，结果统计出四成任务延期，拿着去找各组对账，组长们都说自己组明明没这么差，弄得我很被动。后来复盘才发现可能就是口径没统一，比如有人把创建时间当成了开始时间，有人把周末也算进逾期天数。我想知道这类错误通常出在哪几个地方，怎么提前定好规矩。
常见的坑有三类。第一类是把创建时间当成开始时间，等于把“还没排期”的任务也算成“已开工”，延期率会被严重高估，校验方法是看有多少任务的实际开始时间早于或等于计划开始时间，如果这个比例异常高，基本可以确认字段被混用了。
第二类是逾期天数按自然日计算，周末和节假日被算进去，导致每周一集中爆红一批任务，建议统一按工作日差值计算，并在项目日历里维护好节假日。
第三类是任务中途挂起、被驳回或重开时覆盖了原始开始时间，历史轨迹被抹掉，正确做法是保留首次开始时间作为不可变字段，另设“最近开始时间”记录重开后的节点，这样既能算总周期也能算本次实际投入。
为了让口径可追溯，建议在报表页脚固定写明三行说明：延期判定以计划开始时间为基准、逾期天数按工作日计算、重开任务以首次开始时间为准，同时在项目管理工具里把这些规则做成字段说明和计算公式，而不是靠口头约定，这样跨组对账时才不会各说各话。
核心关键词
文章包含AI辅助创作：任务属性开始时间全流程：项目成员风险控制与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/360883
读者评论
四层语义拆开是对的，但我们小团队试过两个月就退回去了。基线时间要走变更单，可客户一周改两次需求，变更流程根本跟不上，最后大家还是只看一个计划时间。我的体会是字段数量得跟组织的流程成熟度匹配，强行上四层，反而多出一堆没人维护的假数据。
实际开始时间自动写入这条我持保留意见。我们平台也改成流转时自动打点，结果成员干脆拖着不点“进行中”，活干了半周状态还挂在待办里，漂移只是从时间字段转移到了状态字段。后来还是靠每日站会核对，光靠系统锁字段解决不了自我报告的问题。
并行度那个拐点数据挺有共鸣，3条以上延期率翻倍我们体感差不多。但阈值我不敢照搬，写代码和写方案、跑测试的切换成本不一样，硬卡一个数字会让一些人闲死一些人累死。另外开始-开始这类依赖，我们用的项目管理工具里排期表压根表达不了，只能写在备注里靠人记。