程序员的天花板

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

 

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

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

1、绩效考核

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

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

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

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

2、项目进度

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

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

 

3、被打断的思路

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

 

4、技术架构

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

 

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