在我入行的时候,项目经理的Excel或Project里面经常看到我的名字,作为一个资源存在,随时供调配。这个起初还没有什么,但是某一天当我遇到一个烂掉渣的项目经理之后,就对这个越来越反感了。程序员的名字不应该仅仅是表格里面的一个资源,而是企业价值的实现者,没有企业员工你企业屁都不是。
通常一个公司在项目紧张的时候,程序员会面临加班赶进度,甚至熬夜的场景;由于市场环境和企业生存压力,可以理解,特别对于做项目的公司,客户从需求提出到上线,给你2个月时间,任性的要命。但是这种状况如果在一个公司是常态,程序员经常处于救火的状态,从一个项目到另外一个项目,不停切换,那就是公司的问题了。
程序员的劳动是一种较高强度的脑力密集型劳动,很难说将一个程序员放在什么地方,他就能产出多少的成果。一个好的程序员和一个差的程序员写出的程序,其性能,可读性,扩展性差几条街可能还找不到。如何让程序员自由发挥,产出超出预期的成果,是管理者的责任,也是一个好的技术管理者的衡量标准。在不停救火的状态下,程序员只能把你的功能实现,要说其他,那就算了吧!烂项目就是这么养成的,大家都是在自己的一定工作范围内把功能实现,否则老板会说你能力不行,还谈什么设计!还谈什么代码可读可维护!
几个具体建议:
-
给程序员提供一个宽敞的办公环境
有条件的话,可以提供较宽敞的办工桌和办公环境,不说什么人体工程学座椅,只要办工桌够大,办公室开阔,有思考问题的地方就行;没有条件也要创造条件。
-
倾听程序员的声音
项目到期完成不了,不是程序员的问题,是管理者的问题,如果能力不行,那么早开始你为什么看不出来,看出来了为什么不替换掉,不能替换为什么不重新调整工作计划;对进度把我不住,为什么不每天早会,每周周会进行进度调节;先听听程序员的说法,为什么没有完成,是几个项目同时进行,还是需求理解不透,还是技术遇到难点,作为管理者有没有及时发现问题,并帮助解决,见过烂的技术管理者,基本上只会责怪,只会催缴周报!
-
项目进度把控
虽然敏捷流行,但是一般公司也不会这个,但是你只要使用其中几个关键点就行,对项目也能进行把控,象上面说的早会,每个人说清楚自己昨天完成的事情和今天要做的事情,以及困难,这样项目进行中大家都能知道各自做的东西在整个项目中的作用;可以将每次迭代计划分配到人的每个任务写出来贴在墙上,精确到天,做完一个划掉一个,项目每个成员都看的清清楚楚,有压力的同时,动力自然也来了。
-
代码设计评审的重要性
相信现在阿里的代码也没能做到百分之百的评审后上线,但是这个不是你不进行代码设计评审的借口,特别是对于一个企业的核心系统,不然日积月累其结果就是,这个系统就是职业陷阱,谁接手谁离职!一次内部评审也就花个20分钟,说说思路就行,你说你没时间,你有没有想过你一天的工作效率多低,你一天真正集中写代码的时间也就三四个小时而已,其他时间被各种杂事占据,20分钟你也拿不出来。
-
让程序员承担起责任
不要让程序员只是作为一个功能的实现者,要让他们自己有能力的时候承担起一个系统来,人在被动接受任务的时候都会有种反抗心理,主动承担任务的时候,就截然相反了,对于有能力的程序员为什么不让他自己说了算呢!
-
团建的重要性
早前我在的一家公司,我所在的部门有个传统,每个季度都会有个大型的团建活动,把各个地方的员工一起聚在北京一起玩,让大家互相认识互相了解,潜移默化的就是以后工作起来大家比较默契,效率自然就高了。作为技术管理者,搞好搞活团建活动是个硬指标。
请听好了,程序员真的不是资源!
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于