程序员分析处理问题总结

在程序员的工作中 大量时间 实际都在处理和分析问题，很多时候我们都是凭借 经验和习惯分析问题，没有意识去打磨问题分析方法，提升自己能力。写此文 目的总结一下 个人在工作中，关于问题分析，问题单处理 等 经验，方便后续持续完善提升。

一、问题分析处理原则总结

在日常工作中，我们要更多集中在提升自己的问题分析解决能力，而不是习惯性被问题缠绕整天困于项目问题处理中。问题永远处理不完，假如一个项目没有任何问题 也就没有 研发投入的必要了。而解决问题分析能力 和 效率的提升 则是我们自我实力的成长。一个典型问题分析逻辑如下：

1. 先判断 是不是有效问题？— 对齐信息 理解一致 / 有效性确认 / 是否需求

当一个问题从 客户&一线&测试 反馈过来时。第一步 应该是 先判断 是不是一个有效问题，而不是急急忙忙投入。
1）要收集已有的信息，并且双方对这些描述理解一致： 如 所在项目与版本（是不是旧版本已解决问题？），问题场景和异常现象，正确预期（是否是真问题？还是理解偏差？），复现操作（操作是否正确？），是必现还是概率 概率多大（是否是单体问题？硬件或者环境问题？），是否有关键日志（指向性如何？）。 这些信息不完整时，可以要求收集提供。
2）对信息有效性 疑点 进行确认。 在用户提供问题信息时候，一定要考虑信息错误的可能。很多时候 反馈到你手上可能已经 转了好多次 信息和原始情况 有偏差或者错误。甚至最原始的操作者 执行过程或提供信息就不准确。对于一些决定性的关键信息，我们可以提出疑问，或者通过其他信息 或 实验 来佐证。（提供的这个点信息准确吗？是否能看下XXX 或者 进行XXX操作 明确下这个关键点？ 这两个信息有冲突 需要进一步明确下XXX）
3）考虑是否实际为新需求。有时问题和边界没有那么清晰，特别是客户的角度，容易把 隐含的需求 识别为问题缺陷。此时就需要研发识别出来，让客户按需求流程进行，避免把需求按问题处理。

2. 问题的分类和各类问题处理策略— 缺陷 / 矛盾 / 标准不明确

问题也分很多类型，不同的问题，要有不同的处理策略。
1） 缺陷：未正常运转的故障，最常见的问题类型。比如死机、花屏、无法启动等。处理策略：明确出现的场景，问题现象，正确预期，正向分析缩小问题发生范围，制定解决方案。
2）矛盾：某些对象或者目标之间存在冲突。比如 添加XXX算法后 开机速度下降，优化静态闪后动态闪 恶化严重了。处理策略：明确是哪些对象间存在冲突，冲突逻辑如何是否属实，客户侧更看重哪个目标（注意调整客户预期），如果优化或者调整平衡后仍然无法满足客户要求，需要上升决策。
3）标准不明确：无明确目标 或 主观判断双方不一致。比如 显示静态闪 虽然客观设备指标通过 但是 主观测试中 客户认为 有问题，XXX指标 两边判定结果不同 测试方法或者环境条件 不一样。处理策略：如果存在客观指标 明确细节 对齐操作差异，主观效果判定不一样 需要多对齐信息，上升专家判断，重点更多的是沟通对齐。

3. 困难问题应对策略—研发侧-协调资源 / 客户侧-降低期望 / 项目侧-上升求助

在定位问题过程中，肯定会遇到 一些困难问题，分析没有思路 或者 没有找到解决方案，短期无法解决 就需要攻关应对，而不是一个人硬抗 搞得压力很大，典型策略如下：
1）策略1 研发侧 协调专家资源，加大投入：把当前 问题背景&&影响、问题范围阶段性分析状态、重点怀疑方向、关键实验及其结果 整理好，在研发内部协调 涉及范围专家，或者 求助引入系统工程师，共同分析定位。
2）策略2 客户侧 加深沟通，降低预期： 短期难以解决的问题，一定要加深和客户沟通，在客户侧 尽量降低预期，了解清楚真实的影响。客户项目处在什么阶段，发生后影响如何，是否阻碍关键过点。如果不能完整解决，能否先规避 或者 先临时方案降低影响？
3）策略3 项目侧 上升求助，获取跟多支持：短期无法解决的阻碍问题，项目内部要进行上升。一方面可以推动获取更多投入资源，另一方面项目不是单纯技术层面的问题，商业项目推荐涉及因素很多。

4. 无法解决的问题应对策略—无法复现-降级挂起 / 可复现问题 集体评议挂起

项目过程中我们可能会遇到无法解决的问题，持续投入之后仍然无法解决：
1）类型1 无法复现的问题： 针对无法复现的问题，可能由于环境影响，或者 单体硬件缺陷 / 操作问题 引入，这类问题要定一个降级机制，比如几个版本或者多长时间 无法再复现，降低级别，到最低级别时进行关闭。
2）类型2 芯片设计问题&&系统性问题：有些问题最终识别到为芯片设计阶段问题，且无法通过软件规避。或者 属于系统性问题，要解决会导致系统架构上受到冲击，导致大范围方案受到影响，引入不可控的工作量和隐含风险。 这类问题 只能通过集体评议的方式 判断是否要挂起，根据项目影响决策。

5. 如何避免问题缠身—把控入口 / 划分优先级 / 及时求助上升 / 传递能力

在项目问题解决过程，很多时候会面临 并行问题过多，严重问题攻关困难，无法解决问题引入复杂决策和沟通，容易问题缠身。建议如下：
1）明确边界，把控问题入口：要渐进明细自己的责任边界，特别是在快速发展的项目中不是一层不变的。设计上加强问题界定DFX，同时形成一些界定规则【什么情况需要我投入？什么情况一定和我无关？】，实时刷新推广出去。避免变成老好人，最终就是什么都找你，干得越多活越多，结果本职工作没投入做好。
2）观察全局，问题优先级划分：要养成全局眼光，时刻管理自己的任务list，优先整理问题的影响，影响决定价值。重要切紧急的问题&&重要问题优先投入。低优先级的问题 延后处理，转他人处理，甚至 极端情况 不处理。
3）重难点问题及时求助上升：不要惧怕复杂困难的问题，在定位这种问题 时 往往是我们成长最快的时候。重难点问题（没有任何思路、过于复杂分析困难、跨领域处理经验不足）要及时上升求助。求助的过程要注意方式方法，把自己进展总结好 收集好必要信息，拉通处理，要有自己的判断，有主导意识 而不是跟着其他人走。
4）传递能力，培养备份释放投入：要总结自己范围的问题定位思路和手段。培养备份 把能力传递出去，这样一些基础的问题 就不再需要你持续投入 消耗资源。专注在更有价值的事情上。

5. 解决问题过程心态建设—避免过度责任感 / 正确看待批评与投诉 / 关注能力成长

在问题投入过程 很容易搞得压力巨大，我们在工作中要多注意心态建设，聚焦能力提升，几个建议：
1）避免过度责任感，保持平稳心态。 项目成功不是靠人而是靠机制，靠人的项目无法走远。很多时候出现问题不是一件坏事，提醒自己 问题出现不可怕，锻炼能力，及时解决降低影响，总结避免再次出现，完善运作机制会推动项目前进。要平稳心态，专注能力成长。天塌了有高个子顶着。
2）正确看待批评与投诉。没有任何人能永远正确，搞项目不要恐惧批评与投诉，如果的确和自己相关，挨打就要立正，狡辩甩锅短期会获得利益 但长期来看不利于合作和个人成长， 好好总结即可。要保持和领导良好的沟通，自己面临的困难 和 想法传递出去，参考他们的建议，能帮助展开思路。
3）关注能力成长，目光放长远。我们要想明白自己的目标到底是什么。是解决这个问题么？是完成这个项目么？是完成领导期待么？如果完成了这些结果如何，不完成这些结果如何？影响是什么，一年后怎么样 五年后怎么样呢。归根到底，我们真正关注的是利用现有工作提升自己的分析解决问题能力+高压力环境应对方法，这样我们才不会总是纠结一时的问题和得失惶惶不安。

二、典型问题单流程总结—角色关键职责 / 冲突处理

项目的运作不要依赖人而要依赖流程。很多时候 我们都在吐槽 公司的问题单处理系统 麻烦 难用，实际上 另一面 问题单系统也是在保护我们，通过流程让 责任边界更加清晰，避免大家掉坑里面。一个问题单 简要流程如下（各个公司差别较大，不同项目 客户到研发层级 测试流程层级 也有差异，总体思路是一样的）：

下面我们从各个角色来做一些整理

1. 【关键角色1：呈现问题提单者】— 清晰表达 / 准确定级 / 收集必要日志 / 提单争议处理

提单人，典型就是测试组的兄弟 或者 一线支持人员。发现问题时 注意如下：
1）问题清晰表达：所在项目与版本，问题场景和异常现象，正确预期，复现操作，是必现还是概率（概率大致多大）。举例：在XXX机顶盒项目，XXX转测版本，在开机过程在logo阶段 发生概率花屏现象（正常应该显示logo图标），测试概率大致1/10，测试机SN编号XXX；
2）问题准确定级：问题定级影响研发优先级投入，和 对项目状态与准出判断，非常关键，问题定级别要有统一的标准，根据要素决策严重分数定级。典型判断要素如下：是否用户常用操作，是否常用&重要功能，出现场景条件，出现时影响-功能丧失/体验下降，恢复条件
3）收集必要日志&初步定位信息：提单时要收集 必要的软件日志信息，关键状态，异常现象的 截图、照片、视频 等，便于后续定位。如果是一线技术支持人员，要进行问题定位分析，把分析过程 做了哪些实验 结果如何 也记录起来。
4）提单争议处理： 测试和研发之间 时常会有争议情况，是不是一个问题，要抓取哪些关键日志，是否要保留环境调试，或者 反馈问题无人响应判断等。这里涉及内容较多 不再展开，总体原则 如果打不成一致，上升到 测试经理和版本经理 进行判断。

2. 【关键角色2：问题解决处理者】— 根因描述 / 方案描述 / 用例&DFX分析 / 公共问题排查

问题解决者，通常是具体模块开发人员。在解决问题 走单时，要注意：
1）问题根因描述：讲清楚问题逻辑，为什么会出现这个问题；引入问题原因，是近期修改引入 还是 一直都存在；漏测到测试&客户原因，是没有对应研发测试用例 还是 执行不到位；
2）解决方案描述：使用什么方案解决的此问题，如果有代码提交需要附上。
3）用例&DFX分析：是否要新增研发用例，是否要新增DFX手段 方便后续同类问题定位分析；
4）公共问题排查：之前已发布的版本是否有此问题，是否需要推动客户更新版本。

3. 【关键角色3：问题过滤与审核者 】— 问题是否合理 / 提单规范性 / 走单规范性 / 问题度量

问题审核角色，如版本经理 或者 测试经理。
1）、提单是否合理，是否规范。针对提问题单，问题合理性，是否是一个真实的问题，同时针对提单的规范性进行审核。不合规的需要打回。
2）、走单规范性，度量填写是否正确。针对研发解决回归的单，同样要审视内容填写规范性，同时 走单时 填写的问题模块 责任领域是否正确，这些信息在项目阶段性评估时 非常关键，会影响研发的开发质量评估。

4. 【冲突处理：问题降级与挂起处理】— 制定降级规则 / 挂起集体评议

1）问题降级：如果提单初期定级不合理，研发可以与提单人沟通，达成一致后进行调整，有冲突就上升评估。如果是长期无法复现的问题，这类问题需要制定统一的标准，研发 复现多少个版本 或者 多长时间 仍然不出现，提出降级要求。
2）问题挂起：部分问题无法解决，或者影响可控当前项目不解决，可进行挂起操作。此时需要集体评议，需要涉及利益方参加，除了提问题所在模块责任人，还需要 版本经理、测试经理、项目技术专家 共同评估。

三、问题攻关运作总结

1. 什么问题需要启动攻关？—影响产品过点 / 影响生产 / 影响关键联调特性 问题

针对影响 产品过点，阻塞关键特性联调问题，或者 影响重大的现网问题、生产问题；

2. 问题攻关的运作要求—成立攻关组 / 定期召集会议 / 审视上升求助

问题攻关要成立攻关组，明确攻关的目标和计划和分工，建立响应群组。
攻关牵头人 每天或者定期 召集攻关会议，分析关键数据，总结当前进展，制定下一步计划。
根据问题进展，更新攻关涉及人员，如果问题定位受阻，需要审视进行上升求助。

3. 问题攻关日报内容—问题概述/参与人/整体进展/事项跟踪/困难求助

问题攻关的时候，通常需要进行攻关日报 或者 攻关周报，发送给主要参与人，和涉及利益方（主要参与人 主管 等）
攻关日报主要内容举例如下：需要体现 问题概述、主要参与人、问题描述、整体进展、关键进展、事项跟踪、困难与求助。

三、问题报告编写总结（待补充）

四、项目问题阶段性度量分析（待补充）

其他

批判性思维总结（提升信息结构化分析能力）：https://blog.csdn.net/runafterhit/article/details/80474045
金字塔原理（提升信息有层次表达能力）：https://blog.csdn.net/runafterhit/article/details/52772258