工作拙见

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/bukker/article/details/79952199

今天上午被领导叫去进行了绩效面谈,自己所在公司的新财年是从4月份开始,每年到这个时候领导会按照公司的要求对员工进行面对面的交流,因为绩效的评价在3月底的时候已经完成了,面谈主要想了解一下员工对此次考核的看法,和员工交流去年财年的工作得失和接下来的一财年的工作方向,顺便看下员工对公司和工作上有什么好的建议,是一个比较直截了当了解员工工作状态的过程。


今年对于工作的建议主要提供了两点个人的看法,但内部轮岗制当时只是提供了建议,没有讲清楚原因。


1、加强内部资源共享

员工因为工作年限、工作内容和经验的不同,相互之间的水平层次不齐,容易产生较大的差距。而弥补短板最容易的方式就是利用现有的资源,加强内部的分享交流,每周利用恰当的时间来组织有经验的同事来进行分享,感兴趣的同事可以进行参加,一来分享者可以进一步理解自己的知识,和大家进行探讨,二来对于聆听着可以拓展自己的思路,可以解惑,了解不同的工作内容。选择外部专业的人士进行培训效果其实并不太理想,要体现效果周期会比较长,而内部员工相互间的交流却能立竿见影的体现效果。


2、内部轮岗制

现在的公司大都实行模块化管理,经常按组为单位进行工作的开展,每个人从进公司都会被安排负责自己的模块,如果中间没有什么变化,会很长一段时间都是处理同样的事情。但这其实对个人成长是不利的,长时间的流水线式的作业让自己很容易局限于此,虽然公司鼓励员工更专一些,每个人都能各司其职,大家一同协调工作干好项目,但更好的方式还是在保证公司项目正常进行的同时,可以协调一下人员的工作内容,让员工都跳出舒适区,让内部的水流动起来,迸发出更大的活力。我还是坚信,工作的广度和专业的深度并不矛盾,只有广的情况下才能找到自己需要专的地方,在很专的时候你又要跳出来,去寻找更广的空间,如此反复,螺旋上升,才能更好的清楚和发掘自己的价值,企业更需要去根据自己的实际需要去建立一定的机制去培养有创造力的员工,而非呆板、因循守旧。

 

PS:记得去年没有面谈,只是交了纸质版面谈表。另,公司的考核体系从自己进公司来就一直如此,没有什么改进,对于研发同事的KPI考核没有好的思路,还是按照老的套路一直在走。       


    微信公众号:帅不过三秒的码农


                    


阅读更多

关于单元测试的拙见和问题

03-01

对于单元测试,我觉得有三种情况:rn一是输入输出为值,且与数据库无关rn二是输入输出为值,且与数据库有关rn三是输入输出不是值的情况rn第一种情况常见于控制类,它的方法,一般情况下,参数就是输入值,返回值就是输出值,此时输出值只受输入值的影响rn第二种情况常见于实体类,它的方法,一般情况下,与控制类的方法相同,但是输出值不只是受输入值的影响,同时还受当前数据库的内容影响。rn第三种情况常见于边界类(一般就是界面,不知道我这样理解对不对),一般情况下,它的方法是系统定义的方法,虽然也有参数和返回值,但是对开发人员来说并不是很重要,有时甚至不用。如界面中一个按钮的clicked事件。rn对应于上面的三种情况,测试也有不同。rn对于第一种情况,比较好办,在设计这个类时,就可以写出测试用例,包括具体的输入值和期望输出。rn对于第二种情况,在写测试用例时,就必须先假定数据库中相应表的数据值,但是在真正测试时,并不能保证数据库中的真实数据就是我假定的数据,这种情况下,就需要测试人员去查看数据库的当前内容,就有些麻烦。rn对于第三种情况,我根本就不知道怎么去写测试用例。如一个按钮的clicked事件,其中有很多步骤,受影响的部分可能也有很多,这些情况在设计时都已经有说明了,如果对照着设计文档,应该是可以测试的,但要写测试用例,我就不知从何下手,总不能从设计文档中抄一遍吧。这种情况下,我现在的观点是不写测试用例,让测试人员直接看设计文档进行测试。rn以上是我的拙见,不知道这种分类是否科学,另外,对于我说的第二种情况和第三种情况,各位有何高见rn

没有更多推荐了,返回首页