软件项目，什么叫坑爹！大家注意了
“谁也无法改变现状，唯有无数程序员血洒大地，才能使项目重建天日。”这一点也不夸张，软件项目做烂了就是个坑，参与者也不过是填坑的。就像是在魔兽世界战场遇到国家队一样，你赢也赢不了，出也出不去。
一 坑有多深？
当我们进入一个项目时，通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目，往往具有某些“臭味”，以下是我的一些认识，这些“臭味”即是项目健康状态不佳的明显标志：
◆ 编码规范形同废纸，代码质量低下 每个项目都有编码规范，但真正严格实施却是另一回事。太多的项目把编码规范作为形式的存在，没人在乎让开发人员写出“人能读懂的程序”，注释和命名也成了开发人员的随心所欲。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工具，调试工具，测试工具，文档管理，代码生成工具等等。
◆ 分析项目类型，在管理和构建之间找寻平衡 商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度，避免“过度控制”或“控制不足”。
◆ 需求必须被冻结 需求必须被冻结，如果需求不能冻结，那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。
◆ 变更必须走流程 正确应对变更，变更并不可怕，可怕的是失控的变更。以下建议希望对读者有所帮助：
在构建期间处理需求变更
|
◆ 关于加班 做IT的加班是很正常的，但加班要加的有意义，而且不应该长期加班。必须针对关键路径上的工作进行赶工，而不是做些无法加快整体进度的工作。而且，应当安排调休，而不是支付加班费。其主要原因也是我不赞成加班的原因——疲劳更容易引人缺陷。加班无疑会使人疲劳，每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下，人员的工作效率会下降，士气会低落，非正常离职率增加，最重要的是疲惫的团队很难保证软件的质量，缺陷在不知不觉中引人，在后期无疑会为此付出代价。项目的总成本和周期，都会随着引人缺陷的数量的增加而倍增，而且发现的越晚越严重。
◆ 做好版本控制和配置管理 版本控制和配置管理是必须有的，即便是再小的项目也不能忽视，必须加以重视，一旦版本混乱，多多少少会对构活动造成影响。所以，平时不要偷懒，管理好每个基线。
◆ 授权的好处 授权好处多多，包括：一，减少管理者工作量；二，对人员有意识地进行锻炼，培养储备人才；三，提高人员对项目的参与度，从而提高士气。
◆ 乐观管理与悲观管理 乐观与悲观完全取决于人的性格，一般来讲多数倾向于乐观，应该清楚这两种性格在项目中的优势与劣势。我本人倾向于悲观，可能是性格使然，但悲观的管理至少不会误事。乐观管理的优势在于，很容易营造气氛，擅长给客户或领导描绘一个美好的未来。这种作风，前期很舒服，但后期可能要吃苦了。乐观管理容易出现的问题是对风险的预计不足，不能预留充足的缓冲时间，没有准备足够的预防措施。其表现就是，在进行进度计划时，总是认为今天的问题今天可以解决，已经修复的BUG将不会再次出现，用户需求是最后一次变更，等等诸如此类的乐观想法会使管理者蒙蔽双眼，而没有做足风险应对，其结果就是不管怎么加班就是赶不上进度，因为进度计划被设计为最顺利的情形，而不是现实场景。悲观管理的好处是，为潜在风险做足了准备。但悲观管理有一个非常大的缺陷，就是“过度控制”，可以比喻为“疑心病”（小心的都有些病态了）。其表现是为：按照之前的措施，发现遗漏了一个问题，那么悲观管理者会在之前措施基础上增加新的保障措施，然后又发现遗漏了一个问题，之后会继续追加保障措施。乍看之下没啥问题，因为是在不断地进行过程改进，但问题出在保障措施的增长速度过于惊人，称其为“疑心病”一点也不为过，悲观管理者容易在很小的地方施加过多的控制，造成人日的浪费，而忽略掉本应该关注的更为重要的问题。不管那种性格的管理，清楚自己的弱点总是好的。
◆ 有效的沟通，不要踢皮球 软件项目因为其本身的复杂度和涉众众多，所以更加需要沟通。沟通问题是所有大型项目都共用的问题，在大多数团队中往往也不认为沟通是个问题。但我还是想请读者认真对待沟通，比如邮件。邮件可以回复的慢，但请回复邮件。当我在一个连发出的邮件都没人回复的团队中工作时，除了无法解决问题，让我感受到的只有无奈以及冷漠。
◆ 客户是我们的朋友 把你的客户当成朋友，客户是我们做重要的资源之一。在每个客户背后往往隐藏着更多潜在的客户。我们必须清楚，客户作为非专业人士，其可能并不理解我们的工作，在项目执行阶段产生摩擦是难免的。但是，这些都不能成为我们迁怒客户或故意在工作中放水的借口。即便是为了项目能成功收尾，我们也必须维护好与客户的关系。
◆ 不要超前设计，不要项目镀金 超前设计和项目镀金都是不可取的，因为他是在浪费资源。满足需求以外的东西，不会对你的项目有任何好处，但是却可能引人缺陷。
总结经验教训 必须对阶段进行经验教训总结，没有什么比这些收获更有价值。这样文档就是组织的资产，是以后类似项目的参考和依据，并在持续优化方面发挥更为重要的作用。
不要让会议和文档拖了团队的后腿 “当船快要沉的时候，我们需要的是一个发号施令的领袖，而不是开会。”软件项目的核心问题是降低复杂度，越是复杂的项目就越需要沟通，但别让开会拖了我们的后腿。没有必要的会尽量少开或不开，要常开会，开小会，每次会议就几个相关干系人碰头沟通下就可以了，没有必要扩大为全员参与。冗长的讨论应该适时的终止，毕竟会议室上只能做出决策，而解决问题还得在会下。所以我认为应该精简那些冗长的会议，别然开会成为我们的工作。此外，要时刻谨记客户最终需要的是可以良好运行的软件产品而不是华丽的文档。所以，文档要恰到好处，写的再漂亮的文档没有完备的系统也不过是废纸一堆，别丢了西瓜捡芝麻，可以正常工作的软件才是我们的工作重心。
◆ 核对表的你的好助手 就像飞机工程师在检查飞机时使用核对表一样，软件项目也可以大量使用核对表。核对表可以帮助检验文档的质量，降低缺陷数量，以及改进项目管理。好的核对表，是你工作中的好助手。
◆ 小范围的受控好过大范围的失控 要注意控制的粒度，事无巨细。根据项目规模，人员构成，要采用不同的控制粒度。评估可控范围，并不是控制越广越好，控制不了就是失控。 对无暇顾及的地方授权别人管理是个可行的做法。 即便是小范围是受控，也好过大范围的失控。一个失控的项目，谁也不知道其会走向何方。
