二、谁在造坑？

软件项目涉众众多，造坑的多为项目实施团队内部，而究其原因也是多方面的，但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候客户并不具备软件项目的实施经验，而实施团队为了迎合客户意愿，也会多多少少的在这四了维度上做文章。资源、时间不足，轻质量重功能，往往成为造坑的契机。所以，不用怀疑，造坑的往往是我们自己。很难理解，真正挖出大坑的人，后也是填坑的人。一个人很容易被外部事务所左右，如“同假的多了，真的到成假的了一样”，多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过：“当别人做错了，你不要跟着去做！”所以，我认为工作是工作，不需要我们在其中融合多少兴趣，也不要求我们有过多的付出，但对于工作的成果则要求我们认真的对待。俗话说：“拿多少钱，办多少事！”如果多少有些团队意识，能够对自己的工作负责，那至少在意识上，我们能给自己少造些坑。

三、如何免坑？

一）清除盲区

以下观点，仅是我对软件项目中一些错误认识的归纳：

写出能用的程序行啦！我们应该首先清楚我们做的是什么，一个成熟的团队产出的可交付成果应该包括软件编程产品，相关文档，项目实施过程中的经验教训已经其它一些非形式的成果（培训）。这里，我们必须清楚的认识到，我们所开发是是编程产品，而不是我们个人的技术实践或大学的毕设。对于编程产品，我们必须认识到，其是产品级别的，必须保证质量，必须提高用户体验，必须考虑系统的诸多特性或维度。这一过程远比我们自己写个程序要复杂的多。设计需要不断地进行迭代；开发人员需要遵守严苛的规范，编写大量的注释和大量的异常处理；测试人员需要不断地进行各种重复测试，但是正是这种全局的规范，全体团队的不懈努力，才保证了我们的编程产物可以称之为产品。所以，一定要明确，我们要完成的是一个产品，而不是一个毕业设计，它不是一个人的技术实践，而是整个团队倾注精力去完成的佳成果。我们可以轻松的实现客户的某些需求，但需求背后的某些东西，需要我们认真对待，比如安全性和性能等。实现功能的程序谁都会写，而写出高质量的程序的才是真正的艺术。

尽快开始编码吧！软件构件是一个精心设计的过程，其前期准备十分重要。在后期修复缺陷的成本要远远高于前期。因此，在项目执行前，前期的规化十分必要。在前期每发现一个缺陷，都会为后期节省大量的成本。

需求怎么变了！没有不变的需求。

进度落后了招人呗！这是种典型的错误认识，《人月神话》中已经说明的很清楚了——往一个进度落后的项目中注入资源，只会使进度进一步落后。虽然，这本著作成为PM必读之作，其思想也被业界所广泛认可，但是，还是会有很多管理者单纯的认为，通过注入资源能解决问题。对于这些人，只能让实践来检验真理了。

软件质量保证是测试的工作！这是一种逃避责任的说辞。如果把代码质量比喻为减肥，那么测试无疑是一个磅秤，减肥工作还是要有开发人员来完成。所以，不要将代码质量都寄希望于测试工作上。即使是大规模的用户测试，其错误检出率也不足五成。而真正挑起代码质量重担的是代码审查。

程序员你8小时写了这么点代码？让开发人员将全部时间都花在编码上是不可能的。开发人员需要时间预读文档，需要与相关干系人进行沟通，需要花时间来搜索资源。此外，可能还需要编写文档，参加会议，培训以及处理个人事务等等。这些时间都会无情的夺走编码的时间。程序员大约有近似20%的时间甚至更多会用在与编码无关的事情上（不算上班或聊QQ），所以不要错误的以为每个程序员每天能写8小时的程序。

你写了这么多行代码真有效率！编码不是在扫地，比谁扫的面积大。不能单纯用行数来评价开发人员的工作量。评判的标准应该结合模块的复杂度，编码的缺陷检出量以及终交付时可用代码的比例（实践表明，我们报废了大量的无用代码）。

他把自己100多个BUG都改了，我们得在组里表扬下他！在我看来这样的领导不跟也罢，这是让人相当无语的行为。好的开发者在提交测试前，觉得会对自己的代码进行走查和调试，甚至使用单元测试工具，因此其代码的缺陷检出量很小。这样的程序员，才值得被表扬。而那个改了自己100多个BUG的人，作为管理者应该想想，流程哪里错了，需要进行改进。

设计我来定，开发你闭嘴！这样的例子也不少，这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为，如果将设计人员从开发人员剥离，那么可以将架构的概念完整性统一，因为设计人员的数量比开发人员是数量要少的多，更容易统一认识。而这样做的项目组，也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择的设计人员到设计组，但也会有走眼的时候。其一，硬手没有被提拔。这时候多半是硬手对设计不满，并对团队管理层产生质疑，并想法设法进行沟通。如果处理的好，可能硬手会被重视，如果沟通无门，那之后，可能会充斥着抱怨和不满，以及人际关系的恶化。有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是，挑的人干不了设计。这样往往是让他锻炼，而不是撤换（彼得原理——每个人都会被晋升到他不适合的岗位）。这郁闷到极点了，设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中，已经不只是个人的抱怨，甚至会演变成成员集体的士气低落，并终促成小组的重组。我认为，有必要将开发人员纳入设计活动。应该参考开发人员的意见，其原因有三：其一，开发人员对实现相当熟悉，往往发现设计中的不足；其二，通过授权开发者参与设计，能让其感受到认同感，提升其参与项目的欲望，和责任心；其三，让开发参与设计，可以对设计人员进行储备，在需要时作为备选资源使用。

客户（领导）说必须完成，我也没办法！这是“领导一句话，劳动人民跑断腿！”这是非常典型的加班借口。软件构建过程如同耕种，你每次只处理它的一小部分，一点一点的加到整个系统，使系统一点一点的“生长”。这也暗示了，工作应该按部班，正如春种秋收一样，各个环节有强硬的逻辑存在。所以，我们必须学会对不合理的要求说“不”。这里并不是说要拒绝客户的需求，而是指应该向客户说明情况并提出相应的备选方案以供参考。例如通过通过削减范围来达到按时完工的目的。PM需要向客户说明情况，并向其提供几套可行的解决方案，以促成项目向良性发展。

我是领导我来排进度！工作进度的安排不能是领导的单方决策，而应该参考做了解这项工作的人的意见。

系统上线了，项目算结束了！只有当可交付成果成功移交，项目进行的相应的收尾工作，项目的经验教训文档被总结和归纳，一个项目才算真正意义上的完成。