试点选什么场景
合适的试点场景通常有三个特征：重复频率高（收益能快速累积）、边界清晰（步骤与判断点有限）、风险可控（失败可回退且不直接影响核心业务）。常见的起点是配置巡检、日志清理、非核心环境的服务部署。相反，涉及数据库结构变更、核心链路切换的场景不适合作为第一个试点，失败成本会掩盖方法本身的价值。
基本信息
| 试点标准 | 高频、边界清晰、可回退、影响面可控 |
|---|---|
| 验证方式 | 对比执行耗时、失败率与人工投入 |
| 推广节奏 | 先相邻场景，再相邻团队 |
| 人员安排 | 明确试点负责人与后续维护人 |
节奏安排
- 第一阶段只做一件事：单一场景跑通并稳定运行，形成可复述的做法。
- 第二阶段相邻扩展：在同一团队内扩展到流程相似的场景。
- 第三阶段跨团队推广：把做法沉淀为共享能力并提供上手示例。
- 每阶段结束做复盘：记录卡点、返工原因与节省的工时。
- 避免并行铺开多个场景：资源分散会让每个试点都停留在半成品。
- 设定评估时点：明确多久后判断继续、调整或停止投入。
阶段目标与产出
| 阶段 | 目标 | 产出 |
|---|---|---|
| 选点 | 确定试点场景与验收指标 | 场景说明与指标基线 |
| 跑通 | 单场景稳定执行 | 可复用的资产与操作记录 |
| 扩展 | 同类场景覆盖 | 公共能力与变量规范 |
| 推广 | 跨团队使用 | 共享库、示例与培训材料 |
| 复盘 | 判断是否继续投入 | 收益数据与改进清单 |
试点阶段就要考虑维护归属：如果试点完成后没人负责继续维护，收益会在几次环境变化后归零，推广阶段也无从谈起。
推广的最大阻力往往是信任而非技术：把试点的执行记录与节省工时数据公开，比写方案更有说服力。