软件项目“免坑”指南 .pdfVIP

软件项目“免坑”指南

“谁也无法改变现状，唯有无数程序员血洒大地，才能使项目重建天日。”这一点也

不夸张，软件项目做烂了就是个坑，参与者也不过是填坑的。就像是在魔兽世界战场遇到

国家队一样，你赢也赢不了，出也出不去。

一、坑有多深?

当我们进入一个项目时，通过不断观察我们可以发现我们的项目到底是不是一个坑。

造坑的项目，往往具有某些“臭味”，以下是我的一些认识，这些“臭味”即是项目健康

状态不佳的明显标志：

编码规范形同废纸，代码质量低下。每个项目都有编码规范，但真正严格实施却是另

一回事。太多的项目把编码规范作为形式的存在，没人在乎让开发人员写出“人能读懂的

程序”，注释和命名也成了开发人员的随心所欲。project上永远只有开发任务，而几乎

找不到单元测试的时间和代码审查的时间。在高压进度之下的项目，显得如此山寨。当我

们还在抱怨自己工资低的时候，就先看看我们的程序还能称作OOP吗。

缺乏文档或文档质量低下。前期文档很重要，不论是框架的API使用手册，还是需求

或设计文档，以及各种既定流程的规范，不同种类的模板及核对表，等等这些文档，对于

项目来说都是非常重要的资源。而往往有些项目，这类文档就是交由非软件行业的人员来

编写，或者前期根本不打算在文档上浪费时间。这就导致了，缺少相关文档或文档质量低

下，在软件构建过程中，开发者和团队，不得不为这种“表面工程”的产物而纠结。甚至

会退回到前期准备工作，完成所需的文档。有些文档可以在后期补，但有些必须在前期进

行准备，以保住团队降低风险，减少缺陷引人的几率并提高编码质量，如果前期这类文档

没有做好，那么就会像考前不复习一样，自食恶果。

无尽的需求变更，永远追不上的进度。这是最常见也是最可怕的，因为无论怎样，我

们都无法完成它。客户可能认为改个程序，就像改个Excel一样简单省事，甚至会使用可

动用的一切权利和资源来推行变更。好吧，我承认这样的客户我遇到过很多。当我向客户

解释过变更的代价并提供备选方案后，也就只能等待客户的选择了，这多少有些运数的成

分，但也是无奈之举。

仅仅靠加班应对进度落后。进度落后并不可怕，可怕的是仅靠加班来追赶进度。这是

问题的关键，长时间的赶工仍然无法赶上进度，这只意味着项目有某种更深层次的问题，

已经不是单开赶工可以解决的了。留意那些长时间加班的项目，他们往往在管理上存在很

大问题，发现这些问题，在你成为PM时，不要犯类似错误。

沟通无门。如果你在一个“叫天天不应，叫地地不灵”的项目里，那你最好省心吧。

项目中沟通很重要，但总有些项目，领导的工作太忙，人就是找不到，发出去的邮件就是

没人回，遇到问题就是自己扛。在这样的项目里也有一些好处，比如锻炼自己的自学能

力，以及磨练意志与根性。不过这些，也都是我的自嘲。低效的沟通将导致不必要的返

工，这才是我所痛恨之处。我最为恼火的一段经历是，甲方要进行变更，开了一周的会没

人通知我，我的小组在这一周里完成了原计划的数个需求并进入到测试阶段，但这些需求

均被砍掉。本来只有甲方告知是可以调整进度开发其它模块的，但最终演变为资源的浪

费。可见，沟通是多么的重要。

没人关心质量。因为软件构建属于专业领域，客户并不具备相应领域的知识，由于这

种信息不对称，助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的，但

不能够是“高等级低质量”的。但是，太多的项目不在注重编码质量，这与软件构建的复

杂度有关，也与整个行业的风气有关。但不管何种原因，提高代码质量仍然应该作为团队

的努力方向。团队应该奖励那些，编写高质量代码的程序员。如果你的团队奖励的是那

些，“BUG杀手”(每天修改上百个BUG)，而冷落那些缺陷检出数量很低的程序员，那么，

你的PM是个不懂技术的，至少我本人认为，任何有技术背景的PM都应该奖励那些正在保

持职业操守，认真对待需求，保证代码质量的程序员。他们为项目付出了更多，更多的异

常处理，更多的测试调试，更多的检查，更多的重构，虽然他们的进度并不快，但他们引

人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍，而我敬佩那些选择

质量程序员，因为他们才是真正拿开发当事业的人。在此，向所有努力提高代码质量的程

序员致敬!

没人为缺陷买单，没人为自己的成果负责。需求产出了低质量的文档，设计没有进行

充分的迭代，开发可以怎么简单怎么写，测试可以随意测测，没人为自己的成果中的缺陷

买单，除了项目经理，他为项目承担唯一责任。当项目组所有人员都在混时，就是在给自

己挖坑。这种缺陷的堆积，