新人上手时间
新人从入职到独立交付第一个变更的时长，是可维护性最直接的读数：环境搭建、代码可懂性、文档质量与评审引导都会体现在这条时间线上。它比纯静态指标更接近真实体感，因为参与者是缺少历史上下文的真人。
基本信息
| 度量 | 首个小变更合并的时长与阻力点 |
|---|---|
| 拆解 | 环境搭建、代码理解、评审沟通 |
| 动作 | 针对最耗时环节改善：脚本、指南、结对 |
| 频率 | 每季度用真实入职案例复盘一次 |
典型使用场景
- 入职复盘：按阶段记录耗时，定位系统性障碍而不是个人能力问题
- 环境改善：搭建耗时最长就先做一键脚本与容器化开发环境
- 文档改善：代码理解耗时长就补模块地图与「从哪读起」的入口说明
- 流程改善：评审等待久就设评审响应时限与对接人
- 横向对比：把多个新人的记录放在一起看，共性阻力更明显
复盘记录示例
复盘记录示例
# 新人 A：首个变更合并用时 9 个工作日
# - 环境搭建 2 天（文档过时，脚本报错 3 次）
# - 代码理解 4 天（模块入口不清晰，缺调用关系图）
# - 评审沟通 3 天（评审排队等待）
# 行动：更新搭建脚本、补模块地图、设评审响应时限阶段与阻力信号
| 阶段 | 耗时过长的含义 | 对应改善 |
|---|---|---|
| 环境搭建 | 文档过时、依赖缺失、脚本报错 | 容器化开发环境、一键脚本与冒烟自检 |
| 代码理解 | 入口不清、命名含糊、缺图 | 模块地图、架构说明、结对讲解 |
| 首个变更 | 不敢动老代码、缺测试 | 先派小任务、补关键路径测试 |
| 评审沟通 | 排队等待、意见不一致 | 评审时限、清单化评审、指定对接人 |
记录方式要轻：让新人在前两周自己记一行「今天卡在哪」，比事后回忆准确得多；复盘时只谈环节耗时，不评价个人学习速度。
别把上手时间当筛选工具：用它评价新人，会让人在不确定时不敢提问，真实上手周期被拉长，阻力信息也随之消失。