本周发生了一些事情，值得总结一下。
产品需要了解重要故障
本周有两个报障拖着没有解决，我检查了一下，发现这两个故障，其中一个是深圳的班级排序错乱问题，一个是佛山的业务订购冲突问题。第一个故障是全市都存在的问题，属于产品中存在的普遍性问题，属于设计缺陷；第二个故障不是普遍性问题，而是零星发生的，属于产品功能设计的缺陷，是由于产品功能在初期设计时没有考虑到会与其他功能产生冲突，导致冲突发生时系统处理异常。
这两类问题都需要产品经理去了解、跟踪，并提出解决方案的。但是现在运维人员接到这两类故障，是直接转到开发的手上，不会经过产品；而开发人员处理完成后，会直接转回运维手上，也不会经过产品；开发人员在处理过程中，可能只是对故障进行数据修复，或根据自己提出的、未经过沟通的、并非永久解决该问题的临时性解决方案来对故障进行修复，而未站在更高层次上提出、实施最终解决方案。
开发人员与产品人员的思维迥异。产品人员考虑的是，故障是否会产生大范围、持续性影响，综合考虑功能之间的互相作用，评估更高层次的影响，评估出临时性解决方案及永久性解决方案。而开发人员的思维模式可能更倾向于思考问题所在，并只是专注于问题的修复，缺乏更高层次的思考。
由于产品没有渠道了解此类故障，对这类故障一无所知，更无法站在产品层次上对故障提出意见。
如何控制客户需求变更
最近我发现，每次找省移动领导开会沟通需求时，省移动的需求总是会与上次的不一样，然后开会完了之后总要再修改一番，然后再给省移动领导确认的时候，省移动的想法又变了，然后又改。这样首先会导致自己的情绪会不知不觉产生变化，觉得会受挫；其次会导致工期变得紧张，方案不能准时实施，后期坑了小伙伴们。
该如何克服这种问题？孙川提出来的想法是跟省移动确认完一次之后，跟省移动说，修改完这一版之后，就马上投入开发了。如果后续省移动有新的想法，就应该在下一期再规划实施。
或许我应该这样实践一下？
