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

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

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

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

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

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