客户为啥不满意？
案例：客户一个业务系统做了数据库切换后，对乙方的保障方案开发团队很不满意。
甲方：我说说过的，但是没有要求你们做分析
乙方：后台开发没有收到，经过了解，是现场人员配合只对现场数据调整，但是没有通知给后台开发人员全面分析
底层分析：
其实甲方关心的保障系统还能用上不，会不会因为数据库切换导致无法使用
深层次的问题：前台信息没有传达到乙方开发团队，造成后台开发团队不知道，说明乙方在这件事情上没有做到一个整体，内部信息传递不够通畅。
解决方案
1、整合好团队：做好乙方内部做好前段、后台的沟通
2、消除客户顾虑：对于可能影响保障系统的问题，及时反馈给客户，消除客户的顾虑
甲方：听说最近用户需求更新了，不知道监控产品有没有
乙方：部分需求与客户核对，但是用户没有时间确认
底层分析：
其实甲方关心的核心业务系统的变化或者核心保障人员的新诉求，保障系统是否还能否跟上，如果跟不上，那对过去的系统做保障是没有意义的
深层次的问题是：开发团队以任务为中心，不喜欢任务的变化，变更受到阻力
解决方案
1、以解决客户问题为中心：转变开发团队以任务为中心的思想，改为以客户目的为中心的思想，同时注意，需要解决的问题始终没变。
2、定期检查需求和解决方案：定期与客户进行需求确认，包含环境变更确认，确保需求、解决方案还是正确的。
甲方：这是我们今年的工作重点，要求务必保证到位，并且已经和你们签订了合同
乙方：合同内容是写了做xxx功能，我们在做了，但是能不能保障不是合同范围内的工作
作为甲方，目标是保障核心业务系统，之所以愿意给乙方合同，是因为乙方在保障上提供了必不可少的贡献，但是甲方也知道不能只依赖这个，自己内部也要做好相关工作。
作为乙方，工作不是以保障系统为目标的，是以合同的任务，也就是解决方案分解出来的任务为目标的，如果解决方案出现问题，后续开发任务也是错误。如果环境及需求发生变化，解决方案也可能会受到影响。
由于半年开发周期，环境和客户需求可能会发生变化
存在的风险：
乙方的解决方案是甲方整体保障的一部分，单独执行无法给与全面的保障
乙方的保障方案是半年前的一个立项方案，随着时间推广，核心业务系统可能已经存在了更新，需要及时更新方案。
解决方案
1、尽早推出MVP：与客户在真实场景下验证，对于无效的功能停止开发，对于必须能力增加开发投入，同时注意成本。
