2017年下半年我跳出开发团队，跳出了我8年的团队测试的舒适区（盒子），辅助三个团队PTL提升质量。三个团队没有专职QA，团队中的每个开发人员既是开发也是QA，并且3个团队承担了我们这个方向70%的业务，在这种情况下如何做质量工作对于我来说是非常大的挑战。
之前我的工作模式是行动到结果的循环模式，现在我需要思考的是如何辅助团队提高质量，如何知道团队质量确实提升了，如何提前识别可能存在的质量风险点？工作模式是思考到行动再到结果的循环模式。
在切换模式的过程中我也在找我现在工作的定位和工作方式。前期是迷茫加痛苦的，刚开始我完全是被动的，等待项目等待团队Ptl安排工作。唯一让我觉得可以发挥自己能力的地方是每个月的故障复盘，请来质量总工与我一起做质量复盘，做的过程中明白了质量复盘中引入环节和控制环节的意义，并且发现故障复盘可以识别出团队在哪个环节弱和哪项改进生效，让我对故障复盘有了新的认识，并且从质量总工身上学习到了很多。这是2017年下半年收获之一
由于之前是埋头在团队做测试，每天上班的目的就是完成自动化脚本编写和故事的验收测试，对于如何做好测试的思考是不够的。下半年，第一 与技术部的测试专家一起讨论什么是测试策略什么是测试计划，制定了2个版本的测试计划，针对我们项目大版本的系统测试输出内容包括4大部分(功能探索性测试，需求未测完的部分，专向测试和依赖环境无法测试的部分)，系统测试的输入是我们大版本合入的所有需求)，2017年收获之一，第二翻阅了海盗派测试分析，理解了做测试任务应该与开发做需求是一种做事方式，做测试任务也需要去做测试分析，测试澄清和测试设计，我认为这是我2017年在测试认识上有个质的飞跃。(在这个过程中，我实践了站在巨人的肩膀上看的高看的远的道理，明白了多和高人交流的好处)。
2016年参加TiD大会，让我明白了传统的测试只是保证质量的最后一环，而且对于质量改进是性价比最低的一环，质量从项目一成立就出生了，所以从那时起我开始关注每一个环节的质量，尤其是需求的分析质量。很幸运，在参加教练大会之前我看到无线根据需求五步法分析的需求，看完后我对需求要求输出的功能有了系统的认识，但是开发出身的BA认为关键点没有写出，比如新增的功能的依据是什么，里面提到的一个组件找谁联系等等，不同角色的人看到同一份东西感受如此不同，让我对于一个好的需求分析的标准到底是什么产生了好奇心，在教练大会讲师给了一个答案，需求分析后的输出应该是可开发可测试。可开发表现在通过分析需求得出开发需要实现的功能点(ux设计，功能使用频度，技术规格)，可测试表现在每个功能的正常验收点梳理出来。
教练大会与大家交流过程中也得到了一些启发
观点需要与不同的人讨论，反对意见越多检查你观点的机会越多，要感谢这些反对意见，因为它会让你成长。
每个人都有自己的模式，有些人是No,but 有些人是Yes,But。与人相处要有同理心
2017年最大的收获几个词来表达，同理心，套路，接纳反对意见，资源无处不在
