程序员的天花板

好久没写过博客了,最近离了职,有大把的时间思考,随便写点东西~~~

 

在我看来,程序员做的是开创性的工作。互联网的发展不但推动了技术的发展,而且带来了技术的普及。因此程序员不比以前,现在要找某方面的资料是很easy的事情了。看过大量的资料,各种新颖的技术方案和解决思路,不心动那是不可能的。OK,想用某某某框架,想用某某某技术,但是,因为各种原因,没办法应用到自己开发的项目中。这就是一个天花板。

在工作中往往有各种各样的天花板,比如绩效考核,项目进度,被打断的思路,技术架构。因为你不是做决定的那个人,所以你就有天花板。

1、绩效考核

很多公司都有绩效考核,在我看来绩效考核一个出发点很好,但是执行起来很扯淡的东西。从公司的角度来讲,保证每个员工都在努力工作是很必要的一件事情。绩效考核书面上讲是一个激励制度,我倒觉得更像是惩罚措施。绩效考核首要的问题是由谁来考核,在一个团队里不可能每个人都去考核一个人,也不会由普通员工之间进行考核,而是主管对普通员工进行考核。那就有可能滋生官僚主义,也会抑制主动性与创新力,增加犯错机会。如果,对员工的考核都由主管来进行,员工丝毫没有话语权,主管的人品就决定了团队的运作方式。如果主管不太能接受意见,那谁还敢提意见?一个团队了某人犯了错误,哪个主管敢给他背责任?因为也有更高的主管对小主管进行考核。团队之间完全没有了人情味,纯粹就是机器的运作方式。

在这种情况下,大家都加班,你敢不加班么?在这种情况下,主管听不进,你敢指出问题么?在这种情况下,你敢使用新技术,进行技术创新么?在这种情况下,你敢对现有代码进行重构么?要是敢,那出了问题你就得背负。所有反而不如踏踏实实地,就用现有的东西,出了问题,就是已有的问题,没有问题就是混日子。所以,绩效考核成了程序员的天花板,抑制了想象力与创作的热情。哪怕开发计划肯定也是瞄准最容易的,而不会去挑战什么了。

我认为,绩效考核用在无需创新的场合比较合适,在软件开发上,则面临如何去划分工作量,怎么客观得评估工作量,还有就是上面提到的一些问题。大家都知道,这个工作量是很难被确定的,因为需求的变更等原因,即使需求不变,开始时估计的工作量能按时完成的有几个?貌似很多书上都讲很多项目完成的周期在预计的1.5倍时间左右。

我认为只有一种情况可以使用绩效考核对程序员进行管理,那就是你不需要程序员进行思考,在软件设计阶段把所有的风险都规避了。比如瀑布模型开发,所有的东西都确定了,然后程序员只负责开发一个个方法,根本无需考虑算法问题,架构问题。程序员成了代码工人。估计这个程序员离离职也不远了。

2、项目进度

项目进度应该被强调。虽然项目进度也会对程序员的开发有一些抑制,但是不会太过明显。因为项目进度本身就是由他自己来确定的。项目进度虽然会抑制创新,但是会加强团队的整体感。假如甲开发的东西,是乙依赖的,那甲和乙肯定会保持沟通,并且,甲会对乙的进度负有一定的责任。如果甲是由责任感的话,只会让甲对团队有归属感。

但是如果本来是要一个月的开发任务,非要压缩到一周完成的,团队又会滋生新的问题了。一个是互相推诿,一个是团队不稳定(跳槽)。

 

3、被打断的思路

思路被打断是很恼火的事情,如果经常发生这样的情况,那是公司流程上有问题。只能从制度、流程上尽量规避这种事情。

 

4、技术架构

很多小公司其实并不存在这样的情况,因为技术架构就是由工程师直径决定的。在大一点的公司里,架构师设计的架构,就是程序员必须遵循的法则。比如,让你用Mysql你就不能用mongodb。有一些架构师设计出来的技术架构,还留有开发人员自己思考的空间,而有些架构师设计的技术架构,则完全抹杀开发人员的尝试。虽然技术架构保证了业务的稳定性,程序的规范性,可复用性,可维护性,可扩展性.....但对开发人员来讲,那种架构师好则自然不言而喻。

 

在团队管理中,要注重每个人,考虑每个人的发展,而不是抹杀掉他们的思考。总的来讲,团队里人才是最重要的。

posted @ 2012-04-09 17:31 Birdshover 阅读(...) 评论(...) 编辑 收藏