11.2.3 要求处理规范
标准的要求处理规范是按照时序来排列的，大体可以分为受理、调查、修正、确认与汇报等步骤。
（1）受理
受理客户提出要求的方式有很多，这里面最重要的一点就是不能漏掉客户的任何期望。根据要求的种类不一样，可以事先设计好各种标准受理报告单，以便沟通与管理，如故障处理报告单、QA管理表等。
（2）调查
受理之后，根据要求的紧急程度、重要程度等进行区分应对。进行调查时要注意以下事项。
①早期发现客户的失误。
即使是客户的失误，在原因判明之前，该客户也会一直认为是软件问题导致的，因此就需要早期发现客户失误。
另外，在运营过程中，对过去的要求事例进行整理时，要对客户失误率高的事例进行归纳，如果运用得当，则是早期判断客户错误的一个很好的手段。
②发现不良的统一管理。
产品上线后发生的故障，对客户来说防止再次发生是最为重要的事情。有些产品新版本发布后，更新与否取决于客户（例如：APP新版本更新），因此对所有不良进行早期登录，统一管理，同时记录解决方案，这在运营中是非常重要的管理手法。
③回避方案。
回避方案从大的方向来说有两个，一个是业务上回避，就是客户在操作规范上进行回避；另外一个就是需要修改程序。要根据具体系统业务特征与故障情况进行权衡应对。另外，如果是需要停止服务才可以解决的重大故障，则需要用最少的时间解决，以尽快再启动服务。
④原因解析。
原因解析的方法有很多，其中“分段排除法”，是一种非常重要的软件故障调查方法。例如，一部分远程计算机访问不了系统主页。那么如何找出故障原因呢？
首先进行一次切分解析，找出最有可能发生故障的位置，是远程计算机的原因，网线原因，网络代理原因，还是路由器原因？排查过程如图11-1所示。
假如此时初步判断故障的原因为路由器故障，这就是一次切分解析。此时需要联系路由器的运营维护者，由他们进行二次解析，来判明路由器内部的具体故障。
图11-1 一次切分故障排查过程
⑤影响范围。
对于本次应对所涉及的代码、文档，与本系统相关的其他功能，如批处理、报表，以及对其他系统的影响等，都需要做出明确的影响分析。
（3）修正
①代码修正。
修正要在充分调查的基础上进行，要对修正前后的变化进行对比分析，避免二次故障。
②文档修正。
文档修正包括式样、操作规范等与本次修改相关联的一切文档。
（4）确认
确认的流程与开发时的流程一样，都要经过单元测试、结合测试、系统测试阶段。由于系统是在运营中，因此更需要谨慎对待。然而，现实中往往在UT环境下测试成功后就把产品提交给客户了，这种偷工减料的做法很容易引起二次故障，一定要杜绝。
（5）汇报
故障处理完毕，在与客户的定期汇报例会上，对本阶段的所有要求的应对情况都要进行详细的汇报。这样可以让客户认可应对内容，更重要的是建立更好的信任关系，提高客户的满意度。