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

一、坑有多深？

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

编码规范形同废纸，代码质量低下

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

缺乏文档或文档质量低下

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

无尽的需求变更，永远追不上的进度

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

仅仅靠加班应对进度落后

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

沟通无门

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

没人关心质量

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

没人为缺陷买单

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

过高的离职率

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

团队中的不良情绪

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

没有项目或阶段的后评价

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

二、谁在造坑？



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

三、如何免坑？

（一） 清除盲区

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

写出能用的程序就行啦！

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

尽快开始编码吧 ！

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

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

进度落后了就招人呗！

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

软件质量保证是测试的工作！

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

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

你今天写了这么多行代码真有效率！

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

他今天把自己100多个BUG都改了，我们得在组里表扬下他！

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

设计我来定，开发你闭嘴！

这样的例子也不少，这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为，如果将设计人员从开发人员剥离，那么就可以将架构的概念完整性统一，因为设计人员的数量比开发人员是数量要少的多，更容易统一认识。而这样做的项目组，也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组，但也会有走眼的时候。其一，硬手没有被提拔。这时候多半是硬手对设计不满，并对团队管理层产生质疑，并想法设法进行沟通。如果处理的好，可能硬手会被重视，如果沟通无门，那之后，可能会充斥着抱怨和不满，以及人际关系的恶化。

有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是，挑的人干不了设计。这样往往就是让他锻炼，而不是撤换（彼得原理——每个人都会被晋升到他不适合的岗位）。这就郁闷到极点了，设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中，已经不只是个人的抱怨，甚至会演变成成员集体的士气低落，并最终促成小组的重组。我认为，有必要将开发人员纳入设计活动。应该参考开发人员的意见，其原因有三：其一，开发人员对实现相当熟悉，往往发现设计中的不足；其二，通过授权开发者参与设计，能让其感受到认同感，提升其参与项目的欲望，和责任心；其三，让开发参与设计，可以对设计人员进行储备，在需要时作为备选资源使用。

客户（领导）说必须完成，我也没办法！

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

我是领导，我来排进度！

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

系统上线了，项目就算结束了！

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

（二） 参考建议

做好前期准备

前期准备很重要，如果在开始构建之前认真的地进行适当的准备活动，那么项目会运作的良好。充足的准备防止我们制造一个错误的产品。前期工作的好坏，多少会为这个项目的成功和失败打下基础。即使进入构建阶段，如果我们发现前期工作做的不好，也完全有理由退回去。前期准备工作和核心目标就是降低风险——一个好的项目规划者能够尽可能早地将主要的风险清除掉，以使项目的大部分工作能够尽可平稳地进行。目前，对后期影响最严重的风险是糟糕的需求分析和项目规划，因此准备工作就倾向于集中改进需求分析和项目规划。

预先行其事，必先利其器 用软件武装团队提高生产效率，例如：版本控制，错误跟踪，信息发布，自动发布，CASE工具，调试工具，测试工具，文档管理，代码生成工具等等。

分析项目类型，在管理和构建之间找寻平衡

商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度，避免“过度控制”或“控制不足”。

需求必须被冻结

需求必须被冻结，如果需求不能冻结，那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。

变更必须走流程

正确应对变更，变更并不可怕，可怕的是失控的变更。以下建议希望对读者有所帮助：

在构建期间处理需求变更

核对需求，评估质量：如果需求不够好，停下来，把它做好再开始。

确保每一个人都知道需求变更的代价：让客户知道需求办更并不像在Excel上进行几个修改那样容易，“进度”和“成本”是你最有力的武器。

建立一套变更控制程序：固定的变更控制程序让你知道在什么时候处理变更，让客户知道你会处理他们的提议。

使用能适应变更的开发方法：迭代与增量。

放弃这个项目：如果以上提议没有一条奏效，需求变更极其频繁，那么，评估你的项目，考虑放弃它吧，继续下去你只会越陷越深。

注意项目的商业案例：性价比，没必要满足超出项目成本的需求。

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

一、坑有多深？

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

编码规范形同废纸，代码质量低下

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

缺乏文档或文档质量低下

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

无尽的需求变更，永远追不上的进度

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

仅仅靠加班应对进度落后

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

沟通无门

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

没人关心质量

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

没人为缺陷买单

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

过高的离职率

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

团队中的不良情绪

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

没有项目或阶段的后评价

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

二、谁在造坑？



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

三、如何免坑？

（一） 清除盲区

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

写出能用的程序就行啦！

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

尽快开始编码吧 ！

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

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

进度落后了就招人呗！

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

软件质量保证是测试的工作！

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

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

你今天写了这么多行代码真有效率！

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

他今天把自己100多个BUG都改了，我们得在组里表扬下他！

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

设计我来定，开发你闭嘴！

这样的例子也不少，这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为，如果将设计人员从开发人员剥离，那么就可以将架构的概念完整性统一，因为设计人员的数量比开发人员是数量要少的多，更容易统一认识。而这样做的项目组，也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组，但也会有走眼的时候。其一，硬手没有被提拔。这时候多半是硬手对设计不满，并对团队管理层产生质疑，并想法设法进行沟通。如果处理的好，可能硬手会被重视，如果沟通无门，那之后，可能会充斥着抱怨和不满，以及人际关系的恶化。

有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是，挑的人干不了设计。这样往往就是让他锻炼，而不是撤换（彼得原理——每个人都会被晋升到他不适合的岗位）。这就郁闷到极点了，设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中，已经不只是个人的抱怨，甚至会演变成成员集体的士气低落，并最终促成小组的重组。我认为，有必要将开发人员纳入设计活动。应该参考开发人员的意见，其原因有三：其一，开发人员对实现相当熟悉，往往发现设计中的不足；其二，通过授权开发者参与设计，能让其感受到认同感，提升其参与项目的欲望，和责任心；其三，让开发参与设计，可以对设计人员进行储备，在需要时作为备选资源使用。

客户（领导）说必须完成，我也没办法！

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

我是领导，我来排进度！

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

系统上线了，项目就算结束了！

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

（二） 参考建议

做好前期准备

前期准备很重要，如果在开始构建之前认真的地进行适当的准备活动，那么项目会运作的良好。充足的准备防止我们制造一个错误的产品。前期工作的好坏，多少会为这个项目的成功和失败打下基础。即使进入构建阶段，如果我们发现前期工作做的不好，也完全有理由退回去。前期准备工作和核心目标就是降低风险——一个好的项目规划者能够尽可能早地将主要的风险清除掉，以使项目的大部分工作能够尽可平稳地进行。目前，对后期影响最严重的风险是糟糕的需求分析和项目规划，因此准备工作就倾向于集中改进需求分析和项目规划。

预先行其事，必先利其器 用软件武装团队提高生产效率，例如：版本控制，错误跟踪，信息发布，自动发布，CASE工具，调试工具，测试工具，文档管理，代码生成工具等等。

分析项目类型，在管理和构建之间找寻平衡

商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度，避免“过度控制”或“控制不足”。

需求必须被冻结

需求必须被冻结，如果需求不能冻结，那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。

变更必须走流程

正确应对变更，变更并不可怕，可怕的是失控的变更。以下建议希望对读者有所帮助：

在构建期间处理需求变更

核对需求，评估质量：如果需求不够好，停下来，把它做好再开始。

确保每一个人都知道需求变更的代价：让客户知道需求办更并不像在Excel上进行几个修改那样容易，“进度”和“成本”是你最有力的武器。

建立一套变更控制程序：固定的变更控制程序让你知道在什么时候处理变更，让客户知道你会处理他们的提议。

使用能适应变更的开发方法：迭代与增量。

放弃这个项目：如果以上提议没有一条奏效，需求变更极其频繁，那么，评估你的项目，考虑放弃它吧，继续下去你只会越陷越深。

注意项目的商业案例：性价比，没必要满足超出项目成本的需求。