二、谁在造坑？
软件项目涉众众多，造坑的多为项目实施团队内部，而究其原因也是多方面的，但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候客户并不具备软件项目的实施经验，而实施团队为了迎合客户意愿，也会多多少少的在这四了维度上做文章。资源、时间不足，轻质量重功能，往往成为造坑的契机。所以，不用怀疑，造坑的往往是我们自己。很难理解，真正挖出大坑的人，最后也是填坑的人。一个人很容易被外部事务所左右，就如“同假的多了，真的到成假的了一样”，多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过：“当别人做错了，你就不要跟着去做！”所以，我认为工作就是工作，不需要我们在其中融合多少兴趣，也不要求我们有过多的付出，但对于工作的成果则要求我们认真的对待。俗话说：“拿多少钱，办多少事！”如果多少有些团队意识，能够对自己的工作负责，那至少在意识上，我们能给自己少造些坑。
三、如何免坑？
（一）清除盲区
以下观点，仅是我对软件项目中一些错误认识的归纳：
● 写出能用的程序就行啦！我们应该首先清楚我们做的是什么，一个成熟的团队产出的可交付成果应该包括软件编程产品，相关文档，项目实施过程中的经验教训已经其它一些非形式的成果（培训）。这里，我们必须清楚的认识到，我们所开发是是编程产品，而不是我们个人的技术实践或大学的毕设。对于编程产品，我们必须认识到，其是产品级别的，必须保证质量，必须提高用户体验，必须考虑系统的诸多特性或维度。这一过程远比我们自己写个程序要复杂的多。设计需要不断地进行迭代；开发人员需要遵守严苛的规范，编写大量的注释和大量的异常处理；测试人员需要不断地进行各种重复测试，但是正是这种全局的规范，全体团队的不懈努力，才保证了我们的编程产物可以称之为产品。所以，一定要明确，我们要完成的是一个产品，而不是一个毕业设计，它不是一个人的技术实践，而是整个团队倾注精力去完成的最佳成果。我们可以轻松的实现客户的某些需求，但需求背后的某些东西，需要我们认真对待，比如安全性和性能等。实现功能的程序谁都会写，而写出高质量的程序的才是真正的艺术。
● 尽快开始编码吧！软件构件是一个精心设计的过程，其前期准备十分重要。在后期修复缺陷的成本要远远高于前期。因此，在项目执行前，前期的规化十分必要。在前期每发现一个缺陷，都会为后期节省大量的成本。
● 需求怎么变了！没有不变的需求。
● 进度落后了就招人呗！这是种典型的错误认识，《人月神话》中已经说明的很清楚了——往一个进度落后的项目中注入资源，只会使进度进一步落后。虽然，这本著作成为PM必读之作，其思想也被业界所广泛认可，但是，还是会有很多管理者单纯的认为，通过注入资源能解决问题。对于这些人，只能让实践来检验真理了。
● 软件质量保证是测试的工作！这是一种逃避责任的说辞。如果把代码质量比喻为减肥，那么测试无疑是一个磅秤，减肥工作还是要有开发人员来完成。所以，不要将代码质量都寄希望于测试工作上。即使是大规模的用户测试，其错误检出率也不足五成。而真正挑起代码质量重担的是代码审查。
● 程序员你8小时就写了这么点代码？让开发人员将全部时间都花在编码上是不可能的。开发人员需要时间预读文档，需要与相关干系人进行沟通，需要花时间来搜索资源。此外，可能还需要编写文档，参加会议，培训以及处理个人事务等等。这些时间都会无情的夺走编码的时间。程序员大约有近似20%的时间甚至更多会用在与编码无关的事情上（不算上班或聊QQ），所以不要错误的以为每个程序员每天能写8小时的程序。
● 你今天写了这么多行代码真有效率！编码不是在扫地，比谁扫的面积大。不能单纯用行数来评价开发人员的工作量。评判的标准应该结合模块的复杂度，编码的缺陷检出量以及最终交付时可用代码的比例（实践表明，我们报废了大量的无用代码）。
● 他今天把自己100多个BUG都改了，我们得在组里表扬下他！在我看来这样的领导不跟也罢，这就是让人相当无语的行为。好的开发者在提交测试前，觉得会对自己的代码进行走查和调试，甚至使用单元测试工具，因此其代码的缺陷检出量很小。这样的程序员，才值得被表扬。而那个一天改了自己100多个BUG的人，作为管理者应该想想，流程哪里错了，需要进行改进。
● 设计我来定，开发你闭嘴！这样的例子也不少，这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为，如果将设计人员从开发人员剥离，那么就可以将架构的概念完整性统一，因为设计人员的数量比开发人员是数量要少的多，更容易统一认识。而这样做的项目组，也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组，但也会有走眼的时候。其一，硬手没有被提拔。这时候多半是硬手对设计不满，并对团队管理层产生质疑，并想法设法进行沟通。如果处理的好，可能硬手会被重视，如果沟通无门，那之后，可能会充斥着抱怨和不满，以及人际关系的恶化。有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是，挑的人干不了设计。这样往往就是让他锻炼，而不是撤换（彼得原理——每个人都会被晋升到他不适合的岗位）。这就郁闷到极点了，设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中，已经不只是个人的抱怨，甚至会演变成成员集体的士气低落，并最终促成小组的重组。我认为，有必要将开发人员纳入设计活动。应该参考开发人员的意见，其原因有三：其一，开发人员对实现相当熟悉，往往发现设计中的不足；其二，通过授权开发者参与设计，能让其感受到认同感，提升其参与项目的欲望，和责任心；其三，让开发参与设计，可以对设计人员进行储备，在需要时作为备选资源使用。
