反对项目经理在项目计划中把程序员标志为“资源”

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

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

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

几个具体建议:

给程序员提供一个宽敞的办公环境

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

倾听程序员的声音

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

项目进度把控

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

代码设计评审的重要性

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

让程序员承担起责任

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

团建的重要性

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

请听好了,程序员真的不是资源!

本文文字及图片出自 www.yangchangming.com:8090

余下全文(1/3)
分享这篇文章:

请关注我们:

共有 2 条讨论

  1. 呵呵 其实你就是个资源,是人力资源,这有什么好发泄的?

  2. 人脉资源
    环境资源
    当一个个体(人或物)有了价值,就成为了资源。
    如果你自认没有价值,那你自然就不是资源同样也不会被别人标识为资源。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注