3. 延误数据采集
延误分析的起点是数据。如果原始数据不可靠、不完整或口径不一，后续所有量化评估都将失去意义。本节聚焦数据采集的三个核心环节：来源识别、清洗与标准化、常见陷阱规避。
3.1 数据来源：日报、周报与工时系统
项目进度延误数据通常散落在多个管理工具中。下表对比了三种主要来源的适用场景与优缺点：
| 数据来源 | 核心字段 | 优势 | 风险 |
|---|---|---|---|
| 日报 | 当日完成事项、遗留问题、明日计划 | 粒度细，可捕捉单日偏差 | 主观性强，易报喜不报忧 |
| 周报 | 本周里程碑状态、风险、下周预测 | 结构相对规范，便于汇总 | 滞后性明显，掩盖短期波动 |
| 工时系统 | 任务编号、实际工时、剩余工时 | 客观可审计，支持挣值分析 | 录入不及时，分类错误率高 |
实战建议：不要依赖单一来源。最佳实践是“工时系统为主 + 日报校验 + 周报定性补充”。例如，工时系统显示某任务已超支20%，日报中若连续三天出现“阻塞”关键词，则延误原因可快速定位。
3.2 数据清洗与标准化
原始数据必须经过清洗才能进入延误模型。标准流程包含以下四个步骤：
- 去重与补全：删除重复提交的日报记录；对缺失的“实际完成日期”字段，通过相邻记录或审批日志回填。
- 格式统一：将“2024/1/5”、“2024-01-05”、“1月5日”等日期格式统一为
YYYY-MM-DD；工时单位统一为“人时”。 - 异常值过滤：剔除单日工时超过24小时、负工时、或完成百分比超过100%仍标记“进行中”的脏数据。
- 标签标准化：将“卡住”、“等待”、“阻塞”、“依赖未完成”等口语化描述映射为统一延误标签，如
BLOCKED_EXTERNAL。
清洗示例（Python 伪代码）：
# 日期标准化
df['actual_date'] = pd.to_datetime(df['actual_date'], errors='coerce')
# 异常工时过滤
df = df[(df['hours_logged'] > 0) & (df['hours_logged'] <= 24)]
# 延误标签映射
delay_map = {'阻塞': 'BLOCKED', '等待审批': 'WAITING_APPROVAL'}
df['delay_tag'] = df['description'].map(delay_map)3.3 数据采集的常见陷阱
即使建立了采集流程，以下四个陷阱仍会严重污染延误数据：
- 幸存者偏差：只采集了“已完成任务”的数据，忽略了中途取消或长期挂起的任务，导致延误被低估。
- 时间戳污染：系统自动记录的“最后修改时间”被误当作“实际完成时间”，而实际可能滞后数天。
- 粒度错配：用周报数据计算日延误率，或用日报数据做月度趋势分析，导致信号被噪声淹没。
- 标签膨胀：团队成员为规避责任，将“自身效率低”标注为“外部依赖阻塞”，导致延误根因分析失真。
关键提醒：数据采集阶段不要追求“完美数据”。先建立最小可行采集集（如任务ID、计划日期、实际日期、工时、状态），再逐步补充质量维度。过度采集会拖慢分析节奏，且引入更多噪声。
3.4 数据采集清单速查
在项目启动阶段，建议按以下清单完成数据采集基础设施搭建：
| 检查项 | 验收标准 | 责任人 |
|---|---|---|
| 工时系统接入 | 所有任务支持按人、按天记录工时 | PMO / 工具管理员 |
| 日报模板标准化 | 包含“计划 vs 实际”对比字段 | 项目经理 |
| 延误标签库 | 定义 ≤10 个标准延误标签 | 数据分析师 |
| 清洗脚本就绪 | 可自动执行去重、格式转换、异常过滤 | 开发/数据团队 |
| 质量阈值设定 | 数据完整率 ≥95%，异常率 ≤2% | 质量保证 |
本节要点：
- 数据来源必须多元交叉验证，避免单一渠道偏差。
- 清洗标准化是延误分析的“地基”，不可跳过。
- 四大陷阱（幸存者偏差、时间戳污染、粒度错配、标签膨胀）需在采集阶段主动防御。