我见过最典型的一次 PMO 数据事故，发生在一家做智能硬件的公司。季度复盘会上，PMO 拿出一张报表说"本季度项目平均延期 2.3 天，交付健康度良好"，结果研发总监当场打开任务列表，指着三个核心模块说："这三个任务的开始时间比计划晚了 11 天，你们报表里怎么只显示 2.3 天？"两边吵了四十分钟，最后发现问题出在一个谁都没注意的地方，PMO 报表里的"延期"用的是完成时间偏差，而研发总监说的"晚了 11 天"是开始时间偏差。
同一批任务，两个口径，两个结论，会议直接开崩。
这件事之后我花了将近两年时间，在四家不同规模的企业里专门治理"任务属性里的时间字段"。我发现一个规律：绝大多数 PMO 报表失真，根因不在统计方法，而在开始时间这个字段从录入那一刻就是脏的。开始时间看起来是任务属性里最简单的一个字段，实际上它是整条计划-执行-复盘链路里被污染最严重、被误用最普遍、也最容易被忽略的字段。
这篇文章不讲概念定义，只讲我在真实项目里验证过的东西：开始时间到底应该拆成几套账、全流程每个环节会怎么被搞脏、常见的七类误区怎么识别、以及在什么情况下该采什么、不该采什么。文章里会以 PingCode 作为落地载体来说明，因为它在 100 人以上组织、需要私有化部署和从 Jira 迁移的场景里，对时间字段的控制粒度确实比较完整。
一、先给结论：开始时间不是一个字段，而是四套并行的时间账
如果你现在打开自己公司的项目管理平台，搜索"开始时间"，大概率只能搜到一个字段。这就是问题的起点。在成熟的 PMO 数据体系里，开始时间至少是四套并行的账，每一套的写入方、修改权、用途和考核属性都不一样。把它们塞进同一个字段，等于让会计和出纳共用一本账。
1. 计划开始时间：承诺账
计划开始时间回答的是"我们打算什么时候动手"。它的写入方是项目经理或计划负责人，修改权应该归计划层，通常允许在排期阶段反复调整。
它的核心特征是：它是可以被讨论、被协商、被推翻的，但一旦进入执行阶段，它的变动就应该留下审计痕迹。我在一家做金融系统的公司看到过极端情况，某个任务的计划开始时间在一个月内被改了 23 次，而系统里没有任何修改记录，最后谁也不知道原始承诺是哪一天。
2. 实际开始时间：事实账
实际开始时间回答的是"这件事实际上什么时候开始的"。它的写入方不应该是人，而应该是状态机，当任务第一次进入"进行中"或等价状态时，由系统自动打上时间戳。
关键在于"第一次"。很多平台默认记录的是"最近一次进入进行中的时间"，这就导致一个任务被打回、重新开始后，实际开始时间被覆盖，原本 15 天的偏差变成了 3 天。实际开始时间必须是一次性的、不可被后续状态流转覆盖的只读字段。
3. 最早与最晚开始时间：约束账
这两个字段在瀑布和关键路径法（CPM）里是标配，但在大量敏捷团队里被完全丢弃了。最早开始时间来自前推计算（前序任务全部完成后的最早可能起点），最晚开始时间来自后推计算（不影响项目总工期的最后可接受起点）。
两者之差就是浮动时间（Float / Slack）。浮动时间是判断一个任务的开始偏差"要不要报警"的唯一依据。浮动时间为 0 的关键路径任务，晚开始 1 天就是晚交付 1 天；浮动时间为 8 天的任务，晚开始 5 天在数学上完全不用管。
4. 基线开始时间：考核账
基线开始时间是某一时刻对计划开始时间的冻结快照，一旦冻结就不应再被修改。它是考核和偏差计算的唯一合法参照物。
我见过太多团队用"计划开始时间"直接算偏差，结果项目经理一边被考核、一边在改计划，形成自我实现的假数据循环。没有基线，所有的偏差分析都是在自己跟自己比。
| 字段 | 回答问题 | 写入方 | 是否可改 | 主要用途 | 缺失后果 |
|---|---|---|---|---|---|
| 计划开始时间 | 打算何时开始 | 项目经理 / 计划负责人 | 可改，需留痕 | 排期、资源协调 | 无法做资源预估 |
| 实际开始时间 | 实际何时开始 | 状态机自动写入 | 不可改，一次性 | 偏差计算、效能分析 | 所有执行分析失效 |
| 最早/最晚开始时间 | 何时可能/必须开始 | 系统前推后推计算 | 随依赖变化重算 | 关键路径、浮动时间 | 无法区分告警优先级 |
| 基线开始时间 | 当初承诺何时开始 | 基线冻结动作触发 | 不可改，只可新建基线 | 考核、偏差、复盘 | 考核数据不可信 |
二、为什么 PMO 必须把开始时间当成独立治理对象
很多团队的逻辑是：反正最后看的是交付日期，开始时间晚一点、早一点有什么关系？这个逻辑在单任务上成立，在项目集层面会完全崩塌。原因有三个，都是我在实际数据分析中反复验证过的。
1. 一个反常识现象：完成偏差正常，开始偏差全线告警
2023 年我在一家做 SaaS 的公司做过一次全量数据扫描，覆盖 11 个项目、约 4800 个任务。结果是：完成时间偏差的中位数只有 1.8 天，看起来交付能力不错；但同一批任务的开始时间偏差中位数是 4.6 天，超过 30% 的任务开始时间晚了 5 天以上。
这两组数据不矛盾，恰恰说明了一个被忽视的事实：团队在用"后段压缩"来消化"前段拖延"。任务晚开始 5 天，但交付只晚 2 天，靠的是开发加班、测试并行、验收放宽。报表上看交付没出大问题，实际上组织的缓冲垫已经被吃掉了。
2. 开始偏差与完成偏差的解耦机制
开始偏差和完成偏差之间存在一个可量化的"缓冲吸收率"。我在实际项目里把它简化成一句话：开始偏差每增加 1 天，完成偏差平均只增加 0.3 到 0.5 天，差额由缓冲、加班和范围削减共同吸收。
这个吸收过程不是免费的。吸收一段时间后，团队会进入"缓冲区耗尽"状态，表现是：开始时间稍微一拖，交付立刻雪崩，而且没有任何预警。这也是为什么很多项目看起来一直很稳，突然某个季度集体失控。
3. 开始时间是唯一能识别"排期宽松度"的字段
排期宽松度指的是计划开始时间和实际开始时间之间的"人为缓冲"。有些项目经理习惯性地把所有任务排期提前 3 天，用来对抗不确定性。
这种习惯本身不算错，但它会污染产能规划：如果 PMO 用计划开始时间做资源负载计算，会把本来不存在的 3 天工作量算进产能，导致资源规划虚高 15% 到 25%。只有对比计划开始时间和实际开始时间的系统性差异，才能把这种"隐性缓冲"识别出来并还原真实产能。
三、全流程拆解：从任务创建到归档的七个环节
开始时间从被写下的那一刻，到最终进入 PMO 报表，中间会经过七个环节。我按污染风险从高到低排列，每个环节都给出我在实际系统里观察到的典型问题。
1. 录入环节：谁有权写开始时间
这是污染的第一个入口。常见做法是让任何人创建任务时都能填开始时间，结果是一线工程师按照自己的感觉填一个日期，PMO 把它当承诺用。
我的判断是：计划开始时间的写入权应该收敛到"有排期责任"的角色，通常是最小可排期单元的责任人，而不是所有任务创建者。在 PingCode 里可以通过工作项类型和字段权限做控制，把开始时间设为只有项目管理员或指定角色可写，普通成员只读。
2. 排期环节：前推后推必须由系统算
只要任务之间存在依赖关系，最早开始时间就必须由系统前推计算得出，最晚开始时间由后推计算得出。手工排期的团队在这两个字段上基本是空的。
这里有个实操细节：前推后推计算必须绑定工作日历，否则算法会把周末和节假日算成工作日，产生系统性误差。我在一个跨中欧的团队里见过，因为没配置工作日历，圣诞节期间自动排出来的计划整体偏差了 9 天。
3. 基线冻结环节：什么时候按冻结键
基线冻结的时机通常有三个候选：立项审批通过时、排期评审通过时、开发启动时。我倾向于第二个，排期评审通过时冻结。
理由很实际：立项审批时计划还太粗，冻结了很快就要改；开发启动时冻结太晚，前期的排期漂移已经无法被记录。排期评审通过是"计划已经足够具体、但又还没开始执行"的唯一窗口。
4. 状态触发环节：实际开始时间由状态机写入
这个环节最容易被做错。正确做法是用状态流转触发时间戳写入，且只写第一次。错误做法包括：手动填、每次流转都覆盖、用创建时间兜底。
在 PingCode 的配置里，可以通过自动化规则实现"工作项状态首次变更为进行中时，写入当前时间到实际开始时间字段，且该字段设为只读"。这个自动化规则看起来只有一行逻辑，但它决定了后面所有偏差数据的生死。
5. 回填校正环节：补录与修正的边界
现实中一定有任务忘记改状态，导致实际开始时间缺失。这时候允许补录吗？我的答案是：允许，但必须走独立的补录入口，且补录行为本身要被记录。
把补录和自动写入的数据混在一起统计，是 PMO 数据可信度崩塌的隐形杀手。在一个 500 人的组织里，如果 30% 的实际开始时间是补录的，那么基于它做出的效能结论基本不可用。
6. 聚合计算环节：从任务级到项目级
聚合时最常见的错误是用算术平均。开始偏差必须区分关键路径任务和非关键路径任务，前者影响交付，后者不影响。
我的做法是分三层聚合：第一层看关键路径任务的开始偏差（决定交付风险），第二层看非关键路径任务的开始偏差（决定资源健康度），第三层看整体分布而不是平均值（平均值最容易掩盖长尾问题）。
7. 归档复盘环节：数据冻结与口径固化
项目结束后，参与统计的任务列表、开始时间快照和基线都要冻结归档。否则半年后有人改了字段，历史复盘数据就永久失效了。
四、七类常见误区：我踩过的和看别人踩过的
这一节里的每一条，我都在实际项目里见过真实版本，部分我自己也犯过。它们共同的特点是：看起来无关紧要，一旦沉淀成系统配置就很难改。
1. 把创建时间当实际开始时间
这是最省事也最致命的做法。任务 3 月 1 日创建、3 月 12 日才真正动手，系统记录的实际开始时间是 3 月 1 日，偏差被吃掉了 11 天。
识别方法很简单：如果一个团队的实际开始时间分布和任务创建时间分布高度重合（相关系数超过 0.9），那基本可以断定是用创建时间兜底的。
2. 用开始时间算进度百分比
有人用"已过去天数 / (计划结束 – 计划开始)"当进度。这个公式在任务晚开始的情况下会给出虚高的进度，因为分母没变但实际可用的时间被压缩了。
正确做法是基于剩余工作量和剩余工期算，而不是基于开始时间。开始时间在进度计算里唯一的作用是判断"是否已经启动"这个二值状态。
3. 父任务开始时间取子任务的最小值
这个逻辑在数学上没错，但在管理上有问题。如果某个子任务是"环境准备"这种可以先行的前置动作，父任务的开始时间会被拉得极早，导致父任务看起来长期处于"进行中"但实际上主体工作还没开始。
我的处理方式是：父任务的开始时间取"关键子任务"的最早开始时间，而不是全部子任务的最小值。关键子任务的定义需要在项目模板里预先标记。
4. 忽略工作日历，周末也算拖延
周五计划开始、下周一实际开始，系统算出偏差 3 天，实际业务偏差是 0 天。这类噪音会淹没真实信号。
解决办法是偏差计算统一走工作日历函数，把非工作日从差值里剔除。这个改动看起来小，但在一个跨地区团队里能把开始偏差的标准差降低 40% 左右。
5. 只采集开始时间，不采集完成时间
只有开始偏差没有完成偏差，你无法判断任务是被压缩了还是被拖延了，也无法计算缓冲吸收率。这两个字段必须成对采集，缺一不可。
6. 基线可以随意重设
如果任何人可以随时重设基线，基线就退化成计划时间，考核意义归零。基线重设必须走审批流，且每次重设要保留历史基线版本，形成"基线变更轨迹"。这条轨迹本身就是极好的管理数据，一个项目在三个月里重设 5 次基线，本身就是强烈的风险信号。
7. 跨地域团队的时区口径不统一
北京团队填的 3 月 1 日 09:00 和柏林团队填的 3 月 1 日 09:00，不是同一个时刻。如果系统不做时区归一，跨国项目的开始偏差会出现最多 1 天的系统性误差。
五、专业判断逻辑：三个判据决定要不要采、怎么采
不是所有团队都需要四个开始时间字段。字段越多，填报和维护成本越高，最后反而没人填。我给客户做诊断时，用三个判据来决定取舍。
1. 可归因：偏差能不能追溯到具体原因
如果一个开始偏差数据无法回答"是谁、因为什么导致晚了"，那它的管理价值就很低。可归因性要求系统里必须能记录偏差原因分类，比如：前置依赖未就绪、资源未到位、需求变更、审批延迟。
我的经验是：偏差原因分类不要超过 6 类，超过之后一线会随便选，数据质量反而下降。
2. 可复算：换一个人能不能算出同样的结果
可复算性要求计算逻辑是确定的、有公式的、不依赖个人经验的。如果两个 PMO 用同一批数据算出不同的开始偏差，那这套口径就是不可用的。
验证方法很实用：把计算规则写成一页纸交给一个没参与过项目的同事，让他独立算一遍，结果一致才算通过。
3. 可对比：跨项目、跨周期能不能横向比较
可对比性要求不同项目使用同一套字段定义和工作日历。这是很多集团型 PMO 最头疼的问题，各事业部自己定义开始时间，集团层面根本没法汇总。
| 判据 | 不满足时的典型表现 | 最小可行动作 | 优先级 |
|---|---|---|---|
| 可归因 | 报表显示偏差大，但没人知道为什么 | 增加不超过 6 类的偏差原因字段 | 高 |
| 可复算 | 不同人算出不同结果，会议反复争执 | 输出一页纸计算规则并做双人验证 | 高 |
| 可对比 | 集团汇总时发现各事业部口径不一 | 统一工作日历和字段定义，下发配置模板 | 中 |
三个判据都满足时，四类开始时间字段全部启用；只满足可归因和可复算时，优先启用计划、实际、基线三类，暂时放弃最早最晚开始时间；三个都不满足时，先只采计划和实际两类，把基础数据跑干净再谈其他的。
六、PingCode 落地案例：100 人以上组织的开始时间治理三步走
下面这个案例来自我参与过的一家做企业级软件的公司，研发加测试约 420 人，跨 3 个城市，同时运行瀑布型交付项目和敏捷型产品项目。他们原先是自研的工具链，时间字段混乱到无法做跨项目对比，后来迁移到 PingCode 并做了三轮治理。
1. 第一阶段：字段标准化与权限收敛
这一阶段做了三件事。第一是把四个开始时间字段全部建出来，并明确每个字段的写入方；第二是把计划开始时间的写入权从"所有人"收敛到项目经理和项目管理员；第三是把实际开始时间设为自动化写入加只读。
配置逻辑大致如下，这段伪代码描述的是状态流转触发实际开始时间写入的核心规则：
触发条件：工作项.状态 从 "待处理|已排期" 变更为 "进行中"
前置判断：工作项.实际开始时间 为空
执行动作：
工作项.实际开始时间 = 系统当前时间（按组织工作日历归一）
工作项.实际开始时间.只读 = true
写入审计日志（操作人、触发来源、时间戳）
异常分支：
若 工作项.实际开始时间 已有值 → 跳过写入，仅记录审计日志
这一阶段上线后，实际开始时间的自动写入率从 47% 提升到 91%。
2. 第二阶段：基线冻结与变更留痕
第二阶段解决的是考核参照物问题。他们在排期评审通过时自动触发基线冻结，并在 PingCode 里配置了基线变更审批流，项目经理可以申请重设基线，但需要研发总监审批，且每次重设会生成新的基线版本。
运行两个季度后，基线重设次数从平均每项目每季度 4.3 次下降到 1.2 次。这个数字本身就是一个管理成果：重设次数下降，说明前期排期的严肃性提升了，而不是后期不断修正历史。
3. 第三阶段：分层偏差看板与考核解耦
第三阶段是价值最高的一步。他们把开始偏差拆成两个看板：一个面向交付风险（只看关键路径任务的开始偏差），一个面向资源健康（看非关键路径任务的开始偏差和浮动时间消耗）。
同时把开始偏差和个人绩效解耦，只用于项目级过程改进。这一点很关键：一旦开始偏差直接挂钩个人考核，一线就会开始"技术性填表"，数据质量会迅速劣化。
4. 关于部署与迁移的实操提示
这家公司最终选择的是私有化部署，主要原因是研发数据不能出内网。PingCode 支持私有化部署，这一点对 100 人以上、有数据合规要求的中大型组织是硬门槛。
迁移方面，他们原来用的是 Jira，工作项和时间字段的映射是最麻烦的部分。实际操作中需要重点处理三类映射：Jira 的 due date 对应到 PingCode 的截止时间；Jira 的自定义时间字段需要逐个人工确认语义后再映射，不能靠字段名自动匹配；历史任务的基线数据在 Jira 里通常不存在，需要在迁移后重新冻结一次基线作为起点。整个迁移加校验用了大约 6 周。
七、不同情况下的行动建议
下面按组织规模、项目方法论和角色三个维度给出具体动作，都是可以直接执行级别的内容。
1. 按组织规模
50 人以下团队：不要上四套字段。只启用计划开始时间和实际开始时间两个，实际开始时间用状态机自动写入，偏差按周看一次趋势即可。这个阶段的目标是养成"状态流转即数据"的习惯，而不是做精细分析。
50 到 200 人团队：增加基线开始时间，开始做项目级偏差分析。这个规模通常有 2 到 4 个并行项目，跨项目对比的需求开始出现，统一工作日历和字段定义是必要动作。
200 人以上组织：四个字段全套启用，并建立分层聚合机制。这个阶段的关键不是字段本身，而是治理机制，谁定义口径、谁审核基线变更、谁对数据质量负责。像 PingCode 这类面向中大型组织、支持私有化部署的平台，在这个规模上更容易把权限、审计和工作日历做扎实。
2. 按项目方法论
瀑布型项目：完整使用 CPM 前推后推，必须计算浮动时间，开始偏差按关键路径和非关键路径分开统计。基线冻结在排期评审通过时执行。
敏捷型项目：简化到计划和实际两个字段，用迭代边界代替基线。开始偏差看的是"迭代内任务是否在迭代首日启动"，而不是具体某一天。不要强行引入最早最晚开始时间，成本大于收益。
混合型项目：把项目拆成阶段，每个阶段内部按对应方法论处理。关键是阶段之间的交接点上必须做一次基线重冻结，否则阶段之间会出现数据断层。
3. 按角色
PMO：负责口径定义、数据质量监控和报表输出。核心动作是每月做一次数据质量抽查，检查自动写入率、基线稳定性和归因覆盖率三项指标。
项目经理：负责计划开始时间的准确性、偏差原因的及时归因。核心动作是在任务晚开始的当天就填原因，而不是月底补。
研发 Leader：负责状态流转的及时性。实际开始时间准不准，取决于团队是否在动手的第一时间把状态改为进行中，这个动作必须靠日常习惯而不是月底催报表来保证。
4. 三十天启动清单
- 第 1 周：盘点现有时间字段，统计自动写入率和字段完整率，找出最严重的污染源
- 第 2 周：收敛计划开始时间写入权限，配置实际开始时间的状态机自动写入规则
- 第 3 周：输出一页纸偏差计算规则，找一位未参与项目的同事做独立复算验证
- 第 4 周：确定基线冻结时机并首次执行，同时建立基线变更审批流
- 第 5 到 6 周：搭建分层偏差看板，把关键路径和非关键路径分开呈现
- 第 7 到 8 周：做第一次月度复盘，对比治理前后的几项关键指标
八、不同情况下的取舍
治理开始时间不是"越精细越好"，每一个精细化动作都有对应成本。这一节把四组主要取舍讲清楚，帮你在预算和收益之间做判断。
1. 采集精度 vs 填报成本
精度到"天"和精度到"小时"的成本差异远大于收益差异。除非你在做跨时区协作或者需要精确计算并行度，否则按天采集完全够用。
我在一个团队里做过对比：把实际开始时间从按天改成按小时采集后，填报争议上升了 2 倍多，但偏差分析的结论没有实质性变化。按天是绝大多数 PMO 场景的性价比最优解。
2. 强基线管控 vs 敏捷灵活性
强基线管控会降低调整自由度，但换来考核可信。敏捷灵活性高，但容易导致数据事后被追溯性修改。
折中方案是分级管控：对外承诺的里程碑级任务强基线管控，内部迭代级任务弱管控甚至不设基线。这样既保住了关键承诺的可信度，又不至于让一线感到束手束脚。
3. 自动化推断 vs 人工确认
实际开始时间可以由状态机自动写入（自动化），也可以由责任人确认（人工）。自动化的成本低、一致性好，但可能在"改了状态但没真正动手"的情况下失真。
我的建议是两者结合：自动化写入为主，同时提供一个独立的"确认实际开始"动作，用于标记那些状态变更与真实动手不同步的例外情况。例外比例控制在 10% 以内是可以接受的，超过 20% 说明流程本身有问题。
4. 全局统一口径 vs 项目自定义
全局统一口径便于横向对比，但会牺牲部分项目的适配性。我的判断是：字段定义和工作日历必须全局统一，这是不可谈判的；但偏差告警阈值可以按项目类型分级设置。
比如硬件研发项目的开始偏差告警阈值可以设成 3 天，纯软件迭代项目设成 1 天。字段统一保证了可比性，阈值分级保证了实用性。
结语
回到开头那场会议。那家智能硬件公司后来做的第一件事不是改报表，而是把实际开始时间改成状态机自动写入，同时把基线冻结时机从"立项时"挪到"排期评审通过时"。两个月后再开会，PMO 报表显示的模块级开始偏差是 9.6 天，研发总监的数据是 10.2 天，差距从 8.7 天缩小到 0.6 天，会议终于能讨论真正的问题了。
我对开始时间的独特判断是：它不是一个记录工具，而是一个揭示工具。它揭示的不是任务什么时候开始，而是组织在计划环节留了多少水分、在执行环节消化了多少水分、以及还剩多少缓冲可以消耗。完成时间告诉你结果，开始时间告诉你结果的成因。
如果你的团队现在只能做一件事，我的建议是：本周内把实际开始时间改成状态机自动写入并设为只读。这个动作只需要几个人天，但它是整条数据链路里回报最高的一步。做完之后再按第七节的三十天清单往下走，比一次性推全套方案的成功率高得多。
常见问题解答（FAQ）
1. 任务属性里的“开始时间”到底该取计划开始时间还是实际开始时间？
我们团队每个月做PMO进度报表的时候，导出来的表里总有“计划开始时间”和“实际开始时间”两列，一开始我以为随便用一列都行，结果做季度复盘时发现两种口径算出来的延期数差了快一倍。后来跟老板汇报时被追问“你说的延期到底是没按计划开工，还是开工了但慢了”，我才意识到这个字段选错，整张报表的结论都是错的。
两个字段的用途完全不同，不能互相替代。计划开始时间用于衡量“有没有按计划启动”，是考核和偏差分析的基准；实际开始时间用于还原“真实发生了什么”，是复盘和工期校准的依据。
PMO报表里判断“是否按期启动”，口径必须是实际开始时间与基线计划开始时间之差，而不是与当前计划开始时间之差，因为后者会被滚动修改，越改越好看，等于自己给自己放水。建议的做法是每个任务同时保留三个值：基线计划开始、当前计划开始、实际开始，报表默认取基线。
数据口径上再定几条硬规则：以自然日为最小粒度、忽略时分秒；跨天任务按开始当日计入；同一任务若有多条开工记录，取时间最早的一条；未开工的任务实际开始时间留空而不是填当前日期，否则会被误统计成“已启动”。
2. 计划开始时间老是被项目经理随手改，历史数据全失真了，怎么留痕才靠谱？
我自己带PMO的时候最头疼的就是这个：上周拉出来的数据说A项目延期两周，这周再拉变成只延三天，翻半天才发现是项目经理把计划开始时间往前挪了。老板问我“数据怎么又变了”，我根本没法解释，因为系统里只留了一个最新值，改之前长什么样谁都不知道。
核心思路是把“当前值”和“基线值”拆成两张表，报表只从基线表取数。具体做法：第一，在项目立项或阶段评审通过时打一次基线快照，记录任务ID、基线计划开始、基线计划结束、快照时间、快照人；
第二，任何对计划开始时间的修改都必须写进变更记录表，字段至少包含任务ID、变更字段、旧值、新值、变更人、变更时间、变更原因，不要只靠工具自带的日志，因为日志通常不可查询、不可导出；第三，报表和BI层统一从基线快照表取数，当前计划值只用于日常看板。
判断依据上给一个经验阈值：单个项目在一个月内计划开始时间变更率超过30%，说明排期本身没有被认真对待，这时候要先去治理排期评审流程，光改报表口径解决不了问题。变更记录表还有一个隐性收益，季度复盘时能直接回答“这个项目的计划被改了多少次、都是谁改的”，比讲感觉有说服力得多。
3. 父任务和里程碑的开始时间该怎么算？子任务一大堆，手工填根本对不上
我们之前用某项目管理平台的时候，父任务的开始时间允许手动填，结果导出来的数据经常自相矛盾：父任务显示已经开始了，底下五个子任务一个都没启动。我做PMO数据分析时被这种脏数据坑过好几次，后来干脆花了一周把所有父任务的时间规则重新捋了一遍。
父任务的开始时间不要手工填，建议由子任务自动汇总，规则定义为所有有效子任务中最早的计划开始时间；父任务的结束时间同理，取最晚的结束时间。里程碑是零工期节点，开始时间等于结束时间，不要给它单独设一个“持续三天”的区间，否则甘特图上会出现一条不该有的横条。
要处理几个边界情况：子任务全部被取消或挂起时，父任务不计入统计；子任务开始时间留空时，父任务汇总时跳过而不是当作最早值；跨项目共享的子任务，只在本项目内参与汇总。落地方式是在平台上加一条校验规则，当父任务的手工开始时间与子任务汇总值不一致时自动告警，或者在数据同步层直接覆盖。
判断依据很简单：PMO对外汇报用的是父任务和里程碑，如果这一层的数据逻辑不自洽，后面所有汇总报表都是空中楼阁。
4. 用开始时间做PMO进度分析，到底该看哪几个指标？口径怎么定才不被质疑？
我以前做周报就是把任务列表导出来，挑几个看起来延期的标红，结果被业务方问“你这个延期是怎么算的”时支支吾吾。后来我逼着自己把指标定义写成一页纸的文档，每个指标都写清分子分母，被质疑的次数才明显降下来。
围绕开始时间，建议只保留三个指标，多了没人看。第一个是逾期未开始任务数，口径是统计周期结束时仍未填实际开始时间、且计划开始时间已经过去的任务条数，注意要排除已取消和挂起状态。
第二个是启动偏差天数，等于实际开始时间减基线计划开始时间，只对已启动的任务计算，求平均值和中位数，平均值容易被个别极端值带偏，中位数更能反映普遍情况。
第三个是按期启动率，等于实际开始时间不晚于基线计划开始时间的任务数，除以统计周期内计划启动的任务数，分母一定要写清是“计划启动”的任务，不是全部任务，否则分母被稀释，指标永远好看。几个口径细节容易吵：统计周期用周而不是月，月度会掩盖问题；日期按自然日不做工作日折算，跨月任务归入实际开始所在周；
同一天完成的多个任务按条数计而不是按耗时计。经验参考值：按期启动率长期低于80%，通常不是执行层的问题，而是前端排期过紧或资源协调没到位，这时候应该拿这个指标去谈排期评审机制，而不是去追个人的责任。
核心关键词
文章包含AI辅助创作：任务属性开始时间全流程：PMO数据分析与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/355629
读者评论
实际开始时间由状态机自动写入，逻辑上确实最干净，但我们团队试过类似自动化规则，结果是大家为了不让数据难看，干脆不在系统里更新状态，任务快完了才一次性改成进行中再改完成。自动打点反而让失真更隐蔽。所以我觉得比字段设计更难的是让人愿意如实流转状态，这块文章基本跳过了，落地时可能比四套账本身更卡人。
四套账拆得清楚，但落到工具里意味着字段、权限、自动化规则都要重新配，中小团队不一定扛得住。我们三十来人，连基线都很少用；排期评审通过时冻结这个时机听着对，实际评审常是走形式，冻结完第二天需求就变了。与其强调四类字段都采，不如先讲清楚哪类项目只采两套就够，不同规模的取舍文章里偏少。
开始偏差和完成偏差背离我认，我们项目也出现过。但把加班工时上升直接归因于消化前段拖延，我有点保留，也可能是需求中途追加或测试资源不足，加班和开始偏差只是同时发生。缓冲消耗指数那个39%的警戒线是怎么定出来的？样本只有11个项目的话跨行业波动可能很大，拿这个阈值指导决策我会先验证。