如何找对关键点
步骤一：识别关键成功要素、找对人
方法：
-
对要进行关键点萃取的活动和人进行分析：
- 技术要求？
- 特殊性？
- 某项工具？
- 领域专家、技术大牛
-
新人、出错较多的同事要参与一起讨论，帮助定位往往哪里会出现问题
-
开发过程管理人员：对于差异化的过程较敏感的管理方向人员
好处：
萃取经验的同时，触发创新场景，为创新增加更多的机会
步骤二：通过做法上的差异比较，找到核心区别
方法：比较2个工序上的差异
案例：
同样是查找和定位问题：2 个不同的系统定位线上一个接口返回数据较慢
速度快的组：
- 现象——监控（7分钟）
- 日志（0分钟）
- 运行时代码排查（5分钟）
- 尝试优化配置（系统接口得到改善）
速度慢的组：
- 现象——监控（5分钟）
- 日志（40分钟）
- 运行时代码排查（60分钟）
- 尝试优化（系统得到了一些改善）
偏差分析：
偏差在于监控的这个时间范围内，2 个组发现的问题不一致，导致其中一个组去日志中再次定位问题。
经验的关键点是速度快的组再监控里面发现了什么，怎么发现的？
关键发现：
- 工具差异：2组人使用的监控及日志查看工具不同，速度快的组使用的接口排查工具更直观
- 分析思路：速度快的组通过监控发现内存占比不高，实际服务器内存空间很大，进而检查服务器配置
- 问题定位：速度快的组思路清晰，通过监控数据逐步分析，找到了代码中的循环调用、死锁场景
经验提炼判断：
| 场景 | 是否需要写入关键活动 | 理由 |
|---|---|---|
| 数据库配置标准化 | 否 | 通过技控方法使开发、运维团队均不需要关注此项配置 |
| 通过监控快速分析代码死锁 | 是 | 不同接口代码编写方式和人员分析能力影响效率和质量 |
步骤三：语句优化，使人百分百理解并执行
方法：
- 最好找个逻辑感较好的、完全不懂这个领域业务的其他岗位人员逐行来看，哪里不懂直接提问
- 直接找另外的一名员工来模拟实践
三、关键点格式建议
格式标准：场景 + "必须" + 怎么做
1. 场景
- 穷举所有该场景下的要素，把输入交代清楚
- 例如：时间、地点、人物、输入
- 示例：在软件设计中，在后端对于枚举类型字段定义时，如果该字段是在前端展示，并且代表状态时...
2. "必须"
- 不一定是这2个字，代表肯定的语气
- 好处：执行时是百分百绝对的执行，而不是有各种特例
- 注意：如果并不绝对，但又确实是当下的最优方法，必须补充风险差异说明
3. 怎么做
- 明确的执行行动项
- 让所有的人无差别的执行，做到整齐划一