将项目管理过程中踩过的坑，遇到的场景，在这里进行分享，和同行业的伙伴进行探讨、学习。
坑一：客户方主导的系统测试，测试覆盖率完成度不高
项目背景及前提：
1、系统主体核心是我方负责提供服务；
2、客户方的系统测试是由客户方人员主导完成（客户是调用发起方，我方提供跨系统支持）。
风险：
因为核心服务是我方提供，所以承担的主要责任也在我方，进而，由于客户方的系统测试覆盖率不全，会导致上线后出现生产安全事故的风险概率会增大，即，客户的工作不到位，给我方带来很大的风险。
应对策略：
0、双方提前沟通测试方案、案例、计划等；
1、监控客户方的系统测试情况，明确测试覆盖率；
2、与客户方系统测试、客户方业务部门，都进行恰当的沟通，增大投入，在系统测试阶段，完成全覆盖；
3、如果系统测试最终覆盖率还是不完整，与客户方系统测试负责人加强风险沟通，如果客户方系统测试负责人应对态度消极，消息同步给业务部门，进行业务施压。
4、如果基本功能测试完成后，由于卡时间，提交UAT后，覆盖率还是不高，建议UAT阶段进行测试全覆盖，或者跟进线上高概率场景进行针对性测试（此时已经很被动，客户满意度风险很大）
5、同时，看是否能和领导沟通，安排出合理的上线试运行时间（为了这一步的风险准备，在项目规划时，就要预留出系统试运行的时间）。
6、出具我方最终测试报告，汇总报告情况及风险、问题，进行邮件通告。
最终目标：
1、上线之前，所有的测试场景，全部覆盖完整；
2、上线后，系统的服务可以稳定运行，同时，客户的满意度得到保障。
坑二：项目经理主导技术架构决策，系统频繁出现问题，导致客户满意度直线下降
项目背景及前提：
1、纯项目外包，项目经理，强矩阵式管理；
2、对接客户不懂技术，不参与过程管理或监控，只看结果。
风险：
1、项目经理本身并不是全身心投入技术研发，对于架构的把握，以及最终问题的解决，都不是直接处理人，这样对于技术、架构层面的决策，都是基于权利、主观的，与项目稳定运行的最终目标，很可能背道而驰；
2、项目经理决策的技术架构，并不一定是研发团队Hold得住的，整体开发节奏慢下来的概率很大，上线后出问题的概率会加大，解决问题的节奏也会慢下来，带来的一系列问题，需要很长一段适应期来克服、过渡，客户能否在适应期陪着团队一起适应，是个问号。
3、私自调整架构，客户虽然不懂，但是不保证后期不会让懂的人介入，如果一旦被后期得知前期的消息封闭，会让客户得出一个结论：我去理发，你告诉我他是个理发总监，结果是个毛头小子，给我剪坏了头，是不是要赔钱。（这是实际遇到的例子），最终的结果就是，团队形象一落千丈，客户极度不满意，以后所有的问题，客户都会说，研发团队的问题，乙方在欺骗他。
应对策略：
1、专人专事，技术层面的决策让技术专家来做，toB项目的最终目标就是稳定、可靠，客户才会满意。
2、强烈要求客户方配置懂技术的人员，一起参与项目，同步进度，同担风险。
3、项目过程管理，针对客户透明化，项目经理最忌讳鸵鸟心态，要充分提升自己的项目管理能力、风险应对能力、沟通能力等。
4、架构需要简化、尽快简化，千万别追求技术的新颖。
5、如果要扭转客户满意度急剧下降的这种局面，首先要加入技术专家、让客户认可，同时领导、商务出面，协商好惩罚手段，同时提出我方要求。
最终目标：
1、优化自身团队的职责分工；
2、带领客户提升信息化建立能力，让客户认可我方的管理、技术等能力；
3、完成架构的合理优化、裁剪，保证系统的稳定运行。
