项目总结-移花接木三期
这个项目是我从其他PM手里接过来的，对于前期的信息沟通不是很清晰。到我手里的时候，资源、范围都确定了，我就掉以轻心地按照升级包形式来做。
虽然发布之前制定了详细的计划、做了两轮的代码review，发布期间仍然出现了问题：充退查询原充值数据使用大字段兼容方案和分期支付渠道切换到渠道路由兼容方案 。
从项目角度反思了下，有几点是没有做好的：
1. 项目周期太长。从2月底做到5月初。其实工作量没有那么大，而是由于期间被插入过两个高优先级的业务型的升级包，开发和测试两个人都没有fulltime的投入项目，导致发布期间问题较多。以后制定项目计划时一定要避免这种拖沓的情况，让团队成员的注意力保持在一个项目中。
2. 没有遵循变更的处理流程，改动比较随意。 项目期间发现的变更有： a. 在功能测试阶段加入分期的逻辑规则 b. 在代码合并前一周加入无卡支付的搭车逻辑 。 这两个功能都只是系分、测分两个人沟通通过，其他人都是事后被告之，没有经过团队的充分评估。果然这两个后来加上的点在预发布、发布阶段都出现了问题。 以后面对既已发生的变更，在得知之后，还是要遵循变更流程，各方彻底评估后方能接受。
3. 对项目复杂度评估不够，各方资源没准备到位。从系分上看，这只是一个接口的迁移。没想到发展到后来，分期上线、浦发信用卡上线、收银台发布的不兼容等等问题出现，回头看看，资源上是有问题的：系分没有大型项目的经验、测分本身身兼产品Owner的角色，日常事情非常多、收银台的开发是个新人，对系统了解不够…. 当然这是马后炮，以后千万不能小看任何一个项目，每个项目都有独立性，都有不一样的风险，要保持警觉，谨慎对待。
4. 老问题，没管理好干系人。比如系分评审会议，没有喊上架构师和测试主管、 发布计划评审没有喊上SQA，让各种流程沦为形式，没有发挥好每个人的作用。还有一个，项目上线时间变更没有通知到北面（虽然不是需求方，但比较关心这个需求），导致与无线的配合比较仓促。
测分的个人总结：
新老数据兼容性测试，这是今后必须要考虑到也是要做到的点，相同问题决不能再次出现；
需要其他同学配合测试时，需要说明改动点以及测试点和范围，有必要的情况下还可以让配合同学也评估一下是否还有遗漏的点，毕竟人多力量大，想到的也更全面；
项目进行中新增的需求必须充分评估，较为保险的方法就是邀请相关业务负责人一起参与评估及分析，人与人之间重在沟通；
对于项目中任何代码的修改及删除的掌控度需要提高，只有自己知道了这里的改动，才能更好的评估出测试的范围；
对于老数据的特殊性需要追寻，测试过程中，建议增加捞取线上数据的比对环节，这样可以比较好的防止对于某些特殊数据的评估不足的问题。
以上几个问题都是测分需要做到的，但也都是比较花费时间和精力的事情，所以我发现公司制定的金字塔结构的组织架构真的很科学，很符合项目的要求。
为什么要将测分和测试执行者单独分开来？
就是为了让测分同学能有更多的时间和精力去完成上面总结中的工作，只用测分做好了，测试执行也就全面了。
这个项目中做到了测分和测试执行的拆分马？
没有，整个项目中测分和测试执行同学基本上是同一个，其他外围配合同学虽然找了一大推，有快捷网关的梦洁同学、信用卡分期的李寄同学、无卡支付的记儿同学、无线支付的羽东同学、直连冲退的淳于柔同学，等等，但是大家也仅仅是做了下回归工作，回归同学对于项目中的改动是什么根本不明确，这也就是总结中第二点需要改善的。说实话，本项目中测分很缺少时间来完成总结中的第三、四、五点的内容。我的错误在与向主管沟通，让其再协调一个专门进行测试执行的资源给我，替我分担这部分工作，这也是我今后在做此类大型技改类项目时要注意的地方，我太闷了，自己不是万能的。