第三十六条--研究再转化，不可行

关于软件工程研究所中令人难以置信的技术成就，有大量报道。但它们很少能应用于软件开发实践，原因是：

1.一般来说，软件研究者很少有开发实际系统的经验。

2.软件研究者可能会发现，在解决一些技术问题的时候没有必要花费过多时间去“适配”真实场景，这样可使解决问题变得更快更容易。

3.研究者和实践者在用语上存在巨大的分歧，导致他们很难相互沟通。

于是研究者更愿意在越来越多的无实际意义的问题上演示他们的想法。

要实现从研究所到开发机构的最成功的成果转化，从一开始双方就要紧密合作。需要使用工业界的环境作为萌发想法并验证效果的实验室，而不是在想法成形后再做技术转化。

第三十七条--要承担责任

在所有工程学科中，如果一个设计失败，工程师会受到责备。因此，当一座大桥倒塌时，我们会问“工程师哪里做错了?”当一个软件失败了，工程师很少受到责备。如果他们被责备了，他们会回答，“肯定是编译器出错了”，或“我只是按照指定方法的15个步骤做的”，或“我的经理让我这么干的”，或“计划剩余的时间不够”。事实是，在任何工程学科中，用最好的方法也可能产出糟糕的设计，用最过时的方法也可能做出精致的设计。

不要有任何借口。如果你是一个系统的开发者，把它做好是你的责任。要承担这个责任。要么做好，要么就压根不做。

第三十八条--低质量的需求分析，导致低质量的成本估算

POOR REQUIREMENTS YIELD POOR COST ESTIMATES

造成低质量成本估算的前5个原因，都与需求分析流程有关：

1.频繁的需求变更

2.不完整的需求列表

3.不充足的用户沟通

4.低质量的需求规格说明

5.不充分的需求分析

可以使用原型，来降低需求不准确的风险。可以使用配置管理，来控制需求变更。应该为将来的发布，规划好新的需求。应该使用更正式的方法，进行需求分析和编写需求规格说明。

第三十九条--先确定问题，再写需求

当面对他们认定的问题时，大多数工程师都会匆忙提供解决方案。如果工程师对这个问题的看法是正确的，那么解决方案可能奏效。然而，问题往往是难以捉摸的。例如，唐纳德·高斯(Donald Gause)和杰拉尔德·温伯格(Gerald Weinberg)描述了高层办公楼中的一个“问题”，里面的住户抱怨电梯等待时间太长。这真的是一个问题吗?这是谁的问题?从居住者的角度来看，问题可能是浪费了他们太多时间。从房主的角度来看，问题可能是入住率(及租金)可能会下降。

显而易见的解决办法是提高电梯的速度。但其他解决方法可能包括(1)增加新电梯，(2)错峰安排上班时间，(3)给快递保留一些电梯，(4)提高租金(这样业主可以接受降低后的入住率) ，(5)改进电梯使用的“归位算法”（homing algorithm)，以便在闲置时移动到高需求楼层。这些解决方案的成本、风险和时间延迟差别巨大。而任何一个方案生效，都取决于特定的场景。在试图解决问题前，针对面临问题的人及问题的本质，要确保深入分析了所有的可能选择。在解决问题时，不要被最初方案带来的潜在兴奋所蒙蔽。方案的变化总是比构建系统的成本低。

第四十条--立即确定需求

需求难以理解，更难以说明。对此，错误的解决方法是草率地完成需求规格说明，匆忙地进行设计和编码，然后徒劳地希望：

1.任何系统都比没有系统要好。

2.需求迟早会解决。

3.或者，设计师在开发的过程中会明确可以开发什么。

正确的解决方法是，立刻不计代价、尽可能多地获取需求信息。应使用原型的方法。要和更多的客户交谈。可以与客户一起工作一个月，以获得客户使用情况的第一手信息。要收集数据。要使用所有可能的手段。现在就把你所理解的需求记录下来，并规划构建一个满足这些需求的系统。如果你预期需求会发生很大变化，那也没关系。可以用增量的方式开发(见原则14)，但这并不是在任何一个增量开发上做不好需求规格说明的借口。