简图记录-客户问题处理经验（沟通、排序、处理、回溯、总结）

简图记录总结~客户问题处理

    作为软件开发人员，客户问题处理是每个研发人员需要暂用大量时间处理的工作。以下是个人在处理问题过程中的经验总结。

一、客户应对经验

    一般情况研发的同事比较少直接面对客户，大部分还是通过一线的技术支持人员与客户进行沟通。如果你的邮件抄送列表包含了客户，或者电话会议时发现客户也在里面，就必须要慎重的应对：

      （1）注意沟通过程内容需要受限，部分内容是不适合到客户侧。不要轻易 进行根因分析、问题定性、给计划点，这些关键信息应该是由产品维护接口人同意正式提供给客户，不要过于讨论方案细节 暴露内部设计，这些都是关键信息资产。尽量避免和客户直接沟通，即使客户直接联系也要拉上一线技术支持人员。

    （2）不要发现不是自己的问题就急于“甩锅”到他人，引起客户反感。客户不关心 你是负责哪个模块，在客户的眼里你就是代表你的公司，因此特别注意表达。

    （3）不要情绪化，要塑造一个专业、冷静、慎重的形象给客户。表达要逻辑清晰。

二、一线沟通经验

    一线技术支持人员是研发和客户之间的桥梁，他们考虑的就是如何尽快解决客户的问题，完成客户的需求，会面临比较大的客户压力。而研发的角度不同，站在产品研发的角度，首先弄清客户的真实诉求，确认是不是真实问题、是不是必须要这个版本解决，需要考虑解决方案的合理性与工作量、会不会引入约束和对架构的不良影响，很多问题解决方案都是有代价的。

    （1）对于一线的支持和反馈要及时，保持良好的沟通。一线客户压力大，处事风格会偏急，而研发有自己的节奏难免会无法及时支持，这个时候注意要保持快速响应，尽量不让现场干等“挂着”，我们可以快速分析后 让现场辅助做一些信息确认、log抓取、辅助调试。避免由于时间冲突长时间不响应。

    （2）研发人员要保持自己的研发思路，避免只想快速解决问题，但同时也要体谅一线的客户压力。在沟通过程多给一线灌输一些流程 规制限制，在解决问题的同时也要防止架构腐化。是不是真实的问题?是不是当前需要解决？解决方案有哪些，会引入什么约束，是否通过其他模块实现更合理？代价是什么。

    （3）注意沟通过程 正确/准确/清晰/高效，要有逻辑性，不要急躁。客户现场反馈的信息要注意保持警惕，现场环境复杂消息在传递过程中也可能出错，针对关键信息或者有疑问的地方要及时确认。注意重要的信息需要邮件发送并知会相关人员。

    （4）尽可能维护好与一线的关系。在不违背规定的前提，如果时间允许也尽可能多给予支持，如果有困难也要实事求是的表述，计划投入的冲突，流程或制度的限制，相互协调。

三、优先级划分经验

      研发不可避免的会面临多问题的并发，多个产品线、不同的客户、不同的项目各类问题都会并非投入，同时你可能还需要支持开放计划。应此问题必须要做好优先级排序 和 投入冲突的协调。

    （1）问题的排序，总体上 以客户项目阶段划分：是demo演示、内部测试、量产转产 还是 正常维护问题，特别是阻碍客户生产的紧急问题一定要第一时间投入。如果问题阶段相同，建议按产品客户优先级（战略客户、大客户、小客户）配合问题的严重程度影响范围选择。

    （2）问题的投入协调。当一线对于研发问题投入计划又冲突时，则需要协调问题投入，首先研发必须清楚自己当前问题投入的顺序，进行沟通看一线是否接受，如果必要将涉及产品维护接口人拉通一起讨论如何排序。

    （3）维护周报。当维护线压力较大，面临多个问题并发同时涉及资源协调时，建议以周报的方式知会到老大和产品各个项目接口人。周报内容应该包含：1、总体状态描述 2、罗列各个问题及其状态 3、反馈以解决的问题和后续投入重点 4、反馈当前人力投入，有哪些人投入在占比 5、风险点 6、资源诉求

四、问题处理经验

     在处理问题过程：

    （1）遇到问题先尽快排查是否是自己模块问题，定位清楚是外部模块的问题要及时拉通交接出去，及时交接非本模块问题。      （2）要做好过程记录，问题描述、信息确认、复现流程及概率、如果自己搭建环境记录搭建流程、定位分析过程、实验调试操作及结果。

    （3）做好风险的控制和上报，识别到风险后要及时邮件上报知会，寻求资源投入，必要时主动组织问题攻关小组。

    （4）注意问题处理边界，不要修改其他模块代码即使看上去流程很简单，不要推测其他模块内部行为和约束。

五、客户问题回溯

      遇到客户投诉问题 或者 影响较为严重的问题，会针对此问题进行问题回溯（部分问题可能涉及追责），在进行问题回溯过程，一定要注意对事不对人，目的是吸取教训形成规避措施，注意人员参与和报告发放的影响范围。

      问题回溯需要提交正式报告，应包含：（1）基本信息，问题时间地点处理人、回溯责任人及参与人员。（2）事件描述，什么时间地点，谁发现了什么问题，现象是什么，影响范围多大。（3）过程回放，按时间阶段描述定位解决过程关键点，问题发现、分析、核实、方案输出、解决。（4）根由分析，针对问题缺陷引入的环节进行分析，识别关键因素 （5）解决措施 （6）预防措施。

六、项目维护问题总结

      在项目转维节点都需要针对项目的问题情况进行总结分析。提高后续项目的开发维护效率。各个模块研人员 项目问题总结可以从以下几个维度：

    （1）本模块有效问题的投入比例。要区分自己投入的问题单中有多少比例是非问题、多少定位后发现是其他模块问题交接处理。分析比例是否合理，有没有什么方法降低分问题比例？（添加FAQ说明等）降低非本模块问题投入比例？（丰富debug手段）

    （2）问题的内部模块或者规格分布。是哪些规格占比最多？为什么？是由于什么变化引入？为什么前期无法识别？有哪些预防纠正措施？

    （3）问题提出阶段分布。研发自测，研发联调、测试部测试、客户反馈的比例各占多少？是否合理（721原则）。思考为什么这些问题会从自测遗漏出去？后续怎么改进覆盖率？

    （4）问题的引入类型。分析这些问题 是 新需求/规格遗漏/方案不完善/硬件约束/外部模块引入/软件编码问题，针对编码问题也可以进一步分析 同步异步/锁使用/中断问题等。思考如何改进。