程序员不是资源

在我入行的时候，项目经理的Excel或Project里面经常看到我的名字，作为一个资源存在，随时供调配。这个起初还没有什么，但是某一天当我遇到一个烂掉渣的项目经理之后，就对这个越来越反感了。程序员的名字不应该仅仅是表格里面的一个资源，而是企业价值的实现者，没有企业员工你企业屁都不是。

通常一个公司在项目紧张的时候，程序员会面临加班赶进度，甚至熬夜的场景；由于市场环境和企业生存压力，可以理解，特别对于做项目的公司，客户从需求提出到上线，给你2个月时间，任性的要命。但是这种状况如果在一个公司是常态，程序员经常处于救火的状态，从一个项目到另外一个项目，不停切换，那就是公司的问题了。

程序员的劳动是一种较高强度的脑力密集型劳动，很难说将一个程序员放在什么地方，他就能产出多少的成果。一个好的程序员和一个差的程序员写出的程序，其性能，可读性，扩展性差几条街可能还找不到。如何让程序员自由发挥，产出超出预期的成果，是管理者的责任，也是一个好的技术管理者的衡量标准。在不停救火的状态下，程序员只能把你的功能实现，要说其他，那就算了吧！烂项目就是这么养成的，大家都是在自己的一定工作范围内把功能实现，否则老板会说你能力不行，还谈什么设计！还谈什么代码可读可维护！

几个具体细节建议：

有条件的话，可以提供较宽敞的办工桌和办公环境，不说什么人体工程学座椅，只要办工桌够大，办公室开阔，有思考问题的地方就行；没有条件也要创造条件。

项目到期完成不了，不是程序员的问题，是管理者的问题，如果能力不行，那么早开始你为什么看不出来，看出来了为什么不替换掉，不能替换为什么不重新调整工作计划；对进度把我不住，为什么不每天早会，每周周会进行进度调节；先听听程序员的说法，为什么没有完成，是几个项目同时进行，还是需求理解不透，还是技术遇到难点，作为管理者有没有及时发现问题，并帮助解决，见过烂的技术管理者，基本上只会责怪，只会催缴周报！

虽然敏捷流行，但是一般公司也不会这个，但是你只要使用其中几个关键点就行，对项目也能进行把控，象上面说的早会，每个人说清楚自己昨天完成的事情和今天要做的事情，以及困难，这样项目进行中大家都能知道各自做的东西在整个项目中的作用；可以将每次迭代计划分配到人的每个任务写出来贴在墙上，精确到天，做完一个划掉一个，项目每个成员都看的清清楚楚，有压力的同时，动力自然也来了。

相信现在阿里的代码也没能做到百分之百的评审后上线，但是这个不是你不进行代码设计评审的借口，特别是对于一个企业的核心系统，不然日积月累其结果就是，这个系统就是职业陷阱，谁接手谁离职！一次内部评审也就花个20分钟，说说思路就行，你说你没时间，你有没有想过你一天的工作效率多低，你一天真正集中写代码的时间也就三四个小时而已，其他时间被各种杂事占据，20分钟你也拿不出来。

不要让程序员只是作为一个功能的实现者，要让他们自己有能力的时候承担起一个系统来，人在被动接受任务的时候都会有种反抗心理，主动承担任务的时候，就截然相反了，对于有能力的程序员为什么不让他自己说了算呢！

早前我在的一家公司，我所在的部门有个传统，每个季度都会有个大型的团建活动，把各个地方的员工一起聚在北京一起玩，让大家互相认识互相了解，潜移默化的就是以后工作起来大家比较默契，效率自然就高了。作为技术管理者，搞好搞活团建活动是个硬指标。

请听好了，程序员真的不是资源！