这些是我最近思考几个问题,我在这里和大家来探讨一下
(一)关于技术交流:
技术人员的技术交流分为正式和非正式两种途径,正式的比如培训和会议,非正式的途径就很多了,比如一起吃饭聊技术,一起喝茶,或者甚至大家在一起排队等待热水时的闲聊,正式交流一般可以由公司去组织,见效快,周期短,而促进非正式交流却需要很细心的去规划,周期长,效果难于衡量,所以一般公司都倾向于用技术培训和交流会来进行技术交流.一个优秀的,然而从交流比例上来说,具有很好交流传统的公司,非正式的交流应该至少占到80%,正式的交流约占20%,而且在80%的非正式交流中,那些面对面的交流实际是最有效果的,而且这种非正式交流实际是企业文化的重要组成部分,所以我认为衡量一个公司交流的指标应该包含对这个比例的考量,那么问题就出现了,
Q:既然非正式交流如此重要,但是又难于操作,那么我想向大家请教,大家觉得什么样的方法能够促进这种非官方的交流呢?
(二)关于绩效考核:
悖论一:越高明,越感觉不到
我很热爱运动,也经常会有一些运动装备,当我使用他们的时候,会有这样的感觉,越是设计出色的装备,越让你感觉不到他的存在,而只是默默的为你服务,相反,一件质地或者设计不好的装备,却总让你觉得别扭,比如一件不透气的球服,你反而总会想到他,在软件设计上,一个好的架构师设计设计出来的架构,会让实现者觉得非常舒服,甚至很少感到他的存在,于是我们却往往忽略了这些优秀的设计,一些蹩脚的设计却往往引人注目,因为他总有这样那样的问题,而解决这些本来可以避免的问题却让某些人得到重视.再比如一个程序员接手了一个预计需要两周的程序,却花了四周的时间,在报告中,他不断提出这个任务的各种"没有考虑到的难点",并且在三周中加班加点进行开发,最后虽然任务拖延了很久才完成,主管却认为这个技术人员克服了很多的难度,并且非常勤奋,于是给了他嘉奖.后来另外一个程序员接手这个程序,发现这个旧的程序完全是拼凑起来的垃圾,维护他,不如重写他,于是他花了一周半的时间,每天只花工作时间,就完成了这个任务.显然,第一个程序员因为小题大做受到了嘉奖.(这个例子来自员温博格的著作《程序开发心理学》)
Q:由于这个悖论,考核一个程序,或者一个团队就变的很微妙,那么通过什么样的方法或指标能衡量出一个程序,一个架构,或者甚至一个团队的工作呢?
悖论二:永远都不会出现的异常值
绩效考核里,最重要的是什么?是一切都在按照进度顺利进行吗?不!最重要的信息应该是异常的信息,比如什么任务的进度发生了延误,如果一些顺利什么,当然好,然而哪里除了问题才是最重要的.但是,绩效考核是经过层层提交的,每个层次的主管,都会尽量润泽考核,去除一些异常值,使整个过程看起来更加平稳,比如如果一个月的绩效很好,主管可能会把分数打得保守一些,为了接下来的月份里能够不至于太难做.如果情况不是很好,主管也会尽量选择一些内容补充进去.经过一层层的润色,最高主管看到的将是一些非常平稳的数据,因为那些宝贵的异常数据,都被削平了.
Q:怎样保证绩效反映的是最真实的情况呢?
(三)关于进度
悖论一:软件永远不能按时完成
帕金森定律:(Parkinson's Law):工期确定后,工作的实际进度会尽量充满他,也就是说,如果一个工作制定了周期,那么不管这个工作是否需要这么多时间,最后他的完成都会尽量接近这个周期,这当然不一定是坏事情,如果周期制定的合理,那么整个运转就很顺利,然而事实却是大家在制定周期时尽量的放宽时间,加入冗余,最后当然,会出现一个比实际情况冗余很多的周期,于是根据这个定律,工作的实际进度会仍然按照这个进度去实现.并且,开发中当然会插入许多临时的事情,于是进度会延后延后再延后,于是可以推出,软件永远不能按期交付.当然实际情况可能并不如此,但是按时交付的软件里面,是不是完成了所有的功能呢?是不是许多功能都因为某些临时的事情的插入而使用了临时的解决方法呢.
Q:那么我们怎样才能更合理的制定周期,从而提高大家的工作效率呢?