成事不足，败事有余

成事不足，败事有余

吴旻

泰岩网络工作室

 

         新接手的一个项目，由于曾经发生过核心人员的流动，结果留下来的成员对项目未能正确把握，所以项目处于僵死状态。应该说，留下来的项目人员是尽了力的了；但对于一个能力不足的人，再尽力也不可能完成这个项目，除非他的能力能够得到较大的提高。

         初、中级程序员一般会为了完成任务而完成任务，并对项目缺乏前瞻性的预估，结果项目做着做着，就慢慢死掉了。比如，为了省事，在A处分配的内存，要在不知道多远的N处释放，换句话说，时间一长，连写程序的人都不记得自己在哪里释放了内存。一开始程序是不会错的，然后不知道什么时候就开始错了。等到发现错的时候，已经不知道是怎么错的，在哪里错的，如何错的。总之程序会变得莫名其妙，甚至烧香磕头的心都有了，可还是解决不了问题。

         我的介入恰恰就是这个时候。我面临的困难大致有如下几个：

一、公司给的时间非常紧，要求限期加班完成；

二、项目架构混乱，代码编写随意，字面意思与实际含义经常不一致；

三、项目已经僵死，几乎很难调整，或者说项目组中的留下的程序员不愿意做架构上的调整，因为动一下就要牵扯很多东西，而这些东西有太多的不确定性，他们甚至会明确提出：你这样做，能保证解决问题吗？

四、留下的程序员已经没有任何活力，人心涣散，一肚子怨气，自信全无，有时甚至是处于宁愿等死，也不愿拼死一搏的状态。他们麻木了，死活都一样了，甚至更倾向于用去死解脱眼下的困境，或者说他们的是太需要休养生息才能继续战斗；

我发现我根本不能批评任何人，没准他们已经没日没夜的干了很长时间了；我也不能试图在短时间内重新燃起他们工作的热情，他们已经被工作折磨得没了生的自信。我只能试图自己来解决问题。当问题一个一个定位并变成历史的时候，我会想为什么有时候一个简单的事情会让他们做得如此复杂。思考良久，才意识到到团队能力不足的结果只能是让人觉得他们成事不足，败事有余。只要功能稍微变一些，他们就会把可以简单处理的事情弄得极其复杂；用政治的话说：他们只会激化矛盾，而不会化解问题于无形。当小问题累积到一定程度的时候，就是演变成严重的群体性事件，而且不排除群体性暴力的可能——程序崩溃！

这些程序员更愿意直接吃第七个馒头就饱，而不是先吃完前六个然后吃到第七个自然而然的就饱了。他们会直接和我讲：我们现在的问题不是代码重构，而是程序不稳定！言外之意，我在做一些无关痛痒的事情，而根本不是他们需要的事情。对此我只能一笑了之，这几乎没什么可争论的：他们期待的是神话中的英雄，无往而不胜。

事件的结果真的不那么重要了，让我觉得重要的是对人员的使用：如果团队人员能力不足，小心他们会成事不足，败事有余！