首先,技术经理其实并不大关注于功能的本身,其关注点有三个:
1. 会不会导致功能倒退(Regression),即需要修改的软件模块从正常工作的稳定状态退化到不正常工作的不稳定状态。
2. 好不好回滚(rollback),即快速关掉退化了的软件模块,降低影响。
3. 逻辑修改是否足够把以前的语义做了改变,所谓改变是指语义的加强或者削弱,即对模块原有的功能做了调整。
这些关注点往往也代表了客户的满意度,并且降低修改带来的风险。
另外:
针对一个Bug Fix(拖鞋),我们也要作Regression Test。
(1)验证新的代码的确把缺陷改正了。
(2)同时要验证新的代码没有把模块的现有功能破坏,没有Regression。
所以对于“回归测试”中的“回归”,我们可以理解为“回归到以前不正常的状态”。
然后,修改前的修改意图一定要尽早跟他们确认,比如要改什么地方,这样改行不行等。这些东西开头要讲好,细节写下来。如果一直没确认,开头带你的老员工跟你说你就改这里这里这里,你就开始改,然后经理说你这样改不行,然后老员工就说那你照着经理的意思改一下吧,不尴尬嘛?
所以在不熟悉系统运作的时候,还是应该尽早把要修改的地方记录下来,确认一下,然后相关联的接口名字大概过一遍,尽早确认,随时确认,面向修改管理。
还有就是合理处理老大突然找你做事情这个情况:
1. 听完老板的要求--> 询问这个事情着急吗,deadline什么时候。
2,告诉老板现在手里有a,b,c。。。也是需要这个deadline,询问老板是否着急
3, 让老板知道你手上的其他事情,如果老板着急就先做他的,不着急就先把手头做的一半的a做完再做老板的
最后就是,合理处理老员工和经理之间的关系,老员工是组长,经理比组长大,要面向组长和经理一同管理。