批判会后写感想：定岗定编定流程，业务、管理、人

今天临时被叫去参加一个会，结果开到后来，变成了一个对研发中心的批判会。因为会前没有会议邀请，会后也没看到会议纪要，不是很清楚会议议题，不过感觉应该是探讨公司怎么改进测试过程的。

我被叫去是因为带人在做的一个协议原型，开始是为了方便演示，顺便在里面写了个通用的能模拟业务逻辑的测试框架，这个框架完善后可以照搬到现有的应用中，有这么几个好处：1. 通过单元测试表述应用逻辑，做为文档的替代，能加快业务逻辑的传承；2. 能提高现有的单元测试的强度，提高代码质量；3. 模拟业务逻辑足够全面后，能够替代手工测试，大大降低测试代价。

我们部门，在测试环节暴露出的问题：

1. 开发人员业务逻辑不熟悉，无法准确评估所开发功能的影响域；
2. 代码质量低，没有完全实现需求；
3. 合并代码上线速度慢；

这几个问题我真的不好回答，按照我了解的情况，第一条是之前为了让开发人员工作饱满，跨产品线分配任务而且没有问题分析、文档整理时间造成的；第二条是具体当事人的问题；第三条是合并代码过程复杂造成的，想要改变这个过程，必须进入业务，和一线开发人员一起改进。

研发中心都存在的问题：

1. KPI考评缺乏测试部门的反馈
2. 内部缺乏沟通交流
3. 和公司目标不够一致

最后老总的总结我觉得是很有道理的，做为管理人员，最重要的工作就是定岗定编定流程，问题原因分析下来就这么几类：业务、管理、人。人的问题多了，就要加强管理。以前工作重心都在流程、业务上了，对定岗定编和管理问题都不够重视，还有和测试的沟通。由测试引发这个批判会，真是意料之外情理之中的事情啊！

其实把部门拆分成业务线，主要目标就是为了能更好的定岗定编。下一步我要进入一条业务线，在管理上，重点抓业务问题分析跟踪和人员培养；技术和流程上，把模拟业务测试框架引入开发工作，实践代码合并流程改造。要带出一个好的产品线经理，言传不如身教，否则还是只能在批判会上听到问题。