正在思考的几个管理方面的几个问题

今天药忘吃喽~ 2022-09-19 10:57 228阅读 0赞

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