任务属性开始时间全流程：项目负责人数据分析与一文讲清

我做项目负责人复盘时，最常被问到的一个问题是：为什么周报上写着"本周已启动"，到了月底一算，项目还是延期了十天？把任务列表拉出来一看，问题往往不在执行，而在"开始时间"这个属性本身，有人填的是计划开始，有人填的是实际开始，有人压根没填，有人把任务创建时间当成了开始时间。三种语义混在一列里，任何数据分析都是自欺欺人。这篇文章我把任务属性"开始时间"从定义、录入、计算、分析到治理的完整链路讲清楚，并给出项目负责人可以直接照抄的指标口径和落地配置。

一、先给结论：开始时间是三类时间的契约，不是三个字段

很多团队对"开始时间"的理解停留在"任务详情页里有一个日期选择器"。这是最省事的理解，也是最容易出事的地方。我在三个不同规模的组织里做过同一件事：把任务表里所有含"start"的字段导出来，让人工标注每一个值的真实语义，结果标注一致性只有六成左右。也就是说，同样一列"开始时间"，有四成的数据其实在表达不同意思。

1. 三类开始时间的语义必须分开

从计划管理角度，一个任务至少要区分三类开始时间。它们不是三个可以随便互换的字段，而是三份性质不同的契约。

计划开始时间（Planned Start）是排期计算的结果，来自依赖关系、资源可用性和工期估算，它回答的是"按当前方案，这个任务最早应该在什么时候动手"。

承诺开始时间（Committed Start）是负责人或团队对外给出的时间，它回答的是"我向你保证什么时候开始"。承诺时间和计划时间经常不一致，差异本身就是一条重要的管理信号：为什么他不肯承诺计划时间？是资源不够，还是依赖不确定？

实际开始时间（Actual Start）是事实数据，回答的是"真正动手的那一刻是什么时候"。它只能被记录，不能被计划。

把这三类混为一谈，会导致一个典型后果：排期表看起来是计划，实际是承诺，考核时又当成事实来用。一个字段承担三种职能，最后谁都信不过它。

2. 项目负责人真正要算的口径只有三个

不需要把问题想得太复杂。落到日常分析，项目负责人真正要算的就是三个数：启动偏差（实际开始减计划开始）、按期启动率（偏差在容忍阈值内的任务占比）、启动变更次数（一条任务的计划开始时间被改过几次）。

这三个口径对数据质量的要求是完全不同的。启动偏差要求计划时间和实际时间都有值；按期启动率还额外要求有一个明确的容忍阈值，比如两天内算按期；启动变更次数则要求系统保留变更历史，而不是只存最后一次值。

很多团队只做到了第一层，然后用"偏差平均值"去汇报，结果被少数极端值带偏。我在一个交付型团队的样本里看到，启动偏差的算术平均是 4.7 天，但中位数只有 1 天，平均值是被少数延期四十天以上的任务拉起来的。只看平均值，会得出完全错误的资源结论。

3. 我的核心结论

开始时间的全流程，可以概括成一句话：用计划开始时间做推演，用承诺开始时间做对齐，用实际开始时间做归因，三者之间的差值才是管理信息。

如果只记录一个时间，那这个时间既不能用于排期，也不能用于复盘，只能用于"填表交差"。这也是为什么很多组织的项目管理工具里数据看起来很全，但一到分析就没人用。

二、为什么开始时间总在项目里出事：三个真实场景

讲完定义再看现场。下面三个场景来自我参与过的实际复盘，细节做了脱敏，但问题结构是原样的。

1. 场景一：任务清单很漂亮，排期是假的

某产品研发团队，两百人左右，任务拆解做得很细，一个迭代能拆出六百多条子任务，每条都有负责人、工时估算和截止时间。但有一个细节：所有任务的计划开始时间都是迭代第一天。

我随机抽了三十条任务做访谈，问负责人"你打算哪天开始这个任务"，得到的答案分布在迭代的前两周，没有一条是第一天。这说明排期表里的开始时间是假的，是从模板批量带出来的默认值。

后果是什么？依赖链完全失效。排期引擎以为所有任务同时启动，于是把工期估算直接叠加成迭代长度，得出一个看起来很漂亮的甘特图。实际上真正的前置任务第二周才动手，后面的串行任务全部被压到迭代末尾，最后一周出现了典型的资源挤兑。

开始时间批量默认值，是排期数据里最常见的一种污染。它让排期看起来完整，但让所有基于依赖的计算全部失真。

2. 场景二：周报说"已启动"，数据里查不到开始时间

另一个团队的问题更隐蔽。他们的任务状态有"待处理、进行中、已完成"，周报里的"本周启动任务数"来自状态变更记录。但当我试图把状态变更时间和实际开始时间做对账时，发现系统里根本没有实际开始时间这个字段。

状态改成"进行中"确实有时间戳，但那个时间戳不一定等于开始工作的时间。有的负责人习惯提前一天把状态点开，有的攒到周末一次性批量更新，有的任务实际上已经做了两天才想起来改状态。在一个两百条任务的样本里，状态变更时间和负责人回忆的真实开始时间，中位差异是 1.5 天，最长的是 9 天。

这就带来一个尴尬：你可以统计状态变更的准时率，但没法统计真实启动的准时率。两者在管理层眼里看起来是一回事，实际上差了一两天，足以影响一个短迭代的节奏判断。

3. 场景三：依赖链断裂，所有人都以为别人先做

第三个场景涉及跨团队协作。一个需求拆成了三个团队的任务，A 团队产出设计稿，B 团队做前端，C 团队做后端联调。三条任务都有计划开始时间，也都有依赖关系标记，但依赖是"软依赖"，只是写在了描述里，没有配置成系统约束。

结果 A 团队因为另一个项目插单，设计稿晚了四天。B 和 C 的计划开始时间没有任何变化，因为没人手动去改。两边到了计划开始时间，发现前置交付物还没有，于是各自去找别的事情做，等设计稿到齐时，两个团队的注意力已经切走了，重新拉回来又花了两天。

依赖关系如果不参与开始时间的自动重算，开始时间就只是一个人工承诺，不是一条计划。这类问题的代价很难在单条任务上看出来，但会在项目层面表现为反复的"等待-切换-重新进入"损耗。

三、拆解六个常见误区

下面这些误区，我在不同组织里反复见到。它们大多不是态度问题，而是配置和口径没设计好。

1. 误区一：只记录实际开始时间，不保留计划开始时间

有些团队觉得"计划反正会变，记了也没用"，于是只让负责人填一条实际开始时间。这个逻辑听起来务实，实际是把分析能力提前砍掉了。没有计划值，偏差就无从计算，你只能知道每个人什么时候开始的，无法知道该不该在那个时间开始。

我在一个项目里试过补一条对照：让负责人回忆任务原本打算哪天开始。三十条样本里，有十一条的回忆时间和他们当时记录的承诺时间对不上，差异最大的是六天。记忆不是可靠的数据源。

2. 误区二：用创建时间代替开始时间

这是最隐蔽的一种。创建时间在系统里天然存在，不需要任何人录入，看起来是免费的。但它的语义是"这个任务被写进系统的时刻"，和"动手做"完全是两回事。

用创建时间做分析，会出现一个反直觉的结果：接近九成的任务"当天创建当天开始"。这个结论没有任何管理价值，因为需求池里的任务可能躺了三个月才被捡起来做。我在一个用创建时间做统计的团队里做过对比，换成真实开始时间后，平均启动间隔从 0.3 天变成了 11.6 天。

3. 误区三：粒度混用，有的填日期有的填到分钟

同一条分析链路里存在两种粒度，会导致时间差计算出现系统性偏差。日期粒度下，"同一天"的差值恒为 0，但如果任务实际是当天下午才开始，与计划中"当天上午"的差别就被抹掉了。

我的建议是按管理周期定粒度，而不是按喜好定。以周为管理节奏的项目，日期粒度足够；以天为节奏的迭代团队，建议在关键任务上使用带时间的时间戳；只有做流水线、运维值守这类场景，才需要精确到分钟。

4. 误区四：状态流转不写时间戳

如果实际开始时间靠人工填写，它的可靠性就完全取决于填写人的勤快程度。而现实是，忙的时候最先被牺牲的就是填时间。解决方向不是加强督促，而是把时间戳写进工作流：状态从"待处理"流转到"进行中"时，系统自动记录时间，并把它写入实际开始时间字段。

这里有一个细节值得注意：自动写入要区分"首次流转"和"后续回流"。任务从进行中退回待处理，再重新进入进行中，不应该覆盖第一次的实际开始时间，而应该记录为"重新开始时间"。这两条数据在复盘时的含义完全不同。

5. 误区五：基线不锁定，拿最新计划去复盘

项目做完复盘时，很多人直接拿系统里当前的计划开始时间和实际开始时间比，得出一个"偏差很小"的结论。这是典型的循环论证：计划已经被反复调整到接近实际了，当然偏差小。

正确做法是在阶段启动或变更审批通过时锁定一份基线，复盘时用基线版本的开始时间和实际时间对比，同时观察计划被改过几次、每次改动的理由。基线快照的数量和质量，直接决定复盘结论有没有价值。

6. 误区六：拿个人维度的启动偏差做考核

这是最容易引发数据造假的误区。一旦启动偏差和绩效挂钩，负责人最理性的选择就是拖延填写实际开始时间，或者提前把状态改成进行中。数据会变得很好看，管理会变得更差。

我的建议是把启动偏差定位为流程诊断指标，用于观察排期质量、依赖稳定性和资源冲突，而不是个人评价指标。要评价个人，看的应该是承诺兑现率，也就是承诺开始时间和实际开始时间的匹配度，这个指标的口径更清晰，也更依赖负责人的主动承诺。

四、专业判断逻辑：项目负责人该怎么设计开始时间数据链路

定义清楚、误区排掉之后，接下来是设计。我把开始时间的数据链路拆成五层，从下往上依次是定义层、录入层、计算层、分析层、治理层。任何一层缺失，上层的分析都不可靠。

1. 定义层：字段语义和约束

定义层要回答三个问题：字段叫什么、谁可以改、什么时候必填。我的建议是三条硬约束。

第一条，计划开始时间必须由排期动作产生，不允许手工直填。如果确实需要手工调整，必须走变更流程并留痕，而不是直接覆盖。

第二条，实际开始时间只允许由状态流转或工时填报触发，不开放手工编辑。这样能保证它是事实记录而不是主观陈述。

第三条，两类时间必须成对存在。一条任务如果有了实际开始时间却没有计划开始时间，应该被标记为数据异常，进入补数队列。

下面是一份可以直接参考的字段定义，我用 JSON 结构写出来，方便在配置任务类型时对齐口径。

{
"planned_start": {

"type": "datetime",

"required": true,

"editable_by": ["project_manager", "planner"],

"change_policy": "baseline_review",

"description": "由排期引擎计算，手工调整需审批"

},

"committed_start": {

"type": "date",

"required": false,

"editable_by": ["task_owner"],

"change_policy": "log_only",

"description": "负责人对外承诺的开始日期"

},

"actual_start": {

"type": "datetime",

"required": false,

"editable_by": [],

"write_trigger": ["status:todo->in_progress", "first_worklog"],

"immutable": true,

"description": "系统自动写入，不可人工修改"

},

"restart_at": {

"type": "datetime",

"required": false,

"editable_by": [],

"write_trigger": ["status:blocked->in_progress"],

"description": "阻塞恢复后重新开始的时刻，不覆盖首次actual_start"

}

}

2. 录入层：什么动作触发什么时间戳

录入层的设计原则是让人少做决定。每多一个需要人工判断的字段，数据质量就下降一层。理想状态下，负责人只需要做一件事：把任务推进到下一个状态。

具体映射关系建议这样设计：任务从待处理流入进行中，写首次实际开始时间；从阻塞或挂起回到进行中，写重新开始时间；从进行中直接完成，工作日志里补一条实际开始时间，取最早的一条。

跨团队任务要额外注意：如果一条任务由多人协作，实际开始时间应该取第一个人的动手时间，而不是负责人切换状态的时间。这两者在多团队协作里经常差好几天。

3. 计算层：依赖链与浮动时间

有了计划开始时间和实际开始时间，计算层要做的事是把它们放进依赖网络里去算。这里涉及四个量：最早开始时间、最晚开始时间、浮动时间、关键路径。

最早开始时间由前置任务的最早完成时间决定，最晚开始时间由后置任务的最晚完成时间倒推，两者之差就是浮动时间。浮动时间为零的任务构成关键路径，关键路径上的启动偏差几乎是致命的，非关键路径上的偏差只要不超过浮动时间，项目层面可以吸收。

这就是为什么我在做启动偏差分析时，一定要按关键路径和非关键路径分层看。把两者混在一起算平均偏差，得出的数字既不能反映风险，也不能指导行动。在一个我跟踪的项目里，关键路径任务的启动偏差中位数是 0.5 天，非关键路径是 3.2 天，如果只看整体平均，你会以为这个项目排期很松，实际上关键路径承受的压力远比平均值显示的要大。

4. 分析层：五个核心指标

分析层不需要发明太多指标，五个就够用，关键是口径要稳定。

• 按期启动率：实际开始时间与承诺开始时间的差值在容忍阈值内的任务数，除以承诺开始时间存在的任务总数。
• 启动偏差中位数与 90 分位：中位数反映常态，90 分位反映极端情况，两者一起看才不会被平均值误导。
• 计划开始时间变更次数：每条任务在基线之后被调整过几次，用于衡量排期稳定性。
• 浮动时间消耗率：实际启动延迟占该任务总浮动时间的比例，超过 100% 意味着已经冲击关键路径。
• 重新开始率：发生过阻塞并重新开始的任务占比，反映流程中断的频率。

这五个指标里，我最看重的是浮动时间消耗率。它把单个任务的时间偏差转换成了对项目整体风险的影响程度，比单纯的偏差天数更有解释力。一个延迟了五天但浮动时间有三十天的任务，和一个延迟了一天但浮动时间只有一天的任务，管理优先级是完全相反的。

5. 治理层：变更留痕与基线版本

治理层解决的是"怎么保证数据长期可用"。核心动作有两个：一是所有对计划开始时间的修改必须留痕，记录修改人、修改前后值和原因；二是在每个管理周期开始时锁定基线，复盘时同时对比基线和最新计划。

我见过做得很扎实的团队，他们在每个迭代开始和每次重大变更审批通过时都会生成一份基线快照，复盘报告里同时出现"按基线的偏差"和"按最新计划的偏差"两个数字。这两个数字的差，本身就是排期质量的量化体现。如果按最新计划的偏差远小于按基线的偏差，说明这个团队在过程中频繁调整计划来追赶现实，排期的前瞻性不足。

五、数据观察：我跟踪的三个组织，启动偏差长什么样

下面这组观察来自我在三个组织中做的过程数据跟踪，时间跨度大约各一个季度，样本量分别在四百到一千两百条任务之间。需要说明的是，这是过程观察数据，不是行业统计，用于说明问题的形态，不代表普遍水平。

1. 观察一：启动偏差不是正态分布，是长尾

三个组织的数据形态高度一致：绝大多数任务的启动偏差集中在负两天到正三天这个区间，然后拖出一条很长的尾巴，最远的到过四十天以上。

这意味着用平均值描述启动偏差是不合适的。第一个组织的平均值是 4.7 天，中位数是 1.0 天，90 分位是 12 天。平均值被尾部拉高了将近五倍。如果你拿平均值去申请缓冲时间，会给所有任务都加上冗余，反而拖慢整体节奏；如果你按中位数排期，又会在尾部任务上反复翻车。

我的做法是分两段看：中位数用来设定常态排期，90 分位用来识别需要重点盯防的任务类型。尾部那部分任务通常集中在两类：跨团队依赖任务和资源竞争激烈的任务。

2. 观察二：按期启动率和项目结果强相关，但不是因果

第二个组织的数据比较有意思。他们把项目按最终是否按期交付分成两组，按期交付组的按期启动率是 78%，延期交付组是 46%。差距很大。

但我不认为按期启动是延期的原因。更合理的解释是两者都是同一个上游因素的产物：排期质量和资源确定性。排期做得扎实的组织，启动时间估得准，交付也稳；排期拍脑袋的组织，启动时间随机，交付也随机。

所以我一直建议把按期启动率当作过程健康度的代理指标，而不是改进目标本身。直接去逼按期启动率，最常见的结果是数据变好、项目照旧延期。

3. 观察三：粒度越细不等于越准

第三个组织做过一次对照实验：一组任务用日期粒度填计划开始时间，另一组要求填到小时。一个月后对比，细粒度组的录入完整率从 94% 掉到 71%，而两组在最终交付准时率上没有显著差异。

原因不难理解。当录入成本超过收益时，人会选择应付，而不是更精确。细粒度要求带来的额外成本，没有转化成任何决策上的优势，因为他们的管理节奏本来就是以天为单位，小时级别的信息没人用。

我的结论是：粒度应该由决策粒度决定，而不是由技术能力决定。系统能存到秒不代表你该填到秒。

六、以 PingCode 为例：开始时间全流程怎么落地

讲完方法论，说落地。我近几年在中大型组织的项目管理系统选型和配置里，比较多的场景是围绕 PingCode 展开的，它主要服务中大型企业及 100 人以上组织，在任务属性、工作流自动化和基线管理这几个环节上，对开始时间这条链路支持得比较完整。下面按配置顺序说。

1. 字段与权限配置

第一步是把三类开始时间拆成独立字段，而不是复用同一个字段。计划开始时间和计划结束时间作为排期字段，权限收给项目负责人和计划角色；实际开始时间作为只读系统字段，不开放手工编辑；承诺开始时间作为一个轻量的日期字段，由任务负责人自己填。

PingCode 的工作项类型支持按任务类型分别配置字段和必填规则，这一点对中大型组织很重要。不同类型的任务对开始时间的要求本来就不同，需求类任务可能只需要计划开始时间，而交付类任务必须同时有计划和实际两条。一刀切的必填规则会让非关键任务变成填表负担。

2. 状态流转自动写时间戳

第二步是把实际开始时间和状态流转绑定。配置方式是在工作流里为"待处理→进行中"这个流转挂上自动化规则，触发时把当前时间写入实际开始时间字段。

前面提到的重新开始场景也要处理：为"阻塞→进行中"单独配置一条规则，写入重新开始时间，不覆盖首次实际开始时间。这个细节如果不处理，做过阻塞恢复的任务在复盘时会被误判为"一次启动、一次完成"，掩盖中间的中断成本。

还有一个容易漏的点：如果团队用代码提交来驱动状态，需要确认提交动作在时间上是否可靠。有的团队习惯周五批量提交，这时候时间戳反映的是提交行为，不是开发行为。我一般的建议是，对于以代码提交为触发源的任务，实际开始时间取提交记录和状态流转中较早的那个。

3. 基线与依赖

第三步是基线和依赖的配合。基线要在迭代启动或变更审批通过时锁定，锁定后计划开始时间的任何修改都要走变更并留痕。依赖关系要从文字描述升级为系统约束，配置成前置任务的完成会触发后置任务计划时间的重算。

这一步是整个链路里最能体现价值的。依赖变成硬约束之后，前置任务一旦延迟，下游任务的计划开始时间会自动后移，浮动时间也会实时更新。项目负责人不需要每周手工核对甘特图，只需要看浮动时间消耗率超过阈值的那几条任务，管理精力能省下大半。

4. 私有化部署与迁移场景

对于 100 人以上、有数据合规要求的组织，PingCode 支持私有化部署，这一点在做国产替代时会成为关键决策因素。我在几个替换原有海外项目管理平台的场景里参与过迁移，开始时间相关的字段是最容易在迁移中出问题的部分，原因是原平台的字段语义往往没有文档化。

PingCode 支持 Jira 平滑迁移，我的操作建议是迁移时不要直接映射字段名，而是先做一轮语义映射表：把原平台的每一个时间字段标注成计划、承诺、实际或其他四类，再决定映射到哪个目标字段。历史数据里如果只有一列含义模糊的开始时间，建议统一迁移到"计划开始时间"，并在复盘时标注为"迁移数据，语义待确认"，避免和迁移后的新数据混在一起做分析。

5. 报表与看板

最后一步是把前面五个指标做成常驻看板。我的建议是三层：任务层看单条任务的启动偏差和浮动时间消耗，迭代层看按期启动率和启动偏差分布，项目层看基线偏差趋势和重新开始率。

三层看板的刷新频率不一样。任务层实时，迭代层按周，项目层按里程碑。全部都实时刷新只会制造噪音，让人对数字麻木。

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

方法论不是所有组织都该照搬。下面按规模和阶段给出四组建议，你可以直接对号入座。

1. 十人以下小团队

不要上复杂配置。最小可用方案是：只保留计划开始时间和实际开始时间两个字段，实际开始时间由状态流转自动写。每周花十分钟，把上周所有实际开始时间晚于计划开始时间超过三天的任务挑出来，问一句为什么。

这个阶段的目标不是建立分析体系，而是让团队形成"开始时间是有意义的"这个共识。多数小团队的问题不是缺分析，而是缺对时间的共同语言。

2. 五十到一百人团队

这个规模开始出现跨团队依赖，需要在两个地方加码。一是依赖关系要配置成系统约束，触发计划时间重算；二是开始建立基线和变更留痕，哪怕是按月锁定一次也比不锁强。

指标上建议先跑按期启动率和启动偏差分布两张图，跑满两个月再考虑加浮动时间消耗率。指标加得太快，团队还没建立解读能力，容易把它当成考核工具。

3. 一百人以上、多项目并行组织

这个规模必须做统一口径。核心动作有三个：统一字段定义，写进任务类型配置文档；统一指标计算逻辑，避免各部门各算一套；建立基线机制和变更审批流程，把计划开始时间的修改纳入管理动作。

PingCode 这类支持多项目、多工作项类型和细粒度权限的平台在这个阶段比较合适，因为它能把字段定义和权限收敛到平台层，避免每个项目组各配一套。私有化部署能力对有数据合规要求的中大型组织也是刚需。

4. 正在做平台迁移或国产替代的团队

迁移是重建数据口径的最佳时机，也是最容易浪费的时机。我的建议是先做语义映射，再迁数据，最后配规则。顺序反了的话，你会把原来的混乱原样搬到新平台上，白折腾一次。

迁移过程中优先保证两类数据的质量：实际开始时间和基线快照。这两类数据无法通过事后补录恢复，其他字段都可以慢慢补。

八、不同情况下的取舍

任何配置都是取舍。下面四组取舍，我给出自己的倾向和理由。

1. 精度与录入成本

倾向是精度服从决策粒度。如果你的管理节奏是天，就填到天；如果是小时级别的排班或值守，就填到小时。多出来的精度不会自动转化为决策能力，只会转化为录入负担和随之而来的应付行为。

唯一值得为精度付代价的场景是关键路径任务。这类任务的偏差会直接传导到交付时间，值得用更细的粒度去管。所以我的做法是关键路径任务用带时间的字段，普通任务用日期字段，而不是全组织统一。

2. 强制与自由

倾向是事实字段强制，承诺字段自由。计划开始时间和实际开始时间必须有值，因为缺了就无法计算；承诺开始时间可以留空，因为不是所有任务都需要对外承诺。

把承诺做成强制字段的结果，通常是所有人随手填一个和计划一样的日期，这个字段就死了。字段的生命力来自它真的被需要。

3. 统一口径与团队自治

倾向是计算逻辑统一，录入方式自治。偏差怎么算、按期启动率的阈值是多少，这些必须全组织一致，否则跨项目对比没有意义。但具体某个团队是每周更新还是每天更新，可以让他们自己定。

我在一个组织里见过相反的做法：各团队自定偏差容忍阈值，结果同一个项目里，A 团队认为两天内算按期，B 团队认为五天内算按期。汇总时两个团队都报 85% 的按期启动率，实际水平差了将近一倍。

4. 全量记录与抽样分析

倾向是全量记录，抽样分析。记录的成本主要在自动化环节，一旦配好，全量记录和不全量记录的成本差不了多少。但分析的时候没必要看全部，按任务类型或关键路径分层抽样，反而更容易看出问题。

我一般会固定抽三类任务做深度复盘：关键路径任务、启动偏差超过 90 分位的任务、发生过阻塞恢复的任务。这三类任务加起来通常不超过总量的两成，但能覆盖八成的管理风险。

结语

回到开头那个问题：为什么周报说已启动，月底还是延期。答案往往不在执行层，而在开始时间这个属性本身没有承担起它该承担的三份契约。计划开始时间负责推演，承诺开始时间负责对齐，实际开始时间负责归因，三者之间的差值才是项目负责人真正要读的信息。

如果你现在只能做一件事，我建议是把实际开始时间从人工填写改成状态流转自动写入。这一个动作能立刻消除大部分数据失真，而且不需要改变任何人的工作习惯。

如果你还能做第二件事，那就锁定基线。有了基线，你第一次能回答"计划被改过几次"这个问题，而这个问题往往比偏差本身更能解释一个项目为什么失控。

做完这两件事，再考虑依赖硬约束、浮动时间消耗率和分层看板。顺序不要反，因为前两件是地基，后面的是装修，地基不牢，装修越好越容易误导人。