从去年年底加班到现在,终于可以缓一缓了,这是一个“马拉松”式的项目。

半年多来事际上不只一个项目,而是一个项目马不停蹄不停地开发一个又一个新版本,其实客户都没来得及用呢,就不停地升级。。团队在半年的工作中,很少有时间休息,从时间上来说确实是个马拉松。

现在在回头看起来,当时不仅仅是时间上紧张,长期的工作压力使大家都身心俱疲,好几个环节从现在看起来,当时真的是有点手忙脚乱、不知所措,忙得找不到北了。好几次由于前期急于求成而留下了隐患,结果在发版前昔发现后“激动不已”。在临近发版时,由于之前尚未完全理清的需求问题导致的缺陷,哪怕是很细微的缺陷,对实现人员来说,无论是心理上还是生理上,都是巨大的压力。

另一方面,产品经理对于产品或是项目的推进有很高的期望与要求,这也许是公司产品经理考核方式的比较客观的作用;同样,产品或项目发布后在客户方发现的问题,对于测试来说,也是相当巨大的压力,这也会影响对测试人员的考核,这种考核在一定程度上加剧了一种现象——越是临近发版时,测试越发 “给力”,这就容易在临近发版的艰苦岁月里出现缺陷越改越多的现象。在电子政务的大背景下,由于行业竞争压力,以及政务行业信息化项目采购流程的成熟,当年MIS不费吹灰之力,甚至靠着点“先进技术”的噱头或是靠着客户上级部门一张“采购建议”就能轻松获取可观利润的现象,如今已经很难再出现了。公司的考核方式本质上无可厚非,这是保持一个大公司健壮发展的保障。但在客观上,这样的制度导致的加班加点马拉松式的工作方式,对公司的发展不一定会很大帮助。要知道,历史上第一个马拉松选手,跑完全程后放声高呼:欢呼吧,我们胜利了!说完他就挂了,然后,他虽然就没有然后了,但他的确开创了一种高级工作方式,对广大领导来说,他真是死得其所。这样的工作方式对广大实现人员和测试人员影响甚大:长期不间断的加班实际上是在透支广大年轻程序员的未来,当某个人无法再透支未来,或不愿再继续透支未来的时候,弱小的一线人员别无选择,他只能选择离开。如果他很优秀,他也许会引起领导的关注。但这个世界还是普通人居多,事实上越大的企业,越庞大的团体,这个现象越为普遍。大团体的领导者确实没有必要在意团体中某些普通员工的去留,但有一点不可否认,一个团体的文化,一个团体的内涵,实际上就是通过广大的“芸芸众生”来展现的。互联网行业就有这样的例子,行业翘楚,他很强,但是他的人才,一挖就跑,员工都悄悄的走了,正如他们悄悄的来,他们真的很难保持良好的企业文化,长此以往,来来去去进进出出就成了他们的企业文化了。

历史告诉我们,真正的历史都是由人民群众去书写的,人民群众是历史的创造者,而不是少数精英,少数精英只是历史发展的催化剂。这同时也告诉我们,精英要适量,多了没有用的。作为领导者,一味期望属下都是精英这个不对,也不现实。通俗的说,正如广大的农民工建造了高楼大厦一样,我们的项目就是由广大的“码农”创造的,精英可以一个人完成两个人的工作,但他绝对完成不了一堆人的工作;设计能够把一个项目设计的精妙绝伦,但咱公司卖的是项目、产品、服务,客户不会无聊到把我们的设计文档买回去玩的。再通俗一点儿的说吧,我们的广大码农,加班加点的码农,看着别人一对一对的过双休日,自己却一个人去公司直面一坨一坨代码的码农,这才是世界上最可爱的人啊!再再通俗一点的说,他走了,他留下来的“遗产”,谁维护啊?当然对于领导来说,这都不是事儿:这个谁谁,昨天那个谁谁谁走了,现在你接手他那块吧。。唉呀呀,以下屏蔽100个字。。吐槽可以屏蔽,但有一些话不得不说,作为领导者,这样的决策要甚重啊,有些时候认为不是事儿的事儿,往往就是被忽略了的大事儿。唉呀,话说回来,这些道理其实大家都知道的,时间紧,任务重,大家都很忙,忙不过来,领导也不好当啊!要知道,大多数人,自己不会去怪罪自己能力不足,或者说自己报怨自己能力不足的时候不会有什么心理负担;但要是因为别人的错误,尤其是领导者决策失误导致自己出现错误,那这个时候心理就会很寒心的。

总结一不小心就写了这么多,但事实上我还是没有找到解决问题的方法。如果我是开发经理,遇到这些一坨又一坨的状况,我该怎么应对呢?我该如何做好开发管理工作,保质保量地完成任务呢?我想我也是没有什么好办法的。在这里谨以此文记念半年来逝去青春,期待未来的岁月里自己能够有所成长,也期待着团队的成长。