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

软件项目“免坑”指南 “谁也无法改变现状，唯有无数程序员血洒大地，才能使项目重建天日。”这一点也不夸张，软件项目做烂了就是个坑，参与者也不过是填坑的。就像是在魔兽世界战场遇到国家队一样，你赢也赢不了，出也出不去。一坑有多深？　　当我们进入一个项目时，通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目，往往具有某些“臭味”，以下是我的一些认识，这些“臭味”即是项目健康状态不佳的明显标志：编码规范形同废纸，代码质量低下?每个项目都有编码规范，但真正严格实施却是另一回事。太多的项目把编码规范作为形式的存在，没人在乎让开发人员写出“人能读懂的程序”，注释和命名也成了开发人员的随心所欲。project上永远只有开发任务，而几乎找不到单元测试的时间和代码审查的时间。在高压进度之下的项目，显得如此山寨。当我们还在抱怨自己工资低的时候，就先看看我们的程序还能称作OOP吗。缺乏文档或文档质量低下?前期文档很重要，不论是框架的API使用手册，还是需求或设计文档，以及各种既定流程的规范，不同种类的模板及核对表，等等这些文档，对于项目来说都是非常重要的资源。而往往有些项目，这类文档就是交由非软件行业的人员来编写，或者前期根本不打算在文档上浪费时间。这就导致了，缺少相关文档或文档质量低下，在软件构建过程中，开发者和团队，不得不为这种“表面工程”的产物而纠结。甚至会退回到前期准备工作，完成所需的文档。有些文档可以在后期补，但有些必须在前期进行准备，以保住团队降低风险，减少缺陷引人的几率并提高编码质量，如果前期这类文档没有做好，那么就会像考前不复习一样，自食恶果。无尽的需求变更，永远追不上的进度?这是最常见也是最可怕的，因为无论怎样，我们都无法完成它。客户可能认为改个程序，就像改个Excel一样简单省事，甚至会使用可动用的一切权利和资源来推行变更。好吧，我承认这样的客户我遇到过很多。当我向客户解释过变更的代价并提供备选方案后，也就只能等待客户的选择了，这多少有些运数的成分，但也是无奈之举。仅仅靠加班应对进度落后?进度落后并不可怕，可怕的是仅靠加班来追赶进度。这是问题的关键，长时间的赶工仍然无法赶上进度，这只意味着项目有某种更深层次的问题，已经不是单开赶工可以解决的了。留意那些长时间加班的项目，他们往往在管理上存在很大问题，发现这些问题，在你成为PM时，不要犯类似错误。沟通无门?如果你在一个“叫天天不应，叫地地不灵”的项目里，那你最好省心吧。项目中沟通很重要，但总有些项目，领导的工作太忙，人就是找不到，发出去的邮件就是没人回，遇到问题就是自己扛。在这样的项目里也有一些好处，比如锻炼自己的自学能力，以及磨练意志与根性。不过这些，也都是我的自嘲。低效的沟通将导致不必要的返工，这才是我所痛恨之处。我最为恼火的一段经历是，甲方要进行变更，开了一周的会没人通知我，我的小组在这一周里完成了原计划的数个需求并进入到测试阶段，?但这些需求均被砍掉?。本来只有甲方告知是可以调整进度开发其它模块的，但最终演变为资源的浪费。可见，沟通是多么的重要。没人关心质量?因为软件构建属于专业领域，客户并不具备相应领域的知识，由于这种信息不对称，助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的，但不能够是“高等级低质量”的。但是，太多的项目不在注重编码质量，这与软件构建的复杂度有关，也与整个行业的风气有关。但不管何种原因，提高代码质量仍然应该作为团队的努力方向。团队应该奖励那些，编写高质量代码的程序员。如果你的团队奖励的是那些，“BUG杀手”（每天修改上百个BUG），而冷落那些缺陷检出数量很低的程序员，那么，你的PM是个不懂技术的，至少我本人认为，任何有技术背景的PM都应该奖励那些正在保持职业操守，认真对待需求，保证代码质量的程序员。他们为项目付出了更多，更多的异常处理，更多的测试调试，更多的检查，更多的重构，虽然他们的进度并不快，但他们引人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍，而我敬佩那些选择质量程序员，因为他们才是真正拿开发当事业的人。在此，向所有努力提高代码质量的程序员致敬！没人为缺陷买单?没人为自己的成果负责。需求产出了低质量的文档，设计没有进行充分的迭代，开发可以怎么简单怎么写，测试可以随意测测，没人为自己的成果中的缺陷买单，除了项目经理，他为项目承担唯一责任。当项目组所有人员都在混时，就是在给自己挖坑。这种缺陷的堆积，会像放射性元素在食物链中的堆积一样，早晚项目会因此而崩溃。过高的离职率?这个是最明显的“臭味”，这说明我们的同行已经在这里无法忍受了。它所带来的恶略影响不光体现在可用资源的减少，还体现在对成员士气的极大影响。如果不及时改善，这将是一个非常恶性的循环，当往一个进度落后的项目中添加资源只会使进度进一步落后，而非正离职导致必须