“谁也无法改变现状，唯有无数程序员血洒大地，才能使项目重建天日。”这一点也不夸张，软件项目做烂了是个坑，参与者也不过是填坑的。像是在魔兽世界战场遇到队一样，你赢也赢不了，出也出不去。

一、坑有多深？

当我们进入一个项目时，通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目，往往具有某些“臭味”，以下是我的一些认识，这些“臭味”即是项目健康状态不佳的明显标志：

编码规范形同废纸，代码质量低下。每个项目都有编码规范，但真正严格实施却是另一回事。太多的项目把编码规范作为形式的存在，没人在乎让开发人员写出“人能读懂的程序”，注释和命名也成了开发人员的随心所欲。project上永远只有开发任务，而几乎找不到单元测试的时间和代码审查的时间。在高压进度之下的项目，显得如此山寨。当我们还在抱怨自己工资低的时候，先看看我们的程序还能称作OOP吗。

缺乏文档或文档质量低下。前期文档很重要，不论是框架的API使用手册，还是需求或设计文档，以及各种既定流程的规范，不同种类的模板及核对表，等等这些文档，对于项目来说都是非常重要的资源。而往往有些项目，这类文档是交由非软件行业的人员来编写，或者前期根本不打算在文档上浪费时间。这导致了，缺少相关文档或文档质量低下，在软件构建过程中，开发者和团队，不得不为这种“表面工程”的产物而纠结。甚至会退回到前期准备工作，完成所需的文档。有些文档可以在后期补，但有些必须在前期进行准备，以保住团队降低风险，减少缺陷引人的几率并提高编码质量，如果前期这类文档没有做好，那么会像考前不复习一样，自食恶果。

无尽的需求变更，永远追不上的进度。这是常见也是可怕的，因为无论怎样，我们都无法完成它。客户可能认为改个程序，像改个Excel一样简单省事，甚至会使用可动用的一切权利和资源来推行变更。好吧，我承认这样的客户我遇到过很多。当我向客户解释过变更的代价并提供备选方案后，也只能等待客户的选择了，这多少有些运数的成分，但也是无奈之举。

仅仅靠加班应对进度落后。进度落后并不可怕，可怕的是仅靠加班来追赶进度。这是问题的关键，长时间的赶工仍然无法赶上进度，这只意味着项目有某种更深层次的问题，已经不是单开赶工可以解决的了。留意那些长时间加班的项目，他们往往在管理上存在很大问题，发现这些问题，在你成为PM时，不要犯类似错误。

沟通无门。如果你在一个“叫天天不应，叫地地不灵”的项目里，那你好省心吧。项目中沟通很重要，但总有些项目，领导的工作太忙，人是找不到，发出去的邮件是没人回，遇到问题是自己扛。在这样的项目里也有一些好处，比如锻炼自己的自学能力，以及磨练意志与根性。不过这些，也都是我的自嘲。低效的沟通将导致不必要的返工，这才是我所痛恨之处。我为恼火的一段经历是，甲方要进行变更，开了一周的会没人通知我，我的小组在这一周里完成了原计划的数个需求并进入到测试阶段， 但这些需求均被砍掉 。本来只有甲方告知是可以调整进度开发其它模块的，但终演变为资源的浪费。可见，沟通是多么的重要。

没人关心质量。因为软件构建属于专业领域，客户并不具备相应领域的知识，由于这种信息不对称，助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的，但不能够是“高等级低质量”的。但是，太多的项目不在注重编码质量，这与软件构建的复杂度有关，也与整个行业的风气有关。但不管何种原因，提高代码质量仍然应该作为团队的努力方向。团队应该奖励那些，编写高质量代码的程序员。如果你的团队奖励的是那些，“BUG杀手”（每天修改上百个BUG），而冷落那些缺陷检出数量很低的程序员，那么，你的PM是个不懂技术的，至少我本人认为，任何有技术背景的PM都应该奖励那些正在保持职业操守，认真对待需求，保证代码质量的程序员。他们为项目付出了更多，更多的异常处理， 更多的测试调试，更多的检查，更多的重构，虽然他们的进度并不快，但他们引人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍，而我敬佩那些选择质量程序员，因为他们才是真正拿开发当事业的人。在此，向所有努力提高代码质量的程序员致敬！

没人为缺陷买单，没人为自己的成果负责。需求产出了低质量的文档，设计没有进行充分的迭代，开发可以怎么简单怎么写，测试可以随意测测，没人为自己的成果中的缺陷买单，除了项目经理，他为项目承担责任。当项目组所有人员都在混时，是在给自己挖坑。这种缺陷的堆积，会像放射性元素在食物链中的堆积一样，早晚项目会因此而崩溃。

过高的离职率。这个是明显的“臭味”，这说明我们的同行已经在这里无法忍受了。它所带来的恶略影响不光体现在可用资源的减少，还体现在对成员士气的极大影响。如果不及时改善，这将是一个非常恶性的循环，当往一个进度落后的项目中添加资源只会使进度进一步落后，而非正离职导致必须补充新的资源，资源从入职到培训都会对对团队产生震荡，并降低现行团队的生产力。一个频繁处于形成阶段的团队，很难要求其有什么凝聚力，团队问题将会凸显，尤其是在沟通上，在项目忙的时候很少能照顾到新人。花费在对新人进行培训，和与其沟通上的时间，很可能得不偿失。

团队中的不良情绪。不同团队开始扎堆并相互敌视，例如开发组认为设计组是一帮搞业务的白痴，根本不懂编程；测试组认为开发组的人是垃圾，BUG提交了多少便还是无法关闭；PM开始抱怨，自己的成员不配合；成员开始抱怨，PM是个纯管理没资格指挥内行做事。等等，诸如此类的怨念会在团队中积累，并以某个导火索为契机爆发。面对现实吧，至少，我远没有自己想象的那样高尚。我承认我曾经会和别的程序员说：“你看XX他们写的代码...什么呀...”，这样的话。在过去我也吐槽过别人代码，这种做法是错误的，我为此表示歉意。现在，如果有必要，我会说代码有缺陷，但绝不会说他的代码不好。我希望，我们能彼此尊重。对于技术人来说，不尊重他的成果是不尊重他的人，所以我还是建议PM在管理工作中，多用“缺陷”，少用“不行”、“不对”。但是，项目中也总是有些人，靠鄙视别人的成果来彰显自己的实力。这些人，有，但很少。至少我遇到的很少，遇到过几个，让他们的话语成为你学习的动力吧。我曾经被人讽刺UI做的太丑，之后我学会了SL和FLEX；被人鄙视基础太差，之后开始阅读《CLR Via C#》；我朋友被人嘲笑过数据库设计，现在人家也开始买书深造。团队中是这样，我们无法管住别人的嘴，但我们可以管住自己的。少说多听，一鸣惊人，乃上上之策。不要受情绪的影响，保持一个平静的心。

没有项目或阶段的后评价。不对项目的阶段进行后评价，也意味着没人在乎你到底干了些什么，所有人都只是进度是否完成，而没有对完成的好坏进行评价。这也意味了，仅靠做好你的工作，你是无法得到领导的重视的。终只有那些加班时间长的程序员被领导认可。而能力强，口碑好的成员也只能在团队和客户中间留下传说。