Question

软件工程原本是只讨论“过程+方法+工具”的，这是纯粹工程学的视角 2 。这其中即使有一些看起来与人相关的话题，也不会被过深地讨论到。例如，过程中显然涉及人，但不会因此而讨论到“过程中的产品环节是否可以由开发人员来兼任”这样的问题。事实上，在“纯粹的”软件工程的讨论中，过程的各个环节都是由一些“角色”来推动的，这些角色如何存在于一个具体组织的部门中，其职业定位、能力结构等都并不算一个严格意义上的工程话题。

但是这样的“纯粹”显然遇到了挑战。当我们试图将工程完全地理论化之后，它就必然面临实践的困境。“人”的问题在这方面首当其冲。《人月神话》并不是一个“人/月”的度量理论那样简单——事实上那本书很少讨论工程度量的问题。《人月神话》在工程上的重要性在于，它严肃地提出了“人，是不是工程学问题的一部分”这样的话题。这本书的答案将这个话题引向了一个极其巨大的迷局，即如果需要更多的人来实现工程，则应付由人带来的复杂性可能将超过工程本身的技术复杂性。《人月神话》一方面有先见地对技术复杂性提出了一些可靠、可行的方案，另一方面也悲观地认为由人带来的复杂性必然导致“巴比伦塔”最终的倒掉。“没有银弹”的论证过程将所有的焦点集中于：通过（较小规模的）程序实现的过程，无助于求解（包含大规模工程在内的、普遍含义的）根本任务。

作者 Brooks 把三个问题从《人月神话》的讨论中摒除了出去。其一，项目必是有始终的；其二，哪怕是一个不成功的产品，也是需要交付的；其三，团队是人的问题，并不是事的问题。《人月神话》将这三个问题的前题隐设为：项目需要承担大量的附加责任，产品必须是尽善尽美的，以及人是私利的。而这正体现了“工程学”的学术本质，即如果我们可以的话，应当基于工程来解决一切问题；因而它必须首先是能解决一切问题的。

在这些年的实践中，这是我所见的、对“一件事”具有最大伤害的但又貌似义正辞严的、跨越行业与组织的普遍观点了。我之所以用这样复杂的定语来说明这一“普遍观点”，是因为它确实那样“自然而然”地存在着，就像我们每个行业都受了同一个神灵的启迪一般。事实正是如此。任何一个有道德、正义而又富有职业责任感的产品经理都会跳出来，说“这个产品没做好是我们的责任”，然后历数种种设计细节，再加以细化，并立时加入你的需求库；任何一个有同样品质的项目经理也都会跳出来，说“这个项目没做好是因为我们对流程的贯彻不够”，然后开始制定更详细的管理措施；然后开发人员也跳出来，说出超过 200 个的技术改进点……

但每个人都将问题揽在自己头上，这难道不是一种好的品质吗？如果是，那么我又怎么会用一种调侃的语气来说出上面的假设？

这样的假设，在于警示我们一个被忘掉的事实：这是一个系统，并不在于一人一已或者一个角色的过失，也不取决于某一个角色的单方面的努力。这些“积极、冲动而又充满道德责任感”的人，事实上是无助于找到系统问题的答案的。我们总是可以现实中找到许许多多具有这种性质的工程、产品与过程模型，并且在这样的模型中，（提出模型者所代表的）中心角色也总是认为自己应当能够并且也必须能够去承担更多——因而也就更重要，因而其他所有角色都应该围着自己打转转。

然而这样一来，每一个角色都站在一个自己认为“更合适”的角度来看我们在做的事情，而全然不管那件事情本身为何。例如，开发人员可能认为自己的某项技术发明有着相当“巨大”的前景，于是期望着有一个团队来配合自己将它实现为产品。至少在他看来，由技术推动产品和市场是相当伟大的成就。但是，一旦他提的这个想法如同扔进了泥坑一样丝毫得不到反馈，那么他又立即开始着手“发明”下一个技术与想法了。

你会发现，他原来根本不需要对产品和市场负上任何责任的！他只管提出，而不需要负责任，那么又怎么可能站在别的角色上去思考问题呢？

所以我再读《软件工程》这本教材的时候 3 ，就只会看到一些“管理的技术”了。然而我从不指望，把“管理”当成技术手段和工程方法的人能真正地做好项目。

我的意思是那个具体的、眼前的项目。